Chaque adresse Internet commence par « http:// » (ou « https:// »). Ceci renvoie au protocole HTTP utilisé par votre na­vi­ga­teur Web pour consulter un site Internet. Nous vous pré­sen­tons le concept de HTTP, vous ex­pli­quons les dif­fé­rences entre les versions et vous montrons à quels autres concepts le HTTP est associé.

Que signifie HTTP ?

HTTP signifie « Hypertext Transfer Protocol ». Ce protocole a été développé par Tim Berners-Lee au CERN (Suisse) avec d’autres concepts qui ont servi de base à la création du World Wide Web : le HTML et l’URI. Alors que le HTML (Hypertext Markup Language) définit comment un site Internet est construit, le HTTP détermine comment la page est transmise du serveur au client. Le troisième concept, l’URL (Uniform Resource Locator), fixe la façon dont une ressource (par exemple un site Internet) doit être adressée sur le Web.

Mais que signifie exac­te­ment « hy­per­texte », ce terme qui revient dans les abré­via­tions HTTP et HTML ? Il s’agit d’un concept que nous con­nais­sons tous et qui désigne le fait de mettre en lien des fichiers. Les sites Internet con­tien­nent en effet des hy­per­liens renvoyant à d’autres pages Web.

À quoi sert le protocole HTTP ?

Lorsque vous saisissez une adresse Internet dans votre na­vi­ga­teur Web et qu’un site vous est affiché quelques secondes plus tard, cela signifie qu’une com­mu­ni­ca­tion a été établie entre votre na­vi­ga­teur et le serveur Web via HTTP. On peut donc dire que le HTTP est la langue dans laquelle votre na­vi­ga­teur Web parle au serveur Web afin de lui com­mu­ni­quer ce qui est demandé.

Comment fonc­tionne le HTTP ?

Le fonc­tion­ne­ment du HTTP peut être expliqué très sim­ple­ment à travers la con­sul­ta­tion d’un site Internet :

  1. L’uti­li­sa­teur saisit dans la barre d’adresse de son na­vi­ga­teur Internet http://example.com/.
  2. Le na­vi­ga­teur envoie une requête cor­res­pon­dante, appelée requête HTTP, au serveur Web qui ad­mi­nistre le domaine example.com. Nor­ma­le­ment, cette requête est de type : « Merci de m’envoyer le fichier ». Mais le client peut également se contenter de demander : « As-tu ce fichier ? ».
  3. Le serveur Web reçoit la requête HTTP, cherche le fichier désiré (dans l’exemple : la page d’accueil de example.com, c’est-à-dire le fichier index.html) et envoie dans un premier temps l’en-tête qui informe le client à l’origine de la requête du résultat de sa recherche à l’aide d’un code de statut. Vous trouverez des détails con­cer­nant les codes de statut dans notre article détaillé.
  4. Si le fichier a été trouvé et si le client demande à l’obtenir (c’est-à-dire si le client ne souhaite pas uni­que­ment savoir s’il existe), après l’en-tête, le serveur envoie le corps du message, à savoir le contenu à pro­pre­ment parler. Dans notre exemple, il s’agit du fichier index.html.
  5. Le na­vi­ga­teur reçoit le fichier et l’affiche sous forme de site Internet.

Dans quel contexte le HTTP est-il utilisé ?

À l’origine, le HTTP servait uni­que­ment à demander un document HTML à un serveur Web. Aujourd’hui, ce protocole est utilisé de façons très diverses :

  • Le HTTP permet au na­vi­ga­teur de demander tous les types de médias utilisés sur les sites Internet modernes : texte, images, vidéos, code source, etc.
  • Les ap­pli­ca­tions utilisent par ailleurs le HTTP pour charger des fichiers et des mises à jour de serveurs distants.
  • Le HTTP in­ter­vient également dans les API REST, une solution per­met­tant de contrôler les services Web.
  • WebDAV est une autre tech­no­lo­gie basée sur le HTTP.
  • Dans la com­mu­ni­ca­tion de machine à machine, le HTTP est utilisé comme protocole pour la com­mu­ni­ca­tion entre les services Web.
  • Le HTTP est également utilisé par les lecteurs de médias.
  • Les accès à une base de données en ligne, c’est-à-dire les opé­ra­tions CRUD, peuvent également avoir lieu grâce au HTTP.

Quelles versions de HTTP existe-t-il ?

La version initiale : HTTP/1

L’histoire du HTTP commence en 1989 lorsque Tim Berners-Lee et son équipe du CERN (Suisse) se lancent dans le dé­ve­lop­pe­ment du World Wide Web. La version initiale du HTTP portait le numéro de version 0.9 et s’in­ti­tu­lait « protocole une ligne ». Elle per­met­tait uni­que­ment de consulter un fichier HTML depuis un serveur.

GET /dummy.html

Le serveur se con­ten­tait de trans­mettre le fichier cor­res­pon­dant. C’est la raison pour laquelle cette version du protocole ne pouvait gérer que des fichiers HTML.

