- Em ambientes com mais de 500 Mbps a 1 Gbps por conexão, como redes cabeadas de alta velocidade, WiFi 6/7 e 5G, a pilha UDP+QUIC+HTTP/3 apresentou uma taxa de transferência de dados até 45,2% menor do que TCP+TLS+HTTP/2
- Indo além de downloads simples de arquivos, em Chrome, Edge, Firefox, Opera e em ambientes desktop e mobile, quanto maior a largura de banda, maior a diferença de desempenho entre QUIC e HTTP/2
- Resultados de rastreamento de pacotes e profiling em kernel e espaço de usuário indicam que o gargalo está mais próximo do overhead de processamento no lado do recebimento do que do envio, com mais pacotes e mais processamento de ACK em espaço de usuário ao receber via QUIC
- O impacto nas aplicações aparece como uma redução de até 9,8% no bitrate em vídeo DASH e 3,0% a mais no tempo de carregamento de página na média de 100 sites representativos
- A mitigação exige adoção de UDP GRO no lado do recebimento, melhorias em GSO/GRO voltadas a QUIC, aprimoramento da lógica de recepção e uso de vários núcleos de CPU, mas a diversidade de dispositivos clientes e sistemas operacionais dificulta isso
A lacuna de desempenho do QUIC exposta em redes de alta velocidade
- QUIC é um protocolo de transporte multiplexado sobre UDP e foi padronizado pela IETF como base de transporte do HTTP/3
- Empresas como Google, Akamai, Meta e Cloudflare vêm implantando QUIC comercialmente desde 2013, e ele tem sido visto, junto com HTTP/3, como um candidato a mudar o desempenho da web
- Pesquisas anteriores sobre desempenho do QUIC variavam bastante em implementação, ambiente computacional e condições de rede, e muitas se concentravam em casos de uso de baixa vazão
- O foco da medição aqui é o comportamento do QUIC em redes rápidas, como links cabeados de alta velocidade, WiFi 6/7 e 5G, que atingem 500 Mbps ou mais ou 1 Gbps ou mais por conexão
- O alvo da comparação não é um protocolo isolado, mas a pilha completa
- Lado QUIC: UDP+QUIC+HTTP/3
- Lado tradicional: TCP+TLS+HTTP/2
- No resumo, cada lado é chamado simplesmente de QUIC e HTTP/2
Diferenças confirmadas em experimentos de download de arquivos
- Em experimentos simples de download de arquivos com cURL e
quic_clientbaseado em Chromium, a comparação foi feita igualando algoritmo de controle de congestionamento, configuração do servidor e condições de rede - Em larguras de banda relativamente menores, de cerca de menos de 600 Mbps, QUIC e HTTP/2 tiveram desempenho semelhante, mas em larguras de banda maiores a vazão do QUIC foi até 15,7% menor que a do HTTP/2
- À medida que a largura de banda aumentava, a diferença de desempenho ficava mais evidente, e durante o recebimento de pacotes o QUIC mostrou uso de CPU muito maior que o HTTP/2 em hosts clientes modernos
- Nos testes com navegadores principais, a diferença foi ainda maior
- Os navegadores testados foram Chrome, Edge, Firefox, Opera
- No Chrome, quando a largura de banda passa de cerca de 500 Mbps, o QUIC começa a ficar para trás
- Ao chegar a 1 Gbps, o QUIC fica 45,2% mais lento que o HTTP/2
- Em clientes mais fracos, como dispositivos móveis, a diferença aumenta ainda mais
Impacto em aplicações web
- A queda de desempenho não se limita à transferência de arquivos grandes; ela também aparece em aplicações com padrões de tráfego intermitentes
- Ao entregar chunks de vídeo DASH em Ethernet de alta velocidade e 5G, o QUIC apresentou bitrate de vídeo até 9,8% menor do que o HTTP/2
- Essa piora de QoE só aparece quando a largura de banda de base é suficientemente alta
- Em 4G, o efeito fica mascarado
- Em 5G, o efeito aparece
- Em experimentos de navegação web, considerando a média de 100 sites representativos, o tempo de carregamento de página (PLT) do QUIC foi 3,0% maior que o do HTTP/2
- Na cauda longa, houve casos em que a diferença de tempo de carregamento de página passou de 50%
Causa do gargalo: processamento no lado do recebimento e ACK em espaço de usuário
- Pelos rastros de pacotes e dados de desempenho, o cliente QUIC recebe muito mais pacotes do que em downloads via HTTP/2
- Quando o QUIC recebe em alta taxa de dados, aumenta o atraso entre os pacotes de dados recebidos e os pacotes ACK correspondentes, o que eleva o tempo de processamento dos pacotes QUIC
- Essas duas observações indicam que a causa da degradação de desempenho do QUIC em internet rápida está no limite da capacidade de processamento no lado do recebimento
- Há duas razões para o lado do recebimento ser apontado como gargalo
- Em geral, os servidores são mais potentes que clientes como desktops, notebooks e smartphones
- Pelo desenho do QUIC, o processamento de dados recebidos traz dificuldades próprias
- O profiling aprofundado identificou duas causas principais
- Pacotes de dados em excesso
- Ao baixar o mesmo arquivo, a pilha UDP dentro do kernel gera muito mais leituras de pacotes
netif_receive_skbdo que o TCP - Nenhuma das implementações de QUIC analisadas usa UDP generic receive offload, ou UDP GRO
- UDP GRO é um método em que o módulo da camada de enlace combina vários datagramas UDP recebidos em um único datagrama grande antes de entregá-los à camada de transporte
- Isso contrasta com a ampla adoção de TCP segmentation offload e com a ênfase recente em GSO, o offload de envio para UDP
- Ao baixar o mesmo arquivo, a pilha UDP dentro do kernel gera muito mais leituras de pacotes
- Processamento de ACK em espaço de usuário
- Em espaço de usuário, o QUIC tem overhead maior para processar pacotes recebidos e gerar respostas
- As causas incluem o excesso de pacotes vindos do kernel, o processamento em espaço de usuário dos ACKs do QUIC e a ausência de algumas otimizações, como delayed ACK no QUIC
- Pacotes de dados em excesso
Medições preliminares e caminhos de mitigação
- Em um experimento preliminar de download de um arquivo de 1 GB no navegador Chrome, ativar QUIC fez o tempo de download praticamente dobrar
- Os resultados de amostra são a média de 10 execuções
- Ethernet em desktop: HTTP/2 9,32 s, HTTP/3 18,60 s, um aumento de 99%; o uso de CPU subiu de 77,5% para 96,9%
- Pixel 5 em 5G low-band: HTTP/2 37,11 s, HTTP/3 78,65 s, um aumento de 112%; o uso de CPU subiu de 121,55% para 161,77%
- Pixel 5 em 5G mmWave: HTTP/2 30,10 s, HTTP/3 63,20 s, um aumento de 110%; o uso de CPU subiu de 128,43% para 165,20%
- O uso de CPU no desktop tem como base o serviço de rede do navegador, e a medição no smartphone tem como base o processo total do navegador
- Valores de uso de CPU acima de 100% significam que, em sistemas multicore, o processo do navegador usou mais de um núcleo
- As mitigações propostas incluem adoção de UDP GRO no lado do recebimento, melhorias em GSO e GRO voltadas a QUIC, aperfeiçoamento da lógica de recepção do QUIC e recepção de dados QUIC usando vários núcleos de CPU
- Como os hosts clientes incluem PCs, dispositivos móveis e embarcados com vários sistemas operacionais, sua heterogeneidade é maior que a dos servidores, o que cria dificuldades práticas para implementar essas mitigações
- Os dados de medição e o código-fonte foram publicados junto com a pesquisa
1 comentários
Opiniões no Hacker News
Parece que o setor está disposto a fazer qualquer coisa, menos criar sites leves
Mesmo no fim dos anos 90, se você tivesse uma conexão rápida, a internet era instantânea, as páginas eram pequenas e quase não havia JavaScript
Ainda hoje dá para encontrar páginas rápidas e leves assim, e a sensação é quase surreal, como se a página já tivesse carregado inteira antes mesmo de você soltar o botão do mouse
Se ao menos a experiência do usuário tivesse melhorado, daria para tolerar, mas nem isso conseguimos
Ficou mais rápido e muito mais robusto, e as inconsistências de estado entre frontend e backend também desapareceram
Admito um mínimo de JavaScript por conveniência; no momento são algumas centenas de linhas, e ainda pretendo acrescentar um pouco mais para que continue parecendo um app de página única
Com isso dá para eliminar cerca de 40 mil linhas de React e cerca de 20 mil linhas de Kotlin, mas será preciso reescrever cerca de 30 mil linhas de código no backend
Ainda assim, estou gostando
Então migrei minha página pessoal para uma versão estática em VUE.JS para ganhar experiência, mas era estranho amarrar a view e o estado passando nomes de variáveis como strings, a expansão do ambiente de build era desnecessariamente complexa, tudo era lento e tinha de ser feito apenas de uma forma específica
Como todo mundo usava, achei que devia estar certo, mas agora me libertei dessa visão, e a nova versão foi feita apenas com HTML bruto e templates de gerador de site estático
O tamanho do HTML caiu 90%, o uso de JS caiu 97%, e o tempo de build foi de 20 segundos para 2 segundos
A experiência do usuário também melhorou, e as visitas aumentaram 30% desde a nova versão
Quando se usa menos a web, a web pode ser muito mais incrível
No backend também, hoje a galinha dos ovos de ouro é vender microsserviços por meio de produtos SaaS headless conectados por APIs, com a ideia de que a performance naturalmente vai melhorar
https://macharchitecture.com/
Se as pessoas querem comprar esse tipo de pá, no mundo de TI não resta alternativa a não ser empilhar esse tipo de pá também
Meu blog é um site Hugo renderizado estaticamente, sem JS nenhum, e meus projetos são baseados em Rails e HTML renderizado no servidor, com apenas o mínimo de JS para recursos desejáveis
Funciona mesmo sem JS
Talvez eu diga isso por serem meus sites, mas a experiência é muito melhor que a da maior parte da web, e perdemos coisas demais
O Google já chegou a criar um Speedtest puramente em JS
Na época, o Ookla ainda era baseado em Flash, então não funcionava no Chromebook, o que virava um problema para a equipe de instalação validar o estado da instalação
Nesse processo, aprendi muito sobre como o TCP reage a vários fatores
O resultado deste artigo é praticamente o esperado, porque o controle de fluxo foi empurrado do kernel e talvez do adaptador de rede para o espaço de usuário
O TCP tem controle de fluxo e garantia de ordem, e o QUIC meio que faz você gerenciar isso diretamente
Claro que há bons motivos para isso
O controle de congestionamento do TCP é famoso por ter ficado para trás em relação às velocidades de conexão modernas, e surgiram algoritmos novos como o BBR, mas eles têm um custo [1]
Um ponto essencial que fica de fora com frequência demais em testes de rede ou de aplicações web é a latência
Quem mora na Ásia ou na Austrália sabe como uma latência de ida e volta de 100 ms pode ser fatal
Ela pode transformar algo totalmente responsivo em algo completamente inutilizável, reduzir a largura de banda que a conexão consegue suportar por causa da janela e também torná-la menos sensível a erros e ao controle de congestionamento
Se você testa redes ou apps web, recomendo fortemente fazer testes adicionando aleatoriamente 100 ms à latência [2]
Portanto, o overhead do QUIC talvez nem importe de verdade
Porque a largura de banda efetiva em uma única conexão TCP ou stream QUIC pode ser muito menor que a largura de banda bruta real
Em outras palavras, mesmo com 45% de dados adicionais, pode ser vantajoso se, ao gerenciar diretamente o controle de congestionamento, a velocidade efetiva entre dois pontos ficar maior
[1]: https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-c...
[2]: https://bencane.com/simulating-network-latency-for-testing-i...
Olhando em retrospecto parece óbvio, mas, no TCP, basta dizer “kernel, por favor envie este buffer enorme”, enquanto UDP funciona por troca de pacotes, e até enviar 0 tem um custo alto de CPU na maioria dos sistemas operacionais e hardwares de consumo por causa da troca de modo
Existem formas de contornar isso, mas não são fáceis e, pela minha experiência, ainda não estavam prontas; além disso, limitam a escolha de linguagem, biblioteca e plataforma que você pode usar
Como bônus, vi a vazão cair bastante ao usar um MacBook na bateria, provavelmente relacionado aos núcleos de eficiência
Em segundo lugar, o QUIC não lidava bem com controle de congestionamento
Usei quic-go, então pode variar conforme o ambiente, mas nenhum ajuste ajudou muito e, quando havia um stream TCP junto, o TCP ficava com mais largura de banda
Em terceiro lugar, a API é estranha
O QUIC em si tem múltiplos streams, então não é um substituto plug-and-play do TCP
A intenção, porém, é fazer do HTTP/3 um substituto plug-and-play em uma camada mais alta, mas não testei isso, então não posso opinar
Se você trabalha no nível de streams, vale manter isso em mente
No fim, fiquei com uma sensação considerável de derrota, mas ao mesmo tempo passei a respeitar ainda mais a otimização e a resiliência do velho amigo TCP
É uma tecnologia realmente impressionante, e o sistema operacional sempre a fornece de graça
Alguns dos principais problemas do TCP também vêm mais de padrões conservadores ou legados do que de falhas de projeto
Coisas como os limites de buffer do Linux e o Nagle
Seria bom se pudéssemos simplesmente melhorar o TCP em vez de reinventar a roda
[1]: https://payload.app/
Foi uma decisão necessária para o QUIC começar, mas agora que ele existe, ela também pode ser reavaliada
Não há obstáculo técnico para implementar QUIC no kernel e, se o ganho de desempenho for grande, alguém quase certamente fará isso em breve
A diferença é como água e vinho
Há presets Slow/Fast 4G e 3G, e você pode criar um preset personalizado definindo velocidades de download e upload, latência em ms, taxa de perda de pacotes, tamanho da fila de pacotes, e também ativar reordenação de pacotes
Daniel Stenberg, criador e mantenedor do curl, escreveu há alguns meses sobre HTTP/3 no curl: https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-20...
Um dos pontos que ele destacou foi o maior uso de CPU do HTTP/3, a ponto de a CPU limitar a vazão
Fico curioso sobre quanto disso se deve à imaturidade da implementação e quanto é uma característica do próprio design do QUIC
A terceira recomendação é UDP GRO, que consiste em modificar o kernel — idealmente o hardware da NIC — para agrupar pacotes UDP recebidos, reduzindo o trabalho por pacote e substituindo-o por trabalho por grupo
O TCP já tem isso, e no lado de envio há coisas semelhantes como TSO e GSO no Linux
Isso também soa como imaturidade, mas pode ser mais difícil de corrigir se considerarmos a possível falta de suporte de hardware
O resumo fala sobre o custo do mecanismo de ACK do QUIC, mas não analisei esse argumento em detalhe
Outro recurso que se vê em servidores modernos baseados em TCP é o offload de TLS para hardware
Isso parece mais importante em servidores que enviam muitos fluxos TCP simultaneamente
No Linux, isso é possível usando networking em espaço de usuário ou por meio de “kernel tls” e, quando possível, é descarregado para o hardware
Esse recurso também está relacionado a uma peculiaridade do Linux que permite dividir um stream TCP em “mensagens” e enviá-las para outras threads; não sei se, quando um pacote anterior é perdido, ele consegue repassar antecipadamente as mensagens posteriores
Nunca tive a impressão de que a intenção fosse tornar todas as conexões mais rápidas
Visto por esse ângulo, as concessões fazem sentido
Não sou especialista, então espero que alguém que entenda melhor me corrija
O QUIC foi criado porque não havia praticamente nenhuma maneira de fazer todo o hardware e middleware espalhados pela internet oferecer suporte a um novo padrão de TCP ou TLS
Por isso, o QUIC é uma solução elegante para colocar um novo padrão de transporte sobre UDP em cima do hardware legado da internet
Em um mundo ideal, teríamos criado novos padrões de TCP e TLS e substituído ou atualizado todos os roteadores e hardwares da internet no mundo todo para implementá-los com menor uso de CPU
Nos testes, o quiche limitado pela CPU ficou abaixo de 200 MB/s, enquanto o nghttp2 passou de 900 MB/s
Fico me perguntando se a CPU estava sofrendo throttling
Se uma implementação de HTTP/3 usa 4 vezes mais CPU, isso é interessante, mas se o valor absoluto já era muito baixo para começo de conversa, talvez não seja necessariamente um grande problema
A parte essencial é que “em internet rápida, a pilha UDP+QUIC+HTTP/3 reduz a taxa de dados em até 45,2% em comparação com TCP+TLS+HTTP/2”; ainda não li o artigo inteiro, mas na introdução eles parecem considerar menos de 600 Mbit/s como internet lenta
Usando a Cloudflare como exemplo, ela só oferece suporte a QUIC entre cliente <> edge, não nas conexões com a origem
Se a conexão edge <> origem for reutilizável, estável e “rápida”, isso faz sentido
https://developers.cloudflare.com/speed/optimization/protoco...
Não soa como se houvesse um problema fundamental no próprio protocolo
Mas esse tipo de problema de latência não aumenta muito o consumo de bateria, ao contrário de um problema de uso de CPU que faz a CPU entrar em boost
Também não é um problema em comunicação servidor a servidor
Basicamente, em dispositivos de usuários finais, mesmo em 2024, uma conexão muito rápida fica “mais lenta” em transferências de alta largura de banda
A velocidade aqui é a velocidade efetiva entre o dispositivo real e o servidor, não a velocidade contratada anunciada
Não estou dizendo que o artigo seja inútil; as implementações dos navegadores precisam melhorar, e ele mostra bem esse ponto
Ainda assim, o título do artigo é quase 100% clickbait
No momento em que a internet gigabit está se espalhando, mudar para um método de transmissão mais lento é claramente um erro
Daqui a 30 anos será ainda mais rápido; seria tolice ter que usar protocolos mais antigos para aproveitar toda a velocidade do link
O mesmo texto também apareceu em setembro: QUIC is not quick enough over fast internet (acm.org)
https://news.ycombinator.com/item?id=41484991 (327 comentários)
Brave/Vivaldi/Opera etc. precisam fazer uma escolha consciente
É como se, contanto que os anúncios cheguem rápido, o resto não importasse
Isso realmente soa muito estranho
Já consegui atingir 900 mbps tanto com QUIC+HTTP/3 quanto apenas com QUIC
Parece uma implementação TLS ruim ou uma implementação inicial ineficiente
O uso de CPU ficava em torno de 5% em um core EPYC de 2ª geração, algo bem dentro da média
Como anedota, tive um problema para acessar o wordpress.org
Quando comecei a usar o Wordpress, eu conseguia consultar bem a documentação, mas em algum momento deixei de conseguir acessar o site por completo
Como eu fazia dual boot com Linux, não era um problema do Windows; o ping funcionava bem, e mesmo trocando entre três navegadores era igual
Ao entrar no site, ele ficava travado e não carregava nada, ou às vezes a página parava de carregar no meio
Hoje encontrei a solução: desativar Experimental QUIC Protocol nas configurações do Chrome
Passei meses com problemas para acessar o wordpress.org, e me preocupa que não houvesse nenhum indício de que isso era por causa do QUIC
Só percebi por pouco porque erros relacionados ao QUIC apareciam nas ferramentas de desenvolvedor apenas de vez em quando
Fico imaginando quantos outros sites ficaram inacessíveis por causa desse protocolo sem que os usuários saibam a causa
Aqui, internet rápida significa 500 Mbps, e o motivo é que o QUIC parece ficar limitado pela CPU acima disso
Não cheguei a analisar em detalhe o suficiente para verificar se o sistema de teste era de uso doméstico comum ou se o problema ainda ocorreria em um desktop de alto desempenho
O engraçado é que aceitamos implicitamente ideias como “QUIC é o novo HTTP/2” só porque rápido = bom, mesmo sem conhecer bem os detalhes
É parecido com comprar um novo celular 5G porque dizem que ele é várias vezes mais rápido que o 4G
Só que, na prática, 1) meu celular 4G nunca operou na velocidade máxima do 4G, e 2) problemas de conexão quase sempre não são por causa da velocidade da linha de internet, mas de problemas no servidor DNS, no site de destino ou nos equipamentos de multiplexação de conexão da operadora
Mesmo assim vira “mas é 5G”
Também é engraçado ver anúncios de “broadband por fibra óptica” encenando pessoas assistindo TV com o cabelo voando ao vento
Na prática, não funciona assim
Antigamente já fazíamos streaming com conexões de 8 Mb, então 300 Mb podem ser bons para algumas coisas, mas fico em dúvida se dá para sentir uma grande diferença
Eu gostaria que o QUIC tivesse um modo sem TLS
Durante o desenvolvimento local, às vezes eu só quero ver o que está passando pelo fio, e isso adiciona muito atrito desnecessário
Por isso, não consegue funcionar sem isso