[Network] 웹 브라우저 요청과 HTTP 리퀘스트

✔️ URL 입력과 패킷 여행

 

교재에 나와있는 내용이지만 나름 정리해보고 싶어서 다시 그림을 그려보았다.

클라이언트, 웹 서버 LAN, 웹 서버까지 한 번 돌아보면서 정리를 한 다음, 시간이 될 때 허브나 회선 쪽을 공부해보고자 한다.

(성공과 실패를 결정하는 1% 의 네트워크 원리를 읽고 정리한 내용입니다 :D)

 

---

 

✔️ 사용자가 URL을 입력했을 때 생기는 일

이 부분에 대해서 알아보자!

URL이란 무엇일까? Uniform Resource Locator로, http://로 시작하는 것뿐만 아니라 file:, ftp:, mailto: 등등 다양한 종류의 것으로 시작하는 URL들이 존재한다. 브라우저는 단순히 웹 서버에 엑세스 하는 역할만 하는 것이 아닌, 파일 다운로드, 업로드 같은 FTP 클라이언트나 메일 클라이언트 기능도 있기 때문에 여러 종류의 URL을 통해 어떻게 데이터에 엑세스할지 결정하게 된다.

 

대표적으로 몇 가지의 URL 형식을 살펴보자.

 

1) HTTP 프로토콜

http://user:password@www.cyber.co.kr:80/dir/file1.html 

user: 사용자명 (생략 가능)

password: 패스워드 (생략 가능)

www.cyber.co.kr: 웹 서버의 도메인명

80: 포트 번호 (생략 가능)

dir/file1.html: 파일의 경로명

 

2) FTP 프로토콜 - 파일 다운로드 / 업로드

ftp://user:password@ftp.cyber.co.kr:80/dir/file1.html 

user: 사용자명 (생략 가능)

password: 패스워드 (생략 가능)

ftp.cyber.co.kr: ftp 서버의 도메인명

80: 포트 번호 (생략 가능)

dir/file1.html: 파일의 경로명

 

3) 로컬 파일의 데이터 읽기

file://localhost/c:path/file1.html 

localhost: 컴퓨터명 (생략 가능)

/c:path/file1.html: 파일의 경로명

 

우리는 URL이 어떤 식으로 구성되어 있는지 알게 되었다.

그렇다면 우리가 브라우저에 URL을 입력했을 때 어떤 일이 일어나는지 생각해보자.

 

 

🌱 브라우저 - URL 해독하기

먼저, 아까 위의 그림에서 봤던 것처럼 사용자가 URL을 입력하면 브라우저는 이를 해석하여 HTTP 메시지를 만든다.

URL을 해독할 때는 크게 프로토콜 / 웹 서버 / 그리고 파일의 경로명으로 나누게 된다.

그리고, '웹 서버에 있는' ~~라는 '파일'에 엑세스한다는 의미로 URL을 구성하게 된다.

 

http://www.wootecho.co.kr/dir/file1.html

-> 여기서 /dir/file1.html은 파일명을 의미하며, 생략이 가능하다.

파일명을 생략했다면, 서버는 어떤 파일에 엑세스를 해야 할까?

기본적으로 서버에서는 파일명을 생략할 때를 대비하여 (대부분의 경우) index.html이나 default.html을 설정해둔다.

 

http://www.google.com 

위의 url에서는 디렉터리와 파일명까지 함께 생략한 경우이다.

이 경우 디렉터리는 루트 (/)로 설정이 되고, 해당 디렉터리 하위에 설정된 파일에 엑세스하게 된다.

 

 

🌱 HTTP가 무엇일까?

HTTP 프로토콜은 클라이언트와 서버가 주고받는 메시지의 내용이나 순서를 정한 것이다.

클라이언트 -> 서버로 request message를 보내는데, 이때 메시지 안에는 '무엇을', '어떻게' 할지 적혀있다.

 

그리고, 여기서 '무엇을'에 해당하는 것이 URI이며, 보통 CGI 프로그램의 파일명을 URI로 사용한다. 

