Limite de concurrence et problème de blocage de tête de ligne dans le protocole HTTP

Connexions série

Les protocoles HTTP/0.9 et HTTP/1.0 antérieurs sérialisent le traitement des requêtes HTTP. Supposons qu'une page contienne 3 fichiers de style, tous appartenant au même protocole, nom de domaine et port. Ensuite, le navigateur doit lancer un total de quatre requêtes et ne peut ouvrir qu'un seul canal TCP à chaque fois. Après le téléchargement d'une ressource demandée, la connexion est immédiatement déconnectée et une nouvelle connexion est ouverte pour traiter la requête suivante dans la file d'attente. . À mesure que la taille et le nombre de ressources de page continuent d'augmenter, la latence du réseau continuera de s'accumuler. Les utilisateurs seront confrontés à un écran vide et perdront patience après avoir attendu trop longtemps.

Connexion parallèle

Afin d'améliorer le débit du réseau, le protocole HTTP amélioré permet au client d'ouvrir plusieurs TCP connexions en même temps, demandez plusieurs ressources en parallèle et utilisez pleinement la bande passante. Habituellement, il y aura un certain délai entre chaque connexion, mais les temps de transmission des requêtes se chevauchent et le délai global est bien inférieur à celui de la connexion série. Étant donné que chaque connexion consomme des ressources système et que le serveur doit gérer un grand nombre de requêtes utilisateur simultanées, le navigateur fixera certaines limites sur le nombre de requêtes simultanées. Même si la RFC ne précise pas de limite spécifique, chaque fabricant de navigateur aura ses propres standards :

IE 7 : 2
IE 8/9 :6
IE 10 : 8
IE 11 : 13
Firefox : 6
Chrome : 6
Safari : 6
Opéra : 6
iOS WebView : 6
Android WebView : 6

Connexion persistante (connexion longue)

Le premier protocole HTTP occupait une connexion TCP indépendante pour chaque requête, ce qui augmentait sans aucun doute la surcharge d'établissement de la connexion TCP, la surcharge de contrôle de la congestion. , libère la surcharge de connexion, HTTP/1.0 amélioré et HTTP/1.1 (par défaut) prennent tous deux en charge les connexions persistantes. Si une requête est terminée, la connexion ne sera pas déconnectée immédiatement, mais la connexion sera maintenue pendant un certain temps pour traiter rapidement les requêtes HTTP à venir et réutiliser le même canal TCP jusqu'à ce que la détection du rythme cardiaque du client échoue ou que la connexion au serveur expire. . Cette fonctionnalité peut être activée via l'en-tête HTTP Connection: keep-alive. Le client peut également envoyer Connection: close pour fermer activement la connexion. On voit donc que les deux optimisations des connexions parallèles et des connexions persistantes se complètent. Les connexions parallèles permettent à la première page de chargement d'ouvrir plusieurs connexions TCP en même temps, tandis que les connexions persistantes garantissent que les requêtes ultérieures réutilisent les connexions TCP ouvertes. est également un mécanisme courant pour les pages Web modernes.

Connexion au pipeline

Les connexions persistantes nous permettent de réutiliser la connexion pour répondre à plusieurs demandes, mais elle doit répondre aux La séquence de file d'attente FIFO doit garantir que la requête précédente atteint avec succès le serveur, est traitée avec succès et que le premier octet renvoyé par le serveur est reçu avant que la requête suivante dans la file d'attente puisse être lancée. Les canaux HTTP permettent aux clients de lancer plusieurs requêtes successives au sein du même canal TCP sans avoir à attendre une réponse, éliminant ainsi les différences de latence aller-retour. Cependant, en réalité, en raison des limitations du protocole HTTP/1.x, les données ne peuvent pas arriver entrelacées sur un lien (multiplexage IO). Imaginez une situation dans laquelle le client et le serveur envoient une requête HTML et plusieurs requêtes CSS en même temps. Le serveur traite toutes les requêtes en parallèle. Lorsque toutes les requêtes CSS sont traitées et ajoutées à la file d'attente du tampon, il s'avère que le traitement des requêtes HTML est rencontré. un problème et reste bloqué indéfiniment. Dans les cas graves, cela peut même provoquer un débordement de tampon. Cette situation est appelée blocage de tête de ligne. Cette solution n’a donc pas été adoptée dans le protocole HTTP/1.x.

Le blocage de tête de ligne n'est pas un concept unique en HTTP, mais un phénomène courant dans les échanges de réseaux de communication en cache

Résumé

1. Pour le même protocole, nom de domaine et port, le navigateur permet d'ouvrir plusieurs connexions TCP en même temps, et la limite supérieure générale est de 6.
2. La même connexion TCP est autorisée à lancer plusieurs requêtes HTTP, mais vous devez attendre que la réponse du premier octet de la requête précédente parvienne au client.
3. En raison du problème de blocage de la tête de file d'attente, le client n'est pas autorisé à envoyer toutes les requêtes de la file d'attente en même temps. Ce problème a été résolu dans HTTP/2.0.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!