Bases de la compatibilité HTTP/3 et QUIC dans le navigateur

HTTP/3 est la version de HTTP qui s’exécute sur QUIC. QUIC fournit un transport chiffré et multiplexé sur UDP, tandis que HTTP/3 définit l’utilisation de ce transport pour les requêtes et les réponses. Un navigateur et une origine compatibles peuvent utiliser HTTP/3, mais le navigateur choisit encore un protocole adapté à la destination et au réseau actuel. Lorsque QUIC est indisponible, il peut poursuivre avec HTTP/2 sur un autre transport si la politique l’autorise. HTTP/3 élargit les chemins possibles; il ne garantit pas que chaque requête utilise le même protocole.

HTTP/3 et QUIC ont des rôles différents

La RFC 9114 définit HTTP/3 et place sur QUIC les méthodes, en-têtes, flux et codes d’état HTTP. La RFC 9000 définit les connexions, flux, mécanismes de récupération après perte et fonctions de sécurité de QUIC. Cette distinction rend les vérifications de compatibilité plus précises: le navigateur peut implémenter correctement HTTP/3 alors qu’un chemin, un pare-feu ou la destination empêche l’utilisation de QUIC.

QUIC utilise UDP, mais ne consiste pas à envoyer des paquets UDP arbitraires pour une application. Le navigateur et le serveur établissent une liaison de protocole, négocient versions et paramètres de transport, puis chiffrent les données applicatives. Une page ne peut pas remplacer cette négociation avec JavaScript. Une navigation HTTPS réussie ne révèle pas non plus la version HTTP utilisée pour chaque sous-requête.

Cette distinction aide aussi à lire les journaux d’exploitation. HTTP/3 désigne le protocole de requête; QUIC désigne le transport de ses flux. Une connexion peut porter de nombreux flux indépendants: une perte touchant l’un d’eux n’apparaît donc pas nécessairement à la page comme une connexion interrompue. La sémantique HTTP reste familière: l’application reçoit réponses, codes d’état, en-têtes et corps. C’est le comportement du transport sous-jacent qui change.

QUIC comporte sa propre négociation de version et des identifiants de connexion. Ceux-ci aident une connexion à survivre à certains changements de chemin, mais ne donnent pas au site le contrôle de la route et ne garantissent pas un service ininterrompu. Une nouvelle association NAT, un délai d’expiration du pare-feu ou une politique du fournisseur peuvent encore interrompre la connexion. L’identifiant est un état du protocole, pas une identité stable de l’utilisateur ou du réseau.

Le chiffrement protège les paquets QUIC et les données HTTP/3, sous réserve des vérifications habituelles des certificats TLS et de confiance du point de terminaison. HTTP/3 ne supprime pas la nécessité de valider les certificats, protéger les identifiants et vérifier où un proxy termine une connexion. Il ne cache pas non plus à tous les observateurs réseau que le client se connecte à une destination. Le chiffrement du protocole et la politique de confidentialité répondent à des questions différentes.

Le modèle en flux de HTTP/3 peut améliorer le comportement d’une application en présence de pertes, mais ne garantit pas un gain de latence fixe. La congestion, l’ordonnancement du serveur, la taille des requêtes, le cache et le chemin entre navigateur et origine comptent aussi. Une vérification doit mesurer le parcours utile au client et éviter de promettre un pourcentage d’amélioration sur la seule base du nom du protocole.

Négociation et changement de protocole dans le navigateur

Le navigateur découvre les protocoles disponibles pour une origine grâce à son implémentation réseau et à des signaux comme une annonce HTTP Alt-Svc. Il peut essayer HTTP/3 lors d’une connexion ultérieure, réutiliser une connexion existante ou poursuivre avec HTTP/2. Le calendrier, la durée du cache, la stratégie d’essais concurrents et l’ordre de préférence dépendent de l’implémentation. L’aperçu HTTP/3 de MDN apporte du contexte sans promettre un comportement identique entre versions.

