Pipelining HTTP

Un article de Wikipédia, l'encyclopédie libre.

Vous avez de nouveaux messages (diff^?).

Tout ou partie de cet article est soumis à un désaccord de pertinence. Son contenu doit être considéré avec précaution jusqu'à disparition de cet avertissement. Pour toute information complémentaire sur les points remis en cause, consulter la page de discussion associée.

[modifier] Principe du pipelining

Dans la version 1.0 du protocole HTTP, le client doit effectuer une nouvelle connexion avec le serveur pour chaque objet (page,image,etc.) demandé. Il faut donc non seulement initialiser une nouvelle connexion à chaque fois mais en plus attendre le résultat de celle-ci avant de commencer la suivante. La technique du pipelining utilise les connexions persistantes (plusieurs requêtes avec la même connexion). L'avantage du pipelining est que l'on peut effectuer plusieurs requêtes sans attendre les résultats. Cela a pour effet de supprimer le temps de latence entre les requêtes et diminuer le nombre de "handshake" pour initialiser la connexion avec le serveur.

Pour effectuer des connexions persistentes entre le client et le serveur, il faut que ceux-ci utilisent tous les deux le protocole HTTP version 1.1. Lorsque le client établit une connexion TCP avec le serveur et envoie une requête HTTP, il lui transmet la version qu'il utilise. Si c'est la version 1.1, le serveur supposera par défaut qu'il s'agit d'une connexion persistante sauf si le client envoie "Connection: close" dans l'en-tête. D'ailleurs, le client enverra cet en-tête lors de sa dernière requête pour signifier au serveur de terminer la connexion une fois la dernière réponse envoyée. Le client devrait attendre la première réponse du serveur pour connaître sa version. Si celui est bien en HTTP/1.1 le client pourra alors utiliser le pipelining pour les requêtes suivantes.

[modifier] Avantages du pipelining

Voici les avantages des connexions persistantes utilisant le pipelining tels qu'il sont décris dans la spécification du protocole HTTP/1.1 (RFC 2616) :

En ouvrant et fermant moins de connexions TCP, du temps CPU est économisé dans les routeurs et les hôtes (clients, serveurs, proxies, gateways,tunnels ou caches), et ces derniers économisent la mémoire utilisée pour les blocs de contrôle du protocole TCP.
les requêtes et les réponses peuvent être envoyées en pipeline dans une connexion. Cela permet à un client d'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.
La congestion du réseau est diminuée par la réduction du nombre de paquets dus à l'ouverture de la connexion TCP, et par le fait qu'on laisse suffisamment de temps à TCP pour déterminer l'état de congestion du réseau.
La latence est réduite pour les requêtes suivantes puisqu'on ne perd pas de temps à cause de l'initialisation de la connexion TCP (handshake)
HTTP peut évoluer plus facilement comme les erreurs peuvent être reportées sans que la connexion TCP ne soit fermée. Les clients utilisant des versions futures de HTTP pourront utiliser de nouvelles fonctionnalités, et s'il s'avère qu'ils communiquent avec de vieux serveurs, ils pourront réessayer avec une ancienne sémantique si une erreur leur est renvoyée.

[modifier] Problèmes liés au pipelining

Certaines études ont remarqué des interférences entre les connections persistantes utilisant le pipelining et l'algorithme de Nagle (utilisé par défaut dans le protocole TCP). Cet algorithme consiste à agréger les petites données dans un même paquet avant de les envoyer si on est en attente d'un Ack. Cet algorithme est d'ailleurs désactivé dans le serveur Apache. Pour plus de détails, on peut consulter le papier de Heidemann. Le protocole HTTP 1.1 est apparemment plus lent que le protocole HTTP 1.0 lorsque le pipelining n'est pas activé. En effet dans la version 1.0, on effectue plusieurs connexions simultannées au serveur.

Par ailleurs, dans certains cas, le pipelining perd son intérêt quand une requête échoue et doit être retentée. C'est le cas de l'identification (ou authentification) quand une réponse 401 ou 407 est retournée par le serveur, ou des redirections (code HTTP 3xx).

[modifier] Pipelining et proxies

Un problème majeur est que le proxy doit absolument renvoyer les réponses au client dans l'ordre où il a reçu les requêtes. En effet quand le client dialogue directement avec le serveur, celui-ci lui renvoie les réponses dans l'ordre sans causer de problèmes. Etant donné que le client peut accéder à différents serveurs en même temps à travers le proxy, il faut que le proxy conserve l'ordre de toutes les requêtes. Différents modèles permettant de surmonter cette difficulté sont expliqués dans la page en anglais sur le pipelining donnée dans les liens. Pour atteindre une efficacité optimale, le serveur peut utiliser le pipelining sur les connexions persistantes avec les serveurs et doit parfois stocker les réponses pour pouvoir les renvoyer dans l'ordre au client.