não, não, quem está aí? -Iroh

Hoje temos o prazer de anunciar ser (“número 0 QUIC”), nossa própria implementação QUIC de uso geral com suporte a multipath e NAT traversal. É a camada de transporte que alimenta o iroh desde a v0.96, embora não esteja de forma alguma limitada ao caso de uso do iroh.

Se você tem acompanhado o desenvolvimento de Iroh, deve ter lido por que bifurcamos Quinn em 2024. A versão resumida: Iroh estava fazendo muito trabalho pesado em volta QUIC: alternar entre caminhos diretos e de retransmissão, gerenciar a travessia do NAT, fazer malabarismos com o estado de congestionamento. Mas o próprio QUIC não tinha visibilidade de nada disso. Essa incompatibilidade criou problemas que não conseguimos resolver externamente.

Nosso garfo começou pequeno. Queríamos acompanhar de perto o upstream de Quinn, contribuir onde pudéssemos e manter nossa diferença mínima. Essa foi a decisão certa na época. Mas à medida que avançamos no multipath QUIC, na travessia NAT e em nossa própria arquitetura de retransmissão como caminho, a velocidade de desenvolvimento dos dois projetos derivou para ciclos de iteração que não correspondiam. Todas as nossas mudanças constantes levariam a uma carga de revisão irracional para os mantenedores do Quinn. A equipe n0 queria tentar mudanças estruturais mais profundas em nossa implementação do QUIC, e teria sido injusto impor as consequências dessas mudanças a todos os usuários do Quinn. Achamos que um hard fork com um compromisso contínuo com a colaboração faz mais sentido em todos os aspectos.

Então fomos até o fim. Explicamos nosso pensamento no tópico do Quinn multipath. Esta não é uma rejeição de Quinn, que continua sendo uma ótima implementação. É um reconhecimento de que os problemas que estamos resolvendo são específicos o suficiente para que uma base de código separada, com colaboração onde nossos interesses se sobreponham, seja o caminho honesto a seguir.

O recurso de título é uma implementação completa da especificação QUIC Multipath. Foi aqui que a verdadeira mudança arquitetônica aconteceu, tanto dentro do Quinn/noq quanto para uso do iroh. Antes do multipath, o iroh gerenciava vários caminhos (relay, IPv4 direto, IPv6 direto) como uma espécie de prestidigitação abaixo da camada QUIC. Quinn pensou que ele estava se comunicando com o outro endpoint por meio de apenas um endereço IP enquanto embaralhamos os pacotes pelo caminho que funcionava melhor. Mais ou menos como o pequeno NAT de Iroh em torno de Quinn.

Com multipath, esses caminhos são conceitos QUIC de primeira classe. O caminho do relé é um caminho QUIC. O caminho UDP direto é um caminho QUIC. O QUIC conhece todos eles, mantém o estado de congestionamento por caminho e pode decidir qual deles usar. Isso significa que as melhorias de latência que tivemos que hackear por meio de redefinições do controlador de congestionamento agora são tratadas de maneira correta e sistemática.

A implementação do multipath é genérica, mas não serve apenas para Iroh. Pretende ser uma implementação completa da especificação QUIC Multipath, para qualquer finalidade. A implementação ainda é recente, portanto, se você precisar de mais APIs, avise-nos.

Implementamos nossa própria interpretação do rascunho de passagem do QUIC NAT. Até onde sabemos, somos os primeiros a fazer isso de maneira robusta e de nível de produção. A travessia do NAT é notoriamente meticulosa, acertar em toda a gama de comportamentos do NAT na natureza é um problema difícil, e temos testado nossa abordagem em centenas de milhares de dispositivos que já executam o Iroh. Embora esta ainda não seja uma especificação definida, continuaremos iterando.

Expressar a perfuração de passagem NAT diretamente como uma operação no nível QUIC, em vez de algo acontecendo abaixo dela, é mais limpo e confiável, porque torna o controlador de congestionamento QUIC ciente disso e permite uma melhor detecção de perdas.

iroh tem usado nossa implementação do QUIC Address Discovery (QAD) desde a versão 0.32 do iroh. QAD usa conexões QUIC para aprender sobre endereços IP públicos de clientes, o que era feito anteriormente usando STUN. O QUIC permite criptografar esses pacotes sem sacrificar as viagens de ida e volta em comparação com o STUN, evitando a ossificação do protocolo e melhorando a privacidade do usuário.

Qlog é um projeto de padrão para registrar uma grande quantidade de informações sobre conexões QUIC. É uma ótima ferramenta de depuração, existem ferramentas de visualização como o qvis que podem mostrar o fluxo de pacotes entre dois pares.

No noq o suporte ao qlog foi bastante estendido para suportar muitos mais eventos do esquema principal de registro do qlog e [QUIC event definittions]. Além disso, a extensibilidade do qlog foi usada para adicionar eventos ao multipath QUIC. Temos até um protótipo de visualizador que pode mostrar os fluxos de pacotes em vários caminhos.

Embora a maioria das alterações da API do noq giram em torno do suporte multipath, também adicionamos um WeakConnectionHandle. Este é um tipo que não mantém uma conexão ativa, mas pode ser atualizado para uma conexão completa. Connection se ainda não foi descartado. Ele se comporta de maneira muito parecida [std::sync::Weak] mas sem precisar Arc pois isso nem sempre é tão fácil de fazer.

Isso pode ser útil para construir coisas como gerenciadores de conexões. Nós precisamos disso internamente em Iroh, com certeza há mais casos de uso bons.

noq foi enviado como parte do iroh v0.96 e está em produção desde então. Se você estiver usando uma versão recente do iroh, já está usando o noq.

Além de enviar e testar a implementação multipath do noq em relação a si mesmo, também executamos testes de interoperabilidade no picoquic, uma das implementações de referência usadas em eventos de interoperabilidade do grupo de trabalho QUIC.

Vemos o noq como uma base de longo prazo. Há mais trabalho que queremos fazer, como melhorias adicionais na passagem do NAT. O trabalho multipath também permite otimizações de desempenho que não eram possíveis antes. Continuaremos a nos envolver com o grupo de trabalho QUIC e a colaborar com a equipe Quinn em áreas onde nossos interesses se alinham.

Se você estiver trabalhando em implementações QUIC, transporte p2p ou aplicativos que precisam ser executados em diversas condições de rede, adoraríamos conversar. Venha nos encontrar no Discord ou abra um problema no GitHub.

Se você estiver ansioso para experimentar uma implementação multipath QUIC de ferrugem, dê uma olhada na documentação para uma conexão noq multipath.