O QUIC dominará a Internet

QUIC (não é uma sigla) é uma fera única, mas é melhor pensado como um novo protocolo de transporte que resolve muitos problemas de longa data na internet e captura a maior parte do valor fornecido por TCP, TLS, SCTP, IPSec e HTTP/2. Há uma nova versão do HTTP chamada HTTP/3 que foi projetada para funcionar via UDP/QUIC em vez de TCP/TLS.

O Google implantou uma versão inicial do HTTP sobre QUIC em seus navegadores e servidores web já em 2014. Um processo de padronização da IETF começou em 2016. Após muita evolução e coleta de dados, isso resultará no primeiro lote de RFCs no início de 2021. Várias grandes empresas de internet, incluindo a F5, lançaram produtos que usam QUIC ou implementaram QUIC em sua infraestrutura. Em outubro de 2020, 75% do tráfego do Facebook era via HTTP/3 e QUIC.

Essas implantações iniciais e o fervor por novos padrões além do QUIC no IETF indicam que este se tornará um substrato importante e possivelmente dominante para aplicações de ponta na Internet.

Visão geral técnica — Por que QUIC?

A Figura 1 dá ao leitor uma ideia do que o QUIC faz. No entanto, essa decomposição funcional não esclarece por que os primeiros usuários na indústria estão migrando para o QUIC:

1. Menor latência. As transferências de dados semelhantes à Web são dominadas pela latência de três camadas de handshakes: uma para TCP, pelo menos uma para TLS e uma para solicitação/resposta HTTP. Desenvolvimentos recentes em TCP/TLS podem, em princípio, reduzir isso a uma viagem de ida e volta, embora isso raramente funcione na prática. O QUIC reduzirá isso para uma viagem de ida e volta, e no máximo duas.
   
   
2. Fluxos. Assim como o HTTP/2, o QUIC fornece ao aplicativo vários fluxos de bytes para aumentar a independência de dados conceitualmente distintos entregues pela mesma conexão. Fazer isso no transporte só aumenta essa independência. Os streams atendem naturalmente às necessidades de entrega de vídeo em streaming e os principais provedores de conteúdo da Internet estão a caminho de entregar streaming via QUIC.
   
   
3. Melhor resposta a perdas. O design do QUIC melhora a capacidade do TCP de detectar e se recuperar de perdas de pacotes. Além disso, ao apresentar fluxos multiplexados em vez de um único fluxo de bytes em ordem, a perda de um pacote contendo um objeto não precisa atrasar a entrega de um objeto diferente.
   
   
4. Multihoming. Assim como MPTCP e SCTP, as conexões QUIC podem ser associadas a vários endereços IP para cada ponto de extremidade. Ao contrário desses protocolos, o QUIC tem uma boa chance de atravessar uma internet que descarta números de protocolo e opções de cabeçalho TCP desconhecidos.
   
   
5. Segurança e privacidade. O QUIC aplica criptografia na camada de transporte, em vez de acima dela. Toda a carga útil do UDP é autenticada, impedindo qualquer modificação transparente por intermediários, e quase todas as informações de transporte são criptografadas. As ramificações disso são um documento por si só. Basta dizer que isso melhora substancialmente as propriedades de privacidade e praticamente elimina a superfície de ataque que o TCP fornece. Diferentemente do IPSec, isso está sendo executado hoje em escala web. Isso também leva a:
   
   
6. Extensibilidade. O TCP é difícil de mudar porque seus criadores deixaram espaço de extensão limitado e porque os middleboxes impõem o comportamento antigo do TCP. O QUIC combina controle de versão explícito com opacidade para middleboxes para permitir maior inovação no transporte. Isso permitirá suporte para casos de uso futuros e, eventualmente, melhoria na capacidade de transporte em massa em comparação ao TCP.

Há dois motivos, além da inércia, pelos quais alguns aplicativos podem não migrar para o QUIC:

• Complexidade: aplicativos que precisam apenas de um único fluxo de bytes e não se importam com criptografia não precisam da carga de trabalho adicional associada a esses recursos.
  
  
• Caixas intermediárias: Uma porcentagem não desprezível de caminhos de internet não admite UDP. O HTTP/3 foi projetado com fallback TCP para esses caminhos, mas, em última análise, o impacto no desempenho dos principais sites (Google, Facebook, etc.) provavelmente tornará obsoletos os dispositivos responsáveis, exceto quando os estados-nação que desejam vigilância determinarem o contrário.

Está comendo a internet

O Google Chrome, o Google App Clients e o aplicativo do Facebook já oferecem suporte a HTTP/3. Implementações do Safari, Edge e Firefox oferecem suporte a ele, mas (por enquanto) desativado por padrão.

