HTTP/3: opções práticas de implantação (parte 3)

Olá, e bem-vindo à parte final desta série de três partes sobre os novos protocolos HTTP/3 e QUIC! Se após as duas partes anteriores — histórico e conceitos básicos do HTTP/3 e recursos de desempenho do HTTP/3 — você estiver convencido de que começar a usar os novos protocolos é uma boa ideia (e você deveria estar!), então esta parte final inclui todos os você precisa saber para começar!

Primeiro, discutiremos quais alterações você precisa fazer em suas páginas e recursos para usar de maneira otimizada os novos protocolos (essa é a parte fácil). Em seguida, veremos como configurar servidores e clientes (essa é a parte difícil, a menos que você esteja usando uma rede de entrega de conteúdo (CDN)). Por fim, veremos quais ferramentas você pode usar para avaliar o impacto no desempenho dos novos protocolos (essa é a parte quase impossível, pelo menos por enquanto).

Alterações em páginas e recursos

Vamos começar com algumas boas notícias: se você já usa HTTP/2, provavelmente não precisará alterar nada em suas páginas ou recursos ao migrar para HTTP/3! . Isso ocorre porque, como explicamos na parte 1 e na parte 2, HTTP/3 é realmente mais parecido com HTTP/2-sobre-QUIC, e os recursos de alto nível das duas versões permaneceram os mesmos. Como tal, quaisquer alterações ou otimizações feitas para HTTP/2 ainda funcionarão para HTTP/3 e vice-versa.

No entanto, se você ainda está no HTTP/1.1, ou se esqueceu da sua transição para o HTTP/2, ou nunca ajustou as coisas para o HTTP/2, então você pode se perguntar quais foram essas mudanças e por que elas foram necessárias. No entanto, você seria pressionado até hoje para encontrar um bom artigo que detalhasse as melhores práticas diferenciadas . Isso porque, como afirmei na introdução da parte 1, grande parte do conteúdo inicial do HTTP/2 era excessivamente otimista sobre o quão bem ele funcionaria na prática, e alguns deles, francamente, continham grandes erros e maus conselhos. Infelizmente, grande parte dessa desinformação persiste hoje. Essa é uma das minhas principais motivações ao escrever esta série sobre HTTP/3, para ajudar a evitar que isso aconteça novamente.

A melhor fonte multifuncional para HTTP/2 que posso recomendar neste momento é o livro HTTP/2 em Ação de Barry Pollard. No entanto, como esse é um recurso pago e não quero que você fique adivinhando aqui, listei alguns dos pontos principais abaixo, além de como eles se relacionam com o HTTP/3:

1. Conexão Única

A maior diferença entre HTTP/1.1 e HTTP/2 foi a mudança de 6 para 30 conexões TCP paralelas para uma única conexão TCP subjacente. Discutimos um pouco na parte 2 como uma única conexão ainda pode ser tão rápida quanto várias conexões, por causa de como o controle de congestionamento pode causar mais ou mais perda de pacotes com mais conexões (o que desfaz os benefícios de seu início mais rápido agregado). O HTTP/3 continua essa abordagem, mas “apenas” alterna de uma conexão TCP para uma conexão QUIC. Essa diferença por si só não faz muito (reduz principalmente a sobrecarga no lado do servidor), mas leva à maioria dos pontos a seguir.

2. Fragmentação do Servidor e Coalescência de Conexão

A mudança para a configuração de conexão única foi bastante difícil na prática porque muitas páginas foram fragmentadas em diferentes nomes de host e até mesmo servidores (como img1.example.com e img2.example.com ). Isso ocorreu porque os navegadores só abriram até seis conexões para cada nome de host individual, portanto, permitir várias conexões para mais conexões! Sem alterações nessa configuração do HTTP/1.1, o HTTP/2 ainda abriria várias conexões, reduzindo o desempenho de outros recursos, como a priorização (veja abaixo).

Assim, a recomendação original era desfazer a fragmentação do servidor e consolidar os recursos em um único servidor o máximo possível. O HTTP/2 até forneceu um recurso para facilitar a transição de uma configuração HTTP/1.1, chamado de união de conexões. Grosso modo, se dois nomes de host resolverem para o mesmo IP de servidor (usando DNS) e usarem um certificado TLS semelhante, o navegador poderá reutilizar uma única conexão mesmo entre os dois nomes de host .

Na prática, a união de conexões pode ser difícil de acertar, por exemplo, devido a vários problemas sutis de segurança envolvendo CORS. Mesmo se você o configurar corretamente, ainda poderá acabar facilmente com duas conexões separadas. A questão é que isso nem sempre é ruim . Primeiro, devido à priorização e multiplexação mal implementadas (veja abaixo), a conexão única pode ser facilmente mais lenta do que usar duas ou mais. Em segundo lugar, o uso de muitas conexões pode causar perda antecipada de pacotes devido a controladores de congestionamento concorrentes. Usar apenas alguns (mas ainda mais de um), no entanto, poderia equilibrar bem o crescimento do congestionamento com melhor desempenho, especialmente em redes de alta velocidade. Por essas razões, acredito que um pouco de fragmentação ainda é uma boa ideia (digamos, duas a quatro conexões), mesmo com HTTP/2. Na verdade, acho que a maioria das configurações modernas de HTTP/2 funcionam tão bem porque ainda têm algumas conexões extras ou cargas de terceiros em seu caminho crítico.

3. Agrupamento e Inlining de Recursos

No HTTP/1.1, você poderia ter apenas um único recurso ativo por conexão, levando ao bloqueio de cabeçalho de linha (HoL) no nível HTTP. Como o número de conexões foi limitado a apenas 6 a 30, o agrupamento de recursos (em que sub-recursos menores são combinados em um único recurso maior) era uma prática recomendada de longa data. Ainda vemos isso hoje em pacotes como o Webpack. Da mesma forma, os recursos eram frequentemente embutidos em outros recursos (por exemplo, CSS crítico era embutido no HTML).

Com o HTTP/2, no entanto, a conexão única multiplexa recursos, para que você possa ter muito mais solicitações pendentes de arquivos (em outras palavras, uma única solicitação não ocupa mais uma de suas poucas conexões preciosas). Isso foi originalmente interpretado como “ Não precisamos mais agrupar ou in-line nossos recursos para HTTP/2 ”. Essa abordagem foi considerada melhor para o armazenamento em cache refinado porque cada sub-recurso pode ser armazenado em cache individualmente e o pacote completo não precisa ser baixado novamente se um deles for alterado. Isso é verdade, mas apenas de forma relativamente limitada.

Por exemplo, você pode reduzir a eficiência da compactação, porque isso funciona melhor com mais dados. Além disso, cada solicitação ou arquivo extra tem uma sobrecarga inerente porque precisa ser tratado pelo navegador e pelo servidor. Esses custos podem somar, digamos, centenas de arquivos pequenos em comparação com alguns grandes. Em nossos próprios testes iniciais, encontrei retornos seriamente decrescentes em cerca de 40 arquivos. Embora esses números sejam provavelmente um pouco maiores agora, as solicitações de arquivos ainda não são tão baratas em HTTP/2 como previsto originalmente . Por fim, a não inserção de recursos tem um custo de latência adicional porque o arquivo precisa ser solicitado. Isso, combinado com os problemas de priorização e push do servidor (veja abaixo), significa que ainda hoje você ainda está melhor inline alguns de seus CSS críticos. Talvez um dia a proposta de Pacotes de Recursos ajude nisso, mas ainda não.

