Afin de vous aider à comprendre comment Internet fonctionne, nous verrons ce qui se passe lorsque vous effectuez une opération classique -- pointer dans un navigateur ce document à partir du site Web de référence du Projet de Documentation de Linux (Linux Documentation Project). Ce document est :
http://sunsite.unc.edu/LDP/HOWTO/Fundamentals.html
ce qui veut dire qu'il réside dans le fichier LDP/HOWTO/Fundamentals.html, sous le répertoire exporté World Wide Web de la machine sunsite.unc.edu.
La première chose que votre navigateur doit faire est d'établir une connexion réseau avec la machine sur laquelle se trouve le document. Pour faire cela, il doit tout d'abord trouver la localisation réseau de l'hôte sunsite.unc.edu (hôte est un raccourci pour `machine hôte' ou `hôte réseau' ; sunsite.unc.edu est un nom d'hôte (hostname) typique). La localisation correspondante est en fait un nombre appelé adresse IP (nous expliquerons la partie `IP' de ce terme plus tard).
Pour faire cela, votre navigateur sollicite un programme nommé serveur de noms. Le serveur de noms peut résider sur votre machine, mais il est plus probable qu'il soit sur une machine de service avec laquelle vous pouvez dialoguer. Lorsque vous abonnez chez un Fournisseur d'Accés à Internet (FAI), une partie de la procédure d'installation décrit certainement la manière d'indiquer à votre logiciel Internet l'adresse IP du serveur de noms du réseau du FAI.
Les serveurs de noms sur différentes machines communiquent avec les autres en échangeant et en gardant à jour toutes les informations nécessaires à la résolution de noms d'hôte (en les associant à des adresses IP). Votre serveur de noms doit demander à trois ou quatre sites à travers le réseau afin de résoudre sunsite.unc.edu, mais cela se déroule vraiment rapidement (en moins d'une seconde).
Le serveur de noms dira à votre navigateur que l'adresse IP de Sunsite est 152.2.22.81 ; sachant cela, votre machine sera capable d'échanger des bits avec Sunsite directement.
Ce que le navigateur veut faire est d'envoyer une commande au serveur Web sur Sunsite qui a la forme suivante :
GET /LDP/HOWTO/Fundamentals.html HTTP/1.0
Que se passe-t-il alors ? La commande est faite de paquets ; un bloc de bits comme un télégramme est découpé en trois choses importantes : l'adresse source (l'IP de votre machine), l'adresse destination (152.2.22.81), et le numéro de service ou numéro de port (80, dans ce cas) qui indique que c'est une requête World Wide Web.
Alors votre machine envoie le paquet par le fil (de la connexion modem avec votre FAI, ou le réseau local) jusqu'à ce qu'il rencontre une machine spécialisée appelée routeur. Le routeur possède une carte de l'Internet dans sa mémoire -- pas une complète mais une qui décrit votre voisinage réseau et sait comment aller aux routeurs pour les autres voisinages sur l'Internet.
Votre paquet peut passer à travers plusieurs routeurs sur le chemin de sa destination. Les routeurs sont adroits. Ils regardent combien de temps prend un accusé réception pour recevoir un paquet. Ils utilisent cette information pour aiguiller le trafic sur les liens rapides. Ils l'utilisent pour s'apercevoir que d'autres routeurs (ou un câble) sont déconnectés du réseau et modifier le chemin si possible en trouvant une autre route.
Il existe une légende urbaine qui dit qu'Internet a été conçu pour survivre a une guerre nucléaire. Ce n'est pas vrai, mais la conception d'Internet est extrêmement bonne en ayant une performance fiable basé sur des couches matérielles d'un monde incertain... C'est directement du au fait que son intelligence est distribuée à travers des milliers de routeurs plutôt qu'à quelques auto-commutateurs massifs (comme le réseau téléphonique). Cela veut dire que les défaillances tendent à être bien localisées et le réseau peut les contourner.
Une fois que le paquet est arrivé à destination, la machine utilise le numéro de service pour le fournir au serveur Web. Le serveur Web peut savoir à qui répondre en regardant l'adresse source du paquet. Quand le serveur Web renvoie ce document, il sera coupé en plusieurs paquets. La taille des paquets varie en fonction du média de transmission du réseau et du type de service.
Pour comprendre comment des transmissions de multiples paquets sont réalisées, vous devez savoir que l'Internet utilise actuellement deux protocoles empilés l'un sur l'autre.
Le plus bas niveau, IP (Internet Protocol), sait comment recevoir des paquets individuels d'une adresse source vers une adresse destination (c'est pourquoi elles sont appelées adresses IP). Cependant, IP n'est pas fiable ; si un paquet est perdu ou jeté, les machines source et destination ne le sauront jamais. Dans le jargon réseau, IP est un protocole sans connexion (ou mode non connecté) ; l'expéditeur envoie juste un paquet au destinataire et n'attend jamais un accusé de réception.
Cependant, IP est rapide et peu coûteux. Quelquefois, rapide, peu coûteux et non fiable c'est OK. Lorsque vous jouez en réseau à Doom ou Quake, chaque balle est représentée par un paquet IP. Si quelques-unes sont perdues, c'est OK.
Le niveau supérieur, TCP (Transmission Control Protocol), fournit la fiabilité. Quand deux machine négocient une connexion TCP (ce qu'elles font en utilisant IP), le destinataire doit envoyer des accusés de réception des paquets qu'il reçoit à l'expéditeur. Si l'expéditeur ne reçoit pas un accusé de réception pour un paquet après un certain temps, il renvoie ce paquet. De plus, l'expéditeur donne à chaque paquet TCP un numéro de séquence, que le destinataire peut utiliser pour ré-assembler les paquets dans le cas où il sont arrivés dans le désordre. (Cela peut arriver si les liens réseau se rétablissent ou cassent pendant une connexion.)
Les paquets TCP/IP contiennent également un checksum pour permettre la détection de données altérées par de mauvais liens. Ainsi, du point de vue de quelqu'un utilisant TCP/IP et des serveurs de noms, il ressemble à une voie fiable pour faire passer des flux d'octets entre des paires hôte/numéro de services. Les gens qui écrivent des protocoles réseau ne doivent pas se soucier la plupart du temps de la taille des paquets, du ré-assemblage des paquets, de la vérification d'erreurs, le calcul du checksum et la retransmission qui sont au niveau inférieurs.
Maintenant revenons à notre exemple. Les navigateurs et les serveurs Web parlent un protocole d'application qui est au dessus de TCP/IP, en l'utilisant simplement comme une manière de passer des chaînes d'octets dans les deux sens. Ce protocole est appelé HTTP (Hyper-Text Transfer Protocol) et nous en avons déjà vu une commande -- la commande GET utilisée ci-dessus.
Lorsque la commande GET arrive au serveur Web de sunsite.unc.edu avec comme numéro de service 80, elle sera expédiée à un démon serveur qui écoute le port 80. La plupart des services Internet sont implémentés par des démons serveurs qui ne font rien d'autre qu'attendre sur des numéros de port, récolter et exécuter les commandes entrantes.
Cette conception de l'Internet a une règle qui prime sur les autres, c'est que toutes les parties sont le plus simple possible et humainement accessible. HTTP, et ses compères (comme le Simple Mail Transfer Protocol, SMTP, qui est utilisé pour transporter du courrier électronique entre des machines) utilisent de simples commandes de texte qui se terminent par un retour chariot.
C'est rarement inefficace ; dans certaines circonstances vous pouvez obtenir plus de rapidité en employant un protocole binaire fortement codé. Mais l'expérience a montré que le bénéfice d'avoir des commandes qui sont faciles à décrire et à comprendre l'emportent sur le gain marginal de l'efficacité que l'on peut espérer au prix de choses compliquées et compactes.
Par conséquent, ce que le démon serveur vous renvoie via TCP/IP est aussi du texte. Le début de la réponse ressemblera à quelque chose comme (quelques en-têtes ont été supprimés) :
HTTP/1.1 200 OK Date: Sat, 10 Oct 1998 18:43:35 GMT Server: Apache/1.2.6 Red Hat Last-Modified: Thu, 27 Aug 1998 17:55:15 GMT Content-Length: 2982 Content-Type: text/html
Ces en-têtes seront suivis d'une ligne vide et du texte de la page Web (après que la connexion sera rompue). Votre navigateur affichera simplement cette page. Les en-têtes indiquent -- en particulier, l'en-tête Type de Contenu (Content-Type) -- comment les données reçues sont vraiment du HTML).