tuteurs.ens.fr/theorie/internet.tml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
  PUBLIC "-//ENS/Tuteurs//DTD TML 1//EN"
  "tuteurs://DTD/tml.dtd">
<html>
<head>
<title>Internet</title>
</head>
<body>

<h1>Comment marche Internet</h1>

<h2>Relier les ordinateurs</h2>

<h3>Le principe</h3>

<p>
Un câble, d'un côté quelqu'un qui envoit du courant par intermittence, de
l'autre quelqu'un qui regarde quand il y a du courant. C'est le principe du
télégraphe, avec le code Morse. Et ça s'adapte vraiment parfaitement aux
ordinateurs. Les ordinateurs peuvent même faire mieux : ils ont des
métronomes (dans le domaine informatique on parle d'horloges) qui battent
très précisément la mesure ; à chaque tic, ils peuvent envoyer ou pas le
courant, ça fait un bit d'information à chaque fois.
</p>

<p>
Nous ne rentrerons pas dans les détails de la réalisatoin physique : ça
peut aller d'une bête paire de fils sur à peine plus d'un mètre à un
faisceau de fibres optiques, en passant par un câble coaxial. Ça peut
également être des ondes radio, ou bien le fait de dire ou de ne pas dire
bip sur une ligne téléphonique. Bref, il y a plein de manières pour deux
ordinateurs de se dire 0 ou 1.
</p>

<p>
Ça, c'est bien pour relier deux ordinateurs. Mais comment faire s'il y en a
plusieurs ? Tirer un câble entre chaque paire n'est pas envisageable. La
solution la moins coûteuse, et donc celle qui a été rapidement préférée, est
d'utiliser un seul câble qui connecte tous les ordinateurs. Quand un
ordinateur veut parler, il parle à tous les autres, et il faut inventer des
moyens pour que deux ne parlent pas en même temps. Le système de ce genre le
plus répandu consiste en un câble coaxial où tous les ordinateurs sont
branchés en sérié ; plus récemment on a adopté une structure en étoile
autour d'un appareil bon marché appelé hub, plus efficace et plus robuste
que la structure en série.
</p>

<p>
Plusieurs ordinateurs, c'est bien, mais relier beaucoup d'ordinateur, c'est
mieux. La technologie des câbles impose des limites de longueur, et il est
rarement possible de relier directement un câble coaxial de réseau
domestique à un faisceau de fibres optiques transatlantique. La solution
consiste alors à avoir une machine branchée sur les deux (ou plus) réseaux,
avec pour tâche de faire suivre l'information de l'un à l'autre ; quand un
ordinateur d'un réseau veut parler à un ordinateur de l'autre réseau, il
adresse son message à cette machine, avec une étiquette indiquant le
destinataire. On appelle une telle machine un <dfn>routeur</dfn>.
</p>

<h3>Comment on fait, en vrai, sur Internet</h3>

<p>
Pour les réseaux locaux (les
<abbr lang="en" title="Local Area Network">LAN</abbr> quand on veut faire
moderne), la technologie employée est <dfn>ethernet</dfn>. Elle fonctionne
soit avec un câble coaxial en série, soit avec un câble simple (à huit fils
dont peu sont vraiment utilisés) organisé en étoile autour d'un hub. Avec
ethernet, les données sont envoyées par blocs appelés trames qui font au
plus environ 1,5 ko. Il n'y a pas de système pour s'assurer <i>a priori</i>
que deux ordinateurs sur le câble ne parlent pas en même temps : la
détection se fait <i>a posteriori</i> par le fait que le signal est alors
incompréhensible ; les deux ordinateurs réémettent alors après un délai
aléatoire, qui sera probablement différent ; en pratique, ce système marche
plutôt bien.
</p>

<p>
Au début de chaque trame ethernet, ou trouve ce qu'on appelle un
<dfn>entête</dfn> : quelques octets réservés par le protocole ethernet
lui-même pour son fonctionnement interne. Toutes les cartes réseau ethernet
possèdent une adresse
<abbr lang="en" title="Media Access Control">MAC</abbr> depuis l'usine (mais
les cartes modernes permettent de la changer), qui est code unique de six
octets. Par exemple sas.eleves a pour adresse MAC
<code>52:54:00:62:1b:66</code>. Dans l'entête ethernet, on trouve l'adresse
MAC de l'ordinateur auquel la trame est adressée (ainsi que celle de
l'ordinateur qui envoit). En temps normal, le filtrage se fait directement
au niveau de la carte réseau, de sorte que parmi les ordinateurs sur un même
câble, seul celui qui est concerné voit effectivement un message.
</p>

