Desempenho e eficiência: trabalhando com HTTP/3

O HTTP/3 está no horizonte, seguindo os passos do HTTP/2 – que provavelmente ainda é muito jovem. Dado que levou 16 anos para passar de HTTP/1.1 para HTTP/2, alguém deveria realmente se preocupar com HTTP/3?

A resposta curta: Sim, é importante, e você deve estar atualizado com isso. É exatamente como o HTTP/2 fez mudanças significativas do HTTP/1.1 mudando de ASCII para binário. O HTTP/3 novamente faz alterações significativas, desta vez alternando o transporte subjacente de TCP para UDP.

Embora o HTTP/3 ainda esteja em fase de design com a especificação oficial sendo um rascunho, ele já está sendo implantado e há uma boa chance de você encontrar uma versão dele rodando em sua rede hoje.

Mas há alguns novos dilemas colocados pelo funcionamento do HTTP/3. Além disso, qual é o benefício? E o que engenheiros de rede, administradores de sistema e desenvolvedores precisam saber?

A questão principal: desempenho e eficiência

Os desenvolvedores de sites e aplicativos geralmente criam com a intenção de que suas criações sejam realmente usadas. Às vezes, a base de público é finita, mas muitas vezes a ideia é apenas obter o maior número possível de usuários. Naturalmente, quanto mais popular um site se torna, mais receita ele pode gerar.

Um atraso de 100 milissegundos no tempo de carregamento do site pode prejudicar as taxas de conversão em 7%.

Relatório de desempenho de varejo online da Akamai: milissegundos são críticos (2017)

Dito de outra forma, um site de comércio eletrônico com vendas de US$ 40.000 por dia perderia um milhão de dólares anualmente devido a esse atraso.

Também não é segredo que o desempenho de um site é absolutamente crítico para que um site se torne mais popular. A pesquisa de compras online continua a encontrar ligações entre o aumento das taxas de rejeição e tempos de carregamento mais longos, e entre a fidelidade do comprador e o desempenho do site durante a experiência de compra.

A pesquisa também descobriu que:

• 47% dos consumidores esperam que uma página da web carregue em 2 segundos ou menos.
• 40% das pessoas abandonam um site que demora mais de 3 segundos para carregar.

E esse era o estado de paciência do comprador online há mais de uma década . Portanto, o desempenho é fundamental, e HTTP/2 e HTTP/3 significam melhor desempenho do site.

HTTP/2? …O que é isso?

Uma boa compreensão do protocolo HTTP/2 é crucial para entender o HTTP/3. Em primeiro lugar, por que havia necessidade de HTTP/2?

O HTTP/2 começou como um projeto do Google chamado SPDY, resultado de um estudo que relatou que o maior problema de desempenho na web era a latência . O autor concluiu que “mais largura de banda não importa (muito)”:

Se fizermos uma analogia entre o encanamento e a Internet, podemos considerar a largura de banda da Internet como o diâmetro do cano de água. Um tubo maior transporta um volume maior de água e, portanto, você pode fornecer mais água entre dois pontos.

Ao mesmo tempo, não importa o tamanho do seu cano, se o cano estiver vazio e você quiser levar água de um ponto a outro, leva tempo para a água percorrer o cano. Na linguagem da Internet, o tempo que a água leva para viajar de uma extremidade do cano para a outra e voltar é chamado de tempo de ida e volta , ou RTT .

Mike Belshe

No estudo, reduzir o tempo de carregamento da página era o objetivo. Ele mostrou que aumentar a largura de banda ajuda inicialmente, pois passar de 1 Mbps para 2 Mbps reduz pela metade o tempo de carregamento da página. No entanto, os benefícios se estabilizam muito rapidamente.

Em contraste, diminuir a latência tem um benefício constante e alcança os melhores resultados.

HTTP HOL: O problema de bloqueio de cabeça de linha

A principal causa de latência no protocolo HTTP/1 é o problema de bloqueio de cabeçalho. As páginas da Web (quase sempre) requerem vários recursos: CSS, JavaScript, fontes, imagens, AJAX/XMR, etc. Isso significa que o navegador da Web precisa fazer várias solicitações ao servidor. No entanto, nem todos os recursos são necessários para que a página se torne útil.

Com o HTTP/1.0 era necessário que o navegador completasse totalmente uma solicitação, incluindo o recebimento completo da resposta, antes de iniciar a próxima solicitação. Tudo tinha que ser feito em sequência. Cada solicitação bloquearia a linha de solicitações, daí o nome.

