O Quinn é uma implementação pura e compatível com assassinato assíncico do protocolo de transporte quic ietf. O projeto foi fundado por Dirkjan Ochtman e Benjamin Saunders como um projeto paralelo em 2018 e já assistiu a mais de 30 lançamentos desde então. Se você estiver usando o Quinn em um ambiente comercial, considere patrocinar o projeto.
Exemplos
$ cargo run --example server ./
$ cargo run --example client https://localhost:4433/Cargo.toml Isso inicia um servidor HTTP 0.9 no endereço de loopback que serve o diretório de trabalho atual, com o cliente buscando ./Cargo.toml . Por padrão, o servidor gera um certificado autoassinado e o armazena no disco, onde o cliente encontrará e confiará automaticamente.
Links
Um terminal de Quinn corresponde a um único soquete UDP, não importa quantas conexões estejam em uso. O manuseio de altas taxas de dados agregados em um único terminal pode exigir um buffer UDP maior do que o configurado por padrão na maioria dos ambientes. Se você observar a latência e/ou a taxa de transferência errática em um link de rede estável, considere aumentar os tamanhos de buffer usados. Por exemplo, você pode ajustar as opções SO_SNDBUF e SO_RCVBUF do soquete UDP a serem usadas antes de passá -lo para Quinn. Observe que algumas plataformas (por exemplo, Linux) requerem privilégios elevados ou configuração de sistema modificada para um processo aumentar seus tamanhos de buffer UDP.
Por padrão, os clientes quinn validam a identidade criptográfica dos servidores aos quais se conectam. Isso impede que um invasor ativo no caminho de interceptar mensagens, mas requer confiar em alguma autoridade de certificação. Para muitos propósitos, isso pode ser realizado usando certificados de Let's Encrypt for Servers e confiando na configuração padrão para os clientes.
Para alguns casos, incluindo aplicativos de ponto a ponto, confiar em primeiro uso, deliberadamente inseguros ou em qualquer caso em que os servidores não sejam identificados pelo nome de domínio, isso não é prático. A lógica de validação de certificação arbitrária pode ser implementada, permitindo o recurso dangerous_configuration de rustls e construindo um Quinn ClientConfig com um verificador de certificado substituído manualmente.
Ao operar sua própria autoridade de certificado não faz sentido, o RCGEN pode ser usado para gerar certificados autoassinados sob demanda. Para oferecer suporte ao Trust on-First-Use, os servidores que geram automaticamente certificados autoassinados devem escrever seu certificado gerado para armazenamento persistente e reutilizá-lo em execuções futuras.
Todo feedback é bem -vindo. Sinta -se à vontade para arquivar bugs, solicitações de documentação e qualquer outro feedback ao rastreador de problemas.
O conjunto de testes Quinn-Proto usa IO simulado para reprodutibilidade e para evitar sono longo em determinados testes sensíveis ao tempo. Se a variável de ambiente SSLKEYLOGFILE estiver definida, os testes emitirão pacotes UDP para inspeção usando analisadores de protocolos externos como Wireshark e os logs de chave compatíveis com NSS para o lado do cliente de cada conexão serão gravados no caminho especificado na variável.
A versão mínima de ferrugem suportada para lançamentos publicados de nossas caixas sempre terá pelo menos 6 meses de idade no momento do lançamento.