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).
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:24