Na tentativa de compensar o problema de bloqueio de HOL, os navegadores da Web fazem várias conexões simultâneas a um único servidor. Mas eles tiveram que limitar arbitrariamente esse comportamento: servidores, estações de trabalho e redes podem ficar sobrecarregados com muitas conexões.

O HTTP/1.1 introduziu várias melhorias para ajudar a resolver o problema. A principal delas é o pipelining , permitindo que os navegadores da Web iniciem novas solicitações sem precisar aguardar a conclusão das solicitações anteriores. Isso melhorou significativamente os tempos de carregamento em ambientes de baixa latência.

Mas ainda exige que todas as respostas cheguem sequencialmente na ordem em que foram feitas, de modo que o início da linha ainda está bloqueado. Surpreendentemente, muitos servidores ainda não aproveitam esse recurso.

Curiosamente, o HTTP/1.1 também introduziu o keep-alive , que permitiu que os navegadores evitassem a sobrecarga de criar uma nova conexão TCP para cada solicitação HTTP. Esta foi uma tentativa inicial de resolver um problema de desempenho derivado do TCP. Era tão ineficaz que a maioria dos especialistas em desempenho realmente o desencoraja porque sobrecarrega o servidor com muitas conexões inativas. Vamos dar uma olhada no TCP abaixo, bem como como esse problema foi corrigido pelo HTTP/2.

Solução de bloqueio HTTP HOL do HTTP/2

O HTTP/2 introduziu a multiplexação de solicitação-resposta em uma única conexão. Não apenas um navegador pode iniciar uma nova solicitação a qualquer momento, mas as respostas podem ser recebidas em qualquer ordem — o bloqueio é completamente eliminado no nível do aplicativo.

Como resultado direto, isso significa que os servidores da Web com experiência em HTTP/2 podem maximizar a eficiência - mais sobre isso mais tarde.

Embora a multiplexação de solicitação-resposta seja o principal recurso do HTTP/2, ela inclui vários outros recursos significativos. Os leitores podem notar que todos eles estão um pouco relacionados.

Enquadramento binário HTTP/2

O HTTP/2 muda o padrão do protocolo HTTP de um modelo de solicitação-resposta ASCII legível por humanos ineficiente para um enquadramento binário eficiente. Não é mais apenas um pedido e uma resposta:

Com o HTTP/2, os navegadores conversam com os servidores por meio de fluxos bidirecionais com várias mensagens, cada uma consistindo em vários quadros.

HTTP/2 HPACK (compressão de cabeçalho)

A nova compactação de cabeçalho do HTTP/2, usando o formato HPACK, economiza uma tonelada de largura de banda para a maioria dos sites. Isso ocorre porque a maioria dos cabeçalhos é a mesma para as solicitações enviadas em uma conexão.

A Cloudflare relata economias significativas de largura de banda graças apenas ao HPACK:

• 76% de compactação para cabeçalhos de entrada
• Redução de 53% no tráfego total de entrada
• 69% de compactação para cabeçalhos de saída
• Redução de 1,4% a 15% no tráfego total de saída

Obviamente, usar menos largura de banda geralmente significa um site mais rápido.

Priorização de fluxo HTTP/2 e envio de servidor

Aqui é onde a multiplexação do HTTP/2 realmente permite que o servidor maximize a eficiência. A multiplexação ajuda a fornecer recursos mais rápidos (por exemplo, JavaScript em cache de memória) antes dos mais lentos (por exemplo, imagens grandes, JSON gerado por banco de dados etc.). Mas também permite um aumento de desempenho adicional por meio da priorização de fluxo do HTTP/2.

A priorização de fluxo ajuda a garantir que os aspectos quase prontos de uma página sejam concluídos por completo sem ter que aguardar a conclusão de outras solicitações com uso intensivo de recursos. Isso é feito por meio de uma árvore de dependência ponderada. Essa árvore é usada para informar ao servidor quais respostas ele deve alocar mais recursos do sistema para servir.

Isso é particularmente importante para aplicativos da Web progressivos (PWAs). Por exemplo, digamos que uma página tenha quatro arquivos JavaScript. Dois são para a funcionalidade da página e dois são para anúncios. O pior cenário é carregar metade do JS funcional e metade do JS de publicidade e, em seguida, carregar imagens grandes, antes de carregar qualquer um dos JS restantes. Nesse caso, nada na página funciona inicialmente, porque tudo tem que esperar pelo recurso mais lento.

