Comment HTTP2 résout-il le problème de blocage de la tête de ligne (HOL)
Comment HTTP2 résout-il le problème de blocage de tête de ligne (HOL)?
Ce problème est très fréquent dans http1.1, mais j'ai entendu que HTTP2 a résolu ce problème. Quelqu'un pourrait-il expliquer exactement comment HTTP2 a résolu le problème?
Blocage de la tête de ligne HTTP
Le blocage de Head of Line en termes HTTP fait souvent référence au fait que chaque navigateur/client a un nombre limité de connexions à un serveur et que faire une nouvelle demande sur l'une de ces connexions doit attendre que celles-ci soient terminées avant de pouvoir se déclencher. il hors tension.
Les requêtes en tête de ligne bloquent les suivantes.
HTTP/2 résout ce problème en introduisant le multiplexage afin que vous puissiez émettre de nouvelles requêtes sur la même connexion sans avoir à attendre que les précédentes se terminent.
En théorie, le pipeline de HTTP/1.1 offrait également un moyen de contourner HOL, mais il était délicat et très sujet aux erreurs à mettre en œuvre dans la pratique. Cela n'a pas permis une large diffusion sur le Web jusqu'à aujourd'hui.
Blocage de la tête de ligne TCP
HTTP/2 souffre cependant encore d'un autre type de HOL, à savoir au niveau TCP. Un paquet perdu dans le flux TCP fait tous les flux attendent que ce paquet soit retransmis et reçu. Ce HOL est adressé avec le protocole QUIC ...
QUIC est un protocole "de type TCP" implémenté sur UDP où chaque flux est indépendant de sorte qu'un paquet perdu arrête uniquement le flux particulier auquel appartient le paquet perdu, tandis que les autres flux peuvent continuer.
HTTP/1 est fondamentalement un protocole de demande et de réponse: le navigateur demande une ressource (que ce soit une page HTML, un fichier CSS, une image ... peu importe) puis attend la réponse. Pendant ce temps, cette connexion ne peut rien faire d'autre - elle est bloquée en attente de cette réponse.
HTTP/1 a introduit le concept de pipelining afin que vous puissiez envoyer plus de demandes pendant que vous attendiez. Cela devrait améliorer les choses car il n'y a plus de retard dans l'envoi des demandes et le serveur peut commencer à les traiter plus tôt. Les réponses doivent toujours revenir dans l'ordre demandé, ce n'est donc pas un vrai protocole multi-requêtes mais c'est une bonne amélioration (si cela a fonctionné - voir ci-dessous). Cela a introduit un problème de blocage de tête de ligne (HOLB) sur la connexion: si la première demande prend beaucoup de temps (par exemple, elle doit effectuer une recherche dans la base de données, puis effectuer un autre traitement intensif pour créer la page), puis toutes les autres demandes sont alignés derrière, même s'ils sont prêts à partir. En fait, à vrai dire, HOLB était déjà un problème même sans pipelining car le navigateur devait de toute façon mettre les demandes en file d'attente jusqu'à ce que la connexion soit libre de l'envoyer - le pipelining a juste rendu le problème plus apparent au niveau de la connexion.
En plus de ce pipelining dans HTTP/1 n'a jamais été aussi bien pris en charge, compliqué à implémenter et pourrait causer des problèmes de sécurité. Donc, même sans le problème HOLB, ce n'était toujours pas utile.
Pour contourner tout cela, HTTP/1 utilise plusieurs connexions au serveur (généralement 6-8) afin qu'il puisse envoyer des demandes en parallèle. Cela nécessite des efforts et des ressources à la fois côté client et côté serveur pour la configuration et la gestion. De plus, les connexions TCP sont assez inefficaces pour diverses raisons et prennent du temps pour atteindre une efficacité maximale - à ce stade, vous avez probablement fait le gros du travail et n'avez plus besoin de connexions multiples.
HTTP/2, d'autre part, a le concept de flux multiplex bidirectionnels intégrés dès le départ. J'ai une explication détaillée de ce qu'ils sont ici: Que signifie le multiplexage dans HTTP/2 . Cela a supprimé la nature bloquante des requêtes HTTP/1, introduit une version bien meilleure, entièrement fonctionnelle et entièrement prise en charge du pipelining et permet même de renvoyer des parties de la réponse entremêlées avec d'autres réponses. Tout cela ensemble résout HOLB - ou plus précisément l'empêche même d'être un problème.
Le seul point à noter est que même si cela résout HTTP HOLB, il est toujours construit sur TCP et il a son propre TCP problème HOLB qui peut être pire) sous HTTP/2 car il s'agit d'une seule connexion! Si un seul paquet TCP est perdu, alors la connexion TCP doit demander qu'il soit renvoyé et attendre ce paquet) être retransmis avec succès avant de pouvoir traiter les packages TCP TCP suivants - même si ces paquets sont destinés à d'autres flux HTTP/2 qui pourraient, en théorie, être traités pendant ce temps (comme cela se produirait sous true distinct connexions sous HTTP/1). Google expérimente l'utilisation de HTTP/2 sur UDP non garanti plutôt que garanti TCP dans un protocole appelé QUIC pour résoudre ce problème et celui-ci est en train d'être également défini comme standard Web (tout comme SPDY - initialement une implémentation de Google - a été normalisé en HTTP/2).