(CGI 프로그램 = 웹 서버와 외부 프로그램 사이에 정보를 주고받는 방법이나 규약을 지킨 프로그램 - ex. /dir1/file1.html)

물론, URI로 URL을 그대로 사용할 수 있으며, 어디에 엑세스 할지를 정하는 게 URI라고 생각하면 된다.

 

'어떻게'에 해당하는 것은 Http method이다. 웹 서버에게 어떤 동작을 하고 싶은지 전달하는 개념이다.

 

대표적인 HTTP method에 대해서 알아보자.

메서드	의미
GET	URI로 지정한 정보를 도출한다. 파일의 경우 해당 파일의 내용을 그대로, CGI 프로그램은 해당 프로그램의 출력 데이터를 전송한다.
POST	클라이언트에서 서버로 데이터를 송신한다.
HEAD	HTTP 메서드 헤더만 반송하고, 데이터의 내용은 돌려보내지 않는다.
OPTIONS	통신 옵션을 통지하거나 조사할 때 사용한다.
PUT	URI로 지정한 서버의 파일을 치환한다. 파일이 없는 경우에는 새로 파일을 작성한다.
DELETE	URI로 지정한 서버의 파일을 삭제한다.
TRACE	서버측에서 받은 리퀘스트 라인과 헤더를 그대로 클라이언트에 반송한다. 프록시 서버 등을 사용할 때 리퀘스트가 치환되는 상태를 조사할 때 사용한다.
CONNECT	암호화한 메시지를 프록시로 전송할 때 이용한다.

그리고, 리퀘스트 메시지가 웹 서버에 도착하면 웹 서버는 속에 쓰여있는 내용을 해독한다.

내용에 따라 동작을 하고, 결과 데이터를 응답 메시지에 저장하는데, 이때 맨 앞부분에는 실행 결과에 대한 상태를 나타내는 상태 코드를 저장한다. (ex. 200, 400, 404, 500...)

이 부분도 내용이 많지만, 네트워크의 개론을 다루는 것이기 때문에 세부 내용은 생략하도록 하겠다.

 

 

🌱 HTTP 리퀘스트 메시지 만들기

우리는 사용자가 url을 입력하면, 브라우저가 url을 해독하여 Http 메시지를 만든다고 하였다.

이때, 메시지는 그냥 쓰는 것이 아닌, 별도의 포맷에 맞게 생성하게 된다.

 

1) request message

<메서드><공백><URI><공백><HTTP 버전>
<필드명>:<필드값>
...
<공백 행>
<메시지 본문>

요청 메시지는 위와 같은 구조로 이루어져 있다.

첫 번째 행은 request line으로, 위의 request에 대한 대략적인 정보들이 담겨있는 행이다.

그 다음부터 공백까지는 header로, 한 행마다 한 개의 헤더 필드를 작성한다.

마지막 부분은 message body로, 클라이언트에서 서버에 송신하는 데이터가 들어간다.

 

 

2) response message

<HTTP 버전><공백><상태 코드><공백><응답 문구>
<필드명>:<필드값>
...
<공백 행>
<메시지 본문>

응답 메시지는 위와 같은 구조로 이루어져 있다.

첫 번째 행은 status line으로, 응답 코드에 대한 내용을 나타낸다.

그 다음부터 공백까지는 마찬가지로 메시지 헤더고, 마지막 부분은 바디값으로 서버에서 클라이언트로 송신하는 데이터가 들어간다.

 

message header의 경우 날짜(date), 클라이언트 측이 취급하는 데이터 종류 (Accept), 언어 (Language), 클라이언트나 서버의 소프트웨어 명칭과 버전, 데이터 유효 기간 등의 다수의 항목들이 존재한다.

