Accéder au contenu principal

Histoire d'Internet

Chronologie globale   Documents historiques  A venir: les newsgroups, le protocole UUCP, Craig's List, Amazon, eBay, Facebook, Youtube, ...  A venir: RSS, Javascript, Google, Wikipedia, AOL, UUNet, le spam, ... et bien d'autres secrets ...

1991 - HTTP (Hypertext Transfer Protocol)

La date du 6 août 1991 est considérée par beaucoup comme l'annonce officielle et publique du World Wide Web sur le réseau Internet suite à l'annonce par Tim Berners Lee des concepts fondamentaux du web dans un article intitulé "Qualifiers on Hypertext links" posté dans le groupe de news "alt.hypertext". Cet article fait suite aux développements faits conjointement avec Robert Cailliau fin décembre 1990.

Durant cette période, les deux chercheurs ont en effet développer un ensemble de prototypes logiciels incluant le protocole HTTP, le langage HTML, le navigateur et éditeur de pages Web "WorldWideWeb", le logiciel serveur HTTPD et enfin le site web "http://info.cern.ch/". Le protocole HTTP (Hypertext Transfer Protocol) se situe au niveau de la couche applicative du modèle OSI en s'appuyant sur le protocole TCP, et s'articule autour d'un mode Client-Serveur.


La première version "stable" se révèle extrêmement simple en terme d'implémentation :

  • le serveur HTTP ouvre un port en écoute (usuellement le port 80) 
  • le client HTTP se connecte au port en écoute du serveur 
  • le client transmet une requête à l'aide de la commande GET 
  • le serveur transmet au client la réponse à sa requête
  • le serveur ferme la connexion en guise de fin de réponse 

Les échanges HTTP au travers de cette version sont reconnaissables au fait que les requêtes ne sont faites qu'au travers de la commande "GET" suivie d'un seul argument qui est l'objet requis. Aucun numéro n'étant initialement attribué à cette version, il lui sera attribué le numéro "0.9" par la suite lorsque sortira plus tard la version "1.0".

Le développement du protocole sera par la suite porté par le World Wide Web Consortium. En mai 1996, l'IETF publie la RFC1945 qui posera les bases du protocole HTTP/1.0. Suivra en juin 1999, la RFC2616 relative à la version "HTTP/1.1". Les principaux contributeurs à ces deux spécifications seront Tim Berners Lee (membre du W3 Consortium et chercheur au MIT), Roy Fielding (chercheur à Université de Californie, Irvine) et Henrik Frystyk (membre du W3 Consortium et chercheur au MIT).

