이 글은 보초님 깃허브 레포를 참고해서 공부한 글입니다
HTTP/1.1(표준 프로토콜)
- HTTP 헤더 + 바디로 구성되어 있다.
- 헤더에는 URI, Request Method, 여러 헤더 정보가 포함되어있다.
- 사람이 읽을 수 있는 문자열이 그대로 전송된다.
- TCP connection 을 이용한다.
- 3-way-handshake 를 사용하게 되어있다.
- connection 을 재사용한다.
- 통신에 사용된 connection 을 즉시 끊지 않고, 대기하였다가 추가 요청이 있을 경우 재활용한다.
- 파이프라이닝 추가
- 요청에 대한 응답이 끝나기 전에 다음 데이터를 미리 요청한다.
HTTP/1.1 에 문제들
- 바이너리가 아닌 텍스트로 데이터를 보내는 것
- TCP 를 쓰는 것
- 여전히 요청 데이터가 동기적으로 진행되는 것(1개 요청하고 대기, 도착하면 그 다음 데이터 요청)
- 헤더에 중복된 데이터가 있는 것
HTTP/2(성능 향상 버전)
HTTP/1.1 의 문제점을 개선하기 위해 2010년 초중반, 구글에서 SPDY 프로토콜을 기반으로 HTTP2.0 이 등장했다.
스트림, 메시지, 프레임
HTTP/2 에 대해 설명하기 전에 알아야 할 단어들이 몇 가지가 있다.
- 스트림
구성된 연결 내에서 전달되는 바이트의 양뱡향 흐름이며, 하나 이상의 메시지가 전달 가능하다.- 메시지
요청/응답에 해당하는 프레임의 전체 시퀀스- 프레임
HTTP/2 통신에서의 최소 단위이며, 각 프레임에는 하나의 프레임 헤더가 포함된다.
스트림은 하나 이상의 메시지를 전송하고, 메시지는 한 개 또는 여러 개의 프레임으로 구성될 수 있고, 각 프레임은 프레임 헤더를 가지고 있으며, 프레임 헤더를 이용하여 어느 스트림에 속하는 지를 알아낸다.
HTTP/2 특징
- 모든 통신을 단일 TCP 연결을 통해 이뤄질 수 있고, 스트림의 개수는 제한이 없다.
- 각 스트림은 고유 식별자와 우선수위 정보(선택사항) 이 있다.
- 프레임은 통신의 최소 단위이다. TCP가 데이터를 쪼개서 보낸 다음 헤더를 보고 재 조립 하는 것과 비슷하다.
HTTP/1.1 과 HTTP/2 의 차이점
HTTP Body 가 이진 데이터이다.
기존 HTTP 는 바디 가 문자열로 이루어져있지만 HTTP/2 부터는
binary framing layer라는 공간에 이진 데이터로 전송된다.
HTTP Request Method, 헤더 등은 여전히 문자열로 전송되지만 바디 부분이 변경되는 것이 가장 큰 변경점 중 하나다.
HTTP/2.0은 헤더와 바디 프레임으로 나뉘어 들어가는 것을 볼 수 있다.
멀티플렉싱
1.0 에서 1.1 으로 넘어오며 pipelining 기술을 도입하였지만, 여전히
HOL(Head-of-line) Blocking문제가 있다.
HOL Blocking은 패킷이 순서대로 도착해야 하므로, 패킷이 도착할 때까지, 그 이후의 패킷은 전송되지 못하는 것을 의미한다.
위의 스트림의 개념을 사용하자면, 1.1 버전에서는 1개의 TCP 연결 당 1개의 스트림만 이용 가능하다. 따라서 하나의 메시지가 응답될 때까지 다른 메시지를 요청하지 못한다. 그래서 여러 TCP 연결을 수립하여 여러 요청을 수행한다. 하지만 2.0 을 이용하면 스트림을 이용하여 다음과 같은 장점이 있다.
- 여러 요청/응답을 병렬로 처리 (하나의 TCP 연결에 여러 스트림 사용)
- TCP 연결이 1개이므로
3-way-handshake오버헤드가 없다. - 네트워크 가용성 증가로 속도 상승 및 이미지 스트라이트 등을 사용하지 않아도 된다.
스트림 우선순위 지정
1개의 TCP 에 여러 개의 스트림을 사용할 수 있게 되었으므로 각각의 스트림에 우선순위를 둘 수 있게 되었다. 이것을 이용하여 전송 순서를 임의로 고정시킬 수는 없으나, 중요한 데이터를 먼저 보낼 수 있도록 설정하는 것이 가능하다.
헤더 압축
1.0 에서는 헤더가 문자열로 전송된다. 적게는 500~800바이트 크게는 수 KB를 소모한다. 이러한 성능 이슈를 해결하기 위하여 2.0 에서는 HPACK 압축을 이용하여 헤더를 압축하여 보낸다.
Server push
클라이언트에게 필요한 데이터가 있을 때, 직접 요청하기 전에 서버가 미리 데이터를 전송하여 받아볼 수 있게 한다.
이를 통해 여러 TCP 연결을 1개로 합치고, HOL 문제도 해결했다.
하지만 TCP 프로토콜 자체의 한계 때문에 더 이상 성능 개선에도 한계가 오게 된다.
예를 들어 HTTP/2.0 에서 HOL Blocking 문제를 상당 부분 해결하였지만, TCP 프로토콜 자체에의 HOL Blocking 문제가 존재한다.
그러면 TCP 를 쓰지 않는다면 무엇을 쓸까? 같은 전송 계층에 있는 UDP 를 쓰게 될 것이다.
HTTP/3.0
HTTP/3.0 프로토콜의 가장 큰 특징은 TCP 가 아닌 UDP 를 사용한다는 것이다.
그전에 TCP, UDP 의 차이점을 간단하게 알아보자
| TCP | UDP | |
|---|---|---|
| 전송속도(상대적) | 느림 | 빠름 |
| 혼잡제어 | O | X |
| 헤더크기 | 20바이트 | 8바이트 |
정확히 말하면 HTTP/3.0 은 QUIC 이라는 프로토콜 위에서 돌아가는 HTTP 이다.
Quick UDP Internet Connection 의 약자로 UDP 를 사용하는 프로토콜이다.
TCP 는 3-way-handshake, 끝날 때 4-way-handshake 등 오버헤드와 HOL Blocking 등의 문제를 가진다.
QUIC 은 TCP handshake 과정을 최적화하는 것에 집중하여 설계되었다.
QUIC 의 장점
딜레이 감소
HTTPS over TCP + TLS 에서의 소요되는 레이턴시 : 1 RTT(TCP) + 2 RTT(TLS) = 3 RTT 이다.
HTTPS over QUIC 에서의 소요되는 레이턴시 : 1 RTT
멀티플렉싱 지원
멀티플렉싱을 지원하며, 이론 인하여 HOL Blocking 이 없다.
네트워크 스위칭 속도 개선
매 요청마다 클라이언트 - 서버의 IP 가 필요한 것이 아니고, QUIC 는 Unique connection ID 를 사용해서 모든 패킷이 잘 구별될 수 있도록 한다. 예를 들어 휴대폰으로 인터넷을 할 때, 중간에 와이파이에서 LTE 로 변경해도 스트림이 계속 유지가 된다. (TCP 의 경우에는 처음부터 다시 데이터를 받아와야 한다.)
