Desempenho do TLS: QUIC e HTTP/3

O HTTP/2 multiplexa vários fluxos em uma única conexão TCP, resolvendo o bloqueio de início de fila por conexão do HTTP/1.1. No entanto, o próprio TCP causa bloqueio de início de fila na camada de transporte: se um segmento TCP for perdido, todos os dados atrás dele na fila aguardam a retransmissão, bloqueando simultaneamente todos os fluxos do HTTP/2. Uma perda de pacotes de 1% pode degradar o desempenho do HTTP/2 para abaixo do HTTP/1.1 com várias conexões. O QUIC resolve esse problema implementando fluxos multiplexados sobre UDP, nos quais a recuperação de perdas no nível do fluxo não bloqueia os demais fluxos.

QUIC é um protocolo de transporte construído sobre UDP, desenvolvido pelo Google (2012–2015) e padronizado pela IETF como RFC 9000 (2021). QUIC integra o TLS 1.3 à camada de transporte — não há uma negociação separada do TLS sobre o QUIC; o TLS está incorporado à própria negociação do QUIC. QUIC oferece: fluxos multiplexados sem bloqueio de início de fila, migração de conexão (mantendo a conexão ao alternar entre redes, por exemplo, de WiFi para LTE), estabelecimento de conexão 0-RTT para conexões repetidas e detecção de perdas e controle de congestionamento integrados. HTTP/3 (RFC 9114) transporta a semântica do HTTP pelos fluxos QUIC.

A negociação do QUIC combina o estabelecimento da conexão com a negociação do TLS. No primeiro envio (0 RTT na terminologia do QUIC), o cliente envia pacotes iniciais contendo ClientHello do TLS. O servidor responde com seu próprio pacote inicial (ServerHello), além de pacotes de negociação (extensões criptografadas, certificado e mensagem de finalização). O cliente envia a mensagem de finalização da negociação e então está pronto para enviar dados da aplicação — isso corresponde a 1-RTT. Para conexões 0-RTT, o cliente envia pacotes 0-RTT (dados da aplicação) junto com ClientHello, usando uma chave derivada do segredo de retomada da sessão anterior, alcançando zero viagens adicionais de ida e volta para sessões armazenadas em cache.

QUIC usa quatro níveis distintos de criptografia, correspondentes às fases do cronograma de chaves do TLS: Inicial (AEAD derivado do QUIC usando uma chave constante conhecida — fornece integridade, mas não confidencialidade contra atacantes sofisticados), Negociação (derivado do segredo de negociação do TLS — fornece confidencialidade para as mensagens de negociação do TLS), 0-RTT (derivado do segredo inicial da sessão anterior — criptografa os dados da aplicação em 0-RTT) e 1-RTT (derivado do segredo principal do TLS — criptografa todos os dados da aplicação). Os cabeçalhos do QUIC são parcialmente criptografados: o número do pacote e a carga útil são criptografados, mas algumas informações de roteamento, como o identificador de conexão, permanecem visíveis para os balanceadores de carga.

As conexões QUIC são identificadas por um identificador de conexão (CID), e não por uma 4-tupla (IP de origem, porta de origem, IP de destino, porta de destino). Isso permite que as conexões sobrevivam a mudanças de rede: quando um cliente móvel muda de WiFi para LTE, o endereço IP muda, mas o CID permanece o mesmo. O cliente envia um quadro PATH_CHALLENGE pelo novo caminho; o servidor responde com PATH_RESPONSE, validando o novo endereço. A conexão continua sem interrupções e sem renegociação. O TCP não oferece esse suporte — uma conexão TCP está vinculada à sua 4-tupla e precisa ser restabelecida quando a rede muda, exigindo uma nova negociação do TLS. A migração do QUIC melhora significativamente o desempenho percebido pelos usuários móveis.

HTTP/3 mapeia a semântica do HTTP para os fluxos QUIC. Cada par de solicitação e resposta HTTP ocupa um fluxo QUIC bidirecional separado. Os fluxos QUIC são independentes: uma perda no fluxo 3 não bloqueia o fluxo 7. HTTP/3 usa QPACK para compressão de cabeçalhos, substituindo o HPACK do HTTP/2 — QPACK foi redesenhado para funcionar sem exigir entrega na ordem. Dois fluxos de controle unidirecionais dedicados transportam configurações e instruções do decodificador e do codificador. O envio pelo servidor no HTTP/3 usa fluxos de envio, que são unidirecionais. O efeito geral é que HTTP/3 supera o HTTP/2 de forma mais significativa sob condições de perda de pacotes, como em redes móveis e caminhos congestionados, onde o bloqueio de início de fila do TCP é mais prejudicial.

Medições do desempenho do QUIC e do HTTP/3 no mundo real mostram resultados variados, dependendo das condições da rede. Em redes de alta qualidade, com baixa latência e pouca perda de pacotes, HTTP/3 e HTTP/2 têm desempenho semelhante — a sobrecarga do QUIC, com cabeçalhos maiores e processamento adicional do UDP, pode até tornar o HTTP/3 um pouco mais lento. Em redes com perdas, com mais de 1% de perda de pacotes, algo comum em redes móveis e via satélite, HTTP/3 supera significativamente o HTTP/2. O Google informou uma redução de 7–8% na rebufferização do YouTube ao mudar para QUIC. O Facebook (Meta) informou uma melhoria de 7–15% na latência das solicitações dos feeds do Instagram usando QUIC. Os ganhos são mais visíveis na latência de cauda, como p95 e p99, em que as pausas causadas pelas retransmissões do TCP têm maior impacto.

O balanceamento de carga do QUIC é mais complexo que o do TCP porque o QUIC é baseado em UDP, e os balanceadores de carga UDP sem estado não conseguem manter a afinidade de conexão. O rascunho draft-ietf-quic-load-balancers da IETF define uma abordagem: os servidores codificam informações de roteamento no identificador de conexão para que os balanceadores de carga possam encaminhar os pacotes da mesma conexão para o mesmo servidor sem manter o estado de cada conexão. O identificador de conexão transporta um identificador de servidor criptografado usando uma chave compartilhada entre o balanceador de carga e os servidores. Cloudflare, Fastly e Nginx implementam variantes dessa abordagem. A travessia de NAT é outra preocupação: as conexões QUIC precisam sobreviver à reassociação de NAT, tratada pelo mecanismo de migração de conexão.

As principais redes de distribuição de conteúdo implantaram QUIC e HTTP/3 em grande escala. A Cloudflare oferece HTTP/3 desde 2019 e informa que aproximadamente 20% do tráfego usa QUIC quando há suporte tanto no cliente quanto no servidor. Fastly, Akamai e AWS CloudFront oferecem suporte a HTTP/3 em seus pontos de presença. A própria infraestrutura do Google, incluindo Pesquisa, YouTube e Gmail, usa QUIC internamente desde 2013 e disponibiliza HTTP/3 publicamente. As implantações em redes de distribuição de conteúdo se beneficiam da retomada 0-RTT do QUIC: visitantes recorrentes estabelecem conexões mais rapidamente, e a migração de conexão melhora o desempenho para usuários móveis que alternam entre pontos de acesso durante a entrega de conteúdo.

O design do QUIC baseado em UDP introduz considerações específicas de segurança. Ataques de amplificação: um atacante pode falsificar um IP de origem e enviar pequenos pacotes iniciais, fazendo o servidor enviar respostas de negociação grandes à vítima — o QUIC reduz esse risco limitando as respostas do servidor a três vezes os dados recebidos até que a validação do endereço seja concluída, por meio do mecanismo RETRY. Inundação de conexões: os servidores QUIC precisam limitar a taxa de novas tentativas de conexão provenientes do mesmo IP. Ataques de negociação de versão são impedidos pela inclusão da versão na negociação protegida criptograficamente. A criptografia integrada do QUIC significa que os dispositivos de inspeção não conseguem analisar a carga útil do QUIC sem estar no caminho da comunicação com o certificado do servidor, melhorando a privacidade em comparação com o tráfego TCP que pode ser inspecionado.

A implantação do HTTP/3 requer: (1) um servidor compatível com QUIC, como nginx 1.25+, Caddy, HAProxy 2.6+, LiteSpeed ou uma solução no nível da aplicação por meio das bibliotecas quic-go, aioquic e ngtcp2. (2) A porta UDP 443 aberta nos firewalls — muitos firewalls corporativos bloqueiam a UDP 443, fazendo o QUIC recorrer a TCP/TLS. (3) A divulgação do suporte a HTTP/3 por meio do cabeçalho de resposta Alt-Svc: h3=":443"; ma=86400, levando os clientes HTTP/2 a migrar. (4) Balanceadores de carga compatíveis com QUIC ou repasse UDP na camada L4. (5) O monitoramento de métricas específicas do QUIC: eventos de migração de conexão, taxa de aceitação de 0-RTT e taxa de reversão de protocolo. Uma implantação gradual, com retorno ao HTTPS, é transparente para clientes que não oferecem suporte ao QUIC.

Como o QUIC resolve o problema de bloqueio de início de fila que afeta o HTTP/2 sobre TCP?

QUIC integra o TLS 1.3 à camada de transporte sobre UDP, eliminando o bloqueio de início de fila do TCP por meio da recuperação independente de perdas em cada fluxo. Os identificadores de conexão permitem a migração entre mudanças de rede sem renegociação. HTTP/3 mapeia o HTTP para fluxos QUIC usando a compressão de cabeçalhos QPACK. A retomada de conexão 0-RTT reutiliza os segredos da sessão TLS. QUIC supera o HTTP/2 de forma mais significativa sob perda de pacotes, como em redes móveis e congestionadas. O balanceamento de carga do QUIC exige a codificação do roteamento do servidor nos identificadores de conexão. A implantação requer UDP 443, servidores compatíveis com QUIC e cabeçalhos Alt-Svc para anunciar o protocolo.