 |
|
||||
|
 |
 |
|||
|
|
||||||||||||
|
|||||||||||||
|
|||||||||||||
|
|||||||||||||
|
1. Ethernet et la famille IP
Un réseau permet d'accéder aux
Le monde Unix étant un monde ouvert, il doit lui aussi fournir des outils d'accès au réseau. Pour cela, un ensemble de protocoles que l'on appelle "la famille des protocoles IP" a été constituée.
Nous allons revenir très rapidement sur la raison d'être de cette famille et présenter sa structure. Nous présenterons
ensuite les couches I et II d'Ethernet ainsi que le fonctionnement de la couche IP. 1.1.2. Pourquoi une famille de protocoles ?
Selon le matériel utilisé, on souhaite pouvoir accéder à
Selon les applications, nous avons de plus besoin de différents "services" tels que
La famille des protocoles IP offrent bien sûr l'accès à ces supports et propose en standard ces outils. Son atout majeur réside cependant dans son ouverture. En effet, une technologie mono-constructeur présente les inconvénients suivants :
En cas d'interconnexion avec d'autres environnements réseau, il est nécessaire
Il s'est donc rapidement avéré nécessaire qu'une normalisation soit mise en place afin de réduire les impossibilités d'interconnexion de réseaux hétérogènes. La première notion de normalisation est apparue dans les télécommunications car il s'agissait d'une volonté d'état. On retrouve le même principe pour les liens physiques en informatique. Nous pourrions donner une définition à l'ouverture des solutions informatiques afin de mieux en saisir l'importance :
"L'ouverture représente en fait l'universalité du fonctionnement d'un système quels que soient
Une solution possible à l'ouverture est "Internet" (inter-network). Le but d'internet est d'être accessible à partir de tout point informatique quelle qu'en soit la topologie. Nous pourrions modéliser l'accès à Internet par ce simple schéma :
 Du point de vue fonctionnel, il existe en tout point du réseau une même couche protocolaire permettant un dialogue homogène entre deux sites connectés. Dans ce cas il est fait abstraction
Il existe en effet une nouvelle boîte logicielle qui retarde la position de la couche apportée par le fournisseur :
 Quatre caractéristiques essentielles permettent de cerner la famille de protocoles IP :
Ces quatre caractéristiques permettent donc de dire que les protocoles IP sont un bon moyen d'accéder à l'internet.
Le modèle OSI comporte sept couches réparties comme suit :
 Le modèle de l'internet est quelque peu différent :
 1.1.4. l'Internet - Réseau mondial de communication informatique
La création d'Internet résulte d'un projet lancé par la DOD (projet DARPA). Le but de ce projet était de permettre aux militaires américains de partager et recueillir des données stratégiques en tout point du globe quels que soient les supports de télécommunications utilisés. Il y eut par conséquent une investigation des technologies de transmission : X25, satellite, etc, afin de connecter tous les sites DARPA du monde. Il en résulta la création du réseau ARPANET. Un deuxième besoin apparut alors : il fallait permettre aux militaires d'accéder aux ressources des co-contractants (données, programmes, calculateurs). Pour communiquer, on décida de créer une famille de protocoles. Cette famille a été mise en place sur ARPANET. Au début des années 80, ces protocoles ont été inclus dans la version Berkeley (BSD) d'Unix. La présence de ces protocoles sur Unix Système V et sur BSD a provoqué une explosion mondiale du trafic sur ce réseau. Aujourd'hui, deux organismes fédèrent le fonctionnement d'Internet :
L'idée d'Internet est simple : interconnecter des réseaux c'est-à-dire des machines et des passerelles :
 L'Internet propose des services de deux niveaux :
Il existe une certaine dépendance entre les différents niveaux d'IP :
 Nous examinerons dans les chapîtres qui vont suivre chaque protocole de cette famille afin d'en décrire tout le fonctionnement.
Ethernet est une technologie de bus partagé. Ethernet utilise des câbles cylindriques pour transmettre les signaux. Il existe deux supports physiques qui ont donné naissance à deux normes :
1.2.1.Utilisation des transceivers
Un transceiver est un montage électronique dont les buts sont les suivants :
Cet accès est distribué. Il est basé sur une technologie CSMA/CD (Carrier Sense Multiple Access with Collision Detection). Toute machine est autorisée à émettre sur le brin Ethernet à un instant t. Il n'y a pas de notion de priorité d'accès : la machine qui émet à un instant t est celle qui s'est rendu compte en premier que le brin Ethernet était disponible. Pour émettre, l'algorithme est simple :
Deux contraintes découlent de cette technologie :
Pour réduire les collisions sur le brin Ethernet, un algorithme optimal de calcul des temps d'attente T entre deux transmissions infructueuses a été inventé :
1.2.3. Mécanisme d'adressage Ethernet
Cet adressage permet l'élimination des trames erronées. On définit une adresse Ethernet par un entier codé sur 48 bits (i.e. un integer en langage C !). C'est une fourniture hardware pouvant être relue par soft. Chaque constructeur de cartes Ethernet possède une plage réservée d'adresse physique de cartes. Ces adresses sont uniques au monde. Ainsi les adresses physiques des machines sont directement associées avec la carte d'interface hardware. L'inconvénient de cette solution réside dans son évolution : si l'on change la carte Ethernet d'une machine, son adresse physique a changé ! 1.2.4. Structure d'une trame Ethernet Une trame Ethernet
Elle est constituée d'une entête et d'une zone de données :
 Le champ "Type de paquets" indique quel protocole de niveau supérieur est employé. Trois valeurs sont à retenir :
Nous pouvons déduire de cette technique que le protocole Ethernet accepte d'autres protocoles de la couche supérieure que ceux de la famille IP. Ainsi, un brin Ethernet peut véhiculer des paquets IPX/SPX. Toutes les trames se différencient ensuite par leur type. 1.3. Présentation des "gateways"
Dans le réseau Internet, les machines dénommées Gateways offrent toutes les interconnexions à travers le réseau physique (réseau "araignée") => elles sont capables de router tous les paquets. Les gateways dirigent les paquets vers le réseau destinataire et non pas vers la machine destinatrice. Une gateway pourrait donc être vue comme un transceiver intelligent (ou comme un commutateur de paquets IP). Nous verrons que les gateways ont des propriétés particulières et agissent sur les modes de fonctionnement des protocoles de la famille IP.
Ethernet utilise des adresses physiques pour décrire de manière unique chaque machine. Les couches de niveau supérieur ne se base pas sur cette identification. Aussi IP utilise-t-il des adresses Internet permettant aux couches IP de reconnaître de manière unique une machine.
Il existe trois classes d'adresses internet : il s'agit des classes A, B et C. Chaque classe d'adresse IP désigne une gamme de réseau. Une gamme est définie par le nombre de machines qu'elle comporte. Considérons la modélisation des trois classes A, B et C :
 D'après le découpage de ces trois classes, on peut remarquer que
Le tableau suivant reprend donc les valeurs de masque possibles pour ces trois classes :
Remarque : les différents champs de l'adresse sont séparés par des points (par convention). Exemples d'adresse de classe A :
Exemples d'adresse de classe B :
Exemples d'adresse de classe C :
Certaines adresses sont toutefois réservées :
1.5. Le protocole ARP (Address Resolution Protocol)
Nous avons vu dans les paragraphes précédents que le protocole Ethernet possédait un adressage physique des machines. À l'inverse, le protocole IP utilise un adressage logiciel. Lorsqu'une machine souhaite émettre une trame IP sur un brin Ethernet, elle doit donc être capable d'associer un couple (@IP appelante - @IP appelée) à un couple (@Ethernet appelante - @Ethernet appelée). Cette équivalence est obtenue par le protocole ARP (Address Resolution Protocol) qui, par des trames Ethernet spécifiques, permet d'interroger les machines quant à leurs adresses. Comme nous l'avons vu précédemment, une requête ARP s'encapsule dans les trames Ethernet. Pour cela, le champ "Type de paquets" prend la valeur
Toute trame appartenant au protocole ARP a la structure suivante :
Une requête ARP n'a pas d'entête fixe. Son codage est le suivant :
 Le champ Hardware permet au protocole ARP de spécifier le support réseau sur lequel il s'appuie. La valeur 1 désigne le réseau Ethernet. Puisque ARP indique le protocole des couches 1 et 2, il lui est possible de fonctionner sur d'autres réseaux que des réseaux Ethernet. Le champ Protocole désigne le protocole de niveau supérieur. Dans le cas qui nous intéresse, il s'agit du protocole IP et par conséquent ce champ prend la valeur 0x800h. HLEN et ILEN désignent les longueurs des adresses Hardware (HLEN) et des adresses internet (ILEN). De nouveau, on constate la souplesse du protocole ARP puisqu'il peut gérer des adresses de taille variable. Le type de demande indique s'il s'agit du protocole ARP ou du protocole RARP. S'il s'agit d'ARP, deux valeurs sont possibles :