Tudo isso, é claro, ainda é verdade para o HTTP/3. Ainda assim, li pessoas afirmando que muitos arquivos pequenos seriam melhores em relação ao QUIC porque fluxos independentes mais ativos simultaneamente significam mais lucros com a remoção do bloqueio de HoL (como discutimos na parte 2). Acho que pode haver alguma verdade nisso, mas, como também vimos na parte 2, essa é uma questão altamente complexa com muitos parâmetros móveis. Não acho que os benefícios superem os outros custos discutidos, mas são necessárias mais pesquisas. (Um pensamento ultrajante seria ter cada arquivo exatamente dimensionado para caber em um único pacote QUIC, ignorando completamente o bloqueio HoL. Eu aceitarei royalties de qualquer startup que implemente um empacotador de recursos que faça isso. ;))

4. Priorização

Para poder baixar vários arquivos em uma única conexão, você precisa multiplexá-los de alguma forma. Conforme discutido na parte 2, no HTTP/2, essa multiplexação é direcionada usando seu sistema de priorização. É por isso que é importante ter o maior número possível de recursos solicitados na mesma conexão - para poder priorizá-los adequadamente entre si! Como também vimos, porém, esse sistema era muito complexo , fazendo com que muitas vezes fosse mal utilizado e implementado na prática (veja a imagem abaixo). Isso, por sua vez, significou que algumas outras recomendações para HTTP/2 — como empacotamento reduzido, porque as solicitações são baratas e fragmentação de servidor reduzida, para fazer o uso ideal da conexão única (veja acima) — tiveram um desempenho inferior em prática.

Infelizmente, isso é algo que você, como um desenvolvedor web comum, não pode fazer muito, porque é principalmente um problema nos próprios navegadores e servidores. Você pode, no entanto, tentar mitigar o problema não usando muitos arquivos individuais (o que diminuirá as chances de prioridades concorrentes) e ainda usando fragmentação (limitada). Outra opção é usar várias técnicas de influência de prioridade, como carregamento lento, JavaScript async e defer e dicas de recursos, como preload . Internamente, estes alteram principalmente as prioridades dos recursos para que sejam enviados mais cedo ou mais tarde. No entanto, esses mecanismos podem (e sofrem) de bugs. Além disso, não espere colocar um preload -carregamento em um monte de recursos e tornar as coisas mais rápidas: se tudo de repente é uma alta prioridade, então nada é! É até muito fácil atrasar recursos realmente críticos usando coisas como preload .

Como também explicado na parte 2, o HTTP/3 altera fundamentalmente os componentes internos desse sistema de priorização. Esperamos que isso signifique que haverá muito menos bugs e problemas com sua implantação prática, então pelo menos parte disso deve ser resolvido. No entanto, ainda não podemos ter certeza, porque poucos servidores e clientes HTTP/3 implementam totalmente esse sistema hoje. No entanto, os conceitos fundamentais de priorização não mudarão . Você ainda não poderá usar técnicas como preload -carregamento sem realmente entender o que acontece internamente, porque ainda pode priorizar incorretamente seus recursos.

5. Servidor Push e Primeiro Voo

O push do servidor permite que um servidor envie dados de resposta sem primeiro aguardar uma solicitação do cliente. Novamente, isso parece ótimo em teoria e pode ser usado em vez de recursos embutidos (veja acima). No entanto, conforme discutido na parte 2, o push é muito difícil de usar corretamente devido a problemas com controle de congestionamento, armazenamento em cache, priorização e armazenamento em buffer. No geral, é melhor não usá-lo para carregamento geral de páginas da Web, a menos que você realmente saiba o que está fazendo e, mesmo assim, provavelmente seria uma micro-otimização. Eu ainda acredito que poderia ter um lugar com APIs (REST), onde você pode enviar sub-recursos vinculados na resposta (JSON) em uma conexão aquecida. Isso vale para HTTP/2 e HTTP/3.

Para generalizar um pouco, sinto que observações semelhantes podem ser feitas para a retomada da sessão TLS e 0-RTT, seja por TCP + TLS ou via QUIC. Conforme discutido na parte 2, o 0-RTT é semelhante ao servidor push (como normalmente é usado), pois tenta acelerar os primeiros estágios de um carregamento de página. No entanto, isso significa que é igualmente limitado no que pode alcançar naquele momento (ainda mais no QUIC, devido a preocupações de segurança). Como tal, uma micro-otimização é, novamente, como você provavelmente precisa ajustar as coisas em um nível baixo para realmente se beneficiar dela. E pensar que uma vez fiquei muito empolgado para experimentar combinar o push do servidor com 0-RTT.

O que tudo isso significa?

Todos os itens acima se resumem a uma simples regra prática: aplique a maioria das recomendações HTTP/2 típicas que você encontra online, mas não as leve ao extremo .

Aqui estão alguns pontos concretos que valem principalmente para HTTP/2 e HTTP/3:

1. Partilhe recursos em cerca de uma a três conexões no caminho crítico (a menos que seus usuários estejam principalmente em redes de baixa largura de banda), usando pré- preconnect e pré dns-prefetch quando necessário.
2. Agrupe sub-recursos logicamente por caminho ou recurso, ou por frequência de alteração. Cinco a dez recursos JavaScript e cinco a dez CSS por página devem ser suficientes. Inlining CSS crítico ainda pode ser uma boa otimização.
3. Use recursos complexos, como preload -carregamento , com moderação.
4. Use um servidor que suporte adequadamente a priorização HTTP/2. Para HTTP/2, recomendo H2O. Apache e NGINX são geralmente OK (embora possam fazer melhor), enquanto Node.js deve ser evitado para HTTP/2. Para HTTP/3, as coisas estão menos claras neste momento (veja abaixo).
5. Certifique-se de que o TLS 1.3 esteja habilitado em seu servidor web HTTP/2.

Como você pode ver, embora esteja longe de ser simples, otimizar páginas para HTTP/3 (e HTTP/2) não é ciência do foguete. O que será mais difícil, no entanto, é configurar corretamente servidores, clientes e ferramentas HTTP/3.

Servidores e Redes

Como você provavelmente já entendeu, QUIC e HTTP/3 são protocolos bastante complexos. Implementá-los do zero envolveria a leitura (e compreensão!) de centenas de páginas espalhadas por mais de sete documentos. Felizmente, várias empresas estão trabalhando em implementações de QUIC e HTTP/3 de código aberto há mais de cinco anos, então temos várias opções maduras e estáveis ​​para escolher.

Alguns dos mais importantes e estáveis ​​incluem o seguinte:

No entanto, muitas (talvez a maioria) dessas implementações cuidam principalmente do material HTTP/3 e QUIC; eles não são realmente servidores web completos por si mesmos . Quando se trata de seus servidores típicos (pense em NGINX, Apache, Node.js), as coisas ficaram um pouco mais lentas, por vários motivos. Primeiro, poucos de seus desenvolvedores estavam envolvidos com HTTP/3 desde o início, e agora eles precisam se atualizar. Muitos ignoram isso usando uma das implementações listadas acima internamente como bibliotecas, mas mesmo essa integração é difícil.

