Des conventions aux protocoles

Envoyer une lettre à un ami est une action relativement banale. Il convient tout d’abord d’écrire la lettre, de l’insérer dans une enveloppe, de noter l’adresse de l’ami en question sur l’enveloppe, d’y coller un timbre et de la glisser dans une boîte aux lettres. L’enveloppe sera alors récupérée par la poste, qui l’acheminera à l’adresse qui y est indiquée, celle de l’ami destinataire.

À bien y regarder, aussi banale que soit cette action, elle repose sur la mobilisation d’un nombre non négligeable de «conventions» que chacun des acteurs impliqués doit respecter. L’expéditeur indique l’adresse sur l’enveloppe d’une manière très codifiée (que l’on inscrive « la troisième maison à gauche après l’école » et l’on est certain que la lettre se perdra), et colle le timbre en haut à droite de l’enveloppe et pas ailleurs. Les divers employés du service postal qui manipuleront la lettre doivent respecter l’ensemble des processus liés à leur fonction qui feront que la lettre passera correctement de centre de tri en centre de tri jusqu’à la boîte aux lettres du destinataire. Quant à ce dernier, il faudra qu’il sache interpréter tout un ensemble d’autres conventions utilisées par l’expéditeur pour écrire sa lettre : la date qui figure certainement en haut à droite est la date de rédaction (éventuellement accompagnée d’un lieu) et le nom indiqué tout en bas de la lettre est la signature, le nom de l’expéditeur. La langue même dans laquelle est rédigée la lettre est une convention entre l’expéditeur et le destinataire.

C’est parce que cet entremêlement de conventions est respecté par l’ensemble des acteurs qui constituent la chaîne allant de l’expéditeur au destinataire que la communication entre ces derniers est possible. Il en va de même sur Internet lorsque, par exemple, on envoie un courrier électronique ou qu’un navigateur affiche une page d’un site web : la communication a alors lieu entre deux ordinateurs (celui de l’expéditeur et celui du destinataire dans le cas d’un courrier électronique, le serveur du site web et le poste de l’utilisateur dans le cas d’une page web), et cette communication est possible parce qu’un ensemble de conventions sont respectées. Pour des communications entre machines, on n’utilise pas le terme de convention mais celui de «protocole», et ce sont ces protocoles (ou du moins une partie d’entre eux) qui seront détaillés dans ce chapitre.

Les protocoles d’Internet

Pour permettre à deux ordinateurs d’échanger des informations entre eux, il faut un lien physique entre ces deux ordinateurs (éventuellement sans fil). Si on relie non pas deux, mais plusieurs ordinateurs qui vont pouvoir s’échanger des informations, on construit un réseau informatique.

Internet est un réseau de réseaux, c’est-à-dire un ensemble de technologies qui permettent à plusieurs réseaux de s’interconnecter de manière à permettre l’échange d’informations entre ordinateurs connectés non seulement au même réseau, mais aussi sur des réseaux différents. Par exemple, les ordinateurs dans une bibliothèque universitaire sont connectés, certainement par un câble EthernetÉthernet est la technologie standard pour connecter un ordinateur à un réseau avec un câble. Mais nous n’entrerons pas ici dans le détail des normes et protocoles des matériels physiques qui constituent Internet.↩︎, au réseau interne de l’université. Chez un particulier, l’ordinateur familial sera plutôt connecté au réseau de son fournisseur d’accès à Internet, notamment par ADSLAsymmetric Digital Subscriber Line, une technologie permettant de se connecter à un réseau informatique via l’infrastructure des réseaux téléphoniques.↩︎. Le réseau de l’université comme le réseau du fournisseur d’accès à Internet sont connectés à d’autres réseaux, eux-mêmes connectés à d’autres réseaux. Pris ensemble, tous ces réseaux forment Internet.

Pour gérer la transmission de données sur ce réseau de réseaux, deux protocoles sont utilisés et constituent le fondement d’Internet : IP, pour Internet Protocol, et TCP, pour Transfert Control Protocol.

