Pipelining HTTP

Le pipelining HTTP est une technique consistant à combiner plusieurs requêtes HTTP dans une seule connexion TCP sans attendre les réponses correspondant à chaque requête.



Catégories :

HTTP - Standard du Web

Le pipelining HTTP est une technique consistant à combiner plusieurs requêtes HTTP dans une seule connexion TCP sans attendre les réponses correspondant à chaque requête.

Le pipelining présente plusieurs avantages :

Le pipelining nécessite, de la part du client autant que du serveur, le support de la norme HTTP 1.1 telle que décrite dans la RFC 2616.

Principe

Schéma de connexions avec et sans pipelining

Dans la version 1.0 du protocole HTTP, le traitement des requêtes est séquentiel. Le client doit effectuer une nouvelle connexion TCP avec le serveur pour chaque objet (page, image, etc. ) demandé et attendre le résultat avant de pouvoir poursuivre avec la requête suivante.

La technique du pipelining contourne ce problème en exploitant le principe de connexion persistante (keepalive). Quand le client envoie une requête HTTP au serveur, ce dernier inclut dans sa réponse la version du protocole HTTP utilisée. Si les deux extrémités utilisent HTTP 1.1, la connexion sera par défaut persistante. Le client doit indiquer qu'il souhaite fermer la connexion persistante avec le message "Connection : close" quand il ne souhaite plus utiliser la connexion.

Le pipelining peut dans ce cas prendre place sans autre négociation. Il consiste à envoyer plusieurs requêtes à la suite sans attendre leurs résultats. Le serveur HTTP a l'obligation de renvoyer les réponses précisément dans le même ordre que les requêtes.

On remarquera que dans la mesure où il est indispensable qu'il y ait un échange complet entre client et serveur pour s'assurer qu'ils supportent bien l'ensemble des deux HTTP 1.1, les requêtes constituant une nouvelle connexion ne peuvent pas être l'objet du pipelining. De même, seules les requêtes idempotentes[1] — telles que GET, HEAD, PUT et DELETE — peuvent faire l'objet du pipelining.

Avantages

L'utilisation du pipelining hérite plusieurs avantages de l'utilisation des connexions persistantes. Ces avantages sont résumés dans la section 8.1.1 de la RFC 2616 décrivant le protocole HTTP 1.1. Surtout :

L'avantage supplémentaire à l'utilisation du pipelining est qu'un client peut effectuer plusieurs requêtes sans attendre chaque réponse, permettant à une seule connexion TCP d'être utilisée avec plus d'efficacité, dans un temps plus court. Le concept est identique aux mécanismes de fenêtre glissante dans TCP ou fenêtre d'anticipation dans HDLC.

Problèmes

Le W3C a conduit en 1997 une étude sur les performances obtenues grâce aux nouveaux standards de l'époque qu'étaient HTTP 1.1, CSS1 et PNG. L'application construite à l'occasion de ces tests utilisait le pipelining. Les résultats ont montré que HTTP 1.1 avec connexions persistantes et pipelining réduisait d'un facteur 6 le nombre de paquets envoyés mais introduisait une latence supplémentaire d'un facteur 1.5 à la grande surprise des auteurs. HTTP 1.1 est dans l'ensemble des cas plus rapide avec pipelining que sans.

Les auteurs de l'étude ont conclu à une envisageable interférence entre le pipelining et l'algorithme de Nagle mis en œuvre par TCP. Ce dernier effectue en effet, au niveau 4 du modèle OSI, le même type de mise en tampon des données que le pipelining au niveau 7. Cette succession de mise en tampon introduit un délai supplémentaire à l'envoi des données. C'est pourquoi il est recommandé pour les clients et les serveurs utilisant HTTP 1.1 avec pipelining de désactiver purement et simplement l'algorithme de Nagle, ce qui est généralement envisageable dans l'interface BSD socket via l'option TCP_NODELAY.

