HTTP/3 et QUIC

HTTP/3 remplace TCP par QUIC (transport basé sur UDP) pour éliminer le blocage de tête de ligne, réduire la latence de connexion et permettre la reprise de connexion 0-RTT. bext prend en charge HTTP/3 en tant que fonctionnalité Pro, exécutant un écouteur QUIC aux côtés des écouteurs HTTP/1.1 et HTTP/2 existants.

Activation de HTTP/3#

HTTP/3 est opt-in. Ajoutez la section [http3] à votre bext.config.toml :

[http3]
enabled = true
max_concurrent_streams = 100
idle_timeout_ms = 30000

HTTP/3 nécessite TLS 1.3 (QUIC l'impose), vous devez donc également activer TLS :

[tls]
mode = "auto"
acme_email = "ops@example.com"

[http3]
enabled = true

Lorsque les deux conditions sont remplies, bext lie un socket UDP sur le même port que l'écouteur TCP (généralement 443) et commence à accepter les connexions QUIC.

Comment ça marche#

Avec HTTP/3 activé, bext exécute trois écouteurs simultanément :

Tous les trois partagent le même certificat TLS. L'écouteur QUIC utilise le même certificat/clé que l'accepteur TCP TLS, qu'il soit provisionné via ACME, fourni manuellement ou auto-signé.

Publicité d’en-tête Alt-Svc#

Les navigateurs découvrent la prise en charge HTTP/3 via l'en-tête de réponse Alt-Svc. Lorsque HTTP/3 est activé, bext ajoute automatiquement cet en-tête à chaque réponse HTTP/1.1 et HTTP/2 :

Alt-Svc: h3=":443"; ma=86400

Cela indique au navigateur : "Ce serveur prend en charge HTTP/3 sur le même hôte, le port 443, et vous pouvez mettre en cache ces informations pendant 86 400 secondes (24 heures)." Lors des requêtes ultérieures, le navigateur tentera une connexion QUIC.

La valeur ma (âge maximum) contrôle la durée pendant laquelle le navigateur met en cache la publicité Alt-Svc. Une valeur plus longue signifie moins de connexions de secours vers TCP, mais signifie également que les clients mettent plus de temps à arrêter d'essayer QUIC si vous le désactivez.

Reprise de la connexion 0-RTT#

QUIC prend en charge la reprise de connexion 0-RTT (zéro aller-retour). Lorsqu'un client se reconnecte à un serveur qu'il a déjà visité, il peut envoyer des données d'application dans le tout premier paquet, avant la fin de la négociation TLS. Cela réduit la latence perçue d’un aller-retour complet.

bext accepte les données 0-RTT par défaut lorsque HTTP/3 est activé. Gardez à l'esprit que les données 0-RTT sont intrinsèquement rejouables (un attaquant pourrait capturer et renvoyer le paquet initial), donc bext n'autorise que les requêtes idempotentes (GET, HEAD) dans 0-RTT. Les méthodes non idempotentes (POST, PUT, DELETE) sont différées jusqu'à la fin de la négociation.

Paramètres de transport#

La configuration [http3] expose les principaux paramètres de transport QUIC :

[http3]
enabled = true
max_concurrent_streams = 100   # Max simultaneous request streams per connection
idle_timeout_ms = 30000        # Close idle connections after 30 seconds

max_concurrent_streams#

Contrôle le nombre d'échanges de requêtes/réponses HTTP pouvant avoir lieu simultanément sur une seule connexion QUIC. La valeur par défaut (100) convient à la plupart des applications Web. Augmentez-le pour les pages qui déclenchent de nombreuses récupérations de sous-ressources parallèles, ou diminuez-le pour les serveurs API où les connexions sont de courte durée.

idle_timeout_ms#

Le délai d'inactivité pour les connexions QUIC. Après cette période sans transfert de données, la connexion est gracieusement fermée. La valeur par défaut est de 30 secondes. Pour les points de terminaison à interrogation longue ou SSE, envisagez d'augmenter ceci :

[http3]
enabled = true
idle_timeout_ms = 120000   # 2 minutes for long-lived connections

Configuration HTTP/2#

HTTP/2 est activé automatiquement lorsque TLS est actif (aucune configuration requise). Vous pouvez régler ses paramètres dans la section [http2] :

[http2]
enabled = true                  # Default: true when TLS is active
max_concurrent_streams = 100    # Default: 100
initial_window_size = 65535     # Default: 64KB (HTTP/2 spec default)
h2c = false                     # HTTP/2 cleartext (no TLS), for internal networks

L'option h2c active HTTP/2 sur TCP simple, ce qui est utile pour la communication entre les services sur un réseau interne de confiance où la surcharge TLS n'est pas nécessaire.

Compatibilité du navigateur#

Prise en charge de HTTP/3 dans les principaux navigateurs (à partir de 2025) :

Tous les navigateurs modernes prennent en charge HTTP/3 et seront automatiquement mis à niveau lorsqu'ils verront l'en-tête Alt-Svc. Les navigateurs et clients plus anciens qui ne prennent pas en charge QUIC continuent d'utiliser HTTP/2 ou HTTP/1.1 sur TCP de manière transparente.

Comportement de repli#

HTTP/3 est conçu pour coexister avec HTTP/2 et HTTP/1.1. Si une connexion QUIC échoue (UDP bloqué par un pare-feu, problème de chemin réseau ou surcharge du serveur), le navigateur revient immédiatement à TCP. bext gère cela avec élégance :

• L'écouteur TCP est toujours actif quels que soient les paramètres HTTP/3
• Les clients qui ne reçoivent jamais l'en-tête Alt-Svc (connexions proxy, certains réseaux d'entreprise) utilisent TCP dès le départ
• Si l'écouteur QUIC rencontre une erreur au démarrage (port déjà utilisé, socket UDP indisponible), bext enregistre un avertissement et continue le fonctionnement TCP uniquement.

Ce mécanisme de secours signifie que l'activation de HTTP/3 est sûre pour la production : les clients qui peuvent l'utiliser bénéficient d'une latence plus faible, tandis que tous les autres continuent de fonctionner exactement comme avant.

Exemple complet#

Une configuration de production avec toutes les couches protocolaires :

[server]
listen = "0.0.0.0:443"

[tls]
mode = "auto"
acme_email = "ops@example.com"
ocsp_stapling = true

[http2]
max_concurrent_streams = 200
initial_window_size = 131072   # 128KB window for high-bandwidth clients

[http3]
enabled = true
max_concurrent_streams = 200
idle_timeout_ms = 60000

[license]
key = "BEXT-PRO-..."

Cela sert HTTP/1.1, HTTP/2 et HTTP/3 sur le même port avec TLS automatique, agrafage OCSP et de généreuses limites de concurrence.

En rapport#

• TLS et HTTPS — Configuration TLS requise avant d'activer HTTP/3
• Compression — négociation de compression qui s'applique à toutes les couches de protocole
• Modes de déploiement – mode Edge et considérations multi-instances pour les déploiements QUIC
• Opérations : performances — profilage de latence et métriques de connexion
• Architecture : cycle de vie des demandes : chemin de requête complet depuis la prise de contact QUIC jusqu'à la réponse

Links#

• RFC 9000 — Protocole de transport QUIC — la spécification IETF QUIC
• RFC9114 — HTTP/3 — Sémantique HTTP sur QUIC
• MDN : HTTP/3 — prise en charge et présentation du navigateur