Le protocole IP

La métaphore postale permet de saisir le rôle du protocole IP : les deux éléments indispensables pour permettre l’envoi d’une lettre d’un expéditeur à un destinataire sont l’adresse du destinataire et un service postal qui acheminera la lettre jusqu’au destinataire. Il en va de même de la transmission de données sur Internet : le protocole IP permet d’attribuer une adresse unique à chaque ordinateur (nommée « adresse IP ») et fournit les mécanismes pour acheminer les données à bon port.

Certains ordinateurs des réseaux qui constituent Internet, les « routeurs », ont pour fonction d’aiguiller les données de l’expéditeur au destinataire. L’expéditeur encapsule les informations dans un « paquet IP » qui contient, outre les données à transférer, un certain nombre d’informations, dont l’adresse de l’expéditeur. L’ordinateur expéditeur transmet ce paquet à un routeur de son propre réseau, qui à son tour le transmet à un autre routeur, et ainsi de suite jusqu’à ce que le paquet parvienne au destinataire. Une des spécificités d’Internet est d’être entièrement décentralisé : il n’y a aucune machine centrale ayant une vue globale de l’ensemble de sa structure. Les routeurs ne connaissent d’Internet que les autres routeurs auxquels ils sont connectés. Un routeur qui reçoit un paquet IP doit donc déterminer lequel des routeurs auxquels il est connecté est le plus approprié pour rapprocher le paquet IP de son destinataire. Ce choix est fait par un ensemble d’algorithmes associés à d’autres protocoles d’échange d’informations entre routeurs qui ne seront pas détaillés ici.

Cet aspect décentralisé d’Internet est une de ses forces. Il existe toujours plusieurs chemins possibles par lesquels faire transiter un paquet IP entre deux ordinateurs. Et si, à la suite d’une panne par exemple, un chemin venait à disparaître, un autre chemin serait disponible et pourrait être utilisé. Cela fait d’Internet un réseau extrêmement robuste.

Deux propriétés du protocole IP doivent être soulignées. La première est qu’il est non fiable (ce qui ne veut pas dire « pas fiable »). Une fois envoyé, chaque paquet IP suit son propre cheminement et, s’il se perd, par exemple à cause d’une panne d’un routeur, ni l’expéditeur ni le destinataire n’en sont informés. Rien ne garantit non plus que deux paquets envoyés successivement par le même expéditeur au même destinataire arriveront dans l’ordre dans lequel ils ont été envoyés. La seconde propriété est que la taille des paquets IP est limitée, au mieux à 1280 octets, soit la taille d’un texte de 200 mots.

Le protocole TCP

La plupart des informations transitant sur Internet (courriers électroniques, pages web) dépassent largement les tailles maximales des paquets IP. Elles doivent donc être découpées en plusieurs paquets de taille appropriée par l’ordinateur expéditeur et reconstituées par l’ordinateur destinataire. Par ailleurs, les informations sont échangées dans le cadre d’interactions complexes nécessitant des transferts d’information dans les deux sens (voir par exemple le protocole HTTP décrit plus bas). Le rôle du protocole TCP est de composer des échanges de paquets IP pour proposer des services plus adaptés aux types d’échanges d’information se déroulant sur Internet. La métaphore appropriée pour décrire le protocole TCP serait celle du téléphone : une machine en contacte une autre pour établir une connexion et, une fois que cette dernière a accepté, elles disposent d’un canal, stable tant qu’aucune des deux n’interrompt la connexion, par lequel des informations de taille arbitraire peuvent transiter dans un sens comme dans l’autre.

Pour rendre cela possible, lorsqu’une machine souhaite transmettre des données, le protocole TCP se charge de les découper en un ensemble de paquets IP. Du côté de la machine réceptrice, il va se charger de réordonner les paquets IP reçus, d’en accuser la réception ou, au contraire, de redemander ceux qui se seraient perdus et de les réassembler pour reconstituer les données initiales.