Ce problème avait aussi été identifié en 1997 par John Heidemann dans une étude portant sur les connexions persistantes dans HTTP. Il l'avait dans ce cas nommé "Short-Signal-Segment Problem". Plusieurs autres problèmes provenant d'interaction entre TCP et HTTP 1.1 sont abordés dans son étude mais concernent les connexions persistantes et pas uniquement le pipelining.

D'autre part, le pipelining perd son intérêt quand une requête est bloquante et nécessite d'attendre son résultat pour pouvoir procéder à l'envoi de requêtes HTTP subséquentes. En cas d'échec on doit dans ce cas retenter la requête. Aucune ressource n'est par conséquent économisée au niveau de TCP. Un tel cas de figure se produit par exemple quand un client reçoit des réponses 401 ou 407 ou même des redirections 3xx (voir Liste des codes HTTP) en réponse à une HTTP Authentification.

Pipelining et serveurs mandataires

La RFC 2616 indique que quand une connexion fait l'objet de pipelining, les réponses doivent être envoyées dans le même ordre que les requêtes. Quand un serveur mandataire se trouve entre le serveur et le client, il doit par conséquent en faire. Or un client peut accéder à plusieurs serveurs simultanément à travers le serveur mandataire, imposant à ce dernier de conserver en mémoire l'ordre des requêtes pour chaque paire client/serveur.

Cette opération s'avère rapidement complexe quand on augmente le nombre de clients et implique de temporiser les réponses pour pallier les problèmes de déséquencement qui peuvent apparaître dans un réseau TCP/IP[2]. Les difficultés augmentent toujours quand on tente de profiter du serveur mandataire pour répartir la charge sur plusieurs serveurs web.

Implémentations

La norme HTTP 1.1 impose de supporter le pipelining sans pour tout autant rendre son usage obligatoire. Ce sont les clients qui prennent la décision d'utiliser le pipelining si le serveur le supporte.

La plupart des serveurs mandataires sont capables de servir un client qui fait du pipelining. Cependant, ils ne sont pas capables d'envoyer des requêtes pipelinées vers le serveur en amont.

La seule exception connue est Polipo, qui utilise le pipelining de façon agressive. Voir The Polipo Manual : 1.4.2 Pipelining.

Références

Notes

  1. (en) Voir RFC 2616, section 9.1.2, Idempotent Methods
  2. (fr) Gestion d'une connexion HTTP avec pipelining dans un proxy
  3. (en) Voir Firefox Help : Tips & Tricks, Enable pipelining.
  4. (en) Voir Opera 4.0 Upgrades File Exchange : Includes HTTP 1.1.
  5. (en) Voir IE7 MSDN blog.
  6. (en) Voir Microsoft Internet Information Server Ressource Kit, Chapter 1.

Recherche sur Google Images :



"Schéma de connexions avec et sans ..."

L'image ci-contre est extraite du site fr.wikipedia.org

Il est possible que cette image soit réduite par rapport à l'originale. Elle est peut-être protégée par des droits d'auteur.

Voir l'image en taille réelle (400 x 249 - 14 ko - png)

Refaire la recherche sur Google Images

Recherche sur Amazone (livres) :



Ce texte est issu de l'encyclopédie Wikipedia. Vous pouvez consulter sa version originale dans cette encyclopédie à l'adresse http://fr.wikipedia.org/wiki/Pipelining_HTTP.
Voir la liste des contributeurs.
La version présentée ici à été extraite depuis cette source le 11/03/2009.
Ce texte est disponible sous les termes de la licence de documentation libre GNU (GFDL).
La liste des définitions proposées en tête de page est une sélection parmi les résultats obtenus à l'aide de la commande "define:" de Google.
Cette page fait partie du projet Wikibis.
Accueil Recherche Aller au contenuDébut page
ContactContact ImprimerImprimer liens d'évitement et raccourcis clavierAccessibilité
Aller au menu