Em segundo lugar, muitos servidores dependem de bibliotecas TLS de terceiros, como o OpenSSL. Isso ocorre, novamente, porque o TLS é muito complexo e precisa ser seguro, portanto, é melhor reutilizar o trabalho verificado e existente. No entanto, embora o QUIC se integre ao TLS 1.3, ele o utiliza de maneiras muito diferentes de como o TLS e o TCP interagem . Isso significa que as bibliotecas TLS precisam fornecer APIs específicas do QUIC, o que seus desenvolvedores há muito tempo relutam ou demoram a fazer. O problema aqui especialmente é o OpenSSL, que adiou o suporte QUIC, mas também é usado por muitos servidores. Esse problema ficou tão grave que a Akamai decidiu iniciar um fork específico do QUIC do OpenSSL, chamado quictls. Embora existam outras opções e soluções alternativas, o suporte ao TLS 1.3 para QUIC ainda é um bloqueador para muitos servidores, e espera-se que permaneça assim por algum tempo.

Segue uma lista parcial de servidores Web completos que você deve poder usar imediatamente, juntamente com seu suporte HTTP/3 atual:

• Apache
  O suporte não está claro no momento. Nada foi anunciado. Provavelmente também precisa do OpenSSL. (Observe que existe uma implementação do Apache Traffic Server.)
• NGINX
  Esta é uma implementação personalizada. Isso é relativamente novo e ainda altamente experimental. Espera-se que ele seja incorporado ao NGINX principal até o final de 2021. Isso é relativamente novo e ainda altamente experimental. Observe que há um patch para executar a biblioteca quiche da Cloudflare também no NGINX, que provavelmente é mais estável por enquanto.
• Node.js
  Isso usa a biblioteca ngtcp2 internamente. Ele está bloqueado pelo progresso do OpenSSL, embora eles planejem mudar para o fork QUIC-TLS para que algo funcione mais cedo.
• IIS
  O suporte não está claro no momento e nada foi anunciado. Provavelmente usará a biblioteca MsQuic internamente, no entanto.
• Hipercorn
  Isso integra aioquic, com suporte experimental.
• Caddie
  Isso usa quic-go, com suporte total.
• H2O
  Isso usa rapidamente, com suporte total.
• Litespeed
  Isso usa LSQUIC, com suporte total.

Observe algumas nuances importantes:

• Mesmo “suporte total” significa “tão bom quanto possível no momento”, não necessariamente “pronto para produção”. Por exemplo, muitas implementações ainda não oferecem suporte total à migração de conexão, 0-RTT, push de servidor ou priorização HTTP/3 .
• Outros servidores não listados, como o Tomcat, (que eu saiba) não fizeram nenhum anúncio ainda.
• Dos servidores da web listados, apenas o Litespeed, o patch NGINX da Cloudflare e o H2O foram feitos por pessoas intimamente envolvidas na padronização QUIC e HTTP/3, portanto, é mais provável que funcionem melhor no início.
  

Como você pode ver, o cenário de servidores ainda não está completo, mas certamente já existem opções para configurar um servidor HTTP/3. No entanto, simplesmente executar o servidor é apenas o primeiro passo. Configurá-lo e o resto da sua rede é mais difícil.

configuração de rede

Conforme explicado na parte 1, o QUIC é executado em cima do protocolo UDP para facilitar a implantação. Isso, no entanto, significa principalmente que a maioria dos dispositivos de rede pode analisar e entender o UDP. Infelizmente, isso não significa que o UDP seja universalmente permitido . Como o UDP é frequentemente usado para ataques e não é crítico para o trabalho normal do dia-a-dia além do DNS, muitas redes (corporativas) e firewalls bloqueiam o protocolo quase inteiramente. Como tal, o UDP provavelmente precisa ser explicitamente permitido de/para seus servidores HTTP/3 . O QUIC pode ser executado em qualquer porta UDP, mas espera-se que a porta 443 (que normalmente também é usada para HTTPS sobre TCP) seja a mais comum.

No entanto, muitos administradores de rede não desejarão apenas permitir o atacado de UDP. Em vez disso, eles desejarão especificamente permitir o QUIC sobre o UDP. O problema é que, como vimos, o QUIC é quase totalmente criptografado. Isso inclui metadados de nível QUIC, como números de pacotes, mas também, por exemplo, sinais que indicam o fechamento de uma conexão. Para TCP, os firewalls rastreiam ativamente todos esses metadados para verificar o comportamento esperado. (Vimos um handshake completo antes dos pacotes de transporte de dados? Os pacotes seguem os padrões esperados? Quantas conexões abertas existem?) Como vimos na parte 1, essa é exatamente uma das razões pelas quais o TCP não é mais praticamente evolutivo. No entanto, devido à criptografia do QUIC, os firewalls podem fazer muito menos essa lógica de rastreamento em nível de conexão e os poucos bits que podem inspecionar são relativamente complexos.

Como tal, muitos fornecedores de firewall atualmente recomendam bloquear o QUIC até que possam atualizar seu software. Mesmo depois disso, porém, muitas empresas podem não permitir isso, porque o suporte do firewall QUIC sempre será muito menor do que os recursos TCP aos quais estão acostumados.

Tudo isso é ainda mais complicado pelo recurso de migração de conexão. Como vimos, esse recurso permite que a conexão continue a partir de um novo endereço IP sem precisar realizar um novo handshake, por meio de IDs de conexão (CIDs). No entanto, para o firewall, isso parecerá que uma nova conexão está sendo usada sem primeiro usar um handshake, que pode ser um invasor enviando tráfego malicioso. Os firewalls não podem usar apenas os QUIC CIDs, pois eles também mudam ao longo do tempo para proteger a privacidade dos usuários! Como tal, haverá alguma necessidade de os servidores se comunicarem com o firewall sobre quais CIDs são esperados , mas nenhuma dessas coisas existe ainda.

Existem preocupações semelhantes para balanceadores de carga para configurações de grande escala. Essas máquinas distribuem conexões de entrada em um grande número de servidores back-end. O tráfego de uma conexão deve, é claro, sempre ser roteado para o mesmo servidor de back-end (os outros não saberiam o que fazer com ele!). Para TCP, isso poderia ser feito simplesmente com base na tupla de 4, porque isso nunca muda. Com a migração de conexão QUIC, no entanto, isso não é mais uma opção. Novamente, servidores e balanceadores de carga precisarão concordar de alguma forma sobre quais CIDs escolher para permitir o roteamento determinístico . Ao contrário da configuração de firewall, no entanto, já existe uma proposta para configurar isso (embora isso esteja longe de ser amplamente implementado).