TCP est une couche de communication construite par-dessus la couche IP, encapsulant et masquant les détails du protocole IP (du moins les notions de paquets et de routage, car l’adresse IP est utilisée pour identifier les machines), de la même manière qu’IP encapsule et masque les détails des protocoles liés aux connexions physiques (Ethernet, ADSL, etc.). Cette construction par couches successives, chaque couche utilisant les services de la couche inférieure pour en proposer de nouveaux, est un principe constituant d’Internet. TCP et IP sont deux protocoles permettant de transmettre des données, mais restent complètement neutres vis-à-vis des données transmises. Cela fait d’Internet une infrastructure très générique, sur laquelle différents services, ou applications, ont été conçus en construisant de nouvelles couches de protocoles par-dessus TCP. Ces protocoles spécifient la manière dont les machines doivent traiter les données que font transiter IP et TCP : par exemple, le courrier électronique, le web (basé sur le protocole HTTP décrit plus bas) ou le transfert de fichiers (ce que fait le protocole FTP, abordé plus bas également).

Lorsqu’une machine accepte une connexion TCP, il faut qu’elle puisse connaître le protocole qui structure les données qui transiteront dans cette connexion (par exemple HTTP ou FTP) afin de les interpréter et de les traiter correctement. Pour ce faire, elle dispose de différents «ports», identifiés par des numéros, et chaque demande de connexion TCP doit indiquer le port visé. À chacun de ses ports, la machine attendra des données conformes à un protocole donné. Ainsi, par exemple, HTTP sera typiquement associé au port TCP 80.

Noms de domaines

Si les adresses IP permettent d’identifier les ordinateurs sur Internet, ayant été conçues à l’usage des machines, elles sont difficiles à mémoriser pour les humains : 192.0.43.10 est un exemple d’adresse IP. Les applications construites sur Internet telles que le web ou le courrier électronique sont au contraire conçues pour être utilisées par les humains. Pour pallier ce problème de lisibilité des adresses, le Domain Name System (DNS), a été conçu. Il permet que les machines, en parallèle à leurs adresses IP, soient identifiées par un «nom de domaine», plus facilement mémorisable. Ce sont les noms qui sont couramment utilisés lors de l’accès à une page web ou de l’envoi d’un courriel. Il est plus simple de se rappeler que l’adresse d’un site web est www.exemple.com plutôt que « 192.0.43.10 » ou d’envoyer un mail à « nom@exemple.com » plutôt qu’à «nom@192.0.43.10». Il y a une correspondance entre adresse IP et nom de domaine, et des machines spécialisées, les « serveurs DNS », permettent d’effectuer la traduction du nom de domaine en adresse IP.

Le web et le protocole HTTP

Le web, ou plus précisément le World Wide Web, est un système documentaire construit sur Internet dans lequel les documents, nommés hypertextesOn trouve également d’autres types de documents sur le web : images, sons, vidéos, etc.↩︎ ou pages web, sont reliés les uns aux autres par des hyperliensPour en savoir plus sur la création du World Wide Web, voir « D’Internet au web » par Alain Mille.↩︎. Ces documents sont affichés dans des navigateurs qui permettent, grâce aux hyperliens, de naviguer d’une page à une autre. Les données qui sont échangées sur le web le sont avec le protocole HTTP, HyperText Transfert ProtocolOn trouve aussi HTTPS, pour HTTP Secure, qui fonctionne en tout point comme HTTP, si ce n’est que les données sont chiffrées.↩︎.

