Cours 4 : Routage
Introduction
Nous allons étudier comment la couche "INTERCONNECTION" délivre des datagrammes (ou informations) à travers des réseaux interconnectés.Nous aborderons la fragmentation de paquets et ces conséquences.
Principe d'un algorithme de routage
Un des protocoles les plus connus est RIP (RIP: ROUTING INFORMATION PROTOCOL) également connu sous le nom d'un programme qui le met en œuvre : routed . Le logiciel routed a été réalisé à l'université de Californie : Berkeley. Il assure un routage cohérent et permet l'échange d'informations d'accessibilité entre machines sur les réseaux locaux de cette université. Il Utilise la diffusion sur le réseau physique pour propager rapidement les informations de routage. Il n'a pas été initialement conçu pour être utilisé sur les réseaux grande distance. Routed s'appuie sur des travaux de recherche antérieurs menés par le centre de recherche de la compagnie Xerox (PARC: Palo Alto Research Center), à Palo Alto. Il met en œuvre un protocole dérivé du protocole d'informations de routage de Xerox (NS) et l'a généralisé à un ensemble de familles de réseau.La popularité de RIP, en dépit de légères améliorations par rapport à ses précurseurs, ne tient pas à ses mérites techniques. Au contraire, elle résulte de la distribution de ce protocole avec les logiciels du célèbre système d'exploitation UNIX 4 BSD Ainsi, de nombreux sites TCP/IP ont adopté et commencé à utiliser routed et RIP, sans en avoir étudié les caractéristiques techniques ni les limitations. Une fois installé et opérationnel, il a constitué la base du routage local et les groupes de recherches l'ont adopté pour des réseaux plus grands.
Le fait le plus surprenant concernant RIP est peut-être d'avoir été mis en œuvre bien avant que la norme (RFC plus exactement) correspondante ne soit spécifiée. La plupart des mises en œuvre sont dérivées du code de Berkeley et l'interfonctionnement de ce protocole est limité par la compréhension des détails et des subtilités non commentés qu'en avaient les programmeurs. Avec l'apparition de nouvelles versions, de nouveaux problèmes se sont posés un RFC est enfin apparue en juin 1988.
Le protocole RIP sous-jacent est une application directe du routage à vecteurs de distance utilisé pour les réseaux locaux. Il classe les participants en machines passives ou actives. Une passerelle active propage les routes qu'elle connaît vers les autres machines; les machines passives écoutent les passerelles et mettent à jour leurs routes en fonction des informations reçues, mais n'en diffusent pas elles-mêmes. Habituellement, les passerelles utilisent RIP en mode actif et les machines l'utilisent en mode passif.
Une passerelle utilisant RIP en mode actif diffuse un message toutes les 30 secondes. Le message contient des informations extraites de ses tables de routage courantes de la passerelle. Chaque message est constitue d'une partie contenant l'adresse IP d'un réseau et un entier mesurant la distance de la passerelle vers ce réseau. RIP utilise une métrique à nombre de sauts (hop count metric) pour mesurer la distance qui la sépare d'une destination. Dans la métrique RIP, une passerelle est située à une distance d'un saut d'un réseau directement accessible, a deux sauts des réseaux accessibles par l'intermédiaire d'une autre passerelle et ainsi de suite. Le nombre de sauts (number of HOP OU hop count metric) mesure donc le nombre de passerelles que doit traverser un datagramme pour atteindre sa destination, sur un chemin reliant une source donnée à une destination donnée. Il doit être clair que l'utilisation du nombre de sauts pour déterminer les plus courts chemins ne conduit pas toujours à une solution optimale. Par exemple, un chemin qui traverse trois réseaux Ethernet et comporte trois sauts peut être nettement plus rapide qu'un chemin qui ne comporte que deux sauts, mais emprunte deux liaisons séries basse vitesse. Pour compenser les différences inhérentes à la technologie, de nombreuses mises en œuvre de RIP utilisent des nombres de sauts artificiellement élevés lorsqu'elles diffusent des informations relatives des réseaux à bas débit.
Partenaires RIP actifs et passifs écoutent tous les messages et mettent à jour leurs tables de routage, conformément à l'algorithme de routage à vecteurs distance décrit précédemment. Ainsi, dans l'interconnexion présentée
RIP définit quelques règles d'amélioration des performances et de la fiabilité. Ainsi, lorsqu'une passerelle apprend d'une autre passerelle l'existence d'une nouvelle route, elle conserve cette dernière jusqu'à ce qu'elle en connaisse une meilleure. Dans notre exemple, si les passerelles G2 et G5 propagent des informations de routage indiquant que le réseau 1 a un coût de 1, les passerelles G3 et G4 créeront une route passant par la première passerelle dont elles auront reçu le message. Nous pouvons le résumer ainsi:
Pour empêcher l'oscillation entre deux ou plusieurs passerelles de même coût
RIP indique que les routes crées doivent être conservées jusqu'à ce qu'une route de coût strictement inférieur apparaisse.
Que se passe-t-il lorsque la passerelle qui a propagé les informations de routage tombe en panne ? RIP indique que tous les récepteurs doivent associer une temporisation aux routes acquises. Lorsqu'une passerelle définit une route dans ses tables, elle lui associe une temporisation et l'active. La temporisation doit être réarmée à chaque fois que la passerelle reçoit un message RIP référençant cette route. La route est invalidée s'il s'écoule 180 secondes sans qu'elle soit de nouveau référencée.
RIP doit prendre en compte trois types d'erreurs causés par l'algorithme sous jacent. D'abord, l'algorithme ne détecte pas les boucles de façon explicite, RIP doit donc supposer que ses partenaires sont fiables ou prendre des précautions pour détecter les boucles. RIP doit ensuite utiliser une petite valeur comme distance maximale possible (RIP utilise la valeur 16) pour éviter les instabilités. Les administrateurs de réseaux doivent utiliser un autre protocole pour les interconnexions dans lesquelles le nombre de sauts avoisine normalement la valeur 16 (de toute évidence, la petitesse de la valeur limite du nombre de sauts de RIP le rend inutilisable dans les grands réseaux).
Troisièmement, l'algorithme de routage à vecteurs de distance utilisé par RIP entraîne une convergence lente (slow convergence) ou un problème de valeur infinie (count to infinity) qui produit des incohérences parce que les messages se propagent lentement à travers le réseau. Le, choix d'une faible valeur infinie (16) limite le phénomène de valeur infinie, sans pour autant l'éviter.
L'incohérence des tables de routage n'est pas spécifique de RIP. C'est un problème fondamental inhérent à tout protocole à vecteurs de distance où les messages ne véhiculent que des paires (réseau destination, distance). Considérons, pour comprendre le problème, l'ensemble de passerelles de la figure suivante :
La passerelle Gl accède directement au réseau 1. Sa table de routage comporte une route à laquelle est associée une distance 1. Cette route fait partie des informations de routage diffusées périodiquement. La passerelle G2 apprend la route de Gl, l'inscrit dans sa table de routage et propage les informations relatives à cette route, en indiquant une distance 2. Enfin, G3 apprend la route de G2 et propage les informations relatives à cette route en indiquant une distance 3.
Supposez maintenant que l'accès de G1 au réseau 1 tombe en panne. G 1 met immédiatement à jour sa table de routage et affecte une distance infinie (16) à 1a route correspondante. Dans la diffusion d'informations suivante, G1 diffuse le coût élevé associé à cette route. A Moins toutefois que le protocole ne comporte des mécanismes supplémentaires pour éviter l'apparition de ce phénomène, une autre passerelle peut, avant G1 propager des informations relatives à cette route. Supposez., en particulier, que G2 diffuse ses informations de routage juste après que l'accès de G1 au réseau 1 est tombé en panne. Dans ce cas, G 1 reçoit des messages de G2 et applique l'algorithme de routage à vecteurs de distance: elle constate que G2 l'informe de l'existence d'une route vers le réseau 1 dont le coût est inférieur au sien et en déduit que le coût d'accès au réseau 1 est de 3 sauts ( 2 sauts pour atteindre le réseau I depuis G2 plus un pour l'atteindre depuis Gl). Gl inscrit donc dans sa table de routage la route qui passe par G 2 pour atteindre le réseau 1.
Les diffusions RIP ultérieures de ces deux passerelles ne résolvent pas rapidement le problème. Au cycle de diffusion d'informations de route suivante, G1 diffuse le contenu de l'entrée de sa table. Lorsque G2 apprend que la route vers le réseau 1 a un coût de 3, elle recalcule le coût associé à cette route, celui-ci prend la valeur 4. au troisième tour, G1 reçoit de G2 des informations qui signalent une augmentation du coût associé à la route vers le réseau 1. Elle augmente donc la valeur dans sa table de routage. Celle-ci vaut maintenant 5. et elles poursuivent ce processus jusqu'à atteindre la valeur infinie de RIP.
Protocoles utilisés pour les grands réseaux
RIP est simple à mettre en place mais ne résout pas tous les problèmes.Deplus vue le nombre de réseaux, les tables de routage RIP peuvent devenir énormes. En plus des informations statiques, généralement on utilise une route par défaut.
Lorsque l'on envoie un datagramme à une passerelle, cette dernière regarde sa table de routage pour voir si elle connaît la prochaine passerelle pour atteindre le réseau. Si oui elle lui remet de datagramme sinon, elle remet ce dernier à une passerelle spécifique qui procédera de même. Généralement, les passerelles RIP connaissent toutes les routes du réseau de l'entreprise et ignorent les routes vers les réseaux extérieures.
Elles transmettent donc tous les datagrammes destinés à l'extérieur à une autre passerelle. Cette passerelle est souvent appelée passerelle extérieurs par opposition à "passerelles intérieures". Les passerelles extérieures vont utiliser d'autres algorithmes tels que SPF(Link-state, Shortest First).
Ce protocole suppose que toutes les passerelles l'utilisant connaissent la topologie de l'ensemble des réseaux qu'elles gèrent.
EGP (Exterior Gateway Protocol) est un protocole qui est souvent mis en œuvre sur des passerelles qui font l'interconnexion de sites avec des réseaux fédérateurs. Le principe d'EGP est simple. Chaque passerelle ne connaît que ces voisins immédiats et met en place une route par défaut sur l'un de ces voisins pour pouvoir router les paquets vers des réseaux qu'elle ne connaît pas.
Toutes ces méthodes permettent donc à IP de trouver un chemin lorsqu'il existe. Cependant il existe aujourd'hui encore des cas qui posent problèmes.
La fragmentation.
Le but d'IP est de trouver un chemin pour envoyer un datagramme. Ce datagramme va circuler de passerelles en passerelles. Ces passerelles sont connectées sur un support physique qui peut avoir des MTU (Maximum Transfert Unit) différent (c'est-à-dire qui échange des trames de longueurs différentes).
Supposons qu'une machine du réseau 1 envoie un datagramme IP de longueur L à destination d'une machine sur le réseau N, alors 5 cas de figures peuvent se présenter:
- 1°) L < min(M1,M2,...Mn)
alors, le datagramme est émis de passerelles en passerelles jusqu'à ce qu'il atteigne sa destination sur le réseau N. - 2°) L > min(M1,M2,...Mn)
alors si le datagramme ne doit pas être fragmenté, un message ICMP d'erreur est émis vers la machine source et le datagramme est détruit par la passerelle qui ne peut pas le faire transiter sur l'autre réseau. - 3°) L > min(M1,M2,Mn)
alors si le datagramme peut être fragmenté, la passerelle qui ne peut émettre directement ce datagramme va le couper en autant de petits datagrammes que nécessaire et émettre tous les fragments sur l'autre réseau.
Lorsque les fragments arrivent sur la passerelle suivante, cette dernière ignore que ce sont des fragments, et les traite comme des datagrammes normaux. - 4°) le datagramme arrive sur une passerelle qui ne peut le traiter faute de ressources suffisantes, alors ce dernier est détruit sans autre forme de procès.
- 5°) le datagramme arrive sur la passerelle Gi qui ne dispose pas d'information pour router ce datagramme, alors elle le détruit et émet un message ICMP qui signale une erreur de routage.
Conclusion
IP envoie des datagrammes de machines à machines.IP garantie qu'il fera tout son possible pour envoyer le datagramme (Best effort).
IP peut détruire un datagramme.
IP ne garantie pas qu'un datagramme émis arrive à l'identique sur l'autre machine. Il peut fragmenter le datagramme et émettre ces fragments sur différents chemins en fonction des tables de routages.
IP n'est pas un protocole fixe, mais est en perpétuel évolution.
IP ne fixe pas seul les routes, il utilise d'autres protocoles (GGP,RIP, …)
Cours 5 : Couche transport et résolution de noms
But
Jusqu'à présent, nous avons vu comment on pouvait envoyer des informations de machines à machines en trouvant les routes .Lorsqu'une information arrive sur une machine, l'information est destinée à un applicatif qui fonctionne sur cette machine.
Le problème est donc d'identifier cet applicatif.
Identification des applicatifs
Un même applicatif peut être vu de façons différentes en fonction du système d'exploitation sur lequel il fonctionne. On pourra parler de programme, de processus, de job, d'application,... Chacun des noms et des identifiants associés à l'apllicatif étant différent en fonction de l'OS.Nommer un applicatif sur une machine distante est donc difficile. De plus, l'identifiant de l'applicatif en fonction des systèmes peut varier avec le temps.
Un applicatif sur une machine peut également rendre des services différents, le problème est dans ce cas de nommer la partie de l'applicatif que l'on veut joindre. Pour ces raisons, nommer directement des applicatifs que l'on veut joindre sur une machine n'est pas une bonne idée. On utilise plutôt des numéros avec une technique de rendez-vous.
Les ports TCP/IP
Un port TCP/IP est un numéro de service. Quel que soit l'OS sur une machine, gérer des numéros, n'est pas difficile à faire. Un port doit être vu comme un lieu de rendez-vous. Le programme serveur, va demander au système d'exploitation de lui donner toutes les informations qui arrivent sur un ou plusieurs ports donnés. Le programme client qui veut dialoguer avec le serveur, doit donc émettre ses données vers un port spécifié sur une machine donnée.Un client n'a donc aucune idée de l'appellation de l'applicatif (programme, job, processus,...).
Le problème pour un client est donc de connaître le numéro de port qui lui permettra de joindre le bon serveur. Sur la machine destinataire, un utilisateur mal intentionné (s'il dispose de privilège suffisant au niveau de l'OS) peut donc détourner des informations qui sont normalement destinées à un serveur particulier.
Affectation des ports
La question pour un client qui veut joindre un serveur spécifique sur une machine est donc de connaître le numéro de port qu'utilise ce serveur sur cette machine. La norme TCP/IP a divisé les ports en 2 catégories :les ports libres et les ports affectés/réservés (Well Know Ports).
Les numéros de ports qui sont entre 0 et 2048 sont affectés et/ou réservés. Ainsi, le client qui veut joindre un serveur pour faire du transfert de fichier doit envoyer sa demande sur le port UDP 69 pour joindre un serveur utilisant le protocole TFTP. Les ports dont le numéro est compris entre 2048 et 65536 sont dits libres. Libre ne signifie pas qu'ils ne sont pas utilisés, mais qu'on ne peut pas connaître les serveurs (s'ils existent) qui vont répondre sur ces ports.
Etablissement d'une communication client serveur
Nous venons de voir comment on peut identifier un serveur sur une machine. Il faut maintenant voir comment un client va échanger ses données avec le serveur.Lorsque qu'un client veut communiquer avec un serveur, il demande à son OS de lui donner un numéro de port. Ainsi, les données partent d'un port d'une machine source vers un port sur une machine destination.
Le numéro de port attribuer au client par le système n'est pas défini. Le système est libre d'attribuer le port qu'il veut.
Protocoles normalisés de la couche transport
UDP
UDP (User Datagramm Protocol) (et non pas Unix Dispense de Penser:-) UDP est un protocole de transport qui est très proche d'IP. UDP permet d'échanger des informations (USER DATAGRAMM) entre des applications. UDP prend le datagramme de l'utilisateur et le transmet à la couche IP. Cette dernière l'achemine sur la machine destinataire pour le remettre au protocole UDP. Ce dernier redonne le datagramme au processus distant. Comme UDP se contente de donner le datagramme à IP et ne fait aucun contrôle, il n'est pas sur que le datagramme arrive à destination, et que s'il y arrive, il n'est pas sur qu'il soit intact. Il peut avoir été fragmenté par les passerelles, les fragments ne seront pas réassemblés par UDP sur la machine du destinataire. Il est possibles que des fragments n'arrivent jamais, ou qu'ils arrivent dans le désordre. C'est aux applicatifs utilisant UDP de faire tous ces contrôles.UDP est très peu sécurisé, il a été écrit et normaliser car il est très simple à mettre en œuvre. Sa simplicité permet de l'utiliser pour télécharger des OS sur des machines. UDP ouvre et referme une connexion pour chaque datagramme.
TCP
TCP (Transport Control Protocol) est un autre protocole de la couche transport de la famille TCP/IP. On dit que TCP est un protocole de bout en bout (END to END). Lorsque deux applicatifs utilisent TCP pour échanger des données, l'émetteur est sur que le récepteur reçoit exactement les données qui sont émises. TCP gère les contrôles. Ce sont les logiciels TCP qui redemande la transmission de paquets lorsque ces derniers ne sont pas arrivés sur le destinataire. Il assure également la remise dans l'ordre des paquets échangés.Si TCP s'appuie sur IP, il tente d'en corriger les défauts.
Le fonctionnement interne de TCP n'est pas trivial. Il procède par acquittement des messages envoyés. Pour optimiser le transfert TCP utilise une fenêtre glissante sur le bloc de données qu'il doit envoyer. La taille de la fenêtre fait l'objet de négociations entre l'émetteur et le récepteur. TCP est dit protocole en mode connecté, car lorsque qu'un canal est ouvert entre un client et un serveur, ce dernier reste valide jusqu'à sa fermeture (qui doit être demandé par au moins l'un des deux applicatifs). Le numéro de port affecté au client par son OS est donc réservé durant toute la connexion TCP, que l'applicatif envoie ou non des informations.
Tout comme UDP, pour identifier un service sur la machine distante TCP utilise des ports.
La résolution de noms
Maintenant, nous savons comment un applicatif client et un applicatif serveur échange des informations.Ils utilisent via les protocoles TCP ou UDP des numéros de port pour différencier les différents services et des adresses IP pour identifier la machine.
Si ces informations numériques sont très pratiques à traiter par des machines elles le sont moins par des hommes.
TCP/IP ne donne pas de méthode pour associer un nom à un numéro de port. Cependant beaucoup de systèmes permettent de le faire (fonction getservbyname par exemple). La correspondance entre un nom de machine et une adresse IP est maintenant bien normalisée, elle a d'ailleurs donné lieu à des protocoles qui utilisent le DNS. Lorsque l'on parle de résolution de nom on entend généralement par-là, la relation entre un nom de machine (hostname) et son adresse IP. Pour que ce système fonctionne, il faut impérativement qu'il y ait au plus une adresse IP qui corresponde au nom d'une machine.
Historique de la gestion des hostnames
A l'origine de TCP/IP très peu de machines étaient connectées. Les administrateurs de ces machines géraient des tables de conversion manuelle. Ces tables étaient souvent des fichiers ASCII que l'on utilise encore (voir fichier /etc/hosts sous Unix). Le format de ce fichier est relativement simple:
"une adresse " "un nom de machine" "alias" "autre alias" ....
exemple :
- 194.57.186.2 enterprise u6065
- 194.57.186.3 eisti voyager www mail
- ...
Le DNS
Le système de nom de domaine est un système de noms hiérarchisés par opposition à un système de noms à plats.
Ce schéma représente une partie de l'arborescence du DNS.
Le nom qualifié ou complet (FQDN) d'une machine se lit en partant de la feuille et en remontant dans l'arbre. Chaque niveau est séparé par un "." Ainsi la machine sur laquelle vous avez programmé s'appelle hardy.eisti.fr. Le domaine racine n'a pas de nom et par convention est appelé ".". Chaque niveau de l'arborescence garantie que les noms de ces fils sont uniques. La machine qui s'appelle hardy.eisti.fr. est donc différente d'une machine qui pourrait s'appeler hardy.fit.edu. Un nom de domaine est constitué par une suite de noms séparés par des points. Le système DNS ne fait pas de différence dans sa notation entre une machine (hardy.eisti.fr. ) et un domaine (eisti.fr.). Pour chaque domaine et sous domaine (., com., edu, ..., fr, ..., fit.edu, eisti.fr, ibp.fr,..) un responsable est désigné. C'est à ce responsable d'assurer l'unicité des noms du domaine qu'il gère. Ce système est distribué, car à aucun endroit de l'Internet il existe une base de données complète du système de nom.Lorsqu'un applicatif veut connaître l'adresse IP d'une machine, il doit demander au résolveur (appelé par la fonction C gethostbyname) de lui la donner.
Le fonctionnement du résolveur est très simple. Il est basé sur le modèle client serveur. Dans chaque domaine, il y a une (ou plusieurs) machine qui connaît l'adresse de toutes les machines de son domaine et les adresses des serveurs de ses sous-domaines. Ainsi lorsque le résolveur doit trouver le nom d'une machine (A.B.C.D), il commence par demander au serveur de la zone (ou domaine) . l'adresse de la machine A.B.C.D.. Si le serveur de la zone "." ne connaît pas directement l'adresse, il pourra donner au résolveur l'adresse du serveur de la zone D.
Ce dernier pourra répondre ou donner l'adresse du serveur de la zone C.D. ainsi de suite jusqu'à ce que le résolveur est obtenu l'adresse de la machine A.B.C.D.
Le système DNS est donc un système qui garantie l'unicité des noms sur le réseau Internet. Ce système ne fait pas que la résolution des noms, il peut contenir d'autres informations. Il peut par exemple donner le nom de la machine qui a pour adresse 194.57.186.17 ou donner le nom de la machine qui gère le mail d'un domaine,...
Le niveau principal de la hiérarchie du DNS n'a pas été choisi au hasard. Le découpage est normalement géographique. Chaque pays est représenté par son code de pays normalisé ISO (fr, uk, sp, us). A ceci s'ajoute quelques exceptions. Le domaine arpa où l'on a regroupé les machines qui disposaient de noms avant la mise en place du DNS.
Le domaine us existe mais aux USA, il est possible de faire enregistrer un domaine en fonction du secteur d'activité de l'établissement.
- Com pour les entreprises commerciales (dénomination internationale maintenant)
- Edu pour l'éducation
- Gov pour les institutions gouvernementales
- Mil pour les militaires
- Org pour les institutions non gouvernementales
Un sous-domaine (ou machine) peut se faire enregistrer dans plusieurs domaines.