Calculadora de QUIC Handshake RTT vs TCP

Handshake QUIC RTT vs. TCP+TLS

O QUIC é um protocolo de transporte sobre UDP que integra o TLS 1.3 diretamente no estabelecimento da conexão. Seu handshake completa em um único round-trip: QUIC_setup = 1 × RTT para uma conexão nova e 0 × RTT quando usa session resumption com parâmetros em cache. Compare com a pilha clássica: TCP_setup + TLS_setup = 3 × RTT (3-way handshake TCP + ClientHello/ServerHello TLS + Finished).

Em um enlace com RTT de 80 ms, isso significa a diferença entre 80 ms para iniciar a conexão (QUIC) e 240 ms (TCP+TLS 1.3) — ou 0 ms para sessões QUIC retomadas. O QUIC foi prototipado pelo Google em 2012 (Chrome ↔ serviços Google) e padronizado pela IETF como RFC 9000 em 2021. Também elimina head-of-line blocking na camada de transporte ao dar a cada stream recuperação de perdas independente, razão pela qual o HTTP/3 roda exclusivamente sobre QUIC.

Aplicações

QUIC é usado pelo HTTP/3 (Cloudflare, Google, Meta, YouTube), serviços Google (Gmail, Search, Maps), CDNs modernos, apps móveis onde a migração de conexão entre Wi-Fi/celular importa e qualquer carga sensível a latência onde a economia de 2 RTTs se traduz em melhoria mensurável de page load (tipicamente 5-15% em sites reais).

FAQ

Por que o QUIC usa UDP em vez de um novo transporte? Middleboxes (firewalls, NATs) só deixam passar TCP e UDP. Construir sobre UDP permitiu ao QUIC ser implantado imediatamente, sem esperar atualização de kernels de SO e roteadores.

0-RTT é seguro? Dados 0-RTT são replicáveis, então só são seguros para requests idempotentes (GETs). Servidores devem rejeitar 0-RTT não idempotente ou aceitar o risco de replay.

QUIC resolve head-of-line blocking? Sim, na camada de transporte. Um pacote perdido no stream A não trava mais os streams B, C, D. O HTTP/2 sobre TCP sofria desse problema porque o TCP entrega bytes em ordem independente do stream.