[네트워크] http의 구성 요소

 

웹 개발자로서 성장하기 위해서는 웹 통신 체계를 알고 있어야 한다고 생각한다.

개인적으로 토이프로젝트를 만들 때, 데이터 통신을 위해 http를 사용하게 되는데 사실상 내부 구조라던지 작동 방식을 모른채로 '그냥 써보는' 단계에 머물었던 것 같다.

 

이 기회에 한 번 http에 대해 고찰하고 정리해보는 시간을 가져보려고 한다.

 

 

http의 정의

---

---

HTTP(HyperText Transfer Protocol, 문화어: 초본문전송규약, 하이퍼본문전송규약)는 W3 상에서 정보를 주고받을 수 있는 프로토콜이다. 주로 HTML 문서를 주고받는 데에 쓰인다. 주로 TCP를 사용하고 HTTP/3 부터는 UDP를 사용하며, 80번 포트를 사용한다. 1996년 버전 1.0, 그리고 1999년 1.1이 각각 발표되었다. 

 

http는 클라이언트와 서버 사이에 이루어지는 요청과 응답의 프로토콜이라고 한다.

 

이렇게 http의 요청을 Http Request라고 하고, 응답을 Http Response라고 한다.

 

 

 

 

http 에서는 header와 body 부분으로 나뉘게 되는데 이는 헤더의 메타 정보의 끝을 알리는 빈 줄(blank line)이 역할을 하게 된다고 한다.

 

헤더의 request header 부분에서는 이러한 정보를 담고 있다고 한다.

 

• HTTP 메서드 -> 동사, 명사 부분의 정보를 담고 있다 -> 동사(GET, PUT, POST), 명사(HEAD, OPTIONS) -> 서버가 수행 해야할 동작을 나타냄.
• 두번째로는 URL 또는 프로토콜이나 도메인의 절대 경로 등의 정보가 포함될 수 있다. -> 아래에서 다시 자세히 설명
• 마지막에는 HTTP의 버전이 들어가게 된다. 메세지의 남은 구조를 표현하기 위해 사용됨.

 

보면 http의 아주 기본적인 메타 정보가 들어가는 것을 알 수 있다. 개인적으로는 HTTP의 메서드 형식을 어떻게 전달하는지 궁금했는데 http의 가장 처음에 그 정보를 알려주는 것으로 시작한다.

 

Http Request Header

---

 

http 헤더는 request, general, entity 헤더 부분으로 나뉠 수 있다.

 

• Request header는 fetch될 리소스나 클라이언트 자체의 정보를 담고 있는 header이다. 요청의 내용을 구체화 시키고, 제약사항이나 컨텍스트를 제공한다고 한다.
• General header는 요청과 응답 모두에 적용되지만 바디에서 최종적으로 전송되는 데이터와는 관련이 없는 header이다.
• Entity header는 컨텐츠 길이나 MIME 타입과 같이 엔티티 바디에 대한 자세한 정보를 포함하는 header이다.

http의 header에서는 대부분 클라이언트의 요청 사항과 관련된 정보를 담고 있는 것을 볼 수 있다.

다른 곳에서는 이러한 헤더의 길이가 꽤나 길어질 수 있다는 것을 주의하라고 한다.

 

 

Http Request Body

---

http의 body는 http의 종단에 위치하며, 모든 요청에 본문이 포함될 필요는 없다고 한다.

예를 들면 단순한 GET, HEAD, DELETE 등의 동작을 요청하는 것에는 본문이 굳이 필요 없다는 것.

 

이러한 본문은 두 가지 영역을 가지게 되는데,

 

• 단일-리소스 본문(single-resource bodies) : 헤더 두 개(Content-Length, Content-Type)로 정의된 단일 파일로 구성
• 다중-리소스 본문(multiple-resource bodies) : 멀티파트 본문으로 구성되는 다중 리소스 본문에서는 파트마다 다른 정보를 지니게 된다고 한다. -> HTML form과 관련이 있다고 한다.

 

여기서 좀 신기한 게 보이는 것이, 보통 AJAX로 파일을 전송하기 위해서는 multipart/data의 형식을 지정해 주게 되는데 아마도 이 body 부분의 다중-리소스 본문을 사용하기 위한 부분이지 않을까 싶다.

 

 

Http Response Header

---

http response의 경우 응답의 가장 처음에 오는 정보는 상태 줄(status line)이라고 한다.

이런 상태 줄은 여러가지의 정보를 포함하게 되는데,

 

• 프로토콜 버전 : 보통은 HTTP/1.1 이라고 한다.
• 상태 코드 : 요청의 성공 여부를 나타낸다 -> ex) 200, 404, 302...etc.
• 상태 텍스트 : 짧고 간결한 텍스트로 사용자에게 상태에 대한 이해를 쉽게 해주기 위해 쓴다.

보통 인터넷을 하게 될 때, 사이트에서 많이 보게 되는 404에러는 이런 http response에 정보가 담겨와 최종적으로 우리에게 보여주는 것을 알 수 있다.

 

http의 response header를 보면 request header보다 복잡하다는 것을 알 수 있다.

 

• General header : 메세지 전체에 적용되는 내용을 포함.
• Response header : Vary와 Accept-Ranges와 같은 헤더는 상태 줄에 미처 들어가지 못했던 서버에 대한 추가 정보를 제공한다고 한다. -> 아직은 나도 잘 모르겠다. 나중에 다시 알아봐야겠다.
• Entity header : Content-Length 와 같은 헤더는 요청 본문에 적용된다고 한다. 이 경우 당연히 본문이 없을 경우 entity 헤더는 전송 되지 않는다.

 

Http Response Body

---

본문은 의외로 헤더보다 볼 게 없는 것 같다.

 

크게 3가지로 구성될 수 있는데

• 길이가 알려진 단일-리소스 본문 : 헤더 두 개(Content-Length, Content-Type)로 정의.
• 길이를 알 수 없는 단일 파일로 구성된 단일-리소스 본문 : Transfer-Encoding가 chunked로 설정되어 있으며, 파일은 청크로 나뉘어 인코딩 되어 있다고 한다. -> chunked로 설정될 경우 Content-Length는 생략되게 되며, 청크의 길이가 16진수로 표현되어 오고, 이후 청크 데이터 파일이 들어오는 형식이라고 한다.
• 서로 다른 정보를 담고 있는 멀티 파트로 이루어진 다중-리소스 본문 : 상대적으로 위의 두 경우보다 보기 힘들다고 한다. -> 아마 파일 전송이나 그런 부분에서 사용하는 듯.

 

http response 본문의 청크 전송 방식은 내가 최근에 시도하던 스트리밍 기능 구현에 도움이 될 거라고 생각한다.

 

보통 실시간 스트리밍의 경우 앞으로 들어오게 될 정보의 길이를 모르는 경우가 대부분인데,

미리 정보의 길이를 알려주는 것이 아닌 그때그때마다 알려줌으로써 데이터의 길이와 상관 없이 정보를 보내는데 있어서는 좋은 방법이라고 생각한다.