Blocage de tête de file

En réseau informatique, le head-of-line blocking (blocage de tête de file, ou HOL blocking) désigne un goulot d'étranglement de performance qui se produit lorsqu'une file d'attente de paquets est bloquée par le premier paquet, même si d'autres paquets pourraient être traités.

En HTTP/1.1, les requêtes sur une même connexion TCP sont généralement envoyées de façon séquentielle — une nouvelle requête ne peut pas être envoyée tant qu'une réponse à la précédente n'a pas été reçue. Cela peut entraîner des problèmes de blocage de tête de file même s'il existe plusieurs connexions TCP entre le client et le serveur.

HTTP/1.1 définit une fonctionnalité optionnelle appelée HTTP pipelining qui a tenté, sans succès, de contourner ce blocage en permettant d'envoyer des requêtes sans attendre les réponses précédentes. Malheureusement, la conception d'HTTP/1.1 impose que les réponses soient renvoyées dans le même ordre que les requêtes, donc le blocage de tête de file peut toujours se produire si une requête prend beaucoup de temps. Des conditions réseau comme la congestion, la perte de paquets (et les retransmissions TCP qui en résultent), ou le démarrage lent de TCP peuvent aussi retarder la transmission et bloquer les réponses suivantes.

HTTP/2 réduit le blocage de tête de file au niveau applicatif grâce à l'introduction du multiplexage des requêtes et réponses. Plusieurs requêtes et réponses peuvent ainsi être entrelacées sur une seule connexion TCP à l'aide de flux numérotés indépendamment, et la priorisation des flux aide le serveur à décider lesquels envoyer en premier. Cependant, une perte de paquet au niveau transport peut toujours provoquer un blocage de tête de file sur tous les flux, car HTTP/2 fonctionne sur TCP : un segment TCP perdu peut bloquer tous les flux de la connexion jusqu'à la retransmission des données perdues.

HTTP/3 élimine le blocage de tête de file au niveau transport en utilisant QUIC sur UDP : le problème de blocage de tête de file n'existe donc plus en HTTP. QUIC fournit plusieurs flux indépendants avec une reprise sur perte par flux, de sorte qu'une perte de paquet n'affecte que le flux concerné et non toute la connexion. Cela supprime le problème de blocage de tête de file au niveau TCP.