QUIC não é rápido o suficiente em internet veloz
-
Contexto da pesquisa
- Espera-se que o QUIC desempenhe um papel importante na melhoria do desempenho de aplicações web.
- Este artigo investiga de forma sistemática o desempenho do QUIC em redes de alta velocidade.
-
Principais descobertas
- Em internet de alta velocidade, a pilha UDP+QUIC+HTTP/3 reduz a taxa de transferência de dados em até 45,2% em comparação com TCP+TLS+HTTP/2.
- À medida que a largura de banda base aumenta, a diferença de desempenho entre QUIC e HTTP/2 cresce.
- Esse problema afeta não apenas a transferência de arquivos, mas também várias aplicações, como streaming de vídeo (queda de até 9,8% no bitrate de vídeo) e navegação na web.
-
Método de análise
- A causa raiz do problema foi identificada por meio de análise de rastreamento de pacotes e profiling no kernel e no espaço do usuário.
- O alto overhead de processamento no lado do receptor, especialmente o excesso de pacotes de dados e os ACKs do QUIC no espaço do usuário, é a causa do problema.
-
Recomendações de melhoria
- São apresentadas recomendações específicas para mitigar os problemas de desempenho observados.
Resumo do GN⁺
- Este artigo analisa os problemas de desempenho do QUIC em ambientes de rede de alta velocidade e oferece insights importantes que podem contribuir para melhorar o desempenho de aplicações web.
- Ao identificar a causa da degradação de desempenho do QUIC como overhead de processamento no lado do receptor e apresentar medidas concretas para resolver isso, fornece informações úteis para engenheiros de rede e desenvolvedores.
- Outro protocolo com funcionalidade semelhante é o HTTP/2, e a comparação de desempenho com ele indica caminhos para melhorar o QUIC.
1 comentários
Comentários no Hacker News
A indústria está tentando de tudo, menos fazer sites leves. No fim dos anos 90, se você tinha uma conexão de internet rápida, as páginas eram pequenas e quase não tinham JavaScript. Ainda hoje dá para encontrar essas páginas leves que carregam rápido, e a experiência é quase surreal. Se a experiência do usuário tivesse melhorado, isso seria mais tolerável.
Trabalhei no Speedtest puro em JS do Google. Na época, o Ookla era baseado em Flash, então não funcionava em Chromebooks. Aprendi muito sobre como o TCP reage a vários fatores. Ao ver este artigo, pensei que o resultado era o esperado, porque ele empurra o controle de fluxo do kernel para o espaço do usuário. O TCP tem controle de fluxo e sequenciamento. O QUIC faz com que ele mesmo gerencie isso. O controle de congestionamento do TCP não combina com as velocidades modernas de conexão, então são necessários algoritmos novos como o BRR, mas isso tem custo. A maior lição é que não se deve ignorar a importância da latência em testes de rede. Quem mora na Ásia ou na Austrália sabe o quão devastadora pode ser uma latência RTT de 100 ms. O overhead do QUIC pode não ser tão importante na prática, porque a largura de banda real por uma única conexão TCP ou por um stream QUIC pode ser muito menor do que a largura de banda bruta.
Daniel Stenberg, criador e mantenedor do Curl, escreveu no blog sobre HTTP/3. Ele destacou o alto uso de CPU do HTTP/3 e mencionou que a CPU pode limitar a taxa de transferência. Fico me perguntando se isso se deve à imaturidade da implementação ou ao modo como o QUIC foi projetado.
Dizem que, em internet rápida, a pilha UDP+QUIC+HTTP/3 reduz a velocidade de transferência de dados em até 45,2% em comparação com TCP+TLS+HTTP/2. Ainda não li o artigo inteiro, mas abaixo de 600 Mbit/s é considerado "internet lenta".
Dizem que o QUIC não é rápido o suficiente em internet rápida. Eles alcançaram 900mbps com quic+http3, e fico me perguntando se a implementação de TLS é ruim ou se as implementações iniciais são ineficientes. O uso de CPU ficou em cerca de 5% em média em um núcleo EPYC gen 2.
Aqui, "internet rápida" significa 500Mbps, e dizem que isso acontece porque o quic depende da CPU. Não verifiquei se o sistema de teste era um sistema consumidor padrão ou se isso também é um problema em desktops de alto desempenho.
Eu achava que o QUIC era otimizado para latência. Ele é otimizado para carregar muitos pacotes pequenos em páginas web e videogames. Talvez deixe a desejar quando se mede apenas o throughput total. Fico me perguntando se, no nível do protocolo, seria possível detectar transferência de arquivos grandes ou streaming de vídeo de alta largura de banda e mudar para algo menos intensivo em CPU. Também me pergunto se o QUIC é menos otimizado em nível de hardware/SO do que o TCP.
Queria que o QUIC tivesse um modo sem TLS. Ao desenvolver localmente, às vezes quero ver o que está sendo transmitido, e isso adiciona atrito desnecessário.