P. 1
Cours de réseaux (Maîtrise d'informatique Université d'Angers)

Cours de réseaux (Maîtrise d'informatique Université d'Angers)

4.4

|Views: 2,963|Likes:
Published by niko
un guide qui explique le fonctionnement des réseaux informatiques
un guide qui explique le fonctionnement des réseaux informatiques

More info:

Published by: niko on May 14, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

05/09/2014

pdf

text

original

Cours de r seaux Ma trise d'informatique Universit d'Angers

Pascal Nicolas U.F.R. Sciences de l'Universit d'Angers E-Mail : pascal.nicolas@univ-angers.fr Web : www.info.univ-angers.fr/pub/pn

Pr face
Ceci est le support du cours de r seaux de la ma trise d'informatique de l'Universit d'Angers (ann e 1999/2000). Le chapitre 1 traite des transmissions de donn es et des r seaux en g n ral sous l'angle de l'architecture des syst mes ouverts (mod le OSI). Le chapitre 2 traite du r seau Internet et des protocoles qui lui sont associ s. Les chapitres 3 et 4 sont plus orient s vers des applications pratiques visant la mise en place de services sur les r seaux. Ils ne sont pas d taill s dans ce document car ils sont plus particuli rement tudi s en TD et TP. Les principales r f rences bibliographiques en fran ais sont : Guy Pujolle - Les r seaux. - Eyrolles. Patrice Rolin, et al. - Les r seaux, principes fondamentaux. - Herm s. Douglas Comer - TCP/IP, architectures, protocoles et applications. - Inter ditions. W. Richard Stevens - TCP/IP illustr - Vol 1,2,3. - International Thomson Publishing, France. Tous mes remerciements mes coll gues enseignants ou ing nieurs de l'Universit d'Angers : Serge Tah , Jacques Allo et St phane Vincendeau, pour leur aide la mise en place de ce cours.

Table des mati res
1 Principe des r seaux num riques.
1.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Le mod le de r f rence OSI de l'ISO. . . . . . . . . . . . . . . . . . . . . . . . 1.3 La couche physique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Transmission en bande de base. . . . . . . . . . . . . . . . . . . . . . . 1.3.2 Transmission modul e. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.3 Multiplexage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.4 Les supports de transmission. . . . . . . . . . . . . . . . . . . . . . . . 1.3.5 Exemple de l'ADSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 La couche liaison. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 D tection et correction d'erreurs. . . . . . . . . . . . . . . . . . . . . . 1.4.2 Protocoles de liaison de donn es. . . . . . . . . . . . . . . . . . . . . . 1.5 La couche r seau. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 Le contr le de ux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.2 Le probl me de la congestion. . . . . . . . . . . . . . . . . . . . . . . . 1.5.3 Le routage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.4 La norme X25, niveau r seau. . . . . . . . . . . . . . . . . . . . . . . . 1.6 La couche transport. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.1 Qualit de service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.2 Primitives du service transport. . . . . . . . . . . . . . . . . . . . . . . 1.6.3 Le protocole de transport ISO en mode connect (ISO 8073 ou X.224) 1.7 Les couches hautes : session, pr sentation et application. . . . . . . . . . . . . 1.7.1 La couche session. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.2 La couche pr sentation. . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.3 La couche application. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 2.2 2.3 2.4 Historique et organisation d'Internet. . . . . . Architecture des protocoles TCP/IP. . . . . . Adressage. . . . . . . . . . . . . . . . . . . . . La couche liaison d'Internet. . . . . . . . . . . 2.4.1 Le r seau Ethernet . . . . . . . . . . . 2.4.2 La liaison SLIP . . . . . . . . . . . . . 2.4.3 La liaison PPP . . . . . . . . . . . . . 2.4.4 Les protocoles ARP et RARP . . . . . 2.5 Le protocole IP. . . . . . . . . . . . . . . . . . 2.5.1 Le datagramme IP. . . . . . . . . . . . 2.5.2 La fragmentation des datagrammes IP. 2.5.3 Le routage IP. . . . . . . . . . . . . . . 2.5.4 La gestion des erreurs. . . . . . . . . . 2.6 Les protocoles TCP et UDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 4 6 7 9 10 11 12 13 14 16 18 19 19 20 21 22 23 25 27 29 29 31 31

1

2 Le r seau Internet et les protocoles TCP/IP.

32
32 34 36 40 40 43 44 46 47 47 49 51 55 56

2.6.1 Le protocole UDP. . . . . . . . . . . . . . . . 2.6.2 Le protocole TCP. . . . . . . . . . . . . . . . 2.7 Les applications. . . . . . . . . . . . . . . . . . . . . 2.7.1 Protocole de d marrage : BOOTP. . . . . . . 2.7.2 Connexion distance : Telnet et Rlogin. . . . 2.7.3 Syst me de chiers en r seau : NFS. . . . . . 2.7.4 Transfert de chier : TFTP et FTP. . . . . . . 2.7.5 Courrier lectronique : smtp. . . . . . . . . . . 2.7.6 News : nntp . . . . . . . . . . . . . . . . . . . 2.7.7 World Wide Web : http.. . . . . . . . . . . . . 2.8 Outils communs d'utilisation d'un r seau sous Unix. 2.8.1 Fichiers de con guration. . . . . . . . . . . . 2.8.2 Quelques commandes utiles . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

57 58 64 64 65 66 66 68 70 73 75 75 77

3 Applets Java. 4 Installation d'un intranet

82 83

Chapitre 1

Principe des r seaux num riques.
Dans ce chapitre nous aborderons les grands principes r gissant les quipements mat riels et logiciels permettant d' changer des donn es mises sous forme num rique et qui forment les r seaux informatiques.

1.1 Introduction.
Les r seaux informatiques qui permettaient leur origine de relier des terminaux passifs de gros ordinateurs centraux autorisent l'heure actuelle l'interconnexion de tous types, d'ordinateurs que ce soit de gros serveurs, des stations de travail, des ordinateurs personnels ou de simples terminaux graphiques. Les services qu'ils o rent font partie de la vie courante des entreprises et administrations (banques, gestion, commerce, bases de donn es, recherche, etc...) et des particuliers (messagerie, loisirs, services d'informations par minitel et Internet ...).

MAN bus structure d’interconnexion LAN réseaux locaux réseaux métropolitains

WAN réseaux étendus

1m

10 m

100 m

1 km

10 km

100 km

Fig.

1.1 - Classi cation des r seaux informatiques selon leur taille.

On peut faire une premi re classi cation des r seaux l'aide de leur taille comme on peut le voir dans la gure 1.1. Les bus que l'on trouve dans un ordinateur pour relier ses di rents composants (m moires, p riph riques d'entr e-sortie, processeurs, ...) peuvent tre consid r s comme des r seaux d di s des t ches tr s sp ci ques. Les structures d'interconnexion sont des r seaux de tr s haut d bits, mais de faible tendue, et regroupent les pr et post-processeurs des ordinateurs vectoriels par exemple. En e et l'usage d'un super-calculateur (Cray notamment) n cessite un ordinateur, dit frontal, qui lui pr pare les donn es et recueille les r sultats. Un r seau local (Local Area Network) peut s' tendre de quelques m tres quelques kilom tres et correspond au r seau d'une entreprise. Il peut se d velopper sur plusieurs b timents et permet de satisfaire tous les besoins internes de cette entreprise. 1

Un r seau m tropolitain (Metropolitan Area Network) interconnecte plusieurs lieux situ s dans une m me vile, par exemple les di rents sites d'une universit ou d'une administration, chacun poss dant son propre r seau local. Un r seau tendu (Wide Area Network) permet de communiquer l' chelle d'un pays, ou de la plan te enti re, les infrastructures physiques pouvant tre terrestres ou spatiales l'aide de satellites de t l communications.

bus

anneau réseaux en mode de diffusion

satellite

étoile

boucle simple

boucle double

maillage régulier

maillage irrégulier réseaux en mode point à point

Fig.

1.2 - Topologie des r seaux informatiques.

On peut galement di rencier les r seaux selon leur structure ou plus pr cis ment leur topologie comme illustr dans la gure 1.2. On y distingue ainsi deux classes de r seaux : ceux en mode de di usion ceux en mode point point Le premier mode de fonctionnement consiste partager un seul support de transmission. Chaque message 1 envoy par un quipement sur le r seau est re u par tous les autres. C'est l'adresse sp ci que plac e dans le message qui permettra chaque quipement de d terminer si le message lui est adress ou non. tout moment un seul quipement le droit d'envoyer un message sur le support, il faut donc qu'il coute au pr alable si la voie est libre si ce n'est pas le cas il attend selon un protocole sp ci que chaque architecture. Les r seaux locaux adoptent pour la plupart le mode di usion sur une architecture en bus ou en anneau et les r seaux satellitaires ou radio suivent galement ce mode de communication. Dans une telle con guration la rupture du support provoque l'arr t du r seau, par contre la panne d'un des l ments ne provoque pas (en g n ral) la panne globale du r seau. Dans le mode di usion point point le support physique (le c ble) relie une paire d' quipements seulement. Quand deux l ments non directement connect s entre eux veulent communiquer ils le font par l'interm diaire des autres n uds du r seau. Dans le cas de l' toile le site central re oit et envoie tous les messages, le fonctionnement est simple, mais la panne du n ud central paralyse tout le r seau Dans une boucle simple, chaque n ud recevant un message de son voisin en amont le r exp die son voisin en aval. Pour que les messages ne tournent pas ind niment le n ud metteur retire le message
1: Terme

laiss vague pour l'instant.

2

lorsqu'il lui revient. Si l'un des l ments du r seau tombe en panne, alors tout s'arr te. Ce probl me est partiellement r solu par la double boucle dont chacune des boucles fait tourner les messages dans un sens oppos . En cas de panne d'un quipement, on reconstitue une boucle simple avec les l ments actifs des deux boucles, mais dans ce cas tout message passera deux fois par chaque n ud. Il en r sulte alors une gestion tr s complexe. Dans le maillage r gulier l'interconnexion est totale ce qui assure une abilit optimale du r seau, par contre c'est une solution co teuse en c blage physique. Si l'on all ge le plan de c blage, le maillage devient irr gulier et la abilit peut rester lev e mais elle n cessite un routage des messages selon des algorithmes parfois complexes. Dans cette architecture il devient presque impossible de pr voir le temps de transfert d'un n ud un autre. Quelle que soit l'architecture physique d'un r seau on trouve deux modes de fonctionnement di rents : avec connexion sans connexion Dans le mode avec connexion, toute communication entre deux quipements suit le processus suivant: 1. l' metteur demande l' tablissement d'une connexion par l'envoi d'un bloc de donn es sp cial 2. si le r cepteur (ou le gestionnaire de service) refuse cette connexion la communication n'a pas lieu 3. si la connexion est accept e, elle est tablie par mise en place d'un circuit virtuel dans le r seau reliant l' metteur au r cepteur 4. les donn es sont ensuite transf r es d'un point l'autre 5. la connexion est lib r e C'est le fonctionnement bien connu du r seau t l phonique classique. Les avantages du mode avec connexion sont la s curisation du transport par identi cation claire de l' metteur et du r cepteur, la possibilit d' tablir l'avance des param tres de qualit de service qui seront respect s lors de l' change des donn es. Les d fauts sont la lourdeur de la mise en place de la connexion qui peut se r v ler beaucoup trop on reuse si l'on ne veut changer que quelques octets ainsi que la di cult tablir des communications multipoint. Dans le mode sans connexion les blocs de donn es, appel s datagrammes, sont mis sans v ri er l'avance si l' quipement atteindre, ainsi que les n uds interm diaires ventuels, sont bien actifs. C'est alors aux quipements g rant le r seau d'acheminer le message tape par tape et en assurant ventuellement sa temporisation jusqu' ce que le destinataire soit actif. Ce service est celui du courrier postal classique et suit les principes g n raux suivants: - le client poste une lettre dans une bo te aux lettres - chaque lettre porte le nom et l'adresse du destinataire - chaque client a une adresse propre et une bo te aux lettres - le contenu de l'information reste inconnu du prestataire de service - les supports du transport sont inconnus de l'utilisateur du service D'autre part il existe plusieurs types de commutation dont les principaux sont : la commutation de circuits : c'est historiquement la premi re avoir t utilis e, par exemple dans le r seau t l phonique l'aide des auto-commutateurs. Elle consiste cr er dans le r seau 3

un circuit particulier entre l' metteur et le r cepteur avant que ceux-ci ne commencent changer des informations. Ce circuit sera propre aux deux entit s communiquant et il sera lib r lorsque l'un des deux coupera sa communication. Par contre, si pendant un certain temps les deux entit s ne s' changent rien le circuit leur reste quand m me attribu . C'est pourquoi, un m me circuit (ou portion de circuit) pourra tre attribu plusieurs communications en m me temps. Cela am liore le fonctionnement global du r seau mais pose des probl mes de gestion ( les d'attente, m morisation,...) la commutation de messages : elle consiste envoyer un message 2 de l' metteur jusqu'au r cepteur en passant de n ud de commutation en n ud de commutation. Chaque n ud attend d'avoir re u compl tement le message avant de le r exp dier au n ud suivant. Cette technique n cessite de pr voir de grandes zones tampon dans chaque n ud du r seau, mais comme ces zones ne sont pas illimit es il faut aussi pr voir un contr le de ux des messages pour viter la saturation du r seau. Dans cette approche il devient tr s di cile de transmettre de longs messages. En e et, comme un message doit tre re u enti rement chaque tape si la ligne a un taux d'erreur de 10;5 par bit (1 bit sur 105 est erron ) alors un message de 100000 octets n'a qu'une probabilit de 0,0003 d' tre transmis sans erreur. la commutation de paquets : elle est apparue au d but des ann es 70 pour r soudre les probl mes d'erreur de la commutation de messages. Un message mis est d coup en paquets 3 et par la suite chaque paquet est commut travers le r seau comme dans le cas des messages. Les paquets sont envoy s ind pendamment les uns des autres et sur une m me liaison on pourra trouver les uns derri re les autres des paquets appartenant di rents messages. Chaque n ud redirige chaque paquet vers la bonne liaison gr ce une table de routage. La reprise sur erreur est donc ici plus simple que dans la commutation de messages, par contre le r cepteur nal doit tre capable de reconstituer le message mis en r assemblant les paquets. Ceci n cessitera un protocole particulier car les paquets peuvent ne pas arriver dans l'ordre initial, soit parce qu'ils ont emprunt des routes di rentes, soit parce que l'un d'eux a du tre r mis suite une erreur de transmission. la commutation de cellules : une cellule est un paquet particulier dont la taille est toujours x e 53 octets (5 octets d'en-t te et 48 octets de donn es). C'est la technique de base des r seaux hauts d bits ATM (Asynchronous Transfert Mode) qui op rent en mode connect o avant toute mission de cellules, un chemin virtuel est tabli par lequel passeront toutes les cellules. Cette technique mixe donc la commutation de circuits et la commutation de paquets de taille xe permettant ainsi de simpli er le travail des commutateurs pour atteindre des d bits plus lev s.

1.2 Le mod le de r f rence OSI de l'ISO.
Au d but des ann es 70, chaque constructeur a d velopp sa propre solution r seau autour d'architecture et de protocoles priv s (SNA d'IBM, DECnet de DEC, DSA de Bull, TCP/IP du DoD,...) et il s'est vite av r qu'il serait impossible d'interconnecter ces di rents r seaux propri taires si une norme internationale n' tait pas tablie. Cette norme tablie par l'International Standard Organization 4 (ISO) est la norme Open System Interconnection (OSI, interconnexion de syst mes ouverts). Un syst me ouvert est un ordinateur, un terminal, un r seau, n'importe quel quipement respectant cette norme et donc apte changer des informations avec d'autres quipements h t rog nes et issus de constructeurs di rents.
: :

2 Un message est une suite d'informations formant un tout, par exemple un chier ou une ligne de commande tap e au clavier d'un ordinateur. 3 Un paquet est une suite d'octets, dont le contenu n'a pas forc ment une signi cation et ne pouvant pas d passer une taille x e par avance. 4 L'ITU-T, International Telecommunication Union, Telecommunication Sector, anciennement CCITT est galement un organisme de normalisation des t l communications. Il d pend de l'ONU et est bas Gen ve. Information
:

http://www.itu.int

4

7 Application 6 Pr sentation 5 Session 4 Transport 3 R seau 2 Liaison 1 Physique
Fig.

1.3 - Les sept couches du mod le de r f rence OSI de l'ISO.

Le premier objectif de la norme OSI a t de d nir un mod le de toute architecture de r seau bas sur un d coupage en sept couches (cf gure 1.3), chacune de ces couches correspondant une fonctionnalit particuli re d'un r seau. Les couches 1, 2, 3 et 4 sont dites basses et les couches 5, 6 et 7 sont dites hautes.
couche 7

6 ? 6 ? couche 5 6 ? couche 4 6 ? couche 3 6 ? couche 2 6 ? couche 1 6 ?
couche 6
Fig.

protocole de couche 6 protocole de couche 5 protocole de couche 4 protocole de couche 3 protocole de couche 2 protocole de couche 1 protocole de couche 7 support physique

couche 7

6 ? 6 ? couche 5 6 ? couche 4 6 ? couche 3 6 ? couche 2 6 ? couche 1 6 ?
couche 6

1.4 - Communication entre couches.

Chaque couche est constitu e d' l ments mat riels et logiciels et o re un service la couche situ e imm diatement au-dessus d'elle en lui pargnant les d tails d'impl mentation n cessaires. Comme illustr dans la gure 1.4, chaque couche n d'une machine g re la communication avec la couche n d'une autre machine en suivant un protocole de niveau n qui est un ensemble de r gles de communication pour le service de niveau n. En fait, aucune donn e n'est transf r e directement d'une couche n vers une autre couche n, mais elle l'est par tapes successives. Supposons un message transmettre de l' metteur A vers le r cepteur B . Ce message, g n r par une application de la machine A va franchir les couches successives de A via les interfaces qui existent entre chaque couche pour nalement atteindre le support physique. L , il va transiter via di rents n uds du r seau, chacun de ces n uds traitant le message via ses couches basses. Puis, quand il arrive destination, le message remonte les couches du r cepteur B via les di rentes interfaces et atteint l'application charg e de traiter le message re u. Ce processus de communication est illustr dans la gure 1.5. Nous allons maintenant d tailler les caract ristiques de chacune de ces couches en pr cisant d'abord que les fonctions et services d nis dans les couches du mod le OSI peuvent se retrouver dans d'autres couches dans les syst mes op rationnels disponibles sur le march . Il se peut galement qu'une fonctionnalit localis e dans une seule couche dans le mod le OSI se retrouve r partie sur plusieurs couches. Mais cela illustre simplement la distance qui existe entre un mod le th orique et des implantations 5

- application 6 6 ? ? -pr sentation pr sentation 6 6 ? ? - session session 6 6 ? ? - transport transport sous-r seaux 6 - r seau 6 ? ? - r seau - r seau r seau 6 - liaison 6 6 6 ? ? ? ? - liaison - liaison liaison 6 - physique 6 6 6 ? ? ? ? - physique - physique physique 6 physique 6 6 physique 6 ? ? ? ? support support
application
Fig.

metteur A

r cepteur B

1.5 - Communication entre couches.

pratiques essayant de suivre ce mod le.

1.3 La couche physique.
D nition 1.3.1 La couche physique fournit les moyens m caniques, lectriques, fonctionnels et proc duraux n cessaires l'activation, au maintien et la d sactivation des connexions physiques destin es la transmission de bits entre deux entit s de liaison de donn es.

Ici, on s'occupe donc de transmission des bits de fa on brute, l'important est que l'on soit s r que si l' metteur envoie un bit 1 alors le r cepteur re oit un bit 1. Les normes et standards de la couche physique d nissent le type de signaux mis (modulation, puissance, port e...), la nature et les caract ristiques des supports (c ble, bre optique...), les sens de transmission... Tout d'abord une liaison entre 2 quipements A et B peut tre simplex (unidirectionnelle), dans ce cas A est toujours l' metteur et B le r cepteur. C'est ce que l'on trouve par exemple entre un banc de mesure et un ordinateur recueillant les donn es mesur es. La communication est half-duplex (bidirectionnelle l'alternat) quand le r le de A et B peut changer, la communication change de sens tour de r le (comme avec des talkies-walkies). Elle est full-duplex (bidirectionnelle simultan e) quand A et B peuvent mettre et recevoir en m me temps (comme dans le cas du t l phone). La transmission de plusieurs bits peut s'e ectuer en s rie ou en parall le. En s rie, les bits sont envoy s les uns derri re les autres de mani re synchrone ou asynchrone. Dans le mode synchrone l' metteur et le r cepteur se mettent d'accord sur une base de temps (un top d'horloge) qui se r p te r guli rement durant tout l' change. chaque top d'horloge (ou k tops d'horloge k entier x d nitivement) un bit est envoy et le r cepteur saura ainsi quand lui arrive les bits. Dans le mode asynchrone, il n'y a pas de n gociation pr alable mais chaque caract re envoy est pr c d d'un bit de start et imm diatement suivi d'un bit de stop. Ces deux bits sp ciaux servent caler l'horloge du r cepteur pour qu'il chantillonne le signal qu'il re oit a n d'y d coder les bits qu'il transmet. En parall le, les bits d'un m me caract re sont envoy s en m me temps chacun sur un l distinct, mais cela pose des probl mes de synchronisation et n'est utilis que sur de courtes distances (bus par exemple). Quel que soit le mode de transmission retenu, l' mission est toujours cadenc e par une horloge dont la vitesse donne le d bit de la ligne en bauds, c'est- -dire le nombre de tops d'horloge en une seconde. Ainsi, une ligne d'un d bit de 100 bauds autorise 100 missions par seconde. Si chaque top d'horloge un signal repr sentant 0 ou 1 est mis, alors dans ce cas le d bit en bit=s est quivalent au d bit en baud. Cependant, on peut imaginer que le signal mis puisse prendre 4 valeurs distinctes (0, 1, 2, 3) 6

dans ce cas le signal a une valence de 2 et le d bit en bit=s est double de celui en baud. D'une mani re g n rale, si le signal peut prendre 2 valeurs distinctes on dit alors que sa valence est de n, ainsi chaque top n bits peuvent tre transmis simultan ment et si le d bit de la ligne est de x bauds il est en fait de n.x bit/s.
n

1.3.1 Transmission en bande de base.

La transmission en bande de base consiste envoyer directement les suite de bits sur le support l'aide de signaux carr s constitu s par un courant lectrique pouvant prendre 2 valeurs (5 Volts ou 0 par exemple). On d taillera ci-apr s les di rents codages des bits possibles, mais dans tous les cas l' metteur envoie sur la ligne un signal carr du type de celui de la gure 1.6 pour la s quence de bits 1010 par exemple.

1

6

1 1000

1 T = 500

-

Fig.

1.6 - Signal carr de la s quence de bits 1010.

En consid rant ce signal g(t) comme p riodique (il su t de r p ter une fois sur T::2T ] le signal donn sur 0::T ] pour obtenir un signal p riodique sur 0::2T ]) on peut le d composer en une s rie de Fourier de la forme 1 1 X X g(t) = c=2 + a sin(2 nft) + b cos(2 nft)
n n

o

n=1

n=1

f = 1=T la fr quence fondamentale du signal Z c = 2=T g(t)dt
T

a = 2=T
n

Z Z

0

T

0
T

g(t)sin(2 nft)dt g(t)cos(2 nft)dt

b = 2=T
n

0

On dit que le signal carr est d compos en une somme in nie d'harmoniques, la premi re tant d nomm e fondamentale, et cette approximation math matique permet de savoir quel signal lectrique sera r ellement re u au bout du c ble. Cependant, le c ble sur lequel est mis le signal poss de une bande passante qui est l'intervalle des fr quences possibles sur ce support, donc la r ception on ne retrouve pas toute la richesse du signal initial et dans la plupart des cas le signal carr sera tr s d form . Par exemple, le c ble t l phonique a une bande passante de 300 3400 Hz, donc tous les signaux de fr quence inf rieure 300 ou sup rieure 3400 seront limin es. Dans notre exemple nous obtenons g(t) = 1 + 2 sin(2000 t) + 32 sin(6000 t) + 52 sin(10000 t) + : : : 2 Dans la gure 1.7 nous trouvons gauche les 3 premi res harmoniques et on remarque que plus la fr quence augmente plus l'amplitude diminue. droite nous avons le signal r ellement per u par le r cepteur si l'on consid re que le c ble ne laisse passer que ces 3 harmoniques-ci. Dans ce cas le signal re u reste assez proche du carr mis et le r cepteur n'aura pas trop de mal le d coder. 7

1.2 1 0.8 0.6 0.4 0.2 0 -0.2 0
Fig.

1.2 1 0.8 0.6 0.4 0.2 0 -0.2 0.001 0.002 0 0.001 0.002

1.7 - Harmoniques et transform e de Fourrier de la s quence de bits 1010.

Sans entrer dans des d tails relevant de la th orie du signal, nous indiquerons simplement que sur une ligne t l phonique dont la bande passante est de 3100Hz et pour un rapport signal/bruit 5 de 10dB on peut atteindre une capacit de 10Kbits/s.
0 1 1 0 0 1 0
code tout ou rien code NRZ code bipolaire code RZ (retour z ro) code biphase (ou Manchester) code Miller (delay modulation)

0
Fig.

1

1

0

0

1

0

1.8 - Di rents codages en bande de base de la s quence 0110010.

Dans la gure 1.8 nous trouvons quelques exemple de codage de l'information pour une transmission en bande de base. le code tout ou rien : c'est le plus simple, un courant nul code le 0 et un courant positif indique le 1 le code NRZ (non retour z ro): pour viter la di cult par un courant positif et le 0 par un courant n gatif.
:

obtenir un courant nul, on code le 1

5 Rapport de l' nergie du signal mis sur l' nergie du bruit de la ligne. Le bruit tant d'un point de vue math matique une fonction al atoire repr sentant les perturbations (ondes lectromagn tiques, d fauts dans les composants qui relaient le signal...) que subit la transmission.

8

