Aller au contenu principal

8. Connections (Connexions)

8.1 Persistent Connections (Connexions Persistantes)​

8.1.1 Purpose (Objectif)​

Avant les connexions persistantes, il fallait établir une connexion TCP séparée pour récupérer chaque URL, ce qui augmentait la charge des serveurs HTTP et causait une congestion Internet. L'utilisation d'images en ligne et d'autres données associées nécessite généralement qu'un client effectue plusieurs requêtes au même serveur dans un court laps de temps. Les résultats des analyses de ces problèmes de performance et des implémentations de prototypes sont disponibles [26] [30]. L'expérience d'implémentation et les mesures des implémentations HTTP/1.1 (RFC 2068) réelles montrent de bons résultats [39]. Des alternatives telles que T/TCP [27] ont également été explorées.

Les connexions HTTP persistantes présentent de nombreux avantages :

  • En ouvrant et fermant moins de connexions TCP, le temps CPU est économisé dans les routeurs et les hôtes (clients, serveurs, proxies, passerelles, tunnels ou caches), et la mémoire utilisée pour les blocs de contrôle du protocole TCP est économisée dans les hôtes.

  • Les requêtes et réponses HTTP peuvent être mises en pipeline (pipelining) sur une connexion. Le pipelining permet à un client d'effectuer plusieurs requêtes sans attendre chaque réponse, permettant une utilisation plus efficace d'une seule connexion TCP et un temps écoulé considérablement réduit.

  • La congestion du réseau est réduite en diminuant le nombre de paquets causés par les ouvertures TCP et en permettant à TCP de disposer de suffisamment de temps pour déterminer l'état de congestion du réseau.

  • La latence des requêtes ultérieures est réduite car aucun temps n'est passé sur la poignée de main d'ouverture de connexion TCP.

  • HTTP peut évoluer plus gracieusement car les erreurs peuvent être signalées sans la pénalité de fermer la connexion TCP. Les clients utilisant des futures versions de HTTP pourraient tenter de manière optimiste de nouvelles fonctionnalités, mais s'ils communiquent avec un serveur plus ancien, réessayer avec l'ancienne sémantique après avoir signalé une erreur.

Les implémentations HTTP devraient (SHOULD) implémenter des connexions persistantes.

8.1.2 Overall Operation (Fonctionnement Global)​

Une différence significative entre HTTP/1.1 et les versions antérieures de HTTP est que les connexions persistantes sont le comportement par défaut de toute connexion HTTP. C'est-à-dire que, sauf indication contraire, le client devrait (SHOULD) supposer que le serveur maintiendra une connexion persistante, même après une réponse d'erreur du serveur.

Les connexions persistantes fournissent un mécanisme permettant aux applications HTTP/1.0 et HTTP/1.1 de signaler la fermeture de connexion. Ce signal est fourni via le champ d'en-tête Connection (section 14.10). Une fois qu'une option de connexion "close" a été envoyée ou reçue, cette connexion ne doit pas (MUST NOT) être considérée comme "persistante".

Les applications HTTP/1.1 ne doivent pas (MUST NOT) établir de connexions persistantes avec des clients HTTP/1.0.

8.1.3 Proxy Servers (Serveurs Proxy)​

Il est particulièrement important que les proxies implémentent correctement les propriétés du champ d'en-tête Connection, comme décrit dans la section 14.10.

Les serveurs proxy doivent (MUST) signaler séparément les connexions persistantes aux clients et aux serveurs en amont. Chaque connexion persistante ne s'applique qu'à un seul lien de transport.

8.1.4 Practical Considerations (Considérations Pratiques)​

Les serveurs ont généralement une valeur de délai d'expiration au-delà de laquelle ils ne maintiendront plus une connexion inactive. Les serveurs proxy peuvent rendre cette valeur de délai d'expiration plus élevée car les clients peuvent avoir déjà établi des connexions sur les connexions existantes. L'utilisation de connexions persistantes n'exige pas que les serveurs maintiennent les connexions indéfiniment. En fait, les serveurs peuvent (MAY) fermer une connexion à tout moment, mais devraient (SHOULD) le faire de manière gracieuse.

Les clients, serveurs et proxies doivent (MUST) être capables de récupérer des événements de fermeture asynchrones. Le logiciel client devrait (SHOULD) rouvrir la connexion de transport et retransmettre la séquence de requêtes abandonnée sans interaction de l'utilisateur, à condition que la séquence de requêtes soit idempotente (voir section 9.1.2). Les méthodes ou séquences non idempotentes ne doivent pas (MUST NOT) être automatiquement retentées, bien que l'agent utilisateur puisse (MAY) offrir à l'utilisateur un moyen de retenter manuellement les requêtes.

