<네트워크> http 버전 별 특징 (3.0)

 

 

1. HTTP/3

 - HTTP/3 은 UDP 기반의 프로토콜인 QUIC을 사용하여 통신하는 프로토콜이다. 아직 HTTP/2 도 점유율이 50%가 되지 않는데 놀랍다. 아직 표준은 아니지만 구글은 이미 실험적으로 사용하고 있다.

 

 - UDP를 모른다면 TCP와의 비교에 대해 먼저 알아보는 것을 추천한다. 어쨌든 UDP를 조금이라도 안다면 이런 생각이 들 것이다. TCP보다 당연히 빠르지만 신뢰성도 떨어지고 전송 순서도 보장되지 않는 프로토콜 아닌가? 이는 반은 맞고 반은 틀렸다. TCP는 신뢰성있는 통신을 위해 몇 가지 방법을 사용하였다. 이들 또한 클라이언트와 서버와의 통신이므로 레이턴시가 발생하고, 이는 TCP라는 프로토콜이 생길 때부터 정의된 표준이므로 무시할 수가 없다. 

2. TCP의 문제점

 - 위에서 언급했듯 HTTP/3 버전에서 UDP를 사용한이유는 TCP표준을 따른채로 속도를 빠르게 하기엔 한계가 있다.

 

 - 먼저 3 way handshake 이다. 알다시피 TCP연결 생성은 총 3회의 통신을 하여 이루어진다. TLS까지 추가되며 더 많은 핸드쉐이크를 진행해야한다. 이를 통해 신뢰성을 확보하지만 통신마다 번거로운 과정을 거쳐야했다. HTTP/1 버전에서는 매 요청마다 핸드쉐이크를 했지만 HTTP/2 에서는 여러개의 스트림을 사용하면서 단일 TCP연결을 유지하여 개선했다. 어쨌든 기존의 핸드쉐이크 과정은 반드시 필요했다. 그러나 HTTP/3에서는 기존의 핸드쉐이크 자체를 제거하고 새로운 핸드쉐이크 방법으로 신뢰성을 확보한채 레이턴시를 줄이고자 하였다.

 - 다음은 HOLB(Head of line Blocking)문제이다. TCP 통신에서 패킷은 반드시 순서대로 처리되어야 한다. 수신측과 송신측은 시퀀스 번호를 참고하여 패킷을 재조립한다. 따라서 통신 중간에 패킷이 손실되면 다음 패킷을 처리할 수가 없다. 이렇게 패킷이 중간에 유실되거나 느리면 병목현상이 생기는 것을 HOLB라 한다.

 

3. QUIC

 - QUIC은 TCP가 가진 문제를 해결하기 위해 구글이 개발한 UDP기반의 프로토콜이다. UDP는 패킷 간의 순서도 없고, 연결 설정도 별도로 하지 않는다. 그러면 당연히 빠를 수 밖에없는데 신뢰성과 패킷의 무결성은 어떻게 지켜질까. 간단하다. UDP는 데이터 전송을 제외하고는 아무런 정의도 없기 때문에 커스터마이징 하면된다. 그래서 나온 것이 QUIC이다.

TCP 헤더

 - 위는 TCP의 헤더이다. 어마어마하게 많은 정보들이 담겨있다. 이를 통해 신뢰성과 무결성 등 다양한 기능을 개발자에게 제공해주지만 모든 기능이 필수라는 것이 단점이다. 마치 매우 무거운 라이브러리를 쓰는 것과 같다.

UDP 헤더

 - UDP헤더는 출발지와 도착지, 패킷길이, 체크섬 이 전부이다. 패킷은 무결성을 위해 존재하지만 TCP와 달리 옵션이다. 이제 이렇게 휑한 UDP에 필요한 기능을 얹어주기만 하면 TCP보다 가벼우면서 신뢰성과 무결성이 지켜지는 프로토콜이 완성된다. QUIC은 헤더에 별도 패킷 번호 공간을 두어 전송순서를 파악하도록 하였다.

 

 - HTTPS 의 경우 위와 같이 수 많은 요청에 따라 시간이 오래 걸린다. 하지만 QUIC은 3 way handshake 와 TLS1.3의 핸드셰이크를 결합하였다. 이를 통해 훨씬 빠른 데이터 전송이 가능해졌다.

 - QUIC은 패킷 손실 감지에 걸리는 시간을 단축시켰다. TCP는 송신 측이 수신측으로 패킷을 보내고 난 후 얼마나 기다려 줄것인가를 동적으로 계산하면서 문제가 생겼다. 송신측으로 ACK를 받을 때 어느 패킷에 대한 것인지 타임스탬프도 찍어야하며 패킷검사도 해야했다. 하지만 QUIC은 헤더에 별도 패킷 번호 공간이 있어서 매 전송마다 패킷 번호를 증가시켜 패킷의 전송 순서를 명확하게 파악한다. TCP가 타임스탬프 또는 시퀀스 번호에 기반하여 암묵적으로 전송순서를 추론했다면 QUIC은 고유한 패킷번호를 통해 패킷 손실 감지에 걸리는 시간을 단축하였다. 이 외에도 여러가지 방법을 통해 패킷 손실 감지에 걸리는 시간을 줄였으니 자세한 내용은 QUIC Loss Detection and Congestion Control 의 3.1 을 읽어보자.

 

 - QUIC또한 HTTP/2 와 같이 멀티플렉싱을 지원하기 때문에 여러 개의 스트림을 처리할 수 있다. 따라서 불필요한 핸드쉐이크 과정을 줄일 수 있따. 뿐만 아니라 QUIC은 클라이언트의 IP가 바뀌어도 연결이 유지된다. 카페에서 인터넷을 사용하다가 와이파이 또는 데이터로 전환하면 새로 연결이 되는 경험이 있을 것이다. 그러나 QUIC은 Connection ID 를 사용하여 서버와 연결한다. IP와는 전혀 무관하기 때문에 새로 연결을 생성할 때 필요한 핸드쉐이크 과정을 생략할 수 있는 것이다.

 

 

 

---

참고

 

HTTP/3: the past, the present, and the future

 

HTTP/3는 왜 UDP를 선택한 것일까?

 

Usage Statistics of HTTP/2 for Websites, December 2021