Com a priorização de fluxo, os navegadores da Web podem instruir o servidor a enviar os dois arquivos JS de funcionalidade da página antes de enviar qualquer um dos arquivos JavaScript de publicidade. Dessa forma, os usuários não precisam esperar o carregamento completo dos anúncios antes de usar a funcionalidade da página. Embora o tempo de carregamento geral não tenha melhorado, o desempenho percebido aumentou significativamente. Infelizmente, esse comportamento no navegador da web ainda é principalmente uma questão de algoritmos, em vez de algo especificado por desenvolvedores da web.

Na mesma linha, o recurso de push do servidor HTTP/2 permite que o servidor envie respostas ao navegador para solicitações que ainda não foram feitas! O servidor pode aproveitar as lacunas na transmissão, usando a largura de banda com eficiência ao pré-carregar no navegador recursos que o servidor sabe que solicitará em breve. Parte da esperança aqui é eliminar a prática de inlining de recursos, que apenas sobrecarrega os recursos e os faz demorar mais para carregar.

Infelizmente, esses dois recursos precisam de muita configuração cuidadosa por parte dos desenvolvedores da Web para realmente ter sucesso. Simplesmente habilitá-los não é suficiente.

O HTTP/2 claramente traz muitas vantagens em potencial – algumas delas mais baratas de alavancar do que outras. Como eles estão se saindo no mundo real?

Adoção de HTTP vs HTTP/2

O SPDY foi criado em 2009. O HTTP/2 foi padronizado em 2015. SPDY tornou-se o nome de um ramo de desenvolvimento instável do código, com o HTTP/2 se tornando a versão final. O resultado é que o SPDY se tornou obsoleto e o HTTP/2 é comumente o padrão que todos seguem.

Após a padronização, a adoção do HTTP/2 (ou “h2”) cresceu rapidamente para cerca de 40% dos 1.000 principais sites. Isso foi impulsionado principalmente por grandes provedores de hospedagem e nuvem implantando suporte em nome de seus clientes. Infelizmente, vários anos depois, a adoção do HTTP/2 diminuiu e a maior parte da Internet ainda está no HTTP/1.

Falta de suporte do navegador para o modo de texto simples HTTP/2

Houve muitas chamadas para HTTP/2 para tornar a criptografia uma parte obrigatória do padrão. Em vez disso, o padrão definiu os modos criptografado (h2) e de texto simples (h2c). Como tal, o HTTP/2 poderia substituir o HTTP/1 inteiramente.

Apesar do padrão, todos os navegadores da Web atuais suportam apenas HTTP/2 em conexões criptografadas e não implementam intencionalmente o modo de texto simples. Em vez disso, os navegadores contam com o modo de compatibilidade com versões anteriores do HTTP/1 para acessar servidores inseguros. Este é um resultado direto de um impulso ideológico para tornar a web segura por padrão.

Por que HTTP/3? E como é diferente?

Com o problema de bloqueio de cabeçalho de linha HTTP agora corrigido pelo HTTP/2, os desenvolvedores de protocolo voltaram sua atenção para o próximo maior driver de latência: o problema de bloqueio de cabeçalho de linha TCP .

Protocolo de controle de transmissão (TCP)

As redes IP (protocolo de internet) são baseadas na ideia de computadores enviando pacotes uns aos outros. Um pacote é apenas dados com algumas informações de endereçamento anexadas ao topo.

Mas os aplicativos geralmente precisam lidar com fluxos de dados. Para alcançar essa ilusão, o protocolo de controle de transmissão (TCP) apresenta às aplicações um canal através do qual um fluxo de dados pode fluir. Como na maioria dos pipes, há uma garantia de que os dados sairão do pipe na mesma ordem em que entram, também conhecido como “first in, first out” (FIFO). Essas características tornaram o TCP muito útil e amplamente adotado.

Como parte das garantias de entrega de dados que o TCP oferece, ele deve ser capaz de lidar com uma ampla variedade de situações. Um dos problemas mais complexos é como entregar todos os dados quando uma rede está sobrecarregada, sem piorar a situação para todos. O algoritmo para isso é chamado de controle de congestionamento e é uma parte em constante evolução das especificações da Internet. Sem controle de congestionamento suficiente, a internet para.

