UDP 위에 신뢰성·암호화·혼잡 제어를 새로 구현한 전송 프로토콜. HTTP/3의 기반이다. 구글이 만들어 IETF 표준(RFC 9000)이 됐다.
왜 TCP를 안 쓰고 UDP 위에 새로 만들었나
① TCP의 순서 보장이 HOL Blocking을 만든다 스트림 개념이 없어 손실 하나가 무관한 데이터까지 막는다.
② TCP는 개선을 배포할 수 없다 TCP는 커널과 네트워크 장비에 박혀 있다. 새 기능을 만들어도 전 세계 OS와 미들박스가 업데이트돼야 쓸 수 있어 수십 년이 걸린다.
UDP는 "포트 + 체크섬"만 하는 최소 프로토콜이라, 그 위에 사용자 공간(애플리케이션) 에서 원하는 대로 구현할 수 있다. 브라우저·서버만 업데이트하면 즉시 배포된다.
무엇을 얻었나
| 얻은 것 | 어떻게 |
|---|---|
| 스트림 독립 | QUIC이 스트림을 인식 → 한 스트림 손실이 다른 스트림을 안 막음 |
| 연결 수립 단축 | 전송 + 암호 핸드셰이크를 합쳐서 1-RTT, 재연결 0-RTT |
| 연결 마이그레이션 | Connection ID로 식별 → IP가 바뀌어도 연결 유지 |
| 암호화 기본 탑재 | TLS 1.3이 프로토콜에 통합. 헤더 대부분도 암호화 |
연결 마이그레이션이 왜 대단한가
TCP 연결은 4-튜플(출발IP·포트·목적IP·포트)로 식별된다. Wi-Fi에서 LTE로 바뀌면 IP가 바뀌므로 연결이 끊긴다.
QUIC은 Connection ID라는 별도 식별자를 쓴다. IP가 바뀌어도 같은 ID면 같은 연결이다. 걸어가며 영상을 봐도 끊기지 않는 이유다.
핸드셰이크 비교
TCP + TLS 1.2 : 3-way(1 RTT) + TLS(2 RTT) = 3 RTT
TCP + TLS 1.3 : 3-way(1 RTT) + TLS(1 RTT) = 2 RTT
QUIC : 합쳐서 = 1 RTT
QUIC 재연결 : = 0 RTT
지연이 100ms인 회선에서 3 RTT와 1 RTT는 200ms 차이다. 모바일에서 체감이 크다.
대가와 주의
- UDP를 차단·제한하는 네트워크가 있다(일부 기업 방화벽). 그래서 실제 서비스는 HTTP/3 실패 시 HTTP/2로 되돌아가는 경로를 함께 둔다.
- 커널이 아닌 사용자 공간에서 처리해 CPU 사용량이 더 높다. 대규모 서버에서는 이게 비용이 된다.
- 미들박스가 내용을 못 봐서 네트워크 장비의 최적화·진단이 어려워진다.