헤더 이름	설명
General Header: 요청 - 응답 양쪽에 사용
Date	요청 - 응답이 작성된 날짜
Pragma	데이터의 캐시 허용 여부
Cache-Control	케시 제어를 위한 저옵
Connection	응답 송신 후 TCP 커넥션을 유지할지, 끊을지 옵션
Transfer-Encoding	메시지 바디의 인코딩 형식 지정
Via	도중에 경유한 프록시나 게이트웨이 기록
Request Header - 요청에 대한 부가 정보
Authorization	사용자 인증용 데이터
From	리퀘스트 발신자의 메일 주소
If-Modified-Since	지정한 날짜 이후 정보가 갱신된 경우만 리퀘스트를 실행할 때, 이 필드에 날짜를 지정하면 된다. 클라이언트가 캐시에 저장된 정보를 비교하고, 새로운 정보로 갱신할 때 사용하는 필드
Referer	하이퍼링크를 거쳐 어느 페이지를 읽은 경우, 링크 대상 URI를 나타내는 필드
User-Agent	클라이언트 소프트웨어의 명칭이나 버전 정보
Accept	클라이언트 측이 Content-Type으로 받는 데이터 종류
Accept-Charset	클라이언트측이 받은 문자 코드 세트
Accept-Encoding	클라이언트측이 Content-Encoding으로 받은 인코딩 방식
Accept-Language	클라이언트측이 받는 언어의 종류
Host	리퀘스트를 받는 서버의 IP 주소와 포트 번호
If-Match	Etag 참조
If-None-Match	Etag 참조
Range	데이터 일부를 읽을 때 범위 지정
Response Header - 응답의 부가 정보로 사용되는 헤더 필드
Location	정보의 정확한 장소를 지정한다. 리퀘스트 URI가 relative name때 absolute name으로 했을 때의 정보의 위치를 통지하기 위해 사용한다
Server	서버 소프트웨어의 명칭이나 버전에 관한 정보
WWW-Authenticate	요청한 정보에 대해 엑세스가 제한되어 있는 경우, 사용자 인증용 데이터 반송
Accept-Ranges	Range를 지정했을 때 서버가 해당 기능을 가지고 있는지에 대한 여부
Entity Header - message body의 부가 정보로 사용하는 헤더 필드
Allow	지정한 URI로 사용 가능한 메서드를 나타낸다.
Content-Encoding	message body에 압축 등의 인코딩 처리가 되어 있는 경우, 해당 방식을 나타낸다.
Content-Length	message body의 길이를 나타낸다
Content-Type	message body가 어떤 데이터인지 종류를 나타낸다
Expires	message body의 유효기간을 나타낸다
Last-Modified	정보를 최종적으로 변경한 날짜
Content-Language	message body의 언어
Content-Location	message body가 서버의 어디에 있는지 URI로 표현
Content-Range	일부만 리퀘스트 되었을 때, 메시지 본문에 어느 범위의 데이터가 표현되어 있는지 나타냄
Etag	이전 리퀘스트의 응답을 바탕으로 한 갱신 데이터를 다음 리퀘스트에서 송신할 때, 이 둘을 관련시키기 위해 사용하는 정보. 쿠키와 비슷한 역할을 한다. (서버가 Etag에 값 전달 - 클라이언트는 If-Match 같은 필드를 통해 값 통지...)

 

message body의 경우 메시지의 실제 내용을 의미한다.

단, GET 요청의 경우 메서드와 URI로 웹 서버가 무엇을 할지 판단할 수 있기 때문에 본문이 비어있다. (헤더까지만 존재)

 

 

🌱 리퀘스트 메시지에 따른 응답 메시지

이번 챕터에서는 간략하게 무엇인지만 다룬다.

응답이 정상 종료나 오류가 발생했는지, 실행 결과를 나타내는 응답 코드와 응답 문구를 첫 번째 행에 작성한다.

응답 코드의 경우 숫자로, 응답 문구는 문장으로 쓰여있으며 프로그램과 사람에게 보여지는 것이 각각의 목적이다.

이후 응답 메시지를 바탕으로, 화면에 표시하는 역할까지가 브라우저의 역할이다.

 

---

정말 간략하게 다루고 있어서 대략적으로만 작성하였다.

나중에 조금 더 자세한 부분을 알아봐야겠다...!