10. HTTP/3 : QUIC, pertes et garanties restantes

Comprendre le mécanisme

HTTP/3 utilise QUIC comme transport au lieu d’un transport TCP classique pour ses échanges. Des flux de transport distincts réduisent certaines formes de blocage entre eux en cas de perte réseau. Ce changement ne supprime pas toutes les dépendances : le contrôle de congestion, le traitement applicatif et les relations entre données peuvent encore retarder des opérations. La sémantique des méthodes et des statuts reste celle de HTTP.

Raisonner et vérifier

Vérifiez les capacités réelles du client, du frontal et des réseaux traversés, ainsi que la stratégie de repli. Le succès d’une connexion de test n’est pas une preuve de performance universelle. Mesurez pertes, latence, consommation et comportement lors d’un changement de chemin. Continuez à appliquer authentification, autorisation, limites de travail et idempotence : QUIC ne remplace pas ces contrôles.

Transport QUIC

HTTP/3 utilise QUIC comme transport. Le transport et son multiplexage diffèrent. HTTP/3 porte les échanges HTTP sur QUIC. La version effectivement négociée doit être observée dans la trace client ; une capacité annoncée par le serveur ne prouve pas son usage par cette demande.

Blocages entre streams

Des streams QUIC évitent certains blocages entre streams liés à TCP. Le travail serveur et les dépendances restent des causes d’attente. QUIC évite certains blocages entre streams associés à la livraison ordonnée TCP. Cela ne supprime pas les attentes de congestion, de dépendance applicative ou de verrou en base de données.

Autorisation

Les règles d’autorisation restent applicatives. La protection du transport ne décide pas des droits métier. La demande qui arrive via HTTP/3 doit encore être contrôlée sur acteur et ressource. Une amélioration du transport ne modifie pas les règles de propriété d’une réservation ou d’un document.

Budgets

Une limite de taille reste nécessaire. Les ressources de calcul et stockage restent finies. Conservez limites de taille et de travail par opération. Le transport ne transforme pas un upload géant ou une archive très coûteuse à extraire en entrée admissible pour l’application.

Chemin réseau

Le chemin réseau doit supporter le transport choisi. Les politiques et équipements peuvent affecter le passage. Pare-feu, équipements et clients doivent supporter le transport choisi. Vérifiez les conditions réelles de connexion avant d’attribuer une différence de performance au seul code du serveur d’origine.

Repli observé

Le repli doit être observé lors des tests. Le client peut avoir utilisé une autre version. Un service peut annoncer h3 mais cette requête négocier h2. Rapportez le protocole mesuré et les causes de repli pertinentes afin que le résultat reste interprétable et reproductible.

Canal et donnée

Une connexion sécurisée ne rend pas toute donnée métier fiable. L’identité et les entrées doivent toujours être validées. Un canal protégé peut transporter une entrée malformée ou hostile envoyée par un client authentique. Validation et contrôle métier restent des responsabilités propres à l’application après réception.

Corrélation

Les erreurs doivent être corrélées au bon saut. Un proxy peut traduire les protocoles. Le proxy public et l’origine peuvent employer des versions différentes. Conservez le saut et l’opération associés à l’erreur pour éviter de diagnostiquer le mauvais transport ou le mauvais composant.

Performance mesurée

La performance dépend des conditions testées. Topologie et charge influencent les résultats. Comparez avec mêmes données, charge et conditions de perte représentatives. Une mesure locale unique ne démontre pas une amélioration pour tous les réseaux ou tous les profils de client.

Caches

Les caches conservent un contrat de représentation. Le changement de transport n’élimine pas la sémantique du cache. Fraîcheur, portée et variantes restent définies par la sémantique HTTP. Migrer de transport ne corrige pas une réponse personnelle marquée public ou une clé de cache qui oublie le tenant.

Atelier guidé : lire, expliquer et vérifier le code

Advertised capability: h3
Negotiated protocol for this request: h2
Status: 200

La capacité annoncée est h3 mais le protocole négocié est h2. Cette demande ne fournit donc aucune mesure directe de HTTP/3. Relevez le protocole effectif, vérifiez le chemin réseau et comparez ensuite des scénarios contrôlés sans attribuer au transport une garantie de reprise métier.

L’annonce ne prouve pas le protocole utilisé. Le statut ne décrit pas le transport négocié. Le contexte peut conduire à une autre version. La négociation mesurée porte sur h2.

Travail pratique : Préparez une comparaison contrôlée d’un parcours en HTTP/2 et HTTP/3 avec une perte réseau simulée et un repli autorisé.

Critères de correction : Conservez le même contenu et la même charge, vérifiez le protocole effectivement négocié et comparez les mesures. Documentez les conditions au lieu de promettre une accélération absolue pour tous les utilisateurs.