Loading AI tools
protocole de transfert de données dans un réseau informatique De Wikipédia, l'encyclopédie libre
L’Hypertext Transfer Protocol, généralement abrégé HTTP, littéralement « protocole de transfert hypertexte », est un protocole de communication client-serveur développé pour le World Wide Web. HTTPS (avec S pour secure, soit « sécurisé ») est la variante sécurisée par le chiffrement et l'authentification.
HTTP
Ne doit pas être confondu avec Hypertext Transfer Protocol Secure.
HTTP est avec HTML et les URL une des trois inventions fondamentales de Tim Berners-Lee pour créer le World Wide Web.
Les clients HTTP les plus connus sont les navigateurs Web. HTTP est aussi utilisé hors du Web pour mettre en œuvre les interfaces de programmation distribuée fondées sur SOAP et REST.
HTTP a été inventé par Tim Berners-Lee avec les adresses Web et le langage HTML pour créer le World Wide Web. À cette époque, le File Transfer Protocol (FTP) était déjà disponible pour transférer des fichiers, mais il ne supportait pas la notion de format de données telle qu'introduite par Multipurpose Internet Mail Extensions (MIME). La première version de HTTP était très élémentaire, mais prévoyait déjà le support d'en-têtes MIME pour décrire les données transmises. Cette première version reste encore partiellement utilisable de nos jours, connue sous le nom de HTTP/0.9.
En , la RFC 1945[1] décrit HTTP tel que communément implémenté à l'époque et connu sous le nom de HTTP/1.0. Cette version supporte la gestion de cache et l'identification.
En , HTTP/1.1 devient finalement standard de l'IETF. Il est décrit dans la RFC 2068[2] de l'IETF, puis dans la RFC 2616[3] en . Cette version ajoute le support du transfert en pipeline (ou pipelinage) et la négociation de type de contenu (format de données, langue). HTTP/1.1 rend la présence de l'entête Host obligatoire dans les requêtes afin de supporter l'hébergement mutualisé.
En , les travaux à propos de HTTP/2.0 démarrent à l'IETF adoptant SPDY comme matériel de départ.
En , la spécification de HTTP 1.1 a été republiée. Elle a été éclatée en plusieurs RFC et corrigée pour toutes ses imprécisions, RFC 7230[4] à RFC 7237[5].
Dans le protocole HTTP, une méthode est une commande spécifiant un type de requête, c'est-à-dire qu'elle demande au serveur d'effectuer une action. En général l'action concerne une ressource identifiée par l'URL qui suit le nom de la méthode.
Dans l'illustration ci-contre, une requête GET est envoyée pour récupérer la page d'accueil du site web www.perdu.com :
GET / HTTP/1.1 Host: www.perdu.com
Il existe de nombreuses méthodes, les plus courantes étant GET, HEAD et POST :
GETHEADPOSTOPTIONSCONNECTTRACEPUTPATCHDELETECes 3 dernières méthodes nécessitent généralement un accès privilégié.
Certains serveurs autorisent d'autres méthodes de gestion de leurs ressources (par exemple WebDAV).
La liaison entre le client et le serveur n'est pas toujours directe, il peut exister des machines intermédiaires servant de relais :
HTTP permet l'identification du visiteur par transmission d'un nom et d'un mot de passe. Il existe deux modes d'identification : Basic et Digest (RFC 2617[6]). Le premier mode transmet le mot de passe en clair, et ne doit donc être utilisé qu'avec le protocole HTTPS. Le deuxième mode permet une identification sans transmettre le mot de passe en clair. L'identification est cependant souvent effectuée par une couche applicative supérieure à HTTP.
Au début du World Wide Web, il était prévu d'ajouter au protocole HTTP des capacités de négociation de contenu, en s'inspirant notamment de MIME. En attendant, le protocole HTTP 0.9 était extrêmement simple.
GETRequête :
GET /page.html
La méthode GET est la seule possible. Le serveur reconnaît qu'il a affaire à une requête HTTP 0.9 au fait que la version n'est pas précisée à la suite de l'URI.
Réponse :
<TITLE>Exemple</TITLE> <H1>Exemple</H1>Ceci est une page d'exemple.
Pour répondre à une requête HTTP 0.9, le serveur envoie directement le contenu de la réponse, sans métadonnées. Il ne doit jamais se comporter ainsi pour les requêtes HTTP de version supérieure.
Inutile de chercher les versions inférieures à 0.9 du protocole HTTP : elles n'existent pas, car HTTP 0.9 n'avait initialement pas de numéro de version. Il a fallu lui en attribuer un quand HTTP 1.0 est arrivé.
Le protocole HTTP 1.0, décrit dans la RFC 1945[1], prévoit l'utilisation d'en-têtes spécifiés dans la RFC 822[8]. La gestion de la connexion reste identique à HTTP 0.9 : le client établit la connexion, envoie une requête, le serveur répond et ferme immédiatement la connexion.
Une requête HTTP présente le format suivant :
Ligne de commande (Commande, URL, Version de protocole)
En-tête de requête
[Ligne vide]
Corps de requête
Les réponses HTTP présentent le format suivant :
Ligne de statut (Version, Code-réponse, Texte-réponse)
En-tête de réponse
[Ligne vide]
Corps de réponse
Requête :
GET /page.html HTTP/1.0
Host: example.com
Referer: http://example.com/
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
La version du protocole HTTP est précisée à la suite de l'URI. La requête doit être terminée par un double retour à la ligne (CRLFCRLF). HTTP 1.0 supporte aussi les méthodes HEAD et POST. On constate l'usage d'en-têtes inspirés de MIME pour transférer les métadonnées :
HostRefererUser-AgentRéponse :
HTTP/1.0 200 OK Date: Fri, 31 Dec 1999 23:59:59 GMT Server: Apache/0.8.4 Content-Type: text/html Content-Length: 59 Expires: Sat, 01 Jan 2000 00:59:59 GMT Last-modified: Fri, 09 Aug 1996 14:21:40 GMT <TITLE>Exemple</TITLE> <P>Ceci est une page d'exemple.</P>
La première ligne donne le code de statut HTTP (200 dans ce cas).
DateServerContent-TypeContent-LengthExpiresLast-ModifiedLe protocole HTTP 1.1 est décrit par le RFC 2616[3] qui rend le RFC 2068[2] obsolète. La différence avec HTTP 1.0 est une meilleure gestion du cache. L'en-tête Host devient obligatoire dans les requêtes.
Les soucis majeurs des deux premières versions du protocole HTTP sont d'une part le nombre important de connexions lors du chargement d'une page complexe (contenant beaucoup d'images ou d'animations) et d'autre part le temps d'ouverture d'une connexion entre client et serveur (l'établissement d'une connexion TCP prend un temps triple de la latence entre client et serveur). Des expérimentations de connexions persistantes ont cependant été effectuées avec HTTP 1.0 (notamment par l'emploi de l'en-tête Connection: Keep-Alive), mais cela n'a été définitivement mis au point qu'avec HTTP 1.1.
Par défaut, HTTP 1.1 utilise des connexions persistantes, autrement dit la connexion n'est pas immédiatement fermée après une requête, mais reste disponible pour une nouvelle requête. On appelle souvent cette fonctionnalité keep-alive. Il est aussi permis à un client HTTP d'envoyer plusieurs requêtes sur la même connexion sans attendre les réponses. On appelle cette fonctionnalité pipelining. La persistance des connexions permet d'accélérer le chargement de pages contenant plusieurs ressources, tout en diminuant la charge du réseau.
La gestion de la persistance d'une connexion est gérée par l'en-tête Connection.
HTTP 1.1 supporte la négociation de contenu. Un client HTTP 1.1 peut accompagner la requête pour une ressource d'en-têtes indiquant quels sont les langues et formats de données préférés. Il s'agit des en-têtes dont le nom commence par Accept-.
Les en-têtes supplémentaires supportés par HTTP 1.1 sont :
ConnectionAcceptAccept-CharsetAccept-LanguageL'ordre de préférence de chaque option (type, encodage ou langue) est spécifié par le paramètre optionnel q contenant une valeur décimale entre 0 (inacceptable) et 1 (acceptable) inclus (3 décimales maximum après la virgule), valant 1 par défaut.
Le support des connexions persistantes doit également fonctionner dans les cas où la taille de la ressource n'est pas connue d'avance (ressource générée dynamiquement par le serveur, flux externe au serveur…).
Pour cela, l'encodage de transfert nommé chunked permet de transmettre la ressource par morceaux consécutifs en précédant chacun par une ligne de texte donnant la taille de celui-ci en hexadécimal. Le transfert se termine alors par un morceau de taille nulle, où des en-têtes finaux peuvent être envoyés.
Les en-têtes supplémentaires liés à cet encodage de transfert sont :
Transfer-EncodingTrailerTERFC 2616[3] comprenait de nombreuses imprécisions. Le groupe de travail HTTP a pris quelques années afin de clarifier la spécification sans en modifier la sémantique tel que préconisé dans la charte de fonctionnement du groupe pour ce travail. En , huit nouveaux documents ont été publiés qui rendent obsolète la RFC 2616[3] :
Une nouvelle version d'HTTP, HTTP/2, a été développée au sein du groupe de travail « Hypertext Transfer Protocol Bis » (httpbis) de l'Internet Engineering Task Force[15] et approuvée comme RFC standard le [16]. Le développement d'HTTP/2 a débuté à la suite de la création du protocole SPDY proposé par Google afin de réduire le temps de chargement des pages Web[17],[18]. Le groupe de travail httpbis s'était initialement interdit de proposer une nouvelle version d'HTTP, concentrant son activité sur la clarification des spécifications d'HTTP 1.1. Considérant l'arrivée de SPDY et son adoption rapide sur le Web, avec notamment des implémentations dans deux des principaux navigateurs Web, Google Chrome et Mozilla Firefox, Mark Nottingham, « chair » d'httpbis, a émis l'opinion qu'il était temps d'envisager HTTP/2 et proposé d'amender la charte d'httpbis en ce sens, initiant de fait le développement du nouveau protocole[19].
SPDY constituait une option naturelle pour servir de base à HTTP/2. Deux autres propositions concurrentes ont été ensuite transmises à l'IETF : le protocole « HTTP Speed+Mobility » par Microsoft[20] et une proposition de mise à jour d'HTTP (« Network-Friendly HTTP Upgrade »)[21]. En , httpbis a publié un appel à expression d'intérêt (« Call for Expression of Interest ») afin de recueillir l'avis d'acteurs du Web sur les propositions[22]. Parmi les réponses obtenues figure celle de Facebook qui a signifié sa préférence pour SPDY[23]. En , l'IETF a publié le premier draft d'HTTP/2, qui est une copie directe de SPDY[24].
Après plus de deux ans de discussions, la RFC est approuvée en par le groupe de pilotage de l'IETF, et est publiée en .
Le module permettant la prise en charge du protocole HTTP/2 est disponible depuis la version 2.4.17[25] du serveur Web Apache, et depuis la version 1.9.5[26] de Nginx.
Une nouvelle version d’HTTP, HTTP/3, est la troisième et prochaine version majeure du protocole de transfert hypertexte utilisé pour échanger des informations sur le World Wide Web. Celle-ci repose sur le protocole QUIC, développé par Google en 2012.
La sémantique HTTP est cohérente d'une version à l'autre. En effet, les mêmes méthodes de requête, codes de statut et champs de message sont généralement applicables à toutes les versions.
Si HTTP/1 et HTTP/2 utilisent tous deux TCP comme protocole de transport, HTTP/3 quant à lui utilise le protocole QUIC, un protocole de la couche transport qui est plus adapté au Web. Le passage à QUIC vise à résoudre un problème majeur de HTTP/2 appelé « Head-of-line Blocking » grâce à une encapsulation des paquets dans UDP. En effet, avec HTTP/2 reposant sur TCP, une connexion permet d'accéder aux ressources demandées une à une (une seule à la fois). Lorsque l'envoi d’une ressource est perturbé (par exemple par une perte de paquets), la livraison globale des ressources est ralentie. Avec HTTP/3 reposant sur le protocole QUIC, ce problème n'est plus, puisque tous les flux sont indépendants étant encapsulés dans UDP, protocole de transport ne nécessitant pas de connexion.
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
