Version préliminaire de nginx avec prise en charge de QUIC et HTTP/3

La société NGINX a annoncé a annoncé le début des tests implementation des protocoles QUIC et HTTP/3 dans le serveur HTTP et le proxy nginx. L'implémentation est basée sur le brouillon 27 de la spécification IETF-QUIC et est disponible via un dépôt distinct, dérivé de la version 1.19.0. Le code est distribué sous licence BSD et ne chevauche pas l'implémentation proposée précédemment de HTTP/3 pour nginx réalisée par Cloudflare, qui est un projet distinct.

La prise en charge de HTTP/3 dans nginx est marquée comme expérimentale, car toutes les fonctionnalités du protocole ne sont pas encore implémentées. Cependant, nginx peut déjà être utilisé pour répondre à des requêtes simples HTTP/3 sur QUIC et pour le téléchargement/envoi de fichiers lourds. Les fonctionnalités encore manquantes du protocole incluent les mécanismes de négociation de version, ECN et contrôle de congestion, les journaux structurés, le mode de récupération (QUIC recovery, gestion de flux et congestion), le NAT Rebinding, les adresses mobiles, le Server push et l'ajout de données (trailer). De plus, seul un support de base du traitement des paquets ACK et de gestion de flux est proposé, ce qui nécessite des améliorations. Toutes les exigences de la norme ne sont pas prises en compte.

Pour activer HTTP/3, il est nécessaire de compiler nginx avec le module http_v3_module et d'ajouter une directive supplémentaire
« listen » avec l'option « http3 » pour créer un socket UDP d'écoute. Par exemple :

server {
listen 443 ssl; # socket TCP pour HTTP/1.1
listen 443 http3 reuseport; # socket UDP pour QUIC+HTTP/3

ssl_protocols TLSv1.3; # TLS 1.3 est requis dans QUIC
ssl_certificate ssl/www.example.com.crt;
ssl_certificate_key ssl/www.example.com.key;

add_header Alt-Svc ‘quic=»:443″‘; # indication de la disponibilité de QUIC
add_header QUIC-Status $quic; # En-tête avec le statut d'utilisation de QUIC
}

Rappelons que HTTP/3 standardise l'utilisation du protocole QUIC en tant que transport pour HTTP/2. Le protocole QUIC (Quick UDP Internet Connections) développé par Google depuis 2013 comme alternative à la combinaison TCP+TLS pour le Web, résolvant les problèmes de temps d'établissement et de négociation de connexions en TCP et éliminant les retards dus à la perte de paquets lors de la transmission de données. QUIC est une superposition du protocole UDP, prenant en charge le multiplexage de plusieurs connexions et offrant des méthodes de chiffrement équivalentes à TLS/SSL. Du côté du logiciel client, le support expérimental de HTTP/3 a déjà été ajouté dans Curl, Firefox et Chromium.

Principales caractéristiques QUIC :

• Une sécurité élevée, similaire à TLS (en réalité QUIC permet l'utilisation de TLS 1.3 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 remarquable 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