2004-04-12 19:58:01 +02:00
|
|
|
|
<?xml version="1.0" encoding="ISO-8859-1"?>
|
|
|
|
|
|
<!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<EFBFBD> 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<EFBFBD>l<EFBFBD>graphe, avec le code Morse. Et <20>a s'adapte vraiment parfaitement aux
|
2007-07-13 10:40:16 +02:00
|
|
|
|
ordinateurs. Les ordinateurs peuvent m<>me faire mieux : ils ont des
|
2004-04-12 19:58:01 +02:00
|
|
|
|
m<EFBFBD>tronomes (dans le domaine informatique on parle d'horloges) qui battent
|
2007-07-13 10:40:16 +02:00
|
|
|
|
tr<EFBFBD>s pr<70>cis<69>ment la mesure ; <20> chaque tic, ils peuvent envoyer ou pas le
|
2004-04-12 19:58:01 +02:00
|
|
|
|
courant, <20>a fait un bit d'information <20> chaque fois.
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
2007-07-13 10:40:16 +02:00
|
|
|
|
Nous ne rentrerons pas dans les d<>tails de la r<>alisatoin physique : <20>a
|
2004-04-12 19:58:01 +02:00
|
|
|
|
peut aller d'une b<>te paire de fils sur <20> peine plus d'un m<>tre <20> un
|
|
|
|
|
|
faisceau de fibres optiques, en passant par un c<>ble coaxial. <20>a peut
|
|
|
|
|
|
<EFBFBD>galement <20>tre des ondes radio, ou bien le fait de dire ou de ne pas dire
|
|
|
|
|
|
bip sur une ligne t<>l<EFBFBD>phonique. Bref, il y a plein de mani<6E>res pour deux
|
|
|
|
|
|
ordinateurs de se dire 0 ou 1.
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
|
<EFBFBD>a, c'est bien pour relier deux ordinateurs. Mais comment faire s'il y en a
|
2007-07-13 10:40:16 +02:00
|
|
|
|
plusieurs ? Tirer un c<>ble entre chaque paire n'est pas envisageable. La
|
2004-04-12 19:58:01 +02:00
|
|
|
|
solution la moins co<63>teuse, et donc celle qui a <20>t<EFBFBD> rapidement pr<70>f<EFBFBD>r<EFBFBD>e, est
|
|
|
|
|
|
d'utiliser un seul c<>ble qui connecte tous les ordinateurs. Quand un
|
|
|
|
|
|
ordinateur veut parler, il parle <20> tous les autres, et il faut inventer des
|
|
|
|
|
|
moyens pour que deux ne parlent pas en m<>me temps. Le syst<73>me de ce genre le
|
|
|
|
|
|
plus r<>pandu consiste en un c<>ble coaxial o<> tous les ordinateurs sont
|
2007-07-13 10:40:16 +02:00
|
|
|
|
branch<EFBFBD>s en s<>ri<72> ; plus r<>cemment on a adopt<70> une structure en <20>toile
|
2004-04-12 19:58:01 +02:00
|
|
|
|
autour d'un appareil bon march<63> appel<65> 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 <20> un faisceau de fibres optiques transatlantique. La solution
|
|
|
|
|
|
consiste alors <20> avoir une machine branch<63>e sur les deux (ou plus) r<>seaux,
|
2007-07-13 10:40:16 +02:00
|
|
|
|
avec pour t<>che de faire suivre l'information de l'un <20> l'autre ; quand un
|
2004-04-12 19:58:01 +02:00
|
|
|
|
ordinateur d'un r<>seau veut parler <20> un ordinateur de l'autre r<>seau, il
|
|
|
|
|
|
adresse son message <20> cette machine, avec une <20>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<6F>e est <dfn>ethernet</dfn>. Elle fonctionne
|
|
|
|
|
|
soit avec un c<>ble coaxial en s<>rie, soit avec un c<>ble simple (<28> huit fils
|
|
|
|
|
|
dont peu sont vraiment utilis<69>s) organis<69> en <20>toile autour d'un hub. Avec
|
|
|
|
|
|
ethernet, les donn<6E>es sont envoy<6F>es par blocs appel<65>s trames qui font au
|
2007-07-13 10:40:16 +02:00
|
|
|
|
plus environ 1,5 ko. Il n'y a pas de syst<73>me pour s'assurer <i>a priori</i>
|
|
|
|
|
|
que deux ordinateurs sur le c<>ble ne parlent pas en m<>me temps : la
|
2004-04-12 19:58:01 +02:00
|
|
|
|
d<EFBFBD>tection se fait <i>a posteriori</i> par le fait que le signal est alors
|
2007-07-13 10:40:16 +02:00
|
|
|
|
incompr<EFBFBD>hensible ; les deux ordinateurs r<><72>mettent alors apr<70>s un d<>lai
|
|
|
|
|
|
al<EFBFBD>atoire, qui sera probablement diff<66>rent ; en pratique, ce syst<73>me marche
|
2004-04-12 19:58:01 +02:00
|
|
|
|
plut<EFBFBD>t bien.
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
|
Au d<>but de chaque trame ethernet, ou trouve ce qu'on appelle un
|
2007-07-13 10:40:16 +02:00
|
|
|
|
<dfn>ent<6E>te</dfn> : quelques octets r<>serv<72>s par le protocole ethernet
|
2004-04-12 19:58:01 +02:00
|
|
|
|
lui-m<>me pour son fonctionnement interne. Toutes les cartes r<>seau ethernet
|
|
|
|
|
|
poss<EFBFBD>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<6E>te ethernet, on trouve l'adresse
|
|
|
|
|
|
MAC de l'ordinateur auquel la trame est adress<73>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<EFBFBD>ble, seul celui qui est concern<72> voit effectivement un message.
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
|
Dans l'ent<6E>te ethernet, on trouve <20>galement un num<75>ro de protocole. C'est un
|
|
|
|
|
|
petit nombre, sur deux octets, qui d<>crit tr<74>s bri<72>vement ce qu'on pr<70>voit
|
|
|
|
|
|
de faire avec les donn<6E>es de la trame.
|
|
|
|
|
|
L'<abbr lang="en" title="Internet Assigned Numbers Authority">IANA</abbr>
|
|
|
|
|
|
tient <20> jour une
|
|
|
|
|
|
<a href="http://www.iana.org/assignments/ethernet-numbers">table des num<75>ros
|
|
|
|
|
|
ethernet</a> attribu<62>s. Ainsi, le syst<73>me d'exploitation de l'ordinateur qui
|
|
|
|
|
|
a re<72>u la trame peut imm<6D>diatement appeler le bon sous-syst<73>me, ou ignorer
|
|
|
|
|
|
la trame s'il ne sait pas quoi en faire. Pour illustrer, quand on utilise
|
2007-07-13 10:40:16 +02:00
|
|
|
|
ethernet pour faire passer de l'<27> Internet <3B>, le num<75>ro est 513. Ce
|
2004-04-12 19:58:01 +02:00
|
|
|
|
m<EFBFBD>canisme de num<75>ros d<>crivant le genre d'utilisation d'un syst<73>me est tr<74>s
|
|
|
|
|
|
g<EFBFBD>n<EFBFBD>ral, et on le retrouve <20> tous les niveaux des protocoles Internet.
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
|
Quand on utilise une ligne t<>l<EFBFBD>phonique, le protocole employ<6F> est le
|
|
|
|
|
|
<span lang="en">Point to Point</span> (PPP). Il a des m<>canismes diff<66>rents
|
|
|
|
|
|
parce qu'il ne relie que deux ordinateurs, mais sous des contraintes
|
|
|
|
|
|
diff<EFBFBD>rentes (ligne moins fiable et temps de latence sup<75>rieur).
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<h2>Relier les r<>seaux</h2>
|
|
|
|
|
|
|
|
|
|
|
|
<h3>Le routage</h3>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
|
Mettez une lettre <20> la poste. Si le destinataire habite dans la m<>me ville,
|
|
|
|
|
|
elle lui sera distribu<62>e directement. S'il habite dans une ville voisine, le
|
|
|
|
|
|
facteur transmet la lettre <20> son coll<6C>gue de cette ville. S'il habite plus
|
|
|
|
|
|
loin, le facteur transmettra la lettre au centre de tri dont il d<>pend. Et <20>
|
|
|
|
|
|
son tour, le centre de tri va faire suivre la lettre <20> qui de droit. La
|
|
|
|
|
|
lettre va donc passer par diff<66>rentes <20>tapes o<> elle sera redirig<69>e en
|
|
|
|
|
|
fonction de l'adresse qui est <20>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
|
2007-07-13 10:40:16 +02:00
|
|
|
|
mani<EFBFBD>re : les donn<6E>es sont d<>coup<75>es en <dfn>paquets</dfn>, qui jouent le
|
2004-04-12 19:58:01 +02:00
|
|
|
|
r<EFBFBD>le de notre enveloppe. Quand il n'est pas possible de transmettre le
|
|
|
|
|
|
paquet directement <20> son destinataire, il est transmis <20> un ordinateur
|
|
|
|
|
|
(d<>fini dans la configuration du r<>seau) appel<65> <dfn>routeur</dfn>. Cet
|
2007-07-13 10:40:16 +02:00
|
|
|
|
ordinateur est cens<6E> <20>tre capable de faire suivre le paquet ; <20>a suppose par
|
2004-04-12 19:58:01 +02:00
|
|
|
|
exemple qu'il est reli<6C> par un autre c<>ble <20> un autre r<>seau.
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
|
Pour pouvoir marcher, ce syst<73>me a besoin que les ordinateurs soient dot<6F>s
|
|
|
|
|
|
d'une adresse qui refl<66>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 <20> 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 <20>a fonctionne avec
|
|
|
|
|
|
diff<EFBFBD>rents types de connexion (les modems pour les connexions PPP, par
|
|
|
|
|
|
exemple, n'ont pas d'adresse MAC). On invente alors un nouveau syst<73>me
|
|
|
|
|
|
d'adresses, ind<6E>pendant du protocole utilis<69> 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<70>onasme). Ce protocole d<>crit la structure
|
|
|
|
|
|
des adresses utilis<69>e, la mani<6E>re d'<27>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<74>es de 32 chiffres
|
|
|
|
|
|
binaires (bits), ce qu'on <20>crit g<>n<EFBFBD>ralement sous la forme de quatre nombres
|
|
|
|
|
|
entre 0 et 255. Par exemple, l'adresse IP de clipper est 129.199.129.1. Une
|
2007-07-13 10:40:16 +02:00
|
|
|
|
nouvelle version d'IP, IPv6, est progressivement mis en place ; les adresses
|
|
|
|
|
|
y font 128 bits, et sont <20>crites en hexad<61>cimal ; l'ENS n'est pas reli<6C>e en
|
2004-04-12 19:58:01 +02:00
|
|
|
|
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<6C> <20> Internet poss<73>de (au moins) une adresse IP, et il
|
|
|
|
|
|
est le seul <20> la poss<73>der (dans Internet). Ces adresses sont structur<75>es en
|
|
|
|
|
|
r<EFBFBD>seaux et sous-r<>seaux, en fixant les chiffres de gauche <20> droite. Ainsi,
|
|
|
|
|
|
toutes les adresses en 129.199.x.y sont dans l'ENS, et celles en
|
|
|
|
|
|
129.199.129.y sont plus particuli<6C>rement dans la salle S. De l'ext<78>rieur,
|
|
|
|
|
|
quelqu'un qui veut envoyer un paquet <20> 129.199.129.1 a seulement <20> savoir
|
|
|
|
|
|
qu'il doit l'envoyer <20> l'ENS. C'est ensuite <20> nos routeurs de finir le
|
|
|
|
|
|
travail.
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
|
Les paquets IP comportent tous l'adresse IP de l'exp<78>diteur, celle du
|
|
|
|
|
|
destinataire, une somme de contr<74>le qui permet de v<>rifier qu'il est intact,
|
|
|
|
|
|
et un num<75>ro de protocole indiquant <20> quoi va servir ce paquet. Ils
|
|
|
|
|
|
comportent <20>galement un compteur qui limite le nombre de routeurs par lequel
|
|
|
|
|
|
il peut passer (de mani<6E>re <20> ce qu'un paquet perdu ne reste pas <20>ternellement
|
|
|
|
|
|
<EFBFBD> circuler entre des routeurs mal configur<75>s), ainsi que quelques autres
|
|
|
|
|
|
options. Un des principes d'Internet, c'est que les routeurs font le strict
|
2007-07-13 10:40:16 +02:00
|
|
|
|
minimum : ils doivent se contenter de faire suivre les paquets sans les
|
|
|
|
|
|
alt<EFBFBD>rer (sauf le compteur ; si un paquet a atteint la limite, le routeur
|
2004-04-12 19:58:01 +02:00
|
|
|
|
l'arr<72>te et envoit un paquet <20> l'exp<78>diteur pour signaler l'erreur). Un des
|
2007-07-13 10:40:16 +02:00
|
|
|
|
autres principes est que tous les ordinateurs sont <20>gaux : du point de vue
|
2004-04-12 19:58:01 +02:00
|
|
|
|
du protocole, rien ne distingue le super ordinateur central de la NASA de
|
2007-07-13 10:40:16 +02:00
|
|
|
|
votre petit PC personnel ; en particulier, rien ne distingue un serveur d'un
|
2004-04-12 19:58:01 +02:00
|
|
|
|
poste client.
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
|
IP est con<6F>u sur un principe de <span lang="en">best effort</span> (meilleur
|
2007-07-13 10:40:16 +02:00
|
|
|
|
effort) : les infrastructures (les routeurs) font leur possible pour faire
|
2004-04-12 19:58:01 +02:00
|
|
|
|
parvenir vos paquets, mais sans aucune garantie. Un paquet peut dispara<72>tre
|
|
|
|
|
|
sans laisser de trace, ou bien se perdre au mauvais endroit (mais il n'ira
|
|
|
|
|
|
en g<>n<EFBFBD>ral pas bien loin), ou encore <20>tre retard<72> et arriver apr<70>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<EFBFBD>ral</em>, les paquets arrivent bien, et
|
|
|
|
|
|
dans l'ordre. Ce principe du meilleur effort a l'avantage d'<27>tre simple et
|
2007-07-13 10:40:16 +02:00
|
|
|
|
l<EFBFBD>ger ; il est ensuite possible de concevoir un syst<73>me d'accus<75>s de
|
2004-04-12 19:58:01 +02:00
|
|
|
|
r<EFBFBD>ception et de num<75>ros d'ordre pour assurer la fiabilit<69> 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-<2D>tre) <20> n'importe quel ordinateur dans le monde, mais vous,
|
|
|
|
|
|
ce qui vous int<6E>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
|
2007-07-13 10:40:16 +02:00
|
|
|
|
courrier <20>lectronique ne sont pas toujours dans le m<>me logiciel : il faut
|
2004-04-12 19:58:01 +02:00
|
|
|
|
donc que plusieurs applications puissent se partager le r<>seau, et que l'une
|
|
|
|
|
|
n'aille pas recevoir les donn<6E>es de l'autre.
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
|
Quand on programme une application r<>seau, on amierait en g<>n<EFBFBD>ral avoir une
|
2007-07-13 10:40:16 +02:00
|
|
|
|
sorte de tuyau : tout ce qu'on dit d'un c<>t<EFBFBD>, l'application <20> l'autre bout
|
2004-04-12 19:58:01 +02:00
|
|
|
|
le re<72>oit, dans l'ordre, sans perte, et une seule fois, et inversement, on
|
|
|
|
|
|
re<EFBFBD>oit tout ce qu'elle dit. Si les ordinateurs aux deux bouts sont d'accord,
|
2007-07-13 10:40:16 +02:00
|
|
|
|
un tel tuyau peut <20>tre simul<75> : on d<>coupe ce qui doit passer dans le tuyau
|
2004-04-12 19:58:01 +02:00
|
|
|
|
en morceaux assez petits pour tenir dans des paquets, et on les exp<78>die avec
|
2007-07-13 10:40:16 +02:00
|
|
|
|
un num<75>ro d'ordre ; <20> l'autre bout, l'ordinateur r<>pond par un paquet
|
2004-04-12 19:58:01 +02:00
|
|
|
|
accusant la r<>ception, et utilise les num<75>ros pour remettre de l'ordre. Si
|
|
|
|
|
|
on constate qu'un accus<75> de r<>ception tarde, on r<>exp<78>die le paquet
|
|
|
|
|
|
incrimin<EFBFBD>, au pire il arrivera en double et ce n'est pas grave.
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
|
Tant qu'on en est <20> rajouter des num<75>ros aux paquets, on peut ajouter encore
|
|
|
|
|
|
quelques informations. Par exemple l'identit<69> du programme qui l'a envoy<6F>,
|
|
|
|
|
|
ou l'identit<69> du programme qui doit le recevoir. Avec tout <20>a, on peut
|
2007-07-13 10:40:16 +02:00
|
|
|
|
concevoir des <dfn>connexions</dfn> r<>seau : un tuyau virtuel entre un
|
2004-04-12 19:58:01 +02:00
|
|
|
|
ordinateur et un autre, avec une extr<74>mit<69> qui envoit des paquets, attend
|
|
|
|
|
|
des accus<75>s de r<>ception, et r<>exp<78>die les paquets qui se perdent, et
|
|
|
|
|
|
l'autre extr<74>mit<69> qui re<72>oit les paquets et les remet dans l'ordre. Quand un
|
|
|
|
|
|
paquet arrive sur un ordinateur, le syst<73>me r<>seau consulte son contenu pour
|
|
|
|
|
|
voir ses r<>f<EFBFBD>rences, et trouve dans ses tables <20> quelle connexion il
|
|
|
|
|
|
appartient.
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
|
Tout ceci est normalement fait par le syst<73>me d'exploitation des
|
|
|
|
|
|
ordinateurs, et cach<63> aux programmes. Les programmes, eux, se contentent de
|
|
|
|
|
|
r<EFBFBD>clamer une connexion, et ensuite d'utiliser le tuyau. Les donn<6E>es passent,
|
|
|
|
|
|
ils n'ont pas <20> se soucier de toute la machinerie interne.
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<h3>Le protocole TCP</h3>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
|
Sur internet, le protocole qui sert <20> <20>tablir des connexions est
|
|
|
|
|
|
<abbr lang="en" title="Transmission Control Protocol">TCP</abbr>. Pour
|
|
|
|
|
|
distinguer les connexions, TCP utilise un <dfn>num<75>ro de port</dfn>, un
|
|
|
|
|
|
petit nombre (entre 1 et 65535), qu'on peut voir un peu comme le casier d'un
|
2007-07-13 10:40:16 +02:00
|
|
|
|
<EFBFBD>l<EFBFBD>ve, alors que l'adresse IP correspond <20> <20> 45 rue d'Ulm <3B>. Une connexion est
|
|
|
|
|
|
identifi<EFBFBD>e par quatre donn<6E>es :
|
2004-04-12 19:58:01 +02:00
|
|
|
|
</p>
|
|
|
|
|
|
<ul>
|
2007-07-13 10:40:16 +02:00
|
|
|
|
<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<69>e ;</li>
|
2004-04-12 19:58:01 +02:00
|
|
|
|
<li>le port sur cet ordinateur</li>
|
|
|
|
|
|
</ul>
|
|
|
|
|
|
<p>
|
|
|
|
|
|
Chaque paquet <20>chang<6E> dans le cadre d'une connexion rappelle ces quatre
|
|
|
|
|
|
r<EFBFBD>f<EFBFBD>rences. On peut remarquer que sur un ordinateur donn<6E>, le m<>me port peut
|
|
|
|
|
|
participer <20> plusieurs connexions. De fait, <20>a arrive assez souvent, mais
|
|
|
|
|
|
jamais aux deux extr<74>mit<69>s <20> la fois (m<>me si rien ne l'interdit
|
|
|
|
|
|
fondamentalement).
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
2007-07-13 10:40:16 +02:00
|
|
|
|
Les connexions TCP sont toujours doubles : dans un sens et dans l'autre
|
2004-04-12 19:58:01 +02:00
|
|
|
|
entre les m<>mes extr<74>mit<69>s.
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
|
Du point de vue du programme, une connexion est un objet sur lequel on peut
|
|
|
|
|
|
lire et <20>crire des donn<6E>es. Sous Unix, <20>a se pr<70>sente presque de la m<>me
|
|
|
|
|
|
mani<EFBFBD>re qu'un fichier. Le syst<73>me d'exploitation sait <20> quel programme
|
2007-07-13 10:40:16 +02:00
|
|
|
|
chaque connexion active <20> appartient <3B>, et fait tout le n<>cessaire.
|
2004-04-12 19:58:01 +02:00
|
|
|
|
</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<74>mit<69> de la future connexion qui attend
|
|
|
|
|
|
s'appelle un <dfn>serveur</dfn> (eh oui, c'est le contraire du restaurant,
|
|
|
|
|
|
o<EFBFBD> le serveur vient <20> votre table prendre la commande), tandis que
|
|
|
|
|
|
l'extr<74>mit<69> qui fait le premier pas (qui envoit le premier paquet) s'appelle
|
|
|
|
|
|
le <dfn>client</dfn>. Apr<70>s l'<27>change de quelques paquets (trois, avec TCP)
|
|
|
|
|
|
pour v<>rifier qu'il y a bien un serveur au port demand<6E>, pour se mettre
|
|
|
|
|
|
d'accord sur la taille des paquet, etc., la connexion est <20>tabli<6C>.
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
|
Une fois que c'est fait, il n'y a du point de vue du r<>seau plus de
|
|
|
|
|
|
diff<EFBFBD>rence entre les deux extr<74>mit<69>s. Cependant, le dialogue entre les
|
2007-07-13 10:40:16 +02:00
|
|
|
|
programmes ne sera probablement pas sym<79>trique : une fois une connexion
|
2004-04-12 19:58:01 +02:00
|
|
|
|
<EFBFBD>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 <20> Google et non l'inverse. Il arrive n<>anmoins que
|
|
|
|
|
|
<EFBFBD>a finisse par <20>tre sym<79>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<74>mit<69>s se comprennent. Pour <20>a, elles
|
2007-07-13 10:40:16 +02:00
|
|
|
|
doivent encore une fois coder leurs donn<6E>es d'une certaine mani<6E>re : encore
|
2004-04-12 19:58:01 +02:00
|
|
|
|
un protocole. Cette mani<6E>re n'est d'ailleurs pas la m<>me s'il s'agit de web,
|
|
|
|
|
|
de mail, ou d'autres activit<69>s tout aussi passionnantes.
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
2007-07-13 10:40:16 +02:00
|
|
|
|
Les plus attentifs doivent se poser une question : il y a sur l'ordinateur
|
2004-04-12 19:58:01 +02:00
|
|
|
|
de Google (dont l'adresse IP est 216.239.59.99) 65535 ports diff<66>rents,
|
2007-07-13 10:40:16 +02:00
|
|
|
|
comment notre navigateur web a-t-il devin<69> le quel contacter ? La r<>ponse
|
|
|
|
|
|
est simple : le web, c'est sur le port 80. Pourquoi 80 ? C'est comme <20>a. Les
|
2004-04-12 19:58:01 +02:00
|
|
|
|
services importants ont des num<75>ros de port qui leur sont d<>di<64>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<EFBFBD>rant ne pas entrer en conflit avec un autre service, et comme c'est la
|
|
|
|
|
|
m<EFBFBD>me personne qui <20>crit les programme client et serveur c'est le m<>me qui
|
|
|
|
|
|
est utilis<69> des deux c<>t<EFBFBD>s.
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
|
Sous Unix, il faut des droits sp<73>ciaux pour cr<63>er un serveur sur un port en
|
|
|
|
|
|
dessous de 1024, ce qui permet d'<27>tre s<>r, quand on donne son mot de passe <20>
|
|
|
|
|
|
SSH (port 23) ou <20> IMAP (port 143), d'<27>tre bien en train de parler au
|
|
|
|
|
|
programme autoris<69>. Au dessus de 1024, c'est libre. Certains se rappellent
|
|
|
|
|
|
peut-<2D>tre que le serveur web des <20>l<EFBFBD>ves <20>tait
|
|
|
|
|
|
<code>http://www.eleves.ens.fr<strong>:8080</strong>/</code>. Ceci veut dire
|
|
|
|
|
|
qu'il <20>tait sur le port 8080 au lieu du 80 habituel, justepent parce qu'il
|
|
|
|
|
|
aurait fallu des droits suppl<70>mentaires pour avoir 80.
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
2007-07-13 10:40:16 +02:00
|
|
|
|
Pour le client, c'est en g<>n<EFBFBD>ral plus simple : le programme laisse le
|
2004-04-12 19:58:01 +02:00
|
|
|
|
syst<EFBFBD>me d'exploitation choisir un port inutilis<69>. 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<73>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
|
2007-07-13 10:40:16 +02:00
|
|
|
|
avec IPv6. Mais le probl<62>me n'est pas nouveau : on a le m<>me avec les
|
2004-04-12 19:58:01 +02:00
|
|
|
|
num<EFBFBD>ros de t<>l<EFBFBD>phone, et pour le r<>soudre on a invent<6E> 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>
|
|
|
|
|
|
<EFBFBD> l'<27>chelle d'un site, ou d'un fournisseur d'acc<63>s, il y a un (ou plusieurs)
|
|
|
|
|
|
ordinateur, que tous les autres connaissent par son adresse IP, et sur
|
|
|
|
|
|
lequel tourne un programme qui <20>coute sur le port 53 et qui se charge de
|
2007-07-13 10:40:16 +02:00
|
|
|
|
r<EFBFBD>pondre aux questions du genre <20> quelle est l'adresse IP de
|
|
|
|
|
|
<code>www.google.com</code> ? <3B>.
|
2004-04-12 19:58:01 +02:00
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
|
Ce programme n'a en g<>n<EFBFBD>ral pas la r<>ponse, mais il a l'adresse d'autres
|
|
|
|
|
|
ordinateurs <20> qui demander, qui eux-m<>mes peuvent ne pas savoir mais avoir
|
|
|
|
|
|
l'adresse d'autres ordinateurs, etc. Le syst<73>me est hi<68>rarchique. Il y a <20>
|
|
|
|
|
|
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<EFBFBD>s par des organismes fran<61>ais (enfin, pas tous),
|
|
|
|
|
|
qui savent <20> qui s'adresser pour chaque domaine. Et ainsi de suite.
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
|
Par exemple, pour conna<6E>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<EFBFBD>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<EFBFBD> par 129.199.96.11 (on
|
2007-07-13 10:40:16 +02:00
|
|
|
|
reconna<EFBFBD>t le 129.199 : c'est un ordinateur de l'ENS) et quelques autres.
|
2004-04-12 19:58:01 +02:00
|
|
|
|
Enfin, on interroge 129.199.96.11, et on obtient la r<>ponse, <20> savoir
|
|
|
|
|
|
129.199.129.1
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<p>
|
2007-07-13 10:40:16 +02:00
|
|
|
|
Bien s<>r, tous les programmes pour faire <20>a sont d<>j<EFBFBD> <20>crits : quand on
|
2004-04-12 19:58:01 +02:00
|
|
|
|
programme une nouvelle application r<>seau, il suffit d'utiliser la bonne
|
|
|
|
|
|
fonction de la biblioth<74>que standard.
|
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
<div class="metainformation">
|
2007-07-13 10:40:16 +02:00
|
|
|
|
Auteur : Nicolas George.
|
|
|
|
|
|
Derni<EFBFBD>re modification le <date value="$Date: 2007-07-13 08:41:17 $"/>.
|
2004-04-12 19:58:01 +02:00
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
</body>
|
|
|
|
|
|
</html>
|