Le repli est une règle de disponibilité. Lorsque HTTP/3 n’est pas choisi, la page doit préserver la tâche: afficher la réponse, conserver les données du formulaire et proposer une nouvelle tentative limitée si une requête nécessaire échoue. N’envoyez pas une seconde requête incontrôlée simplement parce que le code applicatif ne voit pas les tentatives internes du navigateur. Si un service exige HTTP/3, inscrivez cette exigence dans le contrat de déploiement et définissez une récupération compréhensible.

La première requête et les suivantes peuvent suivre des décisions différentes. Sans indication en cache que l’origine prend en charge HTTP/3, le navigateur peut utiliser HTTP/2 lors de la première visite puis apprendre une préférence ultérieure dans une réponse Alt-Svc. Le cache peut expirer, le profil peut être remplacé ou le réseau peut changer entre deux visites. Une connexion déjà ouverte peut aussi être réutilisée après un changement d’environnement. Une seule visite ne constitue donc pas un test complet de compatibilité.

Le choix du protocole est propre à une origine et à une connexion. Le document peut arriver en HTTP/2 alors qu’une image, une police, une API ou une requête analytique d’une autre origine utilise HTTP/3. Une redirection peut changer d’origine et de politique. Les travailleurs de service et les pools de connexions ajoutent un état de cycle de vie. Testez les requêtes importantes pour l’application sans résumer toute la page par une étiquette de protocole unique.

En cas d’échec, distinguez une erreur de transport d’une réponse HTTP. Un délai dépassé avant toute réponse, une connexion refusée et une réponse HTTP 503 sont des entrées différentes pour l’application. La page peut proposer la même récupération accessible lorsque c’est pertinent, mais l’exploitation doit conserver une catégorie brève qui indique le responsable. N’exposez pas de détails de paquets, d’adresses brutes ou d’identifiants dans un message destiné à l’utilisateur pour prouver qu’un repli a eu lieu.

Le repli acceptable fait partie de la conception du produit. Un document ou un formulaire peut continuer en HTTP/2 sans changer de sens. Une fonction temps réel peut nécessiter un chemin compatible UDP et doit alors signaler son indisponibilité si ce chemin ne peut pas être établi. Une amélioration facultative peut être omise tandis que la tâche principale reste disponible. Décidez de ces cas avant le déploiement afin qu’un délai d’attente ne provoque pas une connexion directe non approuvée.

Une mise à jour du navigateur peut modifier l’ordre des essais, la durée de conservation d’une annonce ou les conditions de réutilisation d’une connexion. Le contrat applicatif doit donc décrire résultats et récupération, pas les temporisateurs internes. Pour comparer deux versions, consignez la version majeure du navigateur et le paquet de profil, puis exécutez le même parcours avec chacune.

Les intermédiaires réseau modifient le résultat

Pare-feu, passerelles d’entreprise, comportement NAT, proxys et politiques de destination peuvent affecter l’accès à UDP. Un réseau peut autoriser HTTPS tout en bloquant ou limitant QUIC. Un proxy peut accepter un tunnel HTTPS sans accepter l’opération UDP nécessaire à HTTP/3. L’origine peut également préférer HTTP/2 ou désactiver temporairement HTTP/3. Ce sont des conditions de compatibilité distinctes, pas des preuves d’incohérence du navigateur.

Testez avec des points de contrôle que vous gérez. Notez la version du navigateur, le profil, l’environnement de l’hôte, la politique de route, la capacité de l’origine et le résultat visible. Couvrez réussite HTTP/3, solution HTTP/2, blocage UDP et origine sans annonce HTTP/3. Gardez captures de paquets, identifiants et historique des destinations dans les systèmes contrôlés; un guide public n’en a pas besoin.

Séparez les deux segments de la connexion. Le navigateur peut joindre le proxy avec un transport et le proxy joindre l’origine avec un autre. Une passerelle d’entreprise peut terminer TLS, relayer un tunnel HTTPS ou appliquer une politique qui désactive UDP. Un répartiteur peut annoncer HTTP/3 pour un nom d’hôte alors qu’un nom voisin ne sert que HTTP/2. Consignez l’origine et la politique utilisées afin de ne pas attribuer un repli à la mauvaise couche.

