QUIC가 등장하게 된 이유
TCP + TLS에서 동작하는 프로토콜 상의 문제점
- HOL(head-of-line): HTTP/2에서 TCP연결을 통해 패킷 전송이 일어날때, 한 패킷에 문제가 생기면 다른 패킷 전송이 영향이 간다.
- QUIC에서는 독립 스트림을 여러개 만들어 이 문제를 피하고자함
TCP or UDP
TCP를 통해서 head-of-line 블로킹을 해결할 수 없다면 이론적으로 새로운 stack을 만들면 되지 않을까? 새로운 프로토콜을 만들었을 때 NAT, 방화벽, 라우터 등등 에 이를 적용해야하는데 현실적인 어려움이 많다. 또한 이들 프로토콜을 운영체제 커널에서 구현해야 할텐데 어느 세월에 배포할수 있을까..
SCTP-over-UDP??
SCTP를 사용하면 되는거 아닌가? WebRTC는 이미 UDP에 이걸 올려서 쓰고 있다 다음과 같은 문제가 존재
- SCTP는 스트림에 대해 head-of-line 블로킹 문제를 고치지 못한다
- SCTP는 연결을 설정할 때 스트림의 수를 결정해야한다
- SCTP에는 견고한 TLS/보안에 대한 언급이 없다.
- SCTP는 4단계 핸드쉐이크(4-way handshake)를 사용하고 QUIC는 0-RTT를 제공한다
- QUIC는 TCP같은 bytestream이고 SCTP는 메시지 기반이다
- QUIC 연결은 IP 주소사이에서 마이그레이션을 할 수 있지만 SCTP는 할 수 없다 (QUIC은 connectionID라는 것을 사용)
QUIC 개발 과정
Google의 Jim Roskind가 초기 QUIC 프로토콜을 설계하고 2012년 처음 구현했으며 2013년에 발표 당시에는 Quick UDP Internet Connectios의 약자였으나 현재는 없음
Chrome에 적용됨
초기에 만들어진 Google-QUIC는 HTTP 프로토콜은 전송하는 목적으로만 사용되었고 TLS의 암호화와 보안을 사용하지 않고 커스텀하게 이용
이후 IETF에서는 HTTP이외의 프로토콜도 사용할 수 있도록 QUIC 계층과 HTTP over QUIC(a.k.a hq) 계층으로 분리 => IETF-QUIC
Google에서도 IETF버전의 세부 내용을 받아들여 IETF 버전에 만들어지 방향으로 Google-QUIC을 개발하였고, 자사의 브라우저와 서비스에 QUIC의 Google버전을 계속해서 사용중
현 상황
아직 널리 배포되어 있지는 않은 상태이며 Apache나 nginx에서 공개적으로 QUIC을 지원한다는 발표는 없다. 비공식적으로 QUICHE를 사용하면 지원 가능
browser의 경우에는 파이어폭스와 크롬의 경우 HTTP/3를 지원하고는 있지만, 따로 설정에서 활성화가 필요하다. macOS BigSur의 safari 14는 HTTP/3가 기본으로 활성화되어 있다.
QUIC로 대규모 배포시 HTTP/2 대비 같은 트래픽 기준 2배의 CPU 연산이 필요 (feat. Google, Facebook) 해당 이유로는 Linux의 UDP가 TCP 만큼 최적화되어 있지 않고, 하드웨어도 TCP와 TLS에 대해서는 최적화가 많이 되어 있지만 UDP에 대해서 그렇게 하는 경우는 드물고 기본적으로 QUIC에 대해서는 아예 신경쓰지도 않는다. 때문에 시간이 지나면 성능 개선이 이루어질 것으로 예상됨
적용 시 문제점 : 53번 포트가 아닌 포트의 UDP 트래픽을 차단하는 경우가 있기도하고, 허용하더라도 제한하는 부분이 많기 때문에 QUIC이 TCP에 기반을 둔 프로토콜 보다 성능상으로 떨어질 수 있다. 하지만 관련 설정만 해준다면 문제 없이 동작한다. 추후에는 default 설정으로 QUIC을 지원할 것이라 기대된다