No lado do servidor, implementações e/ou implantações do Google, Microsoft, Facebook, Apple, Cloudflare, LiteSpeed, F5 BIG-IP, NGINX, Fastly e Akamai já foram lançadas ou estão próximas disso. Recentemente, um importante ISP europeu relatou que 20% de seus pacotes eram QUIC . Cerca de 5% dos sites usam HTTP/3 em fevereiro de 2021, mas esperamos que isso cresça quando o RFC for publicado.

Além disso, há muito trabalho em organizações de padronização para levar o QUIC além do caso de uso do HTTP. Os padrões de rascunho no IETF propõem DNS, Websockets, SIP e túneis TCP e UDP sobre QUIC. O QUIC chegou um pouco tarde demais para ser totalmente incorporado às arquiteturas 5G, mas o interesse e a aplicabilidade do QUIC para provedores de serviços são claros. Por fim, as APIs superiores para HTTP/2 e HTTP/3 são bastante semelhantes, então qualquer protocolo ou aplicativo executado sobre HTTP/2 pode ser facilmente portado para ser executado sobre HTTP/3 e QUIC em vez de TCP.

Ameaças e oportunidades

QUIC e HTTP/3 moldarão uma variedade de mercados . Sites e aplicativos de alto desempenho têm um forte incentivo para mudar para HTTP/3 e QUIC quando o ecossistema estiver totalmente maduro, e esperamos que nossos clientes exijam suporte para HTTP/3 em um ritmo semelhante ao da implantação do HTTP/2.

Produtos de segurança precisam de uma reavaliação fundamental em uma internet denominada QUIC. A inspeção de pacotes é muito mais difícil sem acesso às chaves de sessão TLS, o que geralmente só é possível com a posse da chave privada do domínio. Isso aumenta o valor de uma solução de segurança integrada a um proxy em nível de aplicativo, em vez de uma série de dispositivos de função única.

Além disso, a defesa tradicional contra DDoS precisa de um ajuste. Não só a identificação e a inspeção de pacotes são mais difíceis, mas os syncookies TCP foram substituídos por “pacotes de repetição”, que não podem ser facilmente falsificados por intermediários. Existem maneiras padrão de coordenação que permitem que os servidores descarreguem a geração e validação de pacotes de repetição, mas, novamente, isso exige esforço de desenvolvimento.

O balanceamento de carga tradicional da Camada 4 interromperá a migração de endereços QUIC, pois não poderá associar um fluxo que altere seu endereço ou portas para si mesmo e, em seguida, rotear para o mesmo servidor. Novamente, existem padrões para coordenar e superar esse problema, mas isso requer investimento.

O grupo de trabalho MASQUE do IETF está trabalhando no tunelamento de tráfego generalizado sobre QUIC, o que pode ser a base de esquemas de VPN de próxima geração . As propriedades do QUIC são muito melhores para multiplexar fluxos arbitrários do que o TLS sobre TCP. Esses túneis também podem substituir os túneis IPSec pela criptografia em escala da web, melhorando alguns casos de uso de provedores de serviços e até mesmo fornecendo uma maneira de otimizar conexões QUIC para tipos de links móveis com consentimento explícito do cliente.

O QUIC exigirá novas ferramentas de medição e análise de rede. Sistemas que podem medir a latência e a perda de TCP não podem usar esses sinais, mas há um sinal de latência explícito para a rede, e outros sinais podem estar a caminho. Com mais informações de transporte ocultas por trás da criptografia, as capturas de pacotes são menos úteis. No entanto, há um formato de registro padrão emergente que muitas implementações do QUIC seguem e que as pessoas estão criando ferramentas de análise para aproveitar.

F5 está acompanhando os desenvolvimentos de perto

A equipe do F5 monitora os esforços de padronização no IETF há anos e contribui quando achamos que isso ajudará nossos clientes. O BIG-IP vem monitorando os rascunhos de lançamento do QUIC e do HTTP/3 desde o início, incluindo lançamentos públicos desde o TMOS v15.1.0.1. O NGINX tem uma versão alfa do HTTP/3 e será integrado à linha principal em breve.

Continuaremos observando tendências nessa área e criando produtos novos e interessantes para refletir os novos recursos que esses protocolos oferecem.

Conclusão

O QUIC tem amplo suporte do setor e potencial para ser a base da maioria dos aplicativos que geram valor comercial pela Internet. Qualquer pessoa que forneça aplicativos pela Internet deve começar a pensar em como suas operações devem mudar para refletir as novas ameaças e oportunidades que esses protocolos trazem.