Finalmente, há outras considerações de segurança de nível superior, principalmente em torno de 0-RTT e ataques distribuídos de negação de serviço (DDoS). Conforme discutido na parte 2, o QUIC já inclui algumas mitigações para esses problemas, mas, idealmente, eles também usarão linhas extras de defesa na rede. Por exemplo, servidores proxy ou de borda podem impedir que determinadas solicitações 0-RTT alcancem os back-ends reais para evitar ataques de repetição. Como alternativa, para evitar ataques de reflexão ou ataques DDoS que enviam apenas o primeiro pacote de handshake e, em seguida, param de responder (chamado de inundação SYN no TCP), o QUIC inclui o recurso de repetição. Isso permite que o servidor valide que é um cliente bem comportado, sem ter que manter nenhum estado nesse meio tempo (o equivalente aos cookies TCP SYN). Esse processo de repetição acontece melhor, é claro, em algum lugar antes do servidor de back-end — por exemplo, no balanceador de carga. Novamente, isso requer configuração e comunicação adicionais para configurar.

Esses são apenas os problemas mais importantes que os administradores de rede e sistema terão com QUIC e HTTP/3. Existem vários outros, alguns dos quais eu já falei. Há também dois documentos de acompanhamento separados para os RFCs QUIC que discutem essas questões e suas possíveis mitigações (parciais).

O que tudo isso significa?

HTTP/3 e QUIC são protocolos complexos que dependem de muitos mecanismos internos. Nem tudo isso está pronto para o horário nobre ainda , embora você já tenha algumas opções para implantar os novos protocolos em seus back-ends. No entanto, provavelmente levará alguns meses ou até anos para que os servidores e bibliotecas subjacentes mais proeminentes (como OpenSSL) sejam atualizados.

Mesmo assim, configurar adequadamente os servidores e outros intermediários de rede, para que os protocolos possam ser usados ​​de maneira segura e otimizada, não será trivial em configurações de grande escala. Você precisará de uma boa equipe de desenvolvimento e operações para fazer essa transição corretamente.

Como tal, especialmente nos primeiros dias, provavelmente é melhor confiar em uma grande empresa de hospedagem ou CDN para configurar e configurar os protocolos para você. Conforme discutido na parte 2, é aí que o QUIC tem maior probabilidade de compensar, e usar um CDN é uma das principais otimizações de desempenho que você pode fazer. Eu pessoalmente recomendaria usar Cloudflare ou Fastly porque eles estiveram intimamente envolvidos no processo de padronização e terão as implementações mais avançadas e bem ajustadas disponíveis.

Clientes e QUIC Discovery

Até agora, consideramos o suporte no lado do servidor e na rede para os novos protocolos. No entanto, vários problemas também devem ser superados do lado do cliente.

Antes de chegar a isso, vamos começar com algumas boas notícias: A maioria dos navegadores populares já tem suporte (experimental) HTTP/3! Especificamente, no momento da redação, aqui está o status do suporte (consulte também caniuse.com):

• Google Chrome (versão 91+) : ativado por padrão.
• Mozilla Firefox (versão 89+) : Ativado por padrão.
• Microsoft Edge (versão 90+) : habilitado por padrão (usa o Chromium internamente).
• Opera (versão 77+) : ativado por padrão (usa o Chromium internamente).
• Apple Safari (versão 14) : Atrás de um sinalizador manual. Será habilitado por padrão na versão 15, que está atualmente em pré-visualização de tecnologia.
• Outros navegadores : Ainda não há sinais que eu conheça (embora outros navegadores que usam o Chromium internamente, como o Brave, possam, em teoria, também começar a habilitá-lo).

Observe algumas nuances:

• A maioria dos navegadores está sendo lançada gradualmente, e nem todos os usuários terão o suporte HTTP/3 ativado por padrão desde o início. Isso é feito para limitar os riscos de que um único bug negligenciado possa afetar muitos usuários ou que as implantações de servidor fiquem sobrecarregadas. Como tal, há uma pequena chance de que, mesmo em versões recentes do navegador, você não obtenha o HTTP/3 por padrão e tenha que habilitá-lo manualmente.
• Assim como nos servidores, o suporte HTTP/3 não significa que todos os recursos foram implementados ou estão sendo usados ​​no momento. Particularmente, 0-RTT, migração de conexão, push de servidor, compactação dinâmica de cabeçalho QPACK e priorização HTTP/3 ainda podem estar ausentes, desabilitados, usados ​​com moderação ou mal configurados.
• Se você quiser usar HTTP/3 do lado do cliente fora do navegador (por exemplo, em seu aplicativo nativo), precisará integrar uma das bibliotecas listadas acima ou usar cURL. A Apple em breve trará suporte nativo HTTP/3 e QUIC para suas bibliotecas de rede integradas no macOS e iOS, e a Microsoft está adicionando QUIC ao kernel do Windows e seu ambiente .NET, mas suporte nativo semelhante (que eu saiba) não foi anunciado para outros sistemas como o Android.

Alt-Svc

Mesmo se você tiver configurado um servidor compatível com HTTP/3 e estiver usando um navegador atualizado, poderá se surpreender ao descobrir que o HTTP/3 não está sendo usado de forma consistente . Para entender o porquê, vamos supor que você seja o navegador por um momento. Seu usuário solicitou que você navegue até example.com (um site que você nunca visitou antes) e você usou o DNS para resolver isso para um IP. Você envia um ou mais pacotes de handshake QUIC para esse IP. Agora várias coisas podem dar errado:

1. O servidor pode não suportar QUIC.
2. Uma das redes ou firewalls intermediários pode bloquear completamente o QUIC e/ou UDP.
3. Os pacotes de handshake podem ser perdidos em trânsito.

No entanto, como você saberia (qual) um desses problemas ocorreu ? Em todos os três casos, você nunca receberá uma resposta ao(s) seu(s) pacote(s) de handshake. A única coisa que você pode fazer é esperar, esperando que uma resposta ainda chegue. Então, depois de algum tempo de espera (o tempo limite), você pode decidir que há realmente um problema com o HTTP/3. Nesse ponto, você tentaria abrir uma conexão TCP com o servidor, esperando que HTTP/2 ou HTTP/1.1 funcionem.

Como você pode ver, esse tipo de abordagem pode causar grandes atrasos, especialmente nos anos iniciais, quando muitos servidores e redes ainda não oferecem suporte ao QUIC. Uma solução fácil, mas ingênua, seria simplesmente abrir uma conexão QUIC e TCP ao mesmo tempo e, em seguida, usar o handshake que for concluído primeiro . Este método é chamado de “corrida de conexão” ou “olhos felizes”. Embora isso seja certamente possível, ele tem uma sobrecarga considerável. Mesmo que a conexão perdida seja quase imediatamente fechada, ela ainda ocupa um pouco de memória e tempo de CPU no cliente e no servidor (especialmente ao usar TLS). Além disso, há também outros problemas com esse método envolvendo redes IPv4 versus IPv6 e os ataques de repetição discutidos anteriormente (que minha palestra aborda com mais detalhes).

Como tal, para QUIC e HTTP/3, os navegadores preferem jogar pelo seguro e apenas tentar o QUIC se souberem que o servidor o suporta . Assim, na primeira vez que um novo servidor for contatado, o navegador usará apenas HTTP/2 ou HTTP/1.1 em uma conexão TCP. O servidor pode então informar ao navegador que também suporta HTTP/3 para conexões subsequentes. Isso é feito definindo um cabeçalho HTTP especial nas respostas enviadas de volta por HTTP/2 ou HTTP/1.1. Este cabeçalho é chamado Alt-Svc , que significa “serviços alternativos”. Alt-Svc pode ser usado para informar a um navegador que um determinado serviço também está acessível através de outro servidor (IP e/ou porta), mas também permite a indicação de protocolos alternativos. Isso pode ser visto abaixo na figura 1.

