La couche Application

1. Quel besoin ?

L’homme, au contraire des machines, n’est pas très à l’aise avec les identifiants quand ils sont formés de longues suites numériques, il leur préfère des noms symboliques. Passe encore quand il s’agit de mémoriser un numéro de téléphone à 10 chiffres ou une adresse IPv4, mais imaginez que le téléphone de demain identifie votre correspondant par une suite de 32 symboles hexadécimaux (l’adresse IPv6). À moins que d’ici là il ne soit devenu possible d’implanter des puces bioniques sous la peau, nous voilà dans l’absolu besoin de concevoir un système qui nous permette de substituer un nom symbolique à un identifiant numérique. Mais attention, si l’unicité de l’identifiant numérique est assurée, il faut que le nom associé soit tout aussi unique.

Aux débuts d’Internet, la transcription des noms en adresses s’appuyait sur une table de correspondances maintenue par le NIC (Network Information Center) sous forme d’un unique fichier HOSTS.txt, lequel était transmis via FTP à tous les hôtes (RFC 952, RFC 953). Cette procédure, très consommatrice de bande passante (un doublement du nombre d’hôtes entraîne un doublement de la taille de la base et il faut transmettre cette base à deux fois plus d’hôtes, donc la bande passante consommée est multipliée par quatre), n’a évidemment pas résisté à la croissance exponentielle du nombre d’hôtes (3100 en 1986, 137000 en 1990, plus de 4 millions en 1995).

Par ailleurs, l’informatique a connu une phase de « downsizing » qui a remplacé progressivement les ordinateurs centraux (Mainframes) par des machines PC en réseaux. Les organisations en charge de l’administration de tels réseaux dépendaient du NIC pour que leurs machines deviennent visibles de la communauté Internet et souhaitaient davantage d’autonomie.

En 1983, à la demande de Jon Postel (l’un des plus éminents pères fondateurs d’Internet), Paul Mockapetris propose une architecture de noms de domaine dans les RFC 882 et 883. Ces deux RFC sont mis à...

1. L’hypertexte

Toujours à court de superlatifs, super, hyper, giga, voilà que notre belle époque technologique nous amène un texte hyper. En quoi est-il hyper ? Essentiellement par le fait qu’il comporte des renvois à d’autres documents. C’est bien sûr la version numérique qui est intéressante parce qu’il est possible de suivre le lien « hypertexte » (le renvoi) de façon quasi-instantanée et donc de naviguer dans ce qui devient une sorte de documentation globale à travers les liens relationnels établis. Exit la lecture en séquence du début jusqu’à la fin d’un document ou d’un ouvrage. Le document global résulte d’un assemblage complexe de fragments de documents liés par des relations sémantiques (qui donnent du sens). Dès lors, faire évoluer un document prend une double signification : il peut s’agir de faire évoluer le fond, le contenu ou les relations entre fragments.

Le document se dématérialise, la localisation géographique des fragments n’a plus d’importance. Le concept dépasse aujourd’hui celui du texte, il faudrait parler d’hypermédia, les fragments sont de toute nature, sonores, images fixes ou vidéos.

2. Le Web

Les concepts hypertexte et hypermédia se sont concrétisés dans ce que l’on appelle le « World Wide Web », littéralement la toile (d’araignée) mondiale et que chacun désignera à sa guise en choisissant parmi les termes ou acronymes tels que Web, Toile ou www.

C’est la couche Application qui permet à un ensemble de serveurs de coopérer sur le réseau Internet afin de fournir des documents typés (texte simple ou balisé, image fixe ou animée…) à la demande, c’est-à-dire en réponse à des requêtes de clients qui souhaitent les consulter :

Nombre de ces documents contiennent des liens vers d’autres documents, que ceux-ci soient hébergés sur le même serveur ou non. Un document global en cours de consultation résulte de l’assemblage virtuel de tous les fragments obtenus suite à...

1. Contexte