En 1996, la version HTTP/1 fut décrite par l’Internet En­gi­nee­ring Task Force (IETF) dans le mémo RFC1945, mais elle n’était alors qu’une pro­po­si­tion non con­traig­nante. Un en-tête fut ajouté afin de pouvoir spécifier aussi bien la requête du client que la réponse du serveur. Le champ d’en-tête « Content-Type », qui permet de trans­mettre d’autres fichiers que des documents HTML, a notamment été introduit. Pour résumer, cette version du HTTP pré­sen­tait les pro­prié­tés suivantes :

  • Sans connexion : le client établit la connexion avec le serveur, il présente sa requête à laquelle le serveur répond, puis la connexion est coupée. Pour la requête suivante, le client doit à nouveau établir la connexion. Ce processus est lourd car une page Web se compose gé­né­ra­le­ment de plusieurs fichiers, et chacun d’entre eux doit être « récupéré » à l’aide d’une requête in­dé­pen­dante.
  • Sans statut : les deux côtés, client et serveur, s’« oublient » mu­tuel­le­ment, im­mé­dia­te­ment. Lorsque le client se re­con­necte au serveur, ce dernier ne sait pas que le client lui a déjà envoyé une requête.
  • In­dé­pen­dant du média : le HTTP permet de trans­mettre n’importe quel type de fichier dans la mesure où les deux côtés savent comment ils doivent traiter le type de fichier en question.

Le premier standard officiel : HTTP/1.1

En 1997, la version HTTP/1.1, décrite dans le mémo RFC2068, a fait son ap­pa­ri­tion. Elle fut con­si­dé­rée comme le premier standard « officiel » et est encore utilisée aujourd’hui. Elle a apporté d’im­por­tantes nou­veau­tés par rapport au HTTP/1 :

  • Keepalive : le client a la pos­si­bi­lité de maintenir la connexion au-delà d’une requête (per­sis­tent con­nec­tion) en envoyant un keepalive (lit­té­ra­le­ment « maintenir en vie ») dans l’en-tête de sa requête.
  • Le HTTP-Pi­pe­li­ning per­met­tant au client d’envoyer la requête suivante avant d’avoir reçu la réponse à la première requête.
  • Dans les chats, le na­vi­ga­teur peut ac­tua­li­ser la fenêtre en utilisant le type MIME multipart/replace.
  • Il est également possible de trans­mettre des données du client au serveur.
  • La nouvelle méthode TRACE in­tro­duite permet de suivre le chemin du client au serveur Web.
  • Cache : de nouveaux mé­ca­nismes pour mettre des contenus en mémoire tampon sont dis­po­nibles.
  • Host : grâce à une spé­ci­fi­ca­tion cor­res­pon­dante dans l’en-tête (host), les requêtes HTTP fonc­tion­nent également lorsque plusieurs domaines dif­fé­rents sont hébergés sous une même adresse IP, comme c’est le cas aujourd’hui pour la majorité des sites Internet (Shared Web­hos­ting).

HTTP/2 : une refonte bien né­ces­saire

Au fil des ans, les sites Internet n’ont cessé de gagner en taille et en com­plexité. Pour être en mesure de charger un site Internet moderne dans un na­vi­ga­teur, celui-ci doit demander plusieurs mé­gaoc­tets de données et envoyer jusqu’à cent requêtes HTTP dif­fé­rentes. Comme le HTTP/1.1 prévoit que les requêtes soient traitées les unes après les autres dans une même connexion, plus un site Internet est complexe, plus l’éta­blis­se­ment de la page demande du temps.

C’est pourquoi Google a développé un nouveau protocole ex­pé­ri­men­tal intitulé SPDY (prononcé « Speedy »). Ce dernier a suscité un vif intérêt dans la com­mu­nauté des dé­ve­lop­peurs et a abouti en 2015 à la pu­bli­ca­tion de la version HTTP/2 du protocole. Ce nouveau standard apporte notamment des nou­veau­tés ayant toutes pour objectif d’accélérer le char­ge­ment des sites Internet :

  • Binaire : le protocole est basé sur des données binaires plutôt que sur des fichiers texte.
  • Mul­ti­plexe : le client et le serveur peuvent envoyer et/ou traiter plusieurs requêtes HTTP en parallèle.
  • Com­pres­sion : les en-têtes sont com­pres­sés ; comme ils sont souvent quasiment iden­tiques dans de nom­breuses requêtes HTTP, la com­pres­sion évite les re­don­dances inutiles.
  • Serveur Push : lorsque le serveur est en mesure de prévoir les données dont le client aura encore besoin, il peut les lui envoyer d’emblée dans une mémoire cache client – sans nécessité de requête HTTP préalable.

Le HTTP/2 pourrait ra­pi­de­ment devenir la norme ; les sites Internet pré­sen­tant un trafic important n’ont en par­ti­cu­lier pas attendu pour passer à cette nouvelle version. En janvier 2020, on notait près de 42 pour cent des sites Internet utilisant la version HTTP/2 selon les données de W3Techs.

Conseil

Des in­for­ma­tions com­plé­men­taires con­cer­nant le HTTP/2 sont dis­po­nibles dans l’article "Voici comment le HTTP/2 optimise le World Wide Web".

L’avenir : le HTTP/3

Dans toutes les anciennes versions du protocole HTTP, le protocole de transport TCP sous-jacent cons­ti­tuait l’un des points faibles. Ce dernier exige que le des­ti­na­taire de chaque paquet de données donne con­fir­ma­tion avant de pouvoir envoyer le paquet suivant. Mais si un paquet est perdu, tous les autres paquets doivent attendre que le paquet perdu soit à nouveau transféré. Dans ce cas, les experts parlent de « head-of-line blocking ».

Par con­sé­quent, le nouveau HTTP/3 ne doit plus reposer sur TCP mais sur UDP, qui ne nécessite aucune mesure cor­rec­tive de ce type. Le protocole QUIC (Quick UDP Internet Con­nec­tions) a été développé à partir du protocole UDP et doit servir de base au HTTP/3.

Pour le moment, le HTTP/3 n’a pas encore été dé­fi­ni­ti­ve­ment adopté par l’IETF. Mais d’après W3Techs, près de 3 pour cent des sites Internet utilisent QUIC ou le HTTP/3.

Aller au menu principal