<p>
Dans l'entête ethernet, on trouve également un numéro de protocole. C'est un
petit nombre, sur deux octets, qui décrit très brièvement ce qu'on prévoit
de faire avec les données de la trame.
L'<abbr lang="en" title="Internet Assigned Numbers Authority">IANA</abbr>
tient à jour une
<a href="http://www.iana.org/assignments/ethernet-numbers">table des numéros
ethernet</a> attribués. Ainsi, le système d'exploitation de l'ordinateur qui
a reçu la trame peut immédiatement appeler le bon sous-système, ou ignorer
la trame s'il ne sait pas quoi en faire. Pour illustrer, quand on utilise
ethernet pour faire passer de l'« Internet », le numéro est 513. Ce
mécanisme de numéros décrivant le genre d'utilisation d'un système est très
général, et on le retrouve à tous les niveaux des protocoles Internet.
</p>

<p>
Quand on utilise une ligne téléphonique, le protocole employé est le
<span lang="en">Point to Point</span> (PPP). Il a des mécanismes différents
parce qu'il ne relie que deux ordinateurs, mais sous des contraintes
différentes (ligne moins fiable et temps de latence supérieur).
</p>

<h2>Relier les réseaux</h2>

<h3>Le routage</h3>

<p>
Mettez une lettre à la poste. Si le destinataire habite dans la même ville,
elle lui sera distribuée directement. S'il habite dans une ville voisine, le
facteur transmet la lettre à son collègue de cette ville. S'il habite plus
loin, le facteur transmettra la lettre au centre de tri dont il dépend. Et à
son tour, le centre de tri va faire suivre la lettre à qui de droit. La
lettre va donc passer par différentes étapes où elle sera redirigée en
fonction de l'adresse qui est écrite dessus.
</p>

<p>
Les réseaux informatiques, dès qu'ils dépassent les quelques dizaines de
machines qu'on peut brancher sur un même câble, fonctionnent de la même
manière : les données sont découpées en <dfn>paquets</dfn>, qui jouent le
rôle de notre enveloppe. Quand il n'est pas possible de transmettre le
paquet directement à son destinataire, il est transmis à un ordinateur
(défini dans la configuration du réseau) appelé <dfn>routeur</dfn>. Cet
ordinateur est censé être capable de faire suivre le paquet ; ça suppose par
exemple qu'il est relié par un autre câble à un autre réseau.
</p>

