419 lines
19 KiB
XML
419 lines
19 KiB
XML
<?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 clipper a pour adresse MAC
|
||
<code>08:00:20:b0:24:32</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 clipper est 129.199.129.1. 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>clipper.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.
|
||
Dernière modification le <date value="$Date: 2007-07-17 10:03:07 $"/>.
|
||
</div>
|
||
|
||
</body>
|
||
</html>
|