Três anos e meio se passaram desde a adoção do padrão HTTP / 2: a especificação RFC 7540 foi publicada em maio de 2015, mas ainda não é usada em todos os lugares. O protocolo foi implementado em todos os navegadores desde o final de 2015 e, após três anos, apenas 31,2% dos 10 milhões de sites populares da Internet suportam HTTP / 2. Entre os sites mais populares, Google, Youtube, Wikipedia, Twitter, Vk.com e outros mudaram para ele.

No entanto, o progresso não pára - e o trabalho já está em andamento na próxima versão do HTTP / 3. Como ficou conhecido agora, os desenvolvedores de duas opções alternativas alcançaram compatibilidade, e o protocolo HTTP sobre QUIC agora muda seu nome e é oficialmente chamado de HTTP / 3 . Assim, em uma versão futura do HTTP, o transporte TCP será substituído pelo QUIC.

Confusão com diferentes opções QUIC

QUIC é uma substituição de TCP que funciona sobre o UDP. Inicialmente, essa tecnologia foi criada pelos engenheiros do Google, como o protocolo SPDY anterior, que se tornou a base do HTTP / 2. No início, o QUIC foi chamado de "HTTP / 2 criptografado sobre UDP".

O desenvolvimento QUIC foi então transferido para o IETF para padronização. Aqui foi dividido em duas partes: transporte e HTTP. A idéia é que o protocolo de transporte também possa ser usado para transferir outros dados, e não apenas exclusivamente para protocolos HTTP ou do tipo HTTP. No entanto, o nome permanece o mesmo: QUIC. O protocolo de transporte é desenvolvido pelo Grupo de Trabalho QUIC do Internet Engineering Council (IETF).

Ao mesmo tempo, o Google continuou trabalhando em sua própria implementação - e a implementou no navegador Chrome. Embora os testes mostrem que a implementação do QUIC do Google é significativamente pior que o TCP, se a rede não garantir a entrega de pacotes .


Diferença de desempenho entre QUIC com TCP (em porcentagem) em uma rede com 112 ms RTT e 10 ms jitter, origem


Diferença de desempenho entre QUIC com TCP (em porcentagem) em uma rede com RTT 112 ms e 10 ms jitter, que altera a ordem dos pacotes, origem

Alguns desenvolvedores geralmente consideram qualquer versão do QUIC no UDP uma "experiência mais louca" .

A discórdia nas versões e nomeação do QUIC é explicada por Daniel Stenberg, desenvolvedor de cachos da Mozilla que acompanha essa história há muito tempo.

Segundo ele, os nomes informais das duas versões do QUIC se espalharam entre os desenvolvedores, uma vez que as opções da IETF e do Google variam significativamente nos detalhes da implementação:

• iQUIC (versão IETF)
• gQUIC (versão do Google)

O protocolo para enviar HTTP sobre iQUIC (versão IETF) é chamado há muito tempo "hq" (HTTP sobre QUIC).

Em geral, não havia um nome estabelecido para versões diferentes. No seminário do QUIC Workshop, Mike Bishop assustou a todos com um slide como se fosse um logotipo.


Slide da apresentação de Mike Bishop

Os facilitadores do workshop pediram a Mike para nunca mais mostrá-lo .

No entanto, em 7 de novembro de 2018, um dos principais desenvolvedores do protocolo, Dmitry Tikhonov, anunciou que o LiteSpeed ​​Tech e o Facebook alcançaram a compatibilidade do protocolo, e agora o desenvolvimento continuará na mesma linha.

A combinação do iQUIC e do gQUIC chamado HTTP / 3 em setembro foi proposta por Mark Nottingham, um dos engenheiros mais influentes da IETF, co-autor de vários padrões da web. Segundo ele, isso ajudará a eliminar a confusão entre o transporte QIUC e o wrapper QUIC para HTTP.

Portanto, HTTP / 3 é a nova versão do HTTP que usará o transporte QUIC .

Transporte QUIC

Quais são as vantagens do protocolo de transporte QUIC sobre TCP? Há muitas vantagens e, segundo o próprio Mark Nottingham, a transição do TCP desatualizado para o novo protocolo é simplesmente inevitável, pois agora é óbvio que o TCP está sofrendo problemas de ineficiência.

“Como o TCP é um protocolo de entrega de pacotes em ordem, a perda de um pacote pode interferir na entrega dos pacotes subsequentes do buffer para o aplicativo. Em um protocolo multiplexado, isso pode levar a uma grande perda de desempenho ”, explica Mark Nottingham. "O QUIC está tentando resolver esse problema reconstruindo efetivamente a semântica do TCP (junto com alguns aspectos do modelo de fluxo HTTP / 2) sobre o UDP."



Além de alternar uma quantidade significativa de tráfego de TCP para UDP, o Google QUIC (gQUIC) e o IETF QUIC (iQUIC) exigem criptografia obrigatória: não há QUIC não criptografado . O iQUIC usa o TLS 1.3 para definir chaves de sessão e, em seguida, criptografar cada pacote. Porém, como é baseado no UDP, muitas das informações e metadados da sessão abertos no TCP são criptografados no QUIC.

No artigo "O futuro dos protocolos da Internet", Mark Nottingham fala sobre melhorias significativas na segurança com a mudança para o QUIC:

Na verdade, o atual “cabeçalho curto” iQUIC - que é usado para todos os pacotes, exceto um handshake - fornece apenas o número do pacote, o identificador de conexão opcional e o byte de status, necessário para processos como alterar chaves de criptografia e tipo de pacote (que também podem ser criptografados). Todo o resto é criptografado - incluindo pacotes ACK, o que aumenta muito a barreira para ataques com análise de tráfego .

Além disso, torna-se impossível avaliar passivamente o RTT e a perda de pacotes simplesmente monitorando a conexão; não há informações suficientes para isso.

A falta de observabilidade causou séria preocupação entre alguns representantes da comunidade de operadoras de telecomunicações. Eles dizem que essas medidas passivas são críticas para depurar e analisar suas redes.

Uma das sugestões para resolver esse problema é a introdução de um bit de rotação . Isso é um pouco no cabeçalho que altera seu valor uma vez na ida e volta, para que o observador possa avaliar o RTT. Como não está vinculado ao estado do aplicativo, ele não deve produzir nenhuma informação sobre os terminais, exceto para uma estimativa aproximada do local da rede.

Talvez a adoção do padrão QUIC tivesse acontecido anteriormente se o Google não tivesse se apressado para implementar sua implementação no navegador Chrome, agora a versão proprietária do iQUIC responde por mais de 7% do tráfego da Internet.

Não obstante, o progresso é inevitável - e nos próximos anos, a padronização e a ampla implementação de vários protocolos de nova geração, incluindo HTTP / 3 no transporte QUIC, certamente continuarão.

---