La disponibilité d’UDP ne se réduit pas à l’ouverture d’un port. Les associations NAT peuvent expirer pendant une période inactive; les pare-feu peuvent imposer un délai d’inactivité et un réseau peut laisser passer de petits datagrammes tout en supprimant les plus grands. La validation de chemin et la découverte de taille de paquet de QUIC répondent à ces conditions, mais le navigateur ne peut pas réparer chaque équipement intermédiaire. Une application avec une connexion longue doit prévoir un état de reconnexion et ne pas traiter automatiquement celle-ci comme une nouvelle session sans vérifier ses propres règles d’état.

Les proxys exigent un contrat explicite. Un proxy HTTP peut transporter des requêtes ordinaires et un tunnel HTTPS CONNECT sans transporter de paquets QUIC. Un service SOCKS5 peut proposer un relais UDP, mais cette capacité et sa politique sont distinctes du support HTTP/3. Un proxy compatible QUIC peut aussi avoir des limites de compte, région, concurrence ou point de terminaison. Ne déduisez pas ces capacités du schéma ou du nom commercial; confirmez les opérations prises en charge pour le compte et le point de terminaison réels.

Les vérifications TLS et de certificat restent visibles au point où TLS se termine. Si une passerelle administrée inspecte le trafic, sa configuration de confiance et sa politique de certificats font partie de la frontière de déploiement. Un avertissement du navigateur ne justifie pas la désactivation de la validation. Classez plutôt l’échec comme problème de confiance ou de politique, rétablissez le chemin de certificats approuvé puis répétez le parcours HTTP/3. Le diagnostic du transport ne doit pas affaiblir la sécurité de la connexion.

L’observabilité doit rester limitée. Le dossier de version peut contenir version majeure du navigateur, famille de profil, classe d’hôte, nom de route, catégorie de destination, résultat du protocole et action de récupération. Un identifiant de requête court peut relier les journaux du navigateur et du service sans conserver URL complètes, captures ou adresses brutes. Ne gardez des traces détaillées que dans le système contrôlé et pendant la durée minimale nécessaire à l’examen de l’incident.

La compatibilité des intermédiaires peut varier selon le lieu et le moment. Testez dans la région et avec le niveau de compte utilisés en production; recommencez après un changement de fournisseur, pare-feu, navigateur ou profil. Un succès dans un bureau ne certifie pas tous les réseaux distants. La formulation publique doit décrire la combinaison testée et ses conditions, pas prétendre que HTTP/3 fonctionne partout.

Vérifier une version du navigateur sans risque

Comparez le même parcours applicatif avant et après un changement de navigateur ou de réseau. Confirmez que le navigateur démarre avec le profil prévu, atteint l’état de page attendu et suit la solution documentée si QUIC est indisponible. Mesurez le résultat utile à l’application plutôt que de traiter une étiquette de protocole comme une note de qualité.

BotBrowser prend en charge le routage proxy par contexte, ce qui permet de répéter une politique réseau approuvée pendant l’examen d’un parcours HTTP/3. BotBrowser ne peut pas forcer l’origine à négocier HTTP/3 ni contrôler chaque équipement intermédiaire, route de fournisseur ou choix de protocole. Le navigateur peut utiliser HTTP/2 ou échouer selon la politique configurée; conservez une solution approuvée et une récupération visible dans le dossier de version. Voir le proxy par contexte, la validation des versions du navigateur et le routage proxy QUIC.

Utilisez une politique par contexte lorsque plusieurs parcours approuvés d’un même processus requièrent des routes différentes. Créez le contexte, appliquez la route avant d’ouvrir la première page et inscrivez le nom de route à côté du responsable du contexte. Cela aide à distinguer un repli dû au navigateur, à la route choisie ou à l’origine. Le paramètre de contexte ne garantit pas le choix de protocole de l’origine.

Pour rendre l’examen reproductible, regroupez cinq éléments: version du navigateur, paquet de profil correspondant, hôte et environnement d’affichage, politique réseau et parcours applicatif. Dans la mesure du possible, ne changez qu’un élément à la fois. Si une version candidate échoue, restaurez d’abord la combinaison acceptée, confirmez le parcours puis étudiez le changement. Modifier simultanément navigateur, proxy, profil et application supprime toute référence fiable.