le code bipolaire : c'est aussi un code tout ou rien dans lequel le 0 est repr sent par un courant nul, mais ici le 1 est repr sent par un courant alternativement positif ou n gatif pour viter de maintenir des courants continus. le code RZ : le 0 est cod par un courant nul et le 1 par un courant positif qui est annul au milieu de l'intervalle de temps pr vu pour la transmission d'un bit. le code Manchester : ici aussi le signal change au milieu de l'intervalle de temps associ chaque bit. Pour coder un 0 le courant sera n gatif sur la premi re moiti de l'intervalle et positif sur la deuxi me moiti , pour coder un 1, c'est l'inverse. Autrement dit, au milieu de l'intervalle il y a une transition de bas en haut pour un 0 et de haut en bas pour un 1. le code Miller : on diminue le nombre de transitions en e ectuant une transition (de haut en bas ou l'inverse) au milieu de l'intervalle pour coder un 1 et en n'e ectuant pas de transition pour un 0 suivi d'un 1. Une transition est e ectu e en n d'intervalle pour un 0 suivi d'un autre 0.

1.3.2 Transmission modul e.
Le principal probl me de la transmission en bande de base est la d gradation du signal tr s rapide en fonction de la distance parcourue, c'est pourquoi elle n'est utilis e qu'en r seau local (<5km). Il serait en e et trop co teux de pr voir des r p teurs pour r g n rer r guli rement le signal. C'est pourquoi sur les longues distance on met un signal sinuso dal qui, m me s'il est a aibli, sera facilement d codable par le r cepteur. Ce signal sinuso dal est obtenu gr ce un modem (modulateur-d modulateur)qui est un quipement lectronique capable de prendre en entr e un signal en bande de base pour en faire un signal sinuso dal (modulation) et l'inverse savoir restituer un signal carr partir d'un signal sinuso dal (d modulation). Autrement dit il permet de passer de signaux num riques discrets (0 ou 1) des signaux analogiques continus. Il existe trois types de modulation d crits dans la gure 1.9 la modulation d'amplitude envoie un signal d'amplitude di rente suivant qu'il faut transmettre un 0 ou un 1. Cette technique est e cace si la bande passante et la fr quence sont bien ajust es. Par contre, il existe des possibilit s de perturbation (orage, lignes lectriques...), car si un signal de grande amplitude (repr sentant un 1) est momentan ment a aibli le r cepteur l'interpr tera tort en un 0. la modulation de fr quence envoie un signal de fr quence plus lev e pour transmettre un 1. Comme l'amplitude importe peu, c'est un signal tr s r sistant aux perturbations (la radio FM est de meilleure qualit que la radio AM) et c'est assez facile d tecter. la modulation de phase change la phase du signal (ici de 180 ) suivant qu'il s'agit d'un 0 (phase montante) ou d'un 1 (phase descendante). Dans les exemples donn s ci-dessus on a seulement 2 niveaux possibles chaque fois, donc on a uniquement la possibilit de coder 2 valeurs di rentes chaque instant, dans ce cas 1 baud = 1bit/s. De mani re plus sophistiqu e il existe des modems capables de moduler un signal suivant plusieurs niveaux, par exemple 4 fr quences di rentes que le modem r cepteur saura lui aussi distinguer. Dans ce cas, chaque signal envoy code 2 bits donc 1 baud = 2bit/s. Il est m me possible de transmettre des signaux m lant les di rentes modulations pr sent es comme dans le cas de la norme V29 qui module la fois l'amplitude du signal sur 2 niveaux et la phase sur 8 niveaux (0 ,45 ,. . . ,315 ). En combinant les 2 modulations, on obtient ainsi 16 signaux di rents possibles chaque instant, permettant de transmettre simultan ment 4 bits chaque top d'horloge (1 baud = 4 bit/s). 9

2 1.5 1 0.5 0 -0.5 -1 -1.5 -2

2 1.5 1 0.5 0 -0.5 -1 -1.5 -2 0 1 1 0 0 1 0 0 1 1 0 0 1 0 2 1.5 1 0.5 0 -0.5 -1 -1.5 -2 0 1 1 0 0 1 0

Fig.

1.9 - Modulations d'amplitude, de fr quence et de phase de la s quence de bits 0110010.

1.3.3 Multiplexage.
Le multiplexage consiste faire transiter sur une seule et m me ligne de liaison, dite voie haute vitesse, des communications appartenant plusieurs paires d' quipements metteurs et r cepteurs comme repr sent dans la gure 1.10. Chaque metteur (resp. r cepteur) est raccord un multiplexeur (resp. d multiplexeur) par une liaison dit voie basse vitesse. Plusieurs techniques sont possibles : le multiplexage fr quentiel consiste a ecter chaque voie basse vitesse une bande passante particuli re sur la voie haute vitesse en s'assurant qu'aucune bande passante de voie basse vitesse ne se chevauche. Le multiplexeur prend chaque signal de voie basse vitesse et le r emet sur la voie haute vitesse dans la plage de fr quences pr vues. Ainsi plusieurs transmissions peuvent tre faites simultan ment, chacune sur une bande de fr quences particuli res, et l'arriv e le d multiplexeur 6 est capable de discriminer chaque signal de la voie haute vitesse pour l'aiguiller sur la bonne voie basse vitesse. le multiplexage temporel partage dans le temps l'utilisation de la voie haute vitesse en l'attribuant successivement aux di rentes voies basse vitesse m me si celles-ci n'ont rien mettre. Suivant les techniques chaque intervalle de temps attribu une voie lui permettra de transmettre 1 ou plusieurs bits. le multiplexage statistique am liore le multiplexage temporel en n'attribuant la voie haute vitesse qu'aux voies basse vitesse qui ont e ectivement quelque chose transmettre. En ne transmettant pas les silences des voies basses cette technique implant e dans des concentrateurs am liore
6: Le

m me quipement joue la fois le r le de multiplexeur et d multiplexeur.

10

voies BV . . . MUX voie HV DEMUX

voies BV .. .

6
0

vbv 1

vbv 2 vbv 3 vbv 4 vbv 5 fr quences de la voie HV
Fig.

N kHz

-

vbv 1 0

vbv 2 vbv 3 vbv 4 vbv 5 utilisation de la voie HV

N sec

-

1.10 - Multiplexages d'une ligne.

grandement le d bit global des transmissions mais elle fait appel des protocoles de plus haut niveau et est bas e sur des moyennes statistiques des d bits de chaque ligne basse vitesse.

1.3.4 Les supports de transmission.

L'objectif de la couche 1 du mod le OSI est aussi de xer les caract ristiques des mat riels utilis s pour relier physiquement les quipements d'un r seau. Nous d crivons succinctement quelques uns des supports de transmission les plus usit s. la paire torsad e est un c ble t l phonique constitu l'origine de deux ls de cuivre isol s et enroul s l'un sur l'autre (d'o le nom). Actuellement on utilise plut t des c bles constitu s de 2 ou 4 paires torsad es. Elle est tr s r pandue, de connexion facile et d'un faible co t mais elle poss de une faible immunit aux bruits. Pour am liorer les performances on utilise la paire torsad e blind e plus r sistante aux perturbations lectromagn tiques et qui autorise un d bit pouvant aller jusqu' 16 Mbits/s. D'une mani re g n rale les performances (et les co ts) de ce support d pendent de la qualit des mat riaux employ s et des d tails de r alisation. On recommande actuellement d'utiliser de la 4 paires non blind es de cat gorie 5 avec une imp dance de 100 ohm (la cat gorie 3 est inf rieure en qualit , et l'imp dance 120 ohm est une particularit fran aise). Utilis e en ligne de t l phone classique leur d bit est au maximum de 56 Kbit/s avec les modems les plus r cents, mais les progr s de cette technologie autorisent, sur de courtes distances, des d bits de l'ordre de 10 Mbit/s voire 100 Mbit/s. On la rencontre tr s souvent comme support des r seaux 10 Base T 7 , chaque extr mit d'un tel c ble tant muni d'une prise RJ45. Son int r t principal est que cette m me paire torsad e peut servir au r seau t l phonique, au r seau informatique et vid o d'une m me entreprise et de plus elle pourra tre utilis e ult rieurement pour voluer vers des r seaux 100 Base T et m me Gigabits . Dans ce type de r seaux locaux chaque poste est reli un hub, par une liaison point point, formant physiquement une toile (dont le centre est un hub) ou un arbre, mais dont le fonctionnement est en mode de di usion de type bus. Cependant l'orientation actuelle est de remplacer les hubs par des commutateurs qui eux r alisent de la di usion en mode point point. le c ble coaxial est un c ble utilis galement en t l phonie et en t l vision, il est constitu d'un c ur qui est un l de cuivre. Ce c ur est dans une gaine isolante elle-m me entour e par une tresse de cuivre, le tout est recouvert d'une gaine isolante. Certains coaxiaux large bande peuvent atteindre un d bit maximal de 150 Mhz mais son encombrement est nettement sup rieur celui de la paire torsad e et ses performances n'atteignant pas celle de la bre optique il a tendance dispara tre des nouveaux plans de c blage.
7: T

pour twisted (torsad e), 10 pour 10 Mbits/s et 100

Base T

pour 100 Mbit/s.

11

On le rencontre dans sa version 10 Base2 (ou Ethernet n 10 Mbit/s sur 200 m maximum) ou 10 Base5 (ou Ethernet pais 10 Mbit/s sur 500 m maximum) pour la r alisation de r seaux locaux topologie en bus. Les connexions de chaque poste sur le bus se font l'aide de connecteur en T et la connexion du c ble sur le poste se fait l'aide de connecteur AUI pour l'Ethernet pais et BNC pour l'Ethernet n 8 . Il est actuellement beaucoup utilis pour relier entre eux deux l ments actifs (hub, routeur,...) la bre optique est un support d'apparition plus r cente mais son utilisation prend de l'ampleur de jour en jour car elle permet(tra) des d bits de plusieurs Gbit/s sur de tr s longues distances. Elle est particuli rement adapt e l'interconnexion de r seaux par exemple entre plusieurs b timent d'un m me site. En plus de ses capacit s de transmission, ses grands avantages sont son immunit aux interf rences lectromagn tiques et sa plus grande di cult d' coute, contrairement aux supports lectriques, ce qui la rend galement attrayante dans les contextes o la con dentialit est requise. D'un point de vue technique une bre optique est constitu e d'un c ur et d'une gaine en silice de quelques m recouvert d'un isolant. une extr mit une diode lectroluminescente (LED) ou une diode laser met un signal lumineux et l'autre une photodiode ou un phototransistor est capable de reconna tre ce signal.
source lumineuse

:XX 1PPP XXX PPPP XXX X P XX q P z X
Fig.

1

:

1.11 - R exion interne.

Les di rents rayons lumineux issus de la source sont guid s par le l de verre en suivant un principe de r exion interne qui se produit au niveau de la fronti re entre le c ur et la gaine comme illustr dans la gure 1.11. Si la r exion ne laisse subsister qu'un seul rayon, car le diam tre du l est tr s r duit, alors on parle de bre monomode sinon, lorsqu'il existe plusieurs rayons simultan ment on parle de bre multimode. En n, la bande passante d'une bre optique tant tr s large (plusieurs MHz) il est ais de faire du multiplexage fr quentiel pour faire transiter simultan ment plusieurs communications. les liaisons sans l sont possibles gr ce des liaisons infrarouges ou laser sur de courtes distances et gr ce aux faisceaux hertziens pour les liaisons satellitaires. Les d bits sont tr s lev s mais les transmissions sont sensibles aux perturbations et les possibilit s d' coute sont nombreuses.

1.3.5 Exemple de l'ADSL.
La technique de l'ADSL (Asymetric bit rate Digital Subscriber Line ou ligne num rique d'abonn s d bits asym triques) est une technique r cente qui permet d'utiliser, sur de courtes distances, les lignes t l phoniques classiques mais avec un d bit tr s sup rieur celui des normes plus classiques (V34 ou V90). Par exemple, dans sa version Lite, elle permet de connecter Internet un particulier en utilisant simplement sa ligne t l phonique habituelle comme illustr dans la gure 1.12. De mani re th orique, cette technologie o re un d bit maximal descendant (d'Internet vers l'abonn ) de 8,2 M bit/sec et un d bit maximal montant (de l'abonn vers Internet) de 640 K bit/sec. Cependant, ces performances ne sont pas possibles sur une grande distance (plus de 5 km) et les solutions commerciales grand public propos es en France actuellement ( n 1999) xent par exemple le d bit entrant 512 Kbit/sec et le d bit sortant 128 Kbit/sec.
8: Le

fonctionnement d'un r seau Ethernet sera approfondi dans la section 2.4.1.

12

PC

modem ADSL

modem ADSL

routeur

INTERNET

téléphone filtre

voix

RTC

Fig.

1.12 - Connexion Internet via ADSL Lite.

D'un point de vue technique ADSL fonctionne en full duplex gr ce un multiplexage fr quentiel, permettant de faire transiter simultan ment les signaux montant et descendant accompagn s galement des signaux portant la voix t l phonique. La gure 1.13 illustre ce multiplexage dans le cas o les

RTC

canal montant

canal descendant

0
Fig.

4kHz

25kHz

200kHz

1,1 MHz

1.13 - Multiplexage fr quentiel utilis par ADSL ( chelle des fr quences non r elles).

fr quences pour les voies montantes et descendantes ont t clairement s par es. Pour gagner encore en largeur de bande, et donc en d bit, on peut envisager de rapprocher les deux espaces de fr quences mais il faut alors annuler les perturbations (ph nom ne d' cho) que subissent les signaux montant et descendant mis simultan ment. Les di rents signaux sont transmis selon la technologie DMT (Discrete MultiTone ) qui divise la totalit de la bande passante en 256 sous-canaux d'une largeur de 4,3 kHz. Ainsi, le 1er canal est r serv la t l phonie. Les canaux 2 6 servent s parer la voix des donn es num riques. Le ux montant occupe les 32 canaux suivants et le ux descendant tous les canaux restant, dans le cas o aucune zone de fr quence ne s pare les deux sens de communication et que l'annulation d' cho est en place. Le fait que la largeur de bande montante soit plus faible que la descendante explique le terme asym trique dans la d nomination ADSL. De plus, certains sous-canaux sont utilis s pour la gestion de la transmission Chacun des sous-canaux est modul ind pendamment en utilisant la technique du QAM (Quadrature amplitude modulation), qui est une m thode de modulation d'amplitude de deux porteuses en quadrature (4 niveaux d'amplitude). Avant tout transfert de donn es, une proc dure de n gociation (handshake) est mise en place pour mesurer la qualit de la transmission et l'adapter en fonction de la ligne. On appelle cette technique rate adaptative, car elle est capable de diminuer le d bit si la qualit de la transmission se d grade.

1.4 La couche liaison.
D nition 1.4.1 La couche liaison de donn es fournit les moyens fonctionnels et proc duraux n cessaires l' tablissement, au maintien et la lib ration des connexions de liaison de donn es entre entit s du r seau. Elle d tecte et corrige, si possible, les erreurs d es au support physique et signale la
13

couche r seau les erreurs irr cup rables. Elle supervise le fonctionnement de la transmission et d nit la structure syntaxique des messages, la mani re d'enchainer les changes selon un protocole normalis ou non.

Une connexion de liaison de donn es est r alis e l'aide d'une ou plusieurs liaisons physiques entre deux machines adjacentes dans le r seau donc sans n uds interm diaires entre elles. Nous commen ons par examiner les di rentes techniques de d tection et correction d'erreur (changement de 1 par 0 ou vice-versa), puis nous tudierons deux familles de protocoles de liaison de donn es. Le taux d'erreurs de transmission est de l'ordre de 10;5 sur une ligne t l phonique, de 10;7 10;8 sur un coaxial et de 10;10 10;12 sur une bre optique. ce niveau-l il ne s'agit pas d'assurer la correction globale d'un change, mais de d tecter et d' ventuellement corriger des erreurs de transmissions dans un bloc de bits achemin par le support physique. En e et, puisque la couche 2 ne conna t pas le propri taire des paquets qu'elle manipule, elle ne peut pas se substituer aux couches de niveau sup rieur. Les techniques employ es ici reposent sur l'utilisation de codes correcteurs ou codes d tecteurs d'erreurs qui chacun transforme la suite de bits envoyer en lui ajoutant de l'information base de bits de redondance ou bits de contr le. Le r cepteur se sert de cette information ajout e pour d terminer si une erreur s'est produite et pour la corriger si la technique employ e le permet. la parit ajoute chaque bloc de i bits (i=7 ou 8) mis un bit de parit de telle sorte que parmi les i + 1 bits mis le nombre de bits 1 soit toujours pair (ou impair). Par exemple, pour une parit paire si le bloc initial est de 7 bits et est gal 1000001 le bloc de 8 bits mis est 10000010, pour envoyer 0110100 le bloc 01101001 est mis. la r ception, le d codeur calcule le nombre de bits 1 et dans le cas d'une parit paire si ce nombre de bits est pair on suppose qu'il n'y a pas eu d'erreur. Sinon, on sait alors qu'il y a eu une erreur de transmission mais on ne sait pas la localiser et il faut alors demander la r mission du bloc. La technique de parit est simple mettre en uvre cependant elle ne permet pas de d tecter 2n erreurs dans le m me bloc de bits transmis, car dans ce cas la parit ne sera pas chang e. les codes redondance cyclique (CRC) ajoutent des bits qui sont des combinaisons lin aires des bits de l'information transmettre. La suite de bits transmettre u1 u2 : : : u est consid r e comme un polyn me M (x) = u1 x ;1 + u2 x ;2 + : : : + u . Par exemple 1101011011 est repr sent par x9 + x8 + x6 + x4 + x3 + x + 1 . l' mission, on calcule la division du polyn me M multipli par x par le polyn me g n rateur G de degr r. On appelle Q le polyn me quotient et R le polyn me reste de cette division, on a donc : x M (x) = Q(x):G(x) + R(x) . La suite de bits correspondant au polyn me R constitue le CRC qui est ajout l'information transmettre, le polyn me total mis est donc E (x) = x M (x) + R(x) Par exemple, l'aide du polyn me g n rateur G(x) = x4 + x + 1, la suite 1101011011 sera transmise accompagn e du CRC 1110 car
k k k k r r r

1.4.1 D tection et correction d'erreurs.

x4 M (x) = x13 + x12 + x10 + x8 + x7 + x5 + x4 = (x9 + x8 + x3 + x)(x4 + x + 1) + x3 + x2 + x
la r ception, on divise le polyn me M 0 correspondant la suite totale de bits re us (information+CRC) par le polyn me g n rateur. Si le reste calcul est non nul, c'est qu'une erreur s'est produite dans la transmission. Si le reste est nul, on est peu pr s s r (99,975% avec le polyn me g n rateur x16 + x12 + x5 + 1 de la norme V41 du ITU-T) que la transmission s'est faite sans erreur. 14

Pourquoi cela fonctionne-t-il? Il est vident que x M (x) ; R(x) est divisible par G(x), mais en arithm tique modulo 2 addition et soustraction sont quivalentes (ce sont des OU exclusifs en fait) donc on a galement E (x) = x M (x) + R(x) = G(x)Q(x) montrant que E est un polyn me multiple de G. Si lors de la transmission des erreurs se sont produites, cela se traduit par le fait que le polyn me re u M 0 (x) = E (x) + T (x), T tant le polyn me correspondant aux erreurs (T (x) = x si le ie bit a t invers ). la r ception le d codeur calcule le reste de ( )+ ) ( ) ( ( ) qui est en fait le reste de ( ) puisque E est un multiple de G. Si ce r sultat est non nul, c'est que T est non nul et que des erreurs se sont produites. videmment, le r sultat est galement nul si T est un multiple de G ce qui masque des erreurs, mais le choix judicieux de G permet de minimiser ces erreurs non d tect es. En n, il faut aussi remarquer un inconv nient de cette m thode qui signale des erreurs de transmission m me si celles-ci ont eu lieu dans le CRC et non dans l'information transmettre initialement. Dans ce cas il ne devrait pas tre n cessaire de retransmettre l'information, or c'est ce qui est fait puisque globalement le transfert (info+CRC) a subi des perturbations. le code de Hamming est un code correcteur d'erreurs bas sur la notion de distance de Hamming. Soit un alphabet compos de 4 caract res (00,01,10,11). Si une erreur se produit alors le caract re mis est transform en un autre caract re et il n'y a pas moyen de retrouver le caract re original. Par contre, en ajoutant de l'information de telle sorte que les caract res soient tr s di rents les uns des autres cela devient possible. Par exemple, on peut coder les 4 caract res de la mani re
r r i E x T x G x T x G x

caract re initial caract re mis caract res erron s possibles
Tab.

00 00000 00001 00010 00100 01000 10000

01 01111 01110 01101 01011 00111 11111

10 10110 10111 10100 10010 11110 00110

11 11001 11000 11011 11101 10001 01001

1.1 - Codage de Hamming.

illustr e dans la table 1.1. Ainsi si un bit (parmi les 5 mis) est erron on sait quand m me d terminer quel caract re a t mis, car comme on peut le voir dans la table 1.1 la modi cation d'un bit ne peut pas faire passer d'un caract re initial l'autre. On a des ensembles d'erreurs possibles totalement disjoints. Par contre la modi cation de 2 bits dans cet exemple peut amener des confusions et l'impossibilit de corriger les erreurs. Soit x et y deux caract res d'un alphabet A et soit N la longueur du codage des mots de cet alphabet, x et y d signent respectivement le ie bit de x et y. On peut alors d nir la distance d(x y) = P (x ; y ) mod 2 qui permet de compter le nombre de bits qui di rent entre x et =1 y. On d nit alors la distance de Hamming par d = ( )2A2 6= d(x y) . Dans l'exemple choisi inf ci-dessus, d = 1 dans le premier codage sur 2 bits et d = 3 dans le codage sur 5 bits. Chaque erreur sur un bit d'un caract re x donne un caract re x0 tel que d(x x0 ) = 1, donc pour pouvoir d tecter et corriger une seule erreur il faut que d 3 et pour corriger 2 erreurs il faut que d 5. D'une mani re g n rale on d tecte et corrige n erreurs quand la distance de Hamming est 2n + 1. On peut voir ceci dans la gure 1.14 o sont repr sent s x et y (2 caract res parmi les plus 0 proches de l'alphabet), x et y des d formations de x et y apr s une erreur et x01 et y1 des d formations apr s deux erreurs. Ainsi, quand on re oit un caract re x (erron ou non on ne peut pas le savoir l'avance) il su t de chercher le caract re c 2 A le plus proche de x selon la distance d pour obtenir le caract re mis. Un exemple de code de Hamming est donn par la technique suivante o l'on veut envoyer des caract res cod s sur 4 bits de donn es ABCD. Pour cela on va mettre la suite ABCP2 DP1 P0
i i N i i i H x y H x y H h h i i

15

d

H

=3
x

d

H =5

x

r6 r@ -r -r R @r
x2 x3 x1 x3

6 r -r @ R @r
x2

r

x1

r r

y1

;;-r r
y

r

y3

y2

x

0

1

y

1

0

r

y1

r ;; r r
y3 y

y2

Fig.

1.14 - Distance de Hamming.
i

dans laquelle les bits de contr le P sont plac s sur les bits de rang 2 et sont d nis par
i

8 >P = A C D < >P = A B D :P = A B C
0 1 2
i

Les P sont des bits de parit d nis l'aide des bits de donn es de rang k tels que la d composition de k en somme de puissances de 2 contienne 2 . Par exemple, A est un bit de donn e de rang 7 = 20 + 21 + 22 donc A sert au calcul de P0 , P1 et P2 . De m me, le rang de D est 3 = 20 + 21 donc il sert au calcul de P0 et P1 . la r ception on calcule 8 0 > P0 = P0 A C D < 0 >P = P A B D : P10 = P1 A B C 2 2 si on obtient P20 = P10 = P00 = 0 alors c'est que la transmission s'est pass e sans probl me. Sinon, la valeur binaire de P20 P10 P00 donne la place de l'erreur dans les bits re us (en commen ant par la droite). On corrige alors l'erreur et on recalcule les P 0 , s'ils sont devenus tous nuls l'erreur a t corrig e, sinon il y avait eu au moins deux erreurs et on peut rejeter la suite de bits mais pas la corriger. Par exemple, si l'on veut envoyer les 4 bits 0010, on va nalement mettre 0011001. Si l'on re oit 0 0 0 0010001, on trouve P2 P1 P0 = 100 c'est- -dire 4, donc l'erreur tait en 4e place. On corrige, pour obtenir 0011001 et un nouveau calcul donne P20 = P10 = P00 = 0 assurant que l'on a corrig l'erreur. On peut remarquer qu'en fait on a corrig une erreur qui n' tait pas sur les donn es initiales mais sur les bits de parit rajout s.
i i

1.4.2 Protocoles de liaison de donn es.
Le r le d'un protocole de liaison de donn es est videmment de xer comment doivent tre r alis es les di rentes t ches qui incombent la couche 2 du mod le OSI. Deux grandes familles de telles proc dures sont employ es. Les proc dures orient es caract res (BSC de chez IBM) sont assez anciennes et sont utilis es pour des communications l'alternat sur le principe send and wait. Les proc dures orient es bits (HDLC) sont pr vues pour des transmissions full-duplex et haut d bits. le protocole BSC (Binary Synchronous Communications) est bas sur la transmission de blocs de caract res repr sent s principalement en ASCII (7 bits) ou EBCDIC (8 bits de chez IBM) avec acquittement l'alternat. Il utilise la fois des messages d'information pour transporter les donn es et des messages de service pour superviser ces changes. 16

metteur

XXXData 1 XXXXX z ACK 9X Data 2 X XXX XXX erreur z NACK 9X Data 2 bis X XXX XXX z ACK 9

r cepteur

Fig.

1.15 - Dialogue de type send and wait.

Les erreurs sont donc d tect es et corrig es par demande de r p tition comme illustr dans la gure 1.15. La gestion des changes se fait gr ce l'ensemble de caract res de commandes de la table 1.2.
SYN ENQ SOH STX ETB ETX ACK NACK DLE EOT

synchronous idle

utilis pour la synchronisation caract re et mis en d but de s quence de caract res enquiry invite une station mettre ou recevoir start of heading d but d'en-t te start of text n d'en-t te et d but de texte end of transmission block n de bloc de donn es end of text n du texte et d but des caract res de contr le n cessaires la d tection des erreurs acknowledgement accus de r ception positif negative acknowledgement accus de r ception n gatif data link escape caract re d' chappement de transmission end of transmission n d'un transfert de donn es
Tab.

1.2 - Caract res de commande BSC.

D'autres caract res sp ci ques ont t ajout s par des constructeurs mais ils ne sont pas d taill s ici. Le r le du caract re DLE est primordial car il permet d'obtenir une transmission transparente au code. En e et, si les donn es peuvent contenir des caract res de commande des confusions deviennent possibles. Pour viter cela, tous les caract res de commande sont pr c d s de DLE lorsque l'alphabet est tel que les codes de commande sont susceptibles d'appara tre dans les donn es transmises. De plus, si l'on doit transmettre dans les donn es le caract re DLE lui-m me, il sera alors lui-m me pr c d de DLE de mani re ce que le caract re qui le suit ne soit pas pris tort pour une commande. Les messages (donn es de taille quelconques ) mis selon le protocole BSC sont mis sous forme de blocs de taille appropri e aux possibilit s de la ligne. Ainsi un message constitu d'une en-t te 17

et d'un texte de donn es, le tout ne constituant qu'un seul bloc sera mis de la mani re suivante 9
SYN SYN SYN SYN SOH

...en-t te... STX ...texte... ETX

BCC EOT

BCC (Block Check Character) est en fait un ensemble de caract res de contr le pour d tecter les erreurs de transmission. Pour l'EBCDIC et l'ASCII en mode transparent le BCC est le polyn me de la norme V41 pr sent dans la section 1.4.1 le protocole HDLC (High level Data Link control) est un protocole orient bit et d nit un ensemble de proc dures normalis es par l'ISO pour des communications, aussi bien point point que multipoint, half ou full-duplex, mais toujours entre une machine primaire et une (ou plusieurs) machine(s) secondaires. Les di rents modes sont les suivants : le mode ABM (Asynchronous Balanced Mode) est un mode de r ponse asynchrone quilibr utilis sur une liaison full-duplex entre 2 machines uniquement (liaison point point) qui ont chacune le statut de primaire et de secondaire. Le secondaire peut mettre sans avoir re u de permission du primaire. le mode NRM (Normal Response Mode) est utilis sur une liaison half duplex et ici le secondaire ne peut transmettre que sur invitation du primaire. le mode ARM (Asynchronous Response Mode, connu galement sous le nom LAP) est utilis sur une liaison half duplex galement, mais le secondaire peut mettre sans que le primaire l'ait sollicit . Ceci peut alors provoquer des probl mes si primaire et secondaire veulent simultan ment mettre des donn es. Les trames chang es ont l'allure suivante fanion adresse commande

...donn es... contr

le

Le fanion est gal 01111110 et pour que la transparence au code soit possible, c'est- -dire pour que la pr sence d'une suite de 6 bits 1 dans les donn es ne soit pas interpr t e comme un fanion, l' metteur ins re un 0 apr s chaque suite de 5 1. Le r cepteur supprime ce 0 suppl mentaire apr s 5 1 cons cutifs de mani re restaurer le caract re r ellement mis. Il existe trois types de trame distingu s par les 2 premiers bits du champ de commande. Les trames d'information contiennent des donn es en provenance, ou destination, des couches sup rieures. Les trames de supervision assurent le contr le d'erreur et de ux. Les trames non num rot es servent l'initialisation de la liaison et aux probl mes de reprise sur erreur non r gl s la couche 2. Le contr le est assur par la technique du polyn me g n rateur de la norme V41 (cf section 1.4.1).

1.5 La couche r seau.
vices entre entit de r seau, savoir : l'adressage, le routage, le contr le de ux et la d tection et correction d'erreurs non r gl es par la couche 2. ce niveau l de l'architecture OSI il s'agit de faire transiter une information compl te (un chier par exemple) d'une machine une autre travers un r seau de plusieurs ordinateurs. Il existe deux grandes possibilit s pour tablir un protocole de niveau r seau : le mode avec connexion et le mode sans connexion d j pr sent s dans 1.1. Le premier cas est celui adopt dans la norme X25.3 (composante de la norme X25 du CCITT, galement norme ISO 8208 et quasi standard international des ann es 80, utilis dans le r seau fran ais TRANSPAC) et d crit partiellement ci-apr s et le second est celui du protocole IP du r seau Internet d crit dans la section 2.5.
9 On se place dans le cas o le caract re DLE n'est pas n cessaire et de plus quelques d tails sur la synchronisation sont omis
:

D nition 1.5.1 La couche r seau assure toutes les fonctionnalit s de relai et d'am lioration de ser-

18

1.5.1 Le contr le de ux.
Le contr le de ux consiste g rer les paquets pour qu'ils transitent le plus rapidement possible entre l' metteur et le r cepteur. Il cherche viter les probl mes de congestion du r seau qui surviennent lorsque trop de messages y circulent. On peut citer les quelques m thodes suivantes : Dans le contr le par cr dits, seuls N paquets sont autoris s circuler simultan ment sur le r seau, donc un paquet ne peut entrer dans le r seau qu'apr s avoir acquis un jeton qu'il relache lorsqu'il arrive destination. Dans la m thode isarythmique tous les jetons sont banalis s et la di cult r side dans leur distribution correcte aux bonnes portes du r seau pour assurer un fonctionnement optimal. Cette technique est am lior e en xant des jetons d di s par n ud d'entr e dans le r seau. Chaque n ud g re avec ses jetons une le d'attente des paquets qu'il met. Quand un paquet arrive destination, le r cepteur renvoie l' metteur le jeton correspondant au paquet re u. Dans le cadre d'un circuit virtuel tabli pour le mode avec connexion des r seaux X25 on utilise un m canisme de fen tre. Les paquets de donn es sont num rot s modulo 8 et contiennent deux compteurs : P (S ) un compteur de paquets mis et P (R) un compteur de paquets re us. L' metteur n'est autoris mettre que les paquets inclus dans la fen tre, c'est- -dire les paquets dont le compteur de paquet mis est tel que

dernierP (R)re u P (S )courant dernierP (R)re u + W
o W est la taille de la fen tre d' mission. De son c t le r cepteur renvoie l' metteur le compteur de paquets re us P (R) en l'incr mentant du nombre de paquets re us correctement et en s quence. Le gestionnaire du r seau peut tr s bien ne pas renvoyer imm diatement les acquittements s'il d sire d charger momentan ment le r seau. Par exemple, si le dernier paquet P (R) re u est gal 1 et que la fen tre W = 4 cela signi e que le paquet 0 a bien t re u et que l' metteur peut envoyer les paquets 1, 2, 3 et 4.

7 6 5

0 '$ 1 3 &% 4 2

0 '$ 1 H 7 6

H HH 2 HH 5 3 &%
4

Position initiale de la fen tre
Fig.

Position nale de la fen tre

1.16 - Contr le de ux par fen tre.

Si l' metteur a d j exp di les paquets 1, 2 et 3 et qu'il re oit un compteur de paquets re u P (R) = 2 il d place sa fen tre d' mission de deux positions comme illustr dans la gure 1.16 et peut exp dier les paquets suivants. Malgr tous les e orts pour contr ler le ux d'information dans un r seau celui-ci peut se retrouver face un probl me de congestion. Il s'agit alors de r soudre le probl me sans l'aggraver. En e et, les 19

1.5.2 Le probl me de la congestion.

probl mes de congestion arrivent lorsque les n uds d'un r seau saturent leurs les d'attente et donc perdent des paquets. Si ces paquets sont r exp di s ou si des messages de gestion de r seau se mettent circuler en grand nombre les performances du r seau vont s' crouler tr s vite. On essaye d' viter le probl me de la congestion en autorisant un paquet ne rester dans le r seau qu'un temps limit par un temps maximal x par le gestionnaire du r seau. Tout paquet est donc mis avec une date x e par une horloge commune au r seau, si un n ud s'aper oit que le temps de pr sence dans le r seau d'un paquet est d pass il le d truit. Cela permet ainsi de d truire les paquets perdus par erreur d'adressage ou de routage, ainsi que ceux bloqu s dans un n ud. Mais cette m thode bas e sur une horloge est assez di cile mettre en uvre et on utilise souvent une m thode plus simple consistant m moriser simplement dans la zone de temps un nombre d cr ment chaque travers e de n ud. Lorsque ce nombre atteint la valeur 0 il est d truit.

1.5.3 Le routage.
Le routage des paquets dans un r seau maill consiste xer par quelle ligne de sortie chaque commutateur r exp die les paquets qu'il re oit. Ceci se fait en fonction de la destination nale du paquet et selon une table de routage qui indique pour chaque destination nale quelles sont les voies de sortie possible. Pour l'exemple de la gure 1.17 on pourrait avoir la table de routage suivante :
destination nale D1 D2 D3 D4 voie de sortie A1, A2 A2 A2, A3 A3

les d'attente en sortie voies de sortie A1 le d'attente en entr e

-

-

D1 D2 D3 D4

-

m

n ud de commutation

JJ

J J ^

A2

A3
Fig.

1.17 - Routage de paquets.

D'une mani re g n rale le routage est un ensemble de processus algorithmiques devant prendre des d cisions dispers s dans le temps et dans l'espace. Les di rents algorithmes sont r partis sur chaque n ud du r seau et l'ensemble peut fonctionner de mani re centralis e ou r partie. Le routage centralis est g r par un n ud particulier du r seau qui re oit des informations de chacun des n uds du r seau et leur envoie leur table de routage. Pour xer ces tables on prend en compte notamment le co t des liaisons, le co t de passage dans un n ud, le d bit demand , le nombre de n uds traverser, la s curit de transport de certains paquets, l'occupation des m moires des n uds de commutation,... Le plus souvent un algorithme de plus court chemin donne de bons r sultats en xant 1 le co t de franchissement d'un n ud (on peut galement 20

pond rer plus fortement les n uds qui sont les plus occup s). La mise jour des tables de routage peut se faire de mani re
xe : en fait il n'y a pas de mise jour, la table de routage est x e une fois pour toute en fonction de la topologie du r seau. synchrone : toutes les tables sont mises jour au m me moment par le centre de contr le qui re oit des informations de la part de tous les n uds intervalles r guliers (toutes les 10 sec par exemple). asynchrone : les tables sont mises jour ind pendamment les unes des autres dans certaines parties du r seau, chaque n ud envoyant un compte-rendu de son tat au centre de contr le lorsqu'il observe des changements signi catifs.

