QUIC não é rápido o suficiente em uma internet rápida

• O QUIC é um protocolo do qual se espera uma mudança revolucionária na melhora do desempenho de aplicações web, mas seu desempenho fica aquém do esperado
• Este artigo analisa de forma sistemática o desempenho do QUIC em redes de alta velocidade

Resumo

• Em internet de alta velocidade, a pilha UDP+QUIC+HTTP/3 apresenta uma redução de até 45,2% na taxa de transferência de dados em comparação com TCP+TLS+HTTP/2
• A diferença de desempenho entre QUIC e HTTP/2 aumenta à medida que a largura de banda disponível cresce
• Esse problema é observado em clientes leves de transferência de dados e nos principais navegadores web (Chrome, Edge, Firefox, Opera), em vários hosts (desktop, mobile) e em diferentes redes (banda larga cabeada, celular)
• Afeta não apenas a transferência de arquivos, mas também diversas aplicações, como streaming de vídeo (queda de até 9,8% no bitrate de vídeo) e navegação web
• As causas raiz foram identificadas por meio de análise rigorosa de rastreamento de pacotes e profiling em kernel e espaço de usuário
• Em especial, o overhead de processamento no lado do receptor é alto devido ao excesso de pacotes de dados e aos ACKs do QUIC em espaço de usuário
• São apresentadas recomendações concretas para mitigar os problemas de desempenho observados

Causas raiz da degradação de desempenho

• Overhead excessivo de processamento de pacotes no nível de kernel do lado do receptor
  • O QUIC não usa UDP GRO (Generic Receive Offload), por isso precisa processar muito mais pacotes do que o TCP
  • Isso foi confirmado pelo número muito maior de chamadas à função netif_receive_skb no QUIC
• Overhead excessivo de processamento de pacotes do QUIC também no espaço de usuário
  • Há um alto custo para processar a grande quantidade de pacotes repassados pelo kernel
  • A geração de ACKs do QUIC no espaço de usuário também é uma causa de overhead

Propostas para mitigar a degradação de desempenho

• Introdução de UDP GRO no lado do receptor
  • Reduz o número de pacotes que precisam ser processados na pilha UDP, diminuindo o overhead no kernel e no espaço de usuário
  • No entanto, implantar UDP GRO em diferentes ambientes de cliente pode não ser simples
• Melhorar soluções de offloading como GSO/GRO para se adequarem ao QUIC
  • Dar suporte ao offloading de trens de pacotes UDP com tamanhos diferentes
  • Adicionar configuração adequada de pacing ao GSO para evitar congestionamento na rede
• Otimização da lógica QUIC no lado do receptor
  • Atrasar o envio de ACKs do QUIC para reduzir o overhead de geração de respostas
  • Usar recvmmsg para ler vários pacotes UDP de uma vez e melhorar o desempenho
• Uso de downloads multithread
  • No caso de arquivos grandes, downloads multithread com uso de vários núcleos de CPU podem melhorar o desempenho de recepção
  • Porém, é preciso considerar questões de justiça

[GN⁺]

Comentários do Hacker News

• a interface de syscall é complexa, e a API padrão é lenta demais para pacotes de tamanho comum (cerca de 1500 bytes)
  • GSO ajuda, mas a API é complexa e ainda tem muitos bugs recentes
• por causa das mitigações do Spectre, o custo de syscall aumentou
  • há necessidade de substituir sockets BSD / API POSIX
  • uring é complexo, mas é necessária uma API de nível intermediário
• o buffer UDP do sistema é pequeno demais por padrão
  • só especialistas usam isso, e especialistas ajustam as configurações
• é possível otimizar a stack de UDP
  • GSO mostra isso, mas o próprio GSO é caro e complexo
• algumas otimizações disponíveis hoje só funcionam em escala pequena/média
  • por exemplo, vinculação de conexão para evitar consulta de rota
• implementar GSO pode melhorar bastante o desempenho
  • provavelmente será necessário aumentar o tamanho do buffer no lado da plataforma
• no início do QUIC, a stack de UDP era menos otimizada do que a stack de TCP
  • são necessárias otimizações como UDP generic receive offload
• parece que o HTTP/2 também foi lançado às pressas
  • o Chrome removeu o suporte a server push
  • é preciso pensar mais no assunto
• QUIC e HTTP/2 mostram desempenho semelhante quando a largura de banda da rede é baixa
  • quando a largura de banda passa de 500Mbps, o desempenho do QUIC cai
  • isso é principalmente um problema em redes locais
• o Google tende a repassar a carga de processamento para os usuários
  • por exemplo, o codec de vídeo AV1 foi distribuído aos consumidores mesmo quando não havia suporte a decodificação por hardware
• o artigo de pesquisa está no arXiv
  • https://arxiv.org/pdf/2310.09423
• menção a ping com RTT de 0,23ms
  • mesmo em latência alta, o QUIC é o melhor
• ler a RFC9000 é difícil e complexo
  • a ideia de alto nível do QUIC é simples, mas a especificação exige lidar com muitos casos excepcionais
• disponibilização do PDF gratuito do estudo
  • https://arxiv.org/pdf/2310.09423
• mover o protocolo de conexão para o espaço do usuário talvez não seja um bom plano