Lorsque deux machines s’échangent des données sur le web avec le protocole HTTP, leur rôle est asymétrique. L’une d’entre elles, le « serveur », a pour fonction de fournir des ressources ou des services, tandis que l’autre, le « client », utilise les ressources et les services du serveur. Le protocole HTTP fonctionne selon un principe de requête/réponse : le client formule une requête auprès du serveur, lequel renvoie en retour une réponse au client (il y a une polysémie autour des termes « client » et « serveur » : « client » désigne à la fois l’ordinateur qui émet la requête et le logiciel exécuté par cet ordinateur, typiquement le navigateur web ; de même, «serveur», désigne à la fois l’ordinateur destinataire de la requête et le programme chargé de traiter la requête et formuler une réponse). Un exemple typique de requête est un navigateur réclamant à un serveur une certaine page web, lequel répond en envoyant au client le code HTMLPour en savoir plus sur le HTML (HyperText Markup Language), voir aussi « Les formats » par Viviane Boulétreau et Benoît Habert.↩︎ de la page désirée. Le navigateur traite alors ce code HTML pour afficher la page à l’utilisateur.

La première fois qu’un client envoie une requête HTTP à un serveur, il ouvre une connexion TCP avec le serveur (généralement sur le port 80). Il envoie alors sa requête à travers cette connexion, et le serveur envoie en retour sa réponse par la même connexion. Cette connexion TCP peut être maintenue ouverte pour des requêtes ultérieures. Ce que spécifie HTTP est la structure des messages que le client et le serveur vont échanger à travers la connexion TCP.

URL

Les requêtes HTTP sont, de manière générale, déclenchées lorsqu’un utilisateur clique sur un lien hypertexte ou saisit une adresse dans son navigateur. Dans un cas comme dans l’autre, la requête est construite à partir d’une URL, Uniform Resource Locator.

Par exemple :

http://fr.wikipedia.org:80/w/index.php?title=Uniform_Resource_Locator&oldid=93045880#URL_absolue

Cette adresse, cette URL, a une structure particulière :

• La première partie, « http:// », spécifie qu’il faut émettre une requête HTTP pour traiter cette URL. Des URL peuvent spécifier d’autres protocoles. On rencontre par exemple sur le web des URL débutant par « mailto: », suivi d’une adresse électronique. Ces URL doivent être traitées pour l’envoi d’un courrier électronique, et cliquer sur un hyperlien pointant vers une URL de ce type déclenche, en principe, l’ouverture du logiciel de messagerie électronique.

• La seconde partie, « fr.wikipedia.org », indique le nom de la machine et le nom du domaine où se trouve la ressource (ici, il s’agit de la machine « fr » dans le domaine « wikipedia.org »), c’est-à-dire la machine avec laquelle le client doit établir une connexion TCP. Avant d’établir cette connexion, le client doit faire appel à un serveur DNS qui lui transmettra l’adresse IP correspondante.

• La troisième, « :80 », spécifie le port vers lequel la connexion TCP doit être établie. L’indication du port est facultative. S’il n’est pas mentionné, c’est par défaut sur le port 80 que la connexion se fait. Mais lorsque le serveur est configuré pour accepter les connexions HTTP sur un autre port que le port 80 (on rencontre par exemple le port 8080 lorsque le serveur repose sur la technologie JavaJava est un langage de programmation informatique créé par la société Sun Mycrosystems en 1995.↩︎), cette information doit être précisée.

• La quatrième partie de l’URL, « le chemin d’accès », ici « /w/index.php », donne un chemin dans une hiérarchie similaire à celle des fichiers sur un disque dur. Si, aux débuts du web, ce chemin indiquait en effet la localisation d’un fichier HTML sur le disque dur d’un serveur, cela est beaucoup moins vrai aujourd’hui. Les ressources ne sont pas nécessairement des fichiers préexistants à la requête, mais sont bien souvent au contraire calculées dynamiquement par le serveur. Le chemin est alors au mieux configurable, au pire imposé par une technologie chargée de traiter la requête et construire la réponse. Dans cet exemple, l’extension du fichier, « .php », indique que le fichier index.php est un programme écrit dans le langage de programmation PHPPHP est un acronyme récursif signifiant « PHP : Hypertext Preprocessor ».↩︎, qui permet précisément de construire dynamiquement des documents HTML.