Mais le routage centralis dans un r seau grande chelle est peu performant, car un routage est d'autant meilleur qu'il r agit rapidement aux informations qui lui parviennent. De plus, si une panne survient dans l'ordinateur qui assure ce contr le, c'est tout le r seau qui tombe en panne. Le routage d centralis ne poss de pas de centre de contr le et les r gles de passage d'un paquet (paquet d'appel pour tablissement d'un circuit virtuel) sont : l'inondation : la r ception d'un paquet celui-ci est renvoy sur toutes les lignes de sortie. Cette technique simpliste et rapide est e cace dans les r seaux tra c faible et o le temps r l est n cessaire mais elle est p nalisante en ux de donn es, inadapt e aux r seaux complexe et au circuit virtuel. la technique hot patatoes : un paquet re u est renvoy le plus t t possible par la premi re ligne de sortie vide. On am liore ce principe en a ectant des coe cients chaque ligne de sortie en fonction de la destination voulue. On tient compte de l' tat des n uds voisins, sans utiliser de paquet de contr le, mais simplement en comptabilisant le nombre de paquets re us de chacun d'eux. Ils peuvent galement envoyer de mani re synchrone ou asynchrone un compte-rendu de leur tat, permettant ainsi de choisir la meilleure ligne un instant donn . Mais ceci reste local et une panne du r seau localis e au-del du premier n ud voisin ne pourra pas tre prise en compte. le routage adaptatif la fois dans l'espace et dans le temps demande, de la part de chaque n ud, une connaissance compl te du r seau. Les di rents n uds s' changent donc des messages, mais si chacun envoie des messages tous les autres le tra c va augmenter de mani re baucoup trop grande. C'est pourquoi un n ud ne transmet un compte-rendu qu' ses voisins imm diats qui doivent en tenir compte dans leur propre compte-rendu. (voir exemple) D'une mani re g n rale, le routage doit viter l'usage d'algorithmes adaptatifs trop complexes et limiter les dialogues de services entre les n uds sinon l'e et obtenu sera l'oppos de celui recherch .

1.5.4 La norme X25, niveau r seau.
Cette norme a t tablie en 1976 par le CCITT pour les r seaux commutation de paquets sur proposition de 4 pays qui l'utilisent pour leurs r seaux publics de communication : Transpac pour la France, EPSS pour la Grande-Bretagne, Datapac pour le Canada et Telenet pour les USA. Comme illustr dans la gure 1.18 le protocole X25 contient les trois premi res couches du mod le OSI et d nit l'interface entre un ETTD ( quipement Terminal de Traitement de Donn es) et un ETCD ( quipement de Terminaison de Circuit de Donn es) pour la transmission de paquets. Elle xe donc les r gles de fonctionnement entre un quipement informatique connect un r seau et le r seau lui-m me. 21

ETTD couche 3 couche 2 couche 1 modem modem

ETCD couche 1 couche 2 couche 3

par exemple V24 LAPB : sous-ensemble de HDLC X25 niveau r seau
Fig.

-

-

-

1.18 - Niveaux du protocole X25.

X25 d nit les types de paquets et leur format est le suivant (chaque ligne correspond un octet 10 ) 8 7 6 5 4 3 2 1 identi cateur g n ral de format num ro de groupe de voie logique num ro de voie logique identi cateur g n ral de type de paquet donn es X25 utilise le mode avec connexion, sachant que la connexion est r alis e l'aide d'un circuit virtuel dont le fonctionnement se d roule comme illustr dans la gure 1.19. L' tablissement du circuit virtuel se fait de bout en bout par l'envoi d'un paquet d'appel (call request). Il existe des circuits virtuels permanents (CVP) ou commut s (CVC). un instant donn , plusieurs CVC et CVP peuvent coexister. Chaque circuit virtuel utilise une voie logique rep r e par un num ro de groupe logique (entre 0 et 16) et un num ro de voie (entre 0 et 255). Ainsi, 4095 (la voie 0 est r serv e) voies sont utilisables par une entr e. Pour un CVC les deux num ros sont attribu s pendant la phase d' tablissement de la communication, pour un CVP ils le sont lors de l'abonnement. Lorsque le paquet d'appel arrive l'ETCD destinataire, celui-ci peut refuser la connexion en envoyant une demande de lib ration (clear request) ou l'accepter en envoyant un paquet de communication accept e (call accepted). ce moment-l le circuit virtuel est tabli et les donn es peuvent tre chang es, celles-ci emprunteront alors toutes le m me chemin marqu travers le r seau par le paquet d'appel. Pour leur part la demande et la con rmation de lib ration sont trait es localement et la demande peut tre trait e par n'importe lequel des deux quipements.

1.6 La couche transport.
D nition 1.6.1 La couche transport assure un transfert de donn es transparents entre entit s de
session et en les d chargeant des d tails d'ex cution. Elle a pour r le d'optimiser l'utilisation des services de r seau disponibles a n d'assurer au moindre co t les performances requises par la couche session.

C'est la premi re couche r sider sur les syst mes d'extr mit . Elle permet aux deux applications de chaque extr mit de dialoguer directement ind pendamment de la nature des sous-r seaux travers s et comme si le r seau n'existait pas. Au niveau inf rieur de la couche r seau seule la phase d' tablissement de la liaison logique s'e ectue de bout en bout, alors que les transferts d'information se font de proche en proche.
10: Le

troisi me octet contient les compteurs P(S) et P(R) d crits dans la section 1.5.1.

22

ETTD local

Paquet 6 - d'appel

ETCD local

ETCD distant ETTD distant

Ouverture d'un circuit virtuel

Appel entrant

? Communication 6
Transfert de donn es Donn es

Communication accept e tablie

Ouverture 6 d'un circuit ? virtuel 6

-

Donn es

Transfert de donn es Lib ration

Lib ration

Demande ? - de lib ration 6 ? rmation de lib ration Con

? 6 ? Con rmation de lib ration
Indication de lib ration

Fig.

1.19 - Vie d'un circuit virtuel.

La couche transport doit assurer, en mode connect ou non connect , un transfert transparent de donn es entre utilisateurs de service r seau en leur rendant invisible la fa on dont les ressources de communication sont mises en uvre. Cette notion de transparence implique par exemple de pouvoir acheminer de bout en bout des TPDU (Transport Protocol Data Unit) dont la taille peut varier de 128 8192 octets. Cette taille est cependant xe une fois que la valeur a t n goci e.

1.6.1 Qualit de service.
Une autre fa on de d nir la couche transport est de la consid rer garante de la qualit de service (QOS) rendue par la couche r seau. Si cette derni re est sans faille, alors le travail de la couche transport est minime. Dans le cas contraire elle assure la jonction entre ce que d sire l'utilisateur et ce que la couche r seau met disposition en terme de qualit . La qualit est valu e sur certains param tres avec trois types de valeurs possibles : pr f r , acceptable et inacceptable qui sont choisis lors de l' tablissement d'une connexion (certains param tres sont cependant disponibles pour un mode sans connexion). La couche transport surveille alors ces param tres pour d terminer si la couche r seau sous-jacente assure la qualit de service demand e. Les di rents param tres de la qualit de service sont : le temps d' tablissement de la connexion transport : c'est la dur e qui s' coule entre le moment o une demande de connexion est mise et le moment o la con rmation de cet tablissement est re u et plus ce d lai est court meilleure est la qualit de service. la probabilit d' chec d' tablissement mesure la chance (ou plut t malchance) qu'une connexion ne puisse s' tablir dans un d lai maximum d ni. On ne tient pas compte ici du refus de l'entit 23

distante d' tablir cette connexion, mais on consid re plut t les probl mes d'engorgement de r seau. le d bit de la liaison mesure le nombre d'octets utiles qui peuvent tre transf r s en une seconde, ce d bit est valu s par ment dans les deux sens. le temps de transit mesure le temps coul entre le moment o l'utilisateur du service de transport envoie un message et celui o l'entit de transport r ceptrice le re oit, ce temps est valu s par ment dans les deux sens. le taux d'erreur r siduel est le rapport entre le nombre de messages perdus ou mal transmis et le nombre total de messages mis au cours d'une p riode consid r e. Ce nombre, en th orie nul, a une valeur faible. la probabilit d'incident de transfert mesure le bon fonctionnement du service transport. Lorsqu'une connexion est tablie, un d bit, un temps de transit, un taux r siduel d'erreurs sont n goci s. La probabilit d'incident mesure la fraction de temps durant laquelle les valeurs x es pr c demment n'ont pas t respect es. le temps de d connexion mesure la dur e s' coulant entre une demande de d connexion mise et la d connexion e ective du syst me distant. la probabilit d'erreur de d connexion est le taux de demandes de d connexion non ex cut es pendant le temps maximum d ni. la protection est d nie comme la possibilit de se pr munir contre les intrusions passives (interf rences sur une m me ligne) et actives ( coute et modi cation des donn es transmises). La priorit permet l'utilisateur de privil gier certaines transmissions par rapport d'autres. La r siliation est la libert laiss e la couche transport de d cider elle-m me de la d connexion suite un probl me. En mode non connect , ces param tres indiquent uniquement les souhaits de l'utilisateur en ce qui concerne le d bit, le d lai de transit, le taux d'erreur r siduel et la priorit d'une transmission. Ces param tres sont utilis es apr la couche transport pour xer des options de protocoles avant d' tre soumis la couche r seau. Lorsqu'une connexion est demand e, tous ces param tres sont transmis par l'utilisateur la couche transport, les valeurs d sir es et minimales sont sp ci es. Les di rents cas de gure et tapes peuvent alors se pr senter. Si la demande semble irr aliste pour certains param tres alors la demande de connexion n'est m me pas ex cut e et un message d'erreur est renvoy pour expliquer le probl me. Si la demande ne peut pas tre satisfaite compl tement mais partiellement (par exemple avec un d bit moindre mais acceptable), alors c'est cette demande avec des objectifs moindres qui est soumise. Si l'ordinateur distant ne peut satisfaire compl tement la demande, mais reste au-dessus du minimum requis, alors il modi e aussi le param tre. S'il ne peut pas rester au-dessus de ce minimum, il rejette la demande de connexion. En n, la couche transport avertit son utilisateur de la bonne n (ou non) de la proc dure de connexion et lui transmet les param tres accept s. Cette proc dure s'appelle la n gociation des options qui, une fois x es, restent inchang es pendant toute la connexion. Pour que tous les utilisateurs ne demandent pas une qualit de service optimale, les prix pratiqu s par les fournisseurs de r seaux croissent avec cette qualit de service. 24

1.6.2 Primitives du service transport.
entité de session requète machine de transport confirmation protocole de transport réponse machine de transport entité de session indication

Fig.

1.20 - Dialogue de niveau transport.

Les services qu'o rent la couche transport en mode connect sont rendues par les primitives donn es ci-dessous. Celles-ci se d composent comme dans tout dialogue entre couches en quatre cat gories comme illustr dans la gure 1.20. phase d' tablissement de la connexion
T_CONNECT.request(adresse source, adresse distante, donn es_expr s, qos, donn es_utilisateur) pour demander une connexion T_CONNECT.indication(adresse source, adresse distante, donn es_expr s, qos, donn es_utilisateur) pour indiquer une connexion de transport T_CONNECT.response(adresse source, adresse distante, donn es_expr s, donn es_utilisateur) pour r pondre une demande de connexion de transport T_CONNECT.confirm(adresse source, adresse distante, donn es_expr s, qos, donn es_utilisateur) pour con rmer l' tablissement d'une connexion de transport

phase de transfert de donn es pour demander le transfert de donn es T_DATA.indication(donn es_utilisateur) pour indiquer un transfert de donn es T_EXPEDITED_DATA.request(donn es_utilisateur) pour demander le transfert de donn es expr s
T_DATA.request(donn es_utilisateur) T_EXPEDITED_DATA.indication(donn es_utilisateur)

pour indiquer un transfert de donn es expr s phase de lib ration de la connexion

T_DISCONNECT.request(donn es utilisateur)

port

pour demander une d connexion de transconnexion

T_DISCONNECT.indication(raison, donn es_utilisateur) pour indiquer une d

de transport

La gure 1.21 d taille les di rents encha nements de primitives possibles. Pour chaque cas, un utilisateur est plac gauche des lignes doubles et son homologue est droite, la couche transport est entre les lignes et le temps s' coule de haut en bas. 25

T_CONNECT request

HH j H

T_CONNECT request

HH j H

T_CONNECT indication

HH j H

T_CONNECT request

HH j H

T_CONNECT indication T_DISCONNECT request

HH j H

T_CONNECT response T_CONNECT confirm T_DISCONNECT indication

T_DISCONNECT indication

tablissement d'une connexion
T_DATA request

rejet par un utilisateur d'une demande de connexion

rejet par le fournisseur d'une demande de connexion

HH j H

T_EXPEDITED_DATA request

HH j H

T_DATA indication

HH j H

HH j H

T_EXPEDITED_DATA indication

transfert de donn es normales
T_DISCONNECT request

transfert de donn es expr s
T_DISCONNECT request

HH j H

lib ration sur initiative d'un utilisateur

HH j H

T_DISCONNECT indication

HH j H

T_DISCONNECT request

lib ration sur initiative des deux utilisateurs

T_DISCONNECT indication

HH j H

T_DISCONNECT indication

lib ration provoqu e par le fournisseur
Fig.

1.21 - Encha nements de primitives en mode connect .

Seules les successions de primitives d crites dans l'automate de la gure 1.22 sont autoris s assurant ainsi qu'une machine r alisant le service de transport ne peut se trouver que dans l'un des quatre tats repr sent s savoir
veille : aucune connexion n'est tablie, une demande de connexion peut tre mise ou re ue connexion sortante en attente : la machine a demand une connexion et la r ponse de l'autre extr mit n'est pas encore arriv e connexion entrante en attente : la machine a re u une demande de connexion qu'elle n'a pas encore accept e ou rejet e. transfert de donn es pr t : une connexion a t tablie, les transferts de donn es peuvent commencer

Pour ce qui est du mode non connect seules les primitives suivantes sont disponibles.
T_UNIDATA.request(appel , appelant, qos, donn es utilisateur)

26

repos pas de connexion en cours T_DISCONNECT.indication T_DISCONNECT.indication T_DISCONNECT.request T_DISCONNECT.request

T_CONNECT.request

T_CONNECT.indication

connexion sortante en attente

T_DISCONNECT.indication T_DISCONNECT.request

connexion entrante en attente

T_CONNECT.confirm transfert de données

T_CONNECT.response

T_DATA.request T_EXPEDITED_DATA.request

T_EXPEDITED_DATA.indication T_DATA.indication

Fig.

1.22 - Diagramme d' tats d'une machine de service de transport.

T_UNIDATA.indication(appel , appelant, qos, donn es utilisateur)

1.6.3 Le protocole de transport ISO en mode connect (ISO 8073 ou X.224)
Les fonctions de la couche transport ISO sont tablies dans le but de combler l' cart existant entre les services o erts par les couches basses et les services o rir. Les principales fonctions r alis es pendant l' tablissement de la connexion sont les suivantes. La s lection d'une connexion r seau appropri e. La d cision de mettre en place un multiplexage ou un clatement. Le multiplexage a pour but de regrouper plusieurs connexions de transport sur une m me connexion de r seau, ce qui va permettre de minimiser les ressources utilis es au niveau r seau, donc de diminuer les co ts de communication. Ceci est surtout utile si l'on a de nombreuses connexions de faible d bit tablir. l'inverse, l' clatement consiste r partir une connexion de transport simultan ment sur plusieurs connexions r seau dans le but d'accro tre le d bit et la abilit (voir la gure 1.23). la d termination de la taille optimale des TPDU la mise en relation des adresses transport et r seau l'identi cation de la connexion 27

A

B

C

3

2

1

éclatement de la connexion C3 multiplexage des connexions A1 et B2 CV3 CV1 CV2

adresses de transport adressesde réseau

CV4

Fig.

1.23 - Adressage, multiplexage et clatement de connexions transport.

Lors de la phase de transfert les donn es expr s (interruptions, alarmes de petite taille) ne sont pas soumises au contr le de ux et sont assur es d' tre d livr es avant toutes donn es normales mises apr s elle. La fragmentation-r assemblage permet, si n cessaire, de d couper des TSDU (Transport Service Data Unit) a n de tenir dans un seul TPDU. Ainsi les lettres trop grandes sont d coup es en fragments de taille xe (sauf ventuellement le dernier), num rot s et exp di s chacun dans un paquet pour tre r assembl s l'arriv e. La num rotation des paquets permet galement de d tecter les paquets perdus ou dupliqu s. Les erreurs de transmission tant normalement d tect es par les couches inf rieures, il n'est pas toujours n cessaire de prot ger chaque TPDU. Cependant, si la qualit de service r seau est m diocre, on ajoute des m canismes de d tection d'erreur par total de contr le associ un m canisme de retransmission. Le contr le de ux est fond sur une fen tre coulissante de taille variable, similaire une notion de cr dit. Le destinataire impose la cadence de transfert en indiquant l'exp diteur des cr dits d' mission (num ro dans la s quence ne pas d passer) qu'il lui transmet dans ses acquittements. En n, la lib ration de la connexion de transport peut tre d cid e et d clench e de mani re inconditionnelle par l'un quelconque des correspondants, ce qui peut provoquer des pertes de donn es. Cette lib ration est explicite quand il y a changes d'unit s de donn es sp ciales ou implicite quand en fait c'est la connexion r seau sous-jacente qui est lib r e. Pour simpli er le choix des fonctions mettre en uvre, l'ISO a d ni 5 classes de protocoles chacune tant adapt e un type de r seau particulier 11 et choisi lors de l' tablissement de la connexion. L'appelant d clare sa classe pr f r e et des classes de repli, l'appel choisi parmi ces propositions si aucune classe ne lui convient il refuse la connexion. Succinctement, on trouve la classe 0 : elle assure une connexion standard pour les r seaux de type A ( tablissement n goci e de la connexion, lib ration implicite, transfert de donn es normales, segmentation et r assemblage des donn es. la classe 1 : pour les r seaux de type B elle ajoute la classe 0 le transport de donn es expr s, la reprise sur erreurs signal es, la d connexion et la reprise sur r initialisation du r seau.
11: Les

r seaux sont r parties en 3 classes : - type A : peu d'erreurs signal es et non signal es - type B : peu d'erreurs non signal es, mais trop d'erreurs signal es - type C : trop d'erreurs des deux types.

28

la classe 2 : pour les r seaux de type A elle ajoute la classe 0 le multiplexage et un contr le de ux am lior . la classe 3 : pour les r seaux de type B elle est constitu e des fonctionnalit s des classes 1 et 2. la classe 4 : pour les r seaux de type C elle correspond la classe 3 laquelle on ajoute la d tection et la reprise d'erreurs non signal es et l' clatement de connexions de transport.

1.7 Les couches hautes : session, pr sentation et application.
Les couches session, pr sentation et application constituent les couches hautes du mod le OSI et o rent des services orient s vers les utilisateurs alors que les couches basses sont concern es pas la communication able de bout en bout. Elles consid rent que la couche transport fournit un canal able de communication et ajoutent des caract ristiques suppl mentaires pour les applications.

D nition 1.7.1 La couche session fournit aux entit s de la couche pr sentation les moyens d'organiser et synchroniser les dialogues et les changes de donn es.
Une session peut par exemple tre utilis e pour la connexion distance d'un terminal un ordinateur ou pour le transfert d'un chier et ceci en mode connect . Bien que tr s similaires la session et la
session

1.7.1 La couche session.

transport a) b)

c)

Fig.

1.24 - Sessions et connexions de transport.

connexion de transport ne sont pas identiques, les trois cas de la gure 1.24 peuvent se pr senter. a) Il y a correspondance exacte entre une session et une connexion de transport. b) Plusieurs sessions successives sont tablies sur une seule et m me connexion de transport. Par exemple, ceci peut tre utilis dans le contexte d'une agence de voyage dans laquelle chaque employ utilise un terminal reli un ordinateur local. Celui-ci est reli une base de donn es centrale de la compagnie pour enregistrer les r servations. Chaque fois qu'un employ veut faire une r servation, une session est ouverte avec l'ordinateur central et elle est ferm e lorsque la r servation est termin e. Mais il est inutile de lib rer la connexion de transport sous-jacente car celle-ci sera utilis e quelques instants plus tard par un autre employ . c) Plusieurs connexions de transport successives sont n cessaires pour une seule et m me session. Ceci peut arriver lorsqu'une connexion de transport tombe en panne, la couche session tablit alors une nouvelle connexion de transport de mani re poursuivre la connexion commenc e. Par contre, il n'est pas possible de multiplexer plusieurs sessions sur une m me connexion de transport. Celle-ci ne transporte tout instant qu'au plus une session. Le transfert des donn es est r gi par les trois phases habituelles : tablissement de la session, transfert des donn es et lib ration de la session. Les primitives fournies par la couche session sont semblables celles fournies par la couche transport la couche session. L'ouverture d'une session 29

n cessite la n gociation de plusieurs param tres entre les utilisateurs des extr mit s, certains (qos et existence ou non de donn es expr s) sont identiques ceux de la couche transport qui ils sont pass s tels quels. Un autre param tre peut permettre de d cider quelle extr mit aura l'initiative du dialogue dans le cas d'une session bidirectionnelle. Les di rences entre transport et session vont se situer au niveau de la lib ration de la connexion. Dans le cas du transport, la primitive T_DISCONNECT.request provoque une lib ration brutale de la connexion avec perte des donn es en cours de transfert. Une session, elle, sera termin e par la primitive S_RELEASE.request qui op re une lib ration ordonn e de la connexion, sans perte de donn es, appel e terminaison n goci e. Les di rences entre ces deux modes
A B

A

B

S_DATA request

S_RELEASE. request

T_DATA request

T_DISCONNECT. request

S_RELEASE. indication S_RELEASE. response

S_DATA indication

T_DISCONNECT. indication a)

S_RELEASE. confirm b)

Fig.

1.25 - Lib ration brutale a) et ordonn e b).