Após o recebimento de um cabeçalho Alt-Svc válido indicando suporte a HTTP/3, o navegador o armazenará em cache e tentará configurar uma conexão QUIC a partir de então. Alguns clientes farão isso o mais rápido possível (mesmo durante o carregamento inicial da página — veja abaixo), enquanto outros esperarão até que as conexões TCP existentes sejam fechadas. Isso significa que o navegador só usará HTTP/3 depois de baixar pelo menos alguns recursos via HTTP/2 ou HTTP/1.1 primeiro . Mesmo assim, não é fácil navegar. O navegador agora sabe que o servidor suporta HTTP/3, mas isso não significa que a rede intermediária não irá bloqueá-lo. Como tal, as corridas de conexão ainda são necessárias na prática. Portanto, você ainda pode acabar com HTTP/2 se a rede atrasar o handshake QUIC o suficiente. Além disso, se a conexão QUIC não for estabelecida algumas vezes seguidas, alguns navegadores colocarão a entrada de cache Alt-Svc em uma lista de negação por algum tempo, sem tentar HTTP/3 por um tempo. Como tal, pode ser útil limpar manualmente o cache do seu navegador se as coisas estiverem funcionando, porque isso também deve esvaziar as ligações Alt-Svc . Finalmente, Alt-Svc demonstrou apresentar alguns sérios riscos de segurança. Por esse motivo, alguns navegadores impõem restrições extras sobre, por exemplo, quais portas podem ser usadas (no Chrome, seus servidores HTTP/2 e HTTP/3 precisam estar ambos em uma porta abaixo de 1024 ou ambos em uma porta acima ou igual para 1024, caso contrário, Alt-Svc será ignorado). Toda essa lógica varia e evolui muito entre os navegadores, o que significa que obter conexões HTTP/3 consistentes pode ser difícil , o que também dificulta o teste de novas configurações.

Há um trabalho em andamento para melhorar um pouco esse processo Alt-Svc duas etapas. A ideia é usar novos registros DNS chamados SVCB e HTTPS, que conterão informações semelhantes ao que está em Alt-Svc . Como tal, o cliente pode descobrir que um servidor suporta HTTP/3 durante a etapa de resolução de DNS, o que significa que ele pode tentar o QUIC desde o primeiro carregamento de página em vez de primeiro ter que passar por HTTP/2 ou HTTP/1.1. Para obter mais informações sobre isso e Alt-Svc , consulte o capítulo Web Almanac do ano passado sobre HTTP/2.

Como você pode ver, Alt-Svc e o processo de descoberta HTTP/3 adicionam uma camada de complexidade à sua já desafiadora implantação de servidor QUIC, porque:

• você sempre precisará implantar seu servidor HTTP/3 próximo a um servidor HTTP/2 e/ou HTTP/1.1;
• você precisará configurar seus servidores HTTP/2 e HTTP/1.1 para definir os cabeçalhos Alt-Svc corretos em suas respostas.

Embora isso deva ser gerenciável em configurações de nível de produção (porque, por exemplo, uma única instância Apache ou NGINX provavelmente suportará todas as três versões HTTP ao mesmo tempo), pode ser muito mais irritante em configurações de teste (locais) ups (já posso me ver esquecendo de adicionar os cabeçalhos Alt-Svc ou bagunçando-os). Esse problema é agravado pela (atualmente) falta de logs de erros do navegador e indicadores do DevTools, o que significa que descobrir por que exatamente a configuração não está funcionando pode ser difícil.

Problemas adicionais

Como se isso não bastasse, outro problema dificultará os testes locais: o Chrome dificulta muito o uso de certificados TLS autoassinados para QUIC . Isso ocorre porque os certificados TLS não oficiais são frequentemente usados ​​por empresas para descriptografar o tráfego TLS de seus funcionários (para que eles possam, por exemplo, fazer com que seus firewalls verifiquem o tráfego criptografado). No entanto, se as empresas começassem a fazer isso com o QUIC, teríamos novamente implementações de middlebox personalizadas que fazem suas próprias suposições sobre o protocolo. Isso pode levá-los a quebrar o suporte de protocolo no futuro, o que é exatamente o que tentamos evitar criptografando o QUIC tão extensivamente em primeiro lugar! As such, Chrome takes a very opinionated stance on this: If you're not using an official TLS certificate (signed by a certificate authority or root certificate that is trusted by Chrome, such as Let's Encrypt), then you cannot use QUIC . This, sadly, also includes self-signed certificates, which are often used for local test set-ups.

It is still possible to bypass this with some freaky command-line flags (because the common --ignore-certificate-errors doesn't work for QUIC yet), by using per-developer certificates (although setting this up can be tedious), or by setting up the real certificate on your development PC (but this is rarely an option for big teams because you would have to share the certificate's private key with each developer). Finally, while you can install a custom root certificate, you would then also need to pass both the --origin-to-force-quic-on and --ignore-certificate-errors-spki-list flags when starting Chrome (see below). Luckily, for now, only Chrome is being so strict, and hopefully, its developers will loosen their approach over time.

If you are having problems with your QUIC set-up from inside a browser, it's best to first validate it using a tool such as cURL. cURL has excellent HTTP/3 support (you can even choose between two different underlying libraries) and also makes it easier to observe Alt-Svc caching logic.

O que tudo isso significa?

Next to the challenges involved with setting up HTTP/3 and QUIC on the server-side, there are also difficulties in getting browsers to use the new protocols consistently. This is due to a two-step discovery process involving the Alt-Svc HTTP header and the fact that HTTP/2 connections cannot simply be “upgraded” to HTTP/3, because the latter uses UDP.

Even if a server supports HTTP/3, however, clients (and website owners!) need to deal with the fact that intermediate networks might block UDP and/or QUIC traffic. As such, HTTP/3 will never completely replace HTTP/2 . In practice, keeping a well-tuned HTTP/2 set-up will remain necessary both for first-time visitors and visitors on non-permissive networks. Luckily, as we discussed, there shouldn't be many page-level changes between HTTP/2 and HTTP/3, so this shouldn't be a major headache.

What could become a problem, however, is testing and verifying whether you are using the correct configuration and whether the protocols are being used as expected. This is true in production, but especially in local set-ups. As such, I expect that most people will continue to run HTTP/2 (or even HTTP/1.1) development servers , switching only to HTTP/3 in a later deployment stage. Even then, however, validating protocol performance with the current generation of tools won't be easy.

Tools and Testing

As was the case with many major servers, the makers of the most popular web performance testing tools have not been keeping up with HTTP/3 from the start. Consequently, few tools have dedicated support for the new protocol as of July 2021, although they support it to a certain degree.

Farol do Google