• La construction de la ressource par un programme exécuté sur le serveur peut faire intervenir des paramètres. Ce sont de tels paramètres qui sont indiqués par la partie suivante de l’URL, la « chaîne d’interrogation » : « ?title=Uniform_Resource_Locator&oldid=93045880 ». Il y a ici deux paramètres, le premier ayant pour nom «title» et pour valeur « Uniform_Resource_Locator », le second ayant pour nom « oldid » et pour valeur « 93045880 ». Dans cet exemple, le programme « /w/index.php » construit la version passée d’une page Wikipédia, la version ayant pour identifiant « 93045880 » de la page ayant pour titre « Uniform Ressource Locator ».

• La dernière partie de l’URL, « #URL_absolue », désigne un « fragment » de la ressource. La réponse du serveur à une requête à cette URL sera la totalité de la ressource, mais le navigateur focalisera l’affichage sur le fragment ayant pour identifiant « URL_absolue ». Dans cet exemple, la section « URL absolue » de la page Wikipédia.

Structure des requêtes et des réponses HTTP

Les requêtes et réponses HTTP sont constituées de deux parties, un en-tête qui contient des informations propres au protocole HTTP, et un corps qui contient les données échangées (par exemple, le code HTML de la page renvoyée par le serveur).

L’URL contient une grande partie des informations nécessaires à la construction d’une requête. Le nom de domaine et le port sont utilisés pour établir la connexion TCP, tandis que le chemin d’accès et la chaîne d’interrogation font partie des informations constituant l’en-tête de la requête.

Si, comme l’illustre l’exemple ci-dessus, HTTP permet à un client de réclamer une ressource à un serveur, d’autres types de requêtes sont possibles. Le type d’une requête est identifié par la « méthode HTTP », une autre information que l’on va trouver dans l’en-tête d’une requête HTTP. Ces méthodes sont au nombre de neuf, mais les navigateurs web n’utilisent typiquement que deux d’entre elles. La « méthode GET » est celle qui serait typiquement utilisée à partir de l’URL utilisée en exemple ci-dessus. Cette méthode indique au serveur que le client demande une ressource. À l’inverse, il arrive que le client souhaite transmettre des informations au serveur plutôt que d’accéder à une ressource particulière. C’est le cas, par exemple, lorsqu’un utilisateur remplit un formulaire pour se créer un compte sur un service en ligne. La « méthode POST » est alors utilisée par le client qui insère alors les informations fournies pas l’utilisateur (son nom, son mot de passe, son adresse de courrier électronique, etc.) dans le corps de la requête. Le serveur a alors pour tâche de traiter ces informations afin qu’elles puissent servir lors des futures interactions entre l’utilisateur et le service (par exemple, lorsqu’il s’identifiera).

Outre la méthode, le chemin d’accès et la chaîne d’interrogation, l’en-tête HTTP est également constitué d’un ensemble de paramètres. Ceux-ci permettent, entre autres choses, de transmettre les identifiants de l’utilisateur ou de préciser la requête en spécifiant, par exemple, le format ou la langue de ressource attendue en réponse. Un de ces paramètres est le « cookie ». Un cookie, ou témoin de connexion, est une suite d’informations envoyée par un serveur au client dans une réponse HTTP, et que le client renvoie systématiquement lors des requêtes ultérieures à ce même serveur. Les cookies permettent aux serveurs d’enregistrer des informations sur l’utilisateur à l’origine d’une requête et de les réutiliser lors des requêtes suivantes. Ces informations peuvent être des préférences de l’utilisateur quant au fonctionnement ou à l’aspect du site, ou encore le fait qu’il s’est déjà identifié. Elles assurent une continuité dans le traitement d’un utilisateur.

Le premier élément de l’en-tête d’une réponse HTTP, le « statut », indique la manière dont le serveur a traité la requête du client. Par exemple, le statut « 200 OK » indique que la requête a été correctement traitée : le corps de la réponse contiendra alors la ressource demandée par une requête GET ou un document attestant que les informations transmises par une requête POST ont bien été traitées. À l’inverse, le statut « 404 Not Found » indique que la ressource désignée par l’URL n’a pas pu être fournie par le serveur, soit parce qu’il ne l’a pas trouvée, soit parce qu’il n’a pas su la construire.