de lib ration sont illustr es dans la gure 1.25. Dans le premier cas, B ne peut plus recevoir le message qui est en transit partir du moment o il a mis une demande de d connexion (voir l'automate de la gure 1.22). Dans le deuxi me cas, B continue d'accepter des donn es apr s avoir mis sa demande de lib ration jusqu' ce que A con rme positivement cette d connexion. Si A veut refuser la d connexion, il le signale par l'un des param tres de S_RELEASE.response et il peut ainsi continuer d'envoyer des donn es, la session se prolonge comme si de rien n' tait. Les sessions peuvent autoriser le dialogue bidirectionnel ou unidirectionnel ou l'alternat. Ce dernier cas n'est pas forc ment d des limitations mat rielles mais est souvent inh rent au fonctionnement des applications de plus haut niveau. Par exemple, l'acc s une base de donn es distante est tabli sur ce mode. Un utilisateur envoie depuis son terminal une requ te un ordinateur central, puis il attend la r ponse de celui-ci. Lorsque l'ordinateur central a envoy sa r ponse, l'utilisateur peut envoyer une autre requ te. Ainsi, le mode de fonctionnement l'alternat est naturel. Dans ce cas il s'agit alors de g rer qui c'est le tour d'envoyer des donn es. Ce service est mis en uvre gr ce un jeton de donn es (data token). Seule l'extr mit qui poss de le jeton peut envoyer des donn es, l'autre doit rester silencieuse. La n gociation initiale l' tablissement de la connexion de session xe quelle extr mit re oit en premier le jeton. Lorsque le possesseur du jeton a ni d'exp dier ses donn es il peut passer le jeton son correspondant l'aide de la primitive S_TOKEN_GIVE.request. Si l'extr mit qui ne poss de pas le jeton veut exp dier des donn es il peut le demander, poliment, l'aide de la primitive S_TOKEN_PLEASE.request. Le possesseur du jeton peut alors le lui envoyer ou lui refuser. La synchronisation est galement l'un des services de la couche session et consiste placer les entit s de session dans un tat connu des deux interlocuteurs en cas d'erreur. Il ne s'agit pas ici de r gler des erreurs qui seraient d es un probl me de transmission de donn es puisque la couche transport doit les r gler. Mais celle-ci ne peut e ectuer des reprises sur erreurs dues aux couches sup rieures puisqu'elle 30

n'en a pas connaissance. Par exemple, si lors d'un transfert de chiers tr s long une erreur se produit du c t du r cepteur mais en dehors de la transmission proprement dite (probl me d'acc s un disque par exemple), il faut que la couche session soit capable de s'en apercevoir et qu'elle vite de relancer simplement tout le transfert de chiers. C'est pourquoi, gr ce des points de synchronisation dans le ot d' changes de donn es, elle reprendra les transferts au niveau du dernier point de reprise correct. Ces points consistent d couper le ot de donn es transmettre en pages et videmment, le m canisme n cessite que l'utilisateur de la session metteur soit capable de m moriser su samment longtemps les pages envoy es pour pouvoir en r exp dier certaines si n cessaires.

1.7.2 La couche pr sentation.

D nition 1.7.2 La couche pr sentation s'occupe de la syntaxe et de la s mantique des informations
transport es en se chargeant notamment de la repr sentation des donn es.

Par exemple, sur un ordinateur base d'un processeur de la famille des 68 000 les entiers sont repr sent s avec les bits de poids fort gauche et ceux de poids faible droite. Or, c'est l'inverse sur un ordinateur bas sur un processeur de la famille du 80x86. Cette di cult sera prise en compte par la couche pr sentation qui e ectuera les op rations n cessaires la communication correcte entre ces deux familles de machines. Pour ce faire l'ISO a d ni une norme appel e syntaxe abstraite num ro 1 (Abstract Syntax Notation 1) permettant de d nir une sorte de langage commun (une syntaxe de transfert) dans lequel toutes les applications repr sentent leurs donn es avant de les transmettre. C'est aussi ce niveau de la couche pr sentation que peuvent tre implant es des techniques de compression (code de Hu man par exemple) et de chi rement de donn es (RSA, DSE, etc...) non d taill es ici (voir cours correspondants de licence).

1.7.3 La couche application.
- le transfert d'informations - l'allocation de ressources

D nition 1.7.3 La couche application donne au processus d'application le moyen d'acc der l'environnement OSI et fournit tous les services directement utilisables par l'application, savoir:

- l'int grit et la coh rence des donn es acc d es - la synchronisation des applications coop rantes

En fait, la couche application g re les programmes de l'utilisateur et d nit des standards pour que les di rents logiciels commercialis s adoptent les m mes principes, comme par exemple : - Notion de chier virtuel repr sent sous forme d'arbre pour les applications de transfert de chiers, op rations permises sur un chier, acc s concurrentiels, ... - D coupage des fonctions d'une application de courrier lectronique qui se compose d'un le contenu (en-t te et corps) et d'une enveloppe. Une fonctionnalit de l'application g re le contenu et une autre le transfert en interpr tant l'enveloppe.

31

Chapitre 2

Le r seau Internet et les protocoles TCP/IP.
Ces 15 derni res ann es ont vu merger de nouvelles techniques rendant possible l'interconnexion de r seaux di rents (internetworking ) en les faisant appara tre comme un unique environnement de communication homog ne. On d signe ce syst me d'interconnexion sous le nom d'internet, sachant que r seau Internet et Internet d signent l'ensemble de ces internets dont le point commun est de fonctionner en suivant les protocoles TCP/IP (Transmission Control Protocol/Internet Protocol ). Le but de ce chapitre est d' tudier comment fonctionne l'ensemble de ces protocoles.

2.1 Historique et organisation d'Internet.
Les travaux de l'ARPA (Advanced Research Project Agency ) d but rent au milieu des ann es 70 et avaient pour but de d velopper un r seau commutation de paquets pour relier ses centres de recherches dans le but de partager des quipements informatiques et changer des donn es et du courrier. Le but tait de concevoir un r seau r sistant des attaques militaires. Il ne fallait donc pas qu'il comporte de points n vralgiques dont la destruction aurait entra n l'arr t complet du r seau. C'est ainsi, que d s le d part le r seau ARPANET fut con u sans n ud particulier le dirigeant, et de telle sorte que si une voie de communication venait tre d truite, alors le r seau soit capable d'acheminer les informations par un autre chemin. C'est vers 1980 qu'est apparu le r seau Internet, tel qu'on le conna t maintenant, lorsque l'ARPA commen a faire voluer les ordinateurs de ses r seaux de recherche vers les nouveaux protocoles TCP/IP et qu'elle se mit subventionner l'universit de Berkeley pour qu'elle int gre TCP/IP son syst me d'exploitation Unix (BSD). Ainsi la quasi totalit des d partements d'informatique des universit s am ricaines put commencer se doter de r seaux locaux qui en quelques ann es seront interconnect s entre eux sous l'impulsion de la NSF (National Science Foundation ).2 M me si d s son origine Internet comprenait des soci t s priv es, celles-ci taient plus ou moins li es la recherche et au d veloppement, alors qu' l'heure actuelle les activit s commerciales s'y sont consid rablement multipli es, et ceci surtout depuis l'arriv e du web en 1993. La gure 2.1 (source ISOC, www.isoc.org) donne un r sum des grandes tapes de l' volution d'Internet au niveau mondial qui comportait en 1996 plus de 100 000 r seaux di rents permettant de regrouper presque 10 millions d'ordinateurs dans le monde. Mais les statistiques sont di ciles tablir et sont parfois fantaisistes ou biais es par des consid rations politiques ou commerciales. Une bonne source d'information est encore l'ISOC dont sont extraites les donn es de la gure 2.2. Pour ce qui est de la France, apr s des tentatives avort es de constitution d'un r seau de la recherche, puis l'apparition du r seau EARN (European Academic and Research Network ) bas sur des protocoles et des ordinateurs IBM, un d but de r seau b ti sur des ordinateurs Unix et TCP/IP apparu sous le nom de FNET. C'est la n des ann es 80 que les campus universitaires s' quip rent massivement de r seaux Ethernet et cr rent des r seaux r gionaux bas s sur TCP/IP. L'ouverture l'Internet 32

Fig.

2.1 - Les grandes dates d'Internet.

Fig.

2.2 - volution du nombre de machines connect es Internet

33

mondial ( l' poque presque exclusivement nord-am ricain) eut lieu en 1988 et ensuite la cr ation de Renater (R seau National de T l communications pour l'Enseignement et la Recherche ) en 1994 sont les grandes dates de l' volution d'Internet en France. Comme l'ensemble des protocoles TCP/IP n'est pas issu d'un constructeur unique, mais mane de la collaboration de milliers de personnes travers le monde, une structure de fonctionnement originale a t imagin e d s le d but. Apr s des volutions successives, c'est maintenant l'IAB (Internet Architecture Board ) qui est le comit charg de coordonner l'architecture, les orientations, la gestion et le fonctionnement d'Internet. L'IAB comporte deux branches principales : l'IETF (Internet Engineering Task Force, www.ietf.org) s'occupe des probl mes techniques court et moyen terme et est divis en 9 zones (applications, s curit , routage et adressage, etc...) chacune dot e d'un responsable. l'IRTF (Internet Research Task Force, www.irtf.org) coordonne les activit s de recherche relatives TCP/IP. Par ailleurs, il existe l'ISOC (The Internet Society ) qui est li e l'IAB et qui aide ceux qui souhaitent s'int grer la communaut d'Internet. De nombreux renseignements sur le fonctionnement et les organismes li s Internet sont disponibles sur le web de l'ISOC www.isoc.org. Aucun constructeur, ou diteur de logiciel, ne peut s'approprier la technique TCP/IP, les documentations techniques sont donc mises disposition de tous par l'INTERNIC (Internet Network Information Center partir de son site web ds.internic.net/ds/dspg1intdoc.html). Les documents relatifs aux travaux sur Internet, les nouvelles propositions de d nition ainsi que les modi cations de protocoles, tous les standards TCP/IP, y sont publi s sous la forme de RFC (Request For Comments, appels commentaires). Tous les RFC sont publi s par un membre de l'IAB et sont num rot s s quentiellement, une proposition de RFC s'appelle un Internet Draft qui sera discut , modi , et en n adopt ou rejet par les membres du domaine concern par la note technique.

2.2 Architecture des protocoles TCP/IP.
Les logiciels TCP/IP sont structur s en quatre couches de protocoles qui s'appuient sur une couche mat rielle comme illustr dans la gure 2.3. La couche de liens est l'interface avec le r seau et est constitu e d'un driver du syst me d'exploitation et d'une carte d'interface de l'ordinateur avec le r seau. La couche r seau ou couche IP (Internet Protocol ) g re la circulation des paquets travers le r seau en assurant leur routage. Elle comprend aussi les protocoles ICMP (Internet Control Message Protocol ) et IGMP (Internet Group Management Protocol ) La couche transport assure tout d'abord une communication de bout en bout en faisant abstraction des machines interm diaires entre l' metteur et le destinataire. Elle s'occupe de r guler le ux de donn es et assure un transport able (donn es transmises sans erreur et re ues dans l'ordre de leur mission) dans le cas de TCP (Transmission Control Protocol ) ou non able dans le cas de UDP (User Datagram Protocol ). Pour UDP, il n'est pas garanti qu'un paquet (appel dans ce cas datagramme ) arrive bon port, c'est la couche application de s'en assurer. La couche application est celle des programmes utilisateurs comme telnet (connexion un ordinateur distant), FTP (File Transfert Protocol ), SMTP (Simple Mail Transfert Protocol ), etc... Cette architecture et ces di rents protocoles permettent de faire fonctionner un r seau local, par exemple sur un bus Ethernet reliant un ordinateur client A qui interroge un serveur FTP B, comme illustr dans la gure 2.4 Mais, ceci permet surtout de constituer un internet, c'est- -dire une interconnexion de r seaux ventuellement h t rog nes comme illustr dans la gure 2.5. Ici les 34

7 6 5

applications

processus utilisateur ex : ping

processus utilisateur ex : FTP

processus utilisateur

processus utilisateur ex : BOOTP

logiciels hors du SE

logiciels dans le SE

4

transport

TCP

UDP

3

réseau

ICMP

IP

IGMP

adressage IP suniquement

adressage

2 1

liens

ARP

interface matérielle

RARP

physique

couches OSI correspondantes support matériel

Fig.

2.3 - Architecture d'une pile TCP/IP

ordinateur A

ordinateur B

client FTP protocole FTP

serveur FTP

TCP protocole TCP

TCP

IP protocole IP

IP

driver Ethernet protocole Ethernet

driver Ethernet

bus Ethernet
Fig.

2.4 - Communication entre deux machines du m me r seau 35

ordinateurs A et B sont des syst mes terminaux et le routeur est un syst me interm diaire. Comme on peut le voir, la remise du datagramme n cessite l'utilisation de deux trames di rentes, l'une du r seau Ethernet entre la machine A et le routeur, l'autre du r seau Token-Ring entre le routeur et la machine B. Par opposition, le principe de structuration en couches indique que le paquet re u par la couche transport de la machine B est identique celui mis par la couche transport de la machine A. Lorsqu'une application envoie des donn es l'aide de TCP/IP les donn es traversent de haut en bas chaque couche jusqu' aboutir au support physique o elles sont alors mises sous forme se suite de bits. L'encapsulation illustr e dans la gure 2.6 consiste pour chaque couche ajouter de l'information aux donn es en les commen ant par des en-t tes, voire en ajoutant des informations de remorque. Dans le cas du protocole UDP la place de TCP, les seuls changements sont que l'unit d'information pass IP s'appelle un datagramme UDP dont l'en-t te a une taille de 8 octets.

2.3 Adressage.
Chaque ordinateur du r seau Internet dispose d'une adresse IP unique cod e sur 32 bits. Plus pr cis ment, chaque interface dispose d'une adresse IP particuli re. En e et, un m me routeur interconnectant 2 r seaux di rents poss de une adresse IP pour chaque interface de r seau. Une adresse IP est toujours repr sent e dans une notation d cimale point e constitu e de 4 nombres (1 par octet) compris chacun entre 0 et 255 et s par s par un point. Ainsi 193.49.144.1 est l'adresse IP d'une des principales machines du r seau de l'universit d'Angers. Plus pr cis ment, une adresse IP est constitu e d'une paire (id. de r seau, id. de machine) et appartient une certaine classe (A, B, C, D ou E) selon la valeur de son premier octet, comme d taill dans la gure 2.7. Le tableau ci-apr s donne l'espace d'adresses possibles pour chaque classe. classe adresses A 0.0.0.0 127.255.255.255 B 128.0.0.0 191.255.255.255 C 192.0.0.0 223.255.255.255 D 224.0.0.0 239.255.255.255 E 240.0.0.0 247.255.255.255 Ainsi, les adresses de classe A sont utilis es pour les tr s grands r seaux qui comportent plus de 216 = 65536 ordinateurs. Au niveau mondial, il ne peut exister plus de 127 tels r seaux, par exemple celui de la d fense am ricaine ou du MIT, mais la politique actuelle est de ne plus d nir de tels r seaux. Les adresses de classe B sont utilis es pour les r seaux ayant entre 28 = 256 et 216=65536 ordinateurs, 14 bits d nissent l'adresse du r seau et 16 bits celle d'une machine sur le r seau. Seules 256 machines sont possibles sur un r seau de classe C dont le nombre possible d passe les 2 millions (= 221 ). L'obtention d'une adresse IP pour cr er un nouveau r seau est g r e par l'INTERNIC de mani re d centralis e, savoir qu'un organisme national g re les demandes pour chaque pays. En France c'est l'INRIA (Institut National de Recherche en Informatique et Automatique ) qui est charg de cette t che. Au lieu d'utiliser un adressage plat 1, 2, 3, ... la m thode retenue est plus e cace car elle permet une extraction rapide du num ro de r seau l'int rieur d'une adresse IP ce qui facilitera le routage. Toutes les combinaisons math matiquement possibles pour identi er un r seau ou une machine ne sont pas permises car certaines adresses ont des signi cations particuli res. 0.0.0.0 est utilis e par une machine pour conna tre sa propre adresse IP lors d'une processus d'amor age par exemple <id. de r seau nul>.<id. de machine> est galement utilis e pour d signer une machine sur son r seau lors d'un boot galement <id. de r seau>.<id. de machine nul> n'est jamais a ect e une machine car elle permet de d signer le r seau lui-m me 36

ordinateur A

ordinateur B

client FTP message identique

serveur FTP

TCP

paquet identique routeur

TCP

IP

datagramme identique

IP

datagramme identique

IP

driver Ethernet

trame identique

driver Ethernet

driver Token Ring

trame identique

driver Token Ring

Token Ring bus Ethernet
Fig.

2.5 - Interconnexion de deux r seaux

données utilisateur application en-tete applicatif données utilisateur TCP en-tete TCP données applicatives segment TCP IP

en-tete IP

en-tete TCP

données applicatives datagramme IP driver Ethernet remorque Ethernet

en-tete Ethernet 14 octets

en-tete IP 20 octets

en-tete TCP 20 octets

données applicatives trame Ethernet

Ethernet

46 à 1500 octets

Fig.

2.6 - Encapsulation des donn es par la pile des protocoles TCP/IP.

37

7 bits classe A 0 id. de réseau 14 bits classe B 1 0 id. de réseau 21 bits classe C 1 1 0 id. de réseau 28 bits classe D 1 1 1 0

24 bits id. de machine 16 bits id. de machine 8 bits id. de machine

adresse multidestinataire (muticast) 27 bits

classe E

1

1

1

1

0

réservé pour usage ultérieur

Fig.

2.7 - Les cinq classes d'adressses IP
1> est une adresse

<id. de r seau>.<id. de machine avec tous ses bits

de di usion ou de broadcasting, c'est- -dire qu'elle d signe toutes les machines du r seau concern . Un datagramme adress cette adresse sera ainsi envoy toutes les machines du r seau.
255.255.255.255

est une adresse de di usion locale car elle d signe toutes les machines du r seau auquel appartient l'ordinateur qui utilise cette adresse. L'avantage par rapport l'adresse pr c dente est que l' metteur n'est pas oblig de conna tre l'adresse du r seau auquel il appartient.
127.X.Y.Z

est une adresse de rebouclage qui est utilis e pour permettre les communications inter-processus sur un m me ordinateur ou r aliser des tests de logiciels car tout logiciel de communication recevant des donn es pour cette adresse les retourne simplement l' metteur.

Les adresses de classe A de 10.0.0.0 10.255.255.255, de classe B de 172.16.0.0 172.31.255.255 et de classe C de 192.168.0.0 192.168.255.255 sont r serv es la constitution de r seaux priv s autrement appel s intranet 1 . Le syst me des adresses IP permet galement la d nition d'adresses de sous-r seaux en d coupant la partie r serv e l'adresse des machines sur un r seau en deux parties dont la premi re sera un identi cateur de sous-r seau. Ainsi un seul r seau de classe B, sur lequel on pourrait nommer 65 536 machines pourra tre d compos en 254 sous-r seaux de 254 machines, de la mani re d crite ci-dessous.
<id. de r seau sur 16 bits>.<id. de sous-r seau sur 8 bits>.<id. de machine sur 8 bits>

L'administrateur d'un r seau peut d cider de d couper o il veut la zone des identi cateurs de machines, mais le d coupage autour du . facilite le travail des routeurs. On peut galement adopter le m me principe pour un r seau de classe C. Cette technique a pour e et de provoquer un routage hi rarchique. La gure 2.8 illustre le cas d'un r seau X.Y.0.0 d coup en deux sous-r seaux X.Y.1.0 et X.Y.2.0. Pour tout le reste d'Internet, il n'existe qu'un seul r seau X.Y.0.0 et tous les routeurs traitent les datagrammes destination de ce r seau de la m me fa on. Par contre, le routeur R se sert du troisi me octet ( gal 1 ou 2) de l'adresse contenue dans les datagrammes qui lui proviennent pour les diriger vers le sous-r seau auquel ils sont destin s assurant ainsi un routage hi rarchique. Outre l'adresse IP, une machine doit galement conna tre le nombre de bits attribu s l'identicateur du sous-r seau et celui de la machine. Cette information est rendue disponible gr ce un
1 Un intranet est un r seau d' tendue g ographique tr s limit e, par exemple pour une entreprise, bas sur la technologie TCP/IP mais non reli Internet. Un extranet est galement un r seau priv b ti sur TCP/IP, non connect Internet, mais r parti sur des sites g ographiques distants
:

38

X.Y.1.1

X.Y.1.2

X.Y.1.3

réseau X.Y.1.0 Internet routeur R réseau X.Y.2.0

trafic vers X.Y.0.0 X.Y.2.1

X.Y.2.2

Fig.

2.8 - Adressage de sous-r seau

masque de sous-r seau ou subnet netmask qui est un mot de 32 bits contenant des bits 1 au lieu et place de l'identi cateur de r seau et de sous-r seau et des bits 0 au lieu et place de l'identi cateur de machines. Ainsi le masque 2 255.255.255.0 indique que les 24 premiers bits d'une adresse d signent le sous-r seau et les 8 derniers une machine. Le masque 255.255.255.192 ((192)10 = (11000000)2 ) indique que les 26 premiers bits d signent le sous r seau et les 6 derniers une machine. De cette mani re partir de l'adresse d'un datagramme et de son masque de sous-r seau une machine peut d terminer si le datagramme est destin une machine sur son propre sous-r seau, une machine sur un autre sous-r seau de son r seau ou une machine ext rieure son sous-r seau. Par exemple, dans le cadre du r seau de la gure 2.8 o le masque de sous-r seau est 255.255.255.0 supposons que notre machine soit celle identi e par l'adresse IP X.Y.1.2.

Si l'adresse de destination est X.Y.1.1, un et entre la repr sentation binaire de cette adresse est de celle du masque de sous-r seau donne X.Y.1.0 savoir l'adresse du sous-r seau de notre machine, donc le datagramme est destin une machine de ce m me sous-r seau. Si l'adresse de destination est X.Y.2.1, un calcul du m me genre donne l'adresse d'un autre sous-r seau du m me r seau.
X.Y.2.0

c'est- -dire

Si l'adresse de destination est S.T.U.V (avec (S T ) 6= (X Y )) le r sultat sera l'adresse d'un r seau di rent de celui auquel appartient notre machine. Bien que la num rotation IP l'aide d'adresses num riques soit su sante techniquement, il est pr f rable pour un humain de d signer une machine par un nom. Mais se pose alors le probl me de la d nition des noms et de leur mise en correspondance avec les num ros IP. Au d but des ann es 80, le r seau ARPANET comportait un peu plus de 200 ordinateurs et chacun poss dait un chier /etc/hosts identi ant les noms de ces ordinateurs suivis de leur num ro IP. Lorsqu'une modi cation intervenait, il su sait de mettre jour ce chier. Pour faire face l'explosion du nombre d'ordinateurs reli s Internet, il a t mis en place un syst me de base de donn es distribu es : le syst me de noms de domaines (DNS : Domain Name System ) qui fournit la correspondance entre un nom de machine et son num ro IP. En fait, le DNS est un espace de noms hi rarchis comme illustr dans la gure 2.9. Chaque n ud a un nom d'au plus 63 caract res et la racine de l'arbre a un nom nul (les minuscules et majuscules sont indi renci es). Une zone est un sous-arbre de cette hi rarchie. Le nom de domaine d'un n ud est la concat nation de son nom avec celui de ses anc tres dans l'arbre. La responsabilit du nommage est subdivis e par niveau, les niveaux sup rieurs d l guant leur autorit aux sous-domaines qu'ils cr ent eux-m mes. Il faut bien avoir l'esprit que le d coupage n'a dans certains cas aucune base g ographique on trouve des domaines .com partout dans le monde.
2: En

notation d cimale point e.

39

gov

com

edu

org

fr

de

univangers

elysee

info

istia

vega

Fig.

2.9 - Syst me de noms de domaines.

Le m canisme qui permet la r solution d'un nom en une adresse IP est g r par des serveurs de noms qui repr sentent une base de donn es distribu e des noms de domaine. Quand une personne a re u l'autorit de g rer une zone elle doit maintenir au moins deux serveurs de noms : un primaire et un ou plusieurs secondaires. Les secondaires ont des serveurs redondants par rapport au primaire de mani re faire face une d faillance d'un syst me. Lorsqu'une machine est ajout e une zone, l'administrateur de la zone doit ajouter son nom et son num ro IP dans le chier disque du serveur primaire qui se recon gure alors en fonction de ces nouvelles donn es. Quant eux, les serveurs secondaires interrogent r guli rement (toutes les 3 h) le primaire et fait les mises jour n cessaires en cas d' volution de la base de donn es. Lorsqu'un serveur de noms re oit une demande, il v ri e si le nom appartient l'un des sous-domaines qu'il g re. Si c'est le cas il traduit le nom en une adresse en fonction de sa base de donn es et renvoie la r ponse au demandeur. Sinon, il s'adresse un serveur de nom racine qui conna t le nom et l'adresse IP de chaque serveur de noms pour les domaines de second niveau. Ce serveur de nom racine lui renvoie alors l'adresse d'un serveur de noms contacter, et ainsi de suite, par interrogations successives de serveurs de noms il sera capable de fournir l'adresse demand e. Pour viter de faire trop souvent de telles requ tes, tout serveur de noms stocke dans une m moire cache les correspondances (num ro IP, nom de machine) de mani re pouvoir fournir la r ponse imm diatement si une m me demande lui parvient ult rieurement.

2.4 La couche liaison d'Internet.
Le but de la couche de liens de la pile TCP/IP est d'envoyer et recevoir des datagrammes IP pour la couche IP, d'envoyer des requ tes ARP (respt. RARP) et de recevoir des r ponses pour le module ARP (respt. RARP). Nous examinons ici les caract ristiques des deux premi res couches du mod le OSI (couches physique et de liens) dans le cas d'un r seau local Ethernet et d'une liaison s rie reliant un ordinateur Internet via un modem connect sur le port s rie de cet ordinateur.

2.4.1 Le r seau Ethernet
Ethernet est le nom donn une des technologies les plus utilis es pour les r seaux locaux en bus. Elle a t invent e par Xerox au d but des ann es 70 et normalis e par l'IEEE (Institute for Electrical and Electronics Engineers) vers 1980 sous la norme IEEE 802. Tout d'abord, il existe plusieurs technologies physiques pour tablir un r seau Ethernet.
10 base 5 ou thick Ethernet est un r seau base de c ble coaxial de 1,27 cm de diam tre, d'une

40

longueur de 500 m maximum et termin chaque extr mit par une r sistance. Chaque ordinateur est reli , par un cordon AUI Attachment Unit Interface ), un bo tier appel transceiver luim me connect au c ble par l'interm diaire d'une prise vampire . Le transceiver est capable de d tecter si des signaux num riques transitent sur le c ble et de les traduire en signaux num riques destination de l'ordinateur, et inversement. 10 base 2 ou thin Ethernet est un r seau base d'un c ble coaxial plus n et plus souple, moins r sistant aux perturbations lectromagn tiques que le 10 base 5, mais d'un co t inf rieur. Le transceiver et le c ble AUI ne sont plus utiles car l'ordinateur est reli directement au c ble par l'interm diaire d'une prise BNC en T int gr e la carte Ethernet de l'ordinateur. 10 base T ou twisted pair Ethernet est un r seau dans lequel chaque ordinateur est reli , par un c ble de type paire torsad e, un point central appel hub qui simule l'e et d'un transceiver et de son c ble AUI. La connexion des c bles se fait par l'interm diaire d'une prise RJ45 et les hubs doivent tre aliment s lectriquement. Ils simulent ainsi le fonctionnement d'un bus alors que la topologie physique du r seau est une toile. Majoritairement, les r seaux Ethernet ont un d bit de 10Mbit/s 3 et les informations sont transmises sur le bus sans garantie de remise. Chaque transceiver capte toutes les trames qui sont mises sur le c ble et les redirige vers le contr leur de l'ordinateur qui rejettera les trames qui ne lui sont pas destin es et enverra au processeur celles qui le concernent, c'est- -dire celles dont l'adresse de destination est gale celle de la carte r seau. Comme il n'y a pas d'autorit centrale qui g re l'acc s au c ble, il est possible que plusieurs stations veuillent mettre simultan ment sur le c ble. C'est pourquoi chaque transceiver coute le c ble pendant qu'il met des donn es a n de d tecter des ventuelles perturbations. Si une collision est d tect e par le transceiver, celui-ci pr vient le coupleur qui arr te d' mettre et attend un laps de temps al atoire compris entre 0 et une certaine dur e avant de r mettre ses donn es. S'il y a encore un probl me de collision, alors un nouveau temps d'attente est tir au sort entre 0 et 2 , puis entre 0 et 4 , etc... jusqu' ce que la trame soit mise. Ce principe est justi par le fait que si une premi re collision se produit, il y a de fortes chances que les d lais d'attente tir s au sort par chacune des 2 stations soient tr s proches, donc il ne sera pas surprenant d'avoir une nouvelle collision. En doublant chaque fois l'intervalle des d lais d'attente possibles on augmente les chances de voir les retransmissions s' taler sur des dur es relativement longues et donc de diminuer les risques de collision. Cette technologie s'appelle CSMA/CD (Carrier Sense Multiple Access with Collision Detect). Elle est e cace en g n rale mais a le d faut de ne pas garantir un d lai de transmission maximal apr s lequel on est s r que la trame a t mise, donc cela ne permet pas de l'envisager pour des applications temps r el. Les adresses physiques Ethernet sont cod es sur 6 octets (48 bits) et sont cens es tre uniques car les constructeurs et l'IEEE g re cet adressage de mani re ce que deux coupleurs ne portent pas la m me adresse 4 . Elles sont de trois types - unicast dans le cas d'une adresse monodestinataire d signant un seul coupleur - broadcast dans le cas d'une adresse de di usion g n rale (tous les bits 1) qui permet d'envoyer une trame toutes les stations du r seau - multicast dans le cas d'une adresse multidestinataire qui permet d'adresser une m me trame un ensemble de stations qui ont convenu de faire partie du groupe que repr sente cette adresse multipoint. On voit donc qu'un coupleur doit tre capable de reconnaitre sa propre adresse physique, l'adresse de multicast, et toute adresse de groupe dont il fait partie.
voire une adresse nulle.
3: Les technologies 100 Mbit/s et Gigabit sont galement op rationnelles. 4: En pratique, certains constructeurs ne respectent pas cette r gle et plusieurs

cartes peuvent avoir la m me adresse,

41

Au niveau des trames, la normalisation IEEE 802 5 d nit un format de trame l g rement di rent de celui du v ritable Ethernet. Ainsi, le RFC 894 d nit les trames Ethernet et le RFC 1042 d nit celles des r seaux IEE 802 comme illustr dans la gure 2.10. Mais la variante la plus usit e est l'Ethernet.
trame IEEE 802 (RFC 1042) 802.3 MAC adresse de destination 6 adresse source 6 802.2 LLC longueur DSAP 2 1 SSAP 1 ctrl 1 802.2 SNAP org code 3 type 2 données 38-1492 CRC 4

trame Ethernet (RFC 894)

adresse de destination 6

adresse source 6
Fig.

type 2

données 46-1500

CRC 4

2.10 - Encapsulation Ethernet et IEEE 802.3.

Les deux trames utilisent des adresses mat rielles source et destination de 6 octets (adresse Ethernet) et un CRC de 4 octets mais di rent sur les points suivants. - Dans le format Ethernet le troisi me champ contient le type de donn es transmises selon que c'est un datagramme IP, une requ te ou r ponse ARP ou RARP. Puis, viennent les donn es transmises qui peuvent avoir une taille allant de 46 1500 octets. Dans le cas de donn es trop petites, comme pour les requ tes et r ponse ARP et RARP (voir la sous-section 2.4.4) on compl te avec des bits de bourrage ou padding. - Dans le format IEEE 802, le troisi me champ indique le nombre d'octets de la trame sans compter le CRC. tant donn qu'aucune des valeurs possibles pour le champ type de la trame Ethernet ne peut repr senter une longueur de trame, ce champ peut permettre de distinguer les encapsulations. Pour la sous-couche LLC le champ DSAP (Destination Service Access Point ) d signe le ou les protocoles de niveau sup rieur qui sont destin es les donn es de la trame et le champ SSAP (Source Service Access Point ) d signe le protocole qui a mis la trame. Ici leur valeur hexad cimale est AA, c'est- -dire la valeur d signant le protocole SNAP (Sub-Network Access Protocol ). Le champ de contr le ctrl est mis gal 3 et les 3 octets du champ org code sont mis 0. Ensuite, on trouve le champ type qui a la m me signi cation que celui de la trame Ethernet. De nombreux quipements mat riels interviennent dans la constitution physique d'un r seau Ethernet, ce paragraphe d crit quelques uns de ceux qui interviennent aux niveaux 1 et 2 du mod le OSI. Un r p teur op re de mani re physique uniquement, donc au niveau de la couche 1 du mod le OSI. Il se contente de retransmettre et d'ampli er tous les signaux qu'il re oit, sans aucun autre traitement. Un hub est un r p teur 10 base T multiport qui renvoie donc le signal qu'il re oit par l'un de ses ports vers tous ses autres ports. Un pont est un quipement qui intervient dans l'architecture d'un r seau en reliant deux segments disjoints de ce r seau. Le pont appartient la couche 2 du mod le OSI car il va ltrer les trames du r seau en fonction de leur origine et destination, mais il ne se pr occuppe pas du logiciel r seau de niveau sup rieur (TCP/IP, DECNet, IPX, ...).
5 Elle r unit IEEE 802.2 qui d nit la sous-couche de contr le de liens LLC (Logical Link control ) qui repose sur la sous-couche physique MAC (Medium Access Control ) IEEE 802.3.
:

42

A

B

C

D

pont
Fig.

2.11 - Fonctionnement d'un pont..

Dans la con guration de la gure 2.11 le pont sera capable de d terminer que les ordinateurs A et B sont sur le segment 1 et les ordinateurs C et D sur le segment 2. Il peut obtenir ces informations car il voit passer toutes les trames provenant des ordinateurs appartenant aux deux segments qu'il relie et gr ce aux adresses d'origine contenues dans les trames, il peut se construire une table d'adresses m morisant la cartographie du r seau. Ainsi, si une trame est envoy e de A vers B, ou de C vers D, elle ne franchira pas le pont car celui-ci aura d tect que c'est inutile. Mais si la trame provenant de A est destin e C ou D, elle le traversera sans aucun autre traitement. L'utilisation d'un pont peut ainsi am liorer le d bit d'un r seau car toutes les trames ne sont pas transmises sur tout le r seau. D'autre part, cela peut permettre d'augmenter la con dentialit du r seau en isolant certains ordinateurs des autres de mani re ce que certaines trames soient impossibles capturer par des ordinateurs espions collectionnant toutes les trames qui circulent sur le r seau, m me celles qui ne lui sont pas destin es. Un commutateur est en fait un pont multiport qui va aiguiller chacune des trames qu'il re oit vers le segment sur lequel se trouve l'ordinateur de destination de la trame. Cependant, chacun de ses ports est habituellement reli un segment contenant un nombre restreint d'ordinateurs, voire un seul s'il s'agit par exemple d'un serveur tr s sollicit . SLIP (Serial Link Internet Protocol, RFC 1055) est un protocole permettant d'envoyer des paquets IP entre deux ordinateurs reli s par une liaison s rie (par exemple, gr ce deux modems branch s sur les ports RS-232 et une ligne t l phonique). Dans ce cas il n'y a pas besoin de pr voir un adressage de niveau 2, puisque la liaison est point point (une seule machine chaque extr mit du lien). Par contre, il s'agit de d limiter le d but et la n des paquets IP. L'encapsulation d'un paquet IP avant de l'envoyer sur la ligne consiste simplement le faire terminer par le caract re sp cial END (Oxc0) comme illustr dans la gure 2.12. Pour viter des probl mes de bruit, certaines implantations de SLIP font
datagramme IP c0 db

2.4.2 La liaison SLIP

c0

db dc

db dd

c0

Fig.

2.12 - Encapsulation SLIP.

galement d buter l'envoi du paquet IP par un caract re END. Pour qu'un caract re END faisant partie des donn es du paquet IP ne soit pas interpr t comme la n du paquet, l' metteur le remplace par 43

la s quence d' chappement SLIP_ESC ESC_END (0xdb 0xdc). Si le caract re SLIP_ESC fait partie des donn es transmettre, alors la s quence SLIP_ESC ESC_ESC (0xdb 0xdd) est transmise sa place. Un des d fauts de ce protocole est qu'il faut que les deux extr mit s aient x pr alablement leurs adresses IP, car la liaison SLIP ne leur permet pas de se les changer. Si un site o re via un seul modem l'acc s Internet plusieurs personnes, cela ne posera pas de probl me. En e et, chaque personne aura con gur son ordinateur avec le num ro IP fournit par l'administrateur du r seau et comme une seule connexion est possible la fois la duplication du m me num ro IP n'est pas g nante. Seulement, si le site o re un deuxi me modem sur le m me num ro t l phonique, les utilisateurs ignoreront quel modem ils sont connect s. ce moment l , il faudra que le syst me indique chaque utilisateur comment con gurer son ordinateur en fonction de l'utilisation ou non de l'autre modem de telle mani re que la m me adresse IP ne soit pas donn e deux personnes di rentes simultan ment. Dans ce genre d'utilisation SLIP a le d faut de ne pas o rir d'acc s contr ler par mot de passe. De plus, il n'y a pas de champ type donc la ligne ne peut pas tre utilis e en m me temps pour un autre protocole. Et en n, il n'y a pas de contr le de la transmission. Si une trame subit des perturbations, c'est aux couches sup rieures de de le d tecter. Malgr tout, SLIP est un protocole largement utilis et existe aussi dans une version am lior e CSLIP (Compressed SLIP ).

2.4.3 La liaison PPP
PPP (Point to Point Protocol ) (RFC 1661) est un protocole qui corrige les d ciences de SLIP en o rant les fonctionnalit s suivantes. - utilisation sur des liaisons point point autres que s rie, comme X25 ou RNIS - le transport de protocoles de niveau 3 (IP, Decnet, Appletalk, ...) - la compression des en-t tes IP et TCP pour augmenter le d bit de la liaison - gestion d'un contr le d'acc s au r seau par authenti cation selon le protocole PAP qui n cessite la donn e d'un mot de passe au d but de la communication ou le protocole CHAP qui permet l' change de sceaux crypt s tout au long de la communication - d tection et correction d'erreurs de transmission - ne pas utiliser des codes qui risquent d' tre interpr t s par les modems - con guration automatique de la station client selon ses protocoles de couche r seau (IP, IPX, Appletalk). Le protocole PPP est celui classiquement utilis par les fournisseurs d'acc s Internet pour connecter leurs abonn s selon le sch ma de la gure 2.13. Le processus de connexion d'un client quip d'un
ordinateur client modem réseau téléphonique modem serveur de communications réseau Ethernet

Internet

Fig.

2.13 - Connexion Internet par modem et PPP. 44

ordinateur sous Windows, MacOS, Linux ou autre est le suivant. Le modem du client appelle le num ro de t l phone du fournisseur et la connexion t l phonique s' tablit si l'un au moins de ses modems est libre. L'identi cation du client se fait par envoi d'un nom d'utilisateur et d'un mot de passe soit directement par l'utilisateur, soit selon l'un des protocoles PAP ou CHAP. Pour PAP (Protocol Authenti cation Protocol ) le serveur de communication envoie l'ordinateur un paquet pour demander le nom d'utilisateur et le mot de passe et l'ordinateur renvoie ces informations directement. CHAP (Challenge Handshake Authenti cation Protocol ) fonctionne de la m me mani re sauf que le serveur de communication envoie d'abord une clef qui va permettre de crypter l'envoi du nom d'utilisateur et du mot de passe. Une fois l'identi cation du client control e, le serveur de communication envoie une adresse IP, dite dynamique car elle varie selon les connexions, l'ordinateur du client qui partir de l se retrouve int gr au r seau Internt avec une adresse IP pour tout le temps que durera sa connexion.
fanion 7e 1 addr ff 1 ctrl 03 1 protocole 2 protocole 0021 informations pas plus de 1500 octets CRC 2 fanion 7e 1

datagramme IP

protocole c021

données de controle de liens

protocole 8021

données de controle de réseau

Fig.

2.14 - Encapsulation PPP.

De mani re plus technique l'encapsulation PPP illustr e dans la gure 2.14 est proche du standard HDLC de l'ISO (voir section 1.4.2) et est telle que chaque trame commence et nit par un fanion de valeur 0x7e soit en binaire 01111110. La valeur du champ adresse est toujours x e 0xff puisqu'elle est inutile ici dans le cas d'une liaison point point. Le champ contr le est x 0x03. Le champ protocol a le m me r le que la champ type de la trame Ethernet. Le CRC assure la d tection des erreurs de transmission. Le probl me de l'apparition du fanion 01111110 au milieu des donn es transmettre est r gl des deux mani res suivantes. - Dans le cas d'une liaison synchrone, l' mission un bit 1 et il est retir la r ception.
0

est syst matiquement ajout apr s 5

- Dans le cas d'une liaison asynchrone, le fanion 0x7e est remplac par la suite 0x7d 0x5e, et le code 0x7d est lui-m me remplac par la suite 0x7d 0x5d. De plus tout octet O de valeur inf rieure 0x20 (32 en d cimal), correspondant donc un code de contr le ASCII, sera remplac par la s quence 0x7d O' o O0 = O 0x20. Ainsi, on est s r que ces caract res ne seront pas interpr t s par les modems comme des caract res de commandes. Par d faut, les 32 valeurs sont trait es ainsi mais il est possible d'utiliser le protocole de contr le de liens pour sp ci er pour quels caract res uniquement on fait cette transformation. 45

2.4.4 Les protocoles ARP et RARP
tant donn que le protocole IP, et ses adresses, peuvent tre utilis s sur des architectures mat rielles di rentes (r seau Ethernet, Token-Ring, ...) poss dant leur propres adresses physiques, il y a n cessit d' tablir les correspondances biunivoques entre adresses IP et adresses mat rielles des ordinateurs d'un r seau. Ceci est l'objet des protocoles ARP (Address Resolution Protocol ) et RARP (reverse Address Resolution Protocol ). ARP fournit une correspondance dynamique entre une adresse IP connue et l'adresse mat rielle lui correspondant, RARP faisant l'inverse. Nous nous pla ons dans le cas d'une correspondance tablir entre IP et Ethernet et la n cessit de la r solution d'adresse fournie par ARP appara t dans l'exemple ci-dessous d crivant le d but d'une connexion FTP. 1. Le client FTP convertit l'adresse du serveur FTP (ex : vega.univ-angers.fr) en une adresse IP (193.49.162.1) l'aide du chiers /etc/hosts ou d'un serveur de noms (DNS). 2. Le client FTP demande la couche TCP d' tablir une connexion avec cette adresse. 3. TCP envoie une requ te de connexion ce serveur en mettant un datagramme IP contenant l'adresse IP 4. En supposant que les machines client et serveur sont sur le m me r seau local Ethernet, la machine mettrice doit convertir l'adresse IP sur 4 octets en une adresse Ethernet sur 6 octets avant d' mettre la trame Ethernet contenant le paquet IP. C'est ce que va faire ARP. 5. Le module ARP envoie une requ te ARP dans une trame Ethernet (donn e dans la gure 2.15) avec une adresse de destination multicast. Ainsi, toutes les machines du r seau local re oivent cette requ te contenant l'adresse IP r soudre. 6. La couche ARP de la machine vis e (ici vega.univ-angers.fr) reconna t que cette requ te lui est destin e et r pond par une r ponse ARP contenant son adresse mat rielle 00:20:AF:AB:42:43. Les autres machines du r seau ignorent la requ te. 7. La r ponse ARP est re ue par l' metteur de la requ te. Pour ce retour, il n'y a pas de probl me de r solution puisque l'adresse physique de l' metteur tant envoy e dans la requ te elle est connue de la machine qui r pond. 8. La r ponse ARP est re ue par la couche ARP du client FTP, et le driver Ethernet peut alors mettre le paquet IP avec la bonne adresse Ethernet de destination.
adresse Ethernet de destination adresse Ethernet de source type de trame type de mat. type de prot. taille prot. taille mat. adresse Ethernet de l’émetteur adresse IP de l’émetteur adfesse Ethernet cible adresse IP cible

op

an-tete Ethernet

28 octets requete/réponse ARP/RARP

Fig.

2.15 - Requ te ou r ponse ARP sur un r seau Ethernet.

Les deux premiers champs d'une trame Ethernet (voir gure 2.15) mise par ARP sont conformes l'en-t te d'une trame Ethernet habituelle et l'adresse de destination sera ff:ff:ff:ff:ff:ff, l'adresse multicast d signant toutes les machines du r seau la fois. La valeur du champ type de trame est 0x0806 indiquant le protocole ARP. Le champ type de mat riel est gal 1 pour un r seau Ethernet et et celui type de protocole est gal est 0x800 pour IP. Les tailles en octets sp ci es ensuite sont 6 (6 octets pour une adresse Ethernet) et 4 (4 octets pour une adresse IP). Le champ op vaut 1 pour une requ te ARP et 2 pour une r ponse ARP. Les quatre champs suivants contiennent des adresse et 46

sont redondants dans le cas de l'adresse Ethernet metteur d'une requ te ARP, et non renseign s dans le cas de l'adresse Ethernet cible d'une requ te ARP. La machine qui reconna t son num ro IP l'int rieur d'une requ te ARP qu'elle re oit la renvoie en y intervertissant les adresses IP cible et metteur, ainsi que les adresses Ethernet cible (apr s l'avoir substitu e l'adresse de di usion dans l'en-t te et renseign e dans le corps de la trame) et Ethernet metteur. Pour viter la multiplication des requ tes ARP, chaque machine g re un cache dans lequel elle m morise les correspondances adresses IP/adresses Ethernet d j r solues pr alablement. Ainsi, le module ARP ne lancera une requ te que lorsqu'il ne trouvera pas cette correspondance dans le cache, sinon il se contentera d' mettre les donn es qu'il re oit d'IP en ayant xer correctement l'adresse physique de destination. Cependant, les correspondances ne sont pas conserv es ind niment car cela pourrait provoquer des erreurs lorsque l'on change un ordinateur (ou une carte r seau) sur le r seau en conservant un m me num ro IP pour cet ordinateur mais videmment pas la m me adresse physique. Quant lui, le protocole RARP joue le r le inverse de ARP en permettant de d terminer l'adresse IP d'un quipement dont on conna t l'adresse physique. Ceci est notamment utile pour amorcer une station sans disques, ou un TX, qui n'a pas en m moire son adresse IP mais seulement son adresse mat rielle. Le format d'une trame RARP est celui de la gure 2.15) o le champ type de trame vaut 0x0835 et le champ op vaut 3 pour une requ te RARP et 4 pour une r ponse. Une requ te RARP est di us e sous forme de broadcast, donc toutes les machines du r seau la re oivent et la traitent. Mais la plupart des machines ignorent simplement cette demande, seuls, le ou les serveurs RARP du r seau vont traiter la requ te gr ce un ou plusieurs chiers et vont retourner une r ponse contenant l'adresse IP demand e.

2.5 Le protocole IP.
Comme on a pu le voir dans la gure 2.3 le protocole IP (Internet Protocol, RFC 791) est au c ur du fonctionnement d'un internet. Il assure sans connexion un service non able de d livrance de datagrammes IP. Le service est non able car il n'existe aucune garantie pour que les datagrammes IP arrivent destination. Certains peuvent tre perdus, dupliqu s, retard s, alt r s ou remis dans le d sordre. On parle de remise au mieux (best e ort delivery ) et ni l' metteur ni le r cepteur ne sont inform s directement par IP des probl mes rencontr s. Le mode de transmission est non connect car IP traite chaque datagramme ind pendamment de ceux qui le pr c dent et le suivent. Ainsi en th orie, au moins, deux datagrammes IP issus de la m me machine et ayant la m me destination peuvent ne pas suivre obligatoirement le m me chemin. Le r le du protocole IP est centr autour des trois fonctionnalit s suivantes chacune tant d crite dans une des sous-sections venir. - d nir le format du datagramme IP qui est l'unit de base des donn es circulant sur Internet - d nir le routage dans Internet - d nir la gestion de la remise non able des datagrammes

2.5.1 Le datagramme IP.
Comme cela a d j t illustr dans la gure 2.6 on rappelle qu'un datagramme IP est constitu d'une en-t te suivie d'un champ de donn es. Sa structure pr cise est d taill e dans la gure 2.16 et comporte les champs suivants. - La version code sur 4 bits le num ro de version du protocole IP utilis (la version courante est la 4, d'o son nom d'IPv4). Tout logiciel IP doit d'abord v ri er que le num ro de version du datagramme qu'il re oit est en accord avec lui-m me. si ce n'est pas le cas le datagramme est tout simplement rejet . Ceci permet de tester des nouveaux protocoles sans interf rer avec la bonne marche du r seau. 47

version

longueur d’en-tete Identification

type de services (TOS) drapeaux protocole adresse IP source adresse IP destination

longueur totale déplacement de fragment (offset) total de controle d’en-tete

durée de vie (TTL)

en-tete de 20 octets minimum

options IP éventuelles

bourrage

données

Fig.

2.16 - Structure d'un datagramme IP.

- La longueur d'en-t te repr sente sur 4 bits la longueur, en nombre de mots de 32 bits, de l'en-t te du datagramme. Ce champ est n cessaire car une en-t te peut avoir une taille sup rieure 20 octets (taille de l'en-t te classique) cause des options que l'on peut y ajouter. - Le type de services (TOS) est cod sur 8 bits, indique la mani re dont doit tre g r le datagramme et se d compose en six sous-champs comme suit. 0 1 2 3 4 5 6 7 priorit D T R C inutilis Le champ priorit varie de 0 (priorit normale, valeur par d faut) 7 (priorit maximale pour la supervision du r seau) et permet d'indiquer l'importance de chaque datagramme. M me si ce champ n'est pas pris en compte par tous les routeurs, il permettrait d'envisager des m thodes de contr le de congestion du r seau qui ne soient pas a ect es par le probl me qu'elles cherchent r soudre. Les 4 bits D, T, R et C permettent de sp ci er ce que l'on veut privil gier pour la transmission de ce datagramme (nouvel RFC 1455). D est mis 1 pour essayer de minimiser le d lai d'acheminement (par exemple choisir un c ble sous-marin plut t qu'une liaison satellite), T est mis 1 pour maximiser le d bit de transmission, R est mis 1 pour assurer une plus grande abilit et C est mis 1 pour minimiser les co ts de transmission. Si les quatre bits sont 1, alors c'est la s curit de la transmission qui doit tre maximis e. Les valeurs recommand es pour ces 4 bits sont donn es dans la table 2.1. Ces 4 bits servent am liorer la qualit du routage et
application minimise le d lai maximise le d bit maximise la abilit telnet/rlogin 1 0 0 FTP contr le 1 0 0 transfert 0 1 0 SMTP commandes 1 0 0 donn es 0 1 0 NNTP 0 0 0 SNMP 0 0 1
Tab.

minimise le co t 0 0 0 0 0 1 0

2.1 - Type de service pour les applications standard. 48

ne sont pas des exigences incontournables. Simplement, si un routeur conna t plusieurs voies de sortie pour une m me destination il pourra choisir celle qui correspond le mieux la demande. - La longueur totale contient la taille totale en octets du datagramme, et comme ce champ est de 2 octets on en d duit que la taille compl te d'un datagramme ne peut d passer 65535 octets. Utilis e avec la longueur de l'en-t te elle permet de d terminer o commencent exactement les donn es transport es. - Les champs identi cation, drapeaux et d placement de fragment interviennent dans le processus de fragmentation des datagrammes IP et sont d crits dans la sous-section 2.5.2. - La dur e de vie (TTL) indique le nombre maximal de routeurs que peut traverser le datagramme. Elle est initialis e N (souvent 32 ou 64) par la station mettrice et d cr ment de 1 par chaque routeur qui le re oit et le r exp die. Lorsqu'un routeur re oit un datagramme dont la dur e de vie est nulle, il le d truit et envoie l'exp diteur un message ICMP. Ainsi, il est impossible qu'un datagramme tourne ind niment dans un internet. Ce champ sert galement dans la r alisation du programme traceroute donn dans la section 2.8.2. - Le protocole permet de coder quel protocole de plus haut niveau a servi a cr ce datagramme. Les valeurs cod es sur 8 bits sont 1 pour ICMP, 2 pour IGMP, 6 pour TCP et 17 pour UDP. Ainsi, la station destinatrice qui re oit un datagramme IP pourra diriger les donn es qu'il contient vers le protocole ad quat. - Le total de contr le d'en-t te (header checksum) est calcul partir de l'en-t te du datagramme pour en assurer l'int grit . L'int grit des donn es transport es est elle assur e directement par les protocoles ICMP, IGMP, TCP et UDP qui les mettent. Pour calculer cette somme de contr le, on commence par la mettre z ro. Puis, en consid rant la totalit de l'en-t te comme une suite d'entiers de 16 bits, on fait la somme de ces entiers en compl ment 1. On compl mente 1 cette somme et cela donne le total de contr le que l'on ins re dans le champ pr vu. A la r ception du datagramme, il su t d'additionner tous les nombres de l'en-t te et si l'on obtient un nombre avec tous ses bits 1, c'est que la transmission s'est pass e sans probl me. Exemple : Soit le datagramme IP dont l'en-t te est la suivante 4500 05dc e733 222b ff11 checksum c02c 4d60 c02c 4d01 La somme des mots de 16 bits en compl ments 1 donne 6e08, son compl ment 1 est 91f7. Le datagramme est donc exp di avec cette valeur de checksum. - Les adresses IP source et destination contiennent sur 32 bits les adresses de la machine mettrice et destinataire nale du datagramme. - Le champ options est une liste de longueur variable, mais toujours compl t e par des bits de bourrage pour atteindre une taille multiple de 32 bits pour tre en conformit avec la convention qui d nit le champ longueur de l'en-t te. Ces options sont tr s peu utilis es car peu de machines sont aptes les g rer. Parmi elles, on trouve des options de s curit et de gestion (domaine militaire), d'enregistrement de la route, d'estampille horaire, routage strict, etc... Les champs non encore pr cis s le sont dans la section suivante car ils concernent la fragmentation des datagrammes. En fait, il existe d'autres limites la taille d'un datagramme que celle x e par la valeur maximale de 65535 octets. Notamment, pour optimiser le d bit il est pr f rable qu'un datagramme IP soit encapsul dans une seule trame de niveau 2 (Ethernet par exemple). Mais, comme un datagramme IP peut transiter travers Internet sur un ensemble de r seaux aux technologies di rentes il est impossible de d nir, a priori (lors de la d nition du RFC), une taille maximale des datagrammes 49

2.5.2 La fragmentation des datagrammes IP.

IP qui permette de les encapsuler dans une seule trame quel que soit le r seau (1500 octets pour Ethernet et 4470 pour FDDI par exemple). On appelle la taille maximale d'une trame d'un r seau le MTU (Maximum Transfert Unit ) et elle va servir fragmenter les datagrammes trop grands pour le r seau qu'ils traversent. Mais, si le MTU d'un r seau travers est su samment grand pour accepter un datagramme, videmment il sera encapsul tel quel dans la trame du r seau concern . Comme
A B

réseau1 MTU=1500

réseau3 MTU=1500

R1

réseau2 MTU=620

R2

Fig.

2.17 - Fragmentation d'un datagramme IP.

on peut le voir dans la gure 2.17 la fragmentation se situe au niveau d'un routeur qui re oit des datagrammes issus d'un r seau grand MTU et qui doit les r exp dier vers un r seau plus petit MTU. Dans cet exemple, si la station A, reli e un r seau Ethernet, envoie un datagramme de 1300 octets destination de la station B, reli e galement un r seau Ethernet, le routeur R1 va devoir fragmenter ce datagramme de la mani re suivante. datagramme initial en-t te du donn es1 donn es2 donn es3 datagramme 600 octets 600 octets 100 octets fragment1 fragment2 fragment3 en-t te du donn es1 fragment1 600 octets en-t te du donn es2 fragment2 600 octets d placement 0 d placement 600

en-t te du donn es3 d placement 1200 fragment3 100 octets La taille d'un fragment est choisie la plus grande possible tout en tant un multiple de 8 octets. Un datagramme fragment n'est r assembl que lorsqu'il arrive destination nale, m me s'ils traversent des r seaux avec un plus grand MTU les routeurs ne r assemblent pas les petits fragments. De plus chaque fragment est rout de mani re totalement ind pendante des autres fragments du datagramme d'o il provient. Le destinataire nal qui re oit un premier fragment d'un datagramme arme un temporisateur de r assemblage, c'est- -dire un d lai maximal d'attente de tous les fragments. Si, pass ce d lai, tous les fragments ne sont pas arriv s il d truit les fragments re us et ne traite pas le datagramme. Plus pr cis ment, l'ordinateur destinataire d cr mente, intervalles r guliers, de une unit le champ TTL de chaque fragment en attente de r assemblage. Cette technique permet galement de ne pas faire coexister au m me instant deux datagrammes avec le m me identi ant. Le processus de fragmentation-r assemblage est rendu possible gr ce aux di rents champs suivants. Le champ d placement de fragment pr cise la localisation du d but du fragment dans le datagramme initial. part cela, les fragments sont des datagrammes dont l'en-t te est quasiment identique celle du datagramme original. Par exemple, le champ identi cation est un entier qui identi e de mani re unique chaque datagramme mis et qui est recopi dans le champ identi cation de chacun des fragments si ce datagramme est fragment . Par contre, le champ longueur total est recalcul pour chaque fragment. Le champ drapeaux comprend trois bits dont deux qui contr lent la fragmentation. S'il est positionn 1 le premier bit indique que l'on ne doit pas fragmenter le datagramme et si un routeur doit fragmenter 50

un tel datagramme alors il le rejette et envoie un message d'erreur l'exp diteur. Un autre bit appel fragments suivre est mis syst matiquement 1 pour tous les fragments qui composent un datagramme sauf le dernier. Ainsi, quand le destinataire re oit le fragment dont le bit fragment suivre est 0 il est apte d terminer s'il a re u tous les fragments du datagramme initial gr ce notamment aux champs o set et longueur totale de ce dernier fragment. Si un fragment doit tre nouveau fragment lorsqu'il arrive sur un r seau avec un encore plus petit MTU, ceci est fait comme d crit pr c demment sauf que le calcul du champ d placement de fragment est fait en tenant compte du d placement inscrit dans le fragment traiter.

2.5.3 Le routage IP.
Le routage est l'une des fonctionnalit s principales de la couche IP et consiste choisir la mani re de transmettre un datagramme IP travers les divers r seaux d'un internet. On appellera ordinateur un quipement reli un seul r seau et routeur un quipement reli au moins deux r seaux (cet quipement pouvant tre un ordinateur, au sens classique du terme, qui assure les fonctionnalit s de routage). Ainsi un routeur r mettra des datagrammes venus d'une de ses interfaces vers une autre, alors qu'un ordinateur sera soit l'exp diteur initial, soit le destinataire nal d'un datagramme. D'une mani re g n rale on distingue la remise directe, qui correspond au transfert d'un datagramme entre deux ordinateurs du m me r seau, et la remise indirecte qui est mise en uvre dans tous les autres cas, c'est- -dire quand au moins un routeur s pare l'exp diteur initial et le destinataire nal. Par exemple, dans le cas d'un r seau Ethernet, la remise directe consiste encapsuler le datagramme dans une trame Ethernet apr s avoir utilis le protocole ARP pour faire la correspondance adresse IP adresse physique (voir les sections 2.4.1 et 2.4.4) et mettre cette trame sur le r seau. L'exp diteur peut savoir que le destinataire nal partage le m me r seau que lui-m me en utilisant simplement l'adresse IP de destination du datagramme. Il en extrait l'identi cateur de r seau et si c'est le m me que celui de sa propre adresse IP 6 alors la remise directe est su sante. En fait, ce m canisme de remise directe se retrouve toujours lors de la remise d'un datagramme entre le dernier routeur et le destinataire nal. Pour sa part, la remise indirecte n cessite de d terminer vers quel routeur envoyer un datagramme IP en fonction de sa destination nale. Ceci est rendu possible par l'utilisation d'une table de routage sp ci que chaque routeur qui permet de d terminer vers quelle voie de sortie envoyer un datagramme destin un r seau quelconque. videmment, cause de la structure localement arborescente d'Internet la plupart des tables de routage ne sont pas tr s grandes. Par contre, les tables des routeurs interconnectant les grands r seaux peuvent atteindre des tailles tr s grandes ralentissant d'autant le tra c sur ces r seaux. D'un point de vue fonctionnel une table de routage contient des paires d'adresses du type (D R) o D est l'adresse IP d'une machine ou d'un r seau de destination et R l'adresse IP du routeur suivant sur la route menant cette destination. Tous les routeurs mentionn s dans une table de routage doivent bien s r tre directement accessibles partir du routeur consid r . Cette technique, dans laquelle un routeur ne conna t pas le chemin complet menant une destination, mais simplement la premi re tape de ce chemin, est appel e routage par sauts successifs (next-hop routing ). Une table de routage contient aussi une route par d faut qui sp ci e un routeur par d faut vers lequel sont envoy s tous les datagrammes pour lesquels il n'existe pas de route dans la table. La gure 2.18 donne un exemple d'interconnexion d'un r seau de classe B 140.252.0.0 subdivis en 3 sous-r seaux de masques respectifs 255.255.255.0 pour l'Ethernet du haut, 255.255.255.224 7 pour l'Ethernet du bas et le sous-r seau SLIP. Les masques de sous-r seau sont associ s par d faut chaque interface d'une machine ou sont ventuellement sp ci sur chaque ligne des tables de routage. Dans l'exemple donn ici, la table de routage simple de l'ordinateur R3 (sous syst me unix Sun) est la suivante.
6 Dans le cas d'un routeur, reli r seaux di rents par interfaces, donc poss dant adresses IP distinctes, la comparaison sera faite pour chacun de ces r seaux. 7 En binaire, ce masque est 11111111.11111111.11111111.11100000.
: k k k :

51

INTERNET

140.252.104.1 gateway 140.252.1.4 sous-réseau SLIP 140.252.13.64 O1 O2 .65 .66 140.252.13.35 140.252.1.29 R1 140.252.13.33 sous-réseau Ethernet 140.252.13.32 140.252.13.34 R3 sous-réseau Ethernet 140.252.1

Fig.

2.18 - Exemple d'interconnexion de r seau.

destination gateway ags refcnt use interface 140.252.13.65 140.252.13.35 UGH 0 0 emd0 127.0.0.1 127.0.0.1 UH 1 0 lo0 default 140.252.13.33 UG 0 0 emd0 140.252.13.32 140.252.13.34 U 4 25043 emdO Les ags ont la signi cation suivante. U La route est en service. G La route est un routeur (gateway ). Si ce ag n'est pas positionn la destination est directement connect e au routeur, c'est donc un cas de remise directe vers l'adresse IP de destination. H La route est un ordinateur (host ), la destination est une adresse d'ordinateur. Dans ce cas, la correspondance entre l'adresse de destination du paquet router et l'entr e destination de la table de routage doit tre totale. Si ce ag n'est pas positionn , la route d signe un autre r seau et la destination est une adresse de r seau ou de sous-r seau. Ici, la correspondance des identi cateurs de r seaux est su sante. D La route a t cr e par une redirection. M La route a t modi e par une redirection. La colonne compteur de r f rence (refcnt indique le nombre de fois o la route est utilis e l'instant de la consultation. Par exemple, TCP conserve la m me route tant qu'il l'utilise pour la connexion sous-jacente une application(telnet, ftp, ...). La colonne use a che le nombre de paquets envoy s travers l'interface de cette route qui est sp ci e dans la derni re colonne de la m me ligne. L'adresse 127.0.0.1 est celle de lo0, l'interface de loopback, qui sert pouvoir faire communiquer une machine avec elle-m me. La destination default sert indiquer la destination de tous les datagrammes qui ne peuvent tre rout s par l'une des autres routes. L'utilisation d'une table de routage se fait suivant l'algorithme de routage IP donn ci-dessous.
Proc dure RoutageIP(donn es Dat : datagramme, Tab : Table de routage) d but D := adresse IP de destination de Dat N := identificateur du r seau de D si N est une adresse de r seau directement accessible alors envoyer Dat vers l'adresse D sur ce r seau { il y a r solution de l'adresse IP, en adresse physique, encapsulation de Dat dans une trame physique et mission de la trame} sinon

