QUIC 개요
오늘날 까지 HTTP 프로토콜을 지속적으로 문제를 개선하며 발전시켜 왔으나, TCP 의 본질적인 문제나 TLS/SSL 등의 한계를 개선하지 못하였고, 이를 위해 UDP를 기반으로 하는 신뢰성 프로토콜을 만들자는 취지에서 설계된 구글의 네트워크 프로토콜이다.
기존 TCP의 문제
HTTP/2 를 통해 한번의 TCP 연결에서 여러 패킷을 병렬적으로 전달하는 것이 가능해졌지만, TCP 요청 자체를 병렬적으로 처리하는 것은 불가능했다. 예를 들어 여러 요청을 전달하는 데 있어 사전의 요청이 어떠한 이유로 전송되지 못한 경우, 서버는 재요청을 보내게 되고, 사전 요청이 먼저 서버에 보내지기 전까지 후위 요청은 대기하고 있어야 한다. 이는 TCP 의 데이터 요청간 순서를 보장하기 위함이기 때문에 나타나는 대표적인 병목 현상이다.
이를 TCP HOL Blocking 문제라고 한다.
또한 TLS/SSL 인증이 필요한 경우, 대칭키 생성 및 교환하는 작업을 위해 다시금 핸드셰이크 과정을 거치게 되는데, 이는 멀티플렉싱과 같이 한번의 연결로 처리하는 것이 불가능할 뿐만 아니라, TCP 연결 이후 다시 이루어지는 연결과정이며, TCP 연결도 더 오래걸리는 문제가 있다.
QUIC 의 순서 보장
UDP 기반의 QUIC 가 데이터 순서를 보장하는 방법은 스트림의 우선순위이다. QUIC는 독립된 스트림에 대해 0 부터 256 까지의 8비트 우선순위 값을 지정할 수 있다. 만약 먼저 전송해야 하는 데이터에 대해서는 우선순위를 높게 설정하여 먼저 전송되도록 할 수 있다. 예를들어, 용량이 큰 데이터는 우선순위를 낮게 설정하여 나중에 전송하도록 하거나, 용량이 작은 데이터는 우선순위를 높게 설정하여 먼저 전송되도록 한다. 또한 빠른 렌더링이 필요한 이미지의 경우, 텍스트 파일 보다 더 높은 우선순위를 부여하여 전송하도록 할 수 있다.
더불어 QUIC 역시 패킷마다 일련번호가 부여되며, 수신자는 데이터 조각의 순서를 파악하고 데이터를 올바른 순서로 형성하는 것이 가능하다.
QUIC 의 신뢰성 보장
TCP 의 Fast Retransmit 및 Selective Acknowledgement 와 유사한 방식을 사용한다. 단 패킷 손실 시 재전송하는 과정도 스트림마다 독립적으로 이루어지기 때문에, 다른 요청의 딜레이 없이, 해당 스트림만 재전송하므로, TCP 대비 더욱 빠른 재전송이 가능하다. 이외에도, 기존 패킷 손실을 감지하기 위한 TLD 보다 더욱 빠르게 감지하는 RTO 를 통해 손실을 감지하도록 설계했다고 한다.
RTO, TLD
기존TCP는 Retransmission Timeout (RTO) 이라는 기능을 통해 패킷 손실을 감지하고 재전송한다.RTO는 일정 시간 동안 수신 측으로부터ACK를 받지 못하는 경우, 해당 패킷을 재전송하는 방식이다.
반면에 QUIC에서는 Time Loss Detection (TLD) 기능을 사용한다. 일정 시간 동안 수신 측으로부터 ACK 신호를 받지 못한 경우, 해당 패킷을 재전송하는 것을 기다리는 것이 아닌, 다른 패킷을 우선적으로 전송함으로써 패킷 손실을 회피한다.
RTO 와 TLD 의 가장 큰 차이는 속도이다. 재전송에서도 에러가 나는 경우를 포함한다면, RTO는 수백밀리초 이상의 시간이 소요되는 반면, TLD는 일반적으로 수십밀리초 이하의 시간이 소요된다.
QUIC 의 멀티플렉싱
QUIC 역시 한번의 연결에서 여러 데이터 스트림을 전송하는 것이 가능하다. 단 TCP와 달리 모든 스트림을 한 번에 전송하는 것이 아닌, 각각의 독립적인 스트림으로 분할하여 전송한다. 이를 통해 사전 요청에서 지연이 발생하더라도, 후위의 요청이 지연되는 문제가 없어지게 된다.
QUIC 0-RTT (zero round trip time)
클라이언트가 이전에 연결한 적이 있는 서버에 다시 연결할 때, 인증과정을 생략하고 바로 데이터를 전송하는 것이 가능하며, 기존 TCP와 다르게 클라이언트-서버 연결과 TLS/SSL 을 따로따로 처리하는 것이 아닌 한번에 처리하는 것이 가능해졌다.
0-RTT의 경우 ticket 이라는 데이터를 사용한다. 기존 로그인 시 사용하는 Token의 개념과 유사하며, 클라이언트와 서버가 서로 교환한 대칭키를 포함하여, 보안 알고리즘과 유효기간이 포함된 티켓을 생성하여 지니게 된다. 만약 일정기한내 동일한 서버에 요청을 보내는 경우, ticket을 대신 확인함으로써 인증과정을 생략하는 것이 가능하다.
만약 티켓이 유효하지 않는 경우는 다시 TLS/SSL 인증을 수행하고 새로운 대칭키를 생성한 다음 다시 새로운 티켓을 발급한다.
QUIC 0-RTT, 1-RTT, 2-RTT
연결 설정에 필요한 왕복시간을 의미한다.
0-RTT는 클라이언트가 이전에 연결한 적이 있는 서버에 재접속할 때 사용된다. 이 경우, 클라이언트는 저장된 티켓을 사용하여 서버에 데이터를 전송한다.
1-RTT는 QUIC의 기본 연결 설정 방식이다. 클라이언트와 서버 간에 1회의 왕복시간이 소요된다. 서버에 연결 요청을 보내고 서버가 이를 받아들이고 응답을 보내는 과정이 이루어진다.
2-RTT는 기존 TCP와 유사한 방식으로 연결설정을 수행한다. 클라이언트와 서버 간에 2회의 왕복시간이 소요된다. 클러이언트가 연결 요청을 보내고, 서버가 이를 받아들인 후, 클라이언트에게 응답을 보내는 과정이 이루어진다.
2-RTT의 경우 추가적인 보안 검증이 필요한 상황에서 사용된다. 대표적으로 0-RTT의 티켓 값이 유효하지 않는 경우가 있다. 또한 0-RTT 의 경우 보안상의 이유로 일부 프로토콜에서 사용이 제한되는 경우가 사용하는데, 이러한 경우 1-RTT 나 2-RTT를 사용한다.
일반적으로 3-way handshake 한번에 1-RTT 정도의 연결이 든다. 다만 QUIC은 암호화의 병렬 전송을 통해 연결 설정을 높이고, TCP 에 비해 여러번 연결설정이 이루어지지 않기 때문에, 대부분의 네트워크 환경에서 QUIC가 TCP보다 더욱 빠른 성능을 제공하는 것은 사실이다.
QUIC 의 단점
대표적으로 호환성 문제가 있다. QUIC는 새로운 프로토콜이기에, 기존의 네트워크 인프라와의 호환성 문제가 발생할 수 있다. 특히 기존의 방화벽, 로드 밸런서, 프록시 서버 등의 네트워크 장비들이 QUIC 트래픽을 인식하고 처리하기 어려울 수 있다. 또한 기존 TCP 대비 문제 사례나 커뮤니티가 적어, 인프라 환경을 유지 보수하는 데 있어 복잡성이 증가할 수 있다.
또한 ticket의 사용이 문제가 될 수 있다. TLS/SSL 보다 빠른 연결 설정을 제공하나, ticket에 의한 보안 및 개인정보 문제가 발생할 수 있다. 이를 위한 ticket 자체에 추가적인 보안 설정을 하는 경우도 많다.
