09. HTTP/2 : multiplexage et contraintes partagées

Comprendre le mécanisme

HTTP/2 transporte plusieurs flux sur une connexion avec un encodage binaire et une compression des champs. Ce multiplexage évite certaines contraintes du modèle HTTP/1.1, mais les flux partagent encore des ressources. Sur TCP, une perte de segment peut retarder la progression de plusieurs flux. L’application conserve ses propres files, limites et transactions : un nouveau transport ne corrige pas automatiquement les lenteurs métier.

Raisonner et vérifier

Définissez des limites de concurrence et observez annulations, tailles de champs et coût par requête. Une seule connexion peut porter de nombreux travaux ; limiter uniquement le nombre de connexions ne borne donc pas toute la charge. Mesurez les budgets au niveau des flux et du service, en tenant compte des intermédiaires qui terminent ou traduisent HTTP/2.

Streams concurrents

HTTP/2 peut multiplexer des streams sur une connexion. Plusieurs échanges peuvent partager le transport. Une connexion peut transporter plusieurs échanges simultanés. Distinguez identifiant de connexion et identifiant de stream dans l’observation afin d’attribuer latence, annulation et budgets à la bonne opération.

Compteurs adaptés

Une limite de connexions ne borne pas tous les streams. La concurrence existe aussi dans les streams. Dix connexions autorisées peuvent représenter bien plus de dix demandes actives. Limitez aussi streams et travail applicatif selon la capacité réelle, en particulier pour les opérations lentes ou coûteuses.

Métier inchangé

HTTP/2 conserve les contrôles métier de l’application. Le transport ne décide pas des permissions. Multiplexer ne remplace ni transaction ni autorisation. Une réservation concurrente demande toujours une règle de capacité et un contrôle de propriétaire, même si ses octets arrivent sur un transport plus efficace.

Perte TCP

Le TCP partagé peut affecter plusieurs streams lors d’une perte. Les échanges partagent le canal de transport. HTTP/2 partage TCP ; certaines pertes peuvent retarder plusieurs streams au niveau du transport. Ne promettez pas l’absence de toute attente parce que les échanges HTTP sont logiquement multiplexés.

Ressources

Les limites de ressources restent nécessaires. Le protocole ne crée pas de capacité infinie. Bornez champs, mémoire, opérations actives et temps global. Un client peut créer du travail sans ouvrir beaucoup de connexions ; mesurez aussi le coût d’un stream interrompu après démarrage.

Sauts internes

Le trajet peut changer de version derrière le proxy. La version négociée ne décrit qu’un saut. Le proxy peut traduire vers une autre version. Vérifiez la configuration backend et les budgets de ses connexions ; une optimisation frontale peut déplacer la file d’attente plutôt que la supprimer.

Représentation

Les en-têtes ont une représentation différente sur le fil. Le protocole utilise des frames et une gestion spécifique des champs. HTTP/2 utilise des trames et une représentation de champs différente de la syntaxe textuelle HTTP/1.1. Une trace pédagogique en lignes reste une vue logique et ne décrit pas tous les octets du réseau.

Sémantique conservée

Une requête doit conserver une sémantique de méthode correcte. Le changement de version ne redéfinit pas cette sûreté. GET reste une lecture sûre selon sa sémantique, et une mutation exige toujours un contrat adapté. Le changement de version ne justifie pas une annulation métier cachée dans un lien GET.

Annulations

Les annulations de streams peuvent consommer des ressources. Du travail peut précéder l’annulation. Une remise à zéro de stream peut arriver après consommation de CPU ou début de traitement. Appliquez des protections contre l’abus et vérifiez la propagation d’annulation sans supposer qu’elle annule tout effet durable.

Mesures

Les mesures doivent distinguer connexion et opération. Plusieurs étapes et attentes participent à la durée. Rapportez connexions, streams actifs, demandes applicatives et latences séparément. Une baisse du nombre de sockets ne prouve pas une réduction du nombre d’opérations ni de la charge de la base.

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

HTTP version: 2
Active TCP connections: 1
Active streams on this connection: 40
Policy shown: max_connections = 10

Une connexion TCP porte quarante streams alors que la politique ne montre qu’un plafond de connexions. Ce plafond ne suffit donc pas à borner le travail simultané. Ajoutez limites adaptées et mesurez le nombre d’opérations réellement actives dans l’application et ses dépendances.

Le compteur de connexions ne borne pas à lui seul tous les streams. Le multiplexage permet le partage de la connexion. Cette affirmation contredit le modèle montré. Aucune règle de streams n’est définie.

Travail pratique : Mesurez trois parcours concurrents dont un rapport lent, avec et sans annulation du client.

Critères de correction : Relevez latence par flux et travail réellement interrompu côté application. Vérifiez les limites de requêtes simultanées et le comportement du frontal sous charge de laboratoire. Distinguez attente réseau et saturation métier.