625 lines
24 KiB
Text
625 lines
24 KiB
Text
|
<?xml version="1.0" encoding="ISO-8859-1"?>
|
|||
|
|
<!DOCTYPE html
|
|||
|
|
PUBLIC "-//ENS/Tuteurs//DTD TML 1//EN"
|
|||
|
|
"tuteurs://DTD/tml.dtd">
|
|||
|
|
<html>
|
|||
|
|
<head>
|
|||
|
|
<title>R<>seaux</title>
|
|||
|
|
</head>
|
|||
|
|
<body>
|
|||
|
|
|
|||
|
|
<h1>Qu'est-ce qu'un r<>seau<61>?</h1>
|
|||
|
|
|
|||
|
|
<p>Vous trouverez ici expliqu<71> ce qu'est un r<>seau, et comment les
|
|||
|
|
ordinateurs communiquent entre eux. En un mot, ce qu'est Internet...
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div class="encadre">Ce cours r<>sulte de la compilation d'articles
|
|||
|
|
parus dans le <cite><a
|
|||
|
|
href="&url.tuteurs;docs/hublot/">Hublot</a></cite> en 1999-2000.</div>
|
|||
|
|
|
|||
|
|
<h2>Des uns et des z<>ros</h2>
|
|||
|
|
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Les ordinateurs n'ont que deux doigts, contrairement aux humains. Ils
|
|||
|
|
comptent et manipulent l'information uniquement sous la forme de 0 et
|
|||
|
|
de 1<>; c'est le choix fondamental, l'information minimale, qui
|
|||
|
|
s'exprime ainsi (vrai/faux, ouvert/ferm<72>, oui/non, etc). Une telle
|
|||
|
|
information est appel<65>e un <em>bit</em>. Comme un bit ne contient pas
|
|||
|
|
grand'chose, on groupe plusieurs bits pour qu'ils forment, ensemble,
|
|||
|
|
une information plus complexe.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Huit bits ensemble forment un <em>octet</em>. Chaque bit a une place
|
|||
|
|
particuli<EFBFBD>re dans l'octet, ce qui permet de faire 256 combinaisons
|
|||
|
|
(2<sup>8</sup>). Un octet est adapt<70> pour coder un caract<63>re
|
|||
|
|
occidental (il y a suffisamment de place pour les 26 lettres, avec les
|
|||
|
|
minuscules, les caract<63>res accentu<74>s, les chiffres et quelques autres
|
|||
|
|
signes typographiques).
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<h3>Unit<69>s de mesure</h3>
|
|||
|
|
|
|||
|
|
<p>Les quantit<69>s de donn<6E>es traitables par les ordinateurs se
|
|||
|
|
chiffrent d<>sormais en millions et milliards d'octets. Les
|
|||
|
|
informaticiens ont donc con<6F>u des unit<69>s adapt<70>es. Le
|
|||
|
|
<em>kilo-octet</em> (<code>Ko</code>) comporte 1024 octets
|
|||
|
|
(2<sup>10</sup>). (et non 1000 : 1000 est un nombre rond en base 10,
|
|||
|
|
mais pas en base 2; en revanche, 1024 s'<27>crit 10000000000 en base 2).
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Le <em>m<>ga-octet</em> (<code>Mo</code>) est constitu<74> de 1024 Ko
|
|||
|
|
(plus d'un million de caract<63>res), et le <em>giga-octet</em>
|
|||
|
|
(<code>Go</code>) vaut 1024 Mo. On commence <20> parler de
|
|||
|
|
<em>t<>ra-octet</em> (<code>To</code>) mais c'est encore un peu trop
|
|||
|
|
cher.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Une image plein <20>cran <20><>p<EFBFBD>se<73><65> environ 1 Mo, voire plus si on veut une
|
|||
|
|
grande palette de couleurs. Une simple disquette contient environ 1.44
|
|||
|
|
Mo, et un CD-ROM 660 Mo. Un DVD-ROM p<>se jusqu'<27> 17 Go (plus de 17
|
|||
|
|
milliards de caract<63>res). Pour donner une <20>chelle de valeur, disons
|
|||
|
|
que la Bible, correctement encod<6F>e, tient en 1 Mo (un peu moins d'une
|
|||
|
|
disquette), et que l'<cite>Encyclopedia Universalis</cite>, avec
|
|||
|
|
sch<EFBFBD>mas, photos et quelques animations, rentre dans un CD-ROM.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<h2>Code Morse, multim<69>dia et centre de tri</h2>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Stocker des informations est bel et bon ; mais il est tentant de
|
|||
|
|
pouvoir en <20>changer, sans quoi la scl<63>rose guette. On peut transporter
|
|||
|
|
des disquettes, des CD-ROMs ou d'autres supports du m<>me genre ;
|
|||
|
|
c'est assez efficace en termes de d<>bit (exercice : calculer la
|
|||
|
|
quantit<EFBFBD> d'informations transportable dans une camionnette qui serait
|
|||
|
|
pleine de CD-ROMs — c'est tout simplement colossal) ; mais
|
|||
|
|
le temps de r<>ponse est long, tr<74>s long. Et puis, l'informaticien
|
|||
|
|
n'aime pas se lever de sa chaise s'il n'y est pas pouss<73> par une
|
|||
|
|
n<EFBFBD>cessit<EFBFBD> imp<6D>rieuse (aller prendre sa dose de Coca-Cola par exemple).
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Donc, il s'agit de doter les ordinateurs de moyens de
|
|||
|
|
communication. Pour coder des 0 et des 1, certains protocoles adapt<70>s
|
|||
|
|
sautent aux yeux : le code Morse par exemple. On transmet des <20>longs<67>
|
|||
|
|
et des <20>brefs<66>. Le seul probl<62>me est que le d<>bit n'est pas tr<74>s
|
|||
|
|
satisfaisant : deux bons op<6F>rateurs peuvent s'<27>changer 3 bits par
|
|||
|
|
seconde, et une visio-conf<6E>rence (de mauvaise qualit<69>) en exige au
|
|||
|
|
moins 60 000. M<>me un t<>l<EFBFBD>phone portable, <20> la qualit<69> de son
|
|||
|
|
douteuse, doit <20>changer 9 600 bits par seconde.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
N<EFBFBD>anmoins l'analogie est riche. En effet, en regardant de plus pr<70>s,
|
|||
|
|
quand un message est envoy<6F> en Morse par t<>l<EFBFBD>graphe, son texte est
|
|||
|
|
pr<EFBFBD>c<EFBFBD>d<EFBFBD> du nom du destinataire : au XIXe si<73>cle, il n'y avait pas de
|
|||
|
|
ligne directe de New-York <20> Los Angeles ; le message devait
|
|||
|
|
passer par diff<66>rents op<6F>rateurs qui recevaient le message et le
|
|||
|
|
r<EFBFBD>exp<EFBFBD>diaient imm<6D>diatement dans la bonne direction. Un message pour
|
|||
|
|
San Francisco prenait au d<>but le m<>me chemin. Ce principe de message,
|
|||
|
|
sautant de poste en poste, redirig<69> <20> chaque poste en fonction de sa
|
|||
|
|
destination, est le fondement d'Internet. C'est ce qu'on appelle un
|
|||
|
|
r<EFBFBD>seau par paquets, par opposition au t<>l<EFBFBD>phone, qui est un r<>seau par
|
|||
|
|
circuits.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<h2>Le soleil a rendez-vous avec la lune</h2>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Il existe deux types de r<>seaux : les r<>seaux par paquets et les
|
|||
|
|
r<EFBFBD>seaux par circuits. Le premier type est celui du Morse d<>crit dans
|
|||
|
|
le num<75>ro pr<70>c<EFBFBD>dent : chaque information est un message qui transite
|
|||
|
|
de centre de tri en centre de tri, suivant l'adresse du destinataire;
|
|||
|
|
personne ne s'occupe de l'int<6E>gralit<69> de la transmission, et tout
|
|||
|
|
probl<EFBFBD>me est par essence local.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Le deuxi<78>me type de r<>seau est celui du t<>l<EFBFBD>phone : un rendez-vous est
|
|||
|
|
pris entre les deux parties, une communication physique est <20>tablie
|
|||
|
|
jusqu'<27> ce que l'un des deux raccroche.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Ces deux types de r<>seaux ont des avantages et des inconv<6E>nients
|
|||
|
|
oppos<EFBFBD>s. Essentiellement :
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<ul>
|
|||
|
|
|
|||
|
|
<li> Un r<>seau par circuits permet de garantir un d<>bit, une fois la
|
|||
|
|
connexion effectu<74>e, alors que les paquets sont envoy<6F>s <20> la gr<67>ce
|
|||
|
|
de Dieu.</li>
|
|||
|
|
|
|||
|
|
<li> Un r<>seau par circuits permet aussi de garantir un temps de
|
|||
|
|
r<>ponse, param<61>tre souvent encore plus important que le
|
|||
|
|
d<>bit. Quand on envoie un paquet, on ignore par o<> il va passer ou
|
|||
|
|
m<>me s'il va vraiment arriver <20> destination.</li>
|
|||
|
|
|
|||
|
|
<li> Un r<>seau par circuits doit <20>tre homog<6F>ne : une fois la
|
|||
|
|
connexion <20>tablie, le chemin doit se comporter <20> l'identique sur
|
|||
|
|
toute sa longueur; sur un r<>seau par paquets, il est facile de
|
|||
|
|
construire des passerelles entre des liens de caract<63>ristiques
|
|||
|
|
physiques diff<66>rentes.</li>
|
|||
|
|
|
|||
|
|
<li> Un r<>seau par circuits g<>che de la bande passante (d<>bit maximal
|
|||
|
|
de donn<6E>es);: quand deux personnes sont au t<>l<EFBFBD>phones mais ne
|
|||
|
|
parlent pas, la ligne est occup<75>e.</li>
|
|||
|
|
|
|||
|
|
<li> Un r<>seau par paquets est r<>sistant aux pannes : en cas de
|
|||
|
|
coupure d'un site, les paquets peuvent <20>tre d<>tourn<72>s sur une
|
|||
|
|
autre voie.</li>
|
|||
|
|
|
|||
|
|
<li> Un r<>seau par paquets ne garantit rien sur l'int<6E>grit<69> des
|
|||
|
|
donn<6E>es : quand on envoie un message, on ne peut pas savoir
|
|||
|
|
combien de temps il va mettre pour arriver, ni s'il arrivera un
|
|||
|
|
jour, ou en un seul exemplaire; et s'il se perd, on n'est pas
|
|||
|
|
forc<72>ment pr<70>venu.</li>
|
|||
|
|
|
|||
|
|
</ul>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Actuellement, France Telecom utilise des r<>seaux par paquets pour
|
|||
|
|
toutes les communications nationales. En effet, les possibilit<69>s de
|
|||
|
|
r<EFBFBD>utilisation de la bande passante et de r<>sistance aux pannes sont
|
|||
|
|
tr<EFBFBD>s appr<70>ciables; les caract<63>ristiques habituelles en t<>l<EFBFBD>phonie
|
|||
|
|
(conversation continue, pas de perte de son) sont assur<75>es par des
|
|||
|
|
protocoles de plus haut niveau, qui tentent de r<>tablir des garanties
|
|||
|
|
de d<>bit, de corriger les erreurs, enfin bref de faire au mieux. C'est
|
|||
|
|
une <20>mulation de r<>seau par circuits, par dessus un r<>seau par paquets
|
|||
|
|
(et, bizarrement, <20>a marche).
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p class="centre"><img src="&url.tuteurs;docs/hublot/hublot03/paquets.png"
|
|||
|
|
alt="[Sch<63>ma du r<>seau]" /><br /> Figure 1 : R<>seau par paquets
|
|||
|
|
reliant A <20> B</p>
|
|||
|
|
|
|||
|
|
<h2>Le fil qui chante</h2>
|
|||
|
|
|
|||
|
|
<p class="centre"><img src="&url.tuteurs;docs/hublot/hublot04/reseau1.png"
|
|||
|
|
alt="[Sch<63>ma]" /><br /> Figure 2 : R<>seau ethernet par c<>ble
|
|||
|
|
coaxial</p>
|
|||
|
|
|
|||
|
|
<h3>Coder les 1 et les 0</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Pour connecter deux ordinateurs, il faut tout d'abord pouvoir
|
|||
|
|
repr<EFBFBD>senter les 0 et les 1 sur un m<>dium adapt<70>. Actuellement, on
|
|||
|
|
utilise principalement les m<>thodes suivantes :
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<ul>
|
|||
|
|
|
|||
|
|
<li> Modulation de fr<66>quence : les 0 et les 1 sont cod<6F>s par des sons
|
|||
|
|
de fr<66>quences diff<66>rentes (un aigu, un grave); la th<74>orie montre
|
|||
|
|
que c'est une m<>thode qui r<>siste bien au bruit. C'est ce qu'on
|
|||
|
|
utilise sur les lignes t<>l<EFBFBD>phoniques, avec un modem*. On peut
|
|||
|
|
transmettre quelques centaines de milliers de bits par seconde
|
|||
|
|
ainsi; les modems sont limit<69>s <20> 56 000 bits par seconde pour
|
|||
|
|
d'autres raisons.</li>
|
|||
|
|
|
|||
|
|
<li> Encodage RLL : un 0 est cod<6F> par un changement de polarit<69>, un 1
|
|||
|
|
par deux changements. On trouve cette m<>thode sur les r<>seaux <20>
|
|||
|
|
haut d<>bit (chaque bit contient au moins un changement de
|
|||
|
|
polarit<69>, ce qui permet de conserver la synchronisation entre
|
|||
|
|
l'<27>metteur et le r<>cepteur, m<>me lors d'une longue plage de 0). On
|
|||
|
|
peut monter <20> 100 millions de bits par seconde ainsi; on trouve
|
|||
|
|
cette m<>thode dans les r<>seaux locaux de type ethernet.</li>
|
|||
|
|
|
|||
|
|
<li> Optique : les liens <20> tr<74>s haut d<>bit sont r<>alis<69>s par fibre
|
|||
|
|
optique ou laser; les 0 et les 1 sont alors cod<6F>s en RLL ou avec
|
|||
|
|
une m<>thode analogue. Pour des raisons de co<63>t, seuls certains
|
|||
|
|
sites font usage de moyens optiques, et pour certaines liaisons
|
|||
|
|
seulement (l'universit<69> d'<27>vry utilise un laser pour relier deux
|
|||
|
|
immeubles <20>loign<67>s de 800 m<>tres l'un de l'autre).</li>
|
|||
|
|
</ul>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Le bruit est ce qui s'oppose au signal<61>; par exemple, le cours du prof
|
|||
|
|
c'est le signal, les <20>l<EFBFBD>ves qui chuchotent c'est le bruit. Au
|
|||
|
|
t<EFBFBD>l<EFBFBD>phone, le signal c'est la conversation, tandis que le bruit c'est
|
|||
|
|
la friture.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<h3>Exemples de r<>seaux</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Le cas d'un modem ne pose pas de probl<62>me, car c'est une communication
|
|||
|
|
point <20> point sur une ligne r<>serv<72>e (aucun encombrement). En
|
|||
|
|
revanche, dans un r<>seau local, on veut connecter plusieurs machines,
|
|||
|
|
<EFBFBD>ventuellement beaucoup, et on ne d<>sire pas tendre un c<>ble pour
|
|||
|
|
chaque paire de machines. L'id<69>e est donc de se partager un conducteur
|
|||
|
|
commun, ce qu'on appelle d'habitude un bus. Ensuite, il faut d<>cider
|
|||
|
|
comment partager ce bus entre les diff<66>rents ordinateurs connect<63>s
|
|||
|
|
dessus.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
En <i lang="en">token-ring</i>, un jeton (<i lang="en">token</i>) est
|
|||
|
|
transmis de station <20> station<6F>; c'est le droit de parole. Chaque
|
|||
|
|
station ne peut conserver le jeton que pendant un temps maximal donn<6E>,
|
|||
|
|
mais peut le rel<65>cher imm<6D>diatement si elle n'a rien <20> dire.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<h3>R<>seau Ethernet</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
En ethernet, la m<>thode est plus simple qu'en <i
|
|||
|
|
lang="en">token-ring</i> : quand une station veut <20>mettre un message,
|
|||
|
|
elle espionne le bus jusqu'au moment o<> il se lib<69>re (plus personne ne
|
|||
|
|
parle pendant un tr<74>s court instant); elle prend alors la parole,
|
|||
|
|
d'autorit<69>. Ce faisant, elle continue d'espionner le bus, pour voir si
|
|||
|
|
la communication passe bien; si elle est brouill<6C>e, c'est qu'une autre
|
|||
|
|
station a eu la m<>me id<69>e en m<>me temps. Dans ce cas, la station (et
|
|||
|
|
l'autre aussi, car elle est <20>galement brouill<6C>e) s'arr<72>te, attend un
|
|||
|
|
temps al<61>atoire, et recommence. Avec une bonne probabilit<69>, l'autre
|
|||
|
|
station a attendu un temps al<61>atoire diff<66>rent, et les deux messages
|
|||
|
|
partent sans brouillage. Apr<70>s un certain nombre d'essais infructueux,
|
|||
|
|
avec des d<>lais de plus en plus grands, le message est consid<69>r<EFBFBD> comme
|
|||
|
|
n'ayant pas pu passer, c'est ce qu'on appelle une collision.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Bizarrement, l'ethernet est tr<74>s efficace, et partage tr<74>s
|
|||
|
|
correctement la bande passante, m<>me quand le bus est charg<72>. Il a
|
|||
|
|
l'avantage d'<27>tre tr<74>s d<>centralis<69> : aucune station n'a besoin de
|
|||
|
|
savoir qui, au juste, est pr<70>sent sur le bus, et une station <20>teinte
|
|||
|
|
n'emp<6D>che pas la communication. Son d<>faut principal est l'absence de
|
|||
|
|
garantie de d<>bit, chaque station se contentant de faire au mieux, au
|
|||
|
|
lieu de faire bien.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
L'ethernet se pratiquait sur des c<>bles coaxiaux (fa<66>on c<>ble
|
|||
|
|
d'antenne de t<>l<EFBFBD>vision), passant par toutes les stations et termin<69>s
|
|||
|
|
aux deux bouts par des r<>sistances, avec une longueur maximale de 185
|
|||
|
|
m<EFBFBD>tres (ou 550 m<>tres si on emploie du gros c<>ble blind<6E>,
|
|||
|
|
traditionnellement jaune). Cette m<>thode a l'inconv<6E>nient
|
|||
|
|
d'occasionner une coupure du c<>ble quand on rajoute une nouvelle
|
|||
|
|
prise; et il n'est pas toujours facile de faire passer le m<>me c<>ble
|
|||
|
|
par toutes les stations, suivant leur disposition.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Maintenant, on <20>tablit des structures arborescentes : chaque station
|
|||
|
|
est reli<6C>e, par un c<>ble personnel, <20> un hub, une sorte de multiprise
|
|||
|
|
amplifi<EFBFBD>e. Les hubs sont reli<6C>s entre eux via des c<>bles similaires<65>;
|
|||
|
|
chaque hub reproduit sur toutes les autres prises ce qu'il re<72>oit sur
|
|||
|
|
chacune d'elles. On peut brancher une nouvelle machine sans perturber
|
|||
|
|
le fonctionnement, et on peut plus facilement relier des machines
|
|||
|
|
distantes.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p class="centre"><img
|
|||
|
|
src="&url.tuteurs;docs/hublot/hublot04/reseau2.png" alt="[Sch<63>ma]" />
|
|||
|
|
Figure 3 : R<>seau ethernet arborescent (RJ45)</p>
|
|||
|
|
|
|||
|
|
<h2>Internet dans tout <20>a</h2>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
On a vu, dans la section pr<70>c<EFBFBD>dente, comment relier ensemble deux
|
|||
|
|
stations pour qu'elles puissent s'<27>changer des donn<6E>es, pas forc<72>ment
|
|||
|
|
de fa<66>on fiable, et sans garantie de d<>bit. Ces m<>thodes sont locales,
|
|||
|
|
et il convenait de passer <20> un r<>seau global. Ceci a <20>t<EFBFBD> effectu<74>
|
|||
|
|
gr<EFBFBD>ce au r<>seau Internet, d<>riv<69> de l'Arpanet au cours des ann<6E>es 1970
|
|||
|
|
(Arpanet <20>tait le r<>seau des militaires am<61>ricains).
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Le principe est le suivant : quand une station veut envoyer un message
|
|||
|
|
<EFBFBD> une consoeur, elle commence par examiner ses branchements, pour voir
|
|||
|
|
si la destinatrice ne serait pas, par hasard, accessible
|
|||
|
|
directement. Dans ce cas, elle lui envoie le message par le moyen
|
|||
|
|
physique pr<70>sent. Dans le cas contraire, elle envoie le message <20> une
|
|||
|
|
station dont elle sait qu'elle est plus qualifi<66>e qu'elle pour
|
|||
|
|
r<EFBFBD>soudre ce probl<62>me. La station qualifi<66>e est nomm<6D>e routeur, ou
|
|||
|
|
aussi passerelle.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Pour savoir qui est contactable et comment, chaque station est munie
|
|||
|
|
d'une adresse de 4 octets (chaque octet contenant un nombre entre 0 et
|
|||
|
|
255). Ainsi, la station galion, en salle S, est dot<6F>e de l'adresse
|
|||
|
|
<code>129.199.129.10</code>. Ces adresses sont mondiales, et toutes
|
|||
|
|
les adresses commen<65>ant par <code>129.199</code> sont r<>serv<72>es <20>
|
|||
|
|
l'ENS.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<h3>Un exemple <20> l'<27>cole</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Prenons l'exemple de galion, tentant d'envoyer un message (sous la
|
|||
|
|
forme d'un paquet IP, comme Internet Protocol) <20> aviso, en
|
|||
|
|
Infirmatique.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
galion, d'adresse <code>129.199.129.10</code>, sait qu'elle est reli<6C>e
|
|||
|
|
directement <20> toutes les stations dont l'adresse commence par
|
|||
|
|
<code>129.199.129</code>. Or, aviso a l'adresse
|
|||
|
|
<code>129.199.128.1</code><3E>; galion, constatant cela, d<>cide de
|
|||
|
|
transmettre le paquet <20> sa passerelle, <20> savoir clipper
|
|||
|
|
(<code>129.199.129.1</code>, contactable par un lien ethernet direct
|
|||
|
|
depuis galion). Puis galion se lave les mains de ce qui se passe
|
|||
|
|
ensuite, ce n'est plus son affaire.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
clipper ne peut pas non plus contacter aviso directement, mais il peut
|
|||
|
|
parler sur un deuxi<78>me lien depuis son deuxi<78>me visage, clipper-gw
|
|||
|
|
(<code>129.199.1.22</code>). Sur ce lien, il peut contacter finn
|
|||
|
|
(<code>129.199.1.128</code>), qui est responsable des adresses en
|
|||
|
|
<code>129.199.128.</code> clipper transmet donc le paquet <20> finn, et
|
|||
|
|
se d<>sint<6E>resse lui aussi de la question.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
finn poss<73>de aussi deux visages, le second <20>tant finn128
|
|||
|
|
(<code>129.199.128.254</code>), reli<6C> directement aux stations de
|
|||
|
|
l'Infirmatique. finn peut donc communiquer directement avec aviso, et
|
|||
|
|
lui envoie le paquet.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<h3>Routeurs et r<>seau</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Donc, pour que tout se passe bien, il suffit que chaque station sache
|
|||
|
|
reconna<EFBFBD>tre les adresses contactables directement, et une passerelle
|
|||
|
|
pour les autres cas. Les routeurs, eux, doivent avoir une notion
|
|||
|
|
locale de la hi<68>rarchie (clipper doit conna<6E>tre finn, mais ce que finn
|
|||
|
|
doit faire pour contacter aviso ne le regarde pas).
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Il est m<>me possible de reconstruire ces informations <20> la vol<6F>e :
|
|||
|
|
clipper peut tout envoyer sur la machine par d<>faut (renater), qui lui
|
|||
|
|
signalera <20> chaque fois qu'il existe une route plus directe ne passant
|
|||
|
|
pas par lui; clipper s'en rappellera pendant quelques minutes. Ce
|
|||
|
|
m<EFBFBD>canisme, dit de routage dynamique, est un peu d<>licat <20> mettre en
|
|||
|
|
place, aussi on s'en sert avec parcimonie (il est ais<69> d'obtenir, <20> la
|
|||
|
|
suite d'un malentendu, une partie de ping-pong, o<> deux stations
|
|||
|
|
consid<EFBFBD>rent, pour un paquet donn<6E>, que l'autre station est la
|
|||
|
|
passerelle <20> utiliser).
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Et voil<69>, ceci est Internet : des stations qui s'<27>changent des paquets
|
|||
|
|
(d'une taille maximale de 65.536 octets, mais souvent plus petits, de
|
|||
|
|
l'ordre de 1.500 octets). Normalement, un paquet n'a pas <20> effectuer
|
|||
|
|
plus de 30 sauts pour faire le trajet d'une station <20> une autre. Les
|
|||
|
|
paquets peuvent <20>tre fractionn<6E>s et recombin<69>s au gr<67> des routeurs,
|
|||
|
|
afin de s'adapter aux sp<73>cificit<69>s locales de la liaison.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Le chemin entre deux stations n'est pas forc<72>ment unique<75>; ceci permet
|
|||
|
|
une tol<6F>rance aux pannes ou une adaptation aux
|
|||
|
|
embouteillages. Notamment, les communications <20> grande <20>chelle sont
|
|||
|
|
alors r<>sistantes aux attaques nucl<63>aires (c'est ce qui plaisait aux
|
|||
|
|
militaires am<61>ricains). Une cons<6E>quence de ce fait est que deux
|
|||
|
|
paquets successifs ne suivent pas forc<72>ment le m<>me chemin; ils
|
|||
|
|
peuvent notamment arriver dans le d<>sordre, et certains peuvent <20>tre
|
|||
|
|
dupliqu<EFBFBD>s (quand une passerelle cherche <20> savoir, via un protocole
|
|||
|
|
appropri<EFBFBD>, si un paquet est arriv<69>, et, ne voyant rien venir, en <20>met
|
|||
|
|
un autre, alors que le premier <20>tait simplement parti par un chemin
|
|||
|
|
d<EFBFBD>tourn<EFBFBD>).
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p class="centre"><img
|
|||
|
|
src="&url.tuteurs;docs/hublot/hublot05/reseau-ens.png" alt="[Une
|
|||
|
|
partie du routage <20> l'ENS]" /><br /> Figure 4 : Une partie du routage
|
|||
|
|
<EFBFBD> l'ENS</p>
|
|||
|
|
|
|||
|
|
<h2>Le plombier et le facteur</h2>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Nous voil<69> en position d'envoyer des paquets <20> travers le monde. Mais
|
|||
|
|
avec une fiabilit<69> douteuse. On a principalement deux probl<62>mes :
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<ul>
|
|||
|
|
<li> On voudrait qu'une m<>me station puisse tenir plusieurs
|
|||
|
|
conversations <20> la fois, sur des sujets diff<66>rents. On a donc
|
|||
|
|
invent<6E> des sous-adresses, des bo<62>tes aux lettres diff<66>renci<63>es,
|
|||
|
|
qu'on appelle les ports. Un port est un num<75>ro entre 0 et 65 535;
|
|||
|
|
la plupart des services ont un port canonique (25 pour le courrier
|
|||
|
|
<20>lectronique, 80 pour le Web, etc)<29>;</li>
|
|||
|
|
<li> On voudrait un protocole permettant d'assurer l'int<6E>grit<69> des
|
|||
|
|
donn<6E>es (remise dans l'ordre, accus<75>s de r<>ception et r<>-<2D>mission
|
|||
|
|
des paquets perdus, contr<74>le de flux), si possible int<6E>gr<67> dans le
|
|||
|
|
syst<73>me d'exploitation, pour que les applications puissent s'en
|
|||
|
|
servir sans se prendre la t<>te.</li>
|
|||
|
|
</ul>
|
|||
|
|
|
|||
|
|
<p>Deux protocoles ont donc <20>t<EFBFBD> cr<63><72>s (un protocole est aux donn<6E>es ce
|
|||
|
|
que le langage est <20> une conversation<6F>: c'est le <20><>r<EFBFBD>glement<6E><74>). Le
|
|||
|
|
premier, <strong>UDP</strong> (<i lang="en">User Datagram
|
|||
|
|
Protocol</i>) est une surcouche triviale (couche suppl<70>mentaire
|
|||
|
|
reproduisant la structure sous-jacente) d'IP<49>: on envoie des paquets,
|
|||
|
|
sans garantie, d'une taille maximale de 8 192 octets (pour les
|
|||
|
|
donn<EFBFBD>es; il y a aussi un ent<6E>te donnant entre autres l'adresse et le
|
|||
|
|
port de destination).
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
<strong>TCP</strong> (<i lang="en">Transmission Control Protocol</i>)
|
|||
|
|
est une m<>canique complexe qui assure une s<>mantique de connexion: un
|
|||
|
|
tuyau bidirectionnel, fiable, au flux contr<74>l<EFBFBD> afin de ne pas
|
|||
|
|
provoquer d'embouteillage, est <20>tabli entre deux stations, sur un
|
|||
|
|
certain port.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
TCP est le plus utilis<69>. UDP est utilis<69> pour certains protocoles o<>
|
|||
|
|
l'ordre d'arriv<69>e des donn<6E>es n'est pas important, ou quand les
|
|||
|
|
donn<EFBFBD>es sont rapidement obsol<6F>tes. Par exemple, dans le cas de NFS
|
|||
|
|
(partage de disques par r<>seau), l'ordre des requ<71>tes n'est pas
|
|||
|
|
primordial; quand on fait du t<>l<EFBFBD>phone par Internet, si un paquet se
|
|||
|
|
perd, autant l'oublier: sa doublure arriverait trop tard pour
|
|||
|
|
s'int<6E>grer dans le flux sonore.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<h3>Les applications</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
La face visible d'Internet est form<72>e par les applications. Nous
|
|||
|
|
allons en d<>tailler quelques unes.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<h4>DNS (<i lang="en">Domain Name Server</i>)</h4>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Cette application est charg<72>e de faire la correspondance entre les
|
|||
|
|
adresses num<75>riques, et les noms de stations, noms qui sont destin<69>s
|
|||
|
|
aux humains. Ainsi, c'est le syst<73>me des DNS qui permet <20> toute
|
|||
|
|
station dans le monde de savoir que <code>clipper.ens.fr</code> r<>pond
|
|||
|
|
<EFBFBD> l'adresse <code>129.199.129.1</code>. Chaque site doit disposer d'un
|
|||
|
|
DNS, connaissant les machines locales, et pouvant interroger les
|
|||
|
|
autres DNS. Les DNS communiquent par paquets UDP sur le port 53.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<h4>SMTP (<i lang="en">Simple Mail Transfer Protocol</i>)</h4>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Par connexion TCP sur le port 25, ce protocole permet d'<27>changer des
|
|||
|
|
courriers <20>lectroniques. De fa<66>on similaire au transport des paquets
|
|||
|
|
IP, un courrier peut effectuer quelques sauts (<28> chaque fois sous la
|
|||
|
|
forme d'une connexion TCP) entre serveurs de mails avant d'arriver <20>
|
|||
|
|
destination. Par exemple, <20> l'ENS, tout courrier sortant passe par
|
|||
|
|
<code>nef.ens.fr</code>.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<h4>FTP (<i lang="en">File Transfer Protocol</i>)</h4>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Ce protocole de transfert de fichiers utilise deux connexions TCP, sur
|
|||
|
|
les ports 20 et 21 (celle sur le port 20 sert aux donn<6E>es, celle sur
|
|||
|
|
le port 21 transporte les commandes).
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<h4>NFS (<i lang="en">Network File System</i>)</h4>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Cr<EFBFBD><EFBFBD> par Sun Microsystems, ce protocole de partage de disques permet,
|
|||
|
|
<EFBFBD> l'ENS, de pouvoir manipuler ses fichiers quelle que soit la station
|
|||
|
|
qu'on utilise. Alors qu'il est souvent d<>cri<72>, ses versions modernes
|
|||
|
|
sont fort acceptables, pourvu que le r<>seau sous-jacent soit
|
|||
|
|
rapide. Il utilise des paquets UDP, sur le port 2049.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<h4>HTTP (<i lang="en">HyperText Transfer Protocol</i>)</h4>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
C'est le coeur du World Wide Web, qui n'est qu'une application
|
|||
|
|
d'Internet, r<>cente de surcro<72>t (1990). Par connexion TCP sur le port
|
|||
|
|
80 du serveur Web, le client obtient le contenu d'une page
|
|||
|
|
(normalement en langage HTML) et divers autres types de fichiers
|
|||
|
|
(notamment les images). Une adresse Web (URL) commence par le mot-cl<63>
|
|||
|
|
http, indiquant le protocole utilis<69>, puis contient le nom du serveur
|
|||
|
|
Web, puis enfin le nom du fichier (avec <20>ventuellement des r<>pertoires
|
|||
|
|
et des sous-r<>pertoires) sur ce serveur.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p class="centre"><img
|
|||
|
|
src="&url.tuteurs;docs/hublot/hublot06/reseau.png"
|
|||
|
|
alt="[Fonctionnement du Web]" /><br /> Figure 5 : Consultation de
|
|||
|
|
<code>http://www.ens.fr/index.html</code></p>
|
|||
|
|
|
|||
|
|
<h2>Intervention divine</h2>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Bizarrement, tout cet <20>difice aux proportions bibliques fonctionne la
|
|||
|
|
plupart du temps. N<>anmoins, quand une rupture g<>n<EFBFBD>rale de la Force
|
|||
|
|
arrive, on peut se retrouver avec beaucoup de probl<62>mes, tous
|
|||
|
|
diff<EFBFBD>rents. Voici quelques sp<73>cimens:
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<h3>Ping-pong</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Deux routeurs se renvoient des paquets, chacun ayant d<>cid<69> que Le Bon
|
|||
|
|
Chemin passe par l'autre. Cela se diagnostique avec la commande Unix
|
|||
|
|
<code>traceroute</code>. Solution<6F>: maudire <a
|
|||
|
|
href="http://www.renater.fr/">Renater</a> (le fournisseur d'acc<63>s
|
|||
|
|
Internet de l'ENS, grand sp<73>cialiste du tennis de table) et attendre
|
|||
|
|
que les routeurs oublient d'<27>tre stupides.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<h3>Panne des DNS</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Les DNS forment une structure hi<68>rarchique qui a tendance <20> s'<27>crouler
|
|||
|
|
d'un coup. Dans ces conditions, tout semble fig<69>, sauf si on utilise
|
|||
|
|
directement les adresses num<75>riques; mais il est difficile de retenir
|
|||
|
|
par coeur 4 milliards d'adresses... Le diagnostic<69>: la commande
|
|||
|
|
<code>host</code> sur un h<>te connu (<code>www.google.com</code> par
|
|||
|
|
exemple) bloque et ne r<>pond pas.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<h3>Plantage du serveur NFS</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Votre station est bloqu<71>e, des messages <20><><i lang="en">NFS server not
|
|||
|
|
responding, still trying</i><3E><> apparaissent. C'est typique du serveur
|
|||
|
|
NFS (celui qui poss<73>de, physiquement, les disques partag<61>s) qui a pris
|
|||
|
|
des vacances. Il faut attendre le reboot du serveur. NFS <20>tant bien
|
|||
|
|
fait, cela d<>bloquera les machines sans cons<6E>quence funeste pour les
|
|||
|
|
op<EFBFBD>rations en cours.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<h3>Plantage du serveur NIS</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
NIS, alias les Pages Jaunes, est le protocole permettant de partager
|
|||
|
|
les mots de passe entre les stations. Pour l'utilisateur final, les
|
|||
|
|
cons<EFBFBD>quences sont semblables <20> un plantage NFS<46>: il faut attendre le
|
|||
|
|
retour du serveur NIS. Une fois qu'il est revenu, tout remarche, rien
|
|||
|
|
n'a <20>t<EFBFBD> perdu.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<h3>Embouteillage</h3>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Une partie du r<>seau est <20> genoux. La plupart des paquets s'<27>garent,
|
|||
|
|
tout va lentement, c'est horrible. Pas de solution, sinon esp<73>rer que
|
|||
|
|
de nouvelles lignes seront bient<6E>t mises en place, pester contre ces
|
|||
|
|
milliers de cr<63>tins qui ne pensent qu'<27> r<>cup<75>rer les derni<6E>res photos
|
|||
|
|
de Pamela Anderson, et revenir se connecter <20> une heure plus adapt<70>e
|
|||
|
|
(pour les <20>tats-Unis, la bonne heure est 6 heures du matin<69>: les
|
|||
|
|
Am<EFBFBD>ricains sont couch<63>s, les Europ<6F>ens pas encore lev<65>s).
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Il existe beaucoup d'autres pannes possibles, plus <20>sot<6F>riques. Elles
|
|||
|
|
sont la cause de certaines de ces discussions d'informaticiens que
|
|||
|
|
personne ne comprend, mais qui semblent les amuser follement.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<h2>En savoir plus</h2>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Le cours d'Architecture et Syst<73>mes comprend une partie anim<69>e par
|
|||
|
|
Jacques Beigbeder, qui d<>crit, entre autres, le fonctionnement du
|
|||
|
|
r<EFBFBD>seau.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Les gens motiv<69>s se r<>f<EFBFBD>reront aux RFC (<i lang="en">Request For
|
|||
|
|
Comments</i>). Ce sont les documents de r<>f<EFBFBD>rence<63>; on les trouve l<><6C>:
|
|||
|
|
<a href="ftp://ftp.inria.fr/rfc/">ftp://ftp.inria.fr/rfc/</a>
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<p>
|
|||
|
|
Le protocole IP est d<>crit dans la <a
|
|||
|
|
href="http://www.faqs.org/rfcs/rfc791.html">RFC 791</a>.
|
|||
|
|
</p>
|
|||
|
|
|
|||
|
|
<div class="metainformation">Auteur : Thomas Pornin. Derni<6E>re
|
|||
|
|
modification : le <date value="$Date: 2003-07-08 10:27:53 $" />.</div>
|
|||
|
|
|
|||
|
|
</body>
|
|||
|
|
</html>
|