Les serveurs devraient (SHOULD) toujours répondre à au moins une requête avant de fermer une connexion. Les serveurs ne devraient pas (SHOULD NOT) fermer une connexion au milieu de la transmission d'une réponse, sauf si une défaillance du réseau ou du client est suspectée.

Les clients souhaitant envoyer une connexion persistante peuvent (MAY) "mettre en pipeline" leurs requêtes (c'est-à-dire envoyer plusieurs requêtes sans attendre l'arrivée de chaque réponse). Les serveurs doivent (MUST) envoyer leurs réponses dans l'ordre dans lequel les requêtes correspondantes ont été reçues.

8.2 Message Transmission Requirements (Exigences de Transmission de Messages)​

8.2.1 Persistent Connections and Flow Control (Connexions Persistantes et Contrôle de Flux)​

Les serveurs HTTP/1.1 devraient (SHOULD) maintenir des connexions persistantes pour eux-mêmes, lorsque c'est possible. Cependant, s'ils maintiennent des connexions persistantes, alors pour une connexion TCP donnée, ils devraient (SHOULD) utiliser cette connexion pour au moins une séquence requête-réponse.

8.2.2 Monitoring Connections for Error Status Messages (Surveillance des Connexions pour les Messages d'État d'Erreur)​

Un client HTTP/1.1 (ou supérieur) envoyant une requête (en particulier une requête cruciale pour l'authentification ou ayant une méthode non sûre) doit (MUST) renvoyer la requête si la connexion de transport est fermée ou réinitialisée avant que le client n'ait terminé d'envoyer le message de requête.

8.2.3 Use of the 100 (Continue) Status (Utilisation du Statut 100 (Continue))​

Le but du statut 100 (Continue) (voir section 10.1.1) est de permettre à un client envoyant un corps de message de requête de déterminer si le serveur d'origine est prêt à accepter la requête (basé sur les en-têtes de requête) avant que le client n'envoie le corps de la requête. Dans certains cas, il peut être inapproprié ou inefficace pour un client d'envoyer un corps si le serveur rejettera le message sans lire le corps.

Exigences pour un client HTTP/1.1 (ou supérieur) contenant un corps de message de requête :

  • Si le client attendra une réponse 100 (Continue) pendant une durée raisonnable, le client doit (MUST) envoyer un champ d'en-tête Expect (section 14.20) contenant la valeur d'attente "100-continue".

  • Le client ne doit pas (MUST NOT) envoyer un champ d'en-tête Expect avec la valeur d'attente "100-continue" à un serveur HTTP/1.0 (ou antérieur).

  • Un client qui envoie une attente 100 (Continue) mais ne reçoit pas de statut 100 (Continue) devrait (SHOULD) attendre pendant une période indéterminée ; le client peut (MAY) ensuite expirer et envoyer la requête (avec son corps de message) ou fermer la connexion.

Exigences pour un serveur d'origine HTTP/1.1 (ou supérieur) recevant une requête d'un client HTTP/1.1 (ou supérieur) :

  • Après avoir reçu une requête contenant un champ d'en-tête Expect avec la valeur d'attente "100-continue", le serveur d'origine doit (MUST) répondre avec un statut 100 (Continue) s'il a l'intention de lire et traiter le corps du message de requête, ou répondre avec un code d'état final. Le serveur d'origine ne doit pas (MUST NOT) attendre le corps de la requête avant d'envoyer la réponse 100 (Continue). S'il répond avec un code d'état final, il peut (MAY) fermer la connexion de transport ou il peut (MAY) continuer à lire et ignorer le reste de la requête. Il ne doit pas (MUST NOT) exécuter la méthode de la requête (s'il a l'intention de rejeter la requête).

  • Le serveur d'origine devrait (SHOULD) répondre avec 100 (Continue) immédiatement après avoir reçu les en-têtes de requête d'un client HTTP/1.1 (ou supérieur), sauf si la requête contient un champ d'en-tête Expect avec une valeur d'attente ne comprenant pas "100-continue".

8.2.4 Client Behavior if Server Prematurely Closes Connection (Comportement du Client si le Serveur Ferme Prématurément la Connexion)​

Si un client HTTP/1.1 envoie une requête HTTP avant de recevoir une réponse et reçoit une réponse indiquant que le serveur ne souhaite pas recevoir d'autres requêtes sur cette connexion, le client devrait (SHOULD) renvoyer la requête, à condition qu'il puisse déterminer que toutes les requêtes de la séquence sont idempotentes (voir section 9.1.2).

Les méthodes ou séquences non idempotentes ne doivent pas (MUST NOT) être automatiquement retransmises, mais l'agent utilisateur peut (MAY) offrir un moyen à l'utilisateur de retenter manuellement cette séquence. Avant de retransmettre automatiquement les requêtes, si la séquence de requêtes précédente ne pouvait pas être entièrement complétée, le client devrait (SHOULD) confirmer toute différence entre son état actuel et l'état attendu.

Dernière mise à jour le