HTTP avait permis de profiter d’une ressource très construite, comprenant à la fois du contenu, une « mise en scène » de ce contenu, des relations sémantiques. Rien de tout cela avec FTP, il s’agit ici de transférer un fichier. Avant le transfert, le fichier existe sur une machine X. Après le transfert, ce fichier existe à la fois sur la machine X et sur la machine Y. FTP a transféré et donc cloné le fichier (à quelques restrictions près). Peut-être ces dernières années ont-elles vu la montée en importance des navigateurs et donc du protocole HTTP. Certains jeunes internautes peuvent ignorer l’importance qu’a eue le protocole FTP.

En caricaturant, on a affaire à deux philosophies qui s’affrontent : faut-il travailler à distance sur une ressource en ligne ou rapatrier cette ressource localement puis travailler cette ressource hors ligne ? La complexité est du côté « en ligne », l’efficacité et la rapidité restent l’apanage du « hors ligne ». Mais avec des débits offerts sans cesse croissants et la puissance des processeurs modernes qui permet d’exploiter ces débits, le « en ligne » est peut-être en train de l’emporter. L’administrateur ne peut pourtant pas ignorer complètement le protocole FTP.

Le premier RFC traitant ce sujet remonte à avril 1971 (RFC 114). Le RFC actuel est le RFC 959 amendé par de nombreux RFC. Construire un protocole de transfert de fichiers de bout en bout : évident quand on dispose déjà d’un protocole de transport aussi abouti que TCP ! En fait, il faut vite déchanter, la couche Application doit régler nombre de problèmes non pris en charge par la couche Transport :

1. Contexte

L’application courrier électronique est incontestablement l’une des applications les plus importantes que nous ait apportées TCP/IP. Elle a révolutionné la communication en entreprise mais le particulier l’a adoptée également et de fait, elle est maintenant incontournable. Elle représenterait la moitié des connexions TCP de l’Internet, ce qui ne signifie pas qu’elle soit la première consommatrice de bande passante (cela dépend de la taille moyenne des messages). 

Pourquoi parle-t-on de courrier électronique ? La comparaison avec le courrier « postal » est implicite. Pourquoi vouloir communiquer avec son correspondant en lui envoyant une lettre plutôt qu’en lui téléphonant ? Essentiellement pour deux raisons :

Le courrier électronique fonctionne très exactement de la même façon. La différence tient aux délais. Envoyer une lettre, c’est avoir...

1. Contexte

Nous avons déjà comparé l’informatique centralisée des années 1970 et l’informatique répartie actuelle. Adoptons le point de vue de l’administrateur. Dans les années 70, il s’éloigne rarement de la salle informatique. Puisque l’ordinateur est central, l’administration est centralisée. L’informatique répartie a multiplié les points à administrer : serveurs, commutateurs, routeurs. Évidemment, ces points sont dispersés sur les différents sites de l’entreprise. Comment éviter d’épuiser notre administrateur dans des déplacements incessants ? En lui permettant d’intervenir sur n’importe quel point à partir de l’endroit où il se trouve. C’est ce qu’on appelle la prise de main à distance.

TELNET (Teletype Network) est l’application historique de la pile TCP/IP qui permet cette prise de main. Comme souvent, le mot-clé TELNET recouvre plusieurs réalités : TELNET est à la fois une application du modèle OSI-RM et un protocole d’échange.

Il sera souvent question de terminal dans cette section. Le terminal physique, tel qu’il existait à l’époque de l’informatique lourde, est un ensemble clavier - écran - port série. Tout caractère frappé au clavier est envoyé vers l’ordinateur central via le port série. Tout caractère reçu de l’ordinateur central via le port série est affiché à l’écran. Toute l’intelligence est dans l’ordinateur, le terminal ne dispose que du minimum d’intelligence nécessaire pour gérer sa liaison série. Le terminal est lui-même une adaptation « moderne » du téléscripteur, qui ressemblait à une machine à écrire, et qui faisait office de périphérique...