quinn
quinn-proto 0.11.9, quinn 0.11.6
Quinn est une implémentation compatible asynchronisée pure-rust et du protocole de transport IETF Quic. Le projet a été fondé par Dirkjan Ochtman et Benjamin Saunders en tant que projet parallèle en 2018, et a vu plus de 30 sorties depuis lors. Si vous utilisez Quinn dans un cadre commercial, veuillez envisager de parrainer le projet.
Exemples
$ cargo run --example server ./
$ cargo run --example client https://localhost:4433/Cargo.toml Cela lance un serveur HTTP 0.9 sur l'adresse de bouclage servant le répertoire de travail actuel, avec le client récupérant ./Cargo.toml . Par défaut, le serveur génère un certificat auto-signé et le stocke sur le disque, où le client trouvera automatiquement et lui fera confiance.
Links
Un point de terminaison Quinn correspond à une seule prise UDP, peu importe le nombre de connexions utilisées. La gestion des débits de données agrégés élevés sur un seul point de terminaison peut nécessiter un tampon UDP plus grand que celui qui est configuré par défaut dans la plupart des environnements. Si vous observez la latence et / ou le débit erratiques sur un lien de réseau stable, envisagez d'augmenter les tailles de tampon utilisées. Par exemple, vous pouvez ajuster les options SO_SNDBUF et SO_RCVBUF de la prise UDP à utiliser avant de la transmettre à Quinn. Notez que certaines plates-formes (par exemple Linux) nécessitent des privilèges élevés ou une configuration système modifiée pour un processus pour augmenter ses tailles de tampon UDP.
Par défaut, les clients Quinn valident l'identité cryptographique des serveurs auxquels ils se connectent. Cela empêche un attaquant actif et sur le chemin d'intercepter les messages, mais nécessite de faire confiance à une autorité de certificat. À de nombreuses fins, cela peut être accompli en utilisant des certificats de Let's Encrypt pour les serveurs et en s'appuyant sur la configuration par défaut des clients.
Pour certains cas, y compris le pair à peer, la confiance en première utilisation, les applications délibérément insénuées, ou tout cas où les serveurs ne sont pas identifiés par nom de domaine, ce n'est pas pratique. La logique de validation du certificat arbitraire peut être implémentée en activant la fonctionnalité dangerous_configuration de rustls et en construisant un ClientConfig Quinn avec un vérificateur de certificat remplacé à la main.
Lorsque l'exploitation de votre propre autorité de certificat n'a pas de sens, RCGEN peut être utilisé pour générer des certificats auto-signés à la demande. Pour prendre en charge la fiducie-utilisation, les serveurs qui génèrent automatiquement des certificats auto-signés doivent écrire leur certificat généré en stockage persistant et le réutiliser lors de futures exécutions.
Tous les commentaires sont les bienvenus. N'hésitez pas à déposer des bogues, des demandes de documentation et de toute autre rétroaction au tracker des problèmes.
La suite de tests Quinn-Proto utilise une IO simulée pour la reproductibilité et pour éviter de longs sommets dans certains tests sensibles au timing. Si la variable d'environnement SSLKEYLOGFILE est définie, les tests émettront des paquets UDP pour l'inspection à l'aide d'analyseurs de protocole externes comme Wireshark et des journaux de clés compatibles NSS pour le côté client de chaque connexion seront écrits sur le chemin spécifié dans la variable.
La version de rouille soutenue minimale pour les versions publiées de nos caisses aura toujours au moins 6 mois au moment de la sortie.