52

pour chaque entr e de Tab faire N:=r sultat du et logique de D et du masque de sous-r seau si N=l'adresse r seau ou sous-r seau de la destination de l'entr e alors router Dat vers cette destination sortir finsi finpour si aucune correspondance n'est trouv e alors retourner l'application d'origine du datagramme une erreur de routage host unreachable ou unreachable network finsi finsi fin

L' tablissement d'une table de routage est statique lorsqu'elle r sulte de la con guration par d faut d'une interface, ou de la commande route partir d'un chier de d marrage, ou gr ce une redirection ICMP (voir la section 2.5.4). Mais d s que le r seau devient non trivial, on utilise le routage dynamique qui consiste en un protocole de communication entre routeurs qui informent chacun de leurs voisins des r seaux auxquels ils sont connect s. Gr ce ce protocole, les tables de routage voluent dans le temps en fonction de l' volution des routes. L'un des protocoles de routage les plus populaires est RIP (Routing Information Protocol ) qui est un protocole de type vecteur de distance. C'est- -dire que les messages chang s par des routeurs voisins contiennent un ensemble de distances entre routeur et destinations qui permet de r actualiser les tables de routage. Ce protocole utilise une m trique simple : la distance entre une source et une destination est gale au nombre de sauts qui les s parent. Elle est comprise entre 1 et 15, la valeur 16 repr sentant l' in ni . Ceci implique que RIP ne peut tre utilis qu' l'int rieur de r seaux qui ne sont pas trop tendus. Un message RIP est encapsul dans un datagramme UDP de la mani re d crite dans la gure 2.19. Le champ commande x 1 indique une requ te pour demander tout ou partie d'une table de routage
20 octets 8 octets commande en-tete IP en-tete UDP version adresse IP doit etre 0 doit etre 0 métrique doit etre 0 doit etre 0 20 octets répétés pour chaque couple (adresse, métrique) id. de famille d’adresse

