HTTP
1. WWW의 출범
"인터넷 공간에서 어떻게 정보를 안정적으로 공유할 것인가?"
팀 버너스 리 (이하 팀)는 인터넷 공간에서 정보를 안정적으로 주고 받기 위해서 World Wide Web을 설계했다.
HTTP 서머리에 앞서 WWW을 소개하는 이유는 HTTP가 WWW의 출범과 동 시기에 등장한, 웹 상의 정보 전달을 위해 고안된 개념이기 때문이다.
팀이 월드 와이드 웹을 만들게 된 간략한 뒷배경을 조금 설명하자면,
-
팀은 당시 유럽 입자 물리학 연구소 CERN의 연구원으로 근무중이었다
-
CERN에는 세계의 여러 대학에 수천명의 연구원들이 있었는데, 각자 이용하는 컴퓨터와 시스템이 달랐다.
=> 서로 간의 정보 공유·사용이 용이하지 않았고, 체계가 잡혀있지 않아 정보 유실의 문제 대두
"어떻게 하면 인터넷 공간에서 정보를 안정적·체계적으로 주고받을 수 있을까?"
또, 웹 = 인터넷이라 생각했던 나 같은 사람들을 위해...
아무튼
팀은 위 질문에 대한 해답으로 Internet에서 Hytertext를 통해 정보를 전달하는 방식을 연구하였고,
월드 와이드 웹과 함께 HTML, URI, 그리고 HTTP를 세상에 소개하게 된다.
월드 와이드 웹은 처음에는 웹 브라우저로 고안되었지만, (최초의 웹 브라우저)
점차 웹이 정보 공간으로서의 의미를 갖게 됨에 따라 '웹 브라우저'인 월드 와이드 웹은 후에 '넥서스'로 이름을 바꾸었다.
지금은 망했다."정보들을 Hyper Text들로 표현하여 연결"
위 문장 하나하나 뜯어보며 웹에서 HTML, URI, HTTP의 존재의의에 대해 되짚어보자.
-
HTML (HyperText Markup Language)
- "정보들을 Hyper text들로"
- 우선, 전달할 정보를 담을 형식이 필요하다.
- 정보를 자연어 그대로 전달할 수는 없기에, 웹 브라우저를 통해 display될 표준으로 HTML을 개발하게 되었다.
-
URI (Uniform Resource Identifier)
- "연결"
- 주고받을 정보는 HTML에 싣었고, 이제 "어디와" 통신할지가 관건이다.
- 전화번호도 모르고 전화를 걸 수는 없듯이 HTML을 주고받을 목적지가 있어야하고, 해당 목적지를 식별할 수 있는 유일한 "주소"가 필요하다
- 주소의 역할은 URI가 맡게 된다.
-
HTTP (HyperText Transfer Protocol)
-
정보는 HTML에 담았고 보낼 주소인 URI도 있다.
-
이제 어떻게 보내야 잘 보냈다고 소문이 날지 고민해야할 차례이다.
-
정보를 보낼 때 client와 server가 통신할 때 양측에서 해석할 수 있는 효율적인 양식이 필요한데, 이 것이 바로 HTTP이다.
-
2. HTTP와 server-client 관계
Hypertext Transfer Protocol (HTTP) is an application-layer protocol for transmitting hypermedia documents, such as HTML.
HTTP를 뜻 그대로 직독직해하자면 'Hypertext 통신규약' 이 되겠다.
간단한 설명은 위에서 마쳤으니 이쯤에서 갈무리하고, 가장 중요한 단어인 Protocol (규약)이란 단어에 집중해보자.
돌아보면 우리는 웹을 이용할 때 특정한 규약이나 양식에 맞추어 정보를 요청한 기억이 없다.
양식에 맞추기는 커녕, 양식이 무언지도 모르고 그저 웹의 화면을 클릭해서 다음 정보를 받아온 기억이 전부일 것이다.
여기서 다음 문장을 들여다보자.
HTTP follows a classical client-server model, with a client opening a connection to make a request, then waiting until it receives a response.
HTTP는 전통적인 client-server 모델을 따르며, client가 request를 전송하고, server는 response를 해준단다.
그렇다. 네이버 메인 로고를 클릭하는건 사람이 하지만, 네이버를 보내달라고 양식에 따라 "요청"하는 것은 사람의 몫이 아니다.
양식을 지킨 기억이 없다면 당연하다.
클라이언트인 웹 브라우저가 입력장치로부터 들어온 입력에 대해 HTTP 양식에 맞추어 대신 요청을 보내주기 때문이다.
이 때, 브라우저가 naver의 메인 페이지를 요청하는 것이 request이고, naver의 서버 측에서 naver의 메인 페이지를 보내주는 것이 response이다.
User - Client - Server의 상호작용은 다음 그림을 보면 이해하기 쉽다.
Client와 Server 사이의 통신, 정확히 말하자면 Client와 Server의 웹 상에서의 통신을 위한 규약이 HTTP인 것이다.
3. HTTP Request와 HTTP Response의 Format
드디어 지루한 배경설명이 지나고 HTTP가 어떻게 생겨먹은 녀석인지 확인해 볼 시간이다.
클라이언트는 어떤 양식으로 서버에게 request를 보내고, 서버는 어떤 양식으로 클라이언트에게 response를 돌려줄까?
HTTP의 Request와 Response는 4가지 Parts로 이루어진다.
- Start-line
- 이행되어야 할 request의 개요 혹은 response의 status가 성공적인지, 실패인지에 대해 => 무조건 한줄
- HTTP Headers
- request에 대해 명세하거나 body의 내용에 대해 묘사
- Empty line
- request를 위한 Meta 데이터의 종결을 알려주기 위해 한줄 띄워준다
- Body
- request나 response에 대해 전달해야할 data를 담는다. (optional)
- body의 사이즈나 존재 여부는 Start-line과 HTTP Headers에 명세되어있다
Start-line과 HTTP Headers 는 합쳐서 head of requests로 불리고,
Body는 payload로 불리기도 한다. 3.1 HTTP Requests Format
3.1.1 Start line
start line은 3가지 요소로 이루어져있다.
-
HTTP Method
- GET, PUT, POST, PATCH, HEAD, OPTIONS와 같이 동사 혹은 명사를 통해 어떠한 action을 server측에 보내는지 묘사
-
Request Target
- URL, protocol의 절대경로, 포트, 도메인 같은 action의 목적지
-
HTTP의 버전
3.1.2 Headers
잠시 후 개발자모드-네트워크 파트를 통해 슬쩍 들여다 보겠지만, HTTP Request의 Header는 증말로 다양하다.
종류는 다양하지만 대충 3가지 그룹으로 뭉뚱그려보자면,
-
Request Headers
-
request 보내는 놈이 뭐하는 놈인지 + 보내는 놈은 어떤 타입의 데이터를 수용하고 싶은지
-
ex) Host, User-Agent(내가 이용하고 있는 client와 OS의 정보), Accept(Client가 어떤 type의 data를 수용할지) 등등
-
-
Representation Headers
- request 보내는 놈이 보낼 정보에 대한 명세 => body가 없다면 없어도 된다
-
General headers
- 전송하는 메시지 전반에 적용되는 내용들
3.1.3 Body
Request의 마지막 부분으로 optional하다.
GET, HEAD, DELETE나 OPTIONS와 같이 정보를 받아오기만 하는 action에는 붙이지 않는다.
주로 data를 보내는 POST 메소드가 body를 포함한다.
3.2 HTTP Response Format
3.2.1 Status line
HTTP Response의 첫줄인 status line은 다음과 같은 정보를 포함한다.
-
프로토콜의 버전 => 주로 HTTP 1.1이다
-
status code: request가 성공했는지, 실패했는지, 혹은 다른 상태인지 (200, 404 등이 대표적)
-
status text : status code를 사람이 알기 쉽게 친절히 영어로 적어준다
3.2.2 Headers
Response Headers도 종류는 많지만, 아까와 동일한 3 그룹으로 나눌 수 있다.
전체적인 맥락 역시 동일하니, 위의 것과 대조해보며 보는 것도 좋을 것 같다.
-
Response Headers
- response 보내는 놈(server)에 대한 정보 + 보내는 놈은 어떤 타입의 데이터를 수용하는지
-
Representation Headers
- response 보내는 놈 (server)이 같이 보내는 data에 대한 설명 (데이터 타입, 인토딩 등)
-
General Headers
- request header와 마찬가지로 전송하는 메시지 전반에 적용되는 내용들이 담긴다.
3.2.3 Body
보통 request에서 요구하는 것이 데이터이기 때문에 대부분의 response는 body를 포함하지만, status code: 201 Created나 204 No Content 같이 동봉해 보낼 payload가 없는 경우 body를 포함하지 않기도 한다.
주로 HTML, 이미지나 영상과 같은 멀티 미디어 파일이 body에 실리게 된다.
4. 개발자 도구 - Network
지금까지 HTTP가 어떻게 생겨먹은 양식인지 알아보았다.
이제 HTTP Request와 Response를 실제로 확인해보자.
브라우저의 개발자 도구를 켜고, 네트워크 탭에 들어가서 확인해볼수 있다.
들어갔는데 아무것도 뜨지 않거나, network activity가 몇개 없다면...
네트워크 탭을 연 후에 새로고침을 한번 해주어야 해당 페이지의 요청/응답을 온전히 확인할 수 있다.
네트워크 탭이 열린 시점부터의 network activity를 기록하기 때문이다.
새로고침을 하면,
여기에 보이는 row들이 모두 HTTP Request-Response의 결과로 Server측에서 Client인 브라우저로 보낸 resource들이다.
테이블의 column들을 톺아보자
- Status: status code
- Scheme: 어떤 protocol을 통해 resource에 접근하는지
- Type: resource의 타입
- Initiator: 무엇이 해당 resource가 request되게 했는지 => 링크를 클릭하면 해당 resource가 request된 소스코드로 데려가준다
- Time: request가 얼마나 걸렸는지
- Waterfall: request의 단계를 시각적으로 표현
표의 header 부분을 우클릭하면 더 많은 정보를 column으로 표시할 수 있다.
표의 가장 위 network/ 요소를 클릭해보자.
보통 가장 먼저 도착하는 respose는 html을 담은 response다.
Headers 탭
Header 탭에서는 HTTP Request와 Response의 Headers 부분을 확인할 수 있다.
Gereral의 경우 해당 Request-Response의 일련의 과정에 대한 일반적인 정보를 보여준다. (주로 start-line 부분이 들어있는 것을 알 수 있다.)
하단으로 스크롤하면 Request Headers의 내용도 확인할 수 있으며, 위에서 서술한 일반적인 Format보다는 다양한 요소들이 명세되어있다.
Preview 탭
해당 resource의 preview를 확인할 수 있다.
위 이미지는 첫번째로 도착한 html에 대한 preview이기 때문에 브라우저를 통해 완벽하게 랜더링된 뷰와는 차이가 있다.
Response 탭
HTTP Response의 body, 즉 payload 부분을 확인할 수 있다.
해당 Request-Response는 HTML에 대한 것이기 때문에 HTML 파일의 헤더 부분이 보인다.
이번 response는 single line으로 작성되었는데, 보기 좋게 indent가 들어간 형태로 response가 보이기도 한다.
Initiator, Timing, Cookie 탭
앞서 설명한 initiator, timing과 cookie에 관한 정보를 확인할 수 있다.
References