Em outubro de 86, a Internet teve o primeiro do que se tornou uma série de 'colapsos de congestionamento'. Durante este período, a taxa de transferência de dados de LBL para UC Berkeley (sites separados por 400 jardas e três saltos IMP) caiu de 32 Kbps para 40 bps.

V. Jacobson (1988)

É aí que entra o problema de bloqueio de cabeçalho de linha TCP.

Problema de bloqueio TCP HOL

O controle de congestionamento TCP funciona implementando mecanismos de backoff e retransmissão de pacotes, usados ​​sempre que a perda de pacotes é detectada. A retirada destina-se a ajudar a acalmar a rede. A retransmissão garante que os dados sejam eventualmente entregues.

Isso significa que os dados TCP podem chegar ao destino fora de ordem e é responsabilidade da parte receptora reordenar os pacotes antes de remontá-los no fluxo. Infelizmente, isso significa que um único pacote perdido pode fazer com que todo o fluxo TCP seja pausado enquanto o servidor aguarda sua retransmissão. Assim, a cabeça da linha está bloqueada.

Outro projeto do Google teve como objetivo resolver esse problema introduzindo um protocolo chamado QUIC.

O protocolo QUIC é construído em cima do UDP em vez do TCP, e o QUIC está formando a base para o HTTP/3.

O que é UDP?

O protocolo de datagrama do usuário (UDP) é uma alternativa ao TCP. Ele não oferece a ilusão de um fluxo ou as mesmas garantias que o TCP oferece. Em vez disso, ele simplesmente fornece uma maneira fácil de colocar dados em um pacote, endereçá-lo a outro computador e enviá-lo. Não é confiável , não é ordenado e não vem com nenhuma forma de controle de congestionamento.

Sua finalidade é ser leve e fornecer os recursos mínimos necessários para permitir a comunicação. Dessa forma, o aplicativo pode implementar suas próprias garantias. Isso geralmente é muito útil em aplicativos em tempo real. Por exemplo, em chamadas telefônicas, os usuários geralmente preferem receber 90% dos dados imediatamente, em vez de 100% dos dados eventualmente.

Solução TCP HOL do HTTP/3

Resolver o problema de bloqueio TCP HOL exigiu mais do que apenas mudar para UDP, pois ainda é necessário garantir a entrega de todos os dados e evitar colapsos de congestionamento de rede. O protocolo QUIC foi projetado para fazer tudo isso, fornecendo uma experiência otimizada do tipo HTTP sobre UDP.

À medida que o QUIC assume o controle do gerenciamento de fluxo, enquadramento binário, etc., não resta muito para o HTTP/2 fazer quando executado em cima do QUIC. Isso é parte do fator determinante para que essa nova combinação de QUIC + HTTP seja padronizada como HTTP/3.

Observação: existem muitas versões do QUIC, pois o protocolo está em desenvolvimento e implantado em ambientes de produção há anos. Existe até uma versão específica do Google chamada GQUIC. Como tal, é importante fazer uma distinção entre os antigos protocolos QUIC e o novo padrão HTTP/3.

Sempre criptografado

O HTTP/3 inclui criptografia que toma muito emprestado do TLS, mas não o está usando diretamente. Um dos principais desafios de implementação para HTTP/3 são as bibliotecas TLS/SSL que precisam ser modificadas para adicionar a nova funcionalidade necessária.

Essa alteração ocorre porque o HTTP/3 difere do HTTPS em termos do que criptografa. Com o protocolo HTTPS mais antigo, apenas os dados em si são protegidos por TLS, deixando muitos metadados de transporte visíveis. No HTTP/3, tanto os dados quanto o protocolo de transporte são protegidos. Isso pode soar como um recurso de segurança, e é. Mas é feito dessa maneira para evitar muito da sobrecarga presente no HTTP/2. Portanto, criptografar o protocolo de transporte, bem como os dados, torna o protocolo mais eficiente.

Impacto do HTTP/3 na infraestrutura de rede

O HTTP/3 não é isento de controvérsias. As principais preocupações são sobre a infraestrutura de rede.

HTTP/3 do lado do cliente

No lado do cliente, é bastante comum que o tráfego UDP seja fortemente limitado e/ou bloqueado. A aplicação dessas restrições ao HTTP/3 anula o objetivo do protocolo.

Em segundo lugar, é bastante comum que o HTTP seja monitorado e/ou interceptado. Mesmo com tráfego HTTPS, as redes observam regularmente os elementos de transporte de texto simples do protocolo para determinar se devem interromper a conexão com o objetivo de impedir o acesso a determinados sites de redes específicas ou em regiões específicas. Em alguns países, isso é obrigatório por lei para determinados provedores de serviços. A criptografia obrigatória em HTTP/3 torna isso impossível.

