HTTP
HTTP는 인터넷에서 데이터를 주고받을 수 있는 어플리케이션 계층의 프로토콜입니다. 데이터는 HTML 문서가 될 수도 있고, 이미지, 영상, JSON까지 대부분의 형태의 데이터입니다.
현재 가장 많이 쓰이고 있는 HTTP 버전은 HTTP/1.1부터 시작합니다.
HTTP/1.1
HTTP 통신은 TCP를 이용하기 때문에 연결설정(3-way handshake)이 필요합니다. 1.1버전 이전에는 연결을 유지하기 위해서는 keep-alive header를 이용해야했지만, 1.1버전부터는 기존적으로 연결을 유지시켜주어 헤더 오버헤드를 줄였습니다.
또한 병렬 요청이 가능한 Pipelining 방식이 도입되었습니다.
HTTP/2
HTTP/1.1은 여전히 많은 문제점을 가지고있었습니다.
- 1.1에서 Pipelining을 통한 병렬처리를 가능하게 하였는데, 먼저 보낸 요청이 지연되면 뒤에 전송된 요청도 결국엔 같이 대기해야하는 HoL(Head-of-Line) Blocking이 발생합니다.
`2. 하나의 연결에서는 하나의 요청만이 처리가능하므로 요청마다 연결설정(3-way handshake)을 해주어야 하는데, overhead가 커 RTT(Round Trip Time)이 증가합니다. - header의 메타데이터가 중복 전송되는 오버헤드가 존재합니다.
HTTP/2는 HTTP/1.1의 위의 문제점들을 개선한 버전입니다.
- Multiplexed Streams : 하나의 연결에 여러 개의 요청을 가능하게 하였습니다. 또한 stream 형식으로 데이터를 주고 받음으로써 순서가 중요시되지 않습니다.
- Server Push : 클라이언트가 요청하지 않았지만 추가적으로 필요할 것이라 예상되는 리소스를 서버가 전송해줌으로써 재요청하는 오버헤드를 줄일 수 있습니다.
ex) 클라이언트가 HTML 문서를 요청했지만, 서버는 이와 관련된 css, js파일까지 전송 - Header Compression : 중복 헤더는 인덱스만 검출하고, 나머지는 허프만 코딩으로 압축하여 전송합니다.
HTTP/3
HTTP/3는 비교적 최근에 등장했습니다. 2019년 9월 크롬에서 처음 지원이 되었는데, 이전 버전과의 차이는 UDP로 HTTP통신을 한다는 점입니다.
특징
- client - Server 구조
클라이언트가 서버에 요청을 보내면, 서버는 요청에 대한 결과를 만들어 응답하는 단방향 통신입니다. - Stateless 형식
클라이언트의 상태를 저장하지 않습니다. 즉 이전의 요청에 대한 응답을 저장해두지 않는다는 것입니다.
Stateless가 중요한 이유는 서버 확장이 가능해지기 때문입니다. Stateful일 때는 상태정보를 다른 서버와 정보를 교환해야 합니다. 하지만 이것이 대규모 트래픽인 경우 서버 효율이 급격하게 떨어지게 됩니다. Stateless방식은 이전에 자신이 보낸 요청까지 기억을 해두었다가 다음 요청에 필요 시 이전 요청과 함께 전송하는 방식이기 때문에 다른 서버와의 정보 교환이 필요없어집니다. 대규모 트래픽 요청이 와도 서버 개수만 늘리면 쉽게 해결됩니다.
하지만 Stateless는 클라이언트가 요청 데이터를 보낼 때 필요한 모든 정보를 넣어서 보내도록 요구하기 때문에 Stateful 방식보다는 요청 데이터의 오버헤드는 큽니다.
또한 로그인과 같이 상태 유지가 필요한 경우에는 쿠키와 세션을 이용하여 상태를 유지합니다. - Connectionless 형식
앞서 하나의 요청에 대해 하나의 TCP 연결이 설정된다고 했었는데, HTTP는 요청에 대해 응답을 받으면 연결이 끊어집니다.
이것의 장점은 자원 사용량을 최소화 할 수 있다는 점입니다. 한번에 요청하는 양 자체는 적기 때문에 서버의 자원을 적게 사용하고, 과부하가 적어지기 때문에 빠른 속도로 응답이 가능해집니다.
하지만 단점은 요청마다 연결 설정을 해야하기 때문에 시간이 더 오래걸리고, 관련있는 요청에 대해서도 하나하나 연결 설정을 다시해야 한다는 점입니다.(HTML 요청 시 CSS, JS파일까지 필요해서 다시 요청하는 경우)
앞서 언급했던 1.1 버전의 Keep-Alive 헤더가 이후 버전에서 Persistent Connection 기능으로 바뀌면서 특정 기간동안의 연결을 유지하는 방향으로 해당 문제를 해결했습니다.
메세지 구조
start line
HTTP Headers
(empty line)
body기본적인 HTTP 메세지의 구조입니다. 요청 메세지인지 응답 메세지인지에 따라 형식적인 차이는 있지만 구조는 동일합니다.
HTTP REQUEST
-
start line
HTTP Method + Request Target + HTTP Version형태로 이루어져 있습니다.- HTTP Method 부분에서 메세지가 GET, POST, HEAD, OPTIONS등 어떤 메소드인지 알려줍니다.
- Request Target 부분에서는 요청한 대상이 명시됩니다. 이는 URL 주소일수도, 포트번호, 프로토콜일수도 있습니다.
- HTTP Version은 HTTP 프로토콜 버전을 표시해주는데, 대부분의 경우 1.1, 2, 3 내에서 작성됩니다.
-
HTTP headers
헤더의 종류로 General Headers, Request Headers, Representation Headers로 나눌 수 있는데, 자세한 설명은 생략하도록 하겠습니다. -
Body
Body 부분은 모든 요청에서 필요한 부분은 아닙니다. 예를들어 자원을 요청하는 GET 메소드 같은 경우는 Body가 필요가 없습니다. 따라서 요청 헤더에서는 Body가 비어있는 경우가 많습니다.
HTTP RESPONSE
- status line
응답에서 start line은 status line이라고 부릅니다.Protocol Version + Status Code + Status Text형태로 이루어져 있습니다.- status code는 흔히아는 404 - error, 200 - success와 같은 요청에 대한 응답의 상태를 알려줍니다. 에러가 발생하였는지, 성공적으로 요청에 대한 수행을 완료하였는지 알 수 있습니다.
- status text는 상태에 대한 간략한 설명을 해준 것으로, 가끔 보이는
404 Page Not Found에서 "Page Not Found"가 해당됩니다.
- HTTP headers와 Body는 요청 메세지와 동일합니다.
HTTP 메세지에 대한 자세한 분석은 다음 글에서 다루도록 하겠습니다.
참고자료
https://velog.io/@hoo00nn/HTTP1.1-vs-HTTP2.0#:~:text=HTTP%2F1.1%20%ED%8A%B9%EC%A7%95,-Persitent%20Connections%20%2D%20HTTP&text=Pipelining%20%2D%20%EA%B8%B0%EB%B3%B8%EC%A0%81%EC%9C%BC%EB%A1%9C%20HTTP%20%EC%9A%94%EC%B2%AD,Pipelining%20%EC%8A%A4%ED%8E%99%EC%9D%B4%20%EC%B6%94%EA%B0%80%EB%90%98%EC%97%88%EB%8B%A4.
https://haerang94.tistory.com/207
https://kotlinworld.com/97
https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages
