O TCP estava quebrado demais para ser consertado, então a Internet construiu um novo protocolo sobre o UDP

O TCP é a camada de transporte da Internet desde 1974. Cada página web que você carrega, cada requisição de API que seu aplicativo faz, cada e-mail que você envia — por cinquenta anos, quase tudo isso viajou sobre TCP. O protocolo é confiável, testado em batalha e implantado em todos os dispositivos conectados à rede no planeta. Ele também está se tornando cada vez mais um gargalo para a forma como a web moderna realmente funciona, e consertá-lo se mostrou politicamente impossível. Então a indústria construiu algo novo sobre UDP.

Esse algo novo é o QUIC, padronizado pela IETF em 2021 como RFC 9000. HTTP/3, a versão mais recente do protocolo que alimenta a web, roda sobre QUIC. Cloudflare serviu HTTP/3 para mais de 40% do seu tráfego. O Google implantou QUIC em seus próprios serviços desde 2013. O protocolo que deveria ser um experimento agora transporta uma fatia substancial da Internet.

O que havia de errado com o TCP

O design fundamental do TCP foi construído para um mundo de conexões fixas e confiáveis com fio. O protocolo assume que, se um pacote for perdido, a rede está congestionada e ele deve desacelerar. Isso era razoável em 1974. Em 2026, com usuários móveis constantemente alternando entre Wi-Fi e celular, pacotes são descartados por razões que não têm nada a ver com congestionamento — interferência de sinal, handoffs entre torres, breves lacunas de cobertura. O TCP não consegue distinguir entre "a rede está congestionada" e "o usuário acabou de entrar em um elevador", e desacelera em ambos os casos.

O problema estrutural maior é o bloqueio de head-of-line. Uma única conexão TCP é um fluxo ordenado de dados. Se o pacote 7 for perdido, os pacotes 8 a 100 ficam todos esperando, mesmo que tenham chegado corretamente. HTTP/2 abordou uma versão desse problema multiplexando múltiplas requisições sobre uma única conexão TCP — mas isso na verdade piorou o bloqueio head-of-line na camada TCP, não melhorou. Um único pacote perdido agora pode parar todos os fluxos multiplexados na conexão simultaneamente.

Havia também a sobrecarga de estabelecimento de conexão. O TCP requer um handshake de três vias antes que os dados possam fluir. TLS adiciona mais 1-2 viagens de ida e volta para negociação criptográfica. Carregar um recurso de um novo servidor requer 2-3 viagens completas de ida e volta antes que o primeiro byte de conteúdo chegue. Para um usuário em Tóquio se conectando a um servidor na Virgínia, cada viagem de ida e volta leva aproximadamente 170 milissegundos. Multiplique isso pelo número de servidores distintos com os quais uma página web moderna se comunica, e a sobrecarga de latência é significativa.

Por que construíram sobre UDP

A pergunta lógica é: por que não consertar o TCP? A resposta é que o TCP está implementado no kernel de todos os sistemas operacionais, todos os roteadores, todos os firewalls, todos os balanceadores de carga e todos os middleboxes da Internet. Mudar o comportamento do TCP exigiria atualizar bilhões de dispositivos. Alguns desses dispositivos têm décadas de idade e nunca serão atualizados. Os middleboxes de rede — os aparelhos que inspecionam, roteiam e filtram o tráfego — assumem o comportamento do TCP e quebram de maneiras imprevisíveis quando o TCP é modificado. A IETF tentou várias extensões do TCP ao longo dos anos e descobriu que elas eram simplesmente bloqueadas ou removidas pelos middleboxes em campo.

UDP, por outro lado, é essencialmente uma tela em branco. É um protocolo fire-and-forget sem estado de conexão inerente, ordenação ou confiabilidade. Os middleboxes não mexem com UDP da mesma forma que fazem com TCP porque não há nada com que mexer. Construir QUIC sobre UDP significa que o QUIC pode implementar seu próprio gerenciamento de conexão, confiabilidade, ordenação e controle de congestionamento no espaço do usuário — onde pode ser atualizado sem alterações no kernel — enquanto ainda passa pela infraestrutura da Internet existente sem modificações.

O que o QUIC realmente muda

A melhoria mais imediatamente perceptível é o tempo de estabelecimento de conexão. O QUIC combina o handshake de transporte e o handshake criptográfico TLS 1.3 em uma única viagem de ida e volta. Para uma primeira conexão a um servidor, o QUIC requer uma viagem de ida e volta antes que os dados possam fluir, contra duas ou três para TCP+TLS. Para um usuário que retorna e já se conectou ao servidor antes, o QUIC suporta retomada 0-RTT — o cliente pode enviar dados de aplicação no primeiro pacote, com zero viagens de ida e volta. A melhoria de desempenho é mais pronunciada em redes móveis onde a latência é alta.

A migração de conexão (Connection migration) resolve diretamente o problema de handoff móvel. Uma conexão QUIC é identificada por um ID de conexão escolhido pelo endpoint, não pelo quádruplo (IP de origem, porta de origem, IP de destino, porta de destino) que identifica uma conexão TCP. Quando um telefone passa de Wi-Fi para celular e obtém um novo endereço IP, suas conexões TCP são todas interrompidas e precisam ser restabelecidas. As conexões QUIC sobrevivem à mudança de IP — o cliente anuncia seu novo endereço e a conexão continua sem interrupção.

Fluxos multiplexados sem bloqueio head-of-line é a correção estrutural que o HTTP/2 precisava, mas não conseguiu alcançar sobre TCP. O QUIC implementa múltiplos fluxos independentes dentro de uma conexão; um pacote perdido para o fluxo A não bloqueia os fluxos B, C e D. Cada fluxo tem sua própria garantia de ordenação, de modo que a perda em um fluxo apenas paralisa esse fluxo.

A realidade da implantação

A adoção tem sido mais rápida do que a maioria das transições de protocolo na história da Internet, que ainda é "medida em anos". O Google implantou o QUIC no Chrome em 2015, inicialmente apenas para seus próprios serviços. A IETF padronizou o QUIC e o HTTP/3 em 2021. Em 2023, dados do W3Techs mostravam suporte a HTTP/3 em cerca de 30% dos sites. A Cloudflare relata que o QUIC transporta aproximadamente 35-40% de seu tráfego, e essa fração tem crescido continuamente ano após ano.

A adoção no lado do servidor é forte entre as principais CDNs (Cloudflare, Fastly, Akamai) e provedores de nuvem (AWS CloudFront, Google Cloud). A maioria dos frameworks web modernos e balanceadores de carga suportam HTTP/3. O lado do cliente está coberto: Chrome, Firefox, Safari e Edge suportam HTTP/3 por padrão, assim como os navegadores móveis.

Nem toda conexão QUIC tem desempenho melhor que TCP. Em conexões de banda larga fixa de alta qualidade, a diferença é mínima. A implementação em espaço do usuário do QUIC significa que ele não se beneficia das otimizações de CPU que o TCP acumulou ao longo de décadas no kernel — a sobrecarga de processamento por pacote é maior, o que importa em conexões de alta taxa de transferência. Para transferências de arquivos grandes em links rápidos e confiáveis, o TCP ainda é competitivo.

Os ganhos são mais pronunciados em três cenários: redes móveis de alta latência, conexões que sobrevivem a mudanças de endereço IP e carregamentos de página que envolvem muitas requisições pequenas para muitos servidores. A web em 2026 é fortemente inclinada para esses três cenários, e é por isso que a migração tem um impulso sustentado que versões anteriores do HTTP não alcançaram.

O QUIC não resolve todos os problemas do transporte da Internet — controle de congestionamento, bufferbloat e capacidade da última milha continuam sendo verdadeiras limitações. Mas ele resolve os problemas que eram solucionáveis sem substituir a infraestrutura de rede física. Essa é uma melhoria significativa, entregue por meio de uma das implantações de protocolo mais rápidas da história da IETF.