First, there is the Google Lighthouse tool suite. While this is an amazing tool for web performance in general, I have always found it somewhat lacking in aspects of protocol performance. This is mostly because it simulates slow networks in a relatively unrealistic way, in the browser (the same way that Chrome's DevTools handle this). While this approach is quite usable and typically “good enough” to get an idea of the impact of a slow network, testing low-level protocol differences is not realistic enough. Because the browser doesn't have direct access to the TCP stack, it still downloads the page on your normal network, and it then artificially delays the data from reaching the necessary browser logic. This means, for example, that Lighthouse emulates only delay and bandwidth, but not packet loss (which, as we've seen, is a major point where HTTP/3 could potentially differ from HTTP/2). Alternatively, Lighthouse uses a highly advanced simulation model to guesstimate the real network impact, because, for example, Google Chrome has some complex logic that tweaks several aspects of a page load if it detects a slow network. This model has, to the best of my knowledge, not been adjusted to handle IETF QUIC or HTTP/3 yet. As such, if you use Lighthouse today for the sole purpose of comparing HTTP/2 and HTTP/3 performance, then you are likely to get erroneous or oversimplified results, which could lead you to wrong conclusions about what HTTP/3 can do for your website in practice. The silver lining is that, in theory, this can be improved massively in the future, because the browser does have full access to the QUIC stack, and thus Lighthouse could add much more advanced simulations (including packet loss!) for HTTP/3 down the line. For now, though, while Lighthouse can, in theory, load pages over HTTP/3, I would recommend against it.

WebPageTest

Secondly, there is WebPageTest. This amazing project lets you load pages over real networks from real devices across the world, and it also allows you to add packet-level network emulation on top, including aspects such as packet loss! As such, WebPageTest is conceptually in a prime position to be used to compare HTTP/2 and HTTP/3 performance. However, while it can indeed already load pages over the new protocol, HTTP/3 has not yet been properly integrated into the tooling or visualizations . For example, there are currently no easy ways to force a page load over QUIC, to easily view how Alt-Svc was actually used, or even to see QUIC handshake details. In some cases, even seeing whether a response used HTTP/3 or HTTP/2 can be challenging. Still, in April, I was able to use WebPageTest to run quite a few tests on facebook.com and see HTTP/3 in action, which I'll go over now.

First, I ran a default test for facebook.com , enabling the “repeat view” option. As explained above, I would expect the first page load to use HTTP/2, which will include the Alt-Svc response header. As such, the repeat view should use HTTP/3 from the start. In Firefox version 89, this is more or less what happens. However, when looking at individual responses, we see that even during the first page load, Firefox will switch to using HTTP/3 instead of HTTP/2 ! As you can see in figure 2, this happens from the 20th resource onwards. This means that Firefox establishes a new QUIC connection as soon as it sees the Alt-Svc header, and it switches to it once it succeeds. If you scroll down to the connection view, it also seems to show that Firefox even opened two QUIC connections: one for credentialed CORS requests and one for no-CORS requests. This would be expected because, as we discussed above, even for HTTP/2 and HTTP/3, browsers will open multiple connections due to security concerns. However, because WebPageTest doesn't provide more details in this view, it's difficult to confirm without manually digging through the data. Looking at the repeat view (second visit), it starts by directly using HTTP/3 for the first request, as expected.

Next, for Chrome, we see similar behavior for the first page load, although here Chrome already switches on the 10th resource, much earlier than Firefox. It's a bit more unclear here whether it switches as soon as possible or only when a new connection is needed (for example, for requests with different credentials), because, unlike for Firefox, the connection view also doesn't seem to show multiple QUIC connections. For the repeat view, we see some weirder things. Unexpectedly, Chrome starts off using HTTP/2 there as well , switching to HTTP/3 only after a few requests! I performed a few more tests on other pages as well, to confirm that this is indeed consistent behaviour. This could be due to several things: It might just be Chrome's current policy, it might be that Chrome “raced” a TCP and QUIC connection and TCP won initially, or it might be that the Alt-Svc cache from the first view was unused for some reason. At this point, there is, sadly, no easy way to determine what the problem really is (and whether it can even be fixed).

Another interesting thing I noticed here is the apparent connection coalescing behavior. As discussed above, both HTTP/2 and HTTP/3 can reuse connections even if they go to other hostnames, to prevent downsides from hostname sharding. However, as shown in figure 3, WebPageTest reports that, for this Facebook load, connection coalescing is used over HTTP/3 for facebook.com and fbcdn.net , but not over HTTP/2 (as Chrome opens a secondary connection for the second domain). I suspect this is a bug in WebPageTest, however, because facebook.com and fbcnd.net resolve to different IPs and, as such, can't really be coalesced.

The figure also shows that some key QUIC handshake information is missing from the current WebPageTest visualization.

Note : As we see, getting “real” HTTP/3 going can be difficult sometimes. Luckily, for Chrome specifically, we have additional options we can use to test QUIC and HTTP/3, in the form of command-line parameters.

On the bottom of WebPageTest's “Chromium” tab, I used the following command-line options:

 --enable-quic --quic-version=h3-29 --origin-to-force-quic-on=www.facebook.com:443,static.xx.fbcdn.net:443

The results from this test show that this indeed forces a QUIC connection from the start, even in the first view, thus bypassing the Alt-Svc process. Interestingly, you will notice I had to pass two hostnames to --origin-to-force-quic-on . In the version where I didn't, Chrome, of course, still first opened an HTTP/2 connection to the fbcnd.net domain, even in the repeat view. As such, you'll need to manually indicate all QUIC origins in order for this to work !

We can see even from these few examples that a lot of stuff is going on with how browsers actually use HTTP/3 in practice. It seems they even switch to the new protocol during the initial page load, abandoning HTTP/2 either as soon as possible or when a new connection is needed. As such, it's difficult not only getting a full HTTP/3 load, but also getting a pure HTTP/2 load on a set-up that supports both ! Because WebPageTest doesn't show much HTTP/3 or QUIC metadata yet, figuring out what's going on can be challenging, and you can't trust the tools and visualizations at face value either.

So, if you use WebPageTest, you'll need to double-check the results to make sure which protocols were actually used. Consequently, I think this means that it's too early to really test HTTP/3 performance at this time (and especially too early to compare it to HTTP/2). This belief is strengthened by the fact that not all servers and clients have implemented all protocol features yet. Due to the fact that WebPageTest doesn't yet have easy ways of showing whether advanced aspects such as 0-RTT were used, it will be tricky to know what you're actually measuring. This is especially true for the HTTP/3 prioritization feature, which isn't implemented properly in all browsers yet and which many servers also lack full support for. Because prioritization can be a major aspect driving web performance, it would be unfair to compare HTTP/3 to HTTP/2 without making sure that at least this feature works properly (for both protocols!). This is just one aspect, though, as my research shows how big the differences between QUIC implementations can be. If you do any comparison of this sort yourself (or if you read articles that do), make 100% sure that you've checked what's actually going on .

Finally, also note that other higher-level tools (or data sets such as the amazing HTTP Archive) are often based on WebPageTest or Lighthouse (or use similar methods), so I suspect that most of my comments here will be widely applicable to most web performance tooling. Even for those tool vendors announcing HTTP/3 support in the coming months, I would be a bit skeptical and would validate that they're actually doing it correctly. For some tools, things are probably even worse, though; for example, Google's PageSpeed Insights only got HTTP/2 support this year, so I wouldn't wait for HTTP/3 arriving anytime soon.

Wireshark, qlog e qvis

Como a discussão acima mostra, pode ser complicado analisar o comportamento do HTTP/3 usando apenas o Lighthouse ou o WebPageTest neste momento. Felizmente, outras ferramentas de nível inferior estão disponíveis para ajudar com isso. Primeiro, a excelente ferramenta Wireshark tem suporte avançado para QUIC e também pode dissecar experimentalmente o HTTP/3. Isso permite que você observe quais pacotes QUIC e HTTP/3 estão realmente passando pela rede. No entanto, para que isso funcione, você precisa obter as chaves de descriptografia TLS para uma determinada conexão, que a maioria das implementações (incluindo Chrome e Firefox) permite extrair usando a variável de ambiente SSLKEYLOGFILE . Embora isso possa ser útil para algumas coisas, descobrir realmente o que está acontecendo, especialmente para conexões mais longas, pode exigir muito trabalho manual. Você também precisaria de uma compreensão bastante avançada do funcionamento interno dos protocolos.

Felizmente, existe uma segunda opção, qlog e qvis. qlog é um formato de registro baseado em JSON especificamente para QUIC e HTTP/3 que é suportado pela maioria das implementações de QUIC. Em vez de olhar para os pacotes que passam pela rede, o qlog captura essas informações diretamente no cliente e no servidor, o que permite incluir algumas informações adicionais (por exemplo, detalhes de controle de congestionamento). Normalmente, você pode acionar a saída qlog ao iniciar servidores e clientes com a variável de ambiente QLOGDIR . (Observe que no Firefox, você precisa definir a preferência network.http.http3.enable_qlog . Dispositivos Apple e Safari usam QUIC_LOG_DIRECTORY . O Chrome ainda não suporta qlog.)

Esses arquivos qlog podem então ser carregados para o conjunto de ferramentas qvis em qvis.quictools.info. Lá, você terá várias visualizações interativas avançadas que facilitam a interpretação do tráfego QUIC e HTTP/3 . qvis também tem suporte para upload de capturas de pacotes Wireshark (arquivos .pcap ), e tem suporte experimental para arquivos de netlog do Chrome, então você também pode analisar o comportamento do Chrome. Um tutorial completo sobre qlog e qvis está além do escopo deste artigo, mas mais detalhes podem ser encontrados em forma de tutorial, como um papel, e até mesmo em formato de talk show. Você também pode me perguntar sobre eles diretamente porque eu sou o principal implementador de qlog e qvis. ;)

No entanto, não tenho a ilusão de que a maioria dos leitores aqui deve usar Wireshark ou qvis, porque essas são ferramentas de nível bastante baixo. Ainda assim, como temos poucas alternativas no momento, recomendo fortemente não testar extensivamente o desempenho do HTTP/3 sem usar esse tipo de ferramenta , para ter certeza de que você realmente sabe o que está acontecendo na rede e se o que está vendo é realmente explicado por internos do protocolo e não por outros fatores.

O que tudo isso significa?

Como vimos, configurar e usar HTTP/3 sobre QUIC pode ser uma tarefa complexa e muitas coisas podem dar errado. Infelizmente, nenhuma boa ferramenta ou visualização está disponível que exponha os detalhes necessários em um nível apropriado de abstração. Isso torna muito difícil para a maioria dos desenvolvedores avaliar os benefícios potenciais que o HTTP/3 pode trazer para seu site neste momento ou até mesmo validar se sua configuração funciona conforme o esperado.

Confiar apenas em métricas de alto nível é muito perigoso porque elas podem ser distorcidas por uma infinidade de fatores (como emulação de rede irreal, falta de recursos em clientes ou servidores, uso parcial de HTTP/3 etc.). Mesmo que tudo funcionasse melhor, como vimos na parte 2, as diferenças entre HTTP/2 e HTTP/3 provavelmente serão relativamente pequenas na maioria dos casos, o que torna ainda mais difícil obter as informações necessárias de alto nível ferramentas sem suporte HTTP/3 direcionado.

Como tal, recomendo deixar as medições de desempenho HTTP/2 versus HTTP/3 em paz por mais alguns meses e focar em garantir que nossas configurações do lado do servidor estejam funcionando conforme o esperado . Para isso, é mais fácil usar o WebPageTest em combinação com os parâmetros de linha de comando do Google Chrome, com um fallback para corrigir possíveis problemas - essa é atualmente a configuração mais consistente que posso encontrar.

Conclusão e conclusões

Caro leitor, se você leu a série completa de três partes e chegou até aqui, eu o saúdo ! Mesmo que você tenha lido apenas algumas seções, agradeço seu interesse por esses novos e empolgantes protocolos. Agora, vou resumir as principais conclusões desta série, fornecer algumas recomendações importantes para os próximos meses e anos e, finalmente, fornecer alguns recursos adicionais, caso você queira saber mais.

Resumo

Primeiro, na parte 1, discutimos que o HTTP/3 era necessário principalmente por causa do novo protocolo de transporte QUIC subjacente . O QUIC é o sucessor espiritual do TCP e integra todas as suas melhores práticas, bem como o TLS 1.3. Isso foi necessário principalmente porque o TCP, devido à sua implantação e integração onipresentes em middleboxes, tornou-se muito inflexível para evoluir. O uso de UDP e criptografia quase completa do QUIC significa que (espero) só precisamos atualizar os terminais no futuro para adicionar novos recursos, o que deve ser mais fácil. O QUIC, no entanto, também adiciona alguns novos recursos interessantes. Primeiro, o transporte combinado e o handshake criptográfico do QUIC são mais rápidos que o TCP + TLS e podem fazer bom uso do recurso 0-RTT. Em segundo lugar, o QUIC sabe que está transportando vários fluxos de bytes independentes e pode ser mais inteligente sobre como lida com perdas e atrasos, mitigando o problema de bloqueio de cabeçalho. Em terceiro lugar, as conexões QUIC podem sobreviver aos usuários que se deslocam para uma rede diferente (chamada migração de conexão) marcando cada pacote com um ID de conexão. Finalmente, a estrutura de pacotes flexível do QUIC (empregando quadros) o torna mais eficiente, mas também mais flexível e extensível no futuro. Concluindo, está claro que o QUIC é o protocolo de transporte da próxima geração e será usado e estendido por muitos anos .

Em segundo lugar, na parte 2, analisamos de forma crítica esses novos recursos, especialmente suas implicações de desempenho . Primeiro, vimos que o uso do UDP pelo QUIC não o torna magicamente mais rápido (nem mais lento) porque o QUIC usa mecanismos de controle de congestionamento muito semelhantes ao TCP para evitar a sobrecarga da rede. Em segundo lugar, o handshake mais rápido e o 0-RTT são mais micro-otimizações, porque eles são realmente apenas uma viagem de ida e volta mais rápido do que uma pilha TCP + TLS otimizada, e o verdadeiro 0-RTT do QUIC é ainda mais afetado por uma série de preocupações de segurança que podem limitar sua utilidade. Em terceiro lugar, a migração de conexão é realmente necessária apenas em alguns casos específicos, e ainda significa redefinir as taxas de envio porque o controle de congestionamento não sabe quantos dados a nova rede pode manipular. Em quarto lugar, a eficácia da remoção do bloqueio de cabeça de linha do QUIC depende severamente de como os dados de fluxo são multiplexados e priorizados. As abordagens que são ótimas para se recuperar da perda de pacotes parecem prejudiciais para casos de uso geral de desempenho de carregamento de páginas da Web e vice-versa, embora sejam necessárias mais pesquisas. Em quinto lugar, o QUIC pode ser facilmente mais lento para enviar pacotes do que o TCP + TLS, porque as APIs UDP são menos maduras e o QUIC criptografa cada pacote individualmente, embora isso possa ser amplamente mitigado com o tempo. Em sexto lugar, o próprio HTTP/3 não traz nenhum novo recurso de desempenho importante para a mesa, mas principalmente retrabalha e simplifica os recursos internos de recursos HTTP/2 conhecidos. Finalmente, alguns dos recursos mais interessantes relacionados ao desempenho que o QUIC permite (multipath, dados não confiáveis, WebTransport, correção de erros de encaminhamento, etc.) mais algum tempo para estar disponível. Em conclusão, isso significa que o QUIC provavelmente não melhorará muito o desempenho para usuários em redes de alta velocidade, mas será importante principalmente para aqueles em redes lentas e menos estáveis .

Por fim, nesta parte 3, vimos como usar e implantar de forma prática o QUIC e o HTTP/3 . Primeiro, vimos que a maioria das práticas recomendadas e lições aprendidas do HTTP/2 deveriam ser transferidas para o HTTP/3. Não há necessidade de alterar sua estratégia de empacotamento ou inlining, nem de consolidar ou fragmentar seu farm de servidores. O push do servidor ainda não é o melhor recurso a ser usado, e o preload -carregamento também pode ser uma arma poderosa. Em segundo lugar, discutimos que pode demorar um pouco até que os pacotes de servidor web prontos para uso forneçam suporte total a HTTP/3 (em parte devido a problemas de suporte à biblioteca TLS), embora muitas opções de código aberto estejam disponíveis para os primeiros usuários e vários CDNs importantes têm uma oferta madura. Em terceiro lugar, está claro que a maioria dos principais navegadores tem suporte HTTP/3 (básico), mesmo habilitado por padrão. No entanto, existem grandes diferenças em como e quando eles usam o HTTP/3 e seus novos recursos, portanto, entender seu comportamento pode ser um desafio. Em quarto lugar, discutimos que isso é agravado pela falta de suporte explícito a HTTP/3 em ferramentas populares como Lighthouse e WebPageTest, tornando especialmente difícil comparar o desempenho de HTTP/3 com HTTP/2 e HTTP/1.1 neste momento. Concluindo, HTTP/3 e QUIC provavelmente ainda não estão prontos para o horário nobre, mas em breve estarão .

Recomendações

A partir do resumo acima, pode parecer que estou apresentando fortes argumentos contra o uso de QUIC ou HTTP/3. No entanto, isso é completamente oposto ao ponto que quero fazer.

Primeiro, conforme discutido no final da parte 2, mesmo que seu usuário “médio” possa não obter grandes ganhos de desempenho (dependendo do seu mercado-alvo), uma parte significativa de seu público provavelmente verá melhorias impressionantes . 0-RTT pode salvar apenas uma única viagem de ida e volta, mas isso ainda pode significar várias centenas de milissegundos para alguns usuários. A migração de conexão pode não sustentar downloads consistentemente rápidos, mas definitivamente ajudará as pessoas que tentam buscar esse PDF em um trem de alta velocidade. A perda de pacotes no cabo pode ocorrer em rajadas, mas os links sem fio podem se beneficiar mais com a remoção do bloqueio de cabeça de linha do QUIC. Além disso, esses usuários são aqueles que normalmente encontrariam o pior desempenho do seu produto e, consequentemente, seriam mais afetados por ele. Se você se pergunta por que isso é importante, leia a famosa anedota de desempenho na web de Chris Zacharias.

Em segundo lugar, QUIC e HTTP/3 só ficarão melhores e mais rápidos com o tempo . A versão 1 se concentrou em realizar o protocolo básico, mantendo recursos de desempenho mais avançados para mais tarde. Como tal, acho que vale a pena começar a investir nos protocolos agora, para garantir que você possa usá-los e os novos recursos com o melhor efeito quando estiverem disponíveis no futuro. Dada a complexidade dos protocolos e seus aspectos de implantação, seria bom dedicar algum tempo para se familiarizar com suas peculiaridades. Mesmo que você ainda não queira sujar as mãos, vários dos principais provedores de CDN oferecem suporte HTTP/3 maduro para “virar o interruptor” (particularmente, Cloudflare e Fastly). Eu me esforço para encontrar uma razão para não tentar isso se você estiver usando um CDN (o que, se você se preocupa com o desempenho, realmente deveria estar).

Como tal, embora eu não diga que é crucial começar a usar QUIC e HTTP/3 o mais rápido possível, sinto que já existem muitos benefícios a serem obtidos, e eles só aumentarão no futuro .

Leitura adicional

Embora este tenha sido um longo corpo de texto, infelizmente, ele realmente apenas arranha a superfície técnica dos protocolos complexos que são QUIC e HTTP/3.

Abaixo, você encontrará uma lista de recursos adicionais para aprendizado contínuo, mais ou menos em ordem crescente de profundidade técnica:

• “HTTP/3 explicado”, Daniel Stenberg
  Este e-book, do criador do cURL, resume o protocolo.
• “HTTP/2 em ação”, Barry Pollard
  Este excelente livro completo sobre HTTP/2 tem conselhos reutilizáveis ​​e uma seção sobre HTTP/3.
• @programmingart, Twitter
  Meus tweets são principalmente dedicados a QUIC, HTTP/3 e desempenho na web (incluindo notícias) em geral. Veja, por exemplo, meus tópicos recentes sobre recursos QUIC.
• “YouTube”, Robin Marx
  Minhas mais de 10 palestras em profundidade cobrem vários aspectos dos protocolos.
• “O Blog Cloudlare”
  Este é o principal produto de uma empresa que também administra uma CDN paralelamente.
• “O Blog Fastly”
  Este blog tem excelentes discussões de aspectos técnicos, inseridos no contexto mais amplo.
• QUIC, os RFCs reais
  Você encontrará links para os documentos IETF QUIC e HTTP/3 RFC e outras extensões oficiais.
• Blog do IIJ Engineers: Excelentes explicações técnicas profundas dos detalhes do recurso QUIC.
• Artigos acadêmicos HTTP/3 e QUIC, Robin Marx
  Meus trabalhos de pesquisa cobrem multiplexação de fluxo e priorização, ferramentas e diferenças de implementação.
• QUIPS, EPIQ 2018 e EPIQ 2020
  Esses documentos de workshops acadêmicos contêm pesquisas aprofundadas sobre segurança, desempenho e extensões dos protocolos.

Com isso, deixo você, caro leitor, com uma compreensão muito melhorada deste admirável mundo novo. Estou sempre aberto a comentários, então, por favor, deixe-me saber o que você pensa desta série!