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

[Éditeur : NGINX prend désormais officiellement en charge HTTP/3 avec QUIC. Vous pouvez l’utiliser dans la version principale NGINX 1.25.1 destinée aux utilisateurs de logiciel libre et dans NGINX Plus R30 pour les clients professionnels.]
[ngx_snippet name=’table-style-blog’]
Nous avons le plaisir d’annoncer que notre implémentation préliminaire du support NGINX pour QUIC+HTTP/3 est désormais disponible en packages binaires précompilés 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.

Nous publions des binaires précompilés pour vous permettre de tester NGINX avec QUIC+HTTP/3 plus rapidement et simplement. Vous n'avez plus besoin de compiler le code source : installez-les facilement via les outils standards de gestion de paquets.

Au moment où nous rédigeons ceci, OpenSSL, la norme reconnue pour SSL/TLS open source, ne prend pas en charge QUIC. Nous intégrons donc le package de bibliothèque quictls dans les distributions binaires, installé automatiquement comme dépendance. Nous avons choisi quictls car il offre aujourd’hui le meilleur compromis entre stabilité, compatibilité et 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