Chapitre 5 PROTOCOLES DU DOD (TCP/IP) 5.1 INTRODUCTION Au début des années 70, l'advanced Research Project Agency (ARPA) du département de la défense américain (DOD) a fait développer un ensemble de programmes capables d'interconnecter des ordinateurs en réseau. Le produit qui en est résulté est devenu ARPAnet qui a été une référence de base pour les travaux ultérieurs dans le domaine de la téléinformatique et en particulier pour la dénition des diverses normes. Les protocoles dénis pour ARPAnet ont été utilisés également par la suite pour transmettre des données à travers des réseaux locaux interconnectés. Ces normes sont connues sous le nom de TCP/IP, du nom des principaux modules de cet ensemble. C'est ce protocole qui a été déni comme base d'internet sur lequel a été construit le World Wide Web. En plus de ces modules et des modules mentionnés ci-dessous, ARPAnet possède un protocole de mise à jour des tables de routage. Le contenu de ce chapitre ne saurait sure pour entreprendre le développement des protocoles du DOD, mais il devrait permettre de comprendre les documents qui les décrivent et d'avoir un exemple de protocole complet traitant les problèmes des 7 couches du modèle OSI. Ce chapitre présente également une architecture logicielle qui permet de réaliser ces protocoles de façon systématique. Les principaux modules utilisés dans les réseaux locaux sont les suivants : IP, Internet Protocol Ce module décrit comment sont construits les datagrammes (= blocs de données) qui peuvent être acheminés à travers plusieurs réseaux (locaux ou à longues distances), éventuellement hétérogènes. Ce protocole ne gère pas de circuits, deux blocs appartenant à la transmission du même chier sont acheminés de façon indépendante et peuvent même parvenir à destination par des chemins diérents. Il inclut donc les adresses complètes des destinations dans chaque bloc. ARP, Address Resolution Protocol Ce protocole permet de trouver l'adresse physique d'une station sur un réseau local lorsque l'on ne connaît 53
que son adresse IP. L'ARP est utilisable lorsqu'un groupe de stations sont connectées sur un milieu de transmission homogène (câble passant par toutes les stations) qui est tel que chaque message inonde tout le milieu de transmission, ce qui n'est pas le cas par exemple lorsque l'on se connecte à Internet au moyen d'une ligne téléphonique. UDP, User Datagram Protocol Ce protocole permet d'envoyer des blocs de données indépendants les uns des autres. Il est très peu diérent de IP. TCP, Transmission Control Protocol Ce module correspond à la couche de transport du modèle OSI. Il s'appuie sur les datagrammes transmis par le module IP pour créer des connexions. Il est donc responsable du contrôle de ux, de la réémission des blocs perdus et de l'acheminement à un programme donné. TELNET, Telecommunications Network Ce module est principalement destiné à connecter des terminaux à des processus d'application. Il utilise TCP. Il permet de négocier un écho des caractères et de dénir quelle est l'extrémité de connexion qui s'en charge. Il dénit également la façon de coder les commandes d'eacements de caractères et de lignes ainsi que les interruptions de l'usager destinées à terminer prématurément un programme en cours. FTP, File Transfer Protocol Ce module assure la gestion de chiers à distance : création, copie, effacement, changement de répertoire, etc... Dans chaque site dont les chiers doivent pouvoir être manipulés, on crée un serveur qui attend les ordres FTP en provenance du réseau et y répond. Pour diérencier les commandes des données, FTP utilise 2 canaux TCP distincts. 5.2 IP : INTERNET PROTOCOL 5.2.1 Généralités Le protocole IP assure la transmission et le routage de paquets à travers un réseau (local ou étendu) ou un groupe de réseaux interconnectés. Les noeuds intermédiaires acheminent ces paquets de proche en proche en se référant aux adresses situées dans les en-têtes des paquets et à leurs propres tables de routage. Le protocole IP traite les paquets indépendamment les uns des autres. Il ne crée ni connexion ni circuit virtuel. Il ne possède aucun mécanisme qui garantisse l'intégrité des données ou le séquencement correct des paquets. Il n'eectue pas de contrôle de ux. Ces fonctions sont laissées aux autres couches : erreurs : la couche physique (par exemple Ethernet) sur laquelle IP s'appuie ajoute des codes de détection d'erreurs et ignore tous les paquets dans lesquels des erreurs de transmission dues à des parasites sont détectées. La couche TCP en ajoute également un. Il est possible d'ajouter un code détectant les erreurs dans l'en-tête. connexion, contrôle de ux : ces fonctions sont prises en charge par la couche supérieure (TCP) 54
Station Passerelle Station couche supérieure routage couche supérieure IP IP IP IP Réseau Réseau Fig. 5.1 Routage par le protocole IP 5.2.2 Modèle du protocole IP Le fonctionnement de IP est basé sur le modèle décrit sur la gure 5.1, la structure de ses blocs est décrite sur la gure 5.2 Lorsque la couche supérieure doit envoyer un datagramme à un correspondant situé dans le même ordinateur ou dans un autre, elle appelle la procédure d'émission de la couche IP et lui fournit un bloc de données, l'adresse du correspondant et une série de paramètres décrits plus loin. La couche IP détermine au moyen d'une table si le correspondant est dans le même ordinateur, s'il est directement atteignable ou s'il faut passer par une passerelle intermédiaire. Elle forme un bloc avec les données et l'en-tête IP (g. 5.2 et??). Ce bloc est envoyé à l'ordinateur qui contient le correspondant ou à la passerelle intermédiaire. Pour cela il faut, dans le cas d'un réseau à longue distance, sélectionner la bonne ligne de transmission et dans celui d'un réseau local, déterminer la bonne adresse physique sur le réseau local. Lorsqu'un ordinateur reçoit un paquet, il détermine si celui-ci est destiné à un processus interne ou s'il faut le passer encore plus loin sur un autre réseau. Le paquet est ainsi acheminé de proche en proche jusqu'au destinataire. Chaque paquet doit comprendre toute l'information nécessaire au routage, ce qui implique qu'il ait un en-tête plus grand que des paquets qui suivraient un circuit virtuel pré-établi et qui pourraient réutiliser les mêmes numéros après fermeture d'un circuit. En-tête niveau physique En-tête IP Données de la couche supérieure Fig. 5.2 Structure des blocs IP 55
Classe a 0 Réseau Adresse locale Classe b 1 0 Réseau Adresse locale Classe c 1 1 0 Réseau Adresse loc. Adressage étendu 1 1 1 Adresse indéfinie Fig. 5.3 Adresses IP 5.2.3 Module de gestion des erreurs Ce module, appelé ICMP (pour Internet Control Message Protocol) reçoit les messages indiquant des erreurs de paramètre ou de protocole et les traite. Il fait partie de la couche IP. Les blocs adressés à ICMP ont un code de protocole réservé (01, 9ème champ de la gure??). Les erreurs qui peuvent être traitées sont, par exemple, des paramètres invalides dans un message ou des ressources insusantes qui forcent un routeur à perdre des paquets. 5.2.4 Routage Tout ce qu'on demande des passerelles qui interconnectent les réseaux c'est de comprendre les adresses IP et de passer les paquets sur des réseaux qui rapprochent les paquets de leur destination. On tolère que IP n'achemine pas tous les paquets qui ont la même adresse par le même chemin. En d'autres termes, les couches supérieures doivent être construites de façon telle qu'elles ne reposent pas sur l'hypothèse d'une transmission séquentielle des paquets et qu'elles prennent des dispositions pour remettre les paquets dans l'ordre, si nécessaire. En principe les passerelles pratiquent un routage adaptatif. Elles connaissent la structure globale du réseau et acheminent les paquets "au mieux", c'est-à-dire sans contrôle par acquittement par exemple. Une adresse contient 32 bits découpés selon 4 formes diérentes (Fig. 5.3). La première partie de l'adresse identie le réseau, avec l'idée initiale qu'il y ait dans le monde entier une adresse distincte pour chaque réseau, de façon ce qu'il n'y ait jamais de risque d'ambiguïté dans le routage des messages lorsque l'on réunit plusieurs réseaux. La deuxième partie de l'adresse correspond aux adresses des stations sur les réseaux. Ces dernière années, on a cru arriver au bout des adresses IP, et une nouvelle version d'ip (IP version 6) a été standardisée. Cependant un nouveau découpage des adresses, plus n que celui de la gure 5.3 a permis de les économiser et l'arrivée de la nouvelle version est sans cesse repoussée. 56
VERSION IHL TYPE DE SERVICE LONGUEUR TOTALE IDENTIFICATION F FRAGMENT TTL PROTOCOLE CHECKSUM EN-TETE ADRESSE DE LA SOURCE ADRESSE DE LA DESTINATION OPTIONS BOURRAGE Fig. 5.4 En-tête IP 5.2.5 Routage lâche et routage strict IP comprend une option qui permet d'inscrire, dans un datagramme, une liste de passerelles à franchir pour passer d'un expéditeur à un destinataire donnés. Le routage eectué selon cette méthode peut être strict ou lâche suivant que l'expéditeur exige que le datagramme passe par toutes les passerelles de la liste mais seulement celles-ci ou qu'il tolère qu'un certain nombre d'autres passerelles intermédiaires soient visitées. Une autre option permet d'enregistrer la liste des passerelles traversées dans un datagramme traversant plusieurs passerelles. Pour cela, une marque dans le datagramme indique au programme IP de placer l'adresse de la passerelle chaque fois que le datagramme passe par une passerelle, à la suite des adresses déjà récoltées. La liste obtenue en inversant la liste récoltée, permet de renvoyer un datagramme vers la source, en suivant le même chemin qu'à l'aller, par exemple pour des besoins de tests ou de diagnostics. La taille du bloc doit être susante pour contenir toutes les adresses car il n'est pas rallongé en cours de route. 5.2.6 Fragmentation des datagrammes Le protocole IP étant construit pour acheminer des datagrammes à travers des réseaux hétérogènes, il peut arriver qu'à cause des limitations de la taille des blocs sur un réseau intermédiaire il faille découper un datagramme en fragments pour l'acheminer plus loin. Les en-têtes possèdent des champs qui permettent d'indiquer si les blocs qui arrivent sont des fragments ou des datagrammes complets. Dans l'en-tête de chaque fragment, on trouve la position du premier byte de ce fragment dans le datagramme complet. Ceci permet de reconstruire les datagrammes même si l'ordre des fragments n'est pas conservé et de refragmenter les fragments s'ils doivent traverser un réseau imposant des tailles encore inférieures. 5.2.7 Paramètres prévus par IP Les paramètres prévus dans l'en-tête IP sont présentés ci-dessous, dans l'ordre de leur placement (Fig.??) Version : 4 bits sont réservés pour le numéro de version. La présente est la version 4. La version 6 est dénie, mais utilisée principalement pour des 57
tests. IHL : Internet header length. Ce champ de 4 bits contient la taille de l'entête du datagramme en multiple de 4 octets. Le nombre minimum de quadruplets est 5. TDS : Type de service. Ce paramètre indique les exigences de transmission du datagramme au sujet de la vitesse et de la abilité. Un exemple d'un service qui demande un délai minimum, même au prix d'une abilité moindre, est donné par les communications vocales. Les 8 bits du champ TDS sont utilisés comme suit : Priorité D T R 0 0 Priorité : 1 1 1 : Contrôle du réseau 1 1 0 : Contrôle inter-réseau. 0 0 0 : Standard Délai (D) 0 : normal 1 : inférieur Débit(T) 0 : normal 1 : supérieur Fiabilité(R) 0 : normal 1 : supérieur Ces trois derniers bits indiquent quelles sont les qualités à favoriser dans le compromis délai-débit-abilité. Il ne faut évidemment pas demander les trois qualités à la fois. Chaque passerelle doit traiter ces indications "au mieux", c'est-à-dire que ce traitement est laissé à l'appréciation du réalisateur du système. Si les délais sont facilement traités en organisant des queues de priorité, il n'en est pas forcément de même pour les autres exigences... Longueur totale : La longueur totale, variant de 20 à 2 16-1, indique la taille totale du datagramme, mesurée en octets. Identication : Ce paramètre identie de façon univoque les datagrammes qui proviennent de la même source. Ceci permet de reconstruire les datagrammes fragmentés (voir ci-dessous). F (Fanions) : Ces fanions, situés dans les 3 bits supérieurs, permettent de gérer la fragmentation des paquets. Bit (plus signicatif) : toujours Bit 1 : peut être fragmenté Bit 2 : 1 ne doit pas être fragmenté dernier fragment 1 autre fragment Les passerelles ont l'interdiction de fragmenter les datagrammes dont le bit 1 vaut 1. Ceci est destiné à des applications qui, pour des raisons quelconques, ne peuvent pas réassembler les fragments. Au cas où une station ne peut transmettre un datagramme sans le fragmenter et qu'il possède le fanion interdisant la fragmentation, elle doit renvoyer un message rapportant le problème à l'icmp de l'émetteur. En envoyant des datagrammes 58
de grandeurs croissantes, avec ce bit à 1, jusqu'à ce qu'on reçoive une indication d'erreur, on peut donc trouver la plus grande longueur de datagramme qui peut être envoyée à un partenaire. Placement du fragment : Indication du placement du fragment par la position du premier octet de ce fragment à l'intérieur du datagramme complet. Le premier fragment d'un datagramme ainsi qu'un datagramme complet a ce paramètre égal à. Le bit "dernier fragment" permet de savoir quand le datagramme est complet. TTL : (Time To Live) Durée de vie maximale prévue pour le datagramme. Ce paramètre doit être décrémenté à chaque passage dans une passerelle et s'il vient à s'annuler, le datagramme qui le porte doit être éliminé. Ceci est destiné à empêcher que des datagrammes ne circulent indéniment dans des boucles à cause de problèmes de routage par exemple. Protocole : Ce code indique à quel protocole le datagramme appartient. 0 IP : Internet Protocol 1 ICMP : Internet Control Message Protocol 6 TCP : Transmission Control Protocol 17 UDP : User Datagram Protocol Checksum de l'en-tête : ce paramètre contient le complément à 1 de la somme modulo (2 16-1) des octets de l'en-tête. Il permet de détecter des erreurs de transmission dans l'en-tête, mais non dans les données, de façon à pouvoir accepter des données même si elles sont entachées d'erreurs (transmission de voix, etc). Dans les cas usuels, le protocole s'en remet à la couche inférieure (Ethernet...) ou supérieure pour la vérication de l'intégrité des données. Adresses de source et de destination : Ces champs contiennent les adresses de la source et de la destination, codées selon la gure 5.3. Options : Ces options décrivent à quoi le datagramme sert : données, contrôle, test.... Dans le cas normal, ce champ est absent. Quant il est déni (au moyen du champ IHL), il contient un octet indiquant le type de l'option, suivi éventuellement par un octet de longueur et par la valeur du paramètre selon le format ci-dessous. octet 0 octet 1 octet 2 à (N+1) FC Classe Numéro N Valeurs FC : fanion de copie Classe : 00 : contrôle 10 : déverminage et mesure Numéro : 0 : fanion de n 1 : sans eet 2 : sécurité, utilisé par le DoD pour marquer les documents secrets. 3 : routage lâche 9 : routage strict 7 : enregistrement de la route 8 : identicateur de stream" 4 : récolte des instants de passages dans les passerelles. Valeurs : données correspondant aux paramètres Bourrage : 8 à 24 bits nuls pour compléter le dernier quadruplet. 59
5.3 UDP : USER DATAGRAM PROTOCOL Le protocole UDP (user datagram protocole) permet d'envoyer un bloc de données d'un programme à un autre. Ce protocole est une extension très simple de IP. Il ne réémet pas non plus les blocs en cas d'erreurs. Il a été déni pour qu'on puisse construire son propre protocole au niveau d'une application. Pour que plusieurs applications exécutées dans le même ordinateur puissent s'échanger de tels blocs, les blocs IP sont complétés par un en-tête minimal, indiqué ci-dessous. 0 En-tête IP 31 Port source Port destination Longueur checksum données Chacun des 4 champs a une longueur de 2 octets Le port destination est utilisé par le système d'exploitation pour envoyer le bloc à l'application qui a indiqué qu'elle était prête à les recevoir. Le port source est optionnel. Il représente, s'il est diérent de zéro, le port sur lequel il faut envoyer la réponse pour que l'émetteur la reçoive. La longueur inclut le nombre d'octets d'en-tête plus celui des données. Le checksum" permet de détecter des erreurs de transmission. 5.4 ARP : PROTOCOLE DE RESOLUTION D'ADRESSE Ce protocole a été déni après TCP/IP et il est utilisable par d'autres protocoles aussi. Il est utilisé sur les réseaux locaux d'ordinateurs (chapitre 6) pour découvrir où se trouve une station possédant une adresse IP donnée. En eet aucun matériel n'utilise directement les adresses IP car il ne peut que rarement y avoir correspondance directe entre le code d'adresse physique (celle qui est reconnue par l'interface électronique) et l'adresse IP, ces deux types d'adresses possédant toujours un nombre diérent de bits, des sous-champs délimités différemment, etc... Pour retrouver un destinataire par son adresse IP, il faut diuser (broadcast) cette dernière à toutes les stations du réseau local (g. 5.5. Ceci suppose évidemment que le réseau qu'on doit utiliser possède un procédé de diusion. Le paquet diusé contient un en-tête indiquant qu'il s'agit d'une recherche d'adresse IP, l'adresse physique et l'adresse IP du diuseur ainsi que l'adresse IP recherchée. Les stations IP qui reçoivent cet appel testent si c'est leur propre numéro qui est recherché. La station qui reconnaît son adresse répond en retournant le bloc après y avoir ajouté sa propre adresse physique. Les passerelles participent à cette diusion et en protent pour mettre à jour leur propre table de routage et y insérer les adresses IP et physiques des stations diusantes. Quand une passerelle reçoit un bloc ARP contenant une adresse qu'elle sait transmettre en direction de la destination, elle répond en donnant sa propre adresse physique. La station qui a émis le bloc lui envoie donc ses blocs IP sans 60
Fig. 5.5 Requête ARP pour déterminer une adresse physique qu'elle ait besoin de savoir s'il s'agit de la passerelle ou de la station destinataire. La gure 5.5 montre un bloc lancé par la station IPa, physa pour découvrir l'adresse physique de IP2. Le bloc ARP a la structure suivante : hdr : Identication du type de matériel (16 bits), 1 pour Ethernet, 3 pour AppleTalk, (Notons que le code indiqué correspond forcément au matériel supporté par l'interface, sinon celui-ci n'aurait pas pu le lire!) pro : Identication du protocole (16 bits) 0800 pour IP hln : Longueur de l'adresse physique (8 bits) pln : Longueur de l'adresse logique (IP) (8 bits) op : Code de la commande (16 bits), 1 pour une requête, 2 pour une réponse sha : Adresse physique de l'émetteur de ce paquet (hln octets) spa : Adresse logique de l'émetteur de ce paquet (pln octets) tha : Adresse physique du destinataire (hln octets) tpa : Adresse logique du destinataire (pln octets). L'adresse logique correspond à l'adresse sous laquelle la station considérée est vue par le protocole de type "pro". A l'émission, l'adresse physique du destinataire n'étant pas connue, elle est mise à 0. Pour que la source du message soit toujours en première position, il faut échanger les champs des adresses physiques et logiques de l'appelant et de l'appelé avant de retourner le bloc. 5.5 TCP : PROTOCOLE DE TRANSPORT Le protocole TCP est le protocole de base d'internet. C'est lui qui garantit que les données perdues dans les routeurs surchargés ou transmises dans un ordre diérent de leur émission, parce qu'elles n'ont pas pris le même chemin pour arriver à destination, arrivent nalement correctement à l'utilisateur. Ce protocole établit des connexions entre programmes, qu'on peut s'imaginer comme des tuyaux sans pertes, sans duplication et sans désordre, alors même que la sortie du tuyau est contrôlée par un robinet qui s'ouvre et se ferme de temps en temps. 61
L'extrémité du tuyau est située dans le système d'exploitation. On l'appelle socket lorsqu'on la considère depuis un programme. Vue du réseau, elle est identiée par son port, doté d'un numéro unique dans l'ordinateur. Les données sont emballées dans des datagrammes IP qui circulent sur le réseau. Chaque émetteur met dans chacun de ces datagrammes une adresse IP. Lorsqu'un datagramme est reçu par le destinataire, les bytes qu'il transporte sont déversés dans un tampon identié par le numéro de port, d'où ils seront lus par le programme. TCP réalise le réglage de bout en bout (end to end control) en traitant les aspects suivants : échange de paramètres à l'ouverture d'une connexion (taille des tampons...) récupération des erreurs par retransmission des blocs entachés d'erreurs réglage du ux entre les usagers au moyen d'un protocole à fenêtre glissante et à taille variable ; les numéros de séquence comptent les caractères, non les blocs identication des usagers dans une station (gestion de ports) et multiplexage des connexions sur la couche IP remise des données dans l'ordre 5.5.1 Connexions multiples sur un numéro de port Il peut arriver que plusieurs applications doivent se connecter à un même serveur ou plutôt à des instanciations diérentes d'un même serveur. Par exemple tous les usagers externes qui veulent se connecter sur une entrée de terminal (Telnet) s'adressent au port 23 xé une fois pour toutes à cette valeur. Il faut donc trier les blocs qui arrivent sur ce port en fonction de leur provenance et ceci pour des applications distantes situées dans un même ordinateur ou dans des ordinateurs diérents. Deux appelants partant du même ordinateur doivent donc utiliser des numéros de port source diérents. La gure 5.6 décrit les identités de 3 connexions arrivant sur le même port. Comme chaque bloc de données contient les adresses IP de la source et de la destination et les numéros de port de la source et de la destination, tous les blocs sont ainsi parfaitement identiés. 5.5.2 Format des blocs Avant de détailler le protocole, voyons le format des blocs. Les blocs d'ouverture, de transmission de données et de fermeture de connexion ont tous la même forme. On peut donc très bien recevoir des données dans le bloc communiquant la demande d'ouverture d'un partenaire. Ce format est déni à la gure 5.7. Les champs s'expliquent d'eux-mêmes, à part le groupe de fanions, décrits ci-dessous, qui précisent quels sont les champs valides dans ce même bloc, et le "pointeur urgent" qui est lui décrit au paragraphe 5.5.5. La fenêtre indique combien d'octets le récepteur admet après le numéro de séquence indiqué à la dernière ligne. Les fanions sont les suivants : ACK Le numéro d'acquittement situé dans le champ d'acquittement est valide 62
Serveur Telnet port 12 adresse physique 50 port 12 port 13 connexion 75,13 48,23 connexion 75,13 48,23 connexion 75,13 48,23 port 23 adresse physique 48 adresse physique 75 Fig. 5.6 Trois connexions sur un port PORT SOURCE PORT DESTINATION NUMERO DE SEQUENCE NUMERO D ACQUITTEMENT LONGUEUR U A R P S F EN-TETE RESERVE R C S S Y I FENETRE G K T H N N CHECKSUM DE L ENTETE POINTEUR URGENT OPTIONS DONNEES Fig. 5.7 En-tête TCP PSH Cette indication est positive si la couche supérieure a provoqué l'envoi du dernier bloc (voir Ÿ5.5.4). Elle n'est pas reçue par le programme destinataire. RST Demande la libération de la connexion SYN Le bloc transporte une ouverture de connexion. Le premier octet de données envoyé aura le numéro qui suit le numéro de séquence indiqué dans ce bloc. FIN Demande de fermeture de la connexion. S'il n'y a pas de données dans le même datagramme, le numéro attribué à l'ordre FIN est celui qui est indiqué dans le champ des numéros de séquence. S'il y en a, l'ordre reçoit comme numéro de séquence, le numéro qui suit le dernier octet du datagramme. Remarque : Syn et Fin ont donc leur propre numéro de séquence pointant juste avant, respectivement juste après les données. 63
ouverture active ouverture passive (SYN, SEQ=200) (SYN, SEQ=200, ACK=201) confirmation (ACK=551) confirmation Fig. 5.8 Echanges nécessaires à l'ouverture de TCP 5.5.3 Ouverture, transfert des données et fermeture de TCP L'ouverture d'une connexion TCP est eectuée par trois échanges de messages (s'il n'y a pas d'erreurs de transmission). La gure 5.8 illustre les échanges sous une forme condensée. Le but de ces échanges est qu'on ait un transport des numéros de séquence initiaux (indiqués par le fanion SYN) de A vers B et de B vers A et qu'ils soient les deux acquittés, car les séquences ne commencent pas à 0 pour les raisons indiquées ci-dessous. Le message intermédiaire transporte à la fois le numéro initial et l'acquittement du message provenant de A. La fermeture est faite de la même façon, mais en remplaçant SYN par FIN. FIN recevant un numéro de séquence qui suit directement celui du dernier numéro de séquence, on est sûr que lorsque FIN est acquitté, le dernier caractère a été reçu lui aussi. Cela suppose que FIN soit acquitté dans le même ordre que les caractères. Les caractères sont transmis et acquittés au moyen d'un algorithme à fenêtre coulissante de taille variable (voir Ÿ4.2). La fenêtre indique le nombre de caractères qu'on peut envoyer en avance, avant d'avoir reçu un acquittement. Le numéro de séquence du dernier caractère pouvant être envoyé est égal à la somme du numéro d'acquittement et de la valeur déposée dans le champ de fenêtre dans les datagrammes reçus. Une fenêtre nulle indique donc qu'on ne peut momentanément plus recevoir de données. Il peut arriver qu'on utilise plusieurs fois de suite une connexion TCP entre les deux mêmes usagers, avec les mêmes ports. Par exemple pour transmettre plusieurs chiers. Si la connexion est chaque fois fermée et rouverte avec les mêmes numéros de séquence, il se pourrait très bien que des blocs de données d'une ancienne connexion soient acceptés dans la nouvelle connexion parce qu'ils ont été retardés par un chemin congestionné et qu'ils arrivent au moment où la nouvelle connexion est ouverte. Car comme on l'a vu, tous les blocs ne suivent 64
ACTIVE OPEN OR ACTIVE OPEN WITH DATA INIT SV. SEND SYN CLOSED UNSPECIFIED PASSIVE OPEN OR FULLY SPECIFIED PASSIVE OPEN INIT SV. CLOSE CLEAR SV CLOSE CLEAR SV SYN SENT RECV SYN SEND SYN ACK SYN RCVD RECV SYN SEND SYN ACK LISTEN RECV SYN ACK OF SYN SEND ACK ESTAB RECV FIN ACK OF SYN SEND ACK CLOSE SEND FIN RECV FIN CLEAR SV FIN WAIT CLOSE WAIT RECV ACK OF FIN RECV FIN SEND ACK CLOSE SEND FIN FIN WAIT 2 CLOSING LAST ACK RECV FIN SEND ACK RECV FIN ACK OF SYN SEND ACK RECV FIN ACK RECV ACK OF FIN TIME WAIT CLOSED Fig. 5.9 Automate TCP pas le même chemin et il est possible que dans l'ancienne connexion un bloc ait été considéré comme perdu et donc réenvoyé alors qu'il n'était que temporairement bloqué dans une passerelle congestionnée. Il y a deux moyens d'éviter ces accidents. Le premier est d'attendre un certain temps (2 minutes propose la norme) avant de réutiliser une connexion entre des ports identiques (mêmes usagers avec les mêmes ports). La deuxième est de continuer les numéros de séquences pour la connexion suivante. Ceci est possible, puisque les numéros de séquence initiaux sont communiqués au destinataire à l'ouverture (bloc SYN). Cependant comme la station peut être déclenchée entre les utilisations des deux connexions elle peut perdre ces numéros. Si la connexion est gelée pendant un certain temps et qu'on veuille établir des connexions entre deux stations sans attendre ce délai, il faut changer chaque fois de numéro de port. Heureusement il y en a susamment. 5.5.4 Formation des paquets La couche TCP transmet les données sous une forme qui se rapproche le plus possible d'un ux continu d'octets. L'utilisateur de TCP lui fournit des 65
groupes d'octets. TCP rassemble ces groupes ou les répartit à son gré dans les datagrammes. Le destinataire n'a pas connaissance des limites initiales des paquets. TCP peut décider d'envoyer un datagramme en fonction des critères suivants : Le datagramme est plein L'utilisateur a émis l'ordre push" L'utilisateur a émis des données marquées urgentes. Si l'utilisateur refournit des données avant que les précédentes n'aient pu être émises, elles sont ajoutées au datagramme encore en mémoire. 5.5.5 Données urgentes TCP fournit un mécanisme spécial traitant les données urgentes. L'utilisateur peut l'employer comme il l'entend, mais l'exemple suivant permettra de comprendre comment cela fonctionne. Cet exemple est celui de la purge des données d'une connexion. Si pour une raison ou une autre les données déjà injectées dans la connexion ne sont plus valables, l'émetteur envoie une marque prédéterminée en mode urgent. C'est-à-dire que le fanion urgent est enclenché dans les datagrammes, la position des dernières données urgentes est notée dans le champ correspondant et les datagrammes sont envoyés au plus vite". S'il y a plusieurs datagrammes en attente de transmission, le premier à partir, ou les acquittements si le récepteur a annoncé une fenêtre nulle, transmettra cette indication à l'autre extrémité. L'application du côté du récepteur a comme consigne de pomper et de jeter les données chaque fois qu'il détecte le mode urgent, et ceci jusqu'à la marque convenue. Cette marque est constituée par la position du caractère représentant le dernier caractère urgent, indiquée par la position relative de ce caractère par rapport au numéro de séquence. Cette valeur relative est placée dans le champ pointeur urgent". La position du caractère urgent est donc donnée par le numéro de séquence plus la valeur du pointeur urgent. Pour faciliter le travail du programme qui doit pomper les données devenues inutiles, il a été décidé que TCP fait obligatoirement une césure après le dernier caractère urgent et ne livre pas à l'usager dans le même bloc, les données jusqu'au caractère urgent et les données qui suivent, même si elles arrivent dans le même datagramme. Ainsi le programme qui appelle TCP peut faire des lectures de blocs de n caractères, avec n quelconque, jusqu'à ce que l'indication urgente ne lui soit plus indiquée. 5.5.6 Automate de TCP A titre d'information, l'automate gérant TCP est schématisé sur la gure 5.9. Dans les transitions, on trouve au-dessus de la ligne un événement et audessous l'action qu'il faut exécuter lorsque l'événement survient. La spécication du DOD précise exactement quels sont les événements attendus dans chaque état, quels sont les tests à faire sur les données apportées par l'événement, quel est le prochain état et quelles actions on exécute en fonction des résultats des tests. Sur ce diagramme, on reconna t les ouvertures actives (èches partant à gauche à partir de l'état central CLOSED) et les ouvertures passives (èches partant à droite). Si l'on imagine alors un automate utilisé en mode passif et un 66
autre en mode actif, on peut reconstruire les 3 échanges SYN et ACK reportés sur la gure 5.8. EXERCICE 1. Déterminer l'ordre dans lequel les transitions décrites dans l'automate de la gure 5.9 sont exécutées pour une ouverture puis une fermeture d'une connexion TCP. 5.5.7 Décodage de blocs IP EXERCICE 2. Les objectifs de l'exercice sont de savoir comment interpréter les paquets TCP circulant sur un réseau et d'être en mesure d'analyser un échange TCP de manière critique. On demande de décoder les trames suivantes observées sur un réseau Ethernet à partir des en-têtes décrits aux sections 5.2.7 et 5.5.2. Les paquets observés sont composés d'un en-tête Ethernet (6 octets d'adresse destination, 6 octets d'adresse source, et 2 octets de type de protocole), suivi de l'entête IP, l'entête TCP, etc. Remarquez que le bloc est plus long que la longueur indiquée dans l'en-tête IP, parce que les données occupent moins de 64 bytes et qu'il est donc agrandi articiellement. On a ci-dessous 60 octets + les 32 bits du code de détection d'erreur, qui ne sont pas achés, ce qui constitue la longueur minimale de 64 octets prévue par Ethernet. TCP from ltisun12.epfl.ch to disun45.epfl.ch 00 00 0c 02 78 28 08 00 20 0c db 79 08 00 45 00 00 2c 61 0c 00 00 3c 06 37 cb 80 b2 95 1a 80 b2 4f 76 0b 0d 00 17 59 d4 18 00 00 00 00 00 60 02 10 00 25 39 00 00 02 04 05 b4 10 00 TCP from disun45.epfl.ch to ltisun12.epfl.ch 08 00 20 0c db 79 00 00 0c 02 78 28 08 00 45 00 00 2c f6 7b 00 00 3a 06 a4 5b 80 b2 4f 76 80 b2 95 1a 00 17 0b 0d 06 74 58 00 59 d4 18 01 60 12 10 00 c6 b3 00 00 02 04 05 b4 00 44 TCP from ltisun12.epfl.ch to disun45.epfl.ch 00 00 0c 02 78 28 08 00 20 0c db 79 08 00 45 00 00 28 61 0e 00 00 3c 06 37 cd 80 b2 95 1a 80 b2 4f 76 0b 0d 00 17 59 d4 18 01 06 74 58 01 50 10 10 00 de 70 00 00 02 04 05 b4 00 44 TCP from ltisun12.epfl.ch to disun45.epfl.ch 00 00 0c 02 78 28 08 00 20 0c db 79 08 00 45 00 00 2e 61 0f 00 00 3c 06 37 c6 80 b2 95 1a 80 b2 4f 76 0b 0d 00 17 59 d4 18 01 06 74 58 01 50 18 10 00 df 4c 00 00 ff fd 03 ff fb 18 67
Fig. 5.10 Connexions à travers des routeurs 5.6 CONTROLE DE LA CONGESTION DES RE- SEAUX 5.6.1 Introduction Les blocs IP sont envoyés à travers Internet sans avertissement préalable, donc sans réserver de ressources. On ne peut donc pas refuser l'établissement d'une communication à quelques utilisateurs, comme c'est le cas pour le téléphone par exemple, lorsqu'un grand nombre de ceux-ci décident de transmettre des informations à travers un même réseau, presque simultanément. Il est donc possible qu'à un certain moment, un routeur reçoive plus de messages IP qu'il ne peut en transmettre sur les lignes sur lesquelles le routeur doit envoyer les messages, et cela pendant un certain temps. Les transmissions vont donc ralentir, ce qui mènera à ce qu'on appelle une situation de congestion. On pourrait augmenter la taille de la mémoire des routeurs, mais cela n'empêcherait pas les délais de transmission de cro tre. Il viendra donc un instant où les mêmes messages seront émis une deuxième puis une troisième fois par les émetteurs, car ils ne reçoivent plus d'acquittements dans les temps prévus. Les routeurs ne sont prévus que pour transmettre les messages le mieux possible, compte tenu des circonstances, et n'utilisent pas de moyens pour réguler ces congestions. La seule chose qu'ils puissent faire pour diminuer les congestions est d'équilibrer les nombres de messages en transmission sur les lignes de transmissions au cas où il y aurait plusieurs chemins pour arriver à une destination (g. 5.19). Les organismes qui s'occupent de dénir les concepts sur lesquels le réseau Internet fonctionne ont décidé de ne pas compliquer les protocoles de routeurs et de laisser la gestion des congestions aux utilisateurs. Le moyen choisi pour cela est d'adapter la taille de fenêtre aux conditions de transmission du réseau. En eet, la taille de la fenêtre représente exactement le nombre de caractères qui peuvent se trouver en transmission entre la source et le récepteur et donc dans le réseau. La limite supérieure du nombre d'octets contenus dans le réseau, si l'on ne compte pas les ré-émissions, est donc égale à la somme des valeurs des fenêtres des transmissions actives. La gure 5.11 montre le principe de la gestion de la congestion. Lorsqu'un noeud atteint un certain niveau de congestion, il se met à perdre des paquets 68
Fig. 5.11 Reseau Fig. 5.12 Temps aller-retour (message-acquittement) IP (soit des acquittements, soit des blocs de données). L'émetteur détecte ces pertes en constatant qu'un ou plusieurs acquittements n'arrivent pas dans les temps prévus. Il doit alors diminuer d'un peu sa fenêtre. Le problème qui se pose maintenant est d'évaluer le temps après lequel un acquittement peut être considéré comme perdu et la taille de fenêtre optimale. Si les utilisateurs limitent leur taille de fenêtre, les congestions vont donc automatiquement diminuer. Cependant, le débit d'un utilisateur est égal à la taille de la fenêtre divisée par le temps aller-retour sur le réseau, appelé RTT (round-trip time, g. 5.12) : Debit F enetre/rt T cette expression s'expliquant par le fait que pendant un temps RTT, seuls un nombre F enetre de caractères ont pu être envoyés. Il ne faut donc pas trop diminuer la taille de la fenêtre. Notons que pour mesurer RTT, il sut de noter l'instant de départ des messages et l'instant d'arrivée des acquittements correspondants et de calculer la diérence entre ces deux valeurs (g. 5.12). Notons également que la façon la plus rapide de transmettre des informations est d'être le seul à ne pas respecter les algorithmes présentés dans les paragraphes qui suivent, puisque les routeurs ne font pas (pas encore) de vérications. Actuellement la communauté Ethernet fait conance aux abonnés. Cette remarque implique aussi que si l'on veut tester un nouvel algorithme, il 69
Fig. 5.13 Mesure erronée des temps aller-retour ne sut pas d'établir une communication améliorée" entre deux utilisateurs, mais il faut qu'elle améliore l'ensemble du réseau. 5.6.2 Détermination du temps estimé de retour de l'acquittement Voyons d'abord comment calculer le temps d'acquittement maximal. On pourrait utiliser pour ce temps d'acquittement, la valeur de RTT avec une petite marge, mais ce temps peut varier passablement d'un instant à l'autre, car les communications des autres utilisateurs varient constamment. Un première solution consiste à calculer plutôt une valeur moyenne, de la façon indiquée cidessous, et de considérer qu'un acquittement est perdu s'il n'est pas de retour dans un laps de temps égal à 2 DelaiMoy : avec DelaiMoy = α DelaiMoy + β DernierRT T α + β = 1 et 0.8 < α < 0.9 Ainsi si tous les RTT ont la même valeur, la valeur DelaiMoy tendra petit à petit vers cette valeur de RTT. S'il y a parmi ceux-ci un seul RTT un peu diérent des autres, la valeur moyenne ne changera qu'un peu pendant quelques instants, mais reviendra vers la valeur de RTT. Cet algorithme ltre donc les variations rapides mais non les lentes. 5.6.3 Algorithme de Karn/Partridge En utilisant simplement la diérence des temps de départ d'un message et le temps d'arrivée de l'acquittement correspondant pour estimer le temps allerretour, on peut faire une erreur importante au cas où un message a été répété, comme le montre la gure 5.13. Suivant les circonstances, on peut calculer un temps beaucoup trop grand, ce qui ne porte pas à conséquence, mais on peut aussi calculer un temps trop court, ce qui provoquera de nouvelles retransmissions et donc des risques accrus de retrouver un temps court et risque fort d'établir une situation de mauvais fonctionnement qui se perpétue. Pour résoudre ce problème, Karn et Partridge ont proposé une extension de l'algorithme qui détermine la valeur pour le temporisateur de ré-envoi des 70
Fig. 5.14 Temps aller-retour sur le réseau messages. Lorsque le système suspecte une perte d'acquittement, il suppose que la raison en est une congestion et non une perte par erreur de transmission, ce qui est en eet beaucoup plus rare, et donc plutôt que de mettre à jour la valeur du délai au moyen du calcul précédent, il double la valeur de DelaiMoy, pour tenir compte de la situation de congestion (réelle ou supposée). Par la suite, la valeur DelaiMoy reviendra petitp à petit à sa valeur normale s'il n'y a plus de pertes. 5.6.4 Algorithme de Jacobson/Karel Comme l'illustre la gure 5.14, les valeurs du délai RTT varient au cours du temps. Si le nombre des usagers du réseau est stable, cette valeur ne uctue que peu et la valeur calculée au moyen des algorithmes précédent est relativement able. Par contre si le réseau est instable, il arrivera un moment où la valeur de pointe dépassera souvent le double de la valeur moyenne calculée au moyen de l'algorithme précédent. Pour calculer une valeur plus réaliste, il faut donc tenir compte du degré de uctuation du réseau. L'algorithme proposé par Jacobson et Karel ltre séparément d'une part la valeur moyenne et d'autre part la valeur moyenne des diérences entre la valeur moyenne et la valeur du dernier échantillon de RTT. ou avec α = 1 β DelaiMoy = α DelaiMoy + β DernierRT T DelaiMoy = (1 β) DelaiMoy + β DernierRT T (5.1) = DelaiMoy + β (DernierRT T DelaiMoy) (5.2) La diérence placée entre les dernières parenthèses représente la diérence indiquée sur la gure 5.14. Pour ltrer la valeur de l'écart moyen, on peut utiliser le même algorithme, mais naturellement en prenant la valeur absolue de la diérence, car l'écart est toujours positif, que la valeur instantanée diminue ou augmente. Si l'on écrit Dierence = DernierRT T DelaiM oy on a la valeur ltrée de la déviation : 71
EcartMoy = EcartMoy + β ( Dierence EcartMoy) et l'on peut réécrire l'équation 5.2 de la façon suivante : DelaiMoy = DelaiMoy + β Dierence La délai dans lequel l'acquittement devrait être arrivé est maintenant estimé à : Delai = DelaiMoy + 4 EcartMoy 5.6.5 Régulation de la fenêtre En plus du délai maximal, l'émetteur doit déterminer la taille de la fenêtre qu'il indique à son partenaire, d'une part en fonction de la place disponible dans sa propre mémoire F enetreannoncee et d'autre part en fonction de la congestion du réseau (F enetrecongestion). La taille de fenêtre insérée dans les messages est F enetreu tilisee = min(f enetreannoncee, F enetrecongestion) 5.6.6 Fenêtre de congestion Pour trouver la taille de fenêtre de congestion optimale, on part d'une petite taille, égale à MSS (maximum segment size) et on augmente petit à petit la taille de la fenêtre jusqu'à ce qu'on détecte des pertes de message ou d'acquittement. On diminue alors cette taille d'une valeur importante et on l'agrandit à nouveau petit à petit à chaque acquittement d'un bloc, puisque la congestion pourrait être seulement temporaire. On réduit à nouveau la fenêtre de congestion à la première perte, passant ainsi alternativement d'augmentations à des diminutions et vice-versa. Les expériences et des simulations ont montré qu'en fait il fallait diminuer plus rapidement que ce que l'on augmentait pour obtenir les meilleurs résultats. Si l'on part avec une petite fenêtre dans un réseau peu chargé, on se limite sans améliorer les congestions mais par contre si l'on part avec une fenêtre trop grande, on peut transmettre beaucoup de messages d'un coup et l'on risque de voir tous les messages se perdre, sans que l'on ait rien appris sur le niveau exact de congestion. Pour tenir compte de toutes ces contraintes, diérents algorithmes se superposent, entrant en action dans les diverses circonstances décrites ci-dessous. 5.6.7 Augmentation additive, diminution multiplicative L'algorithme de base est l'augmentation additive, diminution multiplicative. Chaque fois qu'un acquittement est reçu correctement, on ajoute un petit incrément correspondant à la valeur indiquée ci-dessous et chaque fois qu'on constate une perte de message, on multiplie la taille de la fenêtre par un facteur, mais un facteur inférieur à 1, typiquement 1/2. Rappelons que l'adaptation du temps maximal d'acquittement discuté aux paragraphes précédents continue d'être effectuée. 72
Fig. 5.15 Courbe suivie par la taille de la fenêtre L'incrément ajouté vaut : increment = MSS MSS F enetrecongestion Cette expression s'explique de la façon suivante. Au départ, F enetrecongestion est peu diérente de MSS et donc la fraction vaut à peu près 1 et l'incrément à peu près MSS. Puis lorsque la fenêtre grandit, la fraction diminue, et les incréments ne valent donc plus qu'une fraction de MSS. La taille de la fenêtre suit donc une courbe en dent de scie telle celle qui est représentie sur la gure 5.15. 5.6.8 Slow start L'algorithme indiqué au paragraphe précédent est valable pour maintenir une taille de fenêtre à une bonne valeur en régime permanent, mais si l'on doit transmettre de petites quantités de données, on restera toujours dans les zones de petites fenêtres et si le réseau n'est pas chargé, on ralentira donc les utilisateurs inutilement. Pour trouver plus rapidement une valeur acceptable de fenêtre, on part d'une taille égale à MSS et on double la valeur de la fenêtre de congestion chaque fois qu'on reçoit un acquittement dans les temps. Au bout d'un certain temps, il y aura une perte d'acquittement si le réseau est congestionné. On réduit la valeur de la fenêtre à la moitié, c'est-à-dire à l'avant-dernière valeur et l'on passe sur l'algorithme d'augmentation additive diminution multiplicative. Notons que ce départ est plus rapide que dans le cas précédent, mais le nom de slow start est entendu par rapport à la situation initiale de TCP où l'on partait avec une grande fenêtre, pas par rapport à l'algorithme précédent. Le slow start est également utilisé dans une autre circonstance où il mérite mieux son nom. Il s'agit du cas où l'on ne détecte un perte d'acquittement qu'après avoir attendu un certain temps sans envoyer de messages. A cet instant, la fenêtre a une valeur donnée (la dernière valeur calculée divisée par 2). Plutôt que de repartir directement avec cette valeur de fenêtre on repart avec l'algorithme slow start, mais on limite cette fois-ci sa progression à la valeur de la fenêtre déterminièe par les phases précédentes (g. 5.16). 73
Fig. 5.16 Slow start, départ progressif Fig. 5.17 Reconnaissance d'un acquittement perdu 5.6.9 Acquittement manquant Le récepteur envoie le numéro du prochain octet qu'il attend à chaque réception de message. Ainsi, si un message est perdu, les messages qui suivent sont acquittés avec le même numéro, jusqu'à ce que l'émetteur renvoie le message perdu, ce qu'il fera après que le temps aller-retour estimé ait été atteint sans l'acquittement du message perdu. L'émetteur a donc la possibilité de détecter cette situation (g. 5.17) en constatant l'apparition de plusieurs acquittements (en principe 3) avec la même valeur, sans attendre la n du délai d'attente de l'acquittement. Dans ce cas, le programme TCP doit évidemment diminuer sa fenêtre de congestion de moitié, et certaines versions de TCP continuent simplement avec la nouvelle fenêtre, alors que d'autres repartent avec un slow start limité à cette même valeur de fenêtre. Si l'on arrive à la n d'un délai sans l'arrivée de l'acquittement, on doit repartir avec un slow start. Cela ne para t pas très cohérent, puisqu'en cas de perte constatée au bout du délai, on pourrait se dire que l'utilisateur a déjà assez contribué à la baisse de la congestion simplement par l'attente supplémentaire. Toutefois si l'on ne reçoit pas les autres acquittements qui nous permettraient de constater la perte, on peut penser que la congestion est sévère. Notons que si la fenêtre est petite, il est peu probable que l'on pourra envoyer trois messages pour provoquer l'envoi de trois acquittements identiques. 74
5.7 GESTION DES ADRESSES IP Ainsi qu'on l'a vu, les adresses IP sont séparées en 4 classes diérentes. Les adresses de classe A ont toutes été réservées par le DoD à la mise en route du protocole. Les adresses de classe B ne fournissent que 16'000 réseaux de 64'000 stations et les adresses de classe C permettraient de dénir 2 21 réseaux de 255 stations. En attribuant les adresses selon ce schéma, on perd beaucoup d'adresses individuelles, car les réseaux n'ont pas souvent des nombres de stations proches de 64'000 ou de 255 et on a craint pendant un certain nombre d'années de voir s'épuiser rapidement le stock d'adresses. Le comité de l'ietf a donc préparé une nouvelle version d'ip (Ipv6) qui permet d'attribuer les adresses avec plus de souplesse. Cependant remplacer tous les programmes connectés à Internet serait aujourd'hui une tâche gigantesque et entre-temps, une autre façon de gérer les adresses IP a été mise au point. C'est le sujet du présent paragraphe. Les limites prévues par les classes B, C et D ne sont plus prises en compte, et on indique donc pour chaque adresse combien de bits il faut considérer pour l'adresse réseau, au moyen d'un masque, par exemple : 255. 255. 255. 192. 0 (masque) 128. 178. 45. 128. 0 (adresse) Tous les premiers bits du masque sont à 1. L'adresse réseau comporte donc dans le cas présenté ci-dessus les 26 premiers bits. Dans les routeurs, on mémorise pour chaque réseau (appelé alors subnet) la valeur du masque et la valeur du réseau, avec l'indication de l'endroit où il faut envoyer les blocs correspondant à cette adresse. Lorsque le routeur cherche où il doit envoyer un bloc IP, il scrute la table de routage et pour chaque entrée, il eectue l'intersection entre l'adresse du bloc IP et le masque indiqué dans l'entrée de la table (ET bit à bit des deux valeurs), puis il compare la valeur résultante avec l'adresse réseau de cette même entrée. Il est prévu que plusieurs masques de longueurs diérentes puissent correspondre, dans leur partie commune (correspondant donc au masque le plus court) à la même adresse réseau. Cependant une adresse IP qui correspond à l'adresse de réseau mémorisée sous le masque le plus long correspond forcément aussi à l'adresse réseau qui est dans l'adresse qui a le masque plus court, alors que l'endroit où il faut envoyer le bloc peut ne pas être la même. Dans ce cas, il est précisé que c'est l'adresse la plus longue qui est la bonne. Pour utiliser les bonnes adresses, il faut donc les déposer dans le bon ordre dans les tables (les adresses longues d'abord), ou utiliser des arbres adéquats qui ont été étudiés pour réaliser les recherches d'adresses dans ces tables. Quant à la recherche d'adresses eectuée par l'utilisateur, il faut diérencier les situations dans lesquelles il est sur une ligne téléphonique, auquel cas il envoie tous ses blocs sur la ligne et les situations dans lesquelles il est connecté à un réseau local (par exemple Ethernet). Dans ce cas, il conna t le numéro et le masque du réseau où il se trouve. S'il doit atteindre un partenaire sur le même réseau, il utilise le protocole ARP qui a été vu au début de ce chapitre. Sinon, il conna t l'adresse IP du premier routeur et il détermine son adresse physique à nouveau au moyen du protocole ARP. 75