Une requête ARP consiste à poser la question suivante : "Quelle est l'adresse Ethernet de la machine dont l'adresse Internet (ou autre suivant le choix du protocole de niveau supérieur) est xxxxx ?". Par conséquent une réponse ARP est : "L'adresse Ethernet (ou autre) de la machine dont l'adresse Internet est xxxx est yyyyy". Pour réduire le nombre de trames ARP émises, toute machine émettant une requête y inclue sa propre adresse physique. La machine réceptrice stocke alors l'adresse Ethernet de la machine émettrice. Lors d'une connexion par IP, elle ne redemandera donc pas cette valeur. 1.6. Le protocole RARP (Reverse ARP)
Le protocole RARP est l'exact inverse du protocole ARP. Il permet de connaître l'adresse IP d'une machine dont on connaît l'adresse physique. Intérêt du protocole RARP : une machine sans disque connaît son adresse physique (qu'elle est capable de lire sur sa carte Ethernet). Par contre, elle ne connaît pas son adresse Internet. Par conséquent, elle doit interroger un serveur qui connaît son adresse. Pour ce faire, elle émet donc une trame RARP dans laquelle est spécifiée son adresse physique. Émettre une trame RARP consiste donc à poser la question suivante : "Qui peut me dire quelle est l'adresse Internet correspondant à la machine dont l'adresse physique est xxxx ?". Une machine ayant cette information (typiquement le serveur de réseau local) répond par une trame RARP. Une trame RARP s'encapsule dans une trame Ethernet de la même manière que ARP :
 Une trame RARP a la même structure qu'une trame ARP :
 Le type de demande peut prendre deux valeurs :
1.7. Le protocole IP (Internet Protocol)
Le protocole IP appartient à la couche 3 du modèle OSI. Il fonctionne en mode non sécurisé c'est-à-dire que le transport des données par IP n'est pas fiable. Listons les avantages et inconvénients de ce protocole :
La couche IP permet d'interfacer une couche d'interface réseau (couches 1 et 2 du modèle OSI) avec une couche de transport (couche 4 du modèle OSI). On retrouve donc le respect du modèle Internet :
 La couche IP va donc permettre de s'abstraire de la structure du réseau pour mettre en rapport un émetteur et un récepteur :
 Si l'on compare le modèle TCP/IP et le modèle OSI, on remarque que la couche logicielle TCP/IP se décompose suivant 4 axes essentiels :
Il faut bien garder à l'esprit qu'IP respecte le modèle en couches. En effet, les protocoles en couches sont prévus pour que la couche n du modèle ISO de la machine destinatrice reçoive le même type d'objet que la couche n de la machine source. Si nous résumons dans un schéma ce que respecte IP (et les protocoles de transport s'appuyant sur celui-ci) :
 IP émet donc des datagrammes qui sont composés de deux parties :
Un datagramme IP encapsulé dans une trame Ethernet ne peut pas dépasser 1200 octets (contrainte imposée par le protocole Ethernet). Cependant un datagramme IP peut atteindre une taille de 4096 octets au maximum. On préfère ne pas dépasser cette valeur car des paquets volumeux sont plus difficiles à transporter (mais plus simples à perdre !). 1.7.1. Structure d'un datagramme IP
Un datagramme IP a la structure suivante :
 Le premier champ d'un datagramme IP désigne le numéro de version de la couche IP de la machine. En effet, il existe de nombreuses versions d'IP. De nos jours, on utilise la version 4 de ce protocole. Tout datagramme issu d'une version récente d'IP commence donc par la valeur binaire 0100b. On déclare la version d'IP utilisée dans les datagrammes afin de vérifier que deux couches IP de deux machines différentes sont capables de dialoguer. Le champ "Lg entête" indique la longueur de l'entête du datagramme. Celle-ci varie en fonction de la version d'IP employée ainsi que des options choisies. Le champ "Service" est très important. Il se décompose en plusieurs champs dont chacun représente un bit :
 Le premier champ "Précédence" est défini sur trois bits qui permettent de graduer le niveau d'intérêt du datagramme. Le niveau le plus haut concerne les datagrammes de contrôle du réseau (on les dénomme en anglais "Network Datagrams Control"). Ces datagrammes ont une précédence de 7 (le champ précédence prend donc la valeur binaire 111b). Les datagrammes de données sont les moins importants. On dit qu'ils ont une précédence normale. La valeur du champ précédence est alors 000b. D, T et R sont des drapeaux que le protocole IP passe à 1 ou à 0 suivant leur validation/invalidation. D signifie "Delay", T signifie "Throughput" et R "Reliability". Par conséquent, si
Le champ "Time To Live" est une valeur exprimée en secondes. Elle représente le temps pendant lequel le datagramme peut circuler sur le réseau. Il faut donc voir ce champ comme une valeur d'expiration du datagramme. Ce champ est notamment modifié par les gateways : chaque fois que le datagramme passe par une gateway, la valeur du TTL est décrémentée. Ainsi, un paquet dont l'adresse IP n'existe pas ne restera pas indéfiniment sur le réseau. Le champ "Proto" indique le protocole de plus haut niveau. Ce champ indique donc s'il s'agit d'UDP, de TCP ou de VMTP par exemple. Le champ CRC calcule un checksum pour l'entête IP. Attention : les contrôles d'erreur d'IP ne concernent que les entêtes ! Le champ "Options" est variable. Toutefois, pour conserver des entêtes IP multiples de 32 bits, on utilise parfois un champ de bourrage dans lequel tous les bits sont mis à zéro. Le champ "Options" se subdivise en plusieurs zones :
 Une option est toujours définie sur 8 bits. A cet octet s'ajoutent
Le bit "Copy" s'adresse aux gateways. Si ce bit est placé à un, lors de la fragmentation de paquets, les gateways devront recopier les options dans tous les fragments. Dans le cas contraire, les options ne sont pas copiées. Le tableau ci-dessous reprend les classes et numéros d'option les plus courants :
Chaque classe d'option a une signification particulière :
L'option 7 de la classe 0 est intéressante car elle demande à chaque gateway d'enregistrer les adresses IP utilisées pour véhiculer un paquet. Il est alors possible de mémoriser le chemin emprunté par un datagramme. L'option 9 de la classe 0 permet d'imposer un chemin particulier pour le transport du datagramme. Cette option est donc directement suivie de la liste des adresses IP par lesquelles il faut passer. L'option 3 est une variante plus souple de la version 9 : il est possible de passer par une adresse IP non spécifiée dans la liste pour joindre deux adresses IP imposées (i.e. le chemin utilisé entre deux adresses IP imposées est laissé libre). Enfin l'option 4 de la classe 2 contient une liste vide de valeurs lors de l'émission du datagramme. Chaque gateway écrit son adresse IP dans cette liste ainsi que l'heure et la date à laquelle le datagramme lui a été confié. Ainsi, tout comme un road book, la liste contient à l'arrivée du paquet, les passerelles par lesquelles il est passé ainsi que ses heures de passage. 1.7.2. Gestion de la fragmentation des datagrammes
Trois champs des datagrammes IP permettent la fragmentation et le ré-assemblage de ces derniers. Il s'agit des champs "Numéro de paquet", "Drapeaux" et "Numéro de fragment". Le numéro de paquet est codé sur 16 bits (valeur min = 0000000000000000b = 0d, valeur max = 1111111111111111b = 65535d). Les drapeaux comprennent 3 bits. Enfin, le numéro de fragment (ou plus exactement l'offset du fragment dans le datagramme complet) est défini sur 12 bits (valeur min = 000000000000b = 0d valeur max = 111111111111b = 4096d). Cette valeur est une mesure de 8 octets (à partir de 0). Tout datagramme IP peut donc prendre un numéro compris entre 0 et 65535 et être découpé en 4096 fragments. Le premier de ces trois champs permet donc de numéroter chaque datagramme et le troisième champ indique l'emplacement de celui-ci dans le datagramme complet. Les trois bits utilisés par le champ "Drapeaux" ont chacun une signification particulière :
1.7.3.1. Routage à travers un seul réseauCe routage s'appuie alors sur le protocole ARP. IP émet une requête ARP pour connaître l'adresse physique de la machine cible. Une fois les adresses physiques connues des deux machines, les datagrammes IP sont encapsulés dans les trames Ethernet et transportées vers la machine cible. Pour savoir si les machines cible et source appartiennent au même réseau, IP examine les deux adresses Internet des machines. En extrayant le champ "ID du réseau" des deux adresses et en comparant leur valeur, on doit obtenir le même résultat. Dans le cas contraire, il est nécessaire de passer par une gateway et l'on ne peut alors pas utiliser le protocole ARP. 1.7.3.2. Routage à travers plusieurs réseauxIl est impératif pour IP de trouver la gateway la plus proche pour lui transmettre les datagrammes à envoyer sur un autre réseau. C'est pour cette raison que l'on considère les gateways comme des machines interconnectées dont les connexions permettent de relier tous les points IP du monde. Les datagrammes passent de gateway en gateway jusqu'à atteindre leur destination. Les gateways utilisent des tables de routage pour établir les points IP qu'elles peuvent atteindre directement. Sur chaque machine ayant la connaissance de destinations externes au réseau physique sur lequel elle se trouve, il existe une table de routage. La machine examine l'adresse du réseau destinataire au lieu d'examiner l'adresse de la machine destinatrice. Ainsi donc, une table de routage est composée de couples (N, G) N désignant une adresse de réseau et G l'adresse de la gateway par laquelle il faut passer pour atteindre ce réseau. Une table de routage contient également les définitions des routages directs. Il est possible également de définir des routages par défaut. Ils permettent de réduire le nombre d'entrées dans la table de routage. Si une adresse n'est pas trouvée dans la table, on utilise alors le routage par défaut. Une autre possibilité est offerte par IP : il est possible de prévoir des chemins spécifiques vers une machine hôte. On garantit ainsi une certaine sécurité de transport en imposant un chemin unique par lequel tous les datagrammes destinés à cet hôte passeront. 1.7.3.3. Algorithme de routage des datagrammesRoute_IP_Datagram(Table de routage, Datagramme)
Nous verrons dans un autre chapître les protocoles de routage utilisé couramment par les gateways.
Le monde UNIX offre donc une famille de protocoles permettant de concevoir des applications tournant un réseau local ou un réseau WAN. Nous avons présenté les protocoles des couches physiques. Pour un réseau local UNIX, on utilise toujours un réseau Ethernet. Ethernet offrent toutes les fonctionnalités des couches 1 et 2 du modèle OSI. Il se base sur une technologie de bus dont l'accès est partagé. La couche 3 est ensuite occupée essentiellement par le protocole IP. Celui-ci fonctionne en mode datagramme. Il est non sécurisé et nécessite donc l'utilisation d'une couche de transport fiable. IP partage la couche 3 avec les protocoles ARP, RARP, ICMP et les protocoles de routage. Nous avons dans ce document présenté ARP et RARP. Ces derniers permettent d'établir une équivalence bijective entre les adresses physiques des machines (ou adresses Ethernet) et leurs adresses Internet (ou adresses IP). Nous examinerons dans les prochains chapitres
2. Le protocole ICMP
Le protocole IP fournit un transfert non sécurisé de transmission des paquets en mode datagramme. Il existe un mécanisme que les gateways et les machines (que nous appelerons désormais les "hosts") utilisent pour échanger des informations de contrôle et/ou d'erreurs pouvant être nécessaires durant le transfert des datagrammes IP. Les gateways utilisent ce mécanisme pour remonter ce que l'on appelle des "delivery problems" et les hosts les emploient pour tester si les destinations peuvent être atteintes. 2.2. ICMP (Internet Control Message Protocol)
Le protocole IP en lui-même ne contient rien pour aider l'émetteur de datagrammes à tester la connexion de bout en bout ou de s'informer de pannes sur des noeuds du réseau. Pour permettre aux machines de l'Internet de remonter des erreurs ou de fournir des informations concernant des anomalies, un mécanisme spécial de comunication par messages a été ajouté à la famille des protocoles IP. Ce protocole est ICMP (Internet Control Message Protocol). Les messages d'ICMP sont encapsulés dans les datagrammes IP tout comme les données des couches protocolaires s'appuyant sur IP (i.e. TCP et UDP). La destination du message n'est par contre pas un host mais la couche logicielle de la machine à laquelle on souhaite envoyer le message IP. Puisque les messages ICMP sont véhiculées dans des datagrammes IP, ils ont le format suivant :
 La seule différence avec les autres données encapsulées dans le datagramme IP réside dans la gestion des erreurs : si ce paquet provoque une erreur IP lors de son cheminement sur le réseau, il n'y a pas création d'une trame d'erreur pour le signaler. Il n'est en effet pas intéressant de créer une trame d'erreur concernant un message d'erreur ! Tous les messages ICMP ont un format particulier permettant de reconnaître - dès lecture des premiers octets qui les composent - le type de message. Ainsi la structure du datagramme est découpée comme suit :
 Il existe plusieurs types de messages que nous allons examiner dans ce document :
