Chapitre 6 Réseaux

Introduction

La question des réseaux informatiques et celle des systèmes d'exploitation sont en principe distinctes, et elles forment dans les cursus universitaires des disciplines particulières, mais les ordinateurs contemporains sont pratiquement toujours connectés à des réseaux de quelque sorte, et les techniques qui leur permettent d'y accéder sont tellement intimement enfouies au coeur du système qu'il n'est guère possible de parler de celui-ci sans aborder ceux-là. De surcroît, des systèmes sont apparus qui mettent à profit le réseau pour regrouper plusieurs ordinateurs et les considérer comme un seul multi-ordinateur, ou système distribué. Bref, s'il est de bonne méthode de distinguer l'architecture des ordinateurs, qui traite de l'organisation des éléments matériels des machines, l'architecture des systèmes d'exploitation, qui envisage la couche logiciel d'interface entre le matériel et les programmes de l'utilisateur, et l'architecture des réseaux, consacrée aux moyens de communication entre ordinateurs distants, il est clair qu'aucun de ces domaines ne pourra être traité sérieusement sans qu'il soit fait appel aux deux autres.

6.1 Transmettre de l'information à distance

Le problème de base à résoudre pour concevoir et réaliser un réseau d'ordinateurs consiste à établir un échange de données entre deux ordinateurs distants. Ce problème se divise en deux parties : pour que les données circulent correctement elles doivent être représentées selon un codage approprié commun aux deux extrémités, et il y faut un support physique également approprié.

La position de ce problème remonte au moins à Aristote, qui a envisagé la communication d'information entre deux personnes en termes de message et de code. Incidemment, ce modèle est beaucoup mieux adapté à la communication entre ordinateurs qu'à la communication entre êtres humains, qui est extraordinairement compliquée par tout un contexte (culturel, social, sensoriel) et par des éléments non verbaux (expressions du visage, intonations de la voix) qui rendent ce modèle, dans ce cas, assez inapproprié. « Le langage travestit la pensée. Et notamment de telle sorte que d'après la forme extérieure du vêtement l'on ne peut conclure à la forme de la pensée travestie; pour la raison que la forme extérieure du vêtement vise à tout autre chose qu'à permettre de reconnaître la forme du corps¹ ». Bref, pour les ordinateurs le modèle aristotélicien convient bien.

L'invention du téléphone a conduit à le formaliser sous le nom de « communication sur un canal bruité ». En effet il y a du bruit, c'est-à-dire qu'aucun canal de communication n'est parfait, certains éléments du message sont altérés ou perdus. Dans le cas du téléphone c'est tolérable jusqu'à un certain point, il en résulte quelques grésillements et bourdonnements ; Henrik Nyquist, dès les années 1920, et Claude Shannon[61] en 1948 ont posé les bases théoriques précises de ce que veut dire ici « jusqu'à un certain point », et ces bases constituent la théorie dite de l'information². Il va sans dire que pour transmettre de l'information codée sous forme numérique, les altérations des messages sont beaucoup moins tolérables. Nous allons dire quelques mots très sommaires de la théorie de l'information.

6.1.1 Théorie de l'information

Le transfert d'information dans un système de communication s'effectue par messages. Un message est une suite de signes (de symboles) tirés d'un alphabet. L'ensemble S = {m₁ ... m_i ... m_n} des messages que l'on peut former à l'aide d'un alphabet donné constitue une source (discrète) de messages : un texte est une suite de messages.

La notion d'information est liée à l'ignorance du destinataire quant aux messages émis depuis S : il n'y a apport d'information que si le destinataire ignore le contenu du message qu'il va recevoir. L'incertitude, quant à la teneur du message, est d'autant plus grande que le message a une faible probabilité d'être émis ; inversement, la réception de ce message contribue à lever une incertitude d'autant plus grande, et apporte donc une plus grande quantité d'information ; ainsi apparaît une relation entre la quantité d'information d'un message m_i et sa probabilité d'émission, p_i, relation représentée par la fonction logarithmique suivante³ :

I(m_i) = log_a(1/p_i) = - log_ap_i

I étant l'incertitude, ou l'information, a le nombre de symboles de l'alphabet utilisé. On en déduit immédiatement que la valeur de l'unité d'information est celle d'un message de probabilité 1/a. On prend généralement a = 2, l'unité correspondante étant le bit.

Pour donner un contenu plus facile à retenir à la formule ci-dessus, on peut utiliser les logarithmes décimaux, et regarder la quantité d'information transmise par un message émis avec une certaine probabilité :

probabilité d'émission	quantité d'information
p₁=1	I(m₁) = log₁₀ (1/p₁) = - log₁₀ 1 = 0
p₂=0,1	I(m₂) = log₁₀ (1/p₂) = - log₁₀ 10^-1 = +1
p₃=0,01	I(m₃) = log₁₀ (1/p₃) = - log₁₀ 10^-2 = +2
...	...

Cette définition probabiliste de la quantité d'information d'un message montre qu'elle dépend avant tout de la source de messages utilisée ; cette dernière peut être caractérisée par une quantité d'information (ou incertitude) moyenne, d'après l'expression :

H(S) = -

i=1

p_i × log_ap_i

qui permet d'évaluer a priori la quantité moyenne d'information que peut fournir un message ; sa valeur est maximale pour des messages équiprobables. Cette grandeur a la même forme que l'entropie thermodynamique et on l'appelle entropie de S.

L'entropie permet d'évaluer la richesse informationnelle d'un texte ; Shannon a montré que si l'information moyenne d'un alphabet de 27 signes équiprobables était : log₂ 27 = 4,75 bits/lettre, le contenu d'un texte anglais ordinaire n'était que de 1 bit/lettre, soit une redondance de : 1 - 1/4,75 , ou 80% de signes inutiles.

6.1.2 Premières réalisations

La transmission de données entre calculateurs a précédé l'invention de l'ordinateur proprement dit. En 1940 George Robert Stibitz travaillait depuis déjà quelques années à la conception et à la réalisation de calculateurs à relais électromécaniques pour les Bell Telephone Laboratories. Il avait organisé une démonstration de sa machine au Dartmouth College, dans le New Hampshire, où se tenait le congrès de la Société américaine de mathématiques, alors que le calculateur était à New York, à 330 km de là. Le matériel était très encombrant et le déménager compliqué et aléatoire : Stibitz décida de réaliser la démonstration à partir d'un télétype relié par une ligne téléphonique à la machine, ce qui fut fait le 11 septembre 1940 avec un total succès. Dès lors le « problème de base » pouvait être considéré comme résolu. On savait faire communiquer à distance deux machines à traiter de l'information.

Dans ce cas précis le support matériel de la communication était une ligne de téléphone en fils de cuivre, comme on en utilise encore aujourd'hui, mais les réseaux informatiques peuvent utiliser toutes sortes de supports matériel sans que cela modifie la nature du problème à résoudre : fibre optique, faisceau hertzien, canal satellite, câble coaxial, rayons infrarouge, signal laser etc. Il suffit que les équipements à chaque extrémité soient configurés correctement, de façon cohérente, ce qui d'ailleurs n'est pas une mince affaire.

6.1.3 Un modèle pour les réseaux

