HTTP/3.0은 왜 TCP가 아니라 UDP일까?

TCP는 구조상 한계로 개선을 해도 느리다.

특히 모바일 시대에선, 이용자가 움직이면서 네트워크 환경이 바뀌면서 TCP 연결을 새로해야한다는 문제가 발생하고 있다. 와이파이를 바꾸면 새로운 커넥션을 맺어야 하니 끊김 현상이 잦아질 수밖에 없다.

또한, TCP 통신에선 패킷이 무조건 순서대로 처리돼야 하고, 메시지 손실 시 재전송을 해야 한다.

UDP는 신뢰할 수 없지 않아?

UDP 자체는 신뢰성이 없는 게 아니다. 단지 신뢰성을 보장하는 기능을 탑재하지 않았을 뿐이다.
UDP의 진짜 장점은 커스터마징이 가능하다는 것이다. 실제로 TCP처럼 신뢰성을 갖추도록 개조하는 것도 가능하다.

왜 새로운 프로토콜을 만들진 않은거야?

QUIC라는 프로토콜도 만들어진 후, 아직 채택한 곳이 많지 않다고 들었다. 인프라는 결국 레거시환경이라는 것이 있고, 새로운 프로토콜을 만들더라도 기존 인프라에선 작동하지 않을 수 있다.

HTTP/3.0은 뭐가 대단한데?

연결 레이턴시 감소

기존 TLS+TCP에선 TLS연결을 위한 핸드쉐이크와 TCP를 위한 핸드쉐이크가 각각 발생했다.

TCP를 위한 1RTT, TLS를 위한 암호화까지 하면 총 3RTT가 필요했다.(RTT(Round Trip Time)란, 요청(SYN)을 보낼 때부터 요청에 대한 응답(SYN+ACK)을 받을 때까지의 왕복 시간을 의미한다.)

QUCI는 이를 한단계로 줄였다.
UDP위에서 동작하는 QUCI는 통신 시작 시 3way handshake를 거치지 않아도 돼서, 연결 설저엥 1RTT만 소요된다. 그 이유는 연결 설정에 필요한 정보와 함께 데이터도 보내기 때문이다.

QUIC내에 TLS 인증서도 포함하고 있어서, 최초 연결 섲렁에서 필요한 인증 정보와 데이터를 함께 전송한다.

기존 방식은 각자 자신의 세션 키를 주고서 암호화된 연결을 성립하고, 세션키와 함께 데이터를 교환한다.

QUIC는 세션키를 교환하기도 전에 데이터도 함께 교환한다. 다만, 최초의 연결 요청을 봰ㄹ 때는 클라이언트는 서버의 세션 키를 모르기 때문에, 목적지인 서버의 Connection id를 사용해서 생성한 특별한 키인 초기화 키로 통신을 암호화한다.

그리고, 한번 연결을 성공하면 서버는 그 설정을 캐싱해놓고 있다가 바로 사용한다.

HOLB를 해결

HTTP/2에서도 TCP는 수십/수백개의 스트림 데이터를 병렬 전송한다. 그러나, 패킷 하나가 빠지거나 없어지면, 없어진 패킷을 다시 전송하고 목적지를 찾을 동안 전체 TCP연결이 중단된다.

HTTP/2스트림에선 여러 프레임이 뒤섞여 이동하는데, 만약 어느 하나의 프레임에 문제가 생기면 그 뒤 프레임까지 영향이 가게 된다.

거기다가 HTTP/2는 1개의 TCP 커넥션으로 전부를 처리하고 있기 때문에 패킷 손실률이 증가하면 여러 개의 TCP를 사용하는 HTTP/1.1보다 성능 저하가 커질 수 있다.

QUCI는 독립 스트림을 통해서 HOLB를 단축한다. 스트림 자체를 독립적으로 여러개노 나누어서 처리한다. 두가지 다른 스트림을 섲렁하면, 독립적이므로 특정 스트림에서 HOLB가 발생해도 다른 스트림은 영향을 받지 않는다.

패킷 손실 감지에 걸리는 시간 단축

QUIC도 TCP와 마찬가지로 전송 패킷에 대해 흐름 제어를 한다.

HTTP 2.0에서는 아래 그림과 같이 하나의 스트림에 A, B, C 패킷 프레임들이 비순서대로 전달될때, 만일 세번째 프레임에서 패킷 손실이 일어나면, 패킷 B만 중지되어야 하지만 위에서 배운바와 같이 전혀 연관없는 패킷 A와 C도 모두 막혀 대기를 해야된다.

QUIC는 헤더에 패킷의 전송 순서를 나타내는 별도의 패킷 번호 공간을 부여했다.
이를 이용해 QUIC는 패킷 번호를 파악해 개별 파일을 구분하여 중간에 패킷 로스가 발생해도 해당 파일의 스트림만 정지가 되도록 할 수 있다.

네트워크가 변경되도 연결이 유지

TCP의 경우 클라이언트와 서버가 서로를 구분하기 위해서는 클라이언트 IP, 클라이언트 PORT, 서버 IP, 서버 PORT, 이렇게 네 가지가 필요하다. 그래서 클라이언트의 IP가 바뀌는 상황이 발생하면 연결이 끊어져 버린다.

핸드폰을 들고 와이파이존에서 LTE 데이터를 사용하게 됐을 때, 동영상 끊김과 같이 일시적 지연이 일어나는 이유는 클라이언트 IP가 이때 바뀌기 때문이다.

QUIC는 Connection ID를 사용해서 서버와 연결을 생성한다.
Connection id는 각 연결은 연결 식별자나 연결 id를 가지므로 이를 통해 연결을 식별한다.
클라이언트의 IP와는 전혀 무관한 데이터이기 때문에 클라이언트의 IP가 변경되더라도 기존의 연결을 계속 유지할 수 있다.

Connection ID만 사용한다면 해커가 네트워크를 통해 사용자를 추적하여 보안 문제가 일어날 수도 있을 것이다. 그래서 QUIC는 새 네트워크가 사용될 때마다 Connection ID를 변경한다.

클라이언트와 서버가 모두 연결을 위해 무작위로 생성한 Connection ID에 대해 인지하고 있고, 네트워크가 바뀔때 Connection ID를 바꾸더라도 이게 이전 Connectin ID와 동일하다고 인지하여 연결을 유지하는 것이다.

우려되는 점은 없어?

1) 기존 체계 호환성 문제 + 성능 다운그레이드 우려

2) 암호화로 네트워크 제어가 힘들다.
QUIC는 기존에는 암호화하지 않던 헤더 필드도 암호화한다. 
그래서 이런 헤더의 정보를 사용하는 ISP나 네트워크 중계회사들은 기존에 암호화하지 않던 헤더 필드 영역들을 읽을 수 없어 네트워크 혼잡을 관리하기 위한 네트워크를 최적화하기 힘들다.

3) 암호화로 리소스가 많이 든다 ->패킷별로 암호화를 한다. TLS-TCP에서 패킷을 묶어서 암호화하는 것보다 더 큰 리소스 소모를 불러올 수 있다는 단점이 있다.

4) QUIC는 CPU를 너무 많이 사용해서, 스마트폰이나 ioT장치에서 사용하기 ㅎ미들다.