- O primeiro patch para integrar oficialmente o protocolo QUIC ao kernel Linux foi enviado
- O objetivo é superar limitações do TCP, como latência, head-of-line blocking e a ossificação do protocolo causada por dispositivos intermediários
- O QUIC é baseado em UDP, oferece suporte a multistream e criptografia ponta a ponta, e sua adoção no kernel pode ampliar o aproveitamento em mais plataformas e hardwares
- O desempenho da implementação inicial no kernel ficou abaixo do TCP tradicional e do kernel TLS, mas há expectativa de melhora com offloading de hardware e otimizações futuras
- Atualmente, há discussões ativas sobre suporte em Samba, SMB/NFS baseado em kernel, curl e outros, mas a incorporação ao mainline ainda deve levar tempo
Contexto do surgimento do protocolo QUIC e limitações do TCP
- O QUIC foi criado para resolver vários problemas do TCP na internet atual
- A latência causada pelo three-way handshake no processo de conexão do TCP, a falta de bom suporte a multistream e o fenômeno de head-of-line blocking devido à perda de pacotes prejudicam a experiência de uso da web
- Os metadados do TCP são transmitidos sem criptografia, o que traz risco de vazamento de informações, e os middleboxes (dispositivos intermediários) filtram o tráfego com base nas informações da conexão, levando à ossificação do protocolo (ossification)
- Mesmo tentativas de melhorar o TCP, como o Multipath TCP, não conseguem funcionar normalmente sem se disfarçar de TCP convencional
Características do QUIC e vantagens técnicas
- O QUIC funciona sobre UDP e permite estabelecer conexões rapidamente, sem um three-way handshake separado
- O protocolo foi projetado para transmissão multistream, de forma que a perda de pacotes não afete todo o fluxo
- Os dados de transporte relacionados ao QUIC são sempre criptografados de ponta a ponta (com base em TLS), impedindo que dispositivos intermediários acessem as mensagens internas
- Em qualquer ambiente de rede onde pacotes UDP possam passar, o QUIC também pode funcionar normalmente
Visão geral do patch de integração do QUIC no kernel Linux
- O patch enviado introduz um novo tipo de protocolo chamado IPPROTO_QUIC, permitindo usar a chamada de sistema socket() existente
- Assim como no TCP, é possível usar chamadas como bind() , connect() , listen() e accept() , mas o processamento posterior tem diferenças
- O gerenciamento de sessão TLS e os processos de autenticação/criptografia são tratados no espaço do usuário, e após a conexão o handshake TLS precisa ser concluído em cada ponta antes que a troca de dados seja possível
- Após a conexão inicial, é possível armazenar em cache o resultado da negociação TLS, acelerando bastante reconexões entre dois sistemas
Desafios de desempenho e perspectivas
- A implementação de QUIC dentro do kernel ainda mostra desempenho inferior ao do kernel TLS e TCP existentes
- Menos de um terço da vazão do in-kernel TLS; mesmo com a criptografia desativada, a vazão pode ser até 4 vezes menor que a do TCP
- Entre os motivos apontados estão a falta de suporte a segmentation offloading, cópias extras de dados no caminho de transmissão e o processo de criptografia de cabeçalhos
- Espera-se que o desempenho melhore com futuro suporte a offloading de hardware e com a otimização da implementação no kernel
Adoção atual e perspectivas futuras
- Há discussões ativas sobre suporte a QUIC no kernel em vários projetos, como servidor/cliente Samba, sistemas de arquivos SMB e NFS do kernel, curl e outros
- O patch tem cerca de 9.000 linhas e, no momento, inclui apenas código de suporte de baixo nível. A implementação completa foi prometida em patches adicionais
- As discussões de revisão de código e incorporação estão apenas começando, então o uso prático ainda deve levar tempo
- Considerando o precedente recente do protocolo Homa, cuja incorporação ao kernel exigiu 11 envios ao longo de 9 meses, também se espera que o QUIC entre no mainline só depois de 2026
Ainda não há comentários.