au maximum 24 autres routes

Fig.

2.19 - Encapsulation d'un message RIP.

et x 2 pour transmettre une r ponse (d'autres valeurs hors normes actuellement existent galement). Le champ version est positionn 1 et 2 dans la version de RIP2. Pour des adresses IP, le champ identi cateur de famille d'adresses est toujours x 2. l'initialisation, le d mon de routage envoie une requ te RIP chaque interface pour demander les tables de routage compl tes de chacun de ses voisins. Sur une liaison point point la requ te est envoy e l'autre extr mit , sinon elle est envoy e sous forme de broadcast sur un r seau. Le fonctionnement normal de RIP consiste di user des r ponses soit toutes les 30 secondes, 53

soit pour une mise jour d clench e par la modi cation de la m trique d'une route. Une r ponse contient une adresse de destination, accompagn e de sa m trique, de l'adresse du prochain routeur,d'un indicateur de mise jour r cente et de temporisations. Le processus RIP met jour sa table de routage locale en examinant les entr es retourn es dont il v ri e d'abord la validit : adresse de classe A,B ou C, num ro de r seau di rent de 127 et 0 (sauf pour l'adresse par d faut 0.0.0.0), num ro d'ordinateur di rent de l'adresse de di usion, m trique di rente de l' in ni . RIP e ectue ensuite les mises jour propres l'algorithme vecteur de distance suivant. - Si l'entr e n'existait pas dans la table et si la m trique re ue n'est pas in nie, alors on ajoute cette nouvelle entr e compos e de la destination, de l'adresse du prochain routeur (c'est celui qui envoie la r ponse), de la m trique re ue. On initialise la temporisation correspondante. - Si l'entr e tait pr sente avec une m trique sup rieure celle re ue, on met jour la m trique et le prochain routeur et on r initialise la temporisation. - Si l'entr e tait pr sente et que le routeur suivant correspond l' metteur de la r ponse, on r initialise la temporisation et on met jour la m trique avec celle re ue si elles di rent. - Dans les autres cas on ignore l'entr e. Cette m thode correspond l'algorithme de Bellman-Ford de recherche de plus courts chemins dans un graphe. Un des d fauts de RIP est de ne pas g rer les adresses de sous-r seaux. Mais de telles entr es peuvent tre annonc es via le une interface appartenant ce sous-r seau pour pouvoir b n cier du masque qui y est attach et tre correctement interpr t es. En n, RIP met un temps assez long (quelques minutes) pour se stabiliser apr s la d faillance d'une liaison ou d'un routeur ce qui peut occasionner des boucles de routage. RIP2 est un protocole qui tend RIP en utilisant les 4 champs laiss s 0 par RIP dans ses messages. Le premier sert xer un domaine de routage identi ant le d mon de routage qui a mis le paquet et le quatri me l'adresse IP d'un routeur de saut suivant. Ces deux champs ont servi lancer simultan ment plusieurs d mons de routage sur un m me support leur utilisation a t abandonn e. Le deuxi me champ est un identi cateur de route pour supporter des protocoles de routes externes et le troisi me sert sp ci er un masque de sous-r seau pour chaque entr e de la r ponse. OSPF (Open Shortest Path First ) est un nouveau type de protocole de routage dynamique qui limine les limitations de RIP. C'est un protocole d' tat de liens, c'est- -dire qu'ici un routeur n'envoie pas des distances ses voisins, mais il teste l' tat de la connectivit qui le relie chacun de ses voisins. Il envoie cette information tous ses voisins, qui ensuite le propagent dans le r seau. Ainsi, chaque routeur peut poss der une carte de la topologie du r seau qui se met jour tr s rapidement lui permettant de calculer des routes aussi pr cises qu'avec un algorithme centralis . En fait, RIP et OSPF, sont des protocoles de type IGP (Interior Gateway Protocol ) permettant d' tablir les tables des routeurs internes des syst mes autonomes. Un syst me autonome peut tre d ni par un ensemble de routeurs et de r seaux sous une administration unique. Cela peut donc aller d'un seul routeur connectant un r seau local Internet, jusqu' l'ensemble des r seaux locaux d'une multinationale. La r gle de base tant qu'un syst me autonome assure la connexit totale de tous les points qui le composent en utilisant notamment un protocole de routage unique. un niveau plus global, Internet appara t donc comme une interconnexion de syst mes autonomes comme illustr dans la gure 2.20. Dans chaque syst me autonome les tables sont maintenus par par un IGP et sont chang es uniquement entre routeurs du m me sous-syst me. Pour obtenir des informations sur les r seaux externes, ceux de l'autre syst me autonome, ils doivent dialoguer avec les les routeurs externes R1 et R2. Ceux-ci sont des points d'entr e de chaque syst me et, via la liaison qui les relie, ils changent des informations sur la connectivit gr ce EGP (Exterior Gateway Protocol ) ou BGP (Border Gateway Protocol ) qui remplace EGP actuellement. 54

système autonome S1 R1 R2

système autonome S2

Fig.

2.20 - Interconnexion de syst mes autonomes.

Le protocole ICMP (Internet Control Message Protocol ) organise un change d'information permettant aux routeurs d'envoyer des messages d'erreurs d'autres ordinateurs ou routeurs. Bien qu'ICMP tourne au-dessus de IP il est requis dans tous les routeurs c'est pourquoi on le place dans la couche IP. Le but d'ICMP n'est pas de abiliser le protocole IP, mais de fournir une autre couche IP, ou une couche sup rieure de protocole (TCP ou UDP), le compte-rendu d'une erreur d tect e dans un routeur. Un message ICMP tant achemin l'int rieur d'un datagramme IP 8 illustr dans la gure 2.21, il est susceptible, lui aussi, de sou rir d'erreurs de transmission. Mais la r gle est qu'aucun message ICMP
datagramme IP en-tete IP en-tete IP 20 octets type code checksum 2 octets message ICMP contenu variable suivant le type de message

2.5.4 La gestion des erreurs.

1 octet 1 octet
Fig.

2.21 - Encapsulation d'un message ICMP.

ne doit tre d livr pour signaler une erreur relative un message ICMP. On vite ainsi une avalanche de messages d'erreurs quand le fonctionnement d'un r seau se d t riore. Le champ type peut prendre 15 valeurs di rentes sp ci ant de quelle nature est le message envoy . Pour certains types, le champ code sert pr ciser encore plus le contexte d' mission du message. Le checksum est une somme de contr le de tout le message ICMP calcul e comme dans le cas de l'en-t te d'un datagramme IP (voir la section 2.5.1). Le d tail des di rentes cat gories de messages est donn dans la liste ci-dessous o chaque alin a commence par le couple (type code) de la cat gorie d crite. (0,0) ou (8,0) Demande (type 8) ou r ponse (type 0) d' cho dans le cadre de la commande ping (voir section 2.8.2). (3,0-13) Compte-rendu de destination inaccessible d livr quand un routeur ne peut d livrer un datagramme. Le routeur g n re et envoie ce message ICMP l'exp diteur de ce datagramme. Il obtient l'adresse de cet exp diteur en l'extrayant de l'en-t te du datagramme, il ins re dans les donn es du message ICMP toute l'en-t te ainsi que les 8 premiers octets du datagramme en cause. Une liste non exhaustive des di rents codes d'erreurs possibles est : 0 1 2 3 4 5
8: L'en-t

Le r seau est inaccessible. La machine est inaccessible. Le protocole est inaccessible. Le port est inaccessible. Fragmentation n cessaire mais bit de non fragmentation positionn chec de routage de source.
te de ce datagramme contient un champ protocole gal 1.

1.

55

6 7 8 9 10 11 12 13

R seau de destination inconnu. Machine destinataire inconnue. Machine source isol e (obsol te) Communication avec le r seau de destination administrativement interdite. Communication avec la machine de destination administrativement interdite. R seau inaccessible pour ce type de service. Machine inaccessible pour ce type de service. Communication administrativement interdite par ltrage.

(4,0) Demande de limitation de production pour viter la congestion du routeur qui envoie ce message. (5,0-3) Demande de modi cation de route exp di e lorsqu'un routeur d tecte qu'un ordinateur utilise une route non optimale, ce qui peut arriver lorsqu'un ordinateur est ajout au r seau avec une table de routage minimale. Le message ICMP g n r contient l'adresse IP du routeur rajouter dans la table de routage de l'ordinateur. Les di rents codes possibles ci-apr s expliquent le type de redirection op rer par l'ordinateur. 0 1 2 3 Redirection pour un r seau. Redirection pour une machine. Redirection pour un type de service et r seau. Redirection pour un type de service et machine.

(9,0) Avertissement de routeur exp di par un routeur. (10,0) Sollicitation de routeur di us par une machine pour initialiser sa table de routage. (11,0) TTL d tect 0 pendant le transit du datagramme IP, lorsqu'il y a une route circulaire ou lors de l'utilisation de la commande traceroute (voir section 2.8.2). (11,1) TTL d tect 0 pendant le r assemblage d'un datagramme. (12,0) Mauvaise en-t te IP. (12,1) Option requise manquante. (13-14,0) Requ te (13) ou r ponse (14) timestamp, d'estampillage horaire. (15,0) et (16,0) devenues obsol tes. (17-18,0) Requ te (17) ou r ponse (18) de masque de sous-r seau.

2.6 Les protocoles TCP et UDP.
On pr sente ici les deux principaux protocoles de la couche transport d'Internet que sont les protocoles TCP (Transmission Control Protocol ) et UDP (User Datagram Protocol ). Tous les deux utilisent IP comme couche r seau, mais TCP procure une couche de transport able (alors m me que IP ne l'est pas), tandis que UDP ne fait que transporter de mani re non able des datagrammes. 56

Le protocole UDP (rfc 768)utilise IP pour acheminer, d'un ordinateur un autre, en mode non able des datagrammes qui lui sont transmis par une application (voir la gure 2.3). UDP n'utilise pas d'accus de r ception et ne peut donc pas garantir que les donn es ont bien t re ues. Il ne r ordonne pas les messages si ceux-ci n'arrivent pas dans l'ordre dans lequel ils ont t mis et il n'assure pas non plus de contr le de ux. Il se peut donc que le r cepteur ne soit pas apte faire face au ux de datagrammes qui lui arrivent. C'est donc l'application qui utilise UDP de g rer les probl mes de perte de messages, duplications, retards, d s quencement, ... Cependant, UDP fournit un service suppl mentaire par rapport IP, il permet de distinguer plusieurs applications destinatrices sur la m me machine par l'interm diaire des ports. Un port est une destination abstraite sur une machine identi par un num ro qui sert d'interface l'application pour recevoir et mettre des donn es. Par exemple,
... tftp ... snmp ... 69/udp 161/udp

2.6.1 Le protocole UDP.

est un court extrait du chier /etc/services de la machine vega.info.univ-angers.fr dans lequel sont enregistr s les num ros de port utilis s par chaque application. On y voit que l'application tftp utilise le port 69 et que l'application snmp utilise le port 161 9 . Chaque datagramme mis par UDP est encapsul dans un datagramme IP en y xant 17 la valeur du protocole (voir la section 2.5.1). Le format d taill d'un datagramme UDP est donn dans la gure 2.22. Les num ros de port (chacun
port UDP source longueur port UDP destination checksum

données

Fig.

2.22 - Structure d'un datagramme UDP.

sur 16 bits) identi ent les processus metteur et r cepteur. Le champ longueur contient sur 2 octets la taille de l'en-t te et des donn es transmises. Puisqu'un datagramme UDP peut ne transmettre aucune donn e la valeur minimale de la longueur est 8. Le checksum est un total de contr le qui est optionnel car il n'est pas indispensable lorsque UDP est utilis sur un r seau tr s able. S'il est x 0 c'est qu'en fait il n'a pas t calcul . De mani re pr cise, UDP utilise l'en-t te et les donn es mais galement une pseudo-ent te pour aboutir l'ensemble d crit gure 2.23. Cette pseudo en-t te comprend les adresses IP source 10 et destination du datagramme ainsi qu'un ventuel octet de bourrage pour aboutir un nombre d'octets total pair. partir de cet ensemble, le total de contr le est calcul de la m me mani re que dans le cas du datagramme IP (voir section 2.5.1). Si le r sultat donne un checksum nul, son compl ment 1, c'est- -dire 65535 (16 bits 1), est en fait plac dans la zone de contr le. Ce
9 Certains num ros de port (comme 69) sont statiques c'est- -dire que tous les syst mes les associent de la m me mani re aux applications et tous les logiciels applicatifs se conforment cette r gle. D'autres sont dynamiques et un num ro de port est attribu par les logiciels de communication l'application au moment o celle-ci le demande. 10 L'obtention de cette adresse IP source oblige UDP entrer en contact avec sa couche IP. En e et, sur un ordinateur reli plusieurs r seaux l'adresse IP source est celle de l'interface de sortie et celle-ci est fonction de la destination nale et de la table de routage g r e par IP. Ce dialogue UDP/IP pr liminaire l'encapsulation du datagramme UDP est une l g re entorse la notion s paration en couches rendue n cessaire, voire indispensable, pour pouvoir s'assurer pleinement de la remise bonne destination des datagrammes UDP.
: :

57

adresse IP source adresseIP destination port UDP source longueur port UDP destination checksum

données octet de bourrage
Fig.

2.23 - Champs utilis s pour le calcul du checksum UDP.

d tail permet d' viter la confusion avec le checksum nul qui indique qu'il n'a pas t calcul . Pr cisons en n que la pseudo en-t te et l'octet de bourrage ne sont pas transmis et qu'ils n'interviennent pas dans le calcul du champ longueur. la r ception UDP utilise l'adresse IP de destination et l'adresse IP mettrice inscrite dans l'en-t te du datagramme IP pour calculer, de la m me mani re qu' l' mission, une somme de contr le qui permettra d'assurer que le datagramme est d livr sans erreur et la bonne machine. Si une erreur de transmission est d tect e, le datagramme UDP est d truit en silence . Sinon, UDP oriente les donn es du datagramme vers la le d'attente associ e au num ro de port destination pour que l'application associ e celui-ci puisse les y lire.

2.6.2 Le protocole TCP.
Contrairement UDP, TCP est un protocole qui procure un service de ux d'octets orient connexion et able. Les donn es transmises par TCP sont encapsul es dans des datagrammes IP en y xant la valeur du protocole 6. Le terme orient connexion signi e que les applications dialoguant travers TCP sont consid r es l'une comme un serveur, l'autre comme un client, et qu'elles doivent tablir une connexion avant de pouvoir dialoguer (comme dans le cas de l'utilisation du t l phone). Les ordinateurs v ri ent donc pr alablement que le transfert est autoris , que les deux machines sont pr tes en s' changeant des messages sp ci ques. Une fois que tous les d tails ont t pr cis s, les applications sont inform es qu'une connexion a t tablie et qu'elles peuvent commencer leurs changes d'informations. Il y a donc exactement deux extr mit s communiquant l'une avec l'autre sur une connexion TCP 11 . Cette connexion est bidirectionnelle simultan e (full duplex ) et compos e de deux ots de donn es ind pendants et de sens contraire. Il est cependant possible d'inclure dans l'en-t te de segments TCP d'une communication de A vers B des informations relatives la communication de B vers A. Cette technique de superposition (piggybacking ) permet de r duire le tra c sur le r seau. Tout au long de la connexion, TCP change un ux d'octets sans qu'il soit possible de s parer par une marque quelconque certaines donn es. Le contenu des octets n'est pas du tout interpr t par TCP, c'est donc aux applications d'extr mit de savoir g rer la structure du ot de donn es. Si elles sont trop volumineuses, les donn es transmettre pour une application sont fractionn es en fragments dont la taille est jug e optimale par TCP. A l'inverse, TCP peut regrouper des donn es d'une application pour ne former qu'un seul datagramme de taille convenable de mani re ne pas charger inutilement le r seau. Cette unit d'information mise est appel e segment comme d j pr sent dans la gure 2.6. Certaines applications demandent que les donn es soient mises imm diatement, m me si le tampon n'est pas plein. Pour cela, elles utilisent le principe du push pour forcer le transfert. Les donn es sont alors mises avec un bit marquant cela pour que la couche TCP r ceptrice du segment remette imm diatement les donn es l'application concern e.
11 UDP permet lui de mettre en place du broadcasting et du multicasting (via le protocole IGMP) lorsqu'une application veut envoyer un unique message simultan ment vers plusieurs destinataires.
:

58

La abilit fournie par TCP consiste remettre des datagrammes, sans perte, ni duplication, alors m me qu'il utilise IP qui lui est un protocole de remise non able. Ceci est r alis l'aide de la technique g n rale de l'accus de r ception (ACK ) pr sent e de mani re simpli e dans la gure 2.24 Chaque
émetteur segment 1 ACK 1 récepteur émetteur segment 1 segment 1 récepteur émetteur récepteur

segment 2 segment 3

ACK1 devrait être reçu

ACK1 devrait segment 1 ACK 1 être reçu ACK 1 segment 1

ACK2+3 transmissions sans problème
Fig.

cas d’un paquet perdu

cas d’un paquet dupliqué

2.24 - changes de segments TCP.

segment est mis avec un num ro qui va servir au r cepteur pour envoyer un accus de r ception. Ainsi l' metteur sait si l'information qu'il voulait transmettre est bien parvenue destination. De plus, chaque envoi de segment, l' metteur arme une temporisation qui lui sert de d lai d'attente de l'accus de r ception correspondant ce segment. Lorsque la temporisation expire sans qu'il n'ait re u de ACK, l' metteur consid re que le segment s'est perdu 12 et il le r exp die. Mais il se peut que la temporisation expire alors que le segment a t transmis sans probl me, par exemple suite un engorgement de r seau ou une perte de l'accus de r ception correspondant. Dans ce cas, l' metteur r met un segment alors que c'est inutile. Mais le r cepteur garde trace des num ros de segments re us, donc il est apte faire la distinction et peut liminer les doublons. La gure 2.25 donne le format d'un segment TCP qui sert aux trois fonctionnalit s de TCP : tablir une connexion, transf rer des donn es et lib rer une connexion. L'en-t te, sans option, d'un segment
port source port destination numéro de séquence numéro d’accusé de réception
longueur d’en-tête

URG ACK PSH RST SYN FIN

réservé

taille de fenêtre pointeur d’urgence bourrage

checksum options (s’il y en a) données

Fig.

2.25 - Format du segment TCP.

TCP a une taille totale de 20 octets et se compose des champs suivants. - Le port source et le port destination identi ent les applications mettrice et r ceptrice. En les
12: Cela

peut arriver puisque la couche IP sous-jacente n'est pas able.

59

associant avec les num ros IP source et destination du datagramme IP qui transporte un segment TCP on identi e de mani re unique chaque connexion 13 . - Le num ro de s quence 14 donne la position du segment dans le ux de donn es envoy es par l' metteur c'est- -dire la place dans ce ux du premier octet de donn es transmis dans ce segment. - Le num ro d'accus de r ception contient en fait le num ro de s quence suivant que le r cepteur s'attend recevoir c'est- -dire le num ro de s quence du dernier octet re u avec succ s plus 1. De mani re pr cise, TCP n'acquitte pas un un chaque segment qu'il re oit, mais acquitte l'ensemble du ot de donn es jusqu' l'octet k ; 1 en envoyant un acquittement de valeur k. Par exemple, dans une transmission de 3 segments de A vers B, si les octets de 1 1024 sont re us correctement, alors B envoie un ACK avec la valeur 1025. Puis, si le segment suivant contenant les octets de 1025 2048 se perd et que B re oit d'abord correctement le segment des octets de 2049 3072, B n'enverra pas d'accus de r ception positif pour ce troisi me segment. Ce n'est que lorsque B recevra le deuxi me segment, qu'il pourra envoyer un ACK avec la valeur 3073, que A interpr tera comme l'acquittement des deux derniers segments qu'il a envoy s. On appelle cela un acquittement cumulatif. - La longueur d'en-t te contient sur 4 bits la taille de l'en-t te, y compris les options pr sentes, cod e en multiple de 4 octets. Ainsi une en-t te peut avoir une taille variant de 20 octets (aucune option) 60 octets (maximum d'options). - Le champ r serv comporte 6 bits r serv s un usage ult rieur. - Les 6 champs bits de code qui suivent permettent de sp ci er le r le et le contenu du segment TCP pour pouvoir interpr ter correctement certains champs de l'en-t te. La signi cation de chaque bit, quand il est x 1 est la suivante. . . . . . .
URG, le pointeur de donn es urgentes est valide. ACK, le champ d'accus de r ception est valide. PSH, ce segment requiert un push. RST, r initialiser la connexion. SYN, synchroniser les num ros de s quence pour initialiser une connexion. FIN, l' metteur a atteint la n de son ot de donn es.