Dans la littérature relative aux échanges entre un client et un serveur HTTP, il est habituellement cité :

  • l'agent utilisateur (ou User-Agent): il s'agit du client HTTP 
  • le navigateur (ou Browser, ou Butineur: il s'agit du client HTTP 
  • le site web: il s'agit du serveur HTTP 
  • le serveur d'origine: il s'agit du serveur HTTP hébergeant les ressources 
  • le proxy: il s'agit d'un serveur HTTP servant de relai vers le serveur d'origine 

Les versions "HTTP/1.0" et "HTTP/1.1" ont permis l'enrichissement du dialogue entre le client et le serveur en intégrant notamment la transmission de la version utilisée par les deux parties, l'ajout de méthodes en supplément de "GET", mais aussi l'échange d'entêtes de données. Celles-ci permettent au client de spécifier par exemple le language dans lequel il souhaite que le serveur lui réponde. Elles permettent également au serveur de spécifier par exemple la durée de vie d'un contenu.

La requête d'un client HTTP se décompose ainsi :

  • Ligne 1 : "methode" "argument" "version" 
    • "methode' : HEAD, GET, POST, PUT, ELETE, TRACE, OPTIONS, CONNECT 
    • "argument" : chemin complet jusqu'à la ressource demandée 
    • "version" : HTTP/1.0, HTTP/1.1 
  • Lignes suivantes : les entêtes HTTP 
  • Une ligne vide 
  • Lignes suivantes : un message optionnel 
  • Chaque ligne se terminant par les caractères CR (Carriage Return et LF Line Feed 

Exemple de requête afin d'obtenir le fichier exemple.txt du répertoire archives sur le serveur "www.monsite.fr" :

GET /archives/exemple.txt HTTP/1.1
Host: www.monsite.fr
Accept-Language: fr

Requete test 

La réponse d'un serveur HTTP se décompose ainsi :

  • Ligne 1 : code message 
  • Lignes suivantes : le contenu de la réponse 

Exemple de réponse suite à la demande du fichier "http://www.monsite.fr/archives/exemple.txt" : 

HTTP/1.1 200 OK
Date: Mon, 30 Mar 2009 00:01:23 GMT
Content-Type: text/html; charset=utf-8

Ceci est un document texte.
This is a text document.


Les différentes méthodes de requêtes supportées par les versions actuelles du protocole HTTP sont au nombre de 8 :

  • HEAD : requête identique à la méthode GET mais le serveur ne doit pas renvoyer le contenu de la réponse, seulement les entêtes 
  • GET : requête basique d'une ressources 
  • POST : requête avec soumission de données dans le corps de la requête 
  • PUT : requête en téléchargement pour une ressource 
  • DELETE : requête en suppression d'une ressource 
  • TRACE: requête avec demande de renvoi de la demande par le serveur, permet de voir les échanges faits via des intermédiaires comme les proxys 
  • OPTIONS : requête permettant de connaitre les méthodes supportées par le serveurs pour une URL précise 
  • CONNECT : requête permettant d'établir une connexion au travers d'un tunnel TCP/IP 

Les méthodes HEAD, GET, OPTIONS et TRACE sont définies comme étant des méthodes "sûres" puisqu'elle ne sollicitent le serveur que pour une interrogation et non une modification des données qu'il héberge. Par opposition, les méthodes POST, PUT et DELETE sont définies comme étant des méthodes "non-sûres" puisqu'elle s'inscrivent dans une démarche de modification de contenu sur le serveur.

L'un des principaux apports de la version 1.1 est sans aucun doute le mécanisme de connexions persistantes (appelé aussi mécanisme "Keep-Alive"). Il permet à un serveur, si le client le stipule, de conserver ouverte la connexion entre les deux. Ceci a l'avantage de réduire le temps de communication dans la mesure où les deux parties ne renégocient pas de nouvelles connexions après la première requête, et de permettre l'envoi de plusieurs requêtes simultanées par le client (exemple: le contenu d'une page HTML et les images qui lui sont associées).

Le protocole HTTP peut également être sécurisé, il est alors appelé HTTPS (ou Secure HTTP). Les spécifications des échanges sécurisées sont décrites dans le document RFC2817.

Posts les plus consultés de ce blog

2009 - Rétrospective Arpanet

Le professeur Leonard Kleinrock, pionnier de l'Internet à l'UCLA ( University of California, Los Angeles ), présente l'architecture de connexion des premières machines au sein du réseau ARPANET en septembre 1969 et le premier envoi de données en octobre 1969. The first Internet connection

1969 - Arpanet (ARPA Network)

A partir de 1940, le département de la Défense américain crée une agence chargée des projets de recherche en matière de défense militaire. Cette agence nommée DARPA ("Defense Advanced Research Projects Agency") va être à l'origine de la naissance du réseau prédécesseur d'Internet, mais aussi du programme Transit ancêtre du GPS, ainsi que des programmes d'avions furtifs Jusqu'alors, les communications informatiques reposaient sur l'utilisation de circuits dédiés, tout comme les communications téléphoniques. L'agence DARPA lance donc en 1966 un projet de réseau informatique reliant certaines universités américaines. Sans objectif particulier d'un point de vue militaire, ce projet devient le réseau ARPA et en 1969 il relie quatre centres :

1997 - Peer-to-peer (P2P)

Dès sa conception à la fin des années 1960, le réseau ARPANET pose les bases d'un réseau d'interconnexion non hiérarchique et non centralisé. En théorie, la communication entre utilisateurs finaux ne dépend d'aucun élément central et d'aucune liaison point-à-point . Il est donc pas définition possible d'échanger des informations avec n'importe quel ordinateur relié au réseau. Les premiers échanges de données, via les protocoles telnet ou ftp notamment illustrent bien cette idée de connexions non centralisées, inutile de se référencer auprès d'un serveur central pour communiquer entre utilisateurs. La réalité est un peu plus contrastée puisque pour beaucoup de protocoles IP, un modèle client-serveur est nécessaire : un serveur héberge les données et des clients s'y connecte pour les lire ou les modifier.