Le champ CODE fournit des informations complémentaires sur le type de message. Enfin, le CheckSum, calculé selon le même algorithme qu'IP, représente le CRC des données ICMP (il n'inclut pas lors de sa détermination les octets de l'entête IP). 2.3. Les différents messages d'ICMP
Ce test correspond à l'émission d'un message ICMP du type "Echo Request". Ce message entraîne le renvoi d'un message ICMP du type "Echo Reply". Le message "Echo Request" est émis par un host pour vérifier si le host qu'il souhaite atteindre est présent sur le réseau et est capable de répondre aux messages ICMP. Si tel est le cas, on vérifie par ce mécanisme que la machine distante est bien connectée sur le réseau mais on vérifie également que sa couche protocolaire IP répond correctement. Le message ICMP correspondant à l'Echo Request a cette structure :
 Le champ "CODE" prend toujours la valeur 0 quand il s'agit d'un message ECHO. Les champs "Identifiant ICMP" et "Numéro de séquence ICMP" sont deux numéros établis par les machines afin de reconnaître les trames ICMP entre elles (il est en effet possible d'envoyer plusieurs requêtes d'écho - il est par conséquent nécessaire de les numéroter pour l'émetteur et le récepteur). Un champ optionnel est réservé pour l'écriture d'un message. Ce message doit être retourné sans aucune modification par la machine dont on teste la connexion IP. Ce champ est donc une sécurité supplémentaire. Le Checksum des messages ICMP d'écho tiennent bien sûr compte de ces données optionnelles. La structure du message "Echo Reply" est la même ; seule la valeur du champ TYPE est modifiée :
 2.3.2. Réponse d'une destination injoignable
Le message ICMP "Destination Unreachable" est envoyé par une gateway qui ne peut pas expédier correctement un datagramme IP vers un host. Ce message est bien évidemment envoyé à l'émetteur du datagramme. La structure d'un tel message est la suivante :
 Dans le cas présent, le code peut prendre plusieurs valeurs (car l'on peut déterminer de manière présente la cause de ce rejet de trame) :
Nous constatons qu'il est possible à ICMP de signaler des erreurs induites par les couches protocolaires s'appuyant sur IP ("Protocol Unreachable" pourrait signifier que le protocole TCP de la machine distante ne répond pas). Il en est de même pour les protocoles s'appuyant sur TCP et UDP. Ces derniers sont définis sur des ports spécifiques de la machine. Là encore, ICMP peut indiquer à l'émetteur que le port 21 du FTP distant ne répond pas correctement. La trame ICMP contient en plus du statut d'erreur l'entête IP de la trame ayant déclanché ce message ainsi que les 64 premiers bits du datagramme. Ces informations permettent à l'émetteur de retrouver quel datagramme il ne peut pas envoyer ou éventuellement quel datagramme il doit ré-émettre. 2.3.3. Contrôle de flux des datagrammes IP
Si un host (ou une gateway) reçoit les datagrammes trop vite (et que par conséquent il en perd !) il émet un message ICMP "Source Quench" pour que l'émetteur résuide le débit d'émission des trames IP. N.B. : Un message de ce type est émis pour toutes les trames engorgées : elles seront donc toutes ré-émises correctement. Algorithme de ré-émission des datagrammes IP : la machine qui reçoit l'ordre de réduire le débit de transmission des datagrammes IP diminue progressivement ce rythme de transfert jusqu'à ce qu'il ne reçoive plus aucun message "Source Quench" de la part du récepteur.
Un message "Source Quench" se décompose comme suit :
 Comme nous l'avons expliqué, on retourne un message "Source Quench" pour chaque datagramme engorgé. Par conséquent, le moyen de l'authentifier auprès de l'émetteur consiste à retourner l'entête IP du datagramme. 2.3.4. Requêtes de reroutage émis par une gateway
Les tables de routage sont en général statiques. Les machines les chargent en mémoire à partir d'un fichier disque (/etc/hosts) lors de leur démarrage. Ce routage peut pourtant évolué dans la journée (arrivée d'une nouvelle machine sur le réseau, panne d'une gateway...). Les gateways échangent régulièrement leurs tables de routage pour rester à jour. Si une gateway constate qu'un host n'est pas à jour (i.e. qu'il n'utilise plus un plan de routage correct), elle envoie un message "Redirect" vers le host concerné. Une restriction réside dans ce mécanisme : une gateway ne peut informer que les hosts situés sur le même réseau qu'elle. Un protocole de couche supérieur est nécessaire pour diffuser des informations de routage sur plusieurs réseaux. Un message "Redirect" se présente comme suit :
 Le message contient donc l'adresse Internet de la gateway par laquelle l'émetteur devra désormais passer. Afin qu'il reconnaisse le datagramme qu'il doit ré-expédier, l'entête IP de ce datagramme ainsi que les 64 premiers octets qui le composait lui sont retournés. Le champ code peut prendre plusieurs valeurs car il est possible que le nouveau plan de routage concerne un réseau, une machine ou même un service :
2.3.5. Détection de bouclage ou de cheminement trop long
Ce message est basé sur la notion de TTL (Time To Live) du protocole IP. Lorsqu'un datagramme IP est construit, un temps de vie lui est accordé sur le réseau. Ce temps est le champ TTL du datagramme IP. Chaque gateway décrémente le TTL au passage d'un datagramme IP jusqu'à ce que ce datagramme atteigne soit sa destination (et dans ce cas tout va pour le mieux dans le meilleur des Unix) soit la valeur 0 et c'est alors que les ennuis commencent pour lui ! La famille de protocoles IP considère qu'un paquet dont le temps de transit est dépassé ne doit pas rester sur le réseau. Un message annonçant sa destriction est retourné à l'émetteur. Ce message est du type "Time Exceeded". Les messages ICMP "Time Exceeded" se construisent de la manière suivante :
 Le champ code peut prendre deux valeurs :
2.3.6. Retour d'une entête incorrecte
Il est possible que l'entête d'une trame IP soit incorrect (un code d'option est faux par exemple). Dans ce cas, la machine réceptrice retourne un message ICMP à l'émetteur de cette trame érronée. La structure du message ICMP "Parameter Problem" est la suivante :
 Le champ pointeur indique la position de l'octet erroné. Le début du datagramme est retourné pour que l'émetteur ré-émette correctement son datagramme IP. 2.3.7. Synchronisation d'horloge et estimation du temps de transit
Le message "Timestamp Request" permet de demander à un host son heure et sa date système (attention, les machines Unix se basent sur un horaire universel). Tout message "Timestamp Request" correspond à un message réponse "Timestamp Reply". La structure d'un message "Timestamp Request" est la suivante :
 Les champs "Identifiant ICMP" et "Numéro de séquence ICMP" permettent à l'émetteur de reconnaître le message ICMP. Chaque temps donné par les machines sont définis en millisecondes à partir de minuit (respect de l'heure universelle). Le premier temps est écrit par l'émetteur au moment où il émet ce message. Le deuxième temps est fourni par le récepteur au moment où il a reçu le message. Enfin le troisième temps est inscrit par le récepteur au moment où il retourne le message à l'expéditeur. Ainsi donc, l'émetteur du message est capable de déterminer :
Les hosts peuvent déduire de ces valeurs les temps estimés de transmission de leurs données et par conséquent
La structure d'un message "Timestamp Reply" est identique : seul le champ TYPE change de valeur :
 2.3.8. Demande d'une adresse réseau
Cette demande est une alternative aux requêtes RARP (Reverse Address Resolution Protocol). Un message "Information Request" permet de demander au réseau l'adresse IP dont il a besoin. Dans l'entête IP de ce message, il met donc à 0 l'adresse IP de destination et construit un message ICMP comme suit :
 La valeur 15 du champ TYPE correspond à un message "Information Request". En réponse à ce message est construit un nouveau message ICMP "Information Reply" dont le champ TYPE prend la valeur 16. L'adresse IP recherchée est écrite dans le dernier champ de ce message :
 2.3.9. Demande d'un masque de sous-réseau
Ce type de message est similaire à la demande d'une adresse réseau. Nous n'expliquerons donc pas son fonctionnement. Le message émis par le demandeur est du type "Address Mask Request" et se présente comme suit :
 En réponse à ce message est retourné un message "Address Mask Response" défini ainsi :
Nous avons donc constaté que le protocole ICMP permettait de véhiculer des messages informatifs ou bien des messages d'interrogation. Il faut bien garder à l'esprit qu'ICMP est un complément indispensable au protocole IP qui ne propose pas de mécanisme d'émission/réception de messages. ICMP est toujours fourni avec les protocoles de la famille IP car il est indispensable : il est utilisé par d'autres protocoles des couches supérieures pour gérer au mieux les échanges de données via TCP/IP.
3. Les protocoles de routage
Nous avons constaté que le monde UNIX était très hétérogène ; beaucoup de machines d'architecture différente utilisent l'Internet. Ce réseau modial étant très fortement maillé, il est nécessaire d'établir des mécanismes de routage des paquets de données. Nous avons appris qu'IP était capable d'envoyer directement des données sur un réseau local. Il n'est par contre pas prévu pour router des datagrammes sur un réseau mondial. On se base alors sur des machines ayant une connaissance partielle du réseau WAN. Cette connaissance partielle est suffisante pour diriger les flux de données vers la bonne destination. Ainsi, les données passent par ces machines jusqu'à atteindre leur destination finale. Ces machines sont appelées des passerelles ou gateways. Les gateways hébergent donc des protocoles leur permettant d'établir les plans de route des datagrammes IP qu'elles reçoivent. Il faut pour comprendre leur fonctionnement imaginer un gigantesque carrefour possédant un grand nombre de branches. La passerelle reçoit un datagramme par l'une de ces branches, recherche la branche qui convient le mieux au trajet qu'il doit suivre, enfin l'oriente et l'envoie dans la bonne direction. Les gateways se basent sur une table de routage pour établir les plans de route. Ainsi donc, une table de routage est composée de couples (N, G) N désignant une adresse de réseau et G l'adresse de la gateway par laquelle il faut passer pour atteindre ce réseau. Une table de routage contient également les définitions des routages directs. Il est possible également de définir des routages par défaut. Ils permettent de réduire le nombre d'entrées dans la table de routage. Si une adresse n'est pas trouvée dans la table, on utilise alors le routage par défaut. Une autre possibilité est offerte par IP : il est possible de prévoir des chemins spécifiques vers une machine hôte. On garantit ainsi une certaine sécurité de transport en imposant un chemin unique par lequel tous les datagrammes destinés à cet hôte passeront. Chaque gateway doit se poser deux questions :
Pour une machine UNIX, la première question possède une réponse simple : le réseau local de la gateway (ou même sur la machine qui sert de gateway), il existe une table de configuration statique dans le répertoire /etc. Cette table est issue de trois fichiers système :
Deux daemons différents gèrent ensuite le problème du routage statique et du routage dynamique. Nous verrons lors de la présentation concrète sur machine UNIX les daemons "routed" et "gated". Il existe de par le monde deux types de gateways :
Nous allons donc décrire tous les mécanismes internes à ces machines ainsi que les protocoles qui en permettent le fonctionnement. 3.2. GGP (Gateway to Gateway Protocol)
Ce protocole a été créé à l'origine pour les Core Gateways de l'Internet afin d'échanger des informations de routage entre ces entités. Les messages du protocole GGP sont encapsulés dans des datagrammes IP. GGP gère l'ajout d'une Core Gateway dans le réseau. Quand une gateway de ce type est ajoutée, on lui définit un ensemble de voisins proches avec lesquels elle peut communiquer. Ces voisins se chargeront de diffuser l'arrivée de la nouvelle passerelle. Les gateways échangent en fait des couples (N,D) où N représente l'adresse d'un réseau et D la distance nécessaire pour l'atteindre. Attention toutefois : il ne s'agit pas d'une distance en kilomètres mais d'une distance en nombre de gateways à passer. On dit que D = 0 quand une gateway peut atteindre directement un réseau ou une machine. Il est donc possible - pour chaque passerelle - d'optimiser le chemin de routage d'un datagramme. Dans ce cas, la passerelle modifie sa table de routage en fonction de cette information. Il existe quatre types de messages GGP qui ont chacun un format particulier. Les huit premiers bits d'un message GGP permettent de déterminer le type du message émis. 3.2.1. Message de mise à jour d'un routage
Un message de mise à jour d'un routage se compose des champs suivants :
 Le champ Type prend la valeur 12 pour spécifier qu'il s'agit d'une mise à jour de configuration de routage. Le numéro de séquence permet à GGP d'utiliser des aquittements dès réception des messages de mise à jour. Le champ "Mise à jour" permet de différencier le sens de la demande :
Enfin le champ "Nb Distance" indique le nombre de distances Dx dont on remet à jour le routage. Il est donc possible comme le montre l'exemple de remettre à jour en même temps les routages D1 et D2.
Quand une gateway a reçu un message de mise à jour de routage, elle retourne un message d'aquittement dont la structure est très simple :
 Le type vaut toujours 2 pour l'aquittement d'un message. A l'inverse, il vaut 10 si le message a mal été transmis. Dans les deux cas, le numéro de message désigne le numéro du dernier message correctement reçu.
Il est possible qu'une gateway souhaite vérifier la présence d'une autre gateway (par exemple si celle-ci ne répond pas ou si elle ne route plus de datagrammes IP). Dans ce cas, on émet un message "Echo Request" auquel la machine interrogée devra répondre par un message "Echo Reply" :
 Le type de message prend la valeur 8 pour un message "Echo Request" et la valeur 0 pour un message "Echo Reply".
Le dernier type de message permet à une gateway de tester ses couches locales d'interface réseau. Elle teste ainsi si sa connexion au réseau est correcte et que par conséquent si une autre gateway peut la joindre. Le message se présente comme suit :
 Le type du message est égal à 9. Inconvénients de GGP : Ce protocole nécessite une mise à jour général des routes. Ainsi, il est possible d'engorger le trafic si les gateways se remettent régulièrement à jour les unes les autres. De plus, les informations de mise à jour occupent beaucoup d'octets car l'on définit tout le trajet (Dx) pour atteindre un point du réseau. Par conséquent, les messages de mise à jour par GGP peuvent saturer rapidement un réseau. Le dernier inconvénient de GGP est qu'il n'est autorisé que sur les Core Gateways : une passerelle quelconque peut interroger ces Core Gateways mais ne peut pas les mettre à jour. L'ensemble de ces inconvénients obligent à recourir à d'autres protocoles. 3.3. EGP (Exterior Gateway Protocol)
Un protocole complémentaire à GGP est nécessaire pour pallier deux problèmes :
Il est important de noter qu'Internet considère qu'un réseau d'entreprise ayant un ensemble complexe de réseaux et de gateways forme une unique entité et est administrativement considérée comme un système autonome. Ce système autonome possède son propre protocole de routage (ce n'est pas forcément EGP !). Ce système a donc pour responsabilité de
Nous verrons donc qu'il est possible d'utiliser des protocoles tels que RIP pour collecter ces informations. Le choix du protocole de routage au sein même d'un site ne concerne que les administrateurs de ce site. Dans tous les cas, il est nécessaire d'utiliser EGP entre deux systèmes autonomes pour échanger les informations de routage. EGP est de plus le seul protocole permettant de dialoguer avec les core gateways. 3.3.1. Entête des messages EGP
Les 9 messages d'EGP présentent la même entête :
 Le premier champ indique le numéro de version d'EGP employé. La dernière version d'EGP est la version 3. Le champ type du message peut donc prendre neuf valeurs différentes. Celles-ci sont présentées dans le tableau ci-dessous :
Le champ Code vient en complément du champ type car il existe des variantes de ces messages. Pour certains messages, il est également nécessaire de transporter une valeur de status. EGP utilise le même algorithme qu'IP pour calculer le CRC de son message. Celui-ci est codé sur 16 bits. Le champ "Numéro de système autonome" désigne le site. Enfin, le numéro de séquence représente le numéro du message EGP pour ce site. 3.3.2. Demande de relation de voisinage
Pour que deux gateways échangent des informations de routage par EGP, il faut qu'elles se soient chacune accorder le droit de le faire. Pour cela, on utilise les messages "Acquisition Request" dont la structure est la suivante :
 Le champ "code" peut prendre cinq valeurs différentes :
D'autre part, lors de la demande de collaboration des deux gateways, chacune d'elles transmet une valeur d'intervalle pour
3.3.3. Message de vérification de fonctionnement (Hello
Ce type de message permet de tester si une gateway est toujours connectée et qu'elle assure le routage. Pour cela, un message de question/réponse permet de vérifier, à intervalle régulier, s'il n'y a pas de rupture de service. Un message "Hello Request" se présente comme suit :
 Le champ "code" peut prendre deux valeurs différentes :
3.3.4. Demande de mise à jour du routage
Contrairement au protocole GGP, EGP n'émet qu'une partie du plan de routage des réseaux. Ce protocole demande donc dans les messages de demande de mise à jour, les modifications de routage concernant telle adresse Internet. Les messages "Poll Request" se présentent donc ainsi :
 Le champ "Adresse Internet demandée" comprend donc l'adresse d'un réseau auquel les deux gateways ont la possibilité d'accéder (d'après le respect des droits de voisinage). 3.3.5. Message de mise à jour d'un routage
A la demande de mise à jour d'un routage est retourné un message "Routing Update". Il est important de noter qu'EGP permet aux non-core gateways d'avertir uniquement les systèmes anonymes dont elles ont un entier accès.
Un message de mise à jour est très complexe :
 3.4. Les protocoles privés : RIP, HELLO et GATED
Les protocoles RIP et HELLO doivent donc être propres à un site. Ils ne peuvent pas remplacer le protocole EGP. Pour ces deux protocoles, on parle de voisinage interne (en opposition avec le voisinage externe d'EGP). Une gateway peut donc être amenée à utiliser deux protocoles de routage en même temps : elle utilise d'une part EGP pour communiquer à l'externe du système qu'elle gère ; d'autre part, elle emploie indifféremment RIP ou HELLO pour son routage interne. Nous verrons que GATED est multi-protocoles. 3.4.1. RIP (Routing Information Protocol)
3.4.1.1. Présentation du protocoleRIP est le protocole le plus utilisé. RIP utilise des messages Broadcast pour diffuser les informations de routage et les mettre à jour partout en même temps. "Routed" est le nom de baptème de ce protocole (créé par Rank Xerox). Il prit le nom de RIP lorsque son utilisation fut étendu à des machines d'autres constructeurs. RIP n'est pas un protocole très performant. Cependant, parce qu'il a été fourni en standard avec le système UNIX BSD 3.XX, il s'est imposé comme un standard de fait. Le principe de fonctionnement de RIP est simple : les gateways émettent régulièrement par broadcast la mise à jour de leur routage. Les destinataires sont là encore des voisins au sens EGP du terme. Contrairement à EGP, le décompte des distances est calculé par rapport à la table de routage courante de la machine (la mesure est donc un delta et non plus un indice absolu). Trois problèmes ne sont pas traités par le protocole : RIP ne vérifie pas le bouclage des routages. On considère alors que les administrateurs vérifient la cohérence de leur routage. Si une distance est infinie (attention, il s'agit d'un delta), la valeur du champ distance vaut 15. Le problème est donc simple : s'il est nécessaire de passer par 15 gateways supplémentaires pour atteindre une machine, le protocole assimile ce chemin à un parcours infini et considère donc la machine comme injoignable. La mise à jour du routage d'un réseau est lente car chaque gateway peut atteindre 14 gateways voisines (au delà, on atteind l'infini). Le rayon d'action de chaque passerelle étant restreint de la sorte, couvrir l'ensemble du réseau implique l'émission de nombreux messages à partir de toutes les gateways. 3.4.1.2. Structure des messages RIPIl existe deux types de messages RIP :
Bien sûr, les messages broadcast sont les plus importants. Nous n'examinons que ces derniers. Ces messages comprennent une entête fixe suivie d'une liste des routes :
 Le champ "Commande" prend la valeur 1 lorsque le message est une demande de mise à jour et la valeur 2 lorsqu'il s'agit d'une mise à jour. Toutefois, les gateways émettent régulièrement des messages de mise à jour sans avoir été sollicitée par un message d'interrogation. RIP présente un avantage très intéressant par rapport aux autres protocoles de routage : il peut gérer différents types de réseau (pas uniquement Internet donc). En effet, le champ "Famille du réseau n" permet de spécifier le type de réseau. Il est par conséquent possible de transmettre des informations de routage de réseaux hétérogènes. Pour ce faire, les adresses de réseau sont codées sur 14 octets comme le montre le message ci-dessus. Internet n'en utilise que 4 ; les autres octets sont donc mis à zéro.
3.4.2.1. Présentation du protocoleLe protocole HELLO diverge d'EGP et de RIP pour une unique raison : les distances entre deux points du réseau ne sont pas calculées en fonction du nombre de gateways qu'il est nécessaire de traverser mais en fonction du temps de trajet. HELLO est utilisé sur le backbone NFSNet d'Internet ce qui lui donne un certain poids. Par conséquent, ce protocole ne doit pas être trop vite oublié. HELLO offre deux fonctionnalités :
Par conséquent, les messages du protocole HELLO contiennent des informations de routage et des données temporelles (des timestamps dans le jargon UNIX). Avant de transmettre un message, une machine ajoute son "timestamp" dans le message HELLO. La technique est simple : puisque les passerelles sont synchronisées, poser un "timestamp" consiste à inscrire dans le message l'heure courante. L'algorithme de calcul des routes les plus rapides est celui du protocole EGP. La seule différence entre les deux calculs résident dans les unités employées : EGP travaille en nombre de passerelles alors qu'HELLO travaille en nombre de secondes. 3.4.2.2. Structure des messages HELLOUn message HELLO se décompose suivant les champs suivants :
 Le champ "Date" contient la date d'émission du message (c'est-à-dire la date système de la première machine). De la même manière, le champ "Heure" représente l'heure système de la première passerelle. Le champ "Timestamp" est constitué lors de l'envoi du message et est utilisé pour le calcul des temps de transport. Le champ "Nb machines" est augmenté par chaque passerelle dès réception du message. Elle permet de connaître le nombre de couples (DTi - Offseti) contenus dans le message. La passerelle j qui reçoit ce message écrit la valeur j dans ce message et écrit ces données dans la zone j. Chaque temps DTi représente le temps nécessaire pour joindre une autre passerelle. Son calcul est simple : dès réception du message, la passerelle déterminet la différence entre sa date et son heure système avec celles de la machine émettrice. Suivant son heure courante, elle peut en déduire le temps qui s'est écoulé durant le transport du message. Afin que chaque passerelle puisse réaliser ce calcul, la passerelle écrit dans le champ Offset la différence de temps existant entre son heure système et celle de la machine émettrice.
GATED est plus exactement un programme UNIX. Il combine les protocoles RIP, HELLO et EGP pour offrir une seule interface logicielle de gestion de routage. Gated gère des messages de type RIP et HELLO et modifie les tables de routage locales comme le fait le programme ROUTED. Pour avertir le réseau externe d'une modification de son routage, GATED utilise le protocole EGP ; à l'inverse, s'il souhaite mettre à jour des données de routage en interne, il utilise soit HELLO soit RIP.
Le routage des datagrammes IP est essentiel dans le monde de l'Internet. Sur un réseau local, les protocoles ARP et IP suffisent pour transmettre des données entre deux machines. Sur un réseau WAN hétérogènes, on utilise des passerelles qui se chargent de transporter "intelligemment" les données vers leur destination finale. Il existe dans le monde deux types de passerelles : les core gateways et les noncore gateways. Les core gateways sont des machines officiellement administrées par l'INOC alors que les noncore gateways n'ont pas de caractéristisques particulières. Plusieurs protocoles permettent le transport des datagrammes à travers ces passerelles. GGP est le seul protocole utilisé par les core gateways. Entre deux sites différents (ou deux réseaux privés différents), les gateways utilisent le protocole EGP. A l'interne d'un réseau privé, on utilise souvent le protocole RIP mais il existe à cet usage (HELLO est le plus connu après RIP).
4. Le protocole TCP
Le protocole IP fournit un transfert non sécurisé de transmission des paquets en mode datagramme. Ce protocole assure la fonction de la couche 3 du modèle OSI. La couche transport (couche 4 selon la représentation OSI) comprend - dans le monde UNIX - trois protocoles essentiellement : UDP, TCP et VMTP. UDP et TCP sont les plus utilisés. Le protocole TCP est plus complexe que le protocole UDP mais il offre un transport sécurisé des données ainsi qu'un certain nombre de contrôle comme nous allons le voir. 4.2. TCP (Transport Control Protocol)
Le protocole TCP peut fonctionner sur d'autres couches 3 que la couche IP (contrairement au protocole UDP). TCP offre une couche simple et harmonieuse pour interfacer une application et la couche IP. L'interface entre les applications et la couche TCP (que l'on nomme en anglais "The Internet Stream Delivery Service") présente cinq caractéristiques essentielles : 4.2.1. Fonctionnement par flux (stream orientation)
Deux applications échangeant de gros volumes de données s'échangent en fait des flux de bits. TCP est le service protocolaire permettant une transmission sécurisée de ces flux. 4.2.2. Connexion par circuit virtuel
Quatre étapes ponctuent le fonctionnement d'une connexion par TCP : Avant le transfert des données, émetteur et récepteur échangent des données nécessaires à leur couche protocolaire. On utilise la notion de "Call Accept" (comme par le protocole X25). Les couches protocolaires échangent des messages pour vérifier que le transfert est possible et autorisé. Une fois les vérifications faites, la couche transport informe l'application qu'elle peut utiliser la connexion qui vient d'être établie. La couche applicative voit donc la connexion comme un tuyau bi-directionnel dans lequel les données (structurées ou non) vont être véhiculées. Durant le transfert, les couches transport poursuivent leur dialogue indépendamment des dialogues des couches applicatives (ou plus exactement de manière transparente pour ces couches 7 du modèle OSI). Ce dialogue a pour but de
L'application émet et reçoit les données au rythme et suivant les volumes qu'elle souhaite. La couche transport découpe de manière transparente ces buffers pour les passer à la couche IP. Ce découpage entraîne la création de paquets. TCP optimise ce découpage afin de garantir le meilleur débit possible. Pour ce faire, il lui est possible de temporiser l'émission de données en attendant le remplissage complet d'un paquet à transmettre à la couche IP. Il est possible pour certaines applications d'utiliser une méthode "push" pour envoyer les données au rythme de l'application : on peut par exemple envoyer les données octet par octet. Le contrôle de flux offert par TCP est alors inintéressant.
La couche TCP n'impose pas une structure particulière aux données véhiculées : il considère les données applicatives comme des boîtes noires. Cette technique donne une certaine souplesse d'utilisation. 4.2.5. Connexion bi-directionnelle (ou mode full duplex)
Les transferts peuvent s'effectuer simultanément dans les deux sens. Il n'y a pas de contrainte spécifique. 4.3. Transport sécurisé par TCP
TCP se base sur des ACKnowledges "positifs" avec retransmission possible des paquets invalidés. Cette solution implique la possibilité de transmettre des messages d'aquittement. L'émetteur conserve un enregistrement des paquets émis et attend un ACKnowledge pour émettre le paquet suivant :
 Il arme également un timer et retransmet le paquet si ce timer est expiré (i.e. s'il est revenu à zéro). Inconvénient de cette méthode : l'émission se déroule paquet par paquet. TCP introduit donc la notion de fenêtre glissante : l'émetteur peut envoyer plusieurs paquets avant réception d'un aquittement (cf schéma ci-dessous).
Comme le protocole UDP, TCP peut s'encapsuler dans les datagrammes IP :
 Nous allons détailler plusieurs caractéristiques essentielles propres au protocole TCP. 4.4.1. Taille de fenêtre variable et contrôle de flux
Le protocole TCP autorise la modification de la taille de la fenêtre d'aquittement des paquets. TCP utilise une technique de fenêtre glissante dont la taille pourrait être quelconque. En voici un exemple :
 Ce déplacement de fenêtre a été autorisé grâce à l'émission dun paquet ACK. Dans ce paquet TCP, on retourne le nombre d'octets ayant été reçus ainsi que le nombre d'octets supplémentaires que la machine réceptrice est capable d'accepter. Par exemple, si 400 octets ont été reçus correctement et que la machine réceptrice pourrait en recevoir 800 selon le même débit, elle avertit l'émetteur qu'elle peut accepter 400 octets supplémentaires. Ainsi donc, l'émetteur modifiera la fenêtre d'aquittement en conséquence. De la même manière, si la machine réceptrice reçoit des buffers trop gros, elle utilise ce mécanisme pour que l'émetteur réduise la fenêtre d'aquittement. Si les buffers de réception sont pleins, le récepteur peut mettre la taille de sa fenêtre de réception à zéro. Dans ce cas, l'émetteur arrête le trafic TCP jusqu'à ce que le récepteur autorise de nouveau le dialogue. Aucune donnée n'est donc perdue par engorgement. Cette technique permet donc
Un problème de contrôle de flux n'est toutefois pas résolu par cette solution. En effet, les paquets TCP peuvent être amenés à passer par des gateways. Ces dernières ont un débit qui peut être différent de celui de la machine destinatrice : le contrôle de flux ne concerne pas uniquement les machines émettrice et réceptrice). Pour palier ce problème, TCP s'interface avec le protocole ICMP et gère les paquets de type "source quench" définis par ce protocole. 4.4.2. Structure des paquets TCP
Dans le langage UNIX, les paquets TCP sont appelés des segments. Il existe plusieurs types de segments :
Remarque : il est important de noter qu'un aquittement peut être transporté dans un segment de données (ce qui réduit le nombre de segments transmis). La structure d'une trame TCP est la suivante :
 Tout comme le protocole UDP, TCP utilise des numéros de ports pour différencier les connexions dont il a la charge. Les champs "Port Origine" et "Port Destination" désignent donc deux entiers correspondant aux ports sur lesquels les applications émettrice et réceptrice tournent. Le numéro de séquence désigne le numéro de segments de données de l'émetteur. Le numéro d'aquittement représente le dernier segment reçu par le récepteur (nous verrons plus loin qu'il s'agit en fait d'un offset). Le champ "offset" représente l'offset des données dans le segment. Ce champ est obligatoire car le champ options est de taille variable. Le champ "res" est réservé par le protocole mais non utilisé de nos jours. Le champ "code" permet de différencier les types de segments TCP. Il se découpe en bits. Chaque bit prend la valeur 0 ou 1 pour invalider/confirmer l'utilisation des autres champs du segment. Le champ "code" se lit donc de la manière suivante :
Lorsque le bit URG est positionné à la valeur 1, le segment TCP contient des valeurs urgentes. Il est possible que celles-ci soient véhiculées avec d'autres données qui ne le sont pas. Dans ce cas, les données urgentes sont toujours placées au début de la zone de données dans le segment TCP. Le champ "Pointeur d'urgence" représente la position - dans la zone de données - à laquelle les données urgentes se terminent. A partir de cette position et ce jusqu'à la fin du segment, les données sont standard. Le champ "Fenêtre" spécifie le nombre d'octets que le récepteur souhaite recevoir (cf §4.4.1). Le champ "Option" peut par exemple désigner une taille maximale de segment TCP. Cela peut être utile pour des machines qui ont de petits buffers.
Le champ CRC contient sur 16 bits le résultat du calcul de checksum des paquets TCP. TCP se base sur le même calcul que le protocole UDP : UDP utilise le même algorithme qu'IP pour calculer ce checksum. Le calcul du CRC utilise un pseudo-header c'est-à-dire un deuxième ensemble de champs. Le pseudo-header et l'ensemble (entête TCP - Zone de données TCP) interviennent donc dans le calcul du CRC. La structure du pseudo-header est la suivante :
 4.4.4. Aquittements et retransmission
Puisque TCP émet des segments de données de longueur variable, les aquittements sont des offsets et non pas des numéros de segments. Chaque aquittement représente le numéro du dernier octet reçu depuis le début du transfert auquel on ajoute 1. Par exemple, si le récepteur a reçu 34568 octets depuis le début des échanges, l'aquittement prendra alors la valeur 34569. Ainsi, on pourra retenir la règle suivante : "les aquittements désignent le numéro du prochain octet que la machine destination souhaite recevoir". On parle dans ce cas d'aquittements cumulatifs : chaque aquittement dépend de l'historique du transfert. Avantages :
Inconvénient :
4.4.5. Timeout et retransmission
Chaque fois qu'un segment TCP est envoyé, un timer est armé par l'émetteur et TCP attend un aquittement. Si le timer passe à zéro alors que cet aquittement n'est pas reçu, TCP considère AUTOMATIQUEMENT que le segment a été perdu ; il le retransmet donc. Comme les segments TCP passent par des gateways et des machines dont les performances sont variées, TCP doit adapter les timers suivant la topologie du réseau physique par lequel les données circulent. Pour ce faire, il utilise un algorithme adaptatif. Il enregistre les temps auxquels les paquets sont émis et les temps auxquels il a reçu les aquittements leur correspondant. TCP en déduit alors un temps moyen d'émission. Ce temps est perpétuellement réajusté en fonction du trafic. 4.4.6. Gestion de l'engorgement
Si un engorgement se produit sur un point du réseau, les délais de transmission augmentent. Les gateways ou les machines hôtes qui sont engorgées émettent des messages ICMP pour avertir les machines émettrices que des segments vont être perdus. Ces messages sont remontés par la couche IP jusqu'au protocole TCP qui automatiquement identifie les données perdues. Si toutefois ICMP n'émettait pas ces messages d'avertissement, TCP constaterait un problème de transmission à l'aide du temps moyen d'émission : celui-ci augmenterait sans cesse. Toutefois, cette solution ne permet pas de diagnostiquer la raison de cet accroissement. L'interfaçage avec le protocole ICMP est donc préférable. 4.4.7. Etablissement d'une connexion par TCP
Trois segments TCP suffisent à établir une connexion comme le montre le synoptique suivant :
TCP place le bit FIN à 1 pour signaler la fin d'un transfert. Attention toutefois : cette fin de transfert peut n'être valable que pour une direction donnée. En effet, puisque TCP fonctionne en full-duplex, il est possible qu'un transfert se poursuive dans un sens alors que dans l'autre sens la connexion est close.
Si un problème réseau survient, TCP est capable de lancer le reset d'une connexion. Les machines émettrice et réceptrice émettent alors un segment de RESET en plaçant le bit RST du champ CODE à 1.
Le découpage des données par TCP peut être génant pour certaines applications. Aussi, il est possible de forcer l'émission des données en positionnant le bit PSH du champ CODE à 1. Il est de plus possible de demander un envoi urgent de ces données en plaçant à 1 le bit URG du champ CODE : non seulement les données sont émises dès qu'elles sont transmises à la couche TCP mais elles sont envoyées en priorité. 4.4.11. Numéros de ports réservés par des applications standard
Comme UDP, TCP utilise des ports pour les principaux services qu'il gère. Ainsi, on retrouvera dans le fichier /etc/services les applications suivantes : rje 7/tcp ftp-data 20/tcp ftp 21/tcp telnet 23/tcp
TCP est donc un protocole de la couche 4 du modèle OSI. Ses segments ont une entête de 40 octets lui permettant d'assurer différents contrôle de trafic. TCP est donc un protocole sécurisé contrairement au protocole UDP. TCP est utilisé par 90% des applications réseau sous UNIX car il offre une certaine souplesse d'utilisation mais surtout parce qu'il garantie l'émission des données.
5. Protocoles et applications s'appuyant sur TCP et UDP
Nous avons, dans les chapitres précédents, constaté que le monde UNIX basait ses applications réseau sur la famille des protocoles IP. Sur un réseau local, les couches 1 et 2 du modèle OSI sont occupées par le protocole Ethernet. Sur celui-ci on retrouve plusieurs protocoles :
Sur ces deux derniers protocoles reposent d'autres protocoles et applications permettant d'accéder au mieux aux ressources du monde UNIX. Les principaux concernés sont représentés sur le modèle suivant :
 Nous allons dans ce chapitre présenter ces principaux modules ainsi que les commandes UNIX et les fichiers de configuration les concernant. Nous ne parlerons toutefois que brièvement des modules SNMP, DNS et SMTP dont le fonctionnement et la configuration sont très complexes. 5.2. Connexion à une machine distante
Il existe deux commandes de connexion à une machine distante : telnet et rlogin.
Telnet est une application permettant d'établir une connexion sur un terminal distant. Lancer telnet revient à visualiser en local un environnement UNIX que l'on a lancé à distance. Telnet s'appuie sur le protocole TCP pour établir cette connexion entre deux machines. Il peut être utilisé pour se connecter sur une machine du même réseau local ou sur une machine d'un réseau distant. Telnet met donc en jeu deux processus :
Ces processus sont des démons. Ils peuvent être dupliqués n fois grâce au super-démon inetd. Le démon correspondant à telnet est telnetd. Le service telnet est défini sur le port 23. Un contrôle d'accès est nécessaire pour vérifier qu'un système UNIX n'est pas piraté par une connexion telnet non souhaitée. Pour cela, telnet utilise la procédure standard de login. Quand le démon telnetd est activé, l'utilisateur doit entrer son nom et son mot de passe. Une vérification à partir du fichier "/etc/passwd" provoque l'arrêt de la connexion si l'utilisateur ne possède pas de droits d'accès sur cette machine. Il existe deux syntaxes pour lancer la commande telnet :
Dans la première syntaxe, telnet reçoit comme argument un nom symbolique de machine. Le fichier "/etc/hosts" est consulté pour déterminer l'équivalence entre le nom symbolique et l'adresse Internet de la machine. Dans la deuxième syntaxe, on entre directement l'adresse de la machine. Telnet permet de travailler en mode local tout en conservant la connexion distante. Les commandes en mode local doivent être précédées d'un point d'exclamation. Pour passer dans l'application telnet, on utilise le caractère "Escape ]". Une fois ce caractère tapé, l'utilisateur peut solliciter l'aide de telnet en tapant "?" ou lancer d'autres commandes de telnet. Remarque : telnet n'est pas une application spécifique à UNIX (elle existe par exemple dans les environnements DEC). Objets impactés par telnet :
rlogin est un autre outil de connexion à distance. Son principe est similaire à telnet. rlogin fait partie d'une famille de commandes que l'on appelle les "r-commandes", r désignant le terme remote. Toutes les commandes appartenant à cette famille sont lancées à partir d'un poste pour agir sur un autre poste. La commande rlogin n'échappe pas à cette règle : rlogin permet de lancer un login sur une machine distante. rlogin utilise le démon rlogind. Celui-ci est dupliqué par le super-démon inetd. La syntaxe d'appel de rlogin est unique : $rlogin nenuphar [-ec] [-8] [-l nom_utilisateur] où nénuphar est un nom symbolique de machine. Le fichier /etc/hosts est donc consulté pour établir l'adresse Internet de la machine. L'option -l permet de se connecter sous un autre nom que le nom de l'utilisateur courant. Si par exemple vous êtes connecté sous le nom "colas", il est possible de vous connecter à distance sous le nom "lafuma". Dans ce cas, la syntaxe d'appel est : $rlogin nenuphar -llafuma L'option -e permet de spécifier un caractère d'échappement Il doit alors directement suivre ce caractère e. Enfin l'option -8 permet de demander une communication en 8 bits (au lieu de 7 bits par défaut). Tout comme telnet, rlogin impose un certain niveau de sécurité. Deux fichiers systèmes sont employés : ".rhosts" et "/etc/hosts.equiv". Le fichier ".rhosts" est propre à chaque utilisateur. Il est donc placé dans le répertoire de travail de chacun. Ce fichier contient la liste des utilisateurs pouvant se connecter sous le nom de l'utilisateur courant à partir d'une rcommande.
Exemple :
machine1 durand machine2 léopold Chaque ligne de ce fichier contient un couple (machine, utilisateur). Dans notre exemple, l'utilisateur durand peut se connecter à partir de machine1 sur la machine nommée joconde et ce sous le nom d'utilisateur dupont. Dans ce cas, l'utilisateur durand possède les droits d'accès de l'utilisateur dupont. Le fichier "/etc/hosts.equiv" contient la liste des machines qui sont considérées - du point de vue protection - comme équivalente à la machine locale. Exemple : Sur la machine joconde, on trouve le fichier /etc/hosts.equiv suivant : machine1 machine2 La commande rlogin se base donc sur ces fichiers pour vérifier la demande de connexion. Si les définitions ne sont pas faites sur la machine sur laquelle on se connecte, la session n'est pas établie. Remarque : les "r-commandes" ont été développées par BSD. Objets impactés par rlogin :
Il existe quatre applications permettant de lancer un transfert de fichiers entre deux machines : FTP, TFTP, UUCP et rcp.
FTP (File Transfert Protocol) est une application de transfert de fichiers sécurisé. Par conséquent, il s'appuie sur le protocole TCP. FTP se lance en spécifiant comme paramètre le nom de la machine distante : ftp nom_machine Exemple : $ftp nenuphar FTP demande ensuite un nom de login ainsi qu'un mot de passe. Le fichier /etc/passwd est donc consulté pour vérifier les droits de connexion. FTP autorise l'automatisation de la séquence de connexion si le fichier .netrc est constitué. Ce fichier est présent dans les répertoires de travail des utilisateurs (son principe est similaire à celui du fichier .rhosts). Le fichier .netrc possède une syntaxe propre. Il contient trois mots clefs : machine, login et passwd. Exemple de fichier .netrc : machine zebulon login durand passwd fjdls machine nenuphar login dupont passwd gjdf FTP fonctionne en mode full-duplex : il permet le transfert de fichiers dans les deux sens. FTP intègre des commandes permettant par exemple de se déplacer dans les répertoires pour chercher les fichiers voulus. La liste ci-dessous reprend les principales commandes de FTP :
FTP utilise deux ports pour fonctionner. Ces ports sont définis dans le fichier /etc/services. Le port numéro 20 est utilisé par FTP pour effectuer du contrôle de flux et transmettre des messages entre les deux services FTP des machines mises en jeux. Le port numéro 21 est réservé par ftp-data. Ce port est donc dédié aux transferts (bi-directionnels) de données. Le démon ftp est défini dans le fichier /etc/inetd.conf. Ce démon est activé par inetd. Objets impactés par FTP :
TTFP (Trivial FTP) est une version simplifiée (et peu sécurisée) de FTP. Les différences entre FTP et TFTP sont les suivantes :
Une session TFTP est semblable à une session FTP. Elle est lancée par l'activation d'un démon tftpd défini dans les fichiers /etc/services et /etc/inetd.conf. Objets impactés par TFTP :
UUCP (Unix to Unix CoPy) est un logiciel standard permettant à deux sites de communiquer. Il est notamment utilisé par les réseaux de messagerie (Fnet par exemple). UUCP intègre des fonctions de transfert de fichiers, de messagerie et de lancement de commandes à distance. Il est important de noter que UUCP ne fonctionne pas en mode interactif. Ses fichiers de configuration permettent d'automatiser entièrement le fonctionnement de ce logiciel. Enfin, une caractéristique essentielle de UUCP est qu'il fonctionne en mode Client/Serveur. 5.3.3.1. Fonctionnement de UUCPLe déroulement d'opérations par UUCP est comme nous l'avons dit automatique :
Un module UUCP commence toujours par "uu" :
5.3.3.2. Fonctionnement de UUCICODéroulons le fonctionnement de ce programme :
5.3.3.3. Définitions nécessaires à UUCPDéfinitions :
Un ensemble de fichiers de configuration sont placés dans le répertoire /etc/uucp et sont utilisés pour automatiser les tâches du logiciel. Tous appartiennent au groupe d'utilisateurs uucp. Ils ne sont accessibles qu'en lecture pour le groupe uucp (aucun droit pour les autres utilisateurs). Il s'agit des fichiers :
Hormis ces fichiers de configurations, on trouve trois fichiers essentiels qui sont :
5.3.3.4. Répertoires réservés par UUCP/etc/uucp contient tous les fichiers de définition que nous venons de citer. Il comprend également les 4 shells d'administration de UUCP :
/usr/lib/uucp contient tous les programmes de uucp :
/usr/spool/locks contient les fichiers de verrouillage pour éviter des accès simultanés sur les voies de UUCP. Chaque fichier de verrouillage a pour nom LCK..xxx où xxx désigne le nom de la voie. Ces fichiers sont utilisés par uucico :
/usr/spool/uucppublic est le répertoire par défaut des utilisateurs se connectant par UUCP. /usr/spool/uucp contient tous les fichiers temporaires de travail de UUCP. Il contient notamment les files d'attente des travaux pour chaque site. 5.3.3.5. Commandes mises à disposition des utilisateurs
uux demande l'exécution à distance d'une commande. La syntaxe de uux est la suivante : uux [-options] commande
uuto permet de copier des fichiers dans un répertoire spécifique. Les fichiers sont copiés dans une sous-arborescence du répertoire /usr/spool/uucppublic. uupick permet de récupérer des fichiers émis par uuto. uupick intègre donc une procédure de recherche des fichiers reçus. uuname affiche tous les sites accessibles par uucp. uulog affiche l'activité du service uucp du site. uustat affiche l'état de UUCP : requêtes en instance, accessibilités des sites, travaux en exécution pour un site...
rcp (remote copy) est une rcommande. Elle permet de copier un ensemble de fichiers d'une machine à une autre. La syntaxe de cette commande est très simple : $rcp [-p] [-r] source cible
Exemple : $rcp zebulon.colas:/home/siep/users1/.rhosts nenuphar:/home/siep/.rhosts L'option -r permet de copier récursivement les sous-répertoires. L'option -p demande la modification des dates des fichiers copiés sur la machine cible. La commande rcp utilise les fichiers .rhosts et /etc/hosts.equiv pour vérifier les droits de copie. Objets impactés par rcp :
5.4. Commandes à distance : RSH
rsh (remote shell) permet de demander l'exécution d'une commande shell sur une machine distante sans avoir besoin de s'y connecter (par un rlogin). rsh se comporte comme un rlogin.
La syntaxe de rsh est la suivante : rsh machine [-l utilisateur] [-n] commande
Exemple : $rsh zebulon -lcolas -n ls -ail; rsh est lancé par le démond rshd définit dans le fichier /etc/services.
Dans le monde Internet, il est nécessaire de pouvoir véhiculer des messages à travers le monde entier. L'utilitaire permettant ce routage est appelé sendmail. Sendmail récupère des messages déjà constitués pour les transmettre (il n'est donc jamais directement en contact avec les utilisateurs). A partir des adresses qui sont fournis dans les entêtes des messages, sendmail est capable d'assurer la livraison des ces données. Sendmail est en contact avec deux interfaces :
Sendmail prend en compte :
La configuration et le fonctionnement de sendmail est délicate et impose beaucoup de rigueur car il doit permettre d'envoyer et de recevoir des messages du monde entier.
NFS (Network File System) et RFS (Remote File Sharing) permettent le partage des fichiers suivant un mécanisme de fichiers répartis. NFS a été conçu par SUN mais est désormais très largement utilisé (il est même devenu le plus utilisé !). RFS par contre a été écrit par AT&T pour Unix System V. Nous ne présenterons pas dans ce document RFS car il est de nos jours rarement utilisé. 5.6.2. Caractéristiques de NFS
NFS est réalisé au-dessus de deux couches logicielles : les RPC (Remote Procedure Call) et XDR (eXternal Data Representation). La première couche permet de réaliser des appels de procédures à distance et la couche XDR permet à la couche RPC un échange de données entre deux machines hétérogènes (la représentation des caractères pouvant différer d'une technologie hardware à une autre). Ces services sont basés sur des démons que l'on active à distance pour exécuter les requêtes NFS. NFS s'appuie sur UDP et offre les fonctionnalités suivantes :
NFS est structuré de la manière suivante :
 Remarque : toute machine possédant un disque peut être serveur NFS. NFS utilise une méthode simple pour accéder aux fichiers distants : par la commande mount, on déclare un file system de type NFS. On lie par mount les arborescences des machines rendant transparent l'emplacement réel des fichiers. Voici un exemple de partage des fichiers par NFS :
 Remarques :
5.6.3. Configuration du serveur de fichiers
Les parties exportables des machines sont définies dans le fichier /etc/exports. Ce fichier est utilisé par le démon mountd (démon de montage des ressources fichiers). Ce démon est activé par inetd). Remarque : sur les stations SUN, il existe un fichier intermédiaire /etc/xtab qui contient la liste des parties exportables définies par la commande exportfs. Il ajoute le contenu de ce fichier au fichier /etc/exports qui ne contient donc que les ressources à monter localement.
Le fichier /etc/exports contient des lignes ayant la structure
chemin local -options
le champ options permettant de paramétrer l'accès aux ressources (ex : -ro signifie accès en lecture seulement).
La commande showmount permet de consulter le fichier /etc/rmtab dans lequel NFS inscrit toutes les opérations de montage ayant correctement abouti. La syntaxe de cette commande est la suivante :
/usr/etc/showmount [-ade] [hostname]
Les démons nécessaires aux serveurs NFS sont
Ils sont lancés à partir du shell de lancement rc.local. 5.6.4. Configuration du client NFS
Le but d'un client est de déclarer un point de montage distant. Pour ce faire, le client doit également utilisé la commande mount en spécifiant en arguments que le point de montage est sur une machine distante. La syntaxe de la commande mount est
mount [-r] [-ttype] [-ooptions] filesystem directory
Dans le cas d'un montage par NFS, le champ type vaut "NFS". Il existe des options de la commande spécifiques à NFS dont nous citons les principales :
La commande mount consulte le fichier /etc/fstab pour connaître la liste des systèmes de fichiers à monter. Les systèmes de fichiers NFS distants sont donc définis dans ce fichier. NFS utilise un mécanisme de cache fichiers local pour l'accès aux fichiers du serveur. Ce cache est géré par les démons biod (qui sont en quelque sorte les correspondants des démons nfsd). Les démons biod doivent également être lancés au démarrage de la machine après avoir activé le démon portmap.
Le DNS (Domain Name Server) permet de définir une hiérarchie de machines. Il permet à une machine ayant une adresse officielle sur Internet de trouver le numéro Internet d'une autre machine ayant une adresse officielle. DNS pour cela utilise une base de données répartie dans le monde entier. La consultation est libre. Chaque partie de la base de données est laissée à la charge de l'administration (la responsabilité est donc importante). Le DNS utilise un mécanisme similaire au service offert par /etc/hosts. Il offre la possibilité de mise à disposition des informations Internet d'un site pour des sites distants. Il permet aussi de puiser des informations à partir d'autres sites de manière à pouvoir accéder à des machines sans avoir à tenir à jour leur numéro Internet. Un cache est employé par le DNS pour sauvegarder les données reçues des autres DNS (et par conséquent minimiser les échanges d'informations sur le réseau). Le DNS est constitué de deux entités : les serveurs de noms et les méthodes de résolution des noms appelées resolver. Ces méthodes sont implémentées dans la librairie libresolv.a. Il existe plusieurs types de serveurs de noms suivant la responsabilité qui leur est confiée. On parle donc de serveurs primaire, secondaire, cache et forwarder. Les serveurs primaires ont l'autorité d'administration sur une zone et définissent les numéros Internet des machines appartenant à cette zone. Les serveurs secondaires récupèrent les informations des serveurs primaires (ils servent de backup). Les serveurs cache contiennent les données du cache. Enfin, un serveur forwarder permet d'appeler un serveur de niveau supérieur pour connaître les données d'une autre zone. Un forwarder connaît donc plusieurs DNS. DNS est pris en charge par le processus named ou bind (Berkeley Internet Name Domain server). La commande nslookup permet de connaître la configuration d'un serveur de noms.
SNMP (Simple Network Management Protocol) est un protocole d'administration de réseaux basé sur l'interrogation d'agents. Un agent agit sur une entité administrée du réseau. Chaque agent est associé à une MIB (Management Information Base) qui décrit les objets administrés par l'agent ainsi que les variables associées à ces objets. Une norme (SMI : Structure and identification of Management Information for TCP/IP based Internets) a permis la mise en place et le déploiement des MIB. Une station du réseau peut être chargée de récupérer les éléments retournés dans les MIB par les agents SNMP. La commande snmpget permet d'obtenir une information à partir d'une MIB d'un agent. La commande snmpnext permet d'obtenir des informations de la sous-arborescence d'une MIB (car les structures des MIB sont arborescentes). Sur les machines administrables SNMP, il est nécessaire d'avoir un démon snmpd lancé par inetd pour que la collecte des informations soit possible.
Les outils réseaux occupent une place d'autant plus importante dans le monde UNIX qu'Internet nécessite des mécanismes d'interconnexion de réseaux puissants. Nous avons examiné les principales couches de produits et protocoles venant se poser sur les protocoles TCP et UDP mais il est possible de concevoir ces applications en mode réseau à l'aide des bibliothèques C fournies en standard avec le système d'exploitation UNIX.
ANNEXE A : Liste des fichiers de configuration du réseau
ANNEXE A.1. : Fichiers de configuration de chaque utilisateur
ANNEXE A.2. : Fichiers de configuration générale
ANNEXE B : Fichiers de définition des protocoles
Il est possible d'écrire de nouveaux logiciels s'appuyant sur les protocoles TCP, UDP, IP, ICMP et ARP car UNIX met à disposition les fichiers de définition de ces protocoles ainsi que les fonctions C permettant de les manipuler. Ces fichiers de définition sont fournis avec le système d'exploitation.
Remarque : Au-dessus de ces outils bas niveau sont mis à disposition des programmeurs des objets tels que les sockets, les TLI et les RPC permettant de concevoir rapidement et simplement des applications. C'est pourquoi les fonctions d'accès directes aux protocoles sont très rarement utilisées. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Last modified on 10 June 2002 at 14:15:20 CET - webmaster@hsc.fr
Information on this server - © 1989-2010 Hervé Schauer Consultants |
|
![[Course]](/gif/icone.formations.png){kind=small}
![[Tool]](/gif/icone.outils.png){kind=small}
]
![[Course]](/gif/icone.supports.png){kind=small}
]