Calculadora de QUIC Handshake RTT vs TCP

Handshake QUIC RTT vs. TCP+TLS

O QUIC roda sobre UDP e embute o TLS 1.3 já no estabelecimento da conexão. O handshake fecha em um único round-trip. Uma conexão nova custa QUIC_setup = 1 × RTT; se o cliente retoma uma sessão a partir de parâmetros em cache, cai para 0 × RTT. A pilha clássica é mais lenta. Nela você paga TCP_setup + TLS_setup = 3 × RTT, porque espera o 3-way handshake TCP e depois o ClientHello/ServerHello TLS mais o Finished.

Vendo em números: num enlace com RTT de 80 ms, o QUIC inicia a conexão em 80 ms, o caminho clássico TCP+TLS 1.3 leva 240 ms e uma sessão QUIC retomada começa em 0 ms. O Google prototipou o QUIC lá em 2012 para acelerar a conversa do Chrome com seus próprios serviços, e mais tarde a IETF o padronizou como RFC 9000, em 2021. Outra coisa que ele resolve é o head-of-line blocking na camada de transporte: cada stream se recupera da perda por conta própria, e é justamente essa independência que faz o HTTP/3 rodar só sobre QUIC.

Aplicações

Você encontra o QUIC por trás do HTTP/3 na Cloudflare, no Google, na Meta e no YouTube, e também sob serviços Google como Gmail, Search e Maps. CDNs modernos se apoiam nele. Apps móveis se importam porque uma conexão pode migrar entre Wi-Fi e celular sem cair. E em qualquer carga sensível a latência, cortar esses 2 RTTs aparece como ganho real de page load, normalmente algo entre 5-15% em sites reais.

FAQ

Por que o QUIC usa UDP em vez de um novo transporte? Middleboxes como firewalls e NATs costumam deixar passar só TCP e UDP. Por ficar em cima do UDP, o QUIC pôde ser implantado na hora, em vez de esperar anos até kernels de SO e roteadores aprenderem um protocolo totalmente novo.

0-RTT é seguro? Um atacante pode reenviar dados 0-RTT, então use isso apenas para requests idempotentes, como GETs. O servidor ou rejeita 0-RTT não idempotente de cara ou assume conscientemente o risco de replay.

QUIC resolve head-of-line blocking? Na camada de transporte, sim. Perca um pacote no stream A e os streams B, C e D seguem fluindo. O HTTP/2 sobre TCP não conseguia isso, porque o TCP entrega os bytes em ordem, não importa de qual stream eles são.