L’en-tête contient également des métadonnées sur la ressource renvoyée : son format, sa taille, sa langue. L’en-tête peut aussi comprendre un cookie, que le client enregistrera pour des requêtes futures et des informations de redirection, indiquant au navigateur qu’il doit se rendre sur une autre page, c’est-à-dire formuler une nouvelle requête.

D’autres protocoles basés sur Internet : SSH et FTP

Si le web et le courrier électronique sont les applications les plus populaires d’Internet, ce ne sont pas les seules. Deux autres sont présentées ici, l’échange de fichiers au moyen du protocole FTP (File Transfert Protocol) et la connexion à distance en ligne de commande avec le protocole SSH (Secure Shell).

L’échange de fichiers par le protocole FTP

Le principe du protocole FTP est de permettre à un client de parcourir l’arborescence de fichiers d’un serveur et de transférer des fichiers du serveur vers le client et inversement. FTP permet aussi de créer et de supprimer des répertoires sur le serveur et d’y supprimer des fichiers.

Pour se connecter à un serveur FTP, un utilisateur a besoin d’un client FTP (par exemple FilezillaCréé en 2001, Filezilla est un client FTP sous licence publique générale (GNU).↩︎) auquel il spécifie le nom du serveur (qui sera traduit en adresse IP par un serveur DNS), le port (par défaut 21), son identifiant et son mot de passe. L’identification de l’utilisateur permet au serveur de déterminer quels sont les droits de lecture et d’écriture de l’utilisateur pour chaque répertoire et fichier de l’arborescence. Certains serveurs acceptent des connections anonymes.

La connexion à distance en ligne de commande avec le protocole SSH

Les systèmes d’exploitation de la famille UNIX (tels que Linux ou Mac OS) proposent, en plus de leur interface graphique, une interface en ligne de commandeLes systèmes d’exploitation Windows aussi, mais il s’agit d’une interface beaucoup plus pauvre.↩︎. Bien que purement textuel, ce mode d’interaction avec l’ordinateur se révèle souvent plus puissant que l’interface graphique. Il est donc intéressant de pouvoir se connecter en ligne de commande à une machine distante. C’est ce que permet de faire le protocole SSH.

Comme avec le protocole FTP, l’utilisateur qui souhaite utiliser le protocole SSH doit avoir un compte sur le serveur auquel il souhaite se connecter. À la différence de HTTP et de FTP, pour lesquels il existe des logiciels clients avec une interface graphique (les navigateurs web en sont l’exemple le plus évident), une connexion SSH ne s’établit qu’à partir de la ligne de commandeDes clients HTTP et FTP en ligne de commande existent aussi. Ainsi, la commande FTP permet d’initier une connexion avec un serveur FTP et de saisir des commandes directement avec le clavier.
Lynx est un navigateur web entièrement en mode texte, avec lequel on interagit donc uniquement avec le clavier. La commande cURL est très générique et supporte un grand nombre de protocoles.↩︎, à l’aide de la commande « ssh ». Pour Windows, il est nécessaire d’utiliser un client spécifique, tel que PuTTYPuTTY est un logiciel libre.↩︎.

Voici un panorama des protocoles d’échange de données sur Internet. Le respect de ces standards a rendu possible la construction d’un réseau complexe comme le web au sein duquel un nombre très élevé de machines peuvent communiquer. La facilité de la circulation de l’information déterminée par la mise en place de ces conventions est une des bases du modèle actuel de diffusion des contenus.

Contenus additionnels

Jean-Philippe Magué

Jean-Philippe Magué est maître de conférence en Humanités Numériques à l’ENS Lyon et membre du laboratoire ICAR (Interactions, Corpus, Apprentissages, Représentations). Il travaille plus particulièrement sur les nouvelles pratiques scientifiques en lettres et sciences humaines engendrées par l’accès à un nombre croissant de données numériques et sur l’utilisation des outils permettant de les exploiter.