Des packages binaires sont désormais disponibles pour l'implémentation Preview NGINX QUIC+HTTP/3

[ Editeur : NGINX prend désormais officiellement en charge HTTP/3 avec QUIC. Il est disponible dans le cadre de la version principale NGINX 1.25.1 pour les utilisateurs open source et de NGINX Plus R30 pour les clients d'entreprise.]
[ngx_snippet name='table-style-blog']
Nous sommes heureux d'annoncer que notre implémentation préliminaire du support NGINX pour QUIC+HTTP/3 est désormais disponible sous forme de packages binaires prédéfinis pour deux distributions :

• Red Hat Enterprise Linux 9 et variantes compatibles binaires
• Ubuntu 22.04

Les binaires sont les derniers livrables de la branche quic du référentiel nginx-quic distinct qui héberge l'implémentation préliminaire. Comme c'est le cas depuis que nous avons commencé à travailler sur QUIC+HTTP/3 dans NGINX , vous pouvez toujours télécharger et compiler NGINX Open Source avec QUIC+HTTP/3 et un choix de bibliothèques SSL/TLS prenant en charge QUIC. Bien que le code soit étiqueté comme expérimental, plusieurs membres de la communauté ont signalé qu'ils utilisent avec succès nginx-quic en production.

Notre principale motivation pour la publication de binaires prédéfinis est de rendre plus rapide et plus facile le test de NGINX avec QUIC+HTTP/3. Les binaires éliminent le besoin de compiler à partir de la source et peuvent être installés à l'aide d'outils de gestion de paquets standard.

Au moment de la rédaction de cet article, la norme de facto pour SSL/TLS open source, OpenSSL, ne prend pas en charge QUIC. Nous avons donc créé les distributions binaires avec un package de bibliothèque quictls , qui est installé automatiquement en tant que dépendance. Nous avons sélectionné quictls car il représente actuellement le meilleur mélange de stabilité, de compatibilité et de fonctionnalités.

Les instructions d'installation de la distribution binaire sont disponibles sur le site Web NGINX QUIC .

Configuration de NGINX pour QUIC+HTTP/3

Il existe plusieurs nouvelles directives pour configurer NGINX pour QUIC+HTTP/3, mais il est facile de les combiner avec les directives pour HTTP/1.1 et HTTP/2 dans les blocs de configuration de serveur virtuel existants ( server{} ).

Pour la configuration fonctionnelle la plus basique, il vous suffit d'inclure trois directives dans le bloc server{} (et child location{} ) :

Voici un exemple de bloc server{} :

server { # pour une meilleure compatibilité, nous recommandons
# d'utiliser le même numéro de port pour QUIC et TCP
listen 443 quic reuseport; # QUIC
listen 443 ssl; # TCP

ssl_certificate certs/example.com.crt;
ssl_certificate_key certs/example.com.key;
ssl_protocols TLSv1.3;

location / {
# annonce que QUIC est disponible sur le port configuré
add_header Alt-Svc 'h3=":$server_port"; ma=86400';

#proxy_pass <groupe_en_amont>; 
        #racine       /<répertoire_racine>; 
}
}

Il existe plusieurs nouvelles directives et variables facultatives liées à HTTP/3 (non affichées dans l'extrait), notamment celles-ci :

• $http3 – (Variable) Défini sur h3 lorsque la requête est envoyée pendant une session HTTP/3 (sinon, c'est une chaîne vide).
• quic_retry – (Directive) Lorsqu'il est défini sur on , indique à NGINX d'envoyer un message de nouvelle tentative QUIC au demandeur en spécifiant le nouvel ID de connexion à utiliser, dans le but de valider l'adresse IP du demandeur. Le paquet de nouvelle tentative QUIC compense partiellement le fait qu'une négociation de connexion TCP à trois voies ne peut pas être utilisée pour valider la connexion car QUIC s'exécute sur UDP.

• ssl_early_data – (Directive) Lorsqu'il est défini sur on , indique à NGINX d'accepter les données d'application dans la première requête envoyée par un client via une nouvelle connexion TLS 1.3, s'il y avait une connexion précédente de ce client. C'est ce qu'on appelle la reprise de connexion à temps aller-retour nul (0-RTT) . La prise en charge de l’envoi de « données précoces » est une fonctionnalité de TLS 1.3 et contribue à l’amélioration des performances de QUIC+HTTP/3 en éliminant les échanges de messages aller-retour supplémentaires requis pour une négociation TLS.

  Note: La reprise de la connexion 0-RTT peut créer un risque de sécurité, car les premières données sont sujettes à des attaques par relecture si elles incluent une méthode de requête HTTP autre que GET . Pour plus de détails, consultez la section sur TLS 1.3 dans Annonce de NGINX Plus R17 sur notre blog.

Le diagramme montre comment la reprise de connexion 0-RTT avec QUIC+HTTP/3 améliore les performances, car le client peut envoyer une requête HTTP dans son premier message lors de la reprise d'une connexion QUIC à NGINX. Pour TCP avec TLS, en revanche, le client doit effectuer une nouvelle négociation TLS avec NGINX pour établir une connexion sécurisée, au prix de plusieurs allers-retours supplémentaires.

Pour plus d'informations sur toutes les nouvelles directives et variables, consultez le 3. Configuration section de la nginx-quic LISEZ-MOI.

Test de NGINX avec QUIC+HTTP/3

Comme mentionné précédemment, l’une de nos motivations pour la publication de binaires prédéfinis est de faciliter le test de vérification que NGINX gère correctement le trafic HTTP/3. Pour des tests simples en ligne de commande, vous pouvez créer curl avec la prise en charge HTTP/3 ou utiliser un conteneur prédéfini . De plus, les versions plus récentes de la plupart des navigateurs prennent en charge QUIC+HTTP/3.

Pour vérifier que votre site compatible QUIC répond aux demandes de connexion HTTP/3 des navigateurs, vous pouvez utiliser les outils de développement d'un navigateur pour examiner les en-têtes HTTP renvoyés par NGINX. L'implémentation QUIC+HTTP/3 fonctionne correctement si NGINX inclut l'en-tête Alt-Svc décrit ci-dessus dans sa réponse à la demande HTTP initiale du navigateur via TCP.

À ce stade, un navigateur compatible QUIC établit une connexion QUIC sur le port spécifié dans la directive Alt-Svc , et les requêtes et réponses HTTP suivantes s'effectuent via QUIC. Une autre façon de vérifier que QUIC+HTTP/3 est utilisé est d'inclure une autre directive add_header pour définir la valeur d'un en-tête HTTP personnalisé sur le protocole capturé par la variable $server-protocol . Vous pouvez suivre la valeur de l'en-tête à mesure qu'elle change de HTTP/1. x avant que la connexion QUIC ne soit établie vers HTTP/3.0 lorsque QUIC est utilisé.

Voici un exemple de bloc d'emplacement où l'en-tête HTTP personnalisé est le protocole X :

location / { # annonce que QUIC est disponible sur le port configuré 
add_header Alt-Svc 'h3=":$server_port"; ma=86400'; 

# signale si nous utilisons QUIC+HTTP/3
add_header X-protocol $server_protocol always; 

#proxy_pass <groupe_en_amont>; 
    #racine /<répertoire_racine>; 
}

Alternativement, il existe des outils comme l'extension Chrome HTTP Indicator qui indiquent visuellement le protocole utilisé. (Notez qu’il ne s’agit pas d’une approbation d’une quelconque extension de navigateur et vous devez vous assurer que toutes les implications possibles en matière de sécurité d’une extension sont acceptables compte tenu de votre situation).

Et ensuite ?

Nous continuerons à fournir notre solution pour QUIC+HTTP/3 et à fournir davantage d’exemples d’optimisations NGINX dans les semaines à venir. En attendant, veuillez partager les résultats de vos propres tests pour nous aider à prendre nos décisions. Vous pouvez partager vos commentaires sur la liste de diffusion de développement NGINX et sur le canal #quic‑http3 sur NGINX Community Slack .

Pour recevoir des mises à jour sur notre travail sur QUIC+HTTP/3, y compris la prochaine étape importante – la fusion du dépôt nginx-quic dans la branche principale NGINX Open Source – abonnez-vous à la liste de diffusion des annonces NGINX .

Regardez le webinaire

Nous vous encourageons également à assister à notre prochain webinaire, Get Hands-On with NGINX and QUIC+HTTP/3, le mercredi 19 avril 2023 :

• Amérique du Nord – 10h00 PST
• EMEA – 11h00 CET
• APCJ – 10h00 SGT