Une matrice réduite reste utile. Incluez une première visite sans cache préalable, une visite ultérieure, une origine HTTP/3, une origine HTTP/2 uniquement, un blocage UDP contrôlé et la récupération attendue par l’utilisateur. Pour chaque ligne, consignez réussite ou échec limité, pas une version supposée à partir du titre de page. Répétez après une mise à jour majeure du navigateur ou un changement de fournisseur et gardez une solution approuvée pendant les essais.

Les consignes de support doivent indiquer l’action suivante. Un identifiant proxy invalide, un fournisseur qui ne prend pas en charge l’opération, une origine qui n’annonce pas HTTP/3 et un chemin UDP bloqué relèvent de responsables différents. Une courte catégorie et le nom de route suffisent généralement à aiguiller le cas. N’incluez pas dans un ticket URL de proxy, secret, historique complet des destinations ou données de paquets brutes.

La même discipline vaut pour les performances. Comparez première page utilisable, fin d’appel API, disponibilité média ou téléchargement avec le même profil, hôte, région et version applicative. Gardez la route acceptée disponible pendant la mesure candidate. Si le résultat change, restaurez la configuration acceptée avant de modifier une autre variable. Le résultat reste ainsi exploitable sans transformer le protocole en empreinte ou en promesse universelle.

Avant la promotion, déterminez si l’application exige HTTP/3 précisément ou seulement une requête sécurisée et fiable. Si HTTP/2 convient, documentez-le comme solution normale. Si une fonction a réellement besoin d’un chemin UDP, définissez un état d’indisponibilité visible et une récupération approuvée. Le dossier doit dire quel résultat est accepté, quelle route a été testée et qui agit si QUIC ne peut pas être utilisé.

Liste synthétique de compatibilité.

Commencez par le besoin applicatif. HTTP/2 peut suffire si l’application exige une requête chiffrée et une page réactive sur la route approuvée. Si elle dépend d’une propriété propre à QUIC, nommez cette propriété et définissez ce que verra l’utilisateur si elle manque.

Vérifiez séparément l’origine: elle doit accepter HTTP/3 et l’annoncer selon le mécanisme utilisé par le navigateur. Un enregistrement DNS, une connexion TCP réussie ou une page HTTPS chargée ne prouvent pas que l’origine a accepté HTTP/3. Utilisez un point de contrôle que vous gérez ou un rapport du service indiquant le résultat sans exposer de contenu client.

Vérifiez ensuite le chemin. Confirmez que l’hôte, le pare-feu, la passerelle d’entreprise, le proxy, le NAT et le compte fournisseur autorisent le trafic QUIC requis. Gardez équivalentes les routes de test et de production pour le point de terminaison, la région, le niveau de compte, l’authentification et la concurrence. Un essai depuis un réseau domestique sans restriction ne qualifie pas une route de production administrée.

Vérifiez enfin le navigateur: consignez sa version majeure, le paquet de profil, la famille du système et le mode avec ou sans interface. Répétez une première visite sans cache préalable puis une visite ultérieure, car les annonces de protocole et la réutilisation de connexion peuvent changer le premier résultat. Évaluez l’état atteint par le parcours, pas seulement l’apparence normale de la page.

Si une ligne échoue, appliquez la correction la plus ciblée. L’absence d’annonce relève du service; UDP bloqué, du réseau; une capacité proxy manquante, du fournisseur ou du déploiement; une régression navigateur ou profil, de la validation de version. N’affaiblissez pas les certificats, n’ignorez pas la politique et ne forcez pas une connexion directe pour faire réussir l’essai.

Décrivez la solution de repli en termes compréhensibles. Une page de contenu peut continuer en HTTP/2; une fonction temps réel facultative peut être signalée indisponible puis réessayée ultérieurement. Précisez le nombre de tentatives, l’état à préserver et le responsable du prochain examen.

Définissez quand relancer la matrice: mise à jour majeure du navigateur, changement de profil, migration fournisseur, nouvelle politique de pare-feu, changement de région ou modification importante de l’origine. Un succès passé n’est pas une garantie permanente; rattachez la conclusion à la version, la route, l’origine et au résultat observés.

Sources

• RFC 9114 : HTTP/3
• RFC 9000 : transport QUIC
• MDN : HTTP/3
• BotBrowser : proxy par contexte