La société Cloudflare pour assurer le support du protocole HTTP/3 dans NGINX. Le module est conçu comme une extension de la bibliothèque développée par Cloudflare avec la mise en œuvre du protocole de transport QUIC et HTTP/3. Le code de quiche est écrit en Rust, mais le module pour NGINX est écrit en C et utilise la bibliothèque par le biais d'un lien dynamique. Les réalisations sous licence BSD.
Pour la compilation, il suffit de télécharger vers nginx 1.16 et la bibliothèque quiche, puis de reconstruire nginx avec les options «—with-http_v3_module —with-quiche=../quiche». Lors de la compilation, le support TLS doit être basé sur la bibliothèque BoringSSL («—with-openssl=../quiche/deps/boringssl»), l'utilisation d'OpenSSL n'est pas encore supportée. Pour accepter les connexions, il faut ajouter la directive listen avec le drapeau «quic» (par exemple «listen 443 quic reuseport»).
Du côté des logiciels clients, le support de HTTP/3 a déjà été ajouté dans les versions expérimentales de Chrome Canary et dans l'utilitaire curl. Côté serveur, il était encore nécessaire d'utiliser des . La capacité de traitement de HTTP/3 dans nginx permettra de simplifier considérablement le déploiement de serveurs prenant en charge HTTP/3 et rendra plus accessible le test de l'implémentation du nouveau protocole. L'apparition du support officiel de HTTP/3 dans nginx dans la branche 1.17.x dans les 6 à 12 mois.
Rappelons que HTTP/3 standardise l'utilisation du protocole QUIC en tant que transport pour HTTP/2. Le protocole (Quick UDP Internet Connections) est développé par Google depuis 2013 comme une alternative à la combinaison TCP+TLS pour le Web, résolvant les problèmes de latence dans l'établissement et l'accord des connexions TCP et éliminant les retards dus aux pertes de paquets pendant le transfert de données. QUIC représente une couche au-dessus du protocole UDP, prenant en charge le multiplexage de plusieurs connexions et fournissant des méthodes de cryptage équivalentes à TLS/SSL.
Principales QUIC :
- Haute sécurité, similaire à TLS (en substance, QUIC permet d'utiliser TLS sur UDP) ;
- Contrôle de l'intégrité du flux, empêchant la perte de paquets ;
- Possibilité d'établir une connexion instantanément (0-RTT, dans environ 75% des cas les données peuvent être transmises immédiatement après l'envoi du paquet d'établissement de connexion) et de garantir des délais minimaux entre l'envoi de la demande et la réception de la réponse (RTT, Round Trip Time) ;
- Non-utilisation lors de la retransmission d'un paquet du même numéro de séquence, permettant d'éviter toute ambiguïté lors de la détermination des paquets reçus et d'éliminer les délais d'attente ;
- La perte d'un paquet n'affecte que la livraison du flux qui lui est associé et ne bloque pas la livraison des données dans les flux simultanément transmis via la connexion actuelle ;
- Les mécanismes de correction d'erreurs réduisent les délais dus à la retransmission des paquets perdus. L'utilisation de codes spécifiques de correction d'erreurs au niveau du paquet permet de réduire les situations nécessitant la retransmission des données d'un paquet perdu.
- Les limites des blocs cryptographiques sont alignées sur les limites des paquets QUIC, ce qui réduit l'impact des pertes de paquets sur le décodage du contenu des paquets suivants ;
- Absence de problèmes de blocage de la queue TCP.
- Support de l'identifiant de connexion, permettant de réduire le temps d'établissement d'une reconnexion pour les clients mobiles.
- Capacité à se connecter à des mécanismes avancés de contrôle de congestion.
- Utilisation de techniques de prévision de bande passante dans chaque direction pour garantir une intensité d'envoi optimale des paquets, empêchant un glissement vers un état de congestion, où des pertes de paquets sont observées.
- Une augmentation de performance et de bande passante par rapport à TCP. Pour les services vidéo tels que YouTube, l'application de QUIC a montré une réduction de 30% des opérations de re-buffering lors du visionnage de vidéos.
Source : opennet.ru