- La taille de fen tre est un champ de 16 bits qui sert au contr le de ux selon la m thode de la fen tre glissante. Il indique le nombre d'octets (moins de 65535) que le r cepteur est pr t accepter. Ainsi l' metteur augmente ou diminue son ux de donn es en fonction de la valeur de cette fen tre qu'il re oit. - Le checksum est un total de contr le sur 16 bits utilis pour v ri er la validit de l'en-t te et des donn es transmises. Il est obligatoirement calcul par l' metteur et v ri par le r cepteur. Le calcul utilise une pseudo-ent te analogue celle d'UDP (voir la section 2.6.1). - Le pointeur d'urgence est un o set positif qui, ajout au num ro de s quence du segment, indique le num ro du dernier octet de donn e urgente. Il faut galement que le bit URG soit positionn 1 pour indiquer des donn es urgentes que le r cepteur TCP doit passer le plus rapidement possible l'application associ e la connexion.
13: Cette association (num ro IP, 14: C'est un entier non sign cod

port) est appel e socket. sur 32 bits qui retourne 0 apr s avoir atteint la valeur 231 ; 1.

60

- L'option la plus couramment utilis e est celle de la taille maximale du segment TCP qu'une extr mit de la connexion souhaite recevoir. Ainsi, lors de l' tablissement de la connexion il est possible d'optimiser le transfert de deux mani res. Sur un r seau haut d bit, il s'agit de remplir au mieux les paquets, par exemple en xant une taille qui soit telle que le datagramme IP ait la taille du MTU du r seau. Sinon, sur un r seau petit MTU, il faut viter d'envoyer des grands datagrammes IP qui seront fragment s, car la fragmentation augmente la probabilit de pertes de messages. L' tablissement et la terminaison d'une connexion suit le diagramme d' changes de la gure 2.26. L'extr mit demandant l'ouverture de la connexion, est le client. Il met un segment SYN (o le bit
client ouverture active serveur

SYN séq=N ACK=N+1 SYN séq=P ouverture passive

ACK=P+1 connexion établie

échanges de données demande de fin de 1/2 connexion FIN séq=N’ ACK séq=N’+1

information de l’application

FIN séq=P’ ACK séq=P’+1

demande de fin de 1/2 connexion terminaison de connexion

Fig.

2.26 - tablissemnet et terminaison d'une connexion TCP.

SYN est x 1) sp ci ant le num ro de port du serveur avec lequel il veut se connecter. Il exp die galement un num ro de s quence initial N . Cette phase est appel e ouverture active et consomme un num ro de s quence. Le serveur r pond en envoyant un segment dont les bits ACK et SYN sont x s 1. Ainsi, dans un m me segment il acquitte le premier segment re u avec une valeur de ACK=N + 1 et il indique un num ro de s quence initial. Cette phase est appel e ouverture passive. Le client TCP doit videmment acquitter ce deuxi me segment en renvoyant un segment avec ACK=P + 1 15 . La terminaison d'une connexion peut tre demand e par n'importe quelle extr mit et se compose de deux demi-fermetures puisque des ots de donn es peuvent s' couler simultan ment dans les deux sens. L'extr mit qui demande la fermeture (le client dans l'exemple de la gure 2.26 met un segment o le bit FIN est x 1 et o le num ro de s quence vaut N 0 . Le r cepteur du segment l'acquitte en retournant un ACK=N 0 + 1 et informe l'application de la demi-fermeture de la connexion. partir de l , les donn es ne peuvent plus transiter que dans un sens (de l'extr mit ayant accept la fermeture vers l'extr mit l'ayant demand e), et dans l'autre seuls des accus s de r ception sont transmis. Quand l'autre extr mit veut fermer sa demi-connexion, elle agit de m me que pr c demment ce qui entra ne la terminaison compl te de la connexion.
15 Un m canisme comportant 2 couples de segments (SYN, ACK SYN) g re le cas o deux demandes de connexion ont lieu en m me temps chacune dans un sens.
:

61

Le transfert de donn es de TCP est de deux types : le transfert interactif dans lequel chaque segment transporte tr s peu d'octets, voire un seul, et le transfert en masse o chaque segment transporte un maximum d'octets. Cette distinction est confort e par une tude de 1991 qui indique que la moiti des paquets TCP contient des donn es en masse (ftp, mail, news, ...) et l'autre moiti des donn es interactives 16 (telnet, rlogin, ...). Mais, 90% des octets transmis proviennent de donn es en masse et 10% seulement de donn es interactives car il appara t que 90% des paquets de telnet et rlogin comportent moins de 10 octets. Un exemple de transfert interactif est celui g n r par la commande rlogin lanc e depuis un client vers un serveur. Dans ce cas de gure, tous les caract res tap s par l'utilisateur sur le client sont envoy s vers le serveur en utilisant un caract re par segment, et ils sont ensuite renvoy s en sens inverse par le serveur pour un cho sur l' cran du client. Tous les segments chang s dans ce cas l ont leur bit PSH x 1. Or, tout segment doit tre acquitt dans un sens comme dans l'autre ce qui devrait amener au diagramme d' changes illustr dans le a) de la gure 2.27. En fait, TCP g re ce type
client client frappe de c c acquittement de c écho de c affichage de c acquittement de l’écho serveur frappe de c client c acquittement de c écho de c serveur frappe de d frappe de ate newline affichage de d d acquittement de d écho de d acquittement de l’écho ate newline acquittement et écho jusqu’à newline acquittement de l’écho acquittement des échos a) b) c) serveur

affichage de c délai d’attente

Fig.

2.27 - change de donn es interactif.

d' change avec la proc dure d'acquittement retard qui consiste envoyer l'acquittement en l'incluant dans un segment qui transporte galement des donn es comme illustr dans le b) de la gure 2.27. Pour cela l'acquittement est g n ralement retard de 200ms dans le but d'attendre d' ventuelles donn es transmettre. Cependant, dans ce contexte la frappe de la commande date sur le client provoquerait quand m me l' change de 15 datagrammes IP de 41 octets 17 , pour transporter chaque fois seulement 1 octet utile. Ce type de situation est peu g nant sur un LAN mais devient tr s vite pr judiciable au bon fonctionnement d'un WAN. Une solution ce probl me est l'algorithme de Nagle (RFC 896) qui sp ci e qu'une connexion TCP ne peut avoir seulement un petit segment non encore acquitt . Ainsi, si un r seau a un fort d bit et n'est pas du tout charg la proc dure sera celle du b) de la gure 2.27. Par contre, d s que le temps de transfert est non n gligeable, les acquittements vont arriver plus lentement que la frappe des caract res par l'utilisateur du poste client. Dans ce cas, la couche TCP du client va accumuler de petits volumes de donn es (quelques caract res) et les envoyer dans le m me segment TCP diminuant ainsi consid rablement le nombre d' changes comme illustr dans le c) de la gure 2.27. Dans les cas o de petits messages doivent tre remis sans d lai (mouvement de souris dans le cas d'un serveur X) l'algorithme de Nagle doit tre invalid pour donner une impression de temps r el. Dans le cas d'un transfert de donn es en masse, TCP utilise la technique de la fen tre glissante pour contr ler le ux des changes. Ceci est primordial quand un micro ordinateur communique avec un gros ordinateur, sinon le tampon d'entr e du micro sera tr s vite satur . Ceci consiste en un contr le de ux de bout en bout. Mais il s'agit aussi de r guler le tra c en fonction de la charge des routeurs et
16 Aujourd'hui cette statistique a volu tant donn l'importance du tra c de donn es de masses d au protocole http du web qui repr sente plus de 25% des paquets transmis en avril 95. 17 Pour chacun des 5 caract res d a t e newline, il faut 1 octet pour le caract re+20 octets d'en-t te TCP+ 20 octets d'en-t te IP.
: :

62

du d bit des r seaux travers s. On rappelle que l'ensemble d'un ux de donn es unidirectionnel d'une machine A vers une machine B est constitu d'une s quence d'octets tous num rot s individuellement. La fen tre glissante va consister xer quels sont les octets appartenant ce ux que A peut mettre comme c'est illustr dans la gure 2.28. Dans cet exemple la fen tre couvre les octets de 4 9, car
fenetre courante fenetre utilisable

2

3

4

5

6

7

8
octets prets

9

10

11

12

.....

octets émis et acquittés

octets émis et non acquittés

octets bloqués

Fig.

2.28 - Fen tre glissante de TCP.

la taille de la fen tre courante est 6 et que tous les octets jusqu'au troisi me inclus ont t mis et acquitt s. A tout instant TCP calcule sa fen tre utilisable qui est constitu e des octets pr sents dans
ouverture de la connexion 1 SYN séq=1000 MSS=1024 ACK=1001 WIN=4096 3 début 4 des transferts 5 6 ACK PSH 1001-2025 PSH 2025-3049 PSH 3049-4073 ACK=3049 WIN=4096 ACK=4073 WIN=3072 9 PSH 4073-5097 ACK=5097 WIN=4096 11 12 13 PSH 5097-6121 émis par 11 PSH 6121-7145 PSH 7145-8169 émis par 13 ACK=8169 WIN=4096 fermeture de la connexion 14 acquittés par 14 annoncée par 14 émis par 12 10 7 acquittés par 7 8 acquitté par 8 fenetre annoncée par 8 émis par 9 acquitté par 10 fenetre annoncée par 10 fenetre annoncée par 7 émis par 4 émis par 5 émis par 6 2 fenetre annoncée par segment 2 1001 2024 2025 3048 3049 4072 4073 5096 5097 6120 6121 7144 7145 8168

Fig.

2.29 - Exemple d' volution de fen tre glissante.

la fen tre et non encore envoy s. Ces octets sont g n ralement imm diatement transmis. Pour le ot de A vers B, la taille de la fen tre est contr l e par B qui envoie dans chacun de ses accus s de r ception la taille de la fen tre qu'il d sire voir utiliser. Si la demande exprime une augmentation, A d place le bord droit de sa fen tre courante et met imm diatement les octets qui viennent d'y entrer. Si la demande exprime une diminution, il est d conseill de d placer r ellement le bord droit de la fen tre vers la gauche. Ce r tr cissement est op r lors des glissements de la fen tre vers la droite avec l'arriv e des accus s de r ception. La gure 2.29 illustre 18 les changes de segments entre un metteur A et un r cepteur B et l' volution de la fen tre glissante de A suivant les indications de B.
18 Seules les informations n cessaires d tails sont omis.
:

la compr hension du processus de fen tre glissante sont pr sents, d'autres

63

2.7 Les applications.
On d crit ici de mani re succincte quelques applications majeures que l'on trouve sur Internet. Toutes ces applications sont b ties sur le mod le client-serveur savoir qu'une des deux extr mit s de la connexion (TCP UDP)/IP rend des services l'autre extr mit .
BOOTP (Bootsrap Protocol ) est un protocole de d marrage de terminaux X ou stations sans disque qui utilise UDP comme couche de transport et est g n ralement associ TFTP (voir 2.7.4) ou NFS (voir 2.7.3). Comme RARP (voir section 2.4.4), il sert principalement fournir son adresse IP une machine que l'on d marre sur un r seau. Cependant il est plus int ressant que RARP, car il se situe un niveau sup rieur, il est donc moins li au type de mat riel du r seau. De plus, il transmet plus d'information que RARP qui, lui, ne renvoie qu'une adresse IP. Un autre protocole, DHCP (Dynamic Host Con guration Protocol ) permet, lui, d'attribuer cette adresse IP dynamiquement, c'est- -dire que l'adresse IP a ect e la machine qui d marre peut changer d'un d marrage l'autre. BOOTP fait cela de mani re statique en utilisant un serveur (ou plusieurs) qui contient dans un chier l'adresse IP distribuer chaque machine. Le chier est maintenu jour par l'administrateur du r seau et contient pour chaque machine plusieurs informations comme illustr ci-apr s pour le terminal X de l'auteur.
# ......... # # ba -- broadcast bootp reply for testing with bootpquery # bf -- bootfile (for tftp download) # ds -- domain name server IP address # gw -- gateway IP address # ha -- hardware address (link level address) (hex) # hd -- home directory for bootfile (chrooted to tftp home directory) # hn -- send nodename (boolean flag, no "=value" needed) # ht -- hardware type (ether) (must precede the ha tag) # ip -- X terminal IP address # sm -- network subnet mask # tc -- template for common defaults (should be the first option listed) # vm -- vendor magic cookie selector (should be rfc1048) # T144 remote config file name (file name must be enclosed in "") # # H104 (Pascal Nicolas) prise I141 : tx-pn:\ ht=Ethernet:\ ha=0x08001103ec2c:\ bf=/usr/tekxp/boot/os.350:\ ip=193.49.162.63:\ sm=255.255.255.0:\ gw=193.49.162.220:\ vm=rfc1048:\ ds=193.49.162.9:

2.7.1 Protocole de d marrage : BOOTP.

Le format du message BOOTP est donn dans la gure 2.30. Le code vaut 1 pour une requ te et 2 pour une r ponse, le type de mat riel vaut par exemple 1 pour un r seau Ethernet et dans ce cas le champ longueur de l'adresse physique vaut 6 (octets). Le champ compteur de saut vaut 0 en standard, mais si la demande transite par un routeur celui-ci l'incr mente de 1. L'identi cateur de transaction est un entier de 32 bits x al atoirement et qui sert faire correspondre les r ponses avec les requ tes. Le nombre de secondes est x par le client et sert un serveur secondaire de d lai d'attente avant qu'il ne r ponde au cas o le serveur primaire serait en panne. Parmi les 4 adresses IP d'une requ te, le client remplit celles qu'il conna t et met les autres 0 (g n ralement il n'en connait aucune). Dans sa r ponse, le serveur indique l'adresse IP de la machine client dans le champ votre adresse IP et sa propre adresse dans le champ adresse IP du serveur. Il peut aussi donner son nom termin par le caract re nul. Si 64

code

type de matériel

longueur adresse matériel

compteur de saut

id. de transaction nombre de secondes adresse IP du client votre adresse IP adresse IP du serveur adresse IP du routeur adresse matérielle du client nom de machine du serveur nom du fichier de boot information spécifique du vendeur non utilisé

Fig.

2.30 - Format de requ te ou r ponse BOOTP.

un proxy est utilis , celui-ci indique son adresse dans le champ pr vu. Le champ adresse mat rielle du client sert celui-ci pour y indiquer son adresse physique. Ainsi cette adresse sera plus facilement disponible pour le processus BOOTP serveur que celle plac e dans la trame Ethernet. Le nom du chier de boot est le nom du chier transmis par le serveur au client pour que celui-ci puisse ensuite continuer son d marrage. La derni re partie du message est r serv e des caract ristiques particuli res donn es par chaque constructeur de mat riel et permet d'ajouter des fonctionnalit s suppl mentaires. Quand il met une requ te BOOTP, le client l'encapsule dans un datagramme UDP en xant le port source 68 et le port destination (celui du serveur) 67. Dans la majorit des cas, il ne sait pas pr ciser la valeur de l'adresse IP de destination et la xe donc glae 255.255.255.255 l'adresse de di usion. Ainsi, la trame Ethernet correspondante sera di us e toutes les machines du r seau et gr ce au num ro de port seuls le(s) serveur(s) BOOTP re oit le message et le traite. Pour cela, il consulte la table de correspondance et retourne sa r ponse en y xant l'adresse IP du client, le nom du chier t l charger et l'adresse IP du serveur. Il reste un probl me r gler. Lors de l' mission du datagramme IP contenant la r ponse, la couche de liens doit tablir la correspondance adresse IP/adresse physique du client pour construire la trame physique mettre. Or, cette correspondance ne peut tre connue dans la table ARP cet instant puisque la machine client d marre. Et si le logiciel de liens met une requ te ARP (voir section 2.4.4) la machine client ne sait pas r pondre puisqu'elle ne peut pas reconna tre son adresse IP qu'elle ne conna t pas encore. Il existe deux solutions ce probl me. Soit, le module BOOTP, qui dispose de cette correspondance, enrichit la table ARP avant d' mettre. Soit, il n'en a pas les droits et alors il di use la r ponse toutes les machines du r seau, mais cette solution est viter.

2.7.2 Connexion distance : Telnet et Rlogin.
Telnet et Rlogin sont deux applications qui permettent un utilisateur de se connecter distance sur un ordinateur, pourvu que cet utilisateur y dispose d'un acc s autoris . Ces deux applications permettent toutes les deux de prendre le contr le (du moins partiellement) d'un ordianteur distant, mais Rlogin ne permet de le faire qu'entre deux machines Unix, tandis qu'il existe des clients Telnet pour de nombreuses plateformes (Unix, Windows, MacOs, ...). Telnet et Rlogin sont tous les deux b tis sur TCP. Le sch ma de fonctionnement de Telnet est donn dans la gure 2.31. Telnet d nit une interface de communication, le terminal virtuel de r seau, pour que clients et serveurs n'aient pas conna tre les d tails d'implantation de chaque syst me d'exploitation. De cette fa on, les changes se font dans un langage commun compris la fois par le client et le serveur qui n'ont qu' assurer une traduction de (ou vers) leur propre langage vers (depuis) ce langage cible.

65

client Telnet

serveur Telnet

login shell

driver de terminal noyau du SE

TCP/IP

TCP/IP

driver de pseudo terminal noyau du SE

utilisateur sur un terminal

Fig.

2.31 - Sch ma de focntionnement de l'application Telnet.

2.7.3 Syst me de chiers en r seau : NFS.
NFS (Network File System ) est un syst me qui permet de rendre transparente l'utilisation de chiers r partis sur di rentes machines. Son architecture g n rale est donn e dans la gure 2.32. NFS utilise principalement UDP, mais ses nouvelles implantations utilisent galement TCP. Lorsqu'un
processus utilisateur

accès local au fichier

client NFS

serveur NFS

accès local au fichier

TCP/UDP IP noyau client

TCP/UDP IP noyau serveur

disque local

disque local

Fig.

2.32 - Con guration client serveur de NFS.

processus utilisateur a besoin de lire, crire ou acc der un chier le syst me d'exploitation transmet la demande soit au syst me de chier local, soit au client NFS. Dans ce dernier cas, le client NFS envoie des requ tes au serveur NFS de la machine distante. Ce serveur s'adresse la routine locale d'acc s au chiers qui lui retourne le r sulat retransmis vers le client par la connexion UDP (ou TCP) IP. Il ne s'agit pas ici de transf rer un chier d'une machine l'autre mais simplement de le rendre disponible de mani re totalement transparente.

2.7.4 Transfert de chier : TFTP et FTP.
TFTP (Trivial File Transfert Protocol ) et FTP (File Transfert Protocol ) permettent tous les deux de transf rer des chiers d'une machine une autre. Cependant TFTP, b ti sur UDP, est beaucoup plus sommaire que FTP qui utilise TCP. L'utilisation de FTP depuis un poste client pour aller chercher ou d poser un chier sur un serveur n cessite de la part de l'utilisateur de se connecter avec un nom et un mot de passe. Donc, si l'utilisateur n'est pas reconnu la connexion FTP ne sera pas tablie. Dans le

66

cas particulier d'un serveur ftp public, la connexion se fait avec le nom anonymous et il est conseill de donner son adresse lectronique comme mot de passe. Dans le cas de TFTP, aucune authenti cation pr alable n'est n cessaire. C'est pourquoi, lorsqu'un serveur TFTP est install sur une machine il n'o re des possibilit s d'acc s qu' un nombre restreint de chiers bien sp ci ques. Ces chiers sont g n ralement des chiers de d marrage de terminaux X ou stations sans disque qui les r cup rent apr s en avoir t inform s par le protocole BOOTP (voir section 2.7.1). Les di rents messages TFTP sont donn s dans la gure 2.33 et se distingeunt selon leur code d'op ration.
RRQ / WRQ nom de fichier 0 mode 0

DATA

numéro de bloc

données (0-512 octets)

ACK

numéro de bloc

ERROR

numéro d’erreru

message d’erreur

0

Fig.

2.33 - Format des messages TFTP.

-

RRQ

indique une requ te de lecture de chier (transmis au client) et WRQ une requ te d' criture de chier (transmis au serveur). Ensuite, vient le nom du chier termin par un caract re nul. Le champ mode, termin par un caract re nul galement, est gal netascii pour indiquer que le chier est un chier texte o chaque ligne est termin e par CR LF. Ces deux caract res doivent peut- tre tre convertis dans la syntaxe utilis e par la machine locale pour marquer les ns de ligne des chiers textes. Il est gal octet dans le cas d'un chier binaire transf rer tel quel.
DATA

-

d bute les paquets de donn es transmettre. Un chier de N octets sera d coup en N div 512 tels paquets contenant chacun 512 octets de donn es et un paquet contenant N mod 512 octets qui sera reconnu comme le paquet nal puisqu'il contient moins de 512 octets. Le champ num ro de bloc sert num roter chaque paquet de donn es et est utilis pour l'accus de r ception.

- ACK indique que le message acquitte le bloc de num ro sp ci dans le message. TFTP est oblig de s'assurer lui m me de la bonne transmission des donn es puisqu'il utilise UDP qui est un protocole non able. Le protocole d'acquittement est de type stop-and-wait car apr s avoir envoy un paquet l' metteur attend l'accus de r ception du r cepteur avant d'envoyer le paquet suivant. Si l' metteur ne re oit pas d'acquittement avant l'expiration de son d lai d'attente il r exp die le paquet perdu. De m me, le r cepteur qui ne re oit plus de paquets apr s son d lai d'attente renvoie nouveau son acquittement. Seulement, si le ACK k est retard mais non perdu, l' metteur va retransmettre le paquet k que le r cepteur va nouveau acquitter. Donc, deux ACK k vont nalement parvenir l' metteur ce qui va d clencher de sa part l'envoi de deux paquets k + 1, qui provoqueront deux ACK k + 1 et donc l'envoi de deux paquest k+2, etc... - Les messages d butant par ERROR indiquent une erreur de transmission et transportent un code et un message d'erreur. Lorsque cela arrive, le transfert est imm diatement interrompu. Lorsqu'il demande une connexion le client s'attribue un port ph m re UDP et envoie sa requ te au serveur sur le port 69 pr vu pour FTP. ce moment-l , le serveur va s'attribuer un nouveau port ph m re qui devra tre d tect par le client et qui servira tout le temps de la connexion. Il ne conserve 67

pas le port 69 tout au long de l' change car cela l'obligerait soit refuser d'autres connexions pendant ce temps, soit les multiplexer ensemble ce qui alourdirait le protocole. Quant lui, FTP est d ni au-dessus de TCP et utilisent deux connexions TCP IP pour fonctionner comme illustr dans la gure 2.34. Tout d'abord on y voit que le client utilise FTP travers une interface
client

utilisation sur un terminal

interface utilisateur serveur interpréteur de protocole utilisateur

connexion de controle

interface de protocole du serveur

système de fichiers

fonctions de transfert de données

connexion de données

fonctions de transfert de données

système de fichiers

Fig.

2.34 - Tansfert de chier par FTP.

qui peut tre graphique (logiciels XFTP, WS-FTP, Fetch, ...) ou texte (mode commandes d'unix par exemple). La connexion de contr le est tablie de fa on normale en mode client serveur sur le port 21 du serveur et sur un port al atoire du client pour tout ce qui est de type transfert interactif. Elle sert donc tout le temps de la session transf rer les commandes du client et presque toutes les r ponses du serveur. La connexion de donn es sert transf rer les chiers et les contenus de r pertoires du serveur, c'est- -dire tous les transferts de masse. En e et, lorsque le client demande le contenu d'un r pertoire la r ponse peut tre tr s longue et il est pr f rable de l'envoyer sur cette connexion plut t que sur celle du transfert interactif. chaque fois qu'un chier doit tre transf r , dans un sens ou dans l'autre, le client initie une connexion de donn es en s'attribuant un port et envoie au serveur une demande de connexion sur la connexion de contr le. Le serveur se sert du num ro de port re u pour tablir la connexion de donn es entre son port 20 et ce port indiqu par le client.

2.7.5 Courrier lectronique : smtp.
Le courrier lectronique au sein d'Internet est g r par le protocole SMTP (Simple Mail Transfer Protocol ) b ti sur TCP (port 25). Il permet d' changer des messages entre un exp diteur et un (ou plusieurs) destinataire pourvu que leurs adresses soient connues. Une adresse de courrier lectronique se pr sente sous la forme nom@domaine est doit tre compos e de lettres (minuscules ou majuscules sont indi renci es), de chi res, de _ (soulign ) et de . (point). Il est noter qu'un m canisme d'alias permet de d nir des quivalences entre adresses, notamment de pr ciser quelle machine parmi toutes celles d'un m me domaine g re r ellement le courrier de chaque utilisateur. Une des caract ristiques principales du protocole SMTP est d'e ectuer une remise di r e du courrier qui assure que le service sera correctement rendu m me si le r seau ou l'ordinateur destinataire sont momentan ment en panne ou surcharg s. Pour cela le syst me de messagerie fonctionne de la mani re d crite en gure 2.35. Un courrier exp di par un utilisateur est d'abord copi dans une m moire de spool accompagn des noms de l'exp diteur, du r cepteur, de l'ordinateur destinataire et de l'heure de d p t. Puis le syst me de messagerie active en t che de fond le processus de transfert de courrier qui devient un client. Il associe le nom de l'ordinateur destinataire une adresse IP et 68

utilisateur envoyant un courrier

zone de spool pour le courrier sortant

client expédition en tache de fond

logiciel de courrier électronique utilisateur

connexion TCP

utilisateur lisant un courrier

zone de spool pour le courrier entrant

serveur acceptant le courrier

Fig.

2.35 - Sch ma d'une messagerie SMTP.

tente d' tablir une connexion TCP avec le serveur SMTP de celui-ci. Si cela r ussit, le processus de transfert envoie une copie du message au destinataire qui l'enregistre dans une zone de spool sp ci que. Lorsque le client et le serveur se sont con rm s l'envoi et l'enregistrement complet du message le client supprime sa copie locale. Si le client n'arrive pas tablir une connexion TCP, ou si elle est rompue lors du transfert d'un message, il enregistre l'heure de cette tentative et r essaye quelque temps plus tard d'exp dier le message. D'une mani re g n rale un syst me de messagerie examine r guli rement sa zone de spool en envoi et tente d'exp dier les messages (nouveau ou en attente cause d' chec) qui s'y trouvent. Il nira par retourner son exp diteurun message impossible exp dier apr s un d lai important. Ce mode de fonctionnement ( tablir une connexion de bout en bout) assure qu'aucun message ne peut se perdre, soit il est d livr , soit son exp diteur est pr venu de l' chec. Le tableau ci-dessous donne le d tail d'une connexion TCP r ussie qui envoie un message de l'utilisateur toto@expediteur.fr dont le courrier est g r par l'ordinateur exp.expediteur.fr vers l'utilisateur titi@destinataire.fr dont le courrier est g r par l'ordinateur dest.destinataire.fr. La premi re colonne d crit les tapes, la deuxi me (respectivement troisi me) colonne indique les commandes envoy es par l'exp diteur (respectivement destinataire) du courrier.
client demande une connexion TCP sur le port 25 exp.destinataire.fr dest accepte la demande de connexion exp s'identi e dest accepte l'identi cation
exp.expediteur.fr exp.expediteur.fr

SMTP

exp diteur

sur serveur

exp.destinataire.fr

SMTP

destinataire

sur

220 dest.destinataire.fr ... HELO exp.expediteur.fr 250 dest.destinataire.fr Hello exp.expediteur.fr pleased to meet you MAIL From:<toto@expediteur.fr> 250 <toto@expediteur.fr>Sender Ok RCPT To:<titi@destinataire.fr 250 <titi@destinataire.fr>Recipient Ok

indique l'exp diteur accepte l'exp diteur donne le destinataire a v ri et accept le destinataire exp va envoyer les donn es dest est pr t accepter le message exp envoie le message termin par une ligne ne contenant qu'un point.
exp dest exp dest

DATA bla, blabla .
QUIT

354 Enter mail, end with ...

accepte le message demande terminer la connexion dest accepte de terminer la connexion
dest exp

250 OK

221 dest.destinataire.fr closing connection

69

2.7.6 News : nntp
NNTP (Network News Transfert Protocol ) est le protocole d' change des news 19 ou forums de discussions travers Usenet (nom donn au r seau logique constitu des serveurs de news diss min s sur la pan te). Comme illustr dans la gure 2.36, il assure l' change des news entre les serveurs et galement la communication entre serveur et postes clients aussi bien pour la lecture que pour l' criture de messages.

serveur de news

poste client

serveur de news

poste client

poste client

serveur de news

Fig.

2.36 - Communication au sein de Usenet.

Ainsi, lorqu'un utilisateur poste un article dans un groupe de news, il est dans un premier temps d pos sur le serveur de news auquel le poste client est reli . Puis, ce serveur va r exp dier cet article aux di rents serveurs auxquels il est reli , qui eux-m mes proc deront de la sorte. Ainsi, en quelques heures un message post Angers peut se retrouver sur un serveur de news en Australie. Mais, ce processus de di usion syst matique, n'est pas assur pour tous les groupes de news existant au niveau mondial, car chaque serveur de news n'assure le relai que de certains groupes. En e et, il n'est peut- tre pas tr s utile de di user sur les serveurs de news japonais le groupe fr.petites-annonces.automobiles :-). De plus, tout serveur de news xe pour chaque groupe la dur e de conservation des messages sur ses disques durs. De mani re plus technique, NNTP utilise TCP via le port 119, le client envoyant une commande ASCII laquelle le serveur r pond par un code num rique ventuellement suivi par des donn es. Ces donn es sont dispos es sur plusieurs lignes termin es chacune par CR/LF et termin es par une ligne r duite un point. Tout d'abord il faut savoir qu'un serveur de news ne r pond pas syst matiquement toutes les requ tes des postes clients, mais uniquement celles provenant de machines qu'il autorise, par exemple celles de son domaine. Ceci est illustr ci-apr s o l'on voit que le serveur de news news.univ-angers.fr accepte la connexion depuis une machine situ e en Allemagne uniquement pour la lecture des news et
19 Le contenu des news, la description des groupes et l'utilisation pratique d'un logiciel lecteur de news est suppos e connue ici.
:

70

accepte la lecture et l' criture de messadepuis une machine situ e sur son r seau.
brehat.haiti.cs.uni-potsdam.de]telnet news.univ-angers.fr 119 Trying 193.49.144.4... Connected to news.univ-angers.fr. Escape character is '^]'. 201 univ-angers.fr InterNetNews NNRP server INN 1.7.2 08-Dec-1997 ready (no posting). helios]telnet news.univ-angers.fr 119 Trying 193.49.144.4... Connected to news.univ-angers.fr. Escape character is '^]'. 200 univ-angers.fr InterNetNews NNRP server INN 1.7.2 08-Dec-1997 ready (posting ok).

