C-extra.com English Web Page

Index RFC : www.c-extra.com Guide TCP/IP pour réseaux Internet - Description générale Document au format HTML 4.01 Traduction : Valéry G. FREMAUX Origin : Rutgers University Date: November 1995 Revision: November 1996 Compiled by: Vincenzo Mendillo, Associate Professor Department of Communications School of Electrical Engineering Universidad Central de Venezuela Caracas, Venezuela. E-mail: vmendill@conicit.ve Table des matiéres 1. Qu'est ce que TCP/IP ? 2. Description générale des protocoles TCP/IP 2.1. La couche TCP 2.2. La couche IP 2.3. La couche Ethernet 3. Couche applicative et "Sockets réservés" 3.1. Un exemple d'application : SMTP 4. Protocoles autres que TCP : UDP et ICMP 5. Garder la trace des noms : les "Domaines" 6. Routage 7. Détails à propos des adresses Internet : Sous-Réseaux et Diffusion 8. Fragmentation et réassemblage des paquets 10. Où trouver plus d'information 1. Qu'est ce que TCP/IP ? TCP/IP est un ensemble de protocoles permettant à des ordinateurs de partager des ressources à travers un réseau. Il a été développé par un groupe de chercheurs, essentiellement autour du projet ARPAnet. ARPAnet est certainement le plus renommé des réseaux TCP/IP. Cependant, dès Juin 87, 130 différents fournisseurs proposaient déjà des produits TCP/IP, et des milliers de réseaux l'utilisaient. Tout d'abord, quelques définitions de base. Le nom le plus approprié pour cette suite de protocoles est certainement "l'ensemble de protocoles Internet". TCP et IP sont deux protocoles de cet ensemble. (Ils seront décrits ci-dessous.) Comme TCP et IP sont les deux éléments les plus connus de cet ensemble, il est devenu d'usage courant de nommer cette ensemble TCP/IP ou IP/TCP. Il est peut être vain de lutter contre ce fait, bien que cette approximation puisse provoquer certaines confusions. On peut par exemple associer à tort NFS avec TCP/IP, alors qu'il ne se base pas sur le protocole TCP. (Il utilise IP. Mais aussi un autre protocole, UDP, plutôt que TCP. Cette confusion sera vite levée dans les pages qui suivent). Internet est un regroupement de réseaux, incluant ARPAnet (le réseau militaire américain), NSFnet, des réseaux régionaux tels que NYsernet, les réseaux locaux de nombreuses universités et institutions, ainsi que d'autres réseaux militaires. Le terme "Internet" désigne l'ensemble de ces réseaux. Tous ces réseaux sont raccordés les uns aux autres. Les utilisateurs peuvent s'y envoyer des messages de n'importe quel point vers n'importe quel autre, sauf en cas de restrictions d'accès. Officiellement, les documents sur les protocoles Internet ne sont que des standards communs que tous les réseaux ont décidé d'adopter. Bien que le département de la défense américaine étudie une version plus formelle de TCP/IP, la communauté Internet conservera encore longtemps les protocoles adoptés pour la partie civile. TCP/IP est donc une famille de protocoles. Certains implémentent des fonctions de bas niveau utilisées par de nombreuses applications. Ceux-ci sont les protocoles IP, TCP, et UDP. (Nous les décrirons plus avant). D'autres sont des protocoles conçus pour des applications particulières, telles que le transfert de fichiers entre ordinateurs, l'envoi de courrier électronique ou pour trouver qui est "connecté" sur un ordinateur particulier. A l'origine TCP/IP était surtout utilisé entre des micro-ordinateurs ou des centraux. Ces machines avaient toutes leur propre disque dur, et étaient autonomes. Ainsi, les services "traditionnels" assurés par TCP/IP sont : Le transfert de fichiers. Le "file transfer protocol" (FTP) permet à l'utilisateur d'un ordinateur quelconque d'obtenir les fichiers d'un autre ordinateur, ou d'écrire des fichiers vers le même ordinateur. La sécurité est gérée par la présentation d'une demande d'identifiant (User Name) et d'un mot de passe pour pouvoir "voir" l'ordinateur distant. Le protocole prévoit les cas où les ordinateurs sont distincts, les tables de caractères ou les conventions de fin de ligne différentes, etc. Il ne ressemble pas aux nouveaux systèmes d'échange de fichier "network file system" ou "netbios", qui seront décrits plus loin. Au lieu de cela, FTP est un utilitaire qu'il faut exécuter à chaque fois qu'un fichier doit être transmis ou obtenu d'un ordinateur distant. Vous copierez ces fichiers sur votre propre ordinateur. Vous travaillerez alors sur votre copie locale. (Cf RFC 959 pour les spécifications du FTP.) Session distante. Le protocole de terminal distant (TELNET) permet à un utilisateur d'ouvrir une session de travail sur n'importe quel ordinateur du réseau. La session démarre par la spécification de l'ordinateur ou elle doit s'ouvrir. A partir de ce moment, tout ce qui est tapé sur le "terminal" est envoyé au distant. Notez que vous communiquez toujours avec votre propre ordinateur, mais celui-ci devient "transparent" lorsque vous activez l'application Telnet. Chaque caractère tapé es directement envoyé au distant. En général le distant vous demandera toujours une identification, comme si vous l'aviez appelé d'un modem, sous la forme d'un nom d'utilisateur et d'un mot de passe. Lorsque vous vous déconnectez du distant, la session Telnet prend fin, et c'est à votre propre ordinateur que vous continuez à envoyer des caractères. L'implémentation de Telnet sur des micro-ordinateurs prend presque toujours la forme d'une émulation des terminaux les plus connus. (Cf. RFC 854 et 855 pour les spécifications de TELNET.) Courrier électronique. Ce service permet l'envoi de messages d'un ordinateur à l'autre. En général, les utilisateurs travaillent souvent sur une ou deux machines. Ils vont alors maintenir une file de messages sur leur machine. Le système de messagerie électronique est simplement un moyen d'ajouter un message dans cette file à partir d'un autre ordinateur. Ce principe connaît quelques problèmes sur des micro-ordinateurs. La plus sérieuse réserve est que l'utilisation des micro-ordinateurs se prête mal à cette technique. Lorsque vous envoyez un courrier, le logiciel va tenter d'établir une connexion avec l'ordinateur destinataire. Si il s'agit d'un micro-ordinateur, il peut être éteint, ou en train d'exécuter une application exclusive qui empêche l'activation de la réception. Pour cette raison, le service de courrier est en général supporté par un système plus important, multitâche, pouvant laisser en exécution un logiciel de courrier en permanence. Le micro-ordinateur devient alors une interface temporaire, qui viendra récupérer les courriers stockés sur le serveur. (Cf. RFC 821 et 822 pour les spécification du service de courrier. Voir RFC 937 pour les protocoles de récupération de courrier sur les serveurs). Tous ces services feront naturellement partie de l'implémentation de TCP/IP, sauf le courrier électronique sur les micro-ordinateurs par exemple. Ces applications "traditionnelles" jouent toujours un rôle très important dans les réseaux TCP/IP. Cependant, plus récemment, la manière d'utiliser ces réseaux a changé. L'ancienne topologie comprenant des micro-ordinateurs ou mini-ordinateurs autonomes est en train de changer. Les installations actuelles sont plus composites, assemblant des micros, des mini, des stations de travail, des gros centraux. Tous ces ordinateurs se spécialisent actuellement sur des tâches particulières. Comme les utilisateurs restent encore souvent rattachés à une machine, celle-ci devra appeler d'autres unités pour des traitements spécialisés. C'est la base de la nouvelle topologie "serveur/client". Un serveur est un ordinateur assurant un service particulier pour le reste du réseau. Un client est un autre ordinateur utilisant ce service. (Notez que le serveur et le client ne sont pas nécessairement sur des ordinateurs distincts. Il peut s'agir de deux programmes différents exécutés sur la même machine). Voici les types de serveurs les plus couramment trouvés dans des installations actuelles. Notez que tous ces services peuvent s'appuyer sur TCP/IP pour la transmission d'information. Serveurs de fichiers. Il permet la mise à disposition de fichiers pour d'autres ordinateurs d'une façon plus intégrée que le service FTP. Le serveur de fichier donnera l'illusion que ses disques font partie intégrante de l'ordinateur client. Aucun utilitaire ni programme particulier n'est nécessaire pour accéder à ces fichiers. Votre ordinateur croira simplement qu'il dispose de disques supplémentaires. Cette possibilité offre de nombreux avantages. Elle permet de rassembler un grand espace disque sur peu de machines, tout en laissant l'accès à l'espace de stockage aux autres machines. En outre, plusieurs personnes peuvent alors partager des fichiers mis en commun. Ceci permet de faciliter les opérations de maintenance et de sauvegarde, dans la mesure ou le nombre de clones d'un même fichier est largement diminué, diminuant ainsi le nombre de versions différentes et les contraintes de mise à jour. De nombreux constructeurs vendent même des ordinateurs sans aucun disque. Ceux-ci sont justement prévus pour s'appuyer sur des serveurs de fichiers. (Cf. RFC 1001 et 1002 pour la description du NetBIOS PC via TCP. Dans le monde des stations de travail et des mini, le Network File System de Sun est le plus utilisé. Les spécifications en sont disponibles auprès de Sun Microsystems). Impression distante. Il permet d'imprimer des fichiers sur des imprimantes rattachées à d'autres ordinateurs. (Le plus utilisé est certainement le protocole d'impression Berkeley Unix. Malheureusement, aucun document n'existe sur ce protocole. Le code C est cependant facilement disponible auprès de Berkeley). Exécution à distance. Elle permet le lancement d'applications sur d'autres ordinateurs. Ceci est pratique lorsque vous exécutez la plupart de vos travaux sur un petit ordinateur, et que certaines tâches demandent les ressources de machines plus importantes. Il existe plusieurs types d'exécutions à distance. Certaines sont dites "commande par commande". C'est à dire que vous demanderez à un ordinateur précis d'exécuter une commande précise (ou un groupe de commandes). (Des versions plus sophistiquées savent trouver une machine qui est libre à ce moment). Il existe aussi des systèmes d'appels de procédure distants qui permettent à un programme d'exécuter un sous programme sur un autre ordinateur. (Il existe plusieurs protocoles de cette sorte. Berkeley Unix fournit deux serveurs capables d'exécuter des programmes à distance : rsh et rexec. La page man d'Unix décrit le protocole utilisé par ces serveurs. Le système contributif Berkeley 4.3 contient un "shell" distribué pouvant répartir des tâches entre plusieurs systèmes, suivant la charge de chacun d'entre eux. Les mécanismes d'appels de procédures à distance ont fait l'objet de nombreuses recherches depuis des années, et de nombreux organismes ont implémenté des utilitaires dans ce sens. Les deux utilitaires les plus répandus sont certainement Xerox's Courier et RPC de Sun. Les document sur ces protocoles sont disponibles respectivement chez Xerox et Sun. Une version publique de courrier sous TCP fait partie du système contributif Berkeley 4.3. Une implémentation de RPC a été postée vers Usenet par Sun, et fait aussi partie intégrante du système Berkeley 4.3). Serveurs de domaines. Dans de grandes installations, plusieurs ensembles de "noms de domaines " doivent être gérés. on trouve parmi eux les noms d'utilisateurs et leurs mots de passe, le nom et l'adresse des ordinateurs et des comptes à l'intérieur de ces derniers. Il serait bien trop lourd d'avoir à gérer et mettre à jour ces noms s'il étaient répartis dans toutes les machines. Les bases comportant ces données sont dont hébergées en un endroit précis du système. D'autres systèmes viennent y puiser les informations qui leur sont nécessaire. (RFC 822 et 823 décrivent le protocole du serveur de domaines utilisé pour garder la trace des noms de machines et des adresses Internet du réseau. Il représente aujourd'hui un composant indispensable de toute implémentation TCP/IP. L'IEN 116 décrit un ancien protocole de domaines encore utilisé par quelques serveurs de terminaux pour la récupération des noms de machine . Les Yellow Pages de Sun est l'un des grand systèmes de gestion de noms d'utilisateurs, de groupes, et autres données couramment utilisées par les systèmes Unix. Il est largement distribué dans le commerce. La définition de son protocole est disponible auprès de Sun). Serveurs de terminaux. Dans de nombreuses installations, les terminaux ne sont plus directement reliés à l'ordinateur. Au lieu de cela, ils sont connectés à un serveur de terminaux. Celui-ci est en fait un petit ordinateur qui ne sait que lancer Telnet (ou tout autre protocole d'ouverture de session à distance). Si votre terminal est raccordé à un tel serveur, il suffit de taper le nom de l'ordinateur pour y être connecté. Il peut être possible d'ouvrir plusieurs connexions simultanées sur des ordinateurs différents. Le serveur de terminal devra être en mesure de commuter entre différentes sessions rapidement, et de vous avertir quand une sortie attend une activation. (Le serveur de terminal utilise Telnet, comme mentionné ci-avant. Cependant un certain nombre d'autres protocoles devront y être implémentés, comme un serveur de noms). Système de multifenêtrage orienté réseau. Jusqu'à récemment, les applications à haut besoin graphique nécessitaient un affichage sur un écran en "bitmap" (un ou plusieurs bits par pixel) toujours directement rattaché à l'ordinateur local. Les systèmes de fenêtrage orientés réseau permettent cet affichage sur des écrans rattachés à d'autres ordinateurs. Les systèmes de fenêtrage réseau large-bande permettent de distribuer un travail sur plusieurs machines les plus adaptées, mais ne fournissent toujours qu'une interface utilisateur unique. (Un des systèmes les plus connus sur Unix est X. La description du protocole est disponible auprès du MIT, Project Athena. Le MIT en diffuse au public une notice d'implémentation). Un grand nombre de constructeurs utilisent aussi NeWS, un système de fenêtres développé par Sun. Ces deux systèmes s'accordent avec TCP/IP). A noter que les protocoles précités ont été écrits par Berkeley, Sun, ou d'autres organisations. Ils ne font dont pas partie officielle de l'ensemble Internet. Cependant, ils utilisent TCP/IP, tout comme les applications TCP/IP plus traditionnelles. Comme ces protocoles ne sont pas considérés comme "propriétaires", et comme leur implémentations commerciales sont largement diffusées, il est raisonnable de les associer à l'ensemble Internet. A noter que la liste ci dessus n'est pas exhaustive. Elle contient cependant les applications "majeures". Les autres protocoles non cités sont plus assimilables à des utilitaires spécifiques répondant à des besoins ponctuels, pour savoir, par exemple qui est connecté, ou l'heure du jour, etc. Si vous avez besoin d'un protocole qui n'a pas été cité ici, nous vous recommandons de vous référer au document RFC 1011, listant l'ensemble des protocoles disponibles, ainsi qu'aux implémentations majeures de TCP/IP pour voir ce que les constructeurs ont ajouté depuis. 2. Description générale des protocoles TCP/IP TCP/IP est un ensemble de protocoles en "couches". Pour comprendre ce concept, prenons un exemple, un cas typique, l'envoi d'un courrier. Il existe tout d'abord un protocole pour le "mail". Il définit une série de commandes qu'une machine envoie à une autre, ex. commandes pour dire qui envoie le message, quel en est le destinataire, puis le texte du message. Cependant, ce protocole suppose qu'une connexion sure est établie entre les deux ordinateurs. L'application Mail, comme d'autres applications, précise simplement un certain type et nombre de commandes à envoyer. Elle est conçue pour s'appuyer sur TCP et IP. TCP est le responsable de la transmission de ces commandes d'un bout à l'autre. Il garde la trace de ce qui est envoyé, et retransmets tout ce qui n'a pas été reçu à l'autre extrémité. Si un message est trop long pour entrer dans un paquet, ex. le texte du message, TCP le découpera en plusieurs paquets, et s'assurera que tous les paquets seront correctement transmis. Comme cette fonction particulière est commune à de nombreuses applications, elle a été isolée du protocole "mail", et à été à l'origine de cette couche inférieure. Vous pouvez voir TCP comme une librairie de sous programmes que les applications supérieures utilisent lorsqu'elles ont besoin d'une communication sure avec leur interlocuteur. A l'identique, TCP appelle lui-même les services d'IP. Bien que les fonctions que TCP soient communes à de nombreuses applications, il en existe qui n'utilisent pas les ressources complètes de TCP. Il existe néanmoins un ensemble de ressources vraiment communes à TOUTES les applications. celles-ci ont été rassemblées dans IP. Comme pour TCP, pensez IP comme une librairie de sous programmes auxquelles TCP fait appel, et qui restent de plus disponibles aux applications qui ne s'appuient pas sur TCP. Cette stratégie de construction d'un protocole s'appelle la mise en "couches". Ainsi, les applications comme mail, TCP, et IP, sont en fait des "couches" séparées, chacune s'appuyant directement sur la couche en dessous d'elle. En général, les applications TCP/IP utilisent 4 couches : •   un protocole applicatif (ex. mail) •   un protocole type TCP réunissant les fonctions de haut niveau de transmission •   IP, assurant la transmission de base des "paquets" ou encore "datagrammes" •   Le protocole propre au médium physique, comme Ethernet ou un protocole point à point. +--------+ +-----+ +------+ +-------+ +------+ +-----+ +-------+ +------+ | TELNET | | FTP | | SMTP | | HTTP  | | SNMP | | RIP | |  NFS  | | PING | |        | |     | | POP  | |       | |      | |     | |  RPC  | |      | +--------+ +-----+ +------+ +-------+ +------+ +-----+ +-------+ +------+      |       |        |         |        |       |         |        | +----------------------------------+   +-----------------------+ +------+ |                TCP               |   |           UDP         | | ICMP | +----------------------------------+   +-----------------------+ +------+                   |                          |                      | +-----------------------------------------------------------------------+ |                        Internet Protocol (IP)                         | +-----------------------------------------------------------------------+                       |                        +---------------------------+                        |   Local Network Protocol  |                        +---------------------------+ TCP/IP est basé sur le modèle "catenet". (Celui-ci est décrit de façon plus détaillée dans l'IEN 48.) Ce modèle suppose l'existence d'un grand nombre de réseaux indépendants raccordés entre eux par des routeurs. L'utilisateur est sensé pouvoir exploiter les fichiers et ressources de n'importe quel ordinateur connecté sur l'un de ces réseaux. Les paquets d'information pourront transiter à travers plusieurs réseaux avant d'arriver à leur destination finale. Le "routage" des paquets doit cependant rester totalement transparent pour l'utilisateur. Tout ce que l'utilisateur a besoin de connaître se résume par l'adresse Internet de son correspondant. Cette adresse a une forme de type 128.6.4.194. Elle est aujourd'hui représentée par un nombre sur 32 bits. Elle est cependant représentée par un ensemble de quatre nombres décimaux pour plus de commodité, Chacun représentant 8 bits du champ d'adresse. (La documentation utilise le terme "octet" pour nommer les 8 bits). La structure de l'adresse peut vous donner des informations sur la nature du correspondant. Par exemple, 128.6 est e nombre attribué par l'autorité centrale à l'université de Rutgers. Rutgers utilise le nombre suivant (3! position) pour définir lequel des divers Ethernets est visé. 128.6.4 est par exemple, l'adresse de l'Ethernet du Département des Sciences Informatiques. Le dernier octet discriminera une machine particulière parmi 254 sur ce tronçon de réseau. (254 seulement, car 0 et 255 son des adresses réservées, voir plus loin). Par conséquent, les deux adresses 128.6.4.194 et 128.6.5.194 visent des systèmes différents. La structure de l'adresse Internet sera décrite plus en détail par la suite. Pour des raisons évidentes de commodité, une machine sera de préférence adressée par un nom plutôt que par une adresse numérique. Lorsqu'un nom est donné, le logiciel réseau se connecte à une base de donnée pour récupérer la transcription numérique de l'adresse. La plupart des logiciels réseau ne savent en effet travailler qu'avec des adresses numériques. (RFC 882 décrit le protocole utilisé pour conduire cette transcription). TCP/IP est basé sur un principe "non connecté". L'information est encapsulée dans une suite de "paquets" ou "datagrammes". Un paquet est une petite partie des données envoyée individuellement sur le réseau. Le protocole gère l'ouverture d'une connexion sous forme d'un "circuit virtuel" (c'est à dire ouvre une communication durant un certain temps entre deux machines devant se transmettre une certaine quantité d'information). En pratique, ce circuit "virtuel" fait l'objet d'un grand nombre de connexions unitaires et indépendantes dont l'objet est la transmission d'un paquet unique. Supposons par exemple que vous souhaitiez transmettre un fichier binaire de 15000 octets. La plupart des réseaux ne peuvent admettre le transfert en une fois d'un paquet de 15000 octets. Le protocole va donc découper ce fichier en "paquets" de 30 à 500 octets. Chacun de ces paquets étant transmis individuellement à l'autre bout. A l'arrivée, ces paquets seront réassemblés pour reformer le fichier de 15000 octets. Pendant tout le temps de transit de ces paquets, le réseau ignore la corrélation que ces paquets ont entre eux. Il est parfaitement possible que le paquet numéro 14 arrive avant le paquet d'ordre 13. Il est aussi parfaitement possible qu'à la suite d'une erreur, un paquet n'arrive jamais à destination, auquel cas il doit être réémis. Notez que jusqu'ici, nous avons parlé de "paquets" ou de "datagrammes". Techniquement, le "datagramme" est la dénomination exacte de la modularité de données dans TCP/IP. Un datagramme est une unité indivisible de données, que le réseau est amené à gérer. Un paquet définit plutôt une unité physique apparaissant sur un Ethernet ou un autre réseau filaire. Dans la majorité des cas, un paquet transmet physiquement un seul datagramme. Ce n'est pas toujours le cas. Lorsque par exemple TCP/IP est utilisé au travers d'un lien X.25, l'interface X.25 casse le datagramme en "paquets" physiques de 128 octets. Le protocole IP n'en voit rien, car ces "paquets" là sont reconstitués à l'arrivée de la ligne X.25, avant d'être pris en charge par les couches TCP/IP. Dans ce cas précis, un paquet IP sera donc transmis sous la forme de plusieurs paquets. Cependant, dans notre cas, nous continuerons à utiliser le terme "paquet", en ce sens que seuls les couches TCP/IP nous intéressent. 2.1. La couche TCP Deux protocoles distincts sont impliqués dans la transmission de données par TCP/IP. Le protocole TCP ("transmission control protocol") est responsable du partitionnement des données en paquets, de leur émission, de leur rassemblement à l'autre extrémité, de la réémission des paquets perdus ainsi que de la reconstitution dans le bon ordre du message à transmettre. Le protocole IP ("Internet protocol") est responsable du "routage" individuel des paquets. A première vue, il semble que TCP fasse l'essentiel du travail. Cela est vrai pour des réseaux simples. Cependant, dans un réseau comme Internet, la simple tâche de router un paquet à travers le réseau peut devenir très complexe. Une connexion peut fort bien être amenée à traverser plusieurs réseaux Ethernet, Talken ring ou d'autres types avant d'arriver au destinataire. Garder la trace du chemin de chaque paquet, et gérer la compatibilité des médias utilisés en chemin peut devenir un vrai casse-tête. Notez ici que l'interface entre TCP et IP est somme toutes assez simple. TCP donne simplement à IP un paquet avec une destination. IP n'a aucune connaissance de la relation de ce paquet avec un paquet précédemment émis ou à suivre. Quelque chose semble manquer au point où nous en sommes. Nous avons parlé d'adresse Internet, mais absolument pas de comment garder la trace des multiples chemins possibles pour arriver à une destination donnée. Il n'est évidemment pas suffisant de préciser simplement la destination d'un paquet. Encore faut-il que TCP sache de quelle communication ce paquet fait partie. Cette tâche s'appelle le "démultiplexage". En fait, on trouvera plusieurs niveaux de démultiplexage dans TCP/IP. L'information permettant ce travail de démultiplexage se trouve dans ce que l'on appelle des en-têtes de message ou "headers". Une en-tête est constituée de quelques octets supplémentaires ajoutés au paquet pour l'identifier. On peut voir la chose comme une lettre enfermée dans une enveloppe à l'extérieur de laquelle on aurait écrit l'adresse. Sauf pour les réseaux par modem (point à point), ce procédé est utilisé plusieurs fois. C'est comme mettre le message dans une petite enveloppe, laquelle est glissée dans une sacoche pour la poste, laquelle part dans un sac postal, etc. Voici ci-après une description des en-têtes typiquement ajoutées à un message lors d'une transmission sous TCP/IP  : Partons d'un flux de donnée brutes, présente dans l'ordinateur  : ........................................................................... TCP morcelle ces données en paquets diffusables par le réseau. (Pour ce faire, TCP doit savoir quelle est la taille maximale du paquet que le réseau peut supporter. Actuellement, les deux programmes TCP s'échangent la taille maximale que chacun sait gérer. La taille la plus petite est choisie pour la transmission). Le flux continu de données devient un flux discontinu  : .... .... .... .... .... .... .... .... .... .... .... .... .... ..... .... .... .... TCP ajoute alors une en-tête en début de chaque paquet. Ce paquet contient aujourd'hui au moins 20 octets, dont les plus importants codent un "numéro de port" pour la source et la destination, ainsi qu'un numéro de séquence. Les numéros de ports servent à l'identification de la communication. Supposons que 3 personnes transmettent simultanément des données. TCP allouera par exemple les ports 1000, 1001, et 1002 à chacune de ces communications. Lorsqu'un paquet est transmis, il l'est à partir d'un de ces trois ports, représentant le port "source". Bien sur, le TCP distant aura lui aussi assigné des ports à chacune des conversations. Le TCP local devra en avoir eu connaissance avant de transmettre les paquets (Ceci est réalisé lors de la "procédure de connexion", comme nous l'expliquerons plus loin). Il indiquera ce port "destinataire" dans l'en-tête. Dans la communication inverse, les deux numéros de port occuperont les places inversées, la "source" devenant destination, et la "destination" devenant la source à son tour. Chaque paquet est marqué d'un numéro de séquence. Celui-ci est utilisé par le réceptionnaire pour reconstituer les informations dans le bon ordre, et détecter tout paquet perdu. (Voir la spécification TCP pour les détails). TCP numérote en fait les octets plutôt que les paquets. Si chaque paquet transmet 500 octets, le premier sera noté 0, le second 500, le troisième 1000, etc. Nous mentionnerons enfin le Checksum, qui est un nombre de contrôle obtenu par l'addition de tous les octets du message (plus ou moins - voir la spécification TCP). Le résultat est ajouté à l'en-tête. Le TCP distant recalcule ce nombre. Si les deux nombres, celui recalculé, et celui inscrit dans l'en-tête, diffèrent, alors une erreur de transmission s'est certainement produite, peut être pour un seul bit, et le message doit être rejeté. Un paquet prend finalement la forme suivante :  0                   1                   2                   3  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |          Port Source          |       Port Destination        | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |                      Numéro de Séquence                       | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |                    Acknowledgment Number                      | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  Data |           |U|A|P|R|S|F|                               | | Offset|  Reservé  |R|C|S|S|Y|I|            Fenêtre            | |       |           |G|K|H|T|N|N|                               | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |           Checksum            |      Pointeur d'Urgence       | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |                    Options                    |    Padding    | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |                            Données                            | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Si nous symbolisons l'en-tête par le caractère "T", notre flux transmis devient : T.... T.... T.... T.... T.... T.... T.... Vous noterez à ce point quelques éléments de l'en-tête qui n'ont pas encore été décrits. Ils interviennent généralement dans la gestion de la connexion. Pour être sur que le paquet est bien arrivé à destination, le réceptionnaire doit transmettre un "accusé de réception". Il s'agit d'un paquet dont le "numéro d'acceptation" est spécifié. Par exemple, si un paquet est envoyé avec un numéro d'acceptation de 1500, cela indique à la source que les 1500 premiers octets ont bien été reçus. Si la source ne reçoit pas d'accusé de réception au bout d'un temps prédéterminé, il réémet les données supposées non reçues. La donnée de fenêtre permet d'indiquer combien d'octets peuvent être en transit à un moment donné. Cette information fait partie d'une procédure que l'on appelle "contrôle de flux": il ne serait pas judicieux d'attendre que chaque paquet ait fait l'objet d'un accusé de réception avant d'émettre le suivant. La liaison en deviendrait trop lente. D'un autre côté, il n'est pas non plus possible d'émettre continuellement, sans se préoccuper du destinataire. Une différence de puissance, et donc de vitesse entre deux ordinateurs pourrait provoquer un "bourrage" de la liaison. Pour éviter ce problème, chacun inscrit le nombre d'octets qu'il est prêt à absorber dans ce champ appelé "fenêtre". Lorsque l'ordinateur reçoit des données, la "largeur" de cette fenêtre décroît. Lorsqu'elle arrive à zéro, l'émetteur doit cesser d'envoyer des paquets. Au fur et à mesure que le destinataire traite les données reçues, il augmentera de nouveau la taille de la "fenêtre" disponible indiquant à l'émetteur qu'il peut recommencer à transmettre. Souvent, le même paquet sera utilisé pour envoyer un accusé de réception et "rouvrir" la fenêtre de transmission. Le champ noté "d'urgence" permet à une extrémité d'indiquer à l'autre de sauter au traitement d'un octet particulier. Ceci est utile pour la gestion d'événements asynchrones comme l'envoi d'une séquence de contrôle pour indiquer à l'émetteur de stopper immédiatement toute transmission. Les autres champs sont hors du cadre de ce propos. 2.2. La couche IP Pour transmettre ses paquets, TCP va s'adresser à IP. Il devra bien sur donner à IP l'adresse Internet du destinataire. Notez qu'IP n'a effectivement besoin que de cette information. Tout ce qui concerne le contenu du paquet, y compris l'en-tête TCP elle-même lui est parfaitement indifférent. Le travail d'IP est de trouver un chemin pour acheminer le paquet de la source au destinataire. Afin d'aider les routeurs et autres composants intermédiaires dans cette tâche, IP ajoute sa propre en-tête. Les principaux éléments de celle-ci sont les adresses Internet respectives de la source et du destinataire (adresses 32 bits, du type 128.6.4.194), le numéro de protocole, ainsi qu'un Checksum supplémentaire. L'adresse de la source est en fait l'adresse de votre propre machine. (Celle-ci est nécessaire pour que l'ordinateur appelé puisse vous répondre). L'adresse destinataire est celle de l'ordinateur appelé. (Celle-ci est indispensable pour que les composants intermédiaires sur le chemin puissent rediriger votre message). Le numéro de protocole indique à l'IP distant qu'il doit transmettre le paquet à la couche TCP. Bien que la majeure partie du trafic IP s'adresse à TCP, d'autres protocoles peuvent s'appuyer sur IP, lequel doit être précisément notifié dans l'en-tête du paquet transmis. Finalement, le Checksum supplémentaire sert à vérifier la pertinence de la nouvelle en-tête ajoutée au message. (Notez que de ce fait, TCP et IP utilisent un Checksum différent - Notez de plus qu'en suivant ce raisonnement, un nouveau Checksum est nécessaire à chaque fois qu'une information est ajoutée à un paquet par une couche de protocole). IP doit en effet pouvoir vérifier que son propre en-tête n'a pas subi une erreur de transmission en cours d'acheminement, laquelle n'est pas détectable dans le Checksum TCP. Pour des raisons que nous ne développerons pas ici, il est préférable de conserver deux Checksum séparés pour IP et TCP. Le paquet devient alors : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version|  IHL  |Type de Service |          Longueur totale     | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |         Identification         |Flags|       Fragment Offset  | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  Durée de vie  |    Protocole  |      Checksum d'en-tête      | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |                   Adresse de source                           | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |                  Adresse du destinataire                      | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  En tête TCP, puis vos données ......                         | |                                                               | Si nous symbolisons l'en-tête par le caractère "T", notre flux transmis devient : T.... T.... T.... T.... T.... T.... T.... Comme toujours, l'en-tête IP comporte des champs dont nous n'avons pas encore parlé. La plupart d'entre eux sont en dehors du cadre de ce document. Les "flags" et donnée de "fragment" servent à conserver la trace de paquets qui ont été redécoupés plus finement. Ceci survient lorsque celui-ci doit traverser une portion de réseau acceptant des paquets de taille inférieure. (Voir ci-après). La durée de vie est une donnée qui est décrémentée pendant son transit. Lorsqu'elle tombe à zéro, le paquet est rejeté. Elle a été prévu dans le cas peu probable ou un paquet ne trouvant pas sa destination serait amené à boucler son chemin sans aboutir nulle part. Ceci est pratiquement impossible, mais une implémentation bien faite doit pouvoir traiter même les situations impossibles... en théorie. Arrivé à ce point, les données sont parfaitement "encapsulées" et aucune "couche" supplémentaire n'est en principe nécessaire. si votre ordinateur est raccordé par liaison modem directe, ou sur un routeur, il pourrait très bien envoyer notre paquet ainsi constitué sur la ligne (sauf si un protocole de transmission synchrone est utilisé, de type HDLC - utilisé en téléphonie numérique - auquel cas quelques octets en début et en fin seraient encore ajoutés). 2.3. La couche Ethernet Cependant, la majorité de nos réseaux actuels s'appuient sur Ethernet. Nous devons donc décrire les en-têtes ajoutées par ce protocole. Pour notre malheur, Ethernet utilise des adresses qui lui sont propres. Les créateurs d'Ethernet voulaient à l'origine être certains que deux machines ne puissent jamais avoir la même adresse Ethernet. De plus, comme il n'était pas question que l'utilisateur se soucie de la configuration d'une adresse, ce sont les contrôleurs Ethernet physiques dans les machines auxquels sont affectés une adresse Ethernet unique, directement en usine. Pour être sur qu'aucune adresse ne pourrait apparaître en double, les ingénieurs Ethernet ont étendu le champ d'adresse à 48 bits. Ce sont les constructeurs de cartes Ethernet qui doivent se déclarer auprès d'une autorité centrale, afin d'être certain que leur adresses ne recoupent jamais celles d'autre constructeurs. Ethernet est un médium de "diffusion". Un peu comme les toutes premières lignes téléphoniques. Lorsque vous envoyez un paquet sur Ethernet, toutes les machines raccordées sur le réseau "voient" ce paquet. Quelque chose doit donc être mis en place pour être sur que le bon destinataire récupérera bien le paquet qui lui est destiné. Comme vous pouvez le deviner, il s'agit d'une en-tête Ethernet. Chaque paquet Ethernet dispose d'un en-tête de 14 octets comprenant l'adresse (Ethernet) de la source, l'adresse (Ethernet) du destinataire, et un code de type. Chaque machine est sensée ne faire attention qu'aux paquets dont l'adresse destinataire correspond à la sienne. (Il est parfaitement possible de "tricher", voilà pourquoi le réseau Ethernet n'est pas considéré comme un réseau sécurisé). Il n'y a aucune corrélation entre l'adresse Internet et l'adresse Ethernet. Chaque machine devant nécessairement disposer d'une table de correspondance pour savoir à quelle adresse Internet correspond une adresse Ethernet. (Nous décrirons à quoi ressemblent ces tables un peu plus loin). Le code de type permet à plusieurs protocoles distincts de cohabiter sur le même réseau. Un réseau peut donc acheminer des données sous TCP/IP, DECnet, Xerox NS, etc. simultanément. Chacun de ces protocole indiquera une valeur différente dans ce code. Enfin, et comme toujours, on ajoute un Checksum. Celui-ci est calculé sur le paquet entier (et non simplement sur l'en-tête comme le Checksum IP). Si le calcul à la réception diffère du Checksum inclus dans le paquet, ce dernier est jeté. Le protocole Ethernet ajoute le Checksum à la fin du paquet, et non dans l'en-tête. Notre paquet prend donc l'allure suivante : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |       Adresse de destination Ethernet (32 premiers bits)      | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  Ethernet dest (16 derniers)  |Ethernet source (premiers 16)  | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |          Adresse source Ethernet (32 derniers bits)           | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |        Type code              | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |      En-tête IP, en-tête TCP puis vos données                 | |                                                               | |                                                               | |      Fin de vos données                                       | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |                       Checksum Ethernet                       | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Symbolisons de nouveau notre en-tête Ethernet par un "E" et son Checksum par un "C", nous obtenons le flux: EIT....C EIT....C EIT....C EIT....C EIT....C A l'arrivée, chaque couche de protocole analyse son en-tête et Checksum, puis extrait le contenu "interne" pour le transmettre à la couche suivante. Ainsi, l'interface Ethernet enlève l'en-tête Ethernet et le Checksum de fin, et analyse le code de type. Si ce code désigne IP, le driver Ethernet passe le contenu du paquet à IP. IP enlève l'en-tête IP, et analyse le champ de protocole. Si le protocole désigne TCP, le driver IP passe le paquet à TCP qui regarde à son tour le numéro de séquence pour recomposer le fichier original. Ceci termine notre description générale de TCP/IP. Nous ajouterons dans la suite quelques points de détail importants (Pour une description complète, référez-vous aux normes suivantes, RFC 793 pour TCP, RFC 791 pour IP, et RFC 894 et 826 pour la transmission d'IP sur Ethernet). 3. Couche applicative et "sockets réservés" Jusqu'ici, nous avons vu comment TCP/IP tronçonne un flux de donnée, l'envoie, le récupère et le reconstitue, identique à l'original. Nous devons maintenant préciser un point important afin que tout ce processus ait une quelconque utilité. Nous devons trouver le moyen pour ouvrir une communication vers un ordinateur, s'y connecter, y ouvrir une session, choisir un fichier, le rapatrier, et laisser les choses aussi nettes qu'avant d'y être entré. (Si vous avez une autre application en tête, comme le courrier électronique, nous retomberons sur la même problématique). Tout ce travail est l'oeuvre de protocoles applicatifs. Ces applications à part entière s'exécutent au dessus de TCP/IP. C'est à dire, lorsqu'elles désirent transmettre un message, s'adressent à TCP pour le faire à leur place. TCP s'assurera que ce message est bien transmis à l'autre extrémité. Dans la mesure ou TCP et IP s'occupent de tous les aspects du transit de données, les applications ne voient en fait plus qu'un flux continu de départ et d'arrivée, une fois les opérations de connexion effectuées. Avant d'entrer dans le détail des applications, nous devons auparavant savoir où les trouver. Supposons que vous souhaitiez envoyer un fichier sur un ordinateur d'adresse Internet 128.6.4.7. Pour démarrer le processus, il vous faut connaître évidemment l'adresse Internet, mais aussi savoir où trouver l'applicatif FTP sur le distant. En général, les applicatifs réseau sont spécialisés pour des tâches spécifiques. De nombreux systèmes disposent de plusieurs petites applications pour gérer tantôt les transferts de fichiers, tantôt le courrier, tantôt les sessions distantes, etc. Lorsque vous établissez la communication avec l'ordinateur 128.6.4.7, vous devez préciser que vous souhaiter communiquer avec l'application FTP. Ceci est obtenu par l'utilisation de "sockets réservés" dans chaque serveur. Souvenez-vous: TCP utilise les numéros de port pour se "souvenir" des communications individuelles. Les programmes utilisateur utilisent des ports de numéro plus ou moins arbitraires. Le moins arbitraire, c'est lorsque les ports sont dits "réservés" par une application connue. Ces ports réservés sont associés à une application et toute arrivée sur ces ports est routée "en dur" vers celle-ci. Par exemple, vous voulez envoyer votre fichier. Vous démarrez une session "ftp" sur votre ordinateur. Celle-ci va initier une communication en choisissant un numéro de port arbitraire, disons 1234, sur votre ordinateur, mais en spécifiant le port 21 pour le destinataire. 21 est le numéro de port officiel du serveur FTP. Notez ici que deux programmes différents sont impliqués dans la transaction. Vous lancez un "client ftp" sur votre ordinateur. Celui-ci reçoit vos commandes et les transmet à l'autre extrémité. Le programme auquel vous envoyez vos ordres est le Serveur FTP. Il est conçu pour exécuter des commandes transmises sur une connexion réseau plutôt qu'à partir d'un terminal. Votre programme client ftp n'a aucun besoin d'utiliser un socket réservé pour lui-même dans la mesure où il est toujours "demandeur", et jamais "demandé". Les serveurs par contre, doivent se conformer à ces sockets, de sorte que les "clients" puissent se connecter directement à l'application désirée. La liste des "sockets réservés" est fournie en annexe. Notez qu'une connexion est désormais définie par quatre nombres: les deux adresses Internet à chaque extrémité, et les deux numéros de port TCP. Chaque paquet transmis aura ces quatre nombres inscrits à l'intérieur (Les deux adresses Internet dans les en-têtes IP, les ports TCP dans les en-têtes TCP). Pour éviter tout conflit, il n'est pas envisageable de trouver deux communications avec les 4 mêmes nombres. Il suffit par contre qu'un seul des nombres soit différent pour que la deuxième connexion soit valide. Il est par exemple possible à deux utilisateurs de la même machine d'envoyer simultanément deux fichiers à la même machine sur le même port. Les "descripteurs" de communication auront l'allure suivante : Adresses Internet ports TCP connexion 1 128.6.4.194, 128.6.4.7 1234, 21 connexion 2 128.6.4.194, 128.6.4.7 1235, 21 Comme les machines physiques sont les mêmes, les adresses Internet sont identiques. Les deux connexions faisant du transfert de fichier, l'un des ports invoqués est identique dans les deux cas et correspond au fameux ports du Serveur FTP. La seule différence entre les deux connexions est le numéro de port utilisé par les deux programmes clients lancés. Cette seule différence suffit à l'identification de la communication. En général, l'une des extrémités d'une connexion devra demander au réseau de lui attribuer un port libre et unique. En général, c'est souvent du côté client que cette attribution est faite, tandis que le serveur utilise ses ports "réservés". Maintenant que nous savons ouvrir une communication, revenons à nos programmes d'application. Comme nous l'avons mentionné plus haut, une fois que TCP a établi une communication, celle-ci apparaît comme un flux continu de données comme s'il s'agissait d'un simple câble. L'essentiel du travail a été pris en charge par TCP et IP. Il nous reste à déterminer ce que nous allons envoyer par ce flux. Il s'agit essentiellement d'une convention définissant les commandes que les applications vont envoyer, et la syntaxe qui sera adoptée. Souvent il s'agira d'un mélange de commandes et de données. Le contexte en permet la différenciation. Par exemple, le protocole de courrier électronique fonctionne ainsi: Votre programme de courrier ouvre une communication avec le Serveur de courrier. Votre programme donne à ce dernier le nom de votre machine, l'émetteur du message, et le récipiendaire. Il envoie ensuite une commande indiquant qu'il commence à transmettre le contenu du message. A l'autre bout, le serveur sait alors que toutes les données suivantes doivent être interprétées comme des données et non comme des commandes. Le message est alors transmis. A la fin du message, une marque particulière est envoyée (un point dans la première colonne). Elle indique que le serveur doit retourner en mode "commande". Il s'agit de la procédure la plus simple, et évidemment la plus utilisée. Les transferts de fichiers mettent en oeuvre une procédure plus complexe. Le protocole invoqué doit gérer deux connexions. La procédure démarre comme un simple courrier. Le programme client envoie quelque chose qui pourrait bien vouloir dire "fais moi entrer en tant que l'utilisateur X", "voici mon mot de passe", "envoie moi le fichier de tel nom". Cependant, lorsque la commande a été interprétée, une deuxième communication est ouverte pour effectuer le transfert de données. Pratiquement, il était tout à fait possible d'utiliser la première communication pour envoyer les données (toutes les communications sont en effet bidirectionnelles). Cependant, les transferts de fichiers sont souvent longs, et les concepteurs de ce service ont souhaité que l'utilisateur puisse continuer à envoyer des commandes, même pendant un transfert de fichier. Par exemple, l'utilisateur pourrait effectuer une recherche, ou envoyer une commande d'annulation du transfert en cours. C'est pour cela que les concepteurs des applications de transfert de fichiers ont préféré ouvrir une deuxième connexion et laisser la première comme voie de commande active. Notez que ce principe permet aussi d'envoyer des données entre deux ordinateurs tiers, et que dans ce cas une connexion indépendante de la voie de commande est indispensable. L'ouverture d'une session de travail à distance utilise encore une autre procédure. Une seule communication est ouverte dans ce cas. Elle transmet essentiellement des données. Lorsqu'il est nécessaire d'émettre une commande (par exemple pour changer le type de terminal ou commuter un mode opératoire), un caractère spécial permet d'indiquer que le caractère suivant est une commande. Si ce caractère doit être envoyé en tant que donnée, il faudra alors l'envoyer dupliqué: Si le caractère spécial est $ 'a' est une donnée '$a' est une commande '$$' est une donnée représentant le caractère '$' Nous ne décrirons pas plus précisément les protocoles applicatifs ici. Les RFC sont là pour ça. Cependant, nous allons tout de même parler d'un certain nombre de conventions que les applications utilisent. Tout d'abord, la représentation commune du réseau: TCP/IP est conçu pour être utilisable par n'importe quel ordinateur. Malheureusement, tous les ordinateurs ne s'accordent pas sur la manière de représenter les données. Il y a par exemple des différences de tables de caractères (ASCII ou EBCDIC), de conventions de "fin de ligne" (CR, LF, CR/LF, ou une représentation utilisant un comptage), ou dans la manière don les terminaux acceptent les données, caractère par caractère, ou ligne par ligne. Pour que tous les ordinateurs puissent se comprendre, les applicatifs s'appuient sur des représentations standard. Notez que TCP et IP n'ont aucune "conscience" de ces représentations. TCP envoie simplement des octets. Les programmes de niveau supérieur, à l'inverse, doivent s'accorder sur la manière d'interpréter ces données. La RFC de chacune de ces applications définit le standard pour l'interprétation de ces données. Le cas général est la représentation "net ASCII". Celle-ci accepte le code ASCII, les fins de ligne étant représentées par un CR suivi d'un LF. Pour l'application d'ouverture de session à distance, on ajoutera la définition d'un "terminal standard", défini par un fonctionnement "half-duplex" avec écho local. De nombreuses applications disposent des éléments permettant une négociation concertée entre les deux extrémités pour utiliser une représentation plus "riche". Par exemple, le PDP-10 utilise des mots de 36 bits. Il y aura toujours un moyen pour que deux PDP-10 puissent s'échanger un fichier ainsi codé. De même, deux systèmes préférant une communication de type bidirectionnelle (full-duplex) pourront toujours demander à l'établir, outrepassant ainsi le standard "minimum". Ce standard est défini afin de trouver un langage commun sur le principe fondamental de "qui peut le plus peut le moins". 3.1. Un exemple d'application : SMTP Une façon de mieux montrer ce qui est impliquant en termes de protocoles au niveau de l'application est de pendre un exemple, le SMTP, protocole de courrier électronique. (SMTP est l'acronyme de "simple mail transfer protocol"). Nous supposons ici que l'utilisateur TOPAZ.RUTGERS.EDU souhaite envoyer le message suivant: Date: Sat, 27 Jun 87 13:26:31 EDT From: hedrick@topaz.rutgers.edu To: levy@red.rutgers.edu Subject: rdv Rencontrons nous lundi prochain à 13 heures. Notez tout d'abord que le format même du message est cadré selon un protocole Internet (RFC 822). Le standard spécifie que le message doit être émis en "net ASCII" (ASCII, avec CR/LF pour terminer les lignes). Il décrit aussi sa forme générale, composé d'une en-tête, une ligne blanche, puis le texte du message. Enfin, il décrit précisément la composition de l'en-tête, en général constitué de lignes comportant un mot clef et une valeur. Notez que le destinataire est appelé LEVY@RED.RUTGERS.EDU. A l'origine, un destinataire était nommé comme une "personne à une machine donnée". Les standards récents ont rendu cette convention plus flexible. Un système peut aujourd'hui adresser un autre système de courrier. Ceci permet l'adressage de machines non connectées en permanence au réseau. Le nom de machine RED.RUTGERS.EDU peut ne pas exister. Le serveur de noms peut très bien réadresser les courriers par départements, chaque courrier étant redirigé vers la bonne machine. La partie avant le @ peut représenter autre chose qu'un utilisateur. Des programmes sont écrits en effet pour récupérer et traiter ces courriers comme s'il s'agissait d'une boîte aux lettres. Des fonctions existent aussi pour gérer des listes de diffusion, ou des fonctions virtuelles de "receveur principal" ou "opératrice". La manière dont est envoyé le message à l'autre machine est décrite dans les RFC 821 et 974. Le programme chargé de l'émission va demander au serveur de domaines un certain nombre d'informations pour déterminer la route que doit prendre le message. La première de ces questions est de savoir quelle machine physique gère le courrier de l'adresse RED.RUTGERS.EDU. Dans notre cas, le serveur répond que RED.RUTGERS.EDU dispose de sa propre messagerie. Le programme demande l'adresse correspondant au domaine RED.RUTGERS.EDU, qui est dans notre cas 128.6.4.2, puis ouvre une connexion TCP via le port 25 sur la machine 128.6.4.2. Le port 25 est la socket réservée pour l'accès au serveur de courrier. Une fois la communication établie, le programme de courrier commence à émettre ses commandes. En voici un résumé typique. Chaque ligne est écrite comme issue de TOPAZ ou RED. Notez que TOPAZ a été l'initiateur de la communication: RED 220 RED.RUTGERS.EDU SMTP Service at 29 Jun 87 05:17:18 EDT TOPAZ HELO topaz.rutgers.edu RED 250 RED.RUTGERS.EDU - Hello, TOPAZ.RUTGERS.EDU TOPAZ MAIL From:<HEDRICK@TOPAZ.RUTGERS.EDU>  RED 250 MAIL accepted TOPAZ RCPT To:<LEVY@RED.RUTGERS.EDU>  RED 250 Recipient accepted TOPAZ DATA RED 354 Start mail input; end with . TOPAZ Date: Sat, 27 Jun 87 13:26:31 EDT TOPAZ From: hedrick@topaz.rutgers.edu TOPAZ To: levy@red.rutgers.edu TOPAZ Subject: rdv TOPAZ TOPAZ Rencontrons nous lundi prochain è 13 heures. TOPAZ . RED 250 OK TOPAZ QUIT RED 221 RED.RUTGERS.EDU Service closing transmission channel Notez tout d'abord que les commandes sont en mode texte normal. Ceci est caractéristique d'un standard Internet. La plupart des protocoles utilisent des commandes écrites distinctement en ASCII. Cela améliore la traçabilité et le diagnostic en cas d'erreur. Par exemple, le logiciel de courrier garde une trace de toutes les "conversations". Si une erreur s'est produite, le fichier "log" sera envoyé au receveur principal. Comme les commandes sont exprimées en clair, il sera facile de détecter la source de l'erreur. Cette convention permet aussi à nous, pauvre humains, de dialoguer directement avec le programme de courrier, pour des actions de test. (Certains nouveaux protocoles sont tellement complexes que ces dernières opérations sont moins pratiques qu'il n'y parait. Les commandes atteignent une syntaxe qui nécessitera un "transcripteur". Il existe ainsi une tendance à développer des protocoles à écriture binaire, en général issus de développements en C ou en Pascal). Notez aussi que toutes les "réponses" commencent par un nombre. Ceci est aussi caractéristique des protocoles Internet. Les réponses autorisées sont aussi définies par le protocole. Les numéros correspondent à des réponses définies de faon non ambiguës. Le reste de la réponse en est une transcription "humaine" à notre intention. Celle-ci n'a pas d'effet sur le déroulement du programme. (Il existe toutefois des cas où une partie du texte est exploitée). Les commandes sont destinées à indiquer au serveur de courrier les informations nécessaires à la bonne distribution du message. Dans ce cas précis, le serveur aurait pu trouver ces informations dans le message lui-même. Mais dans des cas complexes, cette simplification peut s'avérer dangereuse. Chaque session débute par la commande HELO, destinée à indiquer le nom de la machine initiatrice. L'émetteur et le récipiendaire sont ensuite notifiés. (La commande RCPT peut être répétée, si le destinataire est multiple). Enfin, le texte du message est envoyé, suivi d'une ligne ne contenant qu'une virgule (si une telle ligne faisait partie du message, la virgule apparaîtrait doublée). Une fois le message émis, l'émetteur peut envoyer un deuxième message, ou fermer la communication comme dans le cas ci-dessus. Les numéros donnés comme réponse répondent à un schème précis. Le protocole définit précisément toutes les réponses possibles à une commande donnée. Cependant, les programmes simples de messagerie peuvent ne se limiter qu'au premier chiffre. En général, les réponses commençant par un 2 indiquent une opération aboutie. Un trois 3 indique qu'une action complémentaire est nécessaire. 4 et 5 indiquent une erreur. 4 est une erreur "temporaire", comme un manque d'espace disque. Le message doit être mémorisé, puis réémis plus tard, à un moment où la condition de faute aura disparu. 5 correspond à une erreur "permanente" et dont la condition ne peut disparaître, comme un destinataire inconnu. Le message est alors retourné à l'émetteur avec un statut de faute. (Pour plus de détails, consulter les RFC 821/822 pour le courrier, RFC 959 pour le FTP, et RFC 854/855 pour les sessions Telnet. Pour la liste des "sockets réservés" consulter la liste en annexe, et la RFC 814.) 4. Protocoles autres que TCP : UDP et ICMP Jusqu'ici, nous n'avons parlé que de programmes qui s'appuyaient sur TCP. Souvenons nous que TCP est responsable du découpage des données en "paquets", de leur transmission, et de leur "recomposition" en bon ordre à l'autre extrémité. Il existe des applications pour lesquelles un seul paquet suffit largement aux communications nécessaires. Un exemple en est la recherche de nom. Lorsqu'un utilisateur va vouloir se connecter sur un autre système, il spécifiera généralement ce système par son nom, plutôt que par son adresse Internet. Son propre ordinateur devra tout d'abord transformer ce nom en adresse avant de pouvoir faire quoi que ce soit. Les tables de transcription de ces noms sont hébergées dans un nombre de systèmes très petit en regard du parc de machines raccordées. L'ordinateur de l'utilisateur va donc devoir envoyer une requête à l'un de ces "serveurs de noms". La requête est de petite taille, et tiendra largement dans un paquet. La réponse idem. L'utilisation de TCP semble dans ce cas un peu hors sujet. Bien sur, TCP fait plus que le simple saucissonage des données, en vérifiant leur bonne transmission. Mais pour un message qui ne comprend qu'un paquet unique, utiliser TCP revient à écraser une mouche avec un rouleau compresseur. Si le paquet n'est pas reçu, il suffit de le renvoyer au bout d'un temps donné. Nul besoin d'artillerie lourde pour cette opération. Il existe des alternatives à TCP pour gérer ce genre de situations. La plus commune des alternatives à TCP est UDP ("user datagram protocol"). UDP est justement conçu lorsque les données sont suffisamment courtes pour être émises en une fois. Le protocole est assez proche de celui de TCP, mais avec une en-tête UDP. Le réseau ajoute l'en-tête UDP devant vos données, tout comme TCP ajouterait son en-tête TCP devant chaque paquet. UDP envoie le paquet unique ainsi constitué à IP, lequel ajoute son en-tête IP, en spécifiant bien le code du protocole UDP dans le champ de type au lieu du code attribué à TCP. UDP en fait cependant beaucoup moins que TCP: il ne partitionne pas les données à émettre et ne garde pas la trace de ce qui a été reçu. Tout ce que précise UDP est le numéro de port, afin que plusieurs UDP puissent cohabiter. Les ports définis pour UDP sont identiques à ceux définis pour TCP. On trouvera des sockets "réservés" aux connexions sous UDP. Notez ici qu'une en-tête UDP est évidemment plus courte qu'une en-tête TCP. Elle n'a en effet que la mention du port source et du port destinataire, ainsi que le Checksum. Pas de numéro de séquence, devenu inutile. UDP est utilisé pour la recherche de domaines (Cf. IEN 116, RFC 882, et RFC 883), et un certain nombre de fonctions réseau similaires. Une autre alternative à TCP est ICMP ("Internet control message protocol"). ICMP est utilisé pour la transmission de messages d'erreur, ainsi que d'autres messages à usage du logiciel TCP/IP lui-même, plutôt que par un programme applicatif particulier. Par exemple, vous essayez d'atteindre un "host" momentanément arrêté, vous recevrez un message ICMP disant "host unreachable". ICMP peut aussi être utilisé pour collecter un certain nombre d'informations sur le réseau. Cf. RFC 792 pour les détails sur ICMP. ICMP est similaire à UDP, dans ce sens qu'il gère des messages d'un paquet au plus. Cependant il est encore plus simple qu'UDP. Il ne précise aucun numéro de port dans son en-tête, car tous les messages ICMP sont directement interprétés par la couche réseau elle-même. Aucun port ne doit être défini pour savoir où doit aller le message. 5. Garder la trace des noms : les "domaines" Comme nous l'avons déjà indiqué, la plupart des fonctions réseaux nécessitent la mention d'une adresse Internet sur 32 bits afin de pouvoir établir une connexion ou envoyer un paquet. Les utilisateurs préfèrent manier des noms symboliques explicites plutôt que des nombres. Il existe donc des bases de données effectuant la transcription entre ces noms "clairs" et ces adresses numériques. Lorsqu'Internet était peu étendu, les choses étaient simples. Chaque système pouvait avoir dans ces disques un fichier contenant les noms de tous les autres systèmes, ainsi que leur adresse codée. le parc d'ordinateurs est aujourd'hui bien trop grand pour pouvoir garder cette approche. Il existe donc aujourd'hui des serveurs de noms de domaines dédiés, qui gardent la trace de ces noms et de leur correspondance Internet. (En fait ces serveurs ont des fonctions plus étendues que cela, et la table de domaines ne représente qu'une partie des données qui y sont hébergées). En pratique, il s'agit d'un ensemble de serveurs reliés entre eux plutôt qu'une seule et unique machine. Il y a en effet trop d'institutions indépendantes sur le réseau pour pouvoir déterminer laquelle pourrait être le point "central". L'autorité nécessaire pour attribuer des noms de domaines est donc déléguée à plusieurs institutions, réparties dans le monde entier. Les serveurs de noms utilisent le principe de l'arbre pour trier les noms selon des principes institutionnels. Les noms eux-mêmes suivent cette structure. Un exemple typique est le nom BORAX.LCS.MIT.EDU. Cette machine se situe dans le Laboratory for Computer Science (LCS) au Massachusetts Institute of Technology (MIT. Dans ce cas précis, quatre serveurs seront contactés pour établir l'adresse Internet visée. Tout d'abord, un serveur central "racine" sera contacté pour trouver le serveur EDU. EDU est un serveur qui garde la trace des institutions éducatives américaines. La racine va donner l'adresse de tous les serveurs regroupant les noms du domaine racine EDU (Ils sont effectivement plusieurs, au cas où l'un serait fermé pour faute ou pour maintenance). L'un des serveurs EDU sera ensuite contacté pour déterminer où se trouve le serveur du MIT. De même, les différentes adresses des serveurs du MIT seront données en réponse. En pratique, ces serveurs peuvent se trouver ailleurs qu'au MIT même, pour prendre en compte le cas d'une faute générale d'alimentation électrique du MIT. De proche en proche, l'adresse complète du domaine BORAX.LCS.MIT.EDU est constituée. Chacune de ces étapes met en jeu ce que l'on nomme un "domaine". Le nom entier, BORAX.LCS.MIT.EDU, est appelé un "nom de domaine". (Les noms intermédiaires LCS.MIT.EDU, MIT.EDU, et EDU sont autant de noms de domaines). Fort heureusement, il n'est pas nécessaire de dérouler systématiquement toutes ces requêtes. en premier lieu, le serveur "racine" s'avère être aussi le serveur de noms du domaine EDU. Ainsi, une seule requête à la racine vous amène droit au MIT. En deuxième lieu, le logiciel réseau dispose d'une certaine mémoire. Une fois le domaine LCS.MIT.EDU constitué, le logiciel réseau se souviendra de toutes les routes LCS.MIT.EDU, MIT.EDU, et EDU. il se souviendra en plus de la transcription de BORAX.LCS.MIT.EDU. Chacune de ces mémoires est associée à une durée de vie, typiquement de quelques jours. Après ce délai, l'information est "oubliée" et la requête doit être renouvelée. Le système des domaines ne se limite pas à fournir une adresse Internet. Chaque nom de domaine représente un "noeud" d'une base de données. Ce noeud est constitué d'enregistrements spécifiant un certain nombre de propriétés. On y trouvera par exemple, outre l'adresse Internet, le type de machine, et le type de services que cette machine supporte. Un programme peut demander une information ponctuelle, ou complète à cette base de données. Il est aussi possible pour un noeud d'être défini comme un "alias" (ou "nickname") d'un autre noeud. On pourra utiliser ce système pour stocker des informations concernant les utilisateurs, des listes de diffusion, etc. Il existe un standard Internet qui définit les fonctions de ces bases de données, ainsi que le protocole pour y lire des informations. Chaque utilitaire "réseau" doit pouvoir effectuer ces requêtes, dans la mesure où il s'agit désormais de la procédure officielle pour obtenir les noms de domaines. En général, ces programmes contactent un élément serveur sur leur propre système. Cet élément contactera les serveurs nécessaires. Ceci permet de diminuer la quantité de code dans chaque machine. Le serveur de domaines est un composant particulièrement essentiel du système de messagerie. Il existe une entrée pour indiquer quel est la machine qui traite les piles de courrier pour tel nom de domaine, pour spécifier quel individu doit recevoir un courrier, ou pour stocker des listes de diffusion. (Voir RFC 882, 883, et 973 pour les spécifications concernant les serveurs de domaines. La RFC 974 définit l'intervention du serveur de domaines dans le principe de courrier électronique). 6. Routage Notre explication a permis de mettre à jour le rôle d'IP dans l'acheminement d'un paquet de données vers le destinataire Internet. Jusqu'ici, nous n'avons pas réellement précisé comment cette fonction était réalisée. Cette tâche a un nom explicite: le "routage". En fait, les procédés de routage dépendent fortement des implémentations particulières des systèmes. Nous pouvons néanmoins en dégager des aspects généraux. Il nous faudra tout d'abord comprendre le modèle sur lequel IP est basé. IP suppose que toute machine est raccordée sur un réseau local. De ce fait toute machine peut en principe envoyer des paquets vers toute autre machine du réseau. (Dans le cas d'un réseau Ethernet, son travail consiste à trouver l'adresse Ethernet du destinataire, puis d'émettre le paquet sur la ligne). Le problème apparaît lorsque la machine cible n'est plus sur une portion de réseau directement visible par l'émetteur, un "autre" réseau. Ce problème est résolu par un "routeur". Un routeur est un composant réseau qui interconnecte deux ou plusieurs réseaux. Il s'agit soit d'appareils "physiques", soit simplement d'un ordinateur possédant plusieurs interfaces réseau distinctes. Nous disposons à l'université d'une machine Unix avec deux interfaces Ethernet. Celles-ci sont raccordées aux réseaux 128.6.4 et 128.6.3. Cette machine peut donc servir de routeur entre ces deux réseaux. un logiciel doit y être exécuté qui va faire passer les paquets d'un réseau à l'autre. Par exemple, si une machine raccordée au réseau 128.6.4 envoie un paquet au "routeur", et ce paquet est destiné à une machine du réseau 128.6.3, le routeur aura pour mission de réémettre ce paquet sur cet autre réseau. Les plus grands centres de communication sont équipés de routeurs interconnectant les réseaux les uns aux autres. (Dans bien des cas, les routeurs "physiques" dédiés offrent de bien meilleures performances et fiabilité par rapport aux machines généralistes utilisées comme routeurs). Dans IP, le routage se base exclusivement sur le numéro d'adresse du réseau destinataire. Chaque ordinateur dispose d'une table de numéros de réseaux. Pour chacun de ces numéros, un routeur est indiqué. "Ce routeur est spécifié pour atteindre ce réseau". Notez que ce routeur n'est pas nécessairement le point d'entrée physique du réseau. Il est seulement le meilleur choix pour atteindre le réseau désiré. Par exemple, à Rutgers, notre interface pour le NSFnet est localisée au John von Neuman Supercomputer Center (JvNC). Notre connexion au JvNC est réalisée par un ligne série haut débit, raccordée au routeur 128.6.3.12. Les machines du réseau 128.6.3 vont identifier le routeur 128.6.3.12 comme le chemin le plus pertinent pour un grand nombre d'accès hors du campus. les machines sur le réseau 128.6.4 vont trouver le routeur 128.6.4.1 pour le même besoin. 128.6.4.1 est en fait le routeur interconnectant les réseaux internes 128.6.4 et 128.6.3, et apparaissant comme la première étape vers le JvNC. Lorsqu'un ordinateur veut envoyer un paquet, il va d'abord vérifier si son adresse figure dans ses tables locales. Si c'est le cas, le paquet est envoyé directement. Dans l'alternative le système essaiera de trouver l'adresse du réseau auquel est destiné le paquet, ou du moins la direction à prendre. Le paquet est alors envoyé au routeur qui semble le plus approprié. Ces tables peuvent devenir rapidement très importantes. Aujourd'hui en effet, Internet rassemble plusieurs centaines de réseaux indépendants. Diverses stratégies ont donc du être développées pour éviter une inflation ingérable de ces tables. Une des stratégies s'appuie sur le principe du "chemin par défaut". Elle consiste à indiquer un routeur unique pour toute sortie du réseau local. Ce routeur peut par exemple raccordé un petit réseau local à une "dorsale" Ethernet. Dans ce cas, nul besoin de définir en interne une entrée pour chaque réseau du monde. Il suffit d'indiquer ce routeur comme "par défaut". Lorsqu'aucun chemin explicite ne peut être trouvé pour un paquet, ce dernier est envoyé à ce routeur. On peut définir un routeur par défaut même dans le cas où plusieurs routeurs sont raccordés au même réseau. Il est possible de configurer une réponse du système du type "Je ne suis pas le routeur le plus approprié - utiliser plutôt celui-ci" (Ce type de message est envoyé sous ICMP. Cf. RFC 792.) De nombreux logiciels réseau utilisent cette technique pour ajouter une entrée à leur tables internes. Supposez que le réseau 128.6.4 a deux routeurs, 128.6.4.59 et 128.6.4.1. 128.6.4.59 fait le pont entre deux réseaux interne de Rutgers. 128.6.4.1 fait un lien direct avec NSFnet. Supposons que le routeur 128.6.4.59 soit spécifié comme le "défaut", et aucune entrée de table n'est précisée. Que se passe t'il lorsque nous devons émettre un paquet vers le MIT? MIT est le réseau 18. Comme aucune entrée n'est trouvée pour le réseau 18, le paquet est envoyé au "défaut", c'est à dire au routeur 128.6.4.59. Ce routeur est évidemment le mauvais. Il réemettra le paquet vers le routeur 128.6.4.1, mais va de plus envoyer une erreur disant à peu près: "pour le réseau 18, utilisez le routeur 128.6.4.1". Notre logiciel réseau ajoute alors cette entrée dans sa table locale. Tout autre paquet à envoyer au MIT passera alors directement par le bon routeur: le 128.6.4.1. (Cette erreur, de type normalisé "ICMP Redirect" utilise le protocole ICMP). La plupart des experts IP conseillent que les petits ordinateurs ne gardent jamais la trace de toutes les adresses du réseau. Au lieu de cela, ils conseillent de s'appuyer sur un routeur par "défaut", et laisser le soin à celui-ci de donner les adresses demandées comme nous l'avons vu précédemment. Cela ne nous dit toujours pas comment le routeur lui-même détermine le chemin à suivre. Les routeurs ne peuvent une fois de plus éluder le problème. Ils doivent donc maintenir des tables relativement complètes. Pour ce faire, un protocole de routage s'avère nécessaire. Un protocole de routage est une technique simple permettant à un routeur d'en retrouver un autre, et se souvenir du chemin le plus efficace pour aboutir à n'importe quel réseau. La RFC 1009 contient une description des principaux design de routeurs et des techniques de routage. Cependant, le fichier rip.doc est probablement la meilleure introduction au sujet. Il contient en effet des exercices, ainsi qu'une description détaillée des protocoles les plus utilisés. 7. Détails à propos des adresses Internet : sous-réseaux et diffusion Comme précisé plus tôt, les adresses Internet sont codées sur 32 bits, écrits couramment comme un nombre de 4 octets (en décimal), ex. 128.6.4.7. Il existe aujourd'hui trois types d'adresses. Le problème est que l'adresse doit désigner à la fois le réseau, et la machine raccordée sur ce réseau. Il avait été pressenti que le nombre de réseaux deviendrait rapidement grand. La plupart d'entre eux seraient de petite taille, mais 24 bits semblaient suffire à la numérotation de tous les réseaux. Il avait été prévu aussi des réseaux de très grande taille, nécessitant 24 bits pour coder toutes les machines raccordées. Tout cela laissait à prévoir un champ d'adresse de 48 bits. Les concepteurs décidèrent de s'en tenir aux 32 bits d'adresse initiaux mais en utilisant une astuce pour résoudre ce problème. Ils supposèrent donc que la grande majorité des réseaux devait être de petite taille, et définirent trois "gammes" d'adresses. Les adresses commençant par un nombre entre 1 et 126 n'utiliseraient que le premier nombre pour coder le réseau. Les trois autres octets définissant le numéro de machine et proposant donc 24 bits de codage pour les très grands réseaux. La seule limite est que seuls 126 réseaux peuvent bénéficier de cette capacité d'adressage interne. ARPAnet en est un, ainsi que quelques réseaux commerciaux. Très peu d'organisations peuvent obtenir une telle adresse dite de classe A. Pour des organisations moyennement grandes, les adresses de classe B sont utilisées. Celles-ci utilisent deux octets pour le réseau, et deux pour la machine. Les réseaux ainsi définis prennent les numéros 128.1 à 191.254. (Nous éliminons d'office les valeurs 0 et 255, pour une raison que nous verrons par la suite. Nous éliminons aussi la valeur 127, qui est réservée à un usage spécial). Les machines restent don codées sur 16 bits, permettant d'accueillir 64516 ordinateurs, ce qui devrait être suffisant pour la plupart des sociétés. (il reste toujours possible de cumuler deux adresses réseaux distinctes pour une seule société, au cas où le nombre d'ordinateurs dépasserait cette limite). Enfin, pour les réseaux plus petits, trois octets sont utilisés, pour des adresses réseau allant de 192.1.1 à 223.254.254, chacun pouvant supporter 254 machines. Les adresses débutant par un nombre supérieur à 223 sont actuellement réservées pour le futur, en prévision de classes D et E (actuellement non encore définies). De nombreuses organisations de grande taille ont trouvé pratique de diviser leur propre champ d'adresse en "sous-réseaux". Par exemple, Rutgers utilise une adresse de classe B, 128.6. Nous avons trouvé judicieux d'utiliser le troisième octet pour indiquer sur quel Ethernet une machine était située. Cette division n'a toutefois pas de signification pour l'extérieur. Un ordinateur émettant un paquet à destination de Rutgers ne connaîtra que l'adresse réseau 128.6. Le troisième octet reste pour celui-ci une adresse "machine". Ces paquets provenant de l'extérieur suivront donc la même "route" (externe) qu'ils soient dirigés vers 128.6.4 ou 128.6.5. Mais à l'intérieur de Rutgers, nous traitons 128.6.4 et 128.6.5 comme deux réseaux séparés. En effet, nos routeurs internes à Rutgers ont des entrées séparées pour chaque sous-réseau interne, tandis que les routeurs externes à Rutgers n'ont qu'une entrée pour l'adresse 128.6. A noter que nous aurions obtenu le même résultat en prenant une adresse de classe C pour chacun de ces deux Ethernet. Tant que cela ne concerne que Rutgers, le fait de disposer d'un certain nombre d'adresses de classe C pour coder nos réseaux n'est ni plus ni moins pratique, vu de l'intérieur. En revanche, pour l'extérieur, cela obligerait les serveurs de domaines externes à maintenir autant d'entrées pour chacun de nos sous-réseaux. Si chaque organisation suivait le même principe, le nombre d'entrées de table dépasserait vite la capacité de mémorisation de la plupart des routeurs. En sous divisant en interne une adresse unique de classe B, nous prenons en charge en interne notre propre architecture, sans préjudice pour le monde extérieur. Cette stratégie de sous-division de réseau nécessite un certain nombre de ressources dans le logiciel réseau. Elles sont décrites dans la RFC 950. 0 et 255 ont des significations particulières. 0 est réservé pour les machines ne connaissant pas leur propre adresse. Dans certaines circonstances, une machine peut ignorer le réseau sur lequel elle est raccordée. Pire, elle peut même ignorer son propre numéro de machine sur ce réseau. Par exemple, 0.0.0.23 serait donné par une machine se savant en 23 ème position, mais pas sur quel réseau. 255 est réservé pour la "diffusion". Un message de diffusion est un message destiné à toutes les machines du réseau. Les messages de diffusion sont utilisés lorsque vous ne savez pas exactement à qui parler. Par exemple, supposons que votre machine ait besoin de récupérer l'adresse Internet correspondant à un nom donné. Il peut arriver qu'elle ne sache pas quel est le serveur de domaines le plus proche. Elle utilise le mode diffusion dans ce cas. Il existe aussi un cas où la même information peut être utile à un grand nombre de machines. Il est dans ce cas plus économique en temps d'émettre un seul paquet en diffusion, plutôt que chaque paquet individuellement à chaque machine concernée. Pour émettre un tel message, vous utiliserez votre adresse réseau propre, en mettant des un pour tous les bits désignant le numéro de machine. Par exemple, si votre machine est sur le réseau 128.6.4, l'adresse de diffusion à utiliser est 128.6.4.255. Comment ceci est implémenté dépend du médium. Il n'est pas possible par exemple d'envoyer un message de diffusion sur ARPAnet, ni sur des lignes point à point. Cela est cependant possible sur un Ethernet. Il suffit que tous les bits d'adresse soient à 1 pour que toutes les machines sur l'Ethernet traitent votre message. Bien que l'adresse officielle de diffusion du réseau 128.6.4 soit 128.6.4.255, il existe d'autres adresses provoquant une diffusion selon l'implémentation. Pour plus de commodité, le standard accepte que l'adresse 255.255.255.255 soit utilisée. Cette adresse particulière adresse le message à toutes les machines du réseau local. Il est souvent plus simple d'utiliser l'adresse 255.255.255.255 plutôt que de recherche l'adresse du réseau local et de constituer l'adresse de diffusion telle que 128.6.4.255. De plus, certaines implémentations anciennes admettent le 0 comme marque de diffusion au lieu de 255. De telles implémentations utiliseraient 128.6.4.0 plutôt que 128.6.4.255 pour l'adresse de diffusion du réseau 128.6.4. Enfin, certaines autres anciennes implémentations ne savent pas travailler avec les notions de sous réseau. Ils reconnaîtront toujours notre réseau comme étant le 128.6. Pour eux, l'adresse de diffusion ne pourra être que 128.6.255.255 ou 128.6.0.0. Jusqu'à ce que l'implémentation de la diffusion soit faite de façon plus rigoureuse, ce mode reste cependant assez dangereux à utiliser. 0 et 255 étant respectivement utilisées pour coder les "adresses inconnues" et "diffusion", des adresses normales de machines ne peuvent en aucun cas présenter l'une de ces deux valeurs dans un champ. Les dresses ne peuvent jamais commencer par 0, 127, ni un nombre au dessus de 223. Les adresses violant cette loi sont appelées "Martiennes", selon la rumeur qui attribue l'adresse 225 au réseau de l'Université de Mars ! 8. Fragmentation et réassemblage des paquets TCP/IP est conçu pour fonctionner sur de nombreux types de réseaux. Malheureusement, les concepteurs de réseau n'ont jamais pu se mettre d'accord sur la taille que devaient avoir les paquets. Les paquets Ethernet peuvent avoir une longueur de jusqu'à 1500 octets. Les paquets ARPAnet au maximum environ 1000 octets. Certains réseaux très rapides (token rings 100 GHz) des paquets beaucoup plus longs. Les réseaux ATM voix-données beaucoup plus courts. En principe, on pourrait penser qu'IP pourrait prendre simplement la taille la plus petite. Malheureusement, cela conduirait souvent à une chute vertigineuse des performances. Pour le transfert de gros fichiers, les paquets longs sont beaucoup plus "rentables" et IP doit pouvoir tout faire pour utiliser les plus grands paquets possibles. Mais il faut aussi tenir compte des réseaux à limite très basse. Il y a actuellement deux possibilités pour se sortir de cette contradiction. D'abord, TCP a la possibilité de "négocier" la taille des paquets. A l'établissement d'une communication TCP, les deux extrémités s'échangent la valeur de la taille maximale que leur réseau d'accueil peut supporter. La valeur la plus faible des deux est alors choisie pour la communication. Ceci permet à deux réseaux puissants de communiquer le plus efficacement possible, mais aussi à un réseau puissant de communiquer avec un réseau moins performant. Cependant, ceci ne solutionne pas entièrement le problème: cette transaction ne tient pas compte des possibilités des chemins intermédiaires. Par exemple, pour l'envoi de données entre Rutgers et Berkeley, les deux réseaux locaux respectifs sont de type Ethernet. La transaction prévoit donc logiquement l'envoi de paquets de 1500 octets. Cependant, cette communication se trouve passer par l'intermédiaire du réseau ARPAnet qui ne peut gérer des paquets de cette taille. Dans ce cas, les paquets originaux Ethernet doivent eux-mêmes être "fragmentés". L'en-tête IP contient un champ permettant d'indiquer que cette fragmentation a eu lieu, ainsi que les informations qui permettent de réassembler correctement ces paquets. Lorsqu'un routeur connecte un Ethernet à ARPAnet, il doit être prêt à découper les 1500 octets du paquet Ethernet en éléments pouvant être transmis via ARPAnet. A l'inverse, TCP/IP doit savoir récupérer ces fragments et les "réassembler" correctement. Les implémentations diverses de TCP/IP diffèrent dans la manière de décider de la taille des paquets à utiliser. Il est assez courant que des paquets de 576 octets soient utilisés "par défaut" lorsqu'il est impossible de déterminer la capacité réelle du chemin de bout en bout. Il s'agit là d'un a priori assez conservateur qui peut conduire à quelques cas de transmissions défectueuses, du fait de ne pouvoir correctement réassembler à l'arrivée. Les développeurs tendent même à ignorer le besoin de fragmentation. Les ingénieurs réseau on eux même différentes approches quant à la décision d'utilisation de paquets longs. Certains ne les réservent qu'au réseau local. D'autres généralisent leur usage au sein de la même organisation. La taille de 576 octets ménage la chèvre et le chou, et est en principe convenable dans toutes les installations. 10. Pour plus d'information Ce chapitre liste les normes principales en matière d'Internet. Les documents sur le sujet se comptent par centaines. Nous avons donc listé ici ceux qui nous paraissent les plus importants. Les standards Internet sont nommés RFC, acronyme de "Request for Comment". Un standard est présenté toujours sur la base d'une "proposition", à laquelle est attribuée un numéro de RFC. Lorsqu'il est accepté, ce standard devient parti intégrante des protocoles officiels de l'Internet, mais garde son appellation RFC. Nous citons aussi une IEN. (IEN code des documents à usage plus interne. Cette classification n'existe plus aujourd'hui -- les RFC sont désormais les seuls documents admis pour la normalisation Internet). L'usage veut que lorsqu'un RFC est revu, un nouveau numéro lui est attribué. Ceci présente un avantage certain, mais un inconvénient majeur pour deux séries de documents: les "Assigned Numbers" et la série des protocoles officiels d'Internet. Ces documents sont en constante évolution, et leur numéro ne cesse de changer. Vous pouvez connaître la dernière édition dans le fichier rfc-index.txt. Quiconque s'intéresse sérieusement à TCP/IP devra lire les RFC décrivant IP (791). Le RFC 1009 est aussi très utile. Il s'agit d'une spécification sur les routeurs pour NSFnet. En tant que tel, il contient de nombreuses informations sur la technologie TCP/IP. Il vous sera utile de lire aussi l'une des définitions de protocoles applicatifs, pour voir l'implémentation concrète de TCP/IP. Celle concernant le courrier (821/822) est certainement une des plus intéressante. TCP (793) est bien sur la spécification de base. Ces spécifications sont cependant assez complexes, et nous vous conseillons de les lire avec suffisamment de temps pour bien les analyser. (NdT : nous ferons tout notre possible pour les clarifier). RFC-index Liste toutes les RFC RFC1012 Liste plus complète encore RFC1011 Official Protocols Utile pour savoir pour quelles tâches les protocoles ont été adoptés. Il détermine quels RFC sont actuellement des standards, plutôt que des propositions. RFC1010 Assigned Numbers Pas vraiment excitant à lire, mais contient une liste exhaustive de tous les sockets réservés et quelques autres informations utiles. RFC1009 NSFnet gateway specifications. Une bonne vue d'ensemble du protocole IP et des "routeurs". RFC1001/2 netBIOS Travail en réseau avec des PC RFC973 update Domaines RFC959 FTP RFC950 Sous réseaux RFC937 POP2 Lecture de courrier sur PC RFC894 Comment implémenter IP sur Ethernet, voir aussi RFC825 RFC882/3 Domaines (descriptif de la base de données de transcription "nom de domaines" <-> "adresses Internet" -- gestion d'UUCP). Voir aussi RFC973 RFC854/5 telnet Ouverture de sessions distantes RFC826 ARP Recherche d'adresses Internet RFC821/2 Mail RFC814 Noms et ports - concepts généraux autour des sockets réservés RFC793 CMP RFC791 IP RFC768 UDP Rip.doc Détails sur le protocole de routage le plus utilisé Ien-48 the Catenet model Description générale de la philosophie soustendant TCP/IP Les documents suivants sont plus spécialisés. RFC813 Fenêtres et stratégies d'accusé de réception dans TCP RFC815 Techniques de réassemblage de paquets RFC816 Techniques de résolution de faute RFC817 Modularité et efficacité des implémentations RFC879 Option de taille maximale de segment dans TCP RFC896 Contrôle de congestion RFC827,888 ,904, 975, 985 EGP et textes associés   C-extra.com © 2003-2005