Considérons comme acquise la solution du problème de base, faire communiquer à distance deux machines à traiter de l'information. Avons-nous pour autant un réseau de telles machines ? Sans doute non. Le problème de l'acheminement d'un message dans un réseau complexe se compose de plusieurs sous-problèmes. Un groupe d'experts de l'ISO (Organisation Internationale de Normalisation) réuni de 1977 à 1986 sous la conduite d'Hubert Zimmerman a classé les sous-problèmes selon une échelle allant du plus concret (support physique de la communication) au plus immatériel (le logiciel de communication avec l'utilisateur). Il en est résulté un modèle en couches nommé OSI (pour Open Systems Interconnexion) conforme au principe exposé à la section 1.4, où la couche la plus basse correspond aux questions liées au support physique, et la plus haute au logiciel de contact avec l'utilisateur final ; nous allons examiner dans les sections suivantes les sous-problèmes selon la couche du modèle qui leur correspond.

Avant d'entamer la description du contenu et des fonctions de chaque couche du modèle OSI de l'ISO, il convient de préciser le vocabulaire employé pour décrire les réseaux. Un réseau sert communément à relier un certain nombre de points. De façon générale, un certain nombre de points reliés par des lignes constituent un graphe. Les points reliés sont appelés sommets (vertex en anglais) du graphe, et la ligne qui relie deux points est appelée arc (edge en anglais). Si l'arc qui relie un sommet A à un autre, B par exemple, relie également B à A, on dit que le graphe n'est pas orienté ; dans les graphes orientés les arcs ont un sens ; les graphes dont nous parlerons sont non orientés. La figure 6.1 représente un graphe non orienté G à sept sommets.

Figure 6.1 : Graphe connexe complet

Le graphe G, ou ABCDEFG, est tel qu'entre deux quelconques de ses sommets il existe au moins un chemin constitué d'arcs du graphe : un tel graphe est dit connexe. De surcroît, chaque sommet est relié par un arc à chacun des autres : c'est un graphe connexe complet. Chaque sommet est relié par un arc à chacun des n-1 autres sommets, et chaque arc joue le même rôle pour les deux sommets qu'il relie, G possède donc n × (n-1)/2 arcs.

Figure 6.2 : Graphe simplement connexe

La figure 6.2 représente un graphe H à sept sommets simplement connexe. Lorsque l'on parle de réseaux informatiques, il peut être commode de les représenter par des graphes. Les sommets sont alors généralement appelés noeuds du réseau, et les arcs, lignes ou liaisons.

6.2 Couche 1, physique

Étant donné un support physique approprié reliant deux matériels de traitement d'information, dits équipements terminaux, le premier sous-problème consiste à établir les conditions pour que chacun de ces deux équipements puisse émettre et recevoir des signaux en provenance de et destinés à l'autre. Il s'agit du « problème de base » vu plus haut, que G. Stibitz a été le premier à résoudre, et dont Nyquist et Shannon ont posé les bases théoriques, notamment en donnant le débit maximum d'information que peut assurer un canal donné.

En restant schématique, l'envoi d'informations se fait en modulant une onde hertzienne, ou en modifiant la tension électrique appliquée aux bornes d'un conducteur. La modification de la phase de l'onde ou de la tension est un signal élémentaire, en d'autres termes un bit, une unité d'information. Une telle modification ne peut intervenir qu'un certain nombre de fois par seconde, selon les caractéristiques du matériel. Cette fréquence maximum de variation définit la largeur de bande du canal, qui limite la quantité d'information qu'il peut acheminer.

La solution du sous-problème de la couche 1 fait appel à la physique, à l'électronique, au traitement du signal plus qu'elle ne constitue une question d'informatique à proprement parler, et nous ne nous y attarderons guère. Signalons simplement quels sont les types de supports les plus couramment utilisés pour édifier des réseaux informatiques :

Pour construire un réseau privé dans un immeuble ou sur un campus (LAN, pour Local Area Network), la solution classique consiste à poser de la fibre optique dès que les distances sont un peu grandes, de la paire torsadée téléphonique pour le câblage dit capillaire qui alimente les prises terminales. Les systèmes sans fil (hertzien ou infrarouge) sont aussi utilisés. Les débits peuvent atteindre le milliard de bits par seconde (Gigabit/s).
Les réseaux à longue distance ou WAN's (pour Wide Area Network), comme ceux des fournisseurs d'accès à l'Internet (FAI), ont recours à plusieurs types de solutions : location de lignes aux opérateurs de télécommunications ou aux propriétaires de réseaux d'autre nature (compagnies de chemin de fer, de distribution d'électricité, de métro...), construction d'infrastructures propres. Physiquement, la liaison est presque toujours de la fibre optique. Les débits sont de l'ordre du milliard de bits par seconde. Le satellite est peu utilisable à cause du délai de propagation, qui est d'un quart de seconde aller et retour (pour atteindre les antipodes il faut deux rebonds sur des satellites, soit une demi-seconde).
Pour l'accès des particuliers à leur FAI, l'usage de modems et du réseau téléphonique commuté ne disparaîtra pas tout de suite. Les accès dits à haut débit (câble TV ou ADSL sur réseau téléphonique) procurent un débit de l'ordre du million de bits par seconde (Mégabit/s).

Tous ces débits sont donnés à titre indicatif et très provisoire. Signalons aussi que dans certains cas la couche physique est capable d'acheminer des signaux simultanément dans les deux sens.

6.3 Notion de protocole

Pour acheminer un flux de données sur un canal de transmission, les systèmes matériels et logiciels qui composent le réseau utilisent un ensemble de règles, de conventions et de mises en forme des données qui constituent un protocole de communication. Une des fonctions des protocoles de communication est la détection et la correction des erreurs de transmission, qui constituent un des problèmes classiques des réseaux informatiques.

Les canaux de communication tels que les lignes téléphoniques sont soumis à des erreurs aléatoires, qui constituent le bruit. Pour une conversation cela provoque juste un parasite sonore désagréable, mais dans le cas de la transmission de données ce sera une altération de nature à rendre le message inutilisable. Il faut donc instaurer des moyens de vérifier l'intégrité des données et, quand c'est possible, de la restaurer quand elle a été altérée. Ceci devra être fait pour chaque couche du protocole de transmission, mais c'est spécialement important pour la couche 2, dont le rôle est de garantir aux couches supérieures un canal de transmission sans erreur d'un flux de bits. Le traitement de ce problème peut différer selon qu'il s'agit de liaisons point à point ou de diffusion.

Le protocole définit également, pour chaque couche, d'autres caractéristiques de la transmission : les messages sont généralement découpés en unités de taille homogène (appelés trames pour la couche 2 et paquets pour la couche 3), les noeuds reçoivent lorsque c'est nécessaire des adresses qui permettent, comme celles des personnes, de les trouver et de les identifier dans le réseau.

Nous pouvons nous représenter un protocole de communication comme un protocole au sens habituel ; quand deux entités du réseau entament une communication, l'échange se passe un peu comme ceci :

« Attention, je vais t'envoyer un message de plusieurs pages, es-tu prêt à le recevoir ?

--- Oui, je suis prêt.

--- Tu es sûr ?

--- Oui, je suis prêt.

--- Je vais envoyer.

--- Vas-y.

--- (Envoi de la première page, attachée à une flèche tirée à l'arc).

--- Bien reçue.

--- (Envoi de la seconde page, enroulée autour d'un caillou lancé avec une fronde).

--- Bien reçue.

--- (Envoi de la troisième page, confiée à un pigeon voyageur).

--- Bien reçue.

--- Normalement tu as dû recevoir trois pages numérotées de 1 à 3. Vérifie que tous les numéros sont là et dans le bon ordre.

--- Oui, j'ai bien reçu toutes les pages dans le bon ordre. »

Comme signalé à la section 1.4, dans un modèle en couches les protocoles définissent les règles du dialogue entre couches de même niveau sur des systèmes différents, cependant que les interfaces spécifient les services qu'une couche inférieure fournit à la couche qui lui est immédiatement supérieure au sein du même système.

6.4 Couche 2, liaison de données

La couche 2 du modèle de transmission de données, appelée couche de liaison de données, assure la transmission fiable d'un flux de bits entre deux noeuds adjacents du réseau sur un support physique procuré par la couche 1. Quand on dit adjacents, il faut entendre que les deux équipements terminaux sont connectés par un canal de transmission qui peut être vu comme un fil, c'est à dire que les bits émis à une extrémité sont délivrés exactement dans le même ordre à l'autre extrémité. Le travail de la couche 2 consiste à faire en sorte qu'ils soient également transmis sans omission ni déformation et remis à la couche 3. La figure 6.3 représente cette coopération des fonctions fournies par chaque couche⁴.

Figure 6.3 : Les trois couches basses

La liaison peut être établie de deux façons. La plus simple est la liaison point à point, c'est celle que vous utilisez quand vous vous connectez de votre domicile à l'Internet avec un modem. Le chemin entre votre modem et le modem de votre fournisseur d'accès est une liaison point à point, d'ailleurs gérée par le protocole PPP (Point to Point Protocol, comme son nom l'indique), c'est à dire que vous pouvez considérer ce lien logiquement comme un fil unique, même si le réseau téléphonique traversé est, du point de vue téléphonique, complexe. Derrière le modem du fournisseur d'accès (FAI), il y a bien sûr un réseau complexe qui n'est sans doute plus point à point. La liaison point à point est généralement le procédé utilisé pour les liaisons à longue distance qui constituent un réseau étendu, ou WAN (pour Wide Area Network), par opposition à un réseau local (LAN, pour Local Area Network), c'est-à-dire cantonné à un immeuble ou à un campus. Ces notions de longue distance et de localité sont toutes relatives, par exemple les réseaux d'accès à l'Internet des distributeurs de télévision par câble sont des réseaux locaux à l'échelle d'une ville comme Paris (on parle alors de réseau métropolitain).

Un réseau local est constitué différemment : un assez grand nombre de noeuds partagent une même infrastructure de câblage⁵, par exemple dans un bâtiment Cette infrastructure constitue un unique réseau d'acheminement, qui offre notamment un service de couche 2. Le réseau d'acheminement réunira un ou plusieurs réseaux de couche 2 et accédera à un réseau plus vaste de couche 3, par exemple l'Internet, par l'intermédiaire d'un ordinateur spécialisé appelée passerelle de couche 3, ou plus souvent routeur. Mais examinons pour l'instant les réseaux de couche 2. Nous pouvons les considérer comme des graphes connexes complets conformes à la figure 6.1, c'est-à-dire que chaque noeud peut « parler » directement à tous les autres noeuds du même réseau (de couche 2). Ces réseaux utilisent généralement la diffusion (broadcast), c'est-à-dire que l'émetteur envoie les signaux à tous les noeuds du réseau, à charge pour le destinataire de reconnaître ceux qui lui sont destinés par un procédé d'adressage décrit à la section suivante. C'est le cas des réseaux locaux de type Ethernet.

6.4.1 Notion d'adresse réseau

Dans le cas d'une liaison point à point, identifier le destinataire d'un message n'est pas difficile puisqu'il n'y a que deux noeuds en cause : l'émetteur à une extrémité, le récepteur à l'autre. Dans le cas de la diffusion, l'émetteur d'un message doit désigner le destinataire. Et au niveau de la couche 3, le réseau est complexe et contient généralement de nombreux noeuds qu'il faut identifier et atteindre. À cette fin chaque noeud se voit attribuer une adresse réseau. Aux couches 2 et 3 correspondent des visions différentes du réseau, et de ce fait elles possèdent des systèmes d'adressage distincts.

Adresse de couche 2

L'architecture des réseaux Ethernet, dont notamment leur système d'adressage, a été conçue par Xerox et réalisée par Xerox, Intel et Digital Equipment. Plus tard, l'IEEE (Institute of Electrical and Electronics Engineers) a promulgué la norme 802.3 censée décrire Ethernet, mais qui introduit quelques divergences qui obligent les industriels à s'adapter aux deux variantes, ce qui n'est pas trop compliqué.

Pour qu'un ordinateur puisse être connecté à un réseau Ethernet, il faut qu'il possède une interface matérielle qui se présente généralement sous la forme d'une carte dite carte réseau, ou NIC (Network Interface Card). Un ordinateur peut posséder plusieurs cartes réseau, pour être relié plusieurs fois au même réseau, ou à plusieurs réseaux de couche 2 différents, ce qui lui permet éventuellement de jouer le rôle de routeur, c'est-à-dire de faire passer les données d'un réseau à un autre.

Chaque interface réseau reçoit à sa fabrication une adresse de couche 2, dite « adresse MAC » (MAC pour Medium Access Control) ou adresse Ethernet, ou encore adresse physique (parce qu'associée à un dispositif matériel), de 48 bits de longueur. L'unicité à l'échelle mondiale des adresses MAC est assurée par l'IEEE, qui attribue à chaque industriel producteur un préfixe, charge à lui de gérer l'unicité des chiffres suivants. Ainsi l'adresse MAC de l'ordinateur que j'utilise en ce moment est 00:48:54:C0:C9:04, où chaque groupe de deux caractères isolé par « : » représente un octet codé en hexadécimal, soit une valeur décimale comprise entre 0 et 255 (voir annexe A section A.4.1 pour les détails de cette représentation). Ceci assure en principe qu'il n'y aura pas sur le réseau de dysfonctionnements provoqués par deux interfaces ayant la même adresse, mais en fait il est possible de modifier une adresse MAC dynamiquement par logiciel. Cela dit les logiciels raisonnables (et non piratés) ne font pas cela.

6.4.2 Détection et correction d'erreur pour la couche 2

Découpage en trames (framing)

La transmission de la voix par un procédé analogique se fait selon un flux continu de signaux, à l'image de la parole. La nécessité du contrôle d'intégrité des données impose pour la transmission de données numériques de procéder autrement. Pour les locuteurs de langues non écrites, la parole se manifeste comme un flux continu, et la conscience de son découpage en mots n'est pas de la même nature que pour les locuteurs de langues écrites qui ont dû apprendre à procéder mentalement à ce découpage (voir [36] pour de plus amples éclaircissements). De façon analogue, le flot de bits, que la couche 1 est prête à fournir à la demande, est découpé par les protocoles de couche 2 en entités discrètes de longueur limitée appelées trames (en anglais frame).

Le découpage du flot de données en trames est en fait plutôt une image : il nous faudra un moyen de reconnaître le début et la fin d'une trame. Les solutions raisonnables sont :

séparer les trames par des intervalles de « silence » ; cette solution est employée pour les réseaux locaux parce que le débit est élevé et la bande passante disponible à profusion ;
utiliser des trames de longueur soit fixe, soit variable mais connue en cours de transmission, et compter les bits ; cette solution et la suivante sont employées notamment pour les liaisons à longue distance ;
utiliser des configurations de bits particulières et inutilisées par le codage des données pour marquer le début et la fin de trames, et guetter leur occurrence.

Détection de trames endommagées

Les trames seront les entités dont les procédures de détection d'erreur vérifieront l'intégrité. Nous considérons ici, dans un premier temps, le traitement des trames qui arrivent à destination mais dont le contenu a été altéré par un parasite quelconque.

Le principe de base de la détection de ce type d'erreur est la redondance : avant d'émettre une trame, la station émettrice ajoute au message à transmettre (ici le contenu de la trame) une information supplémentaire calculée à partir des bits du message selon un algorithme dit de hachage (hash). À la réception, la station réceptrice effectue le même calcul ; si elle ne trouve pas le même résultat c'est qu'il y a eu une erreur. Cette information supplémentaire calculée à partir de l'information utile s'appelle somme de contrôle (en anglais checksum). L'algorithme de calcul de la somme de contrôle doit bien sûr être le même aux deux extrémités : cette convention fait partie du protocole. Une méthode très répandue est le code de redondance cyclique (CRC), dont nous ne donnerons pas le calcul ici.

Si le calcul prévu par la procédure donne le résultat attendu, il n'y a pas d'erreur et alors, dans le cas des réseaux longue distance (WAN), le protocole de couche 2 (côté récepteur) envoie un acquittement (conventionnellement ACK) à l'émetteur ; sinon il envoie par exemple un acquittement négatif (NAK) qui demande à l'émetteur de retransmettre la trame considérée. Pour savoir quelle trame est acquittée, le protocole prévoit aussi que chaque trame comporte un numéro de séquence permettant de la distinguer des précédentes et des suivantes. Ethernet procède sans échange d'acquittements : les détections d'erreur sont signalées par un signal de couche 1.

Il existe aussi des codes auto-correcteurs, dont le plus célèbre est le code de Hamming : au prix de plus de redondance, ces codes permettent de connaître précisément les positions des bits erronés, s'il n'y en a pas trop, et partant de les corriger. Cela semble séduisant mais n'est pas tellement utilisé, parce qu'en pratique on observe que les trames sont le plus souvent soit intactes, soit trop fortement endommagées pour être corrigées. De plus les trames endommagées sont rares sur la plupart des réseaux modernes, où les taux d'erreur sont de l'ordre de 10^-6, voire moins⁶. Il est plus efficace de retransmettre les données erronées.

Contrôle de flux

Les contrôles d'erreur évoqués à la section précédente faisaient l'hypothèse que les délais de transmission d'une trame et de l'acquittement en sens inverse étaient négligeables, ce qui est vrai pour un réseau local mais beaucoup moins pour une liaison à longue distance. Un protocole de couche 2 doit également se prémunir contre un autre risque : si un émetteur a une interface réseau beaucoup plus rapide que celle du récepteur, le récepteur ne pourra pas absorber toutes les trames qui lui sont envoyées et des données vont se perdre. Il faut donc un algorithme pour réguler les transmissions, et notamment s'assurer que les trames envoyées sont bien reçues.

La solution évoquée à la section précédente, qui consiste, avant d'envoyer une nouvelle trame, à attendre d'avoir reçu un acquittement positif pour la précédente, répond à la question, mais impose un ralentissement insupportable et une utilisation extrêmement inefficace de la bande passante. Cette inefficacité est particulièrement grande pour les liaisons par satellite géostationnaire, qui peuvent avoir un débit élevé mais un temps de transit incompressible de l'ordre d'un quart de seconde : s'il fallait attendre l'acquittement, on aurait un débit de deux trames par seconde, ce qui ne serait évidemment pas acceptable.

Pour améliorer cette situation, les protocoles adaptés aux liaisons à délai de transit important utilisent un algorithme basé sur le principe suivant : l'émetteur n'attend l'acquittement de la trame numéro n qu'après l'émission de la trame n+p, avec p>1. Le délai nécessaire à la transmission de p trames est appelé délai de garde (timeout interval). Cette méthode est appelée pipeline, parce que l'on enfourne les trames dans le « tuyau » sans attendre que les précédentes soient sorties. Comme à la section précédente, chaque trame est dotée d'un numéro de séquence qui permet de savoir, notamment, quelle trame acquitte tel ACK (dans le cas des protocoles WAN).

Mais alors, que va-t-il se passer si une trame, au milieu d'un long message, est corrompue ou n'arrive pas ? Rappelons que la couche 2 a pour mission de délivrer les trames dans l'ordre à la couche 3. Un tel cas est illustré par la figure 6.4, où nous supposerons p=3. Soit le cas d'école suivant : la trame 2 est émise, mais perdue ou détériorée en route. Le récepteur détecte le problème sans coup férir : si la trame est détériorée, par une des méthodes de détection d'erreur indiquées à la section précédente 6.4.2 ; si elle est perdue en route, le contrôle des numéros de séquence montre que la trame 1 devrait être suivie de la trame 2, or il reçoit à la place la trame 3 (ou une autre...), qui ne satisfait pas aux règles du protocole.

Dès que le récepteur constate la défaillance de la trame 2, il rejette imperturbablement toutes les trames que l'émetteur continue à lui envoyer. L'émetteur va-t-il s'en apercevoir ? Oui : après p émissions, soit après la trame n+p=2+3=5, il s'attend à recevoir l'acquittement de la trame 2, attente déçue. Que va-t-il faire alors ? Il va simplement réémettre la trame 2, puis toutes ses suivantes. Le récepteur va enfin recevoir la trame 2 attendue, il va l'accepter et l'acquitter, ainsi que les suivantes.

Figure 6.4 : Fenêtre glissante

Combien de trames ont été perdues ou rejetées ? p+1=4. Pour que l'algorithme soit correct, il faut que l'émetteur garde en mémoire au moins les p+1 dernières trames émises, afin de pouvoir les réémettre. Plus p sera grand, plus le protocole sera rapide, mais plus il faudra de mémoire dans les équipements de transmission, ce qui est un compromis constant pour les performances des ordinateurs et autres machines à traiter de l'information.

Du côté du récepteur, notre algorithme rejette toutes les trames consécutives à la trame détériorée : on pourrait imaginer de conserver les trames correctes qui arrivent après la trame détériorée. Ainsi lorsqu'à l'expiration du délai de garde l'émetteur constaterait qu'une trame n'a pas été acquittée, il n'aurait que celle-là à retransmettre. Bien sûr, tant que le récepteur n'a pas reçu la trame détériorée, il ne peut pas remettre les suivantes à la couche réseau, il doit donc les garder dans sa mémoire de travail (une telle zone de mémoire est appelée communément buffer). Le nombre de trames que le récepteur peut ainsi conserver définit la largeur d'une fenêtre de réception. Notre exemple initial, où toutes les trames consécutives à l'erreur étaient rejetées, correspond à une fenêtre de largeur 1. Le nombre de trames que l'émetteur s'impose de garder en mémoire en attendant leur acquittement s'appelle la fenêtre d'émission. Cet algorithme est nommé protocole de la fenêtre glissante.

La largeur des fenêtres, en émission et en réception, peut varier. Cet algorithme est dit de contrôle de flux : si l'émetteur constate que sa fenêtre d'émission est toujours vide, il peut augmenter son débit si c'est possible. Si le récepteur ne peut pas épuiser la fenêtre de réception, la fenêtre d'émission va se remplir et l'émetteur sera obligé de s'interrompre.

Ce protocole de fenêtre glissante, que nous venons de décrire pour la couche 2, est également utilisé pour la couche 4 de transport (TCP).

6.4.3 Un exemple de liaison de données : Ethernet

Si vous utilisez un réseau local à votre domicile ou sur votre lieu de travail, il y a de fortes chances (en 2002) que ce soit un réseau Ethernet. Cette technologie a supplanté la plupart des concurrentes, et de nos jours une carte réseau de ce type vaut une quinzaine d'Euros. L'auteur se rappelle la première « carte » Ethernet qu'il a achetée (pour le compte de son employeur) : elle avait coûté l'équivalent de 100 000 Euros et il avait fallu abattre une cloison pour loger l'armoire d'extension de 50 cm de large, 120 cm de hauteur et 70 cm de profondeur nécessaire à son installation. C'était un matériel DEC connecté à un VAX 11/750 sous VMS, en 1984.

Ethernet a été inventé au PARC (Palo Alto Research Center) de Xerox en 1973 par Robert Metcalfe et David Boggs. Le lecteur trouvera dans le livre de réseau de Tanenbaum [67] une description historique et technique détaillée. La première version commercialisée a été introduite en 1980 par Xerox, Intel et DEC. Le protocole a été normalisé par l'IEEE en 1983 sous la référence 802.3, toujours en vigueur.

Le nom Ethernet est un hommage à un ancêtre de ce protocole, ALOHA, inventé à l'Université d'Hawaï en 1970 par Norman Abramson. Comme Abramson voulait relier les campus de l'université, situés sur des îles différents, ALOHA était un protocole de réseau par radio, les communications circulaient dans l'éther.

Selon ALOHA, toutes les stations émettent et reçoivent sur la même bande de fréquence. Les messages sont découpés en trames, identifiées par un numéro d'ordre et l'adresse de la station destinataire. C'est une conversation à plusieurs : toutes les stations reçoivent toutes les trames, identifient celles qui leur sont destinées, jettent les autres.

La communication par radio entre sites distants interdit toute idée de contrôle centralisé : ALOHA doit prévoir le cas où deux stations (ou plus) voudraient commencer à émettre en même temps. Cette circonstance est nommée collision, et résulte en trames brouillées, incompréhensibles, en un mot perdues. Il va falloir réémettre ces trames perdues, et si possible en évitant de provoquer une nouvelle collision, sinon le protocole n'aboutira jamais.

Pour diminuer le risque de nouvelle collision, ALOHA utilise un algorithme probabiliste : chacune des stations qui a émis une trame perdue à cause de la collision calcule un nombre aléatoire, en déduit un intervalle de temps et réémet. La probabilité que deux stations aient calculé le même délai est très faible ; si néanmoins c'est le cas une nouvelle collision a lieu, et il faut réitérer le calcul. La probabilité que deux stations calculent trois fois de suite le même délai est tellement faible que cet algorithme, en pratique, fonctionne très bien. Il peut être encore amélioré au moyen d'une horloge centrale qui émet un signal dont la période est égale au délai de transmission d'une trame à travers le réseau : les trames ne peuvent être émises qu'au « top » d'horloge donné par ce signal. Cette discrétisation des émissions améliore l'efficacité du réseau en diminuant l'intervalle de temps minimum avant réémission en cas de collision.

Ethernet utilise le même principe qu'ALOHA : le support physique du réseau est accessible par toutes les stations simultanément, qu'il s'agisse d'un câble coaxial comme dans les années 1980, de liaisons en paires torsadées dans les années 1990, de fibre optique, d'un réseau hertzien, comme la mode (fort pratique mais avec quelques problèmes de sécurité induits) s'en répand en ce début de millénaire, de liaisons infra-rouges, etc. Il y a donc des collisions. Ethernet apporte deux perfectionnements par rapport à ALOHA :

les stations écoutent le trafic sur le câble avant d'émettre et, si le câble est occupé, observent un délai avant de réessayer ;
si une collision se produit, les émetteurs la détectent immédiatement et cessent d'émettre.

Ces améliorations confèrent au protocole Ethernet le qualificatif CSMA-CD (Carrier Sense Multiple Access with Collision Detection, ou accès multiple avec écoute de la porteuse et détection de collision).

Les aspects non déterministes, probabilistes, du protocole Ethernet ont pu inquiéter : et s'il y a sans arrêt des collisions, alors le réseau sera bloqué ? Les concurrents ont bien sûr mis à profit ces angoisses pour faire la promotion de leurs protocoles déterministes, beaucoup plus lourds et moins efficaces, tel Token ring d'IBM, aujourd'hui bien oublié. Le succès d'Ethernet, qui a été total, est un argument de plus pour croire aux résultats du calcul des probabilités.

La convergence des algorithmes d'Ethernet impose un certain nombre de contraintes sur la topologie et l'organisation physique des réseaux. Il faut notamment qu'une trame puisse traverser le réseau aller et retour selon son diamètre (c'est-à-dire entre les deux noeuds les plus « éloignés » l'un de l'autre) dans un délai aller et retour de 51,2 µs. Pour la première version d'Ethernet sur coaxial à 10 Mbps (mébibits par seconde), dite 10Base5, cette condition imposait qu'il n'y ait pas plus de 2,5 km de câble et pas plus de 4 répéteurs entre les noeuds. Un répéteur est un matériel de couche 1 qui possède plusieurs interfaces connectées chacune à un segment de réseau et qui se contente de recevoir, amplifier et retransmettre les signaux sur toutes ses interfaces ; il peut ainsi étendre le réseau à plusieurs segments de câble ; typiquement, les réseaux Ethernet sur paires torsadées (dits 10BaseT) sont organisées selon une topologie en étoile autour d'un répéteur appelé hub. La leçon pratique à retenir est que s'il est commode d'étendre son réseau en multipliant des hubs en cascade (comme des prises multiples pour l'électricité), il vient un moment où l'on viole la règle des « 4 répéteurs au plus », et alors le réseau se met à adopter des comportements erratiques et non souhaités : ce n'est pas forcément une panne franche, par moments cela marche, par moments non, c'est-à-dire que c'est une panne difficile à diagnostiquer.

En 2002, les répéteurs (hubs) tendent à être abandonnés (sauf pour les réseaux très bon marché, puisqu'un petit hub coûte moins de 40 Euros) au profit de commutateurs (switches), qui reprennent la même topologie en étoile mais disposent d'une logique plus complexe qui, au lieu de propager le signal sur toutes les interfaces, ne l'envoie que sur celle qui correspond à l'adresse de destination de la trame reçue. Comment le commutateur connaît-il l'adresse de destination de la trame ? Par apprentissage : lorsqu'il reçoit une trame pour une station qui ne s'est jamais manifestée, il agit comme un répéteur et la diffuse à toutes ses interfaces. Dès qu'une station s'est manifestée il conserve son adresse dans une table et n'envoie qu'à elle les trames qui lui sont destinées. Cette nouvelle organisation permet accessoirement de diminuer considérablement le nombre de collisions, puisqu'ainsi seules les stations concernées écoutent le trafic qui leur est destiné. Cela améliore aussi la sécurité. Pourquoi alors ne pas l'avoir fait plus tôt ? Parce qu'il a fallu du temps pour pouvoir fabriquer à des coûts raisonnables une électronique suffisamment complexe et rapide : échantillonner un signal à 10 MHz (et maintenant 100 MHz pour le FastEthernet, 1 GHz pour le GigabitEhernet, demain 10 GHz) et analyser à la volée l'adresse MAC de destination semble banal, mais ne l'était pas au début des années 1980.

Signalons aussi que la fibre optique, support très rapide, permet d'outrepasser la règle des quatre répéteurs, ce qui en fait un support de choix pour les épines dorsales (backbones) de réseaux de campus, voire de métropole (Metropolitan Area Networks, ou MAN) comme le Réseau Académique Parisien, qui relie plusieurs universités et centres de recherches parisiens au moyen de fibres optiques posées dans les tunnels du métro.

Saisissons l'occasion de cette section consacrée à Ethernet pour signaler le nombre considérable d'innovations capitales dont l'origine se trouve au PARC créé en 1970 par Xerox : Ethernet pour commencer. Le langage de description de page PostScript : les fondateurs d'Adobe ont quitté Xerox, frustrés de voir leur employeur ne rien faire de leur invention. L'impression laser vient aussi du PARC (1971). Les interfaces à fenêtres popularisées par le Macintosh ont été inventées par Alan Kay à la fin des années 1960 alors qu'il travaillait au langage Smalltalk, d'abord à l'Université d'Utah, puis à l'Université Stanford, enfin au PARC de 1972 à 1983, où Steve Jobs le rencontra et conçut le projet d'un ordinateur Apple sur la base de ces idées. Incidemment, si la programmation par objets avait déjà été inventée en 1965 par l'équipe de Simula, Alan Kay et le PARC ont beaucoup contribué à son succès avec Smalltalk. Bref, que serions-nous sans eux. Une des explications de cette fécondité extraordinaire dont Xerox a finalement tiré peu de gains financiers est que le PARC avait été créé essentiellement pour dépenser à fonds perdus une partie des bénéfices énormes engendrés par les brevets de la photocopie à sec, afin d'éviter qu'ils n'engendrent des impôts également énormes. La rentabilité était un non-objectif.

6.5 Couche 3, réseau

Dès que notre réseau comportera un nombre n d'équipements terminaux supérieur à 2 ou 3, il ne sera plus raisonnable de les relier deux à deux par des supports physiques dont le nombre serait égal, nous l'avons vu, à n × (n-1)/2, même s'il s'agit de faisceaux hertziens. Il faut donc acheminer les messages par un trajet complexe qui passe par plusieurs segments de liaison de données. Ce sous-problème suppose résolu le précédent (en d'autres termes, la couche 3 fonctionne en utilisant les services fournis par la couche 2) et constitue le problème du réseau proprement dit.

6.5.1 Commutation de circuits

Une première solution consiste à établir un circuit entre deux équipements en sélectionnant un certain nombre de segments de câble (par exemple) qui, mis bout à bout, constituent un itinéraire de l'un à l'autre. Aux jonctions des segments devront se trouver des équipements de transmission de données capables de jouer le rôle de poste d'aiguillage pour les signaux échangés. Nous aurons ainsi constitué un circuit physique, dit circuit commuté, qui une fois établi peut être considéré comme l'équivalent d'une liaison point à point. C'est ainsi que fonctionnent, par exemple, les réseaux de téléphones, fussent-ils mobiles : pendant une communication, un circuit physique est établi entre les deux correspondants, circuit constitué de plusieurs segments aux jonctions desquels se trouvent des équipements de commutation capable d'associer une destination à un numéro.

Le réseau téléphonique automatique (dit « commuté ») est constitué de lignes physiques qui résolvent le problème de base et relient entre eux des équipements terminaux (des téléphones fixes ou portables, des modems, des fax...) et des équipements de transmission de données, qui sont essentiellement des auto-commutateurs. Quand vous composez un numéro de téléphone vous utilisez une ligne (de cuivre pour un téléphone fixe, hertzienne pour un portable) qui vous met en relation avec l'auto-commutateur du secteur ; celui-ci peut identifier la destination de votre appel d'après le numéro de votre correspondant et sélectionner une ligne qui va soit atteindre directement votre correspondant dans le cas d'un appel local, soit atteindre un autre auto-commutateur qui va lui-même sélectionner une ligne propre à acheminer votre communication vers votre correspondant, qui après quelques étapes entendra sonner son téléphone. Pendant toute la durée de votre conversation les différents segments de ligne qui auront été sélectionnés par les auto-commutateurs successifs seront réservés à votre usage exclusif. Ils constitueront un circuit commuté, et pour cette raison le réseau téléphonique est qualifié de réseau à commutation de circuits, ou réseau commuté tout court.

Si un des auto-commutateurs du circuit n'a plus de ligne libre au moment de votre appel, celui-ci ne pourra pas être établi et une voix enregistrée vous suggérera de renouveler votre appel ultérieurement. Cette nécessité de réserver physiquement un canal de communication de bout en bout pour une communication individuelle, même quand vous et votre interlocuteur marquez une pause dans la conversation, est une limite du réseau téléphonique.

6.5.2 Commutation de paquets

Beaucoup de réseaux informatiques ont fonctionné en se contentant de la commutation de circuits, ce qui, soit dit en passant, revient à se ramener à des liaisons de couche 2 : une fois le circuit établi, on a l'illusion d'une liaison unique. Depuis la fin des années 1960 une autre idée s'est imposée. Monopoliser un circuit physique pour une seule communication semblait logique pour acheminer la voix lors d'un échange téléphonique : cela correspondait au modèle de taxation des compagnies de téléphone, la voix exige pour être transmise sans déformation le respect de la cadence d'émission des impulsions, ce que l'on appelle l'isochronie, à l'époque la transmission était analogique, et le débit prévisible et à peu près constant. Mais pour la transmission de données l'impératif d'isochronie est moins fort et l'on peut imaginer d'autres solution.

Pour comprendre les réseaux d'ordinateurs il peut être utile de les comparer à d'autres types de réseaux : téléphonique, ferroviaire, électrique, routier, de distribution d'eau ou de courrier postal. Tous ces réseaux ont des caractéristiques communes ; dès qu'ils atteignent une certaine taille, l'acheminement d'un message (ou respectivement d'une communication téléphonique, d'un wagon de marchandises, d'une quantité d'énergie électrique, d'une lettre...) pose des problèmes d'itinéraire et de vérification de bon acheminement. Il faut aussi optimiser l'usage du réseau : chaque wagon n'a pas sa propre locomotive du départ à l'arrivée, mais il peut être accroché successivement à différents trains qui le rapprocheront de sa destination, ce que nous appellerons du multiplexage (de messages ou de wagons).

Tentons une comparaison avec le réseau téléphonique : lorsque nous avons résolu le problème de base, faire communiquer deux équipements, nous avons l'équivalent d'une paire de talkie-walkie. C'est un bon début, mais si nous pensons à la façon dont nous utilisons le téléphone, pour appeler par une procédure automatique un abonné au Japon ou un portable en rase campagne, nous concevons qu'il faut bien des équipements et des techniques pour passer du stade « talky-walky » à un vrai réseau complexe, ou de la couche 1 à la couche 2 en l'occurrence.

Circuits virtuels

Pensons maintenant à la circulation de wagons de marchandises dans un réseau ferré : ils sont accroché à des locomotives pour former des trains. Soit par exemple un wagon à acheminer de Lille à Nice. Il va d'abord être accroché à un train Lille--Paris. À Paris, le train va être démembré dans une gare de triage et notre wagon accroché à un nouveau train Paris-Marseille, en compagnie de nouveaux compagnons wagons. À Marseille un nouveau triage aura lieu à l'issue duquel un train venant par exemple de Perpignan mènera notre wagon jusqu'à Nice. Ces trois trains successifs auront roulé à des vitesses différentes en comportant des wagons différents, mais nous pouvons dire, du point de vue de l'entreprise lilloise qui envoyait le contenu d'un wagon de Lille à Nice, qu'ils ont constitué un unique train virtuel Lille--Nice pour le wagon qui nous intéresse. Sur aucun des trois segments de la ligne virtuelle Lille--Nice, le wagon n'a eu besoin d'un conducteur informé de la destination et de l'itinéraire détaillé pour y parvenir : le conducteur de la locomotive et les opérateurs des postes d'aiguillage ont assuré son acheminement. Il fallait juste une étiquette (sans doute à code barre ou électronique) « Nice » sur le wagon pour qu'il soit correctement aiguillé lors des opération de triage.

Les réseaux informatiques conformes à la norme X25, dont l'exemple en France est le réseau Transpac, popularisé en son temps par le Minitel dont il était le support, fonctionnent selon un principe conforme à la métaphore du train de marchandises. Le flux d'informations est découpé en paquets de taille plus ou moins fixe, quelques centaines à quelques milliers de caractères, et ces paquets vont être acheminés par un circuit virtuel. Lorsque l'on veut établir une communication entre deux noeuds du réseau, on commence par déterminer un circuit virtuel qui passe par différents équipements intermédiaires que nous appellerons concentrateurs. Un concentrateur est un ordinateur spécialisé qui dispose d'un certain nombre de lignes de communications, d'une mémoire et d'un logiciel. Le logiciel du concentrateur de Paris est capable de déterminer que pour contribuer à l'établissement du circuit virtuel Lille--Nice il faut envoyer les paquets en provenance de Lille et destinés à Nice sur la ligne qui se dirige vers le concentrateur de Marseille, qui fera suivre. Le concentrateur gardera en mémoire une table (dite table de routage) qui associera un circuit virtuel Lille--Nice à un numéro d'identification et à une sortie vers le concentrateur de Marseille. Chaque paquet expédié sur ce circuit virtuel comportera comme une étiquette le numéro d'identification de circuit virtuel qui permettra au concentrateur de l'expédier dans la bonne direction.

L'ensemble de ces conventions --- format et contenu des tables de routage et des paquets, format des adresses (analogues à des numéros de téléphone) qui identifient de façon unique chaque noeud et chaque extrémité du réseau, procédure d'établissement du circuit virtuel, structure de son numéro d'identification, règles d'acheminement des paquets, procédure d'accusé de réception par laquelle l'extrémité destination avertit l'extrémité origine de la bonne fin de l'échange --- constituent un protocole de communication, ici en l'occurrence le protocole X25, protocole de couche 3 pour les réseaux à commutation de paquets par circuits virtuels.

Le progrès par rapport à la commutation de circuits est considérable : plusieurs circuits virtuels peuvent partager, pour une partie de leurs trajets respectifs, la même infrastructure physique. Les tronçons très fréquentés peuvent être équipés de lignes à plus haut débit que ceux qui le sont moins. Les concentrateurs réalisent l'adaptation de débit entre les liaisons de caractéristiques différentes. Ce modèle a beaucoup plu aux opérateurs téléphoniques traditionnels parce qu'il permettait un mode de tarification conforme à leurs habitudes : une fois le circuit virtuel établi, tous les paquets empruntent le même itinéraire et il suffit de les compter dans un concentrateur quelconque pour pouvoir facturer au bit près.

Nous allons voir mieux. Le modèle que nous venons de décrire a des limites : l'établissement d'une communication exige que soit constitué dès auparavant un circuit virtuel de bout en bout. Cela ne pose pas de problème particulier au sein d'un réseau doté d'une administration unique et centralisée, par exemple Transpac. Il est à la rigueur concevable d'organiser une coordination entre quelques grands opérateurs nationaux, conformément encore une fois au modèle familier à France Télécom et à ses homologues dans d'autres pays, quoique l'expérience ait prouvé le caractère laborieux (et onéreux) d'une telle coordination. Mais nous allons voir un principe plus souple, celui de l'Internet, qui permet l'acheminement sûr des communications parmi un univers de réseaux multiples au foisonnement anarchique.

Commutation de paquets « pure »

Passons de la métaphore ferroviaire à la métaphore routière. Soit une noce : la famille et les différents groupes d'invités doivent se rendre au village où ont lieu la cérémonie et le banquet. Ils y vont en voiture. Plusieurs groupes partent de la même ville, mais ils ne tiennent pas tous dans la même voiture, alors ils voyagent indépendamment. Tous ne prennent pas le même itinéraire, et les premiers partis ne sont pas forcément les premiers arrivés. Certains ont étudié la carte et déterminé un trajet jusqu'au village, mais d'autres, plus insouciants, se fient aux panneaux indicateurs qu'ils observent au bord de la route ou aux carrefours au fur et à mesure de leur progression vers l'objectif, ce qui ne devrait pas les empêcher d'arriver à bon port. Si la noce est très nombreuse elle peut saturer l'autoroute, auquel cas les panneaux lumineux de type « bouchon à 5 km » viendront avertir les attardés qu'il vaut mieux prendre l'itinéraire de délestage, ce qui leur permettra éventuellement d'arriver avant les premiers partis.

À l'arrivée au village il a été convenu de former un cortège, ce qui suppose bien sûr un ordre protocolaire : d'abord la voiture de la mariée, puis celle du marié, suivi de la belle-mère, etc. Évidemment les voitures n'arrivent pas dans le bon ordre, et pour rester fidèle à la tradition la mariée arrivera la dernière, aussi faudra-t-il une manoeuvre supplémentaire pour constituer le cortège dans le bon ordre, ce qu'aurait évité un voyage par train spécial.

Le tableau que nous venons de dresser du départ et du regroupement final de la noce figure assez fidèlement l'acheminement d'un message de bonne taille par l'Internet conformément au protocole IP (Internet Protocol). Chaque voiture représente un paquet, appelé aussi datagramme IP, ce qui insiste sur son caractère autonome, par opposition au paquet X25, sagement rangé en file sur un circuit virtuel. Le cortège nuptial des voitures remises dans le bon ordre représente le message tel qu'il doit parvenir à destination. Comme chaque paquet est acheminé indépendamment des autres, par un itinéraire éventuellement différent, il ne suffit pas pour savoir comment l'acheminer d'un numéro de circuit virtuel, donc chaque paquet doit comporter son adresse d'origine et son adresse de destination. Le protocole IP définit un format d'adresse, et les organismes de coordination de l'Internet en assurent l'unicité à l'échelle mondiale.

Aux noeuds du réseau se trouvent non plus des concentrateurs X25, mais des ordinateurs spécialisés qui remplissent un rôle similaire, même si sensiblement plus complexe, appelés routeurs. Fondamentalement, un routeur reçoit un paquet par une de ses lignes de communication, analyse son adresse de destination, consulte ses tables de routage, et en déduit sur quelle ligne il doit réexpédier le paquet, ou s'il doit le rejeter.

À première vue, tout ceci semble moins rationnel et moins efficace que les circuits virtuels de X25. Mais c'est aussi considérablement plus souple, et finalement ce modèle l'a emporté.

6.5.3 Le protocole IP et l'Internet

Le protocole IP correspond à la couche 3 du modèle OSI, la couche réseau. La « pile » TCP/IP (comme une pile de couches... empilées) n'obéit pas strictement à la nomenclature du modèle OSI : elle comporte une couche liaison de données qui englobe les couches 1 et 2 de l'OSI, la couche IP (réseau) correspond à la couche 3 de l'OSI, la couche TCP⁷ (transport) correspond à la couche 4 de l'OSI. La couche « applications » englobe tout ce qui relève des couches hautes de l'OSI.

L'architecture de TCP/IP peut être vue sous l'angle suivant. À partir d'un message émis par un utilisateur, chaque couche en partant de la plus haute lui ajoute des en-têtes qui contiennent les informations nécessaires à son fonctionnement, ce que montre la figure 6.5.

Figure 6.5 : En-têtes des quatre couches de TCP/IP

Ainsi, un message électronique sera d'abord doté par votre logiciel de courrier des en-têtes applicatives, en l'occurrence telles que décrites par le RFC 822 (ce sont les lignes From:, To:, Subject:, etc. que vous lisez en haut des messages). Puis ce message conforme au RFC 822 se verra découpé en segments TCP, chacun doté de l'en-tête convenable (décrite plus bas). Chaque segment TCP sera empaqueté dans un datagramme IP qui possède lui aussi une en-tête. Et chaque datagramme sera expédié sur la couche liaison de données qui correspond au support physique, Ethernet par exemple.

Le protocole réseau IP fournit à la couche transport un service non fiable non connecté de datagrammes. Le terme datagramme signifie que le flux de bits remis par la couche transport (TCP) est découpé en paquets acheminés indépendamment les uns des autres. Par non fiable nous entendons que la couche IP ne fournit aucune garantie de remise des datagrammes ni aucun contrôle d'erreur, et par non connecté nous entendons que la couche IP ne maintient aucune information d'état sur une transmission de données en cours, et notamment qu'elle ne garantit pas la remise des datagrammes dans l'ordre dans lequel ils ont été émis.

Ces caractéristiques sont de nature à inquiéter les néophytes, et semblent curieuses, d'autant plus que la couche de liaison de données fournit à la couche réseau, pour chaque segment physique d'un chemin de données utilisé par un datagramme, un service fiable de flux de bits remis dans le bon ordre.

En fait, la couche IP ne fournit pas de contrôle d'erreur parce que de toute façon la couche TCP devra en effectuer, ainsi que la vérification du bon ordre de remise des datagrammes au terminus de la transmission, et que de tels contrôles au niveau de la couche 3 seraient redondants. Son ascétisme et sa désinvolture confèrent à la couche IP la simplicité, la légèreté et la souplesse qui font son efficacité. Mais avant d'en décrire plus précisément les principes techniques, il nous faut donner quelques informations sur l'organisation du plus grand réseau IP : l'Internet.

Organisation administrative de l'Internet

Une chose que les néophytes ont souvent du mal à comprendre, c'est que l'Internet ne soit la propriété de personne ni d'aucune institution. Saisissons cette occasion de démentir la légende répétée ad nauseam qui voudrait que l'Internet ait été inventé à la demande des militaires américains selon un cahier des charges rédigé en vue de préserver une capacité de communication après une frappe nucléaire. Il n'y a jamais rien eu qui ressemble de près ou de loin à un « cahier des charges de l'Internet ». Cette thèse télescope plusieurs événements liés mais distincts. Paul Baran, de la firme RAND, contractant du DoD (Department of Defense), avait posé les principes d'un tel système de communications dépourvu de point de centralisation unique afin de maintenir certaines liaisons même si certains noeuds venaient à être détruits. Les travaux de Baran furent publiés entre 1960 et 1964. Le même DoD, plusieurs années plus tard, en 1969, a impulsé par son agence l'ARPA (Advanced Research Projects Agency) la création du réseau ARPANET, qui n'était pas destiné aux communications militaires mais à faciliter la collaboration entre centres de recherches universitaires et industriels sous contrat avec l'ARPA. BBN (Bolt, Baranek & Newman) a été très impliqué dans le développement d'ARPANET, où se retrouvent certaines idées de Paul Baran ; ce réseau fut un des premiers (avec Cyclades en France) à utiliser la technique de commutation de paquets. En 1976, la clairvoyance de Vint Cerf et de Robert Kahn, le financement de BBN et les contrats de l'ARPA devenue entre temps la DARPA donnèrent naissance au protocole réseau de l'Internet, TCP/IP. Un peu plus tard, en 1979, le groupe de recherche en système (Computer Systems Research Group, CSRG) de l'Université de Californie à Berkeley allait incorporer TCP/IP à une nouvelle version de Unix, dite BSD (Berkeley Software Distribution). Tous ces éléments marinaient dans une soupe originelle qui a donné naissance à l'Internet à la fin des années 1970, quand les centres de recherche connectés à ARPANET ont voulu communiquer avec les universités de leur choix et que la NSF (National Science Foundation) a entrepris de leur en donner les moyens.

Le fonctionnement de l'Internet, à l'image de sa construction, repose sur la coopération volontaire. Les décisions organisationnelles et techniques sont prises par des instances aux séances desquelles tout un chacun peut assister et participer.

L'Internet Architecture Board (IAB) est responsable des grandes orientations et de la coordination.
L'Internet Engineering Task Force (IETF) se charge de la normalisation à court terme et émet les Requests for Comments (RFC), qui sont les documents de référence pour le fonctionnement du réseau. Citons ici le nom de Jon Postel, éditeur des RFC depuis la première en 1969 jusqu'à sa mort en 1998, et auteur ou coauteur de 204 d'entre elles, ce qui lui a conféré une influence considérable sur la physionomie du réseau. Toutes les RFC sont accessibles par l'URL (Universal Resource Locator) http://www.ietf.org/rfc/ ou sur de nombreux sites miroirs. Nous ne saurions trop en conseiller la lecture, même si leur qualité littéraire est inégale elles fournissent sur l'Internet une information de première main, souvent exposée très clairement, et dont la citation dans les dîners en ville vous assurera une réputation de guru du réseau.
L'Internet Steering Group (IESG) coordonne l'IETF, dont l'effectif est devenu très important.
L'Internet Assigned Numbers Authority (IANA) centralise et contrôle les conventions relatives à l'identification des objets du réseau, et notamment veille à l'unicité des adresses.
L'Internet Corporation for Assigned Names and Numbers (ICANN) supervise l'attribution des noms de domaines et des adresses.

Cette organisation coopérative ne signifie pas l'absence de rapports de force marchands ou politiques, mais elle exclut (au moins à court terme) la prise de contrôle par une entreprise unique.

Organisation topographique de l'Internet

La figure 6.6 donne une représentation schématique de la topographie de l'Internet. Cette représentation est simplifiée, notamment elle est purement arborescente, alors que rien n'empêche une entreprise d'avoir plusieurs FAI, ni un FAI d'être connecté à plusieurs centres d'interconnexion de niveau supérieur, ce qui complique le schéma et le transforme d'un arbre en un graphe connexe quelconque. L'essentiel dans l'établissement d'une communication, c'est, à chaque noeud, de savoir quel est le prochain noeud sur l'itinéraire, et par quelle liaison l'atteindre. Les noeuds terminaux, origines ou destinations des communications, sont au sein des réseaux locaux de campus ou d'entreprise. Les routeurs sont des noeuds particuliers, dotés de plusieurs adresses réseau (une par interface raccordée à une ligne de communication) et possédant des tables de routage.

La figure 6.7 représente un gros plan sur un réseau local simple, raccordé à l'Internet par un routeur, et constitué d'un unique segment de couche 2, en l'occurrence un réseau Ethernet.

La double ligne horizontale symbolise le bus, ou graphe connexe complet, qui stipule qu'une trame émise par une des stations atteindra toutes les stations du réseau. Les réseaux Ethernet contemporains ont une topologie physique assez différente de ce schéma, surtout s'ils utilisent les transmissions sans fil, mais ce schéma correspond toujours bien à la structure logique de la communication.

Figure 6.6 : Topographie de principe de l'Internet

Les stations ordinaires ont une seule interface réseau, et donc une seule adresse de couche 2 et une seule adresse de couche 3 (dans les deux couches les adresses sont associées aux interfaces). Dans notre exemple les adresses (de couche 3) des stations vont de 192.168.2.101 à 192.168.2.105. Le routeur, par définition, possède au moins deux interfaces et donc deux adresses, ici vers le réseau local et vers le FAI et l'Internet. Dans notre exemple l'adresse intérieure est 192.168.2.1 et l'adresse extérieure 171.64.68.22.

Figure 6.7 : Un réseau local simple

L'adresse et le datagramme IP

Comme nous l'avons vu plus haut, la couche réseau a sa propre vision de la topologie du réseau, et partant son propre système d'adressage.

Il faut tout d'abord rappeler que les adresses de couche 3, comme celles de couche 2, sont attribuées aux interfaces et non aux machines. Une machine qui a trois cartes réseau aura au moins trois adresses ; à chaque interface peuvent correspondre plusieurs adresses.

Comme nous allons le voir, l'adresse a deux fonctions : l'identification d'un noeud et sa localisation ; elle est en cela analogue au numéro de téléphone. On aurait pu imaginer qu'il en soit autrement : notre numéro de sécurité sociale nous identifie sans nous localiser, ce qui nous évite d'avoir à en changer à chaque déménagement. Mais c'est ainsi et la nouvelle version du protocole IP, IPv6, reste en gros fidèle à ce principe ; la dissociation de ces deux rôles de l'adresse aurait des avantages indéniables pour les stations mobiles, de plus en plus nombreuses, et des recherches se poursuivent dans cette direction.

Chaque adresse IP est unique⁸ dans tout l'Internet, ce qui lui permet d'assurer sa fonction d'identifiant. Quant à la fonction de localisation elle est assurée par les mécanismes complexes du routage.

La façon dont une station (terme qui désigne un noeud vu du point de vue de celui qui s'en sert) reçoit son adresse IP est variable. L'ICANN distribue des tranches d'adresses à des organismes régionaux (pour l'Europe, c'est RIPE, pour Réseaux IP Européens), qui les redistribuent à des organismes qui peuvent être nationaux (pour la France c'est l'association AFNIC), qui eux-mêmes les attribuent aux fournisseurs d'accès à l'Internet (FAI). Lorsqu'une entreprise ou un particulier veut obtenir un accès à l'Internet, il s'adresse à un FAI, qui lui attribue, selon l'importance de son réseau et de son abonnement, une ou plusieurs adresses IP. En général, les particuliers n'ont pas besoin d'une adresse fixe permanente : lorsqu'ils allument leur ordinateur et leur modem, le routeur du FAI le détecte et leur envoie une adresse temporaire, affectée dynamiquement à partir d'un pool d'adresses, qui servira le temps de la session de travail. Cette adresse peut d'ailleurs être privée (voir plus haut).

En cette année 2002, IP est en pleine transition : les adresses couramment utilisées sont celles d'IP version 4 (spécifié par le RFC 791 de septembre 1981), qui comportent 32 chiffres binaires (bits), ce qui autoriserait théoriquement un maximum de 4 milliards de noeuds, en fait moins, à cause de la structure de l'adresse. Cette valeur qui semblait astronomique dans les années 1970 est en passe d'être atteinte par le développement de l'Internet. Les organismes qui coordonnent l'Internet ont défini une nouvelle version du protocole, IP version 6, et sont en train de planifier son déploiement, ce qui ne sera pas une mince affaire. L'adresse IPv6 comporte 128 bits. Cette nouvelle version du protocole apporte d'autres innovations, dans le domaine de la sécurité et dans celui de l'auto-configuration des noeuds qui rejoignent le réseau notamment.

L'adresse IPv4 est structurée en deux parties : les chiffres les plus significatifs désignent le numéro de réseau, ou adresse de réseau, les moins significatifs l'adresse locale, qui identifie une interface d'un noeud dans le réseau (une machine peut avoir plusieurs interfaces, et donc plusieurs adresses). Il existe trois classes de réseaux, distinguées par le nombre de bits réservés à l'adresse de réseau et à l'adresse locale respectivement. Ce partage de l'espace adresse en classes ne s'est pas avéré très judicieux avec la montée de la pénurie mondiale d'adresses et il est partiellement abandonné aujourd'hui. IPv6 offre plus de souplesse dans la gestion des adresses, en tenant compte de phénomènes inconnus lors de la spécification d'IPv4, comme le rôle des fournisseurs d'accès à l'Internet (FAI), la mobilité et le nomadisme.

Écrire un nombre binaire de 32 chiffres est malcommode ; pour représenter une adresse IP on utilise la convention suivante : elle est découpée en quatre nombres de huit bits (octets), et on écrit ces nombres en notation décimale, séparés les uns des autres par un point. Voici une adresse représentée de la sorte : 171.64.68.20. Pour préciser la forme des adresses IPv4 donnée à l'alinéa précédent, le RFC 791 distingue des adresses de classe A, avec le premier bit à 0, 7 bits pour l'adresse de réseau (le premier octet est un nombre inférieur à 128) et 24 bits pour l'adresse locale (interface d'un noeud) ; des adresses de classe B avec le premier bit à 1, le deuxième bit à zéro (le premier octet est un nombre compris entre 128 et 191 inclus), 14 bits pour l'adresse de réseau et 16 bits pour l'adresse locale ; les adresses de classe C avec les deux premiers bits à 1 et le troisième bit à 0 (le premier octet est un nombre supérieur à 191 et inférieur à 224), 21 bits pour l'adresse de réseau et 8 bits pour l'adresse locale.

Figure 6.8 : Datagramme (ou paquet) IPv4

Actuellement ce système assez rigide est souvent contourné et les classes sont de fait abolies par le système CIDR (Classless Interdomain Routing), qui instaure une situation hiérarchique plus simple où, à une feuille de l'arborescence, l'administrateur d'un réseau local fixe les quelques bits les plus à droite de l'adresse d'une interface, puis le FAI régional fixe quelques bits un peu plus à gauche, puis un organisme national encore quelques bits supplémentaires, et ainsi de suite jusqu'à l'ICANN qui distribue les bits de gauche à toute la planète, tout ceci en essayant de s'organiser pour que des machines topologiquement proches les unes des autres aient le plus de bits de gauche en commun afin de simplifier et d'abréger les tables de routage. Mais comme le RFC 791 est toujours en vigueur et que la plupart des adresses que vous rencontrerez au cours des prochaines années lui obéiront, autant comprendre cette syntaxe curieuse.

La partie « adresse de réseau » de l'adresse joue le rôle de préfixe : ainsi, dans un réseau local de campus ou d'immeuble tel que représenté par la figure 6.7, tous les noeuds du réseau ont le même préfixe, qui caractérise le réseau. Dans notre cas, l'adresse de réseau est 192.168.2, ce qui incidemment est un préfixe d'adresse réservé aux réseaux privés, non visibles de l'Internet. À l'intérieur du réseau, les noeuds sont distingués par le suffixe de leur adresse. De l'extérieur du réseau, pour envoyer un message à un de ses noeuds, il suffit de l'envoyer à l'adresse extérieure du routeur d'entrée (dans notre exemple 172.64.68.22), ce routeur détiendra l'information propre à acheminer le message à la bonne adresse. Quand une machine du réseau souhaite expédier un datagramme à une machine extérieure, elle l'envoie à l'adresse intérieure du routeur (192.168.2.1), qui joue le rôle de passerelle de sortie et qui sait (nous allons bientôt le savoir nous aussi) comment le faire parvenir à destination.

Pour donner une meilleure vision du datagramme (ou paquet) IPv4, la figure 6.8 en donne le diagramme complet. Le champ « protocole supérieur » permet de connaître la nature des données, en général soit un segment TCP, soit un segment UDP. Les informations de la seconde ligne (identifiant, flags, position du fragment) servent dans le cas suivant : tous les segments d'un itinéraire dans un réseau n'ont pas forcément les mêmes caractéristiques techniques, et notamment certains peuvent n'accepter qu'une taille maximum de paquet inférieure à la taille fournie par le noeud précédent, ce qui oblige le routeur à fragmenter le paquet, qui devra bien sûr être réassemblé à un moment ou à un autre, grâce à ces informations. Cette possibilité de fragmentation est un dispositif souvent utilisé par les pirates pour leurrer les logiciels de sécurité qui analysent les paquets de données, parce que les algorithmes de fragmentation et de réassemblage sont compliqués et donc souvent mal réalisés par certains fournisseurs.

Le paquet IPv4 comporte beaucoup d'informations en fait inutiles et parfois gênantes, en particulier la somme de contrôle qui doit être recalculée chaque fois que l'en-tête du paquet est modifié (elle ne contrôle l'intégrité que de l'en-tête). Le paquet IPv6 est beaucoup plus simple, comme en témoigne la figure 6.9.

L'adresse IPv6, de 128 bits donc, est notée de la façon suivante : elle est découpée en tranches de 16 bits, représentée chacune par quatre chiffres hexadécimaux, les tranches séparées les unes des autres par le signe « : », ainsi :

0123:4567:89ab:cdef:0123:4567:89ab:cdef

Il y a des règles assez subtiles pour abréger cette représentation lorsqu'elle comporte de longues suites de bits à zéro, dont l'exposé ne nous semble pas indispensable, sachant que le lecteur curieux en trouvera le détail dans le RFC 2373 (http://www.ietf.org/rfc/rfc2373.txt).

Figure 6.9 : Datagramme (ou paquet) IPv6

IPv6 introduit d'autres modifications dans le traitement des adresses : si une adresse est toujours attribuée à une interface (plutôt qu'à un noeud), cette attribution est temporaire et les adresses sont réputées changer. Les chiffres les moins significatifs de l'adresse IPv6 sont calculés à partir de l'adresse de couche 2 (MAC) lorsqu'il y en a une.

6.5.4 Exception à l'unicité des adresses : traduction d'adresses (NAT)

Le principe du standard téléphonique d'hôtel

Le système de traduction d'adresses⁹ NAT (Network Address Translation) est apparu en 1994 dans le RFC 1631 [23] (remplacé maintenant par le 3022 [65]), initialement pour permettre la communication entre l'Internet et des réseaux privés contenant des adresses IP non conformes au plan d'adressage de l'Internet, et il a été ensuite très largement utilisé pour pallier le déficit d'adresses IP engendré par l'étroitesse de la plage d'adresses de la version 4 du protocole. Il est devenu de ce fait à la fois une solution et un problème de sécurité des réseaux.

Le principe en est le suivant : chaque noeud de l'Internet doit posséder une adresse IP pour mettre en oeuvre le protocole TCP/IP, et cette adresse doit être unique, comme pour les numéros de téléphone, sinon il serait impossible d'acheminer correctement les communications.

Figure 6.10 : Réseau sans NAT : les adresses des hôtes sont des adresses uniques et routées sur Internet.

Mais, pour poursuivre la comparaison avec le téléphone, dans un hôtel par exemple, seul le standard a un numéro de téléphone unique, et le poste de chaque chambre a un numéro local, à usage strictement interne, et qui peut très bien être le même que celui d'une chambre dans un autre hôtel : cela n'a aucune conséquence fâcheuse parce que le numéro de la chambre n'est pas visible de l'extérieur ; ceci permet parfaitement à l'occupant de la chambre d'appeler l'extérieur en donnant un code particuler (« composer le 0 pour avoir l'extérieur »), et de recevoir des communications en passant par le standard qui effectue la commutation vers la ligne de la chambre.

Adresses non routables

Le système NAT repose sur un principe analogue : dans un réseau local, seuls les serveurs qui ont vocation à abriter des serveurs vus de tout l'Internet, comme le serveur WWW de l'entreprise ou sa passerelle de messagerie, doivent recevoir des adresses reconnues universellement, et donc uniques et conformes au plan d'adressage de l'Internet. Les postes de travail ordinaires peuvent recevoir des adresses purement locales, qui ne sont pas routables, c'est-à-dire qu'un paquet à destination d'une telle adresse peut circuler sur le réseau local et atteindre sa destination, mais ne peut pas franchir un routeur, parce que ces classes d'adresses sont explicitement désignées pour que les routeurs les oublient. Sont dites non routables toutes les adresses appartenant aux blocs d'adresses définis à cet effet par le RFC 1918 [55] : 192.168.0.0 à 192.168.255.255 (préfixe 192.168/16), 172.16.0.0 à 172.31.255.255 (préfixe 172.16/12) et 10.0.0.0 à 10.255.255.255(préfixe 10/8).

Accéder à l'Internet sans adresse routable

Si la gestion des adresses non routables s'arrêtait là, ces malheureux ordinateurs dotés d'adresses de seconde zone ne pourrait jamais naviguer sur l'Internet : en effet, une communication aussi simple que l'accès à un serveur WWW demande que les paquets comportent une adresse source et une adresse destination valides, ne serait-ce que pour que le serveur puisse renvoyer au client le contenu de la page qu'il a voulu consulter. D'ailleurs dans un réseau fermé sans connexion à l'Internet les possibilités de communication sont limitées au réseau local, et c'est pour de tels réseaux qu'avaient été créées à l'origine les classes d'adresses non routables, que NAT a ensuite astucieusement détournées de leur destination, si j'ose dire.

Sur un réseau connecté à l'Internet qui ne contient que des postes de travail dotés d'adresses non routables, il y a au moins un noeud qui possède une adresse routable, c'est le routeur d'entrée du réseau, puisque justement il est connecté. Alors il y a au moins un moyen de faire communiquer un poste du réseau local avec l'extérieur : il faut pour cela que le routeur soit doté de la capacité de traduction d'adresses, justement ; ainsi il pourra jouer vis-à-vis des noeuds du réseau local le même rôle que le standard de l'hôtel vis-à-vis des postes téléphoniques des chambres, en « passant les communications ». Le principe de NAT est de remplacer une adresse interne non routable par une adresse routable.

Réalisations

La façon la plus simple de réaliser la traduction d'adresse est la méthode statique : à chaque adresse interne non routable on fait correspondre, bijectivement, une adresse routable qui la remplace. Le routeur contient la table de correspondance et fait la traduction, sans autre forme de procès.

Figure 6.11 : Réseau avec NAT : les adresses des hôtes sont des adresses réutilisables. Le routeur d'entrée fait la traduction d'adresse. On notera que la modification du plan d'adressage alloue désormais un réseau /16 par sous-réseau, s'affranchissant de la limite des 254 adresses possibles avec un /24.

La traduction d'adresse statique est simple, mais dans l'univers de la fin des années 1990 la pénurie des adresses IP (la version 4 du protocole IP comporte des adresses sur 32 chiffres binaires, ce qui autorise un maximum de 4 294 967 295 adresses uniques, mais en fait un peu moins compte tenu des contraintes sur la structure de ces adresses) a conduit vers d'autres réalisations, notamment la traduction d'adresses dite dynamique, et plus particulièrement vers une de ces méthodes dynamiques, dite IP masquerading (masquage d'adresse IP), aujourd'hui prédominante et que nous allons décrire bièvement (pour plus de détails et de références, cf. Wikipédia [75]). Avec NAT et le masquage d'adresse IP, seul le routeur possède une adresse routable, toutes les communications des noeuds internes sont vues de l'extérieur comme issues de cette adresse ou destinées à elle, et le tri est fait par le routeur au moyen d'une manipulation des numéros de port, de façon tout à fait analogue au travail du standardiste de l'hôtel que nous évoquions ci-dessus.

Figure 6.12 : Réseau avec NAT et masquage d'adresse IP : seule l'adresse de l'interface externe du routeur est utilisée ; le multiplexage/démultiplexage des adresses IP internes se fait grâce aux numéros de ports (modifiés par le routeur).

En anticipant sur la section suivante, disons qu'une connexion TCP est identifiée par la quadruplet {adresse IP de destination, numéro de port de destination, adresse IP d'origine, numéro de port d'origine}¹⁰. En général, dans le paquet qui initie la connexion, le numéro de port de destination obéit à une convention (par exemple 80 pour l'accès à un serveur WWW), et le numéro de port d'origine est quelconque, supérieur à 1024, et choisi de façon à former un couple unique avec l'adresse d'origine. Lorsque le routeur recevra un tel paquet, où l'adresse d'origine sera une adresse NAT non routable, il remplacera cette adresse par sa propre adresse, éventuellement il remplacera le numéro de port d'origine par un autre, s'il a déjà utilisé ce couple { adresse, numéro de port} pour une autre traduction, et il conservera dans une table la correspondance entre ce couple {adresse, port} envoyé sur l'Internet et celui du poste émetteur, ce qui permettra, au prix donc d'une traduction, d'acheminer les paquets dans les deux sens.

6.5.5 Une solution, quelques problèmes

À première vue, NAT est une solution de sécurité : avec un tel procédé et le masquage d'adresse IP, les adresses des noeuds du réseau interne, qui sont en général les postes de travail des utilisateurs, ne sont pas visibles de l'extérieur, ils sont donc hors d'atteinte de connexions établies par des malfaisants, et de fait il n'y a en général aucune raison valable pour qu'une connexion soit établie depuis l'extérieur vers un poste de travail individuel ; si tel devait être le cas cela devrait être fait selon une méthode de traduction explicite, par exemple pour permettre la prise de contrôle à distance dans un contexte d'assistance technique ou d'administration du système (mise à jour d'anti-virus, etc.).

Cette protection du réseau privé par NAT est réelle et ne doit pas être sous-estimée. Il convient cependant d'avoir conscience du fait qu'avec la version 6 du protocole TCP/IP NAT va probablement disparaître, au moins sous sa forme actuelle, et avec lui les politiques de sécurité qui reposeraient trop exclusivement sur ses caractéristiques contingentes.

NAT pose des problèmes aux protocoles qui transportent des adresses IP et des numéros de port dans la partie « données » de leurs paquets. De tels protocoles sont dits « sales », parce qu'ils ne respectent pas le modèle d'abstraction en couches, et qu'ils transportent de l'information de niveau protocolaire (adresses) sous forme de données quelconques. Le type même du protocole sale est H323, utilisé pour la téléphonie sur IP et la visio-conférence.

NAT pose aussi des problèmes à IPSec, parce que NAT modifie les adresses et les numéros de ports, donc modifie les paquets, ce qui, du moins en IPv4, oblige à recalculer la somme de contrôle qui y figure (IPv6 supprime cette contrainte).

Dans un réseau qui met en oeuvre NAT, le masquage d'adresse IP et les adresses non routables du RFC 1918 (cf. ci-dessus 6.5.4), ce qui est très répandu, notamment avec les petits routeurs ADSL que chacun installe maintenant à son domicile, les adresses sont généralement affectées de façon dynamique par un protocole conçu à cet effet, DHCP (Dynamic Host Configuration Protocol). Ce protocole n'est pas exempt de critiques du point de vue de la sécurité, notamment parce qu'il émet des diffusions générales à la cantonade sans que ce soit toujours nécessaire, et aussi parce qu'il n'est pas protégé contre les usurpations d'identité : je monte un serveur DHCP pirate, j'alloue aux clients naïfs des adresses que je contrôle, je fais croire au service de noms local que les communications à destination de ces adresses doivent m'être envoyées, et ainsi j'intercepte des communications qui ne me sont pas destinées.

6.5.6 Traduction de noms en adresses : le DNS

Depuis quelques paragraphes nous parlons d'expédier des datagrammes à des adresses ici ou là, mais nous, utilisateurs de l'Internet, comment connaissons-nous les adresses des machines avec lesquelles nous voulons communiquer ? Ce que nous voulons faire, le plus souvent, c'est envoyer un courrier électronique à France.Gall@freesurf.fr, ou consulter le serveur http://www.sncf.fr pour connaître l'horaire du train pour la rejoindre. www.sncf.fr n'est pas une adresse, mais un nom qui désigne la machine qui abrite le serveur désiré. freesurf.fr n'est pas une adresse mais un nom qui désigne un domaine au sein duquel se trouvera une machine nommée par exemple mail.freesurf.fr, qui abritera le serveur de courrier électronique qui détient la boîte aux lettres électronique de France Gall (n'essayez pas, cette adresse est fictive). Mais la couche réseau IP n'a que faire des noms, elle ne connaît que des adresses.

Incidemment, avant même de résoudre cette embarrassante affaire de noms et d'adresses, ce que nous voulons envoyer ce ne sont pas des datagrammes IP, mais des courriers électroniques ou des interrogations au serveur. Mais là, la réponse est aisée. Notre logiciel de courrier électronique donnera à notre message la mise en forme convenable (définie par un RFC fameux entre tous, le RFC 822), puis le transmettra à un logiciel serveur de messagerie (couche application) conforme au protocole de transport de courrier électronique SMTP (Simple Mail Transfer Protocol) tel que Sendmail ou Postfix, qui s'occupera de déterminer comment atteindre le destinataire, et transférera toutes les informations et données nécessaires au protocole de transport TCP (couche 4 de l'OSI), qui lui-même entamera les manoeuvres nécessaires en envoyant des flux de bits à la couche IP (couche 3 de l'OSI), qui découpera tout cela en datagrammes avec les bonnes données et les bonnes adresses, et les enverra à la couche liaison de données (couche 2 de l'OSI).

Revenons maintenant à la question initiale, nous connaissons le nom d'un serveur (de courrier électronique, WWW, etc.) et ce qu'il faut à la couche IP c'est son adresse. Dans la vie courante, pour répondre à ce genre de question il y a des annuaires, eh bien sur l'Internet c'est la même chose. L'annuaire qui permet, si l'on connaît le nom d'un serveur, de trouver son adresse, et vice-versa, s'appelle le DNS (Domain Name System). C'est une immense base de données distribuée sur l'ensemble de la planète, peut-être la plus grande qui existe. Ce processus de résolution de noms en adresses est complété par un autre service, qui publie les noms des serveurs de courrier électronique qui desservent un domaine. Mais qu'est-ce qu'un domaine ?

L'espace des noms de l'Internet (il est important de garder à l'esprit que les schémas qui vont suivre décrivent un espace abstrait de noms de serveurs et de domaines, et pas la topologie du réseau physique qui les relie) est organisé de façon hiérarchique, selon un schéma calqué sur l'organisation du système de fichiers Unix que nous avons vu à la section 5.2.1 illustré par la figure 5.6. Ce système génial, dont le fonctionnement n'est pas très intuitif, a été gravé dans le marbre des RFC 1034 et 1035 par Paul Mockapetris, actuel président de l'IAB.

Figure 6.13 : Organisation en arbre des noms de domaine

La figure 6.13 montre l'organisation hiérarchique de l'espace de noms de l'Internet. Chaque noeud de l'arbre, représenté par un cercle, comprend un label, qui peut avoir jusqu'à 63 caractères de long, et pour lequel les lettres minuscules et majuscules ne sont pas distinguées. Le nom de domaine d'un noeud s'obtient en construisant la séquence de tous les labels des noeuds compris entre le noeud considéré et la racine inclus, séparés par des points, comme par exemple vera.sophia.inria.fr.

Sous une racine sans nom se trouvent un certain nombre de domaines de premier niveau (TLD, pour Top Level Domains). Chaque entreprise, association, université ou autre entité désireuse d'accéder à l'Internet appartiendra à un de ces domaines. Ceux qui ont des noms à trois lettres sont dits domaines génériques : com, edu, net, gov, respectivement pour les activités commerciales, éducatives, liées au réseau ou rattachées au gouvernement américain. Les TLD à deux lettres sont des domaines géographiques : fr, ca, be, de, dz respectivement pour la France, le Canada, la Belgique, l'Allemagne et l'Algérie. Le domaine arpa a un rôle particulier, il sert à la résolution inverse, c'est-à-dire à la traduction des adresses en noms.

Au niveau inférieur, au sein du TLD, on trouve généralement les domaines qui correspondent aux universités, entreprises, etc. qui se sont connectées à l'Internet. Elles ont choisi elles-mêmes leur nom de domaine, avec la contrainte que le nom complet doit être unique : il ne peut y avoir qu'un domaine inria.fr, mais il peut y avoir ibm.com, ibm.fr, ibm.be, etc. Ces domaines peuvent être eux-mêmes subdivisés : ainsi l'INRIA (Institut National de la Recherche en Informatique et en Automatique) aura sans doute un domaine pour chacune de ses unités de recherche, Rocquencourt, Sophia-Antipolis, Nancy, Grenoble, etc., qui s'appelleront peut-être sophia.inria.fr, nancy.inria.fr, grenoble.inria.fr, etc.

Cette subdivision peut atteindre des niveaux encore plus fins, mais nous allons supposer que l'INRIA en est resté là, et qu'au sein du domaine sophia.inria.fr au niveau juste inférieur se trouvent les noms des noeuds du réseau, qui sont des stations ou des serveurs auxquels leurs utilisateurs ont donné les noms asja, vera, salome, electre. Leurs noms complets, uniques pour tout l'Internet et auxquels le DNS aura pour mission de faire correspondre leur adresse IP, seront asja.sophia.inria.fr, vera.sophia.inria.fr, salome.sophia.inria.fr, electre.sophia.inria.fr.

Une station sur le réseau peut avoir, outre son nom propre tel que nous venons de le voir, un ou plusieurs alias. Ainsi il est de coutume que le serveur WWW d'un organisme soit connu sous le nom www.quelquechose.fr. Alors si le serveur WWW de l'INRIA Sophia est hébergé sur la machine asja, celle-ci recevra un alias, www.sophia.inria.fr. Les deux noms désigneront la même machine, ou plus exactement la même interface sur le réseau.

Il serait possible d'imaginer une administration centralisée de l'arbre des domaines, mais une fraction de seconde de réflexion révélerait l'immensité des difficultés qui en résulteraient. Aussi cet arbre est-il découpé en sous-arbres appelés zones, administrées séparément. Ainsi en France l'association AFNIC administre-t-elle tous les domaines dont le nom se termine par .fr : on dit que l'AFNIC a reçu délégation pour la zone fr. De même l'AFNIC déléguera l'administration de la zone inria.fr à l'INRIA, qui lui-même déléguera à une équipe de son unité de Sophia-Antipolis l'administration de sophia.inria.fr.

Dès lors qu'un organisme a reçu délégation de l'administration d'une zone, il a le devoir de mettre en service des serveurs de noms pour cette zone, au moins deux, un primaire et un secondaire. Un serveur de noms est un logiciel que l'on peut interroger : si on lui fournit le nom d'une machine il renvoie son adresse, et vice-versa. Dès qu'un nouvel ordinateur est mis en service dans une zone, l'administrateur du DNS de cette zone doit lui affecter un nom et une adresse et les ajouter à la base de données du serveur de noms primaire local. On dit que ce serveur de noms a l'autorité sur la zone.

Un serveur primaire obtient les informations relatives à sa zone en accédant directement les bases de données locales. Un serveur secondaire (il peut y en avoir plusieurs, et il est recommandé qu'ils soient physiquement distincts et redondants) obtient ces mêmes informations en les demandant au serveur primaire. L'opération par laquelle un serveur secondaire reçoit du serveur primaire l'information qui décrit la zone est nommée transfert de zone. La pratique courante est de demander à un collègue sur un autre site d'être secondaire pour votre zone, à charge de revanche.

Donc tout système installé dans la zone, lorsqu'il voudra traduire un nom en adresse, posera la question au serveur de la zone. Plus précisément, le logiciel d'application qui a besoin de l'adresse (par exemple votre navigateur WWW ou le logiciel de transfert de courrier électronique) fait appel à un résolveur, qui va dialoguer avec le serveur de noms qui lui aura été désigné.

Si le nom à traduire désigne une machine locale, le serveur interrogera directement sa base. Sinon, il doit interroger un autre serveur de noms, qui, lui, connaîtra la réponse. Comment trouver un tel serveur de noms, en possession de la réponse à la question posée ? Chaque serveur connaît (il en possède les adresses dans sa base de données) la liste des serveurs de noms racines, à ce jour au nombre de treize, dispersés à la surface de la planète mais surtout aux États-Unis qui en abritent dix. Ces serveurs racines détiennent la liste des serveurs de noms qui détiennent l'autorité pour tous les domaines de second niveau (dans notre schéma de la figure 6.13, la ligne ibm.com, inria.fr, etc.).

Notre serveur va donc interroger un serveur racine. Celui-ci répondra en donnant l'adresse du serveur qui détient l'information autorisée relative au domaine de second niveau dont relève le nom de domaine que nous cherchons à résoudre ; ce troisième serveur, interrogé, donnera soit la réponse, soit l'adresse d'un quatrième serveur plus proche du domaine concerné, etc. Le serveur interrogé initialement peut soit transmettre la première réponse au résolveur, charge à ce dernier d'interroger le serveur de noms suivant, et ainsi de suite : une telle interrogation est dite itérative. Le résolveur peut au contraire demander au serveur de faire son affaire des interrogations des autres serveurs de noms impliqués, une telle interrogation sera dite récursive.

Toute cette subtile conversation entre serveurs sera bien sûr ignorée de l'utilisateur. Les logiciels de courrier électronique ou de navigation sur le WWW savent faire appel au résolveur. Lorsqu'un abonné individuel à l'Internet allume son modem, la plupart du temps le routeur de son FAI lui envoie, grâce au protocole DHCP (Dynamic Host Configuration Protocol), en même temps que son adresse IP dynamique, l'adresse du ou des serveurs de noms auxquels le résolveur pourra s'adresser. Mais ainsi vous saurez à quoi correspond la case la plus perturbante du menu de configuration de votre accès au réseau : celle où on vous demande l'adresse de votre serveur DNS. Heureusement vous n'aurez presque plus jamais à la remplir.

6.5.7 Mécanisme de la couche IP

Nous allons maintenant étudier la façon dont des datagrammes IP qui contribuent à l'acheminement d'un message quelconque atteignent leur destination. Ce transfert de données a pour origine un ordinateur raccordé au réseau, évidemment. Le principe de la couche réseau IP consiste, à chaque noeud du réseau traversé, à déterminer le prochain noeud à atteindre, et plus concrètement sur quelle interface réseau émettre le datagramme. S'il n'y a qu'une interface réseau active, la décision est très simple, comme on peut l'imaginer. Par convention, la couche IP considère aussi une interface dite « locale », qui n'a pas d'existence physique et qui permet à un noeud de s'atteindre lui-même, cas trivial mais qu'il ne faut pas oublier de traiter.

Sur le noeud émetteur, le rôle de la couche IP est le suivant :

recevoir un flux de bits de la couche TCP (transport) ; TCP découpe ce flux en morceaux de taille raisonnable appelés segments ;
mettre chaque segment dans un datagramme (ou exceptionnellement plusieurs) ;
déterminer l'interface réseau appropriée pour atteindre l'adresse de destination ;
munir le datagramme d'une en-tête qui comporte les informations nécessaires à son acheminement, c'est-à-dire essentiellement, en ce qui relève de nos préoccupations du moment, l'adresse IP de l'interface émettrice et l'adresse IP du destinataire ;
remettre le datagramme à la couche liaison de données attachée à la bonne interface, avec si nous sommes sur un réseau local la bonne adresse de couche 2 (MAC).

Effectuer ces opérations, et notamment les trois dernières, c'est déterminer l'itinéraire (en anglais route) que doit emprunter le datagramme, soit par extension de langage effectuer le routage de ce datagramme.

Chaque station connectée à un réseau IP possède une table de routage, qui contient deux types d'informations : des adresses de réseaux et le moyen de les atteindre. Pour une simple station « feuille » du réseau, le nombre de cas possibles est limité :

dans le cas d'un réseau auquel la station est directement connectée, le moyen de l'atteindre est le nom de l'interface qui assure cette connexion ;
pour tout autre réseau, le moyen de l'atteindre est l'adresse du routeur qui y mène.

Fonctionnellement, la différence entre une station ordinaire et un routeur, c'est que le routeur est programmé pour recevoir des paquets sur une interface et les réémettre sur une autre, alors que la station sait juste émettre et recevoir. Lorsqu'un routeur réémet un paquet, il ne modifie pas l'adresse de l'émetteur, qui reste celle de l'émetteur original.

Une fois obtenue l'adresse IP de destination au moyen du DNS (voir section 6.5.6), l'algorithme d'émission d'un datagramme est le suivant :

Extraire de l'adresse de destination la partie « adresse de réseau ».
Chercher dans la table de routage cette adresse de réseau. Quatre cas sont possibles :
1. l'adresse du réseau de destination figure dans la table de routage et y correspond à un réseau directement connecté : il y a remise directe du datagramme sur ce réseau par l'interface désignée et le routage est fait (il faudra encore traduire l'adresse IP en adresse MAC par le protocole ARP (Address Resolution Protocol)¹¹ ;
2. le réseau de destination figure dans la table de routage et le moyen de l'atteindre qui y est mentionné est l'adresse d'un routeur : le datagramme est transmis à ce routeur selon le procédé vu pour le cas précédent ;
3. le réseau de destination ne figure pas dans la table de routage, mais la table mentionne un routeur par défaut : le datagramme est transmis à ce routeur ;
4. tout autre cas déclenche une erreur de routage (le trop célèbre message Network is unreachable).

Le cas le plus fréquent est bien sûr le cas 3 ! Si nous imaginons le réseau comme un océan qui reçoit des fleuves eux-mêmes dotés d'affluents, le réseau local de notre campus ou de notre université est un peu comme le bassin d'une rivière et de ses affluents : l'itinéraire par défaut pour nos bouteilles à la mer, c'est d'aller vers l'aval et de tomber dans le fleuve qui figure le réseau de notre FAI. Mais une fois dans l'océan, il va bien falloir trouver l'embouchure du fleuve qu'il faudra remonter pour arriver finalement au ruisseau sur la berge duquel repose le serveur WWW que nous voulons atteindre. Y a-t-il un gigantesque routeur central qui posséderait dans ses tables de routage les adresses de tous les réseaux de l'univers ? Ce serait une solution théorique, mais ce que nous avons déjà dit de l'Internet et ce que nous savons de sa vitesse d'évolution nous suggère que cela ne fonctionne pas ainsi : la solution est à la section suivante.

Algorithmes de routage

La solution hypothétique évoquée ci-dessus, d'un routeur central de l'Internet distribuant les datagrammes à tous les réseaux, et que l'on peut raffiner en découpant l'Internet en plaques organisées chacune autour d'un routeur possédant toutes les adresses réseau de la plaque et communiquant avec un routeur central moins monstrueux, possédant les adresses des plaques et le moyen d'attribuer un réseau à une plaque, cela s'appellerait le routage statique. C'était la solution retenue par les réseaux X25 du bon vieux temps du minitel et du monopole des réseaux, et c'est une solution utilisable à une échelle pas trop grande, pour un réseau d'entreprise par exemple. Mais pour un réseau de grande taille et dépourvu d'administration centralisée, comme l'Internet, ce ne serait guère réaliste. Ce qui a fait la force de l'Internet, c'est sa capacité à acheminer les paquets à destination dans un réseau en évolution permanente et sans administration centrale, bref le routage dynamique dont nous allons étudier maintenant les principes.

Pour poursuivre notre métaphore fluviale et maritime, les réseaux locaux et de FAI correspondent aux ruisseaux, rivières et fleuves et possèdent tous un routage par défaut simple : si la destination n'est pas locale, elle sera, le plus souvent vers l'Internet, c'est-à-dire au-delà des mers, donc vers l'embouchure (respectivement, vers le routeur de sortie du réseau local).

À leur embouchure sur l'océan de l'Internet, nous pouvons nous imaginer que chaque réseau de FAI possède un routeur, ou plusieurs dans le cas de deltas, chargés de trouver les bons itinéraires pour les paquets qui sortent du réseau ou qui veulent y entrer. Il pourra y avoir aussi des routeurs en pleine mer, chargés d'orienter de grands flux maritimes, vers le Cap Horn ou le détroit de Gibraltar... Les routeurs du delta du Gange ignorent bien sûr le détail des réseaux du bassin de la Méditerranée, détail qui devra en revanche être connu du routeur du détroit de Gibraltar. L'idée du routage dans l'Internet, c'est que tous ces routeurs sont capables d'échanger des informations, et que plus précisément ils informent leurs voisins des réseaux auxquels ils sont directement connectés. Ainsi, une fois notre datagramme¹² tombé dans l'océan, il va aller de routeur en routeur, aucun ne connaissant sa destination finale, mais chacun étant capable de trouver un itinéraire qui l'en rapproche. C'est ce que l'on appelle le routage dynamique.

Le routage dynamique, pour être efficace dans un réseau aussi vaste que l'Internet, met en oeuvre des protocoles complexes. En fait l'Internet est une confédération de réseaux IP, mais il existe pour l'organisation du routage un niveau d'agrégation intermédiaire, le Système Autonome (Autonomous System, AS), qui est un regroupement de réseaux qui peuvent être vus de l'extérieur comme une entité pourvue d'une autorité administrative unique. Ainsi, sauf pour ceux qui n'ont pas bien compris le fonctionnement de l'Internet, chaque FAI et ses clients apparaîtront comme un seul AS. Des tables de routage globales seront échangées entre AS. Au sein d'un AS seront utilisés des protocoles plus simples et des tables de routage plus petites, étant donné qu'un client désireux d'envoyer un paquet à une adresse extérieure à l'AS la remettra à un routeur de son FAI, qui, lui, possédera les tables de routages globales. Après tout, lorsque nous mettons une carte postale à la boîte, nous nous attendons à ce que la Poste française sache comment la faire parvenir à la Poste vénézuélienne, qui elle saura trouver notre correspondante à Caracas.

Le protocole global de communication de tables de routages d'AS à AS est BGP (Border Gateway Protocol). Il y a plusieurs protocoles de routage dynamique au sein d'un AS ou d'un réseau, celui qui tend aujourd'hui à être le plus utilisé est OSPF (Open Shortest Path First), qui repose sur un algorithme de recherche de parcours dans un graphe dû à Dijkstra en 1959 (encore lui ! inutile de dire qu'à cette époque il ne soupçonnait pas l'usage qui serait fait de son algorithme). OSPF et BGP ont supplanté d'autres protocoles parce qu'ils donnent de meilleurs résultats, mais cette supériorité est au prix d'une complexité élevée. Pour ceux de nos lecteurs qui ne se destinent pas à la profession d'ingénieur réseau, nous exposerons un protocole plus simple et encore souvent utilisé dans de petits réseaux, RIP (pour Routing Information Protocol), qui repose sur l'algorithme de Bellman-Ford, imaginé en 1957 par Richard Bellman et doté d'une version distribuée en 1962 par Lestor R. Ford Jr et D. R. Fulkerson. Comme beaucoup d'algorithmes utilisés dans le monde des réseaux, il est issu du domaine de la recherche opérationnelle, et appartient à la famille des algorithmes de calcul de chemin le plus court dans un graphe par une méthode du type « vecteur de distance », par opposition à OSPF qui appartient à la famille des méthodes de calcul « par l'état des liaisons ».

Les méthodes de calcul de chemin le plus court dans un graphe « par l'état des liaisons » comme OSPF imposent que chaque routeur possède dans ses tables la topographie et la description de l'ensemble du domaine de routage, et que toute cette information soit retransmise à travers tout le domaine chaque fois qu'elle subit une modification. En revanche avec les méthodes de calcul « par vecteur de distance » comme RIP chaque routeur ne maintient que l'information qui le concerne lui-même et celle relative à ses voisins immédiats. On conçoit qu'OSPF ait attendu pour se généraliser une époque de débits élevés et de mémoire bon marché, et que RIP ait eu plus de succès dans la période précédente.

Le but d'un algorithme de routage est de trouver le chemin le plus court entre deux points d'un graphe (respectivement d'un réseau). En termes de réseaux informatiques, « court » ne désigne pas vraiment une distance en termes de longueur, mais plutôt en termes de débit de liaison et de nombre de noeuds traversés ; une distance faible désignera une liaison rapide avec peu de routeurs, une distance élevée une liaison lente ou qui traverse de nombreux routeurs.

Le principe de fonctionnement de RIP est le suivant : chaque routeur du réseau propage sur toutes ses interfaces des vecteurs de distance, qui constituent en fait le résumé de sa table de routage. Initialement (c'est-à-dire à la mise sous tension) un routeur ne connaît qu'un itinéraire, celui qui mène à lui-même, avec une distance nulle. Mais en propageant cette table de routage élémentaire il va permettre à ses voisins d'apprendre son existence ; lui-même apprendra de la même façon l'existence de ses voisins, et des voisins de ses voisins ; ainsi au fur et à mesure les tables de routage des uns et des autres s'enrichiront. Ce que nous démontrent MM. Bellman, Ford et Fulkerson, c'est que cet algorithme converge, c'est à dire qu'à l'issue d'un certain nombre d'échanges de tables de routage le système constitué par ce réseau de routeurs atteindra un état stable, où l'envoi de nouvelles informations de routage ne provoquera plus aucune modification des tables.

Un routeur est capable de tester ses interfaces, et notamment de détecter la présence ou l'absence d'une interface qui répond à l'autre extrémité. En cas de coupure inopinée d'une liaison, les routeurs concernés la détectent, recalculent leurs tables de routage en affectant une distance infinie à la destination précédemment atteinte par la liaison coupée, et l'algorithme de propagation est exécuté à nouveau, jusqu'à l'obtention d'un nouvel état stable.

Le lecteur curieux de ces questions consultera avec profit le livre de Christian Huitema « Routing in the Internet » [32], qui lui donnera une description complète des problèmes de routage et de leurs solutions.

Problèmes de routage

Figure 6.14 : Avant le rebond

Dans de nombreux cas, RIP réussit brillamment à reconfigurer automatiquement un réseau endommagé et à lui rendre sa connectivité. RIP doit aussi éviter des pièges, comme celui tendu par la situation illustrée par la figure 6.14, où l'on voit, à l'état initial, un noeud B qui accède au réseau R par l'intermédiaire du noeud A.

Supposons maintenant que la liaison 2 entre A et R soit coupée inopinément (figure 6.15) : A connaissait un itinéraire vers R par cette liaison 2, il ne peut plus désormais essayer de faire passer ses paquets que par la liaison 1 vers B, ce qui est clairement sans espoir. Avec un algorithme trop naïf, A peut envoyer ses paquets à B, qui dirait « oui, je connais un excellent itinéraire vers R, via A », et acheminerait les paquets vers A, qui les renverrait vers B, et ainsi de suite... En fait, la convergence de l'algorithme dépend de qui envoie son vecteur de distance le premier :

Figure 6.15 : Rebond !

si A émet son vecteur de distance avant que B ait pu le faire, l'information de la coupure de la liaison 2 sera effectivement correctement propagée ;
si B émet son vecteur de distance entre l'instant où A détecte la coupure de liaison et celui où A aurait effectivement dû émettre le sien, par exemple parce qu'il a reçu une mise à jour en provenance d'un autre point du réseau, A va accepter la vision de B et nous aurons une situation de boucle ou rebond.

Une telle situation ne peut être évitée que par une convention. À chaque échange de vecteur de distance, la distance de A à R croît de 2 par le mécanisme suivant :

lorsque A constate la rupture de liaison, il mentionne dans sa table de routage une distance infinie vers R ;
si à cet instant A reçoit de B un vecteur qui indique pour R une distance 2, il constate que cette valeur est inférieure à celle contenue dans sa table, et la met à jour avec pour R la liaison 1 et la distance 2+1=3, puis diffuse son vecteur de distance ;
B reçoit le vecteur de A et apprend que son itinéraire vers R a maintenant une distance de 3 : il lui ajoute 1 et diffuse son vecteur avec la valeur 3+1=4...

Pendant tout ce temps, les paquets envoyés de A ou de B vers R seront routés de A à B puis de B à A et vice versa...

Pour éviter ce processus de boucle infinie, on fixera une valeur élevée qui sera considérée, par convention, égale à l'infini, et quand la distance atteindra cette valeur la destination sera réputée impossible à atteindre. Dans ce contexte, l'infini pourra être fixé à 32, par exemple. Les paquets seront aussi dotés d'un paramètre « durée de vie » (TTL, Time to live), à savoir un nombre maximum de noeuds qu'ils auront le droit de traverser avant d'être purement et simplement abandonnés.

6.5.8 Nouvelles tendances IP

Nous l'avons dit, le protocole IP est entré dans une période de transition de la version 4 à la version 6 (la version 5 n'a jamais été déployée). Compte tenu du nombre considérable d'installations concernées, cette transition sera longue et les deux versions sont appelées à cohabiter pendant des années. Les routeurs du coeur de l'Internet (les core routers) seront bien sûr appelés les premiers à pouvoir traiter simultanément les deux versions, ils le font déjà d'ailleurs, cependant que la migration des stations de travail de base n'est pas vraiment urgente. Il existe un RFC qui précise comment encapsuler une adresse v4 au format v6.

IPv6, outre le nouveau format d'adresses qui en est l'aspect le plus spectaculaire, comporte d'autres nouveautés qui vont donner des solutions techniquement correctes à des problèmes que la version 4 résout par des artifices fragiles. Parmi les artifices employés par IPv4 pour faire face à la pénurie d'adresses, nous avons cité CIDR (Classless Interdomain Routing) et NAT (Network Address Translation). Le nouvel espace d'adressage offert par les 128 bits de l'adresse IPv6 mettra un terme à ces acrobaties, et de toute façon l'ancienne notion de classe disparaît.

IPv6 introduit également de nouveaux protocoles de sécurité désignés collectivement par le terme IPSec. En fait IPSec intervient au niveau de la couche transport (TCP), mais IPv6 le rend obligatoire, cependant que des adaptations permettent de l'introduire avec IPv4. IPSec définit en gros deux classes de services, une destinée à l'authentification des parties, l'autre au chiffrement.

Le support des noeuds mobiles est un autre problème apparu après la conception d'IPv4, et qui avait dû être résolu par des adjonctions plus ou moins satisfaisantes. La question intervient au stade du routage : la station mobile établit une communication avec une station fixe, qui n'est par définition pas toujours la même. L'émission depuis la station mobile vers une adresse IP quelconque ne pose aucun problème particulier, ce qui est inédit c'est la façon d'atteindre la station mobile depuis un point quelconque de l'Internet. La solution utilisée sous IPv4, nommée mobile IP, assez expérimentale, est incorporée à IPv6 et généralisée.

La configuration d'une station sous IPv4 était souvent une opération manuelle laborieuse par manque de possibilités d'auto-configuration. Quel utilisateur n'a pas blêmi devant un écran où un logiciel lui demandait son adresse IP et, pire, celle de son serveur de noms ? Le déploiement de DHCP (Dynamic Host Configuration Protocol) a contribué à résorber ce problème, et cette solution sera généralisée avec IPv6.

6.6 Couche 4, transport

La couche transport a le numéro 4 dans le modèle OSI ; elle est la troisième couche de TCP/IP. Nous nous intéresserons essentiellement à TCP/IP, qui en fait propose le choix entre deux modèles de transport : UDP (User Datagram Protocol), protocole simple non fiable sans état, et TCP (Transmission Control Protocol).

6.6.1 TCP (Transmission Control Protocol)

Le protocole de transport TCP (couche 4 du modèle OSI) fournit aux protocoles de niveau application (HTTP comme HyperText Transfer Protocol pour le WWW, SMTP comme Simple Mail Transfer Protocol pour le courrier électronique, H323 pour la visioconférence, etc.) un flux de bits fiable de bout en bout au-dessus de la couche IP.

Pour obtenir ce résultat, TCP est un protocole en mode connecté, par opposition à IP qui est un protocole sans connexion, c'est-à-dire que tous les segments TCP qui correspondent au même échange de données sont identifiés comme appartenant à une même connexion.

Figure 6.16 : Segment TCP

Connexion

TCP découpe les messages qui lui sont remis par les protocoles de la couche application en segments. Chaque segment sera ensuite remis à la couche réseau (IP) pour être inclus dans un datagramme IP. La taille d'un segment est donc calculée de façon à ce qu'il puisse tenir dans un datagramme, c'est-à-dire que la taille maximum d'un segment est égale à la taille maximum d'un datagramme diminuée de la longueur des en-têtes de datagramme.

Une connexion est totalement identifiée par ses adresses d'origine et de destination (inscrites dans les en-têtes de ses datagrammes IP) et par ses numéros de ports¹³ d'origine et de destination, qui sont inscrits dans les en-têtes de ses segments TCP. L'association d'une adresse IP et d'un numéro de port sur le même noeud constitue une extrémité de connexion.

En fait le mécanisme des sockets réseau repose sur le mécanisme des sockets du noyau, qui est un mécanisme de communication entre processus. Mais il n'est pas illogique qu'un mécanisme de communication en réseau se traduise au bout du compte par une communication entre processus.

Modèle client-serveur et numéros de port

Les numéros de port sont des identifiants conventionnels. Selon le modèle client-serveur implicite dans ce type d'accès au réseau, un client actionné par un utilisateur (navigateur WWW, logiciel de courrier électronique) demande un service à un serveur distant (serveur WWW, serveur de courrier, serveur de fichiers...). Du côté du serveur, le service demandé est identifié par un numéro de port conventionnel, connu et habituel, en un mot réservé : 80 pour un serveur WWW, 25 pour un serveur de courrier électronique, 53 pour un serveur de noms). Du côté du client, TCP attribue à la demande de connexion un numéro de port arbitraire, non encore utilisé. Ainsi, il est possible d'établir entre deux noeuds plusieurs connexions vers un même service sans qu'elles se confondent : elles auront même adresse de serveur, même adresse de client, même port de serveur, mais des ports de client différents.

Poignée de main en trois étapes (three-way handshake)

Avant tout transfert de données, TCP ouvre donc une connexion, ce qui se passe selon la procédure suivante appelée poignée de main en trois étapes (three-way handshake) (voir figure 6.17) :

Figure 6.17 : Poignée de mains en trois temps

Le noeud à l'origine de la demande de communication (appelé communément le client) émet un segment TCP avec le bit SYN positionné, le numéro de port du serveur avec lequel le client veut communiquer dans le champ port de destination de l'en-tête de segment, un numéro de port arbitraire dans le champ port d'origine, les adresses d'origine et de destination convenables dans l'en-tête de datagramme. Le numéro de séquence est également initialisé dans l'en-tête de segment.
Le serveur répond en acquittant ce message au moyen d'un segment dont le bit SYN est lui aussi positionné, le bit ACK positionné également, les numéros de ports et adresses d'origine et de destination logiquement inversés par rapport au segment du client.
Le client acquitte lui-même ce message en renvoyant un segment avec le bit ACK positionné. À l'issue de cet échange en trois temps, client et serveur sont réputés s'être mis d'accord sur les numéros de ports nécessaires à l'établissement de la connexion.

Contrôle de flux et évitement de congestion

TCP est un protocole fiable de bout en bout au-dessus d'une couche réseau non fiable, c'est-à-dire qu'il assure entre les deux stations qui communiquent en dernière analyse le même type de sûreté que le protocole de liaison de données assure entre deux noeuds adjacents.

Pour garantir l'absence de pertes et le bon ordre de remise des segments, TCP utilise un algorithme de fenêtre glissante tout à fait similaire à celui que nous avons décrit pour la couche liaison de données à la section 6.4.2, que nous vous invitons de ce fait à relire.

Nous avions dit en décrivant cet algorithme de fenêtre glissante pour la couche 2 qu'il permettait un contrôle de flux, c'est-à-dire l'adaptation mutuelle du débit d'émission de l'émetteur et du débit de réception du récepteur par l'accroissement ou la diminution de la largeur de la fenêtre d'émission. Cette propriété de l'algorithme est bien sûr conservée si on l'applique à la couche transport, mais au lieu d'agir sur une liaison entre deux noeuds adjacents, le contrôle agit désormais à travers tout l'Internet. D'ailleurs, comme TCP est un protocole bi-directionnel, chaque extrémité de la connexion possède deux fenêtres, une en émission et une en réception.

L'application du contrôle de flux à grande distance produit des effets puissants mais à manier avec précautions : les implémentations modernes de TCP utilisent la technique dite du « démarrage lent » pour éviter de saturer un routeur surchargé à un point quelconque de l'itinéraire. La connexion démarre avec une fenêtre dont la largeur correspond à un seul segment. Si tout se passe bien (les acquittements ACK arrivent), la fenêtre d'émission est élargie progressivement. Si une fois la connexion établie en régime permanent des pertes de segments sont constatées, ce qui indique une congestion quelque part sur le trajet, la fenêtre sera à nouveau rétrécie.

Cette politique de démarrage lent et d'évitement de la congestion joue un rôle capital dans le fonctionnement général de l'Internet, qui sinon se serait effondré depuis longtemps. L'inventeur de cette innovation de grande valeur est Van Jacobson.

Nous invitons le lecteur à quelques secondes de réflexion admirative devant un dispositif technique conçu à l'origine pour une centaine de noeuds et qui a pu résister à une croissance de six ou sept ordres de grandeur, d'autant plus que cette conception n'était le fait ni d'un grand groupe industriel ou financier, ni d'un gouvernement, ni d'un conglomérat de telles puissances. Mais peut-être était-ce là le secret ?

6.6.2 UDP (User Datagram Protocol)

Nous ne dirons que peu de mots d'UDP, qui est un protocole beaucoup plus simple que TCP. Il fournit au-dessus d'IP un protocole de transport non fiable, sans connexion et sans état. UDP se contente de construire un datagramme doté, comme les segments TCP, d'un numéro de port d'origine et d'un numéro de port de destination, et de l'encapsuler dans un datagramme IP. UDP convient bien à l'envoi de messages brefs et isolés ; cela dit, il est généralement considéré comme un protocole dangereux, à n'utiliser qu'en toute connaissance de cause. Notamment, dans un mode sans connexion, il n'est pas possible de vérifier l'appartenance d'un paquet à une connexion légitime.

De façon générale, les protocoles sans état sont des trous de sécurité. C'est spécialement le cas des protocoles de niveau application destinés au partage de fichiers en réseau, que ce soit NFS pour Unix, Netbios pour Windows-xx, Appleshare pour MacOS. Il est relativement facile d'introduire des paquets parasites dans un échange de messages établi avec ces protocoles, et ils sont particulièrement dangereux parce qu'ils exécutent des programmes à distance par le protocole RPC (Remote Procedure Call), créent, modifient et détruisent des fichiers, bref ils donnent accès à tous les outils dont peut rêver un pirate sur une machine distante qu'il se propose d'attaquer.

6.7 Les téléphonistes contre-attaquent : ATM

La controverse entre les réseaux à commutation de circuits virtuels comme X25 et les réseaux à commutation de paquets « pure » comme TCP/IP a animé la décennie 1980. Les tenants de la première technique, ainsi qu'il a été signalé ci-dessus, étaient les opérateurs téléphoniques traditionnels, qui y voyaient un moyen de préserver leur méthode de facturation du transport de données au volume, cependant que les constructeurs de réseaux informatiques en ressentaient les lourdeurs qui se répercutaient en rigidités insupportables. L'Internet et TCP/IP ont fini par l'emporter grâce à la facilité de déploiement que leur conféraient la commutation de paquets associée aux protocoles de routage dynamique.

Les années 1990 ont vu une contre-attaque de grande envergure des téléphonistes sous les espèces d'ATM (Asychronous Transfer Mode). ATM ressuscite la commutation de circuits selon un protocole conçu par un centre de recherche de France Télécom, normalisé par l'UIT (Union Internationale des Télécommunications) et implémenté avec des moyens considérables.

Comme X25, l'architecture ATM comporte des aspects qui relèvent de couches différentes du modèle OSI :

couche 2 : format des données transmises au support physique, dont les différentes variétés sont spécifiées dans le protocole ;
couche 3 : établissement d'un circuit virtuel, qui fixe le ou les itinéraires possibles de bout en bout ;
couche 4 : contrôle de flux de bout en bout.

Cette confusion des couches nuit à l'adoption d'un protocole. Une des clés du succès de TCP/IP, c'est que les protocoles de couche 3 et 4 (IP, TCP, UDP...) sont totalement indépendants du support physique et de la couche de liaison de données sous-jacents. Avec X25 ou ATM, vous ne choisissez pas seulement un protocole, mais aussi une technologie de réseau, et en fin de compte un fournisseur de services réseau, c'était d'ailleurs le but poursuivi, il aurait peut-être été atteint en situation de monopole fort des téléphonistes, mais aujourd'hui ATM est globalement un échec même si certains opérateurs télécom l'utilisent encore dans leurs réseaux internes.

ATM fournit un service non fiable et connecté de transmission de datagrammes sur un circuit virtuel. Le terme datagramme signifie que le flux de bits transmis par le protocole est découpé en paquets acheminés indépendamment les uns des autres. Par non fiable nous entendons que le protocole ne fournit aucune garantie de remise des datagrammes ni aucun contrôle d'erreur. Le caractère connecté d'ATM est en fait discutable : certes il y a établissement de circuit virtuel, mais le protocole ne maintient aucune information d'état sur une transmission de données en cours.

Les datagrammes d'ATM s'appellent des cellules et ont une taille fixe de 48 octets de données (oui, c'est minuscule) auxquels s'ajoutent 5 octets d'information de contrôle, dont un numéro de chemin virtuel sur 12 bits et un numéro de circuit virtuel sur 16 bits, soit 53 octets au total.

La conjonction du mode non fiable et du circuit virtuel peut sembler paradoxale : X25 était fiable et connecté. En fait le circuit virtuel a deux rôles : éviter de placer dans chaque cellule une information complète d'origine et de destination (il ne resterait plus guère de place pour les données utiles), et maintenir des paramètres de qualité de service, essentiellement débit et isochronie. Préférer le débit à la fiabilité des données, c'est une attitude de téléphoniste ou de télévidéaste : une cellule corrompue dans une conversation téléphonique ou une image, ce n'est pas grave. Mais une cellule corrompue dans une transmission de données, c'est tout le message à retransmettre, et comme les cellules ne contiennent aucune information qui permette de les identifier, il faut retransmettre toute la transaction, éventuellement un grand nombre de cellules. Le numéro de circuit virtuel est fixé lors d'une procédure d'appel qui recourt à des cellules au format particulier, dites de signalisation, comme avec X25.

Beaucoup des idées élaborées pour permettre à ATM de gérer des communications avec des qualités de services diverses, appropriées à des applications telles que le transport de la voix et de l'image, ou le contrôle en temps réel de dispositifs matériels (machines, robots, dispositifs de sécurité), ont trouvé leur chemin dans les recherches actuelles sur le développement de TCP/IP.

6.8 Client--serveur ou poste à poste (peer to peer) ?

Tous les usages du réseau que nous avons évoqués jusqu'ici reposent plus ou moins explicitement sur le modèle client-serveur : un navigateur WWW (le client) demande une page à un serveur WWW, un logiciel de messagerie (le client) relève sa boîte à lettres sur un serveur par le protocole POP (Post Office Protocol), etc.

Ce modèle a de nombreux usages fort utiles, mais il ne saurait prétendre à l'universalité et il donne une vision restreinte des possibilités du réseau. En concentrant une grande partie du trafic sur des noeuds spécialisés, les serveurs, il crée une absence de fluidité et un risque de congestion. On peut imaginer un autre modèle où chaque noeud serait connecté, plus ou moins virtuellement, à tous les autres. Si un tel modèle était inimaginable il y a vingt ans pour des raisons techniques, la croissance continue des débits des réseaux, des tailles mémoire et des puissances de calcul disponibles permet d'imaginer que chaque ordinateur personnel au domicile de chacun devienne à la fois serveur et client. Je peux ainsi héberger mon propre site WWW sur ma machine, avec mes photos de vacances et mes articles. Mon fournisseur d'accès à l'Internet ne me donne pas d'adresse IP fixe ? Qu'à cela ne tienne, des bienfaiteurs de l'humanité comme dyndns.org fournissent (et gratuitement de surcroît) un service de noms de domaines dynamiques qui ajuste périodiquement l'adresse IP qui correspond à mon nom de domaine à moi, ce qui permet à mes « clients » d'atteindre mon site à tout moment.

Ce qui est décrit ci-dessus est encore trop artisanal : il faut publier des services afin que chacun puisse y accéder sans avoir à connaître leur localisation a priori. C'est le pas franchi par des protocoles comme Napster ou Gnutella, auxquels chacun peut s'abonner, et devenir serveur même à son insu (ce qui n'a pas forcément que des avantages, par exemple lorsque le serveur en question abrite des données que la loi interdit de divulguer parce qu'elles sont protégées par le droit d'auteur ou tout simplement interdites). L'information sur les services disponibles circule de proche en proche.

Une autre direction importante où les protocoles peer to peer joueront un rôle est celui du « calcul en grille » (grid computing) : un calcul important, tel que ceux effectués en dynamique des fluides ou en analyse de génomes, est partagé entre de nombreux ordinateurs en réseau. Si le problème et ses données sont faciles à subdiviser, les communications entre les noeuds de calcul ne seront pas intenses, mais si ce n'est pas le cas le réseau sera soumis à une forte charge et la coordination par un serveur central constituerait un goulot d'étranglement insupportable. L'utilisation d'algorithmes distribués et de communications bilatérales indépendantes entre les noeuds s'imposera. Ces questions sont encore du domaine de la recherche, même si des réalisations opérationnelles existent déjà.

Signalons que ce type de service a eu un précurseur très précoce, le protocole NNTP de diffusion des News du réseau (des forums, en fait), qui est doté de primitives dont les noms disent tout : ihave, post, takethis, check. Les articles des News se propagent de site en site, sans arbre hiérarchique prédéfini.

6.9 Versatilité des protocoles poste à poste

6.9.1 Définition et usage du poste à poste

Un grand coup de hache sur le modèle client-serveur est venu des protocoles peer to peer (souvent abrégés en P2P), ce que Wikipedia propose de traduire en français pas poste à poste et décrit ainsi :

« P2P désigne un modèle de réseau informatique dont les éléments (les noeuds) ne jouent pas exclusivement les rôles de client ou de serveur mais fonctionnent des deux façons, en étant à la fois clients et serveurs des autres noeuds de ces réseaux, contrairement aux systèmes de type client-serveur, au sens habituel du terme.

...

Les réseaux P2P permettent de communiquer et de partager facilement de l'information - des fichiers le plus souvent, mais également des calculs, du contenu multimédia en continu (streaming), etc. sur Internet. Les technologies P2P se sont d'ailleurs montrées si efficaces que le P2P est considéré par certains comme l'étape ultime « de la liberté et de la démocratie » sur Internet. Sans aller jusque là, on considère souvent que le P2P porte (et est porté par) une philosophie de partage et un profond esprit communautaire. »

Pour une présentation des évolutions récentes on pourra consulter la communication de Franck Cappello aux journées JRES 2005 [12].

Ces protocoles poste à poste sont utilisés massivement par les internautes équipés d'une connexion à heut débit pour échanger des fichiers aux contenus musicaux ou cinématographiques, au titre de ce que le droit français nomme la copie privée, et le droit américain fair use.

Les industries du disque et du cinéma n'étaient pas préparées à cette extension de la copie privée, à laquelle elles ont réagi principalement par le recours à la loi. Les premiers protocoles P2P, tel Napster, comportaient un serveur central qui recueillait et distribuait les adresses des participants, ce qui a permis aux industriels d'engager contre le propriétaire de ce serveur des actions en justice et d'obtenir sa fermeture.

Instruit par cette expérience, les protocoles poste à poste contemporains, tels KaZaA, Skype ou eMule, ne comportent pas de serveur central, ce qui oblige les entreprises qui souhaiteraient poursuivre leurs utilisateurs à les identifier un par un.

6.9.2 Problèmes à résoudre par le poste à poste

Les noeuds des systèmes poste à poste, quasiment par définition, sont des ordinateurs situés à la périphérie de l'Internet, et qui sont le plus souvent soit des machines personnelles dans un domicile privé, soit des postes de travail individuels au sein d'une entreprise qui n'a pas vraiment prévu qu'ils soient utilisés pour du poste à poste, voire qui essaye de l'interdire. Les conséquences techniques de cette situation sont les suivantes :

les ordinateurs concernés sont souvent éteints ;
ils n'ont souvent pas d'adresse IP permanente ;
voire pas d'adresse routable (adresses dites « NAT (Network Address Translation) »).

Il faudra malgré ce contexte d'amateurisme que tous les noeuds puissent être à la fois clients et serveurs, qu'ils puissent communiquer directement deux à deux, et que chacun en fonction de ses capacités contribue au fonctionnement général de l'infrastructure. Il faut qu'un noeud qui rejoint le réseau puisse découvrir ceux qui offrent les ressources qui l'intéressent, selon le schéma de la figure 6.18.

Figure 6.18 : Un poste client tente de rejoindre une communauté de pairs.

Pour surmonter les difficultés énumérées plus haut et atteindre ces objectifs, un système poste à poste comporte quatre composants fondamentaux :

une passerelle, qui publie l'adresse IP d'autres noeuds et permet à l'utilisateur de choisir une communauté au sein de laquelle il va échanger des données, comme représenté par la figure 6.19 ;

Figure 6.19 : Une passerelle (gateway) va permettre au nouvel arrivant de découvrir l'adresse IP d'un membre déjà connecté.
un protocole réseau pour l'établissement des connexions et l'exécution des opérations de transport de données ; un élément crucial de ce protocole sera bien sûr son aptitude au franchissement de coup-feu, comme indiqué par la figure 6.20 ; en effet la communication poste à poste serait impossible dans le respect des règles de filtrage qu'imposent la plupart des réseaux, notamment en entreprise ;

Figure 6.20 : Ici deux noeuds confinés par des coupe-feux (firewalls) essaient néanmoins de construire une voie de communication entre eux, mais le procédé retenu est rudimentaire et peu efficace.
un système de publication de services et d'annonces de ressources disponibles, qui permet à chacun de contribuer à l'oeuvre commune ;
un système, symétrique du précédent, de recherche de ressources, qui permet de trouver ce que l'on cherche, tel morceau de musique ou tel film, ou le chemin d'accès à tel téléphone réseau.

1: Voir Wittgenstein, Tractatus logico-philosophicus, [76].
2: Michel Volle me fait remarquer que cette expression consacrée par l'usage est malheureuse, il serait plus approprié de dire « théorie de la communication », conformément d'ailleurs au titre de l'article de Shannon, A mathematical theory of communication, (Bell System Technical Journal, vol. 27, juillet et octobre 1948)[61], ou « théorie des données ». L'ordinateur, ou le réseau de communication, contiennent et transmettent des données, qui ne deviennent de l'information que dans l'esprit d'un être humain, capable (et lui seul en est capable) de leur donner un sens. Voir à ce sujet http://www.volle.com/ulb/021115/textes/vocabulaire.htm.
3: On rappelle que par définition le logarithme de base a de x, noté log_ax, est le nombre m tel que a^m = x. On vérifie que log_aa = 1 et que, indifféremment à la valeur de a, log1 = 0 et log(a × b) = loga + logb. Cette dernière propriété, très intéressante puisqu'elle permet, avec une table de logarithmes, de faire des multiplications même si on ne connaît que la table d'addition, est (était ?) le principe de base de la règle à calcul, qui n'est pas autre chose qu'une table de logs en plastique.
4: Sans trop entrer dans les détails, signalons que la couche de liaison de données comporte deux sous-couches, dont l'une est la couche MAC (Medium Access Control, ou commande de l'accès au support physique). Dans le cas des réseaux locaux (Local Area Networks, LAN's), la couche 2 se réduit pratiquement à la sous-couche MAC, et de ce fait on rencontre les expressions couche MAC, adresse MAC etc.
5: ... ou de transmission sans fil.
6: Ceci est vrai des réseaux locaux et des réseaux téléphoniques des pays riches, maintenant presque toujours numériques. Ce ne l'est pas dans les pays dotés de réseaux téléphoniques et électriques de mauvaise qualité, qui de ce fait ont parfois intérêt à continuer à utiliser des protocoles moins rapides mais plus robustes.
7: ... ou UDP, l'autre couche transport disponible au-dessus d'IP.
8: Il y a une exception à l'unicité des adresses IP : sur un réseau connecté à l'Internet, on peut décider que certaines machines ne seront pas « visibles » de l'extérieur, c'est-à-dire qu'elles ne pourront pas être directement atteintes par une communication en provenance de l'Internet. Les communications qu'elles entameront se feront par l'intermédiaire d'un routeur qui, lui, sera « visible ». Ces machines non visibles pourront recevoir des adresses dites privées, pour lesquelles la contrainte d'unicité sera limitée au réseau local considéré. Le moyen par lequel elles communiquent avec l'Internet, que nous décrirons plus en détail un peu plus loin (cf. 6.5.4), repose sur une traduction d'adresse (NAT, pour Network Address Translation) effectuée par le routeur.
9: Incidemment, l'anglais translation se traduit ici en français par traduction, translation d'adresse ne veut rien dire et celui qui employe cette locution prouve simplement qu'il ne connaît ni l'anglais ni le français et qu'en outre il ne sait pas de quoi il parle.
10: En précisant qu'un port (en français sabord, orifice destiné à laisser passer un flux) dans la terminologie TCP/IP est un numéro conventionnel qui, associé à une adresse IP, identifie une extrémité de connexion, ou en termes plus techniques une socket, que l'on pourrait traduire par prise. Par convention certains numéros de ports sont réservés aux serveurs de certains protocoles ; ainsi le port 80 est réservé au protocole HTTP (WWW), le port 25 à SMTP (courrier électronique), les ports n° 137, 138 et 139 au protocole de partage de fichiers Netbios, c'est-à-dire qu'un serveur Netbios sera en écoute sur le réseau et attendra des tentatives de connexion sur ces numéros de port, cependant que les clients Netbios essaieront de s'y connecter. À l'extrémité côté client, le numéro de port est quelconque, en général supérieur à 1024, et choisi de façon à former un couple unique avec l'adresse d'origine. Incidemment, il est possible, lors de l'initiation d'une connexion réseau, de déterminer un tel couple {adresse,port}, nommé socket, doté de la propriété d'unicité, parce que ce n'est pas le logiciel client qui établit la connexion, mais le noyau du système d'exploitation, du moins dans les systèmes sérieux. La connexion est ainsi identifiée de façon unique par le quadruplet {adresse IP d'origine, port d'origine, adresse IP de destination, port de destination}. Cette abstraction permet à un noeud unique du réseau d'être simultanément serveur pour plusieurs protocoles, et également d'être à la fois serveur et client. Les pirates recherchent activement sur l'Internet les machines accessibles qui laissent ouverts des ports de protocoles réputés vulnérables pour essayer de compromettre le serveur à l'écoute.
11: Le principe du protocole ARP est le suivant : la station qui possède une adresse IP et veut connaître l'adresse MAC correspondante (cela ne marche qu'au sein d'un même réseau local, de type Ethernet par exemple) envoie en diffusion générale à toutes les stations du réseau un message qui comporte l'adresse IP en question. La station qui possède cette adresse IP se reconnaît et répond « C'est moi, et voici mon adresse MAC ».
12: Rappelons qu'un datagramme IP c'est un paquet, à la fragmentation près : si un datagramme est fragmenté, c'est chaque fragment qui est un paquet. La fragmentation tombe en désuétude.
13: Le terme port ne doit pas suggérer une métaphore portuaire : il s'agit en fait d'un numéro conventionnel, qui identifie éventuellement un protocole de niveau application, ainsi port 25 pour le protocole SMTP de courrier électronique, port 80 pour le WWW, port 22 pour le protocole de communication chiffrée SSH. En anglais port signifie sabord, lumière dans le piston d'un moteur deux-temps, bref un orifice par lequel peut s'écouler un flux. Comme le flux des données d'une communication selon un protocole donné. Un port est choisi lors de l'ouverture d'une socket (douille, ou prise), ce qui complète la métaphore de l'établissement d'un tuyau entre deux systèmes communicants, comme le camion citerne et la cuve à mazout. Voir aussi la note 6.5.4.