La liste des commandes connues d'un serveur de news peut- tre obtenue en l'interrogeant au moyen de la commande help, comme d crit ci apr s.
help 100 Legal commands authinfo user Name|pass Password|generic <prog> <args> article MessageID|Number] body MessageID|Number] date group newsgroup head MessageID|Number] help ihave last list active|active.times|newsgroups|distributions|distrib.pats|overview.fmt|subscriptions] listgroup newsgroup mode reader newgroups yymmdd hhmmss "GMT"] <distributions>] newnews newsgroups yymmdd hhmmss "GMT"] <distributions>] next post slave stat MessageID|Number] xgtitle group_pattern] xhdr header range|MessageID] xover range] xpat header range|MessageID pat morepat...] xpath MessageID Report problems to <newsmaster@univ-angers.fr@news.univ-angers.fr> .

Quant aux codes de r ponses du serveur de news, ils sont d crits dans la table 2.2. Le r le de quelques commandes de NNT est illustr ci-apr s en interrogeant le serveur news.univ-angers.fr.
list

retourne la liste des groupes de news, en indiquant leur nom, le num ro de l'article le plus r cent, le num ro de l'article le plus ancien encore conserv , et la lettre y si le postage est libre ou m s'il est control par un mod rateur.
list

71

code 1yz 2yz 3yz 4yz 5yz x0z x1z x2z x3z x4z x8z x9z
Tab.

description information requ te accept e d but de requ te correcte, la suite eut tre envoy e requ te correcte, mais non trait e requ te incorrecte, non implant e ou erreur fatale connexion, mise en place et divers choix des groupes de news choix des articles fonctions de distributions postage extension non standard sortie de debug

2.2 - Signi cation des 2 premiers chifres des codes de r ponses de NNTP

215 Newsgroups in form "group high low flags". control 0001251116 0001053999 y junk 0000000486 0000000480 y bionet.agroforestry 0000002281 0000002229 y bionet.announce 0000000165 0000000116 m .... group

xe un groupe courant et renvoie une estimation du nombre d'articles dans le forum, le num ro de l'article le plus ancien, celui de l'article le plus r cent et le nom du groupe.

group fr.comp.os.linux 211 6543 27618 34211 fr.comp.os.linux

La di rence 34211-27618=6593 est plus grande que 6543 car tous les messages ne sont pas forc ment conserv s aussi longtemps les uns que les autres. Si le nom du groupe est erron on obtient ceci :
group fr.comp.linux 411 No such group fr.comp.linux head

envoie les en-t tes d'un article dont le num ro est sp ci .

head 34205 221 34205 <3634E2EC.9B76A7E8@cern.ch> head Path: univ-angers.fr!enst!isdnet!newsgate.cistron.nl!het.net!news.belnet.be! news-zh.switch.ch!news-ge.switch.ch!cern.ch!news From: Nuno DOS SANTOS <Nuno.Dos.Santos@ces20s15ss15s12s9s3s4s5s Newsgroups: fr.comp.os.linux Subject: Instal carte de son Date: Mon, 26 Oct 1998 22:00:28 +0100 Organization: CERN Lines: 10 Message-ID: <3634E2EC.9B76A7E8@cern.ch> NNTP-Posting-Host: pcst101.cern.ch Mime-Version: 1.0

72

Content-Type: text/plain charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sunnews.cern.ch 909435628 12357 (None) 128.141.182.63 X-Complaints-To: news@sunnews.cern.ch X-Mailer: Mozilla 4.05 en] (Win95 I) Xref: univ-angers.fr fr.comp.os.linux:34205 . body

retourne le coprs de l'article dont le num ro est sp ci .

222 34205 <3634E2EC.9B76A7E8@cern.ch> body Salut, J'arrive pas a instaler ma carte de son SB PCI awe64. Dans le HOW-TO ils parlent toujours de make config, xconfig, etc., mais la commande make ne passe pas. Il me donne l'erreur "make:*** No rule to make target 'xconfig'. Stop.". Le fichier sndstat est vide. Vous pouvez m'aider? Une sugestion? Merci .

Le point nal ne fait pas partie du message mais est envoy par NNTP pour terminer sa r ponse
HTTP (HyperText Transfer Protocol ) est le protocole de communication du web 20 permettant d' changer des documents hypertextes contenant des donn es sous la forme de texte, d'images xes ou anim es et de sons. Tout client web communique avec le port 80 d'un serveur HTTP par l'interm diaire d'une, ou plusieurs, connexions TCP simultan es, chacune des connexions TCP ouvertes servant r cup rer l'un des composants de la page web. Trois types de requ tes sont disponibles GET url renvoie l'information sp ci e par l'url.

2.7.7 World Wide Web : http..

renvoie l'en-t te de l'information demand e et non pas le contenu du document. POST pour envoyer du courrier lectronique, des messages de news, ou des formulaires interactifs remplis par l'utilisateur. La requ te du client se compose de lignes de texte ASCII termin es par les caract res CR/LF et organis es comme ci-apr s :
HEAD url requ te url-demand HTTP-version en-t tes (0 ou plus) <ligne blanche> corps de la requ te (seulement pour une requ te POST)

Une r ponse du serveur web se pr sente comme suit :
HTTP-version code-r ponse phrase-r ponse
20: L'utilisation

du web est suppos e connue ici.

73

code description 1yz non utilis succ s 200 OK, requ te r ussie 201 OK, nouvelle ressource cr e (commande POST) 202 requ te accept e mais traitement incomplet 204 OK, mais pas de contenu envoyer redirection ( g rer par le client) 301 le document demand a t d nitivement d plac vers une autre url 302 le document demand a t temporairement d plac vers une autre url 304 le document n'a pas chang (dans le cas d'un GET conditionnel) erreur du client 400 requ te mal formul e 401 interdit, la requ te n cessite une certi cation 403 interdit sasn raison s pci que 404 document non trouv erreur du serveur 500 erreur interne du serveur 501 non implant 502 mauvaise passerelle, r ponse invalide d'une passerelle 503 service temorairement indisponible
Tab.

2.3 - Codes de r ponses de HTTP

en-t tes (0 ou plus) <ligne blanche> corps de la r ponse

Les en-t tes de requ tes ou de r ponses ont la forme :
nom-de-champ: valeur

et se classent ainsi : en-t tes de requ te : authorization, date, from, if-modified-since, location, mime-version, pragma, referer,user-agent en-t tes de r ponse : date, location, mime-version, pragma, server, www.authenticate en-t tes de corps dans les r ponses HTTP ou les requ ts POST : allow, content-encoding, content-length, content-type, expires, last-modified Les codes de r ponses sont des nombres de 3 chi res rang s en 5 cat gories comme d crits dans la table 2.3. Ci -dessous est d crit un exemple de requ te et r ponse HTTP, apr s s' tre connect un serveur web, par exemple avec un client telnet.
helios|~>telnet www.yahoo.fr 80 Trying 195.67.49.47... Connected to www.yahoo.fr. Escape character is '^]'. get / http/1.0 HTTP/1.0 200 OK

74

Last-Modified: Mon, 26 Oct 1998 19:13:02 GMT Content-Type: text/html Content-Length: 13163 <head> <title>Yahoo! France</title> <base href="http://www.yahoo.fr/"> </head> <body> .... </body> </html>

2.8 Outils communs d'utilisation d'un r seau sous Unix.
Le but de cette section est de d crire les principaux chiers de con guration et les principales commandes relatives l'utilisation du r seau Internet depuis une machine unix. Elle sert de support des manipulations devant ordinateur. On ne d crit pas ici les commandes li es aux services Internet les plus classiques : mail, ftp, web, news... qui sont pr sent es par ailleurs. Les informations donn es ici sont relatives la machine vega.info.univ-angers.fr (un Linux BiPentium Pro, 200Mhz, 256 Mo) n novembre 1997.

2.8.1 Fichiers de con guration.
/etc/hosts

Il est structur sous la forme
adresse IP nom de machine liste d'alias commentaire
127.0.0.1 193.49.162.1 193.49.162.2 193.49.162.10 193.49.162.4 localhost vega.info.univ-angers.fr vega sirius.info.univ-angers.fr sirius moinefou.info.univ-angers.fr moinefou helios.info.univ-angers.fr helios

Il assure la correspondance (nom, adresse IP). S'il existe un serveur de noms sur cette machine, il contient tr s peu de lignes et ne sert qu'au d marrage de la machine avant que le serveur de noms ne soit lanc . Si le serveur de noms est sur une machine distante il ne contient que les machines du r seau local. Celui de la machine moinefou se pr sente de la mani re suivante
127.0.0.1 193.49.144.1 193.49.144.220 193.49.162.1 193.49.162.2 193.49.162.10 193.49.162.4 localhost loopback lagaffe gw-info vega.info.univ-angers.fr vega sirius.info.univ-angers.fr sirius moinefou helios

dans lequel est sp ci e l'adresse d'une passerelle (gateway d'adresse IP qui se termine par .220) laquelle est renvoy tout paquet qui n'appartient pas au r seau local 193.49.162.0. 75

/etc/resolv.conf domain info.univ-angers.fr search info.univ-angers.fr univ-angers.fr etud.univ-angers.fr nameserver 193.49.162.9 nameserver 193.49.144.1

Il pr cise le domaine d'appartenance de la machine, les noms de domaines avec lesquels compl ter le nom d'une machine pour conna tre son nom complet, ainsi que les adresses de serveurs de noms interroger.
/etc/protocols ip icmp igmp ggp tcp pup udp idp raw 0 1 2 3 6 12 17 22 255 IP ICMP IGMP GGP TCP PUP UDP IDP RAW # # # # # # # # # internet protocol, pseudo protocol number internet control message protocol internet group multicast protocol gateway-gateway protocol transmission control protocol PARC universal packet protocol user datagram protocol WhatsThis? RAW IP interface

Il contient la liste des protocoles connus et utilis s dans Internet sous la forme
nom du protocole num ro du protocole liste d'alias commentaire
/etc/services ..... 15/tcp 17/tcp 19/tcp 19/udp 20/tcp 21/tcp 23/tcp 25/tcp 37/tcp .....

netstat qotd chargen chargen ftp-data ftp telnet smtp time

quote ttytst source ttytst source

mail timserver

Il contient la liste des services Internet connus sous la forme
nom du service num ro de port/protocole liste d'alias commentaire
/etc/inetd.conf ..... tcp tcp tcp .....

ftp telnet gopher

stream stream stream

nowait nowait nowait

root root root

/usr/sbin/tcpd /usr/sbin/tcpd /usr/sbin/tcpd

in.ftpd -l -a in.telnetd gn

Il contient les liens entre nom de services et ex cutables r alisant ce service. 76

2.8.2 Quelques commandes utiles

Les commandes sont illustr es avec leur r sultats apr s les avoir lanc es sur vega.info.univ-angers.fr. Il est conseill d'utiliser la commande man du syst me pour obtenir de plus amples informations sur celles-ci.
hostname rusers

retourne le nom de la machine.

(rwho est une commande similaire) renvoie la liste des utilisateurs connect s sur les machines du r seau local.
finger

renvoie des informations sur un utilisateur, en utilisant s'ils existent les chiers .plan et .project.
ping

permet de tester l'accessibilit d'une machine. Elle envoie une requ te ICMP (echo) destination d'une machine cible, sp ci e par son nom ou son adresse IP, qui lui retourne une r ponse ICMP (echo). Si une machine ne r pond pas au ping, elle est inutilisable pour toute autre application.
|vega|~>ping babinet PING babinet.univ-angers.fr (193.49.163.20): 56 64 bytes from 193.49.163.20: icmp_seq=0 ttl=254 64 bytes from 193.49.163.20: icmp_seq=1 ttl=254 64 bytes from 193.49.163.20: icmp_seq=2 ttl=254 data bytes time=1.7 ms time=1.7 ms time=1.6 ms

--- babinet.univ-angers.fr ping statistics --3 packets transmitted, 3 packets received, 0\% packet loss round-trip min/avg/max = 1.6/1.6/1.7 ms

Ping renvoie galement le num ro de la s quence ICMP ex cut e, la valeur du champ TTL et le temps d'aller-retour entre les deux machines. Elle peut le faire car dans le paquet exp di pour la requ te elle place son heure d' mission et lorsqu'elle re oit la r ponse elle la soustrait de l'heure syst me. Puis, en n d'ex cution (provoqu e par l'utilisateur ou suite l'envoi du nombre de paquets sp ci s), quelques donn es statistiques sont a ch es permettant d' valuer la qualit de la liaison.
traceroute

renvoie la route prise par des paquets pour atteindre une destination. Elle utilise le champ TTL (Time to Live) des paquets IP transmis selon le protocole UDP. Ce champ est d cr ment d'une unit chaque travers e de routeur, et normalement devrait tre d cr ment galement quand il stationne trop longtemps dans un routeur. Quand un routeur re oit un paquet IP avec un TTL = 1 (ou 0), il le d truit et renvoie le message ICMP time exceeded l'exp diteur. Ce message ICMP contient l'adresse IP du routeur qui le produit. Pour conna tre le chemin reliant une machine A une machine B, le programme traceroute de A envoie donc destination de B un premier paquet IP avec un champ TTL gal 1. Ainsi le premier routeur lui renvoie un paquet ICMP avec son adresse. Traceroute renvoie alors un 2e paquet destination de B avec un TTTL = 2, celui-ci sera refus par le 2e routeur, et ainsi de suite traceroute augmente le champ TTL jusqu' avoir travers tous les routeurs s parant A de B. Comme les messages ICMP contiennent les adresses des routeurs il su t de les visualiser chaque retour de message. Bien qu'en th orie 2 paquets se suivant ne prennent pas forc ment la m me route, ils le font la plupart du temps, c'est pourquoi traceroute donne des informations ables, en tous les cas au moment o on fait appel lui.
|vega|~>traceroute www.sciences.univ-nantes.fr

77

traceroute to www.sciences.univ-nantes.fr (193.52.109.12), 30 hops max, 40 byte packets 1 gw-maths.net.univ-angers.fr (193.49.162.220) 2.882 ms 3.246 ms 3.034 ms 2 193.52.254.254 (193.52.254.254) 4.638 ms 2.239 ms 2.298 ms 3 gw-ft.net.univ-angers.fr (193.49.161.1) 2.353 ms 2.419 ms 2.627 ms 4 angers.or-pl.ft.net (193.55.153.41) 4.027 ms 4.117 ms 13.75 ms 5 nantes.or-pl.ft.net (193.55.153.9) 8.747 ms 10.96 ms 7.499 ms 6 u-sciences-nantes.or-pl.ft.net (193.54.136.138) 14.468 ms 9.77 ms 16.273 ms 7 193.52.96.2 (193.52.96.2) 15.29 ms 13.83 ms 12.026 ms 8 www.sciences.univ-nantes.fr (193.52.109.12) 12.149 ms 9.715 ms 20.812 ms

30 hops signi e que l'on ne fera pas plus de 30 sauts. 40 octets pour le datagramme IP correspondent 20 octets pour l'en-t te IP, 8 octets pour l'en-t te UDP, 12 octets de donn es utilisateurs dont une copie du TTL et l'heure d' mission. On obtient en r sultat le TTL, le nom et l'adresse IP des routeurs interm daires (et de la machine destinatrice). Puis, comme pour chaque valeur de TTL, traceroute envoie 3 datagrammes IP, on obtient les temps d'aller (du paquet IP) et retour (du paquet ICMP). On peut donc conn tre le temps de transmission entre le routeur N et N+1 en faisnat la di rence des temps retourn s sur les lignes N+1 et N. Si on a une * c'est qu'il n'y a pas eu de r ponses dans les 5 secondes pour le paquet concern . Si on a toute une ligne d'*, c'est que les paquets ICMP de retour ne sont pas parvenus la machine A, par exemple car il ont t mis par B avec un TTL trop faible, ou qu'il ont tous mis plus de 5 sec revenir. arp permet de visualiser et modi er (si on a le droit) la table de translation adresses Ethernet/adresses Internet (pour plus de d tails consulter la section 2.4.4). Cette table est en fait un cache qui volue au fur et mesure des sollicitations des machines du r seau.
|vega|~>arp -a Address tx-fb.info.univ-angers. tektro1.info.univ-anger tx-bd.info.univ-angers. sirius.info.univ-angers helios.info.univ-angers kitsch.info.univ-angers moinefou.info.univ-ange tektro10.info.univ-ange gw-maths.net.univ-anger tx-pn.info.univ-angers. nslookup HWtype ether ether ether ether ether ether ether ether ether ether HWaddress 08:00:11:06:98:77 08:00:11:03:31:2D 08:00:11:06:97:21 00:20:AF:BB:BB:6A 08:00:20:88:0F:4E 08:00:09:6D:AE:6C 08:00:09:70:14:A3 08:00:11:03:31:35 00:20:DA:78:F9:39 08:00:11:03:EC:2C Flags C C C C C C C C C C Mask * * * * * * * * * * Iface eth0 eth0 eth0 eth0 eth0 eth0 eth0 eth0 eth0 eth0

permet d'interroger les serveurs de noms d'Internet. Elle fonctionne en mode interactif quand on l'appelle sans argument ou avec les arguments - nom ou adresse IP de machine, ce moment-l on obtient
|vega|~>nslookup Default Server: kitsch.info.univ-angers.fr Address: 193.49.162.9 >

o l'on a le nom du serveur de noms par d faut. Dans le mode interactif on obtient de l'aide sur les di rentes commandes l'aide de la commande ?.
> ?

78

$Id: nslookup.help,v 8.3 1996/08/05 08:31:39 vixie Exp $ Commands: NAME NAME1 NAME2 help or ? set OPTION all no]debug no]d2 no]defname no]recurse no]vc domain=NAME srchlist=N1 root=NAME retry=X timeout=X querytype=X port=X type=X class=X server NAME lserver NAME finger USER] root ls opt] DOMAIN -a -h -s -d -t TYPE view FILE exit (identifiers are shown in uppercase, ] means optional) - print info about the host/domain NAME using default server - as above, but use NAME2 as server - print info on common commands see nslookup(1) for details - set an option - print options, current server and host - print debugging information - print exhaustive debugging information - append domain name to each query - ask for recursive answer to query - always use a virtual circuit - set default domain name to NAME /N2/.../N6] - set domain to N1 and search list to N1,N2, etc. - set root server to NAME - set number of retries to X - set initial time-out interval to X seconds - set query type, e.g., A,ANY,CNAME,HINFO,MX,PX,NS,PTR,SOA,TXT,WKS - set port number to send query on - synonym for querytype - set query class to one of IN (Internet), CHAOS, HESIOD or ANY - set default server to NAME, using current default server - set default server to NAME, using initial server - finger the optional USER at the current default host - set current default server to the root > FILE] - list addresses in DOMAIN (optional: output to FILE) - list canonical names and aliases - list HINFO (CPU type and operating system) - list well-known services - list all records - list records of the given type (e.g., A,CNAME,MX, etc.) - sort an 'ls' output file and view it with more - exit the program, ^D also exits

whois permet d'interroger une base de donn es sur les r seaux et leurs administrateurs. Par d faut le serveur rs.internic.net est interrog , mais on peut sp ci er quel serveur whois on interroge, comme par exemple dans la commande suivante.
|vega|~>whois univ-angers.fr@whois.ripe.net bsdbase.ripe.net] \% Rights restricted by copyright. See http://www.ripe.net/db/dbcopyright.html domain: descr: descr: descr: admin-c: tech-c: tech-c: zone-c: univ-angers.fr Universite d'Angers 30, rue des Arenes 49035 Angers CEDEX 01, France Jacques Allo Olivier Girard Jean-Marie Chretien AR41

79

nserver: lagaffe.univ-angers.fr 193.49.144.1 nserver: biotheo.ibt.univ-angers.fr 193.49.145.60 nserver: resone.univ-rennes1.fr dom-net: 193.49.144.0 193.49.145.0 193.49.146.0 mnt-by: FR-NIC-MNT changed: Vincent.Gillet@inria.fr 970219 source: RIPE ........................ etc ....

On peut aussi utiliser whois
netstat

nom_de_personne@nom_de_serveur.

permet d'obtenir des statistiques sur le nombre de paquets, les erreurs, les collisions etc... sur une interface en donnant la liste de toutes les sockets ouvertes.
|vega|~>netstat -e|more Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address tcp 0 0 vega.info.univ-ang:1023 tcp 0 0 vega.info.univ-ang:1022 tcp 0 0 vega.info.univ-ang:1021 tcp 57 0 vega.info.univ-ang:1632 ........................ etc ....

Foreign Address helios.info.univ-an:993 helios.info.univ-a:1016 moinefou.info.uni:login istia.istia.univ-an:ftp

State ESTABLISHED ESTABLISHED ESTABLISHED CLOSE_WAIT

User root root frantz frantz

On obtient la table de routage par
|vega|~>netstat -rn Kernel IP routing table Destination Gateway 193.49.162.0 0.0.0.0 127.0.0.0 0.0.0.0 0.0.0.0 193.49.162.220

Genmask 255.255.255.0 255.0.0.0 0.0.0.0

Flags U U UG

MSS 1500 3584 1500

Window 0 0 0

irtt 0 0 0

Iface eth0 lo eth0

U route utilisable, G route indirecte visualise di rentes informations (selon les options de la commande) sur les paquets qui passent par l'interface r seau de la machine. C'est une commande r serv e root. Ci-dessous on a les 20 derniers paquets qui ont transit .
tcpdump
tcpdump -c 20 tcpdump: listening on eth0 12:41:15.069542 vega.info.univ-angers.fr.syslog > sirius.info.univ-angers.fr.syslog: udp 98 12:41:15.079542 vega.info.univ-angers.fr.1164 > tx-pn.info.univ-angers.fr.6000: . ack 965632022 win 31744 12:41:15.079542 vega.info.univ-angers.fr.6000 > helios.info.univ-angers.fr.47589: . ack 504866793 win 31744 12:41:15.069542 theo.maisel.int-evry.fr.6665 > vega.info.univ-angers.fr.1951: . 59767366:59768826(1460) ack 579761084 win 8760 (DF) 12:41:15.079542 vega.info.univ-angers.fr.1951 > theo.maisel.int-evry.fr.6665: . ack 4294963200 win 31744 tos 0x8] 12:41:15.079542 vega.info.univ-angers.fr.1164 > tx-pn.info.univ-angers.fr.6000: P 0:128(128) ack 1 win 31744 (DF) 12:41:15.079542 theo.maisel.int-evry.fr.6665 > vega.info.univ-angers.fr.1951: P 1460:2636(1176) ack 1 win 8760 (DF) 12:41:15.079542 vega.info.univ-angers.fr.1951 > theo.maisel.int-evry.fr.6665: . ack 4294963200 win 31744 tos 0x8] 12:41:15.079542 vega.info.univ-angers.fr.1953 > kitsch.info.univ-angers.fr.domain: 53323+ (43) 12:41:15.079542 vega.info.univ-angers.fr.nfs > moinefou.info.univ-angers.fr.131f35e: reply ok 128 12:41:15.089542 vega.info.univ-angers.fr.1909 > tx-is.info.univ-angers.fr.6000: . ack 720241486 win 31744 12:41:15.089542 kitsch.info.univ-angers.fr.domain > vega.info.univ-angers.fr.1953: 53323* 1/2/2 (181) 12:41:15.089542 vega.info.univ-angers.fr.1954 > kitsch.info.univ-angers.fr.domain: 53324+ (43) 12:41:15.089542 moinefou.info.univ-angers.fr.131f35f > vega.info.univ-angers.fr.nfs: 144 getattr |nfs] 12:41:15.089542 vega.info.univ-angers.fr.nfs > moinefou.info.univ-angers.fr.131f35f: reply ok 96 getattr |nfs] 12:41:15.089542 moinefou.info.univ-angers.fr.131f360 > vega.info.univ-angers.fr.nfs: 152 readdir |nfs] 12:41:15.089542 kitsch.info.univ-angers.fr.domain > vega.info.univ-angers.fr.1954: 53324* 1/2/2 (179) 12:41:15.089542 vega.info.univ-angers.fr.nfs > moinefou.info.univ-angers.fr.131f360: reply ok 376 readdir |nfs] 12:41:15.089542 vega.info.univ-angers.fr.1164 > tx-pn.info.univ-angers.fr.6000: P 128:256(128) ack 1 win 31744 (DF) 12:41:15.089542 vega.info.univ-angers.fr.1956 > kitsch.info.univ-angers.fr.domain: 53325+ (44)

80

tcpdump tcp port 21

ftp.

ne renverra que les paquets li s au protocole tcp sur le port 21, savoir

tcpdump arp

ne renverra que les paquets li s au protocole arp.

81

Chapitre 3

Applets Java.
Ce chapitre est trait lors de travaux dirig s et travaux pratiques et aborde les g n ralit s n cessaires l' criture d'applets.

82

Chapitre 4

Installation d'un intranet
Ce chapitre est trait lors d'une s ance de travaux pratiques qui consiste en l'intallation d'un syst me Linux RedHat ( partir du serveur ftp.univ-angers.fr) et la con guration rapide des services r seaux (web, news, mail, ftp, ...).

83

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->