Não é apenas a filtragem em nível governamental. Muitas universidades, bibliotecas públicas, escolas e lares com pais preocupados optam ativamente por bloquear o acesso a determinados sites ou pelo menos manter um registro de quais sites foram visitados. A criptografia obrigatória em HTTP/3 torna isso impossível.

Vale a pena notar que a filtragem limitada é atualmente possível. Isso ocorre porque o campo de indicação do nome do servidor (SNI) — que carrega o nome do host do site, mas não o caminho, os parâmetros de consulta etc. — ainda não está criptografado. Mas isso deve mudar em um futuro próximo com a introdução do ESNI (SNI criptografado), que foi recentemente adicionado ao padrão TLS.

HTTP/3 do lado do servidor

No lado do servidor, é uma prática recomendada bloquear todas as portas e protocolos que não estão esperando tráfego, o que significa que os administradores do servidor agora precisam abrir o UDP 443 para HTTP/3, em vez de confiar em suas regras TCP 443 existentes.

Em segundo lugar, a infraestrutura de rede pode tornar as sessões TCP rígidas , o que significa que elas sempre serão roteadas para o mesmo servidor, mesmo que as prioridades de roteamento mudem. Como o HTTP/3 é executado em UDP – que é sem sessão – a infraestrutura de rede precisa ser atualizada para rastrear IDs de conexão específicos de HTTP/3, que foram deixados sem criptografia especificamente para auxiliar no roteamento fixo.

Em terceiro lugar, é bastante comum que o HTTP seja inspecionado para detectar abusos, monitorar problemas comuns de segurança, detectar e impedir a propagação de malware e vírus, etc. Isso não é possível com HTTP/3 devido à sua criptografia. Ainda assim, opções em que o dispositivo interceptador tenha uma cópia das chaves de segurança ainda são possíveis, desde que os dispositivos implementem suporte a HTTP/3.

Por fim, muitos administradores se opõem a ter que gerenciar ainda mais certificados SSL, embora isso seja menos problemático agora com serviços como o Let's Encrypt disponíveis.

Até que haja soluções amplamente aceitas e conhecidas para resolver essas preocupações, acho que é provável que muitas grandes redes simplesmente bloqueiem o HTTP/3.

Impacto do HTTP/3 no desenvolvimento da Web

Não há muito com o que se preocupar nesta frente. A priorização de fluxo do HTTP/2 e os recursos de envio de servidor ainda estão presentes no HTTP/3. Vale a pena que os desenvolvedores da Web se familiarizem com esses recursos se quiserem realmente otimizar o desempenho do site.

Usando HTTP/3 agora

Os usuários do Google Chrome, ou do navegador Chromium de código aberto, já estão configurados para usar HTTP/3. Os lançamentos com qualidade de produção de servidores HTTP/3 ainda estão um pouco distantes – a especificação ainda não está finalizada no momento em que este artigo foi escrito. Mas, enquanto isso, há muitas ferramentas para brincar, e tanto o Google quanto a Cloudflare já ofereceram suporte para seus ambientes de produção.

A maneira mais simples de experimentar é usando o Caddy no Docker. Um certificado SSL é necessário para isso, portanto, um endereço IP acessível publicamente facilita as coisas. Os passos são:

1. Configuração de DNS. Obtenha um nome de host funcional que esteja ativo na Internet, por exemplo, yourhostname.example.com IN A 192.0.2.1 .
2. Criação do Caddyfile. Deve conter estas linhas:

 yourhostname.example.com log stdout errors stdout ext .html .htm .md .txt browse gzip tls [email protected]

1. Executando Caddy: docker run -v Caddyfile:/etc/Caddyfile -p 80:80 -p 443:443 abiosoft/caddy --quic —ou fora do Docker, caddy --quic .
2. Executando o chromium com o QUIC ativado: chromium --enable-quic
3. (Opcional) Instalando uma extensão do Indicador de Protocolo.
4. Navegando para o servidor habilitado para QUIC , onde um navegador de arquivos deve estar visível.

Os desenvolvedores também podem testar seus servidores com as seguintes ferramentas úteis:

• Teste HTTP/2 do Keycdn
• HTTP3Check do LiteSpeed
• Teste do servidor SSL da Qualys

Obrigado por ler!