<p>
Pour pouvoir marcher, ce système a besoin que les ordinateurs soient dotés
d'une adresse qui reflète leur position dans le réseau global. L'adresse MAC
ne convient pas pour cette tâche, d'une part parce que elle est (plus ou
moins) immuable et ne correspond en rien à la position sur le réseau (un
portable qu'on débranche d'un endroit et rebranche a un autre ne change pas
d'adresse MAC), et d'autre part parce qu'on souhaite que ça fonctionne avec
différents types de connexion (les modems pour les connexions PPP, par
exemple, n'ont pas d'adresse MAC). On invente alors un nouveau système
d'adresses, indépendant du protocole utilisé pour connecter les ordinateurs. 
</p>

<h3>Le protocole IP</h3>

<p>
Ce qui fait Internet, c'est
<abbr lang="en" title="Internet Protocol">IP</abbr> (et l'on découvre que le
titre de cette section est un pléonasme). Ce protocole décrit la structure
des adresses utilisée, la manière d'écrire ces adresses dans les paquets, et
les moyens d'assurer leur bonne circulation.
</p>

<p>
Nous utilisons actuellement la version 4 d'IP, ce qu'on indique parfois par
IPv4. Dans cette version, les adresses sont constituées de 32 chiffres
binaires (bits), ce qu'on écrit généralement sous la forme de quatre nombres
entre 0 et 255. Par exemple, l'adresse IP de sas.eleves est 129.199.129.11. Une
nouvelle version d'IP, IPv6, est progressivement mis en place ; les adresses
y font 128 bits, et sont écrites en hexadécimal ; l'ENS n'est pas reliée en
IPv6, mais si vous voulez un exemple, 2001:660:3001:4002:2C0:4FFF:FE4E:41D3
est l'adresse IPv6 du serveur web de
<a href="http://www.renater.fr/">Renater</a>.
</p>

<p>
Tout ordinateur relié à Internet possède (au moins) une adresse IP, et il
est le seul à la posséder (dans Internet). Ces adresses sont structurées en
réseaux et sous-réseaux, en fixant les chiffres de gauche à droite. Ainsi,
toutes les adresses en 129.199.x.y sont dans l'ENS, et celles en
129.199.129.y sont plus particulièrement dans la salle S. De l'extérieur,
quelqu'un qui veut envoyer un paquet à 129.199.129.1 a seulement à savoir
qu'il doit l'envoyer à l'ENS. C'est ensuite à nos routeurs de finir le
travail.
</p>

<p>
Les paquets IP comportent tous l'adresse IP de l'expéditeur, celle du
destinataire, une somme de contrôle qui permet de vérifier qu'il est intact,
et un numéro de protocole indiquant à quoi va servir ce paquet. Ils
comportent également un compteur qui limite le nombre de routeurs par lequel
il peut passer (de manière à ce qu'un paquet perdu ne reste pas éternellement
à circuler entre des routeurs mal configurés), ainsi que quelques autres
options. Un des principes d'Internet, c'est que les routeurs font le strict
minimum : ils doivent se contenter de faire suivre les paquets sans les
altérer (sauf le compteur ; si un paquet a atteint la limite, le routeur
l'arrête et envoit un paquet à l'expéditeur pour signaler l'erreur). Un des
autres principes est que tous les ordinateurs sont égaux : du point de vue
du protocole, rien ne distingue le super ordinateur central de la NASA de
votre petit PC personnel ; en particulier, rien ne distingue un serveur d'un
poste client.
</p>

<p>
IP est conçu sur un principe de <span lang="en">best effort</span> (meilleur
effort) : les infrastructures (les routeurs) font leur possible pour faire
parvenir vos paquets, mais sans aucune garantie. Un paquet peut disparaître
sans laisser de trace, ou bien se perdre au mauvais endroit (mais il n'ira
en général pas bien loin), ou encore être retardé et arriver après un paquet
pourtant parti plus tard. Il arrive même qu'un paquet arrive en plusieurs
exemplaires. Bien sûr, <em>en général</em>, les paquets arrivent bien, et
dans l'ordre. Ce principe du meilleur effort a l'avantage d'être simple et
léger ; il est ensuite possible de concevoir un système d'accusés de
réception et de numéros d'ordre pour assurer la fiabilité de la
transmission.
</p>

<h2>Relier les programmes</h2>

<h3>Trier les paquets</h3>

<p>
C'est bien gentil de dire que votre ordinateur peut envoyer des paquets qui
arriveront (peut-être) à n'importe quel ordinateur dans le monde, mais vous,
ce qui vous intéresse, c'est de surfer sur le web et d'envoyer du courrier
en même temps, et que les informations arrivent. Pourtant, le web et le
courrier électronique ne sont pas toujours dans le même logiciel : il faut
donc que plusieurs applications puissent se partager le réseau, et que l'une
n'aille pas recevoir les données de l'autre.
</p>

<p>
Quand on programme une application réseau, on amierait en général avoir une
sorte de tuyau : tout ce qu'on dit d'un côté, l'application à l'autre bout
le reçoit, dans l'ordre, sans perte, et une seule fois, et inversement, on
reçoit tout ce qu'elle dit. Si les ordinateurs aux deux bouts sont d'accord,
un tel tuyau peut être simulé : on découpe ce qui doit passer dans le tuyau
en morceaux assez petits pour tenir dans des paquets, et on les expédie avec
un numéro d'ordre ; à l'autre bout, l'ordinateur répond par un paquet
accusant la réception, et utilise les numéros pour remettre de l'ordre. Si
on constate qu'un accusé de réception tarde, on réexpédie le paquet
incriminé, au pire il arrivera en double et ce n'est pas grave.
</p>

<p>
Tant qu'on en est à rajouter des numéros aux paquets, on peut ajouter encore
quelques informations. Par exemple l'identité du programme qui l'a envoyé,
ou l'identité du programme qui doit le recevoir. Avec tout ça, on peut
concevoir des <dfn>connexions</dfn> réseau : un tuyau virtuel entre un
ordinateur et un autre, avec une extrémité qui envoit des paquets, attend
des accusés de réception, et réexpédie les paquets qui se perdent, et
l'autre extrémité qui reçoit les paquets et les remet dans l'ordre. Quand un
paquet arrive sur un ordinateur, le système réseau consulte son contenu pour
voir ses références, et trouve dans ses tables à quelle connexion il
appartient.
</p>

<p>
Tout ceci est normalement fait par le système d'exploitation des
ordinateurs, et caché aux programmes. Les programmes, eux, se contentent de
réclamer une connexion, et ensuite d'utiliser le tuyau. Les données passent,
ils n'ont pas à se soucier de toute la machinerie interne.
</p>

<h3>Le protocole TCP</h3>

<p>
Sur internet, le protocole qui sert à établir des connexions est
<abbr lang="en" title="Transmission Control Protocol">TCP</abbr>. Pour
distinguer les connexions, TCP utilise un <dfn>numéro de port</dfn>, un
petit nombre (entre 1 et 65535), qu'on peut voir un peu comme le casier d'un
élève, alors que l'adresse IP correspond à « 45 rue d'Ulm ». Une connexion est
identifiée par quatre données :
</p>
<ul>
<li>l'adresse IP de l'ordinateur de départ ;</li>
<li>le port sur cet ordinateur ;</li>
<li>l'adresse IP de l'ordinateur d'arrivée ;</li>
<li>le port sur cet ordinateur</li>
</ul>
<p>
Chaque paquet échangé dans le cadre d'une connexion rappelle ces quatre
références. On peut remarquer que sur un ordinateur donné, le même port peut
participer à plusieurs connexions. De fait, ça arrive assez souvent, mais
jamais aux deux extrémités à la fois (même si rien ne l'interdit
fondamentalement).
</p>

<p>
Les connexions TCP sont toujours doubles : dans un sens et dans l'autre
entre les mêmes extrémités.
</p>

<p>
Du point de vue du programme, une connexion est un objet sur lequel on peut
lire et écrire des données. Sous Unix, ça se présente presque de la même
manière qu'un fichier. Le système d'exploitation sait à quel programme
chaque connexion active « appartient », et fait tout le nécessaire.
</p>

<h3>Clients et serveurs</h3>

<p>
Comme dans toutes relations de couple, aux débuts d'une connexion, il faut
que l'un des deux fasse le premier pas, alors que l'autre se contente
d'attendre. En informatique, l'extrémité de la future connexion qui attend
s'appelle un <dfn>serveur</dfn> (eh oui, c'est le contraire du restaurant,
où le serveur vient à votre table prendre la commande), tandis que
l'extrémité qui fait le premier pas (qui envoit le premier paquet) s'appelle
le <dfn>client</dfn>. Après l'échange de quelques paquets (trois, avec TCP)
pour vérifier qu'il y a bien un serveur au port demandé, pour se mettre
d'accord sur la taille des paquet, etc., la connexion est établié.
</p>

<p>
Une fois que c'est fait, il n'y a du point de vue du réseau plus de
différence entre les deux extrémités. Cependant, le dialogue entre les
programmes ne sera probablement pas symétrique : une fois une connexion
établie entre votre navigateur web et
<a href="http://www.google.com/">Google</a>, c'est bien votre navigateur web
qui va poser une question à Google et non l'inverse. Il arrive néanmoins que
ça finisse par être symétrique, en particulier dans le cas de dialogue en
direct (avec ytalk par exemple) ou de jeux en réseau sans serveur central.
</p>

<p>
L'important est que les deux extrémités se comprennent. Pour ça, elles
doivent encore une fois coder leurs données d'une certaine manière : encore
un protocole. Cette manière n'est d'ailleurs pas la même s'il s'agit de web,
de mail, ou d'autres activités tout aussi passionnantes.
</p>

<p>
Les plus attentifs doivent se poser une question : il y a sur l'ordinateur
de Google (dont l'adresse IP est 216.239.59.99) 65535 ports différents,
comment notre navigateur web a-t-il deviné le quel contacter ? La réponse
est simple : le web, c'est sur le port 80. Pourquoi 80 ? C'est comme ça. Les
services importants ont des numéros de port qui leur sont dédiés, l'IANA les
<a href="http://www.iana.org/assignments/port-numbers">recense</a>. Les
services moins répandus prennent un port plus ou moins au hasard, en
espérant ne pas entrer en conflit avec un autre service, et comme c'est la
même personne qui écrit les programme client et serveur c'est le même qui
est utilisé des deux côtés.
</p>

<p>
Sous Unix, il faut des droits spéciaux pour créer un serveur sur un port en
dessous de 1024, ce qui permet d'être sûr, quand on donne son mot de passe à
SSH (port 23) ou à IMAP (port 143), d'être bien en train de parler au
programme autorisé. Au dessus de 1024, c'est libre. Certains se rappellent
peut-être que le serveur web des élèves était
<code>http://www.eleves.ens.fr<strong>:8080</strong>/</code>. Ceci veut dire
qu'il était sur le port 8080 au lieu du 80 habituel, justepent parce qu'il
aurait fallu des droits supplémentaires pour avoir 80.
</p>

<p>
Pour le client, c'est en général plus simple : le programme laisse le
système d'exploitation choisir un port inutilisé. Certains programmes
forcent l'utilisation d'un port en dessous de 1024 pour prouver qu'ils ne
sont pas n'importe quel utilisateur, mais cette pratique tombe en désuétude
au profit de méthodes cryptographiques.
</p>

<h2>Plus pour nous faciliter la vie</h2>

<h3>Le DNS</h3>

<p>
Se rappeler les adresses IP, ce n'est pas facile. Et ce sera encore pire
avec IPv6. Mais le problème n'est pas nouveau : on a le même avec les
numéros de téléphone, et pour le résoudre on a inventé l'annuaire.
L'annuaire pour Internet s'appelle le
<abbr lang="en" title="Domain Name System">DNS</abbr>, et fonctionne bien
entendu en réseau.
</p>

<p>
À l'échelle d'un site, ou d'un fournisseur d'accès, il y a un (ou plusieurs)
ordinateur, que tous les autres connaissent par son adresse IP, et sur
lequel tourne un programme qui écoute sur le port 53 et qui se charge de
répondre aux questions du genre « quelle est l'adresse IP de
<code>www.google.com</code> ? ».
</p>

<p>
Ce programme n'a en général pas la réponse, mais il a l'adresse d'autres
ordinateurs à qui demander, qui eux-mêmes peuvent ne pas savoir mais avoir
l'adresse d'autres ordinateurs, etc. Le système est hiérarchique. Il y a à
la racine quelques ordinateurs (une douzaine) qui savent qui s'occupe des
<code>.com</code>, qui s'occupe des <code>.org</code>, qui s'occupe des
<code>.fr</code>, etc. Dans le cas des <code>.fr</code>, il y a encore
quelques ordinateurs, gérés par des organismes français (enfin, pas tous),
qui savent à qui s'adresser pour chaque domaine. Et ainsi de suite.
</p>

<p>
Par exemple, pour connaître l'adresse de <code>sas.eleves.ens.fr</code>, il
faut commencer par interroger l'un des serveurs racine, par exemple
198.41.0.4, qui répond qui'il ne sait pas, mais que les <code>.fr</code>
sont gérés par 192.93.0.1, 193.51.208.13, et quelques autres. Si on
interroge l'un d'entre eux, on apprend qu'il ne sait pas non plus, mais il
nous informe que <code>ens.fr</code> est géré par 129.199.96.11 (on
reconnaît le 129.199 : c'est un ordinateur de l'ENS) et quelques autres.
Enfin, on interroge 129.199.96.11, et on obtient la réponse, à savoir
129.199.129.1
</p>

<p>
Bien sûr, tous les programmes pour faire ça sont déjà écrits : quand on
programme une nouvelle application réseau, il suffit d'utiliser la bonne
fonction de la bibliothèque standard.
</p>

<div class="metainformation">
Auteur : Nicolas George.
<date value="from git" />
</div>

</body>
</html>