HTTP 1.0
하나의 연결 당 하나의 요청을 처리한다.
연결을 맺고 끊음을 반복함으로써 속도가 매우 느리다.
HTTP 1.1
한 번 연결하고, 다수의 요청들을 처리한 다음에 연결을 끊는다.
이 때, keep-alive 옵션을 사용해서 일정 시간동안 연결 상태를 유지한다.
TCP 특성 상, 요청 후 응답이 올 때 까지 기다려야하는 문제를 보완하기 위해 파이프라이닝 기법을 도입했다.
따라서, 클라이언트는 앞에 보낸 요청의 응답이 올 때까지 기다리지 않고, 순차적으로 여러 개의 요청을 전송할 수 있다.
서버는 요청이 들어온 순서대로 응답을 해준다.
하지만 2가지 문제점 존제이 존재한다.
1. 파이프라이닝 도입으로 HOL Blocking이 발생하는 문제가 발생한다.
HOL Blocking : 앞의 요청에 대한 응답이 늦어지면 뒤에 빠르게 처리할 수 있는 요청이 오더라도 모두 blocking 되어 응답이 지연되는 문제이다.
2. 연속되는 요청의 헤더에 많은 중복이 있다는 것이다.
HTTP 2.0
- 바이너리 프레이밍
1.1에서는 텍스트로 정보를 주고받았지만, 2.0에서는 바이너리로 인코딩해서 정보를 주고받기 때문에 처리 속도가 빨라진다.
- Stream과 Frame
1.1에서는 HTTP 요청과 응답은 message 단위로 구성되어 있었다.(다수의 frame으로 이루어진 요청/응답)
2.0로 넘어가면서 stream과 frame이라는 단위가 추가되었다.
stream은 하나의 연결 내에서 양방향으로 message를 주고 받는 하나의 흐름을 의미하고,
frame은 http/2.0에서 통신의 최소 단위이다.
-> 즉 frame들이 모여서 하나의 message가 되고
message는 특정 stream에 속하게 되고
여러 개의 stream이 하나의 연결이 되는 것이다.
- 멀티플렉싱
이렇게 데이터를 frame 단위로 쪼갰기 때문에 요청과 응답의 순서가 상관이 없어졌다.
하나의 message는 stream으로 구분이 가능하고,
frame이 stream을 통해 전달되며, 하나의 연결 안에 여러 개의 스트림을 가지기 때문에 멀티플렉싱이 가능해진다.
먼저 도착한 응답을 먼저 처리할 수 있기 때문에 HOL Blocking 문제를 해결할 수 있게 되었다.
- compression header
중복된 헤더는 인덱스 값만 전송하고, 중복되지 않은 헤더의 정보는 허프만 인코딩 기법을 사용하여 전송한다.
이를 통해 중복 헤더의 문제를 해결했다.
- Server push
클라이언트의 요청이 없을 때에도, 서버에서 리소스를 보내 줄 수 있다.
하지만 여전히 TCP 위에서 동작하기 때문에, TCP HOL Blocking 문제가 해결되지 못했다.
TCP는 패킷이 손실되면 재전송하기 때문에, 결국 재전송 과정에서 패킷 지연이 발생한다.
이 문제를 TCP 자체의 문제로 파악하고, 구글에서는 새로운 전송계층 프로토콜을 만들어버렸다.
그게 QUIC이고 HTTP/3.0으로 불린다.
QUIC(HTTP/3.0)
HTTP/2.0까지는 TCP 위에서 동작했지만 QUIC는 UDP 위에서 동작하는 전송계층 프로토콜이다.
UDP 위에 QUIC 위에 HTTP가 올려진 형태이다.
- TCP HOL Blocking
요청별로 다른 스트림을 사용하므로써 HOL Blocking 해결한다.
특정 패킷이 손실되더라도, 해당 패킷이 속한 스트림에서만 지연이 일어나고 다른 스트림에는 영향을 주지 않는다.
- TLS 연결
HTTPS를 사용하면 추가로 TLS 연결과정이 필요한데
HTTPS를 쓴다고 가정하고 첫 연결에 TLS 연결까지 끝냄으로 지연을 줄인다.
- Connection ID
클라이언트에게 connection id를 부여한다.
기존 TCP는 ip와 port 번호로 클라이언트를 구분했는데 connection id로 구분하기 때문에
클라이언트의 ip가 변경되더라도 연결이 끊기지 않게 된다.
현재 구글, 유튜브, 페이스북에서는 QUIC 프로토콜을 지원하고 있다.