Get best of the week

Comparação de desempenho HTTP / 3 e HTTP / 2



Nós da Cloudflare anunciamos o suporte ao HTTP / 3 em setembro passado quando estávamos comemorando nosso nono aniversário . Nosso objetivo sempre foi melhorar a Internet. A colaboração no campo de padrões é uma parte importante do processo e temos a sorte de estar envolvidos no desenvolvimento do HTTP / 3.

Embora o HTTP / 3 ainda esteja na fase de rascunho, notamos um grande interesse no novo protocolo de nossos usuários (a infraestrutura Cloudflare atende a mais de 10% dos sites da Internet - aprox. Por.). Até o momento, mais de 113.000 zonas ativaram o suporte a HTTP / 3 e, se você possui um navegador experimental, agora pode acessá-las usando o novo protocolo! É ótimo que muitas pessoas o incluam: trabalhar no HTTP / 3 de um grande número de sites reais significa que você pode testar várias propriedades a partir de navegadores.

Inicialmente, lançamos o HTTP / 3 em parceria com o Google, que também incluía suporte experimental para o Chrome Canary. Desde então, mais e mais navegadores adicionaram suporte experimental: ele apareceu nas versões Firefox Nightly , em vários navegadores baseados no Chromium, como Opera e Edge (por meio do mecanismo básico do Chromium) e nas pré-versões do Safari. Monitoramos de perto esses desenvolvimentos e ajudamos sempre que possível. Ter uma grande rede de sites que ativaram o HTTP / 3 oferece aos desenvolvedores de navegadores um excelente campo de teste para validar o código.

Então, qual é o status atual?


O processo de padronização da IETF envolve uma série de rascunhos para preparar um “rascunho final” pronto para rotular como um padrão RFC. Os membros da equipe do QUIC trabalham juntos na análise, implementação e interoperabilidade para identificar possíveis problemas. Lançamos o suporte ao protocolo na fase da 23ª versão do rascunho e, em seguida, seguimos todas as alterações. No momento da redação (14 de abril de 2020), a última era a 27ª versão. Com cada rascunho, a qualidade das definições do QUIC melhora e aborda um “consenso aproximado” sobre como o protocolo deve se comportar. Para evitar análises perpétuas com configurações infinitamente dopilivaniya ao ideal, a cada nova versão do rascunho aumenta a barra para fazer alterações nas especificações. Isso significa que em cada versão há menos alterações, e a RFC final corresponderá de perto ao protocolo que já lançamos em produção.

Benefícios


Uma das principais vantagens do HTTP / 3 foi o aumento no desempenho, especialmente ao solicitar vários objetos ao mesmo tempo. No HTTP / 2, qualquer interferência (perda de pacotes) em uma conexão TCP bloqueia todos os fluxos de uma só vez (bloqueando o início de uma linha). Como o HTTP / 3 é baseado no UDP, apenas um fluxo é interrompido quando um pacote é perdido, mas não todos.

Além disso, o HTTP / 3 suporta 0-RTT ( tempo de recebimento e transmissão zero), ou seja, as conexões subseqüentes podem iniciar muito mais rapidamente que a primeira, eliminando a necessidade de confirmar o TLS do servidor ao estabelecer uma conexão. Isso significa que o cliente começa a solicitar dados muito mais cedo do que com a negociação TLS completa, ou seja, o site começa a carregar no navegador mais cedo.

As animações abaixo mostram o efeito da perda de pacotes. No primeiro exemplo, as solicitações são recebidas do cliente para o servidor via HTTP / 2 para receber dois recursos. Solicitações e respostas relacionadas são coloridas em verde e amarelo. As respostas são divididas em vários pacotes. Infelizmente, um pacote é perdido - como resultado, a transferência de ambos os recursos está atrasada.



No segundo exemplo, solicitações de dois recursos são recebidas via HTTP / 3. Um pacote é perdido, bloqueando a transferência do recurso amarelo, mas sem afetar o verde.



Melhorias no procedimento para negociar uma sessão significam que as "conexões" com os servidores são estabelecidas muito mais rapidamente, ou seja, os dados chegam mais rapidamente no navegador. Estávamos curiosos sobre o quanto isso se refletia no tráfego real, por isso realizamos vários testes. Para avaliar a contribuição do 0-RTT, lançamos vários testes de controle para medir o tempo até o primeiro byte (tempo para o primeiro byte, TTFB). Em média, em HTTP / 3, o primeiro byte aparece após 176 ms. No caso do HTTP / 2, vemos 201 ms, ou seja, o HTTP / 3 aqui reduz o atraso em 12,4%!



Curiosamente, rascunhos e RFCs não regulam todos os aspectos do protocolo. Por exemplo, o método de transferência de pacotes afeta o desempenho.e algoritmo de controle de congestionamento de tráfego. O controle de congestionamento é um método de adaptação às redes congestionadas no lado do cliente e do servidor: quando os pacotes são perdidos, a qualidade da comunicação diminui. Como o QUIC é um novo protocolo, são necessárias experimentação e ajuste para projetar e implementar adequadamente um sistema de gerenciamento de sobrecarga.

Como ponto de partida simples e seguro, a especificação de detecção de perda e controle de congestionamento recomenda o algoritmo Reno , mas qualquer outro pode ser usado. Começamos com o algoritmo New Reno , mas com base na experiência, assumimos que não era o ideal. Recentemente, mudamos para o CUBIC - E em uma rede com transmissões superdimensionadas e maior perda de pacotes, o CUBIC teve um desempenho melhor que o New Reno. Em breve falaremos mais sobre isso, fique atento para uma atualização do blog.

Na pilha HTTP / 2 atual, temos o BBR v1 (TCP). Isso significa que os testes não realizam uma comparação exata de maçãs com maçãs, pois esses algoritmos de controle de congestionamento se comportam de maneira diferente em diferentes tamanhos de engrenagem. No entanto, ao mudar de HTTP / 2 para HTTP / 3, já vemos uma melhoria em sites menores. Em grandes áreas, o desempenho brilhante é mostrado pela nossa pilha HTTP / 2 otimizada e refinada.

Uma pequena página de teste de 15K é carregada em HTTP / 3 em média em 443 ms, em comparação com 458 ms no HTTP / 2. Mas se você aumentar o tamanho da página para 1 MB, essa vantagem desaparecerá: especificamente em nossa rede, o protocolo HTTP / 3 agora funciona um pouco mais devagar que HTTP / 2 - 2,33 s contra 2,30 s.







Os benchmarks sintéticos são interessantes, mas é interessante como o HTTP / 3 se mostra no mundo real.

Para comparação, queríamos atrair um serviço de terceiros que pode baixar sites da nossa rede, simulando um navegador da web. O WebPageTest é uma estrutura comum para medir o tempo de carregamento da página, com bons diagramas em cascata (cascata). Para analisar o back-end, usamos nosso próprio sistema Browser Insights , fixando os horários nos limites da nossa rede. Então eles conectaram as duas partes por um pouco de automação.

Como um caso de teste para medir o desempenho, criamos nosso próprio blog . Configuramos nossas instâncias WebPageTest para carregar o site em locais ao redor do mundo, tanto por HTTP / 2 quanto por HTTP / 3. HTTP / 3 e Insights do navegador incluídos. Assim, sempre que um navegador com suporte a HTTP / 3 carregava a página, os scripts de teste solicitavam dados de análise coletados do navegador. O mesmo procedimento foi repetido para HTTP / 2 para que pudesse ser comparado.

O gráfico a seguir mostra o tempo de carregamento da página blog.cloudflare.com real com uma comparação das métricas HTTP / 3 e HTTP / 2. Temos essas métricas para diferentes pontos geográficos.



Como você pode ver, o desempenho do HTTP / 3 ainda é inferior ao desempenho do HTTP / 2. A diferença é de cerca de 1-4% em média na América do Norte. Resultados semelhantes na Europa, Ásia e América do Sul. Suspeitamos que isso possa ocorrer devido a uma diferença nos algoritmos de controle de congestionamento: o BBR v1 funciona no HTTP / 2 e o CUBIC no HTTP / 3. No futuro, tentaremos implementar o mesmo algoritmo de controle de sobrecarga nos dois protocolos para obter uma comparação mais precisa de maçãs com maçãs.

Conclusão


No geral, estamos muito felizes em ajudar a avançar no novo padrão. Nossa implementação é boa, em algumas situações mostra melhor desempenho e, na pior das hipóteses, HTTP / 2 semelhante. À medida que o padrão é finalizado, esperamos que os navegadores adicionem suporte a HTTP / 3 nas principais versões. Quanto a nós, daremos suporte aos rascunhos mais recentes e procuraremos novas maneiras de otimizar o HTTP / 3 para melhorar ainda mais o desempenho, seja configurando o controle de congestionamentos, a priorização ou a configuração do sistema (CPU e largura de banda do canal).

Enquanto isso, se você quiser experimentar o HTTP / 3 em ação, basta ativá-lo em nosso painel e fazer o download do conjunto de testes (Nightly, Canary) de qualquer um dos principais navegadores. Consulte a documentação do desenvolvedor para obter instruções sobre como ativar o HTTP / 3 .

More articles:


All Articles