PROTOCOLES DU DOD (TCP/IP)

Transcription

1 Chapitre 5 PROTOCOLES DU DOD (TCP/IP) 5.1 INTRODUCTION Au début des années 70, l'advanced Research Project Agency (ARPA) du département de la défense américain (DOD) a fait développer un ensemble de programmes capables d'interconnecter des ordinateurs en réseau. Le produit qui en est résulté est devenu ARPAnet qui a été une référence de base pour les travaux ultérieurs dans le domaine de la téléinformatique et en particulier pour la dénition des diverses normes. Les protocoles dénis pour ARPAnet ont été utilisés également par la suite pour transmettre des données à travers des réseaux locaux interconnectés. Ces normes sont connues sous le nom de TCP/IP, du nom des principaux modules de cet ensemble. C'est ce protocole qui a été déni comme base d'internet sur lequel a été construit le World Wide Web. En plus de ces modules et des modules mentionnés ci-dessous, ARPAnet possède un protocole de mise à jour des tables de routage. Le contenu de ce chapitre ne saurait sure pour entreprendre le développement des protocoles du DOD, mais il devrait permettre de comprendre les documents qui les décrivent et d'avoir un exemple de protocole complet traitant les problèmes des 7 couches du modèle OSI. Ce chapitre présente également une architecture logicielle qui permet de réaliser ces protocoles de façon systématique. Les principaux modules utilisés dans les réseaux locaux sont les suivants : IP, Internet Protocol Ce module décrit comment sont construits les datagrammes (= blocs de données) qui peuvent être acheminés à travers plusieurs réseaux (locaux ou à longues distances), éventuellement hétérogènes. Ce protocole ne gère pas de circuits, deux blocs appartenant à la transmission du même chier sont acheminés de façon indépendante et peuvent même parvenir à destination par des chemins diérents. Il inclut donc les adresses complètes des destinations dans chaque bloc. ARP, Address Resolution Protocol Ce protocole permet de trouver l'adresse physique d'une station sur un réseau local lorsque l'on ne connaît 53

2 que son adresse IP. L'ARP est utilisable lorsqu'un groupe de stations sont connectées sur un milieu de transmission homogène (câble passant par toutes les stations) qui est tel que chaque message inonde tout le milieu de transmission, ce qui n'est pas le cas par exemple lorsque l'on se connecte à Internet au moyen d'une ligne téléphonique. UDP, User Datagram Protocol Ce protocole permet d'envoyer des blocs de données indépendants les uns des autres. Il est très peu diérent de IP. TCP, Transmission Control Protocol Ce module correspond à la couche de transport du modèle OSI. Il s'appuie sur les datagrammes transmis par le module IP pour créer des connexions. Il est donc responsable du contrôle de ux, de la réémission des blocs perdus et de l'acheminement à un programme donné. TELNET, Telecommunications Network Ce module est principalement destiné à connecter des terminaux à des processus d'application. Il utilise TCP. Il permet de négocier un écho des caractères et de dénir quelle est l'extrémité de connexion qui s'en charge. Il dénit également la façon de coder les commandes d'eacements de caractères et de lignes ainsi que les interruptions de l'usager destinées à terminer prématurément un programme en cours. FTP, File Transfer Protocol Ce module assure la gestion de chiers à distance : création, copie, effacement, changement de répertoire, etc... Dans chaque site dont les chiers doivent pouvoir être manipulés, on crée un serveur qui attend les ordres FTP en provenance du réseau et y répond. Pour diérencier les commandes des données, FTP utilise 2 canaux TCP distincts. 5.2 IP : INTERNET PROTOCOL Généralités Le protocole IP assure la transmission et le routage de paquets à travers un réseau (local ou étendu) ou un groupe de réseaux interconnectés. Les noeuds intermédiaires acheminent ces paquets de proche en proche en se référant aux adresses situées dans les en-têtes des paquets et à leurs propres tables de routage. Le protocole IP traite les paquets indépendamment les uns des autres. Il ne crée ni connexion ni circuit virtuel. Il ne possède aucun mécanisme qui garantisse l'intégrité des données ou le séquencement correct des paquets. Il n'eectue pas de contrôle de ux. Ces fonctions sont laissées aux autres couches : erreurs : la couche physique (par exemple Ethernet) sur laquelle IP s'appuie ajoute des codes de détection d'erreurs et ignore tous les paquets dans lesquels des erreurs de transmission dues à des parasites sont détectées. La couche TCP en ajoute également un. Il est possible d'ajouter un code détectant les erreurs dans l'en-tête. connexion, contrôle de ux : ces fonctions sont prises en charge par la couche supérieure (TCP) 54

3 Station Passerelle Station couche supérieure routage couche supérieure IP IP IP IP Réseau Réseau Fig. 5.1 Routage par le protocole IP Modèle du protocole IP Le fonctionnement de IP est basé sur le modèle décrit sur la gure 5.1, la structure de ses blocs est décrite sur la gure 5.2 Lorsque la couche supérieure doit envoyer un datagramme à un correspondant situé dans le même ordinateur ou dans un autre, elle appelle la procédure d'émission de la couche IP et lui fournit un bloc de données, l'adresse du correspondant et une série de paramètres décrits plus loin. La couche IP détermine au moyen d'une table si le correspondant est dans le même ordinateur, s'il est directement atteignable ou s'il faut passer par une passerelle intermédiaire. Elle forme un bloc avec les données et l'en-tête IP (g. 5.2 et??). Ce bloc est envoyé à l'ordinateur qui contient le correspondant ou à la passerelle intermédiaire. Pour cela il faut, dans le cas d'un réseau à longue distance, sélectionner la bonne ligne de transmission et dans celui d'un réseau local, déterminer la bonne adresse physique sur le réseau local. Lorsqu'un ordinateur reçoit un paquet, il détermine si celui-ci est destiné à un processus interne ou s'il faut le passer encore plus loin sur un autre réseau. Le paquet est ainsi acheminé de proche en proche jusqu'au destinataire. Chaque paquet doit comprendre toute l'information nécessaire au routage, ce qui implique qu'il ait un en-tête plus grand que des paquets qui suivraient un circuit virtuel pré-établi et qui pourraient réutiliser les mêmes numéros après fermeture d'un circuit. En-tête niveau physique En-tête IP Données de la couche supérieure Fig. 5.2 Structure des blocs IP 55

4 Classe a 0 Réseau Adresse locale Classe b 1 0 Réseau Adresse locale Classe c Réseau Adresse loc. Adressage étendu Adresse indéfinie Fig. 5.3 Adresses IP Module de gestion des erreurs Ce module, appelé ICMP (pour Internet Control Message Protocol) reçoit les messages indiquant des erreurs de paramètre ou de protocole et les traite. Il fait partie de la couche IP. Les blocs adressés à ICMP ont un code de protocole réservé (01, 9ème champ de la gure??). Les erreurs qui peuvent être traitées sont, par exemple, des paramètres invalides dans un message ou des ressources insusantes qui forcent un routeur à perdre des paquets Routage Tout ce qu'on demande des passerelles qui interconnectent les réseaux c'est de comprendre les adresses IP et de passer les paquets sur des réseaux qui rapprochent les paquets de leur destination. On tolère que IP n'achemine pas tous les paquets qui ont la même adresse par le même chemin. En d'autres termes, les couches supérieures doivent être construites de façon telle qu'elles ne reposent pas sur l'hypothèse d'une transmission séquentielle des paquets et qu'elles prennent des dispositions pour remettre les paquets dans l'ordre, si nécessaire. En principe les passerelles pratiquent un routage adaptatif. Elles connaissent la structure globale du réseau et acheminent les paquets "au mieux", c'est-à-dire sans contrôle par acquittement par exemple. Une adresse contient 32 bits découpés selon 4 formes diérentes (Fig. 5.3). La première partie de l'adresse identie le réseau, avec l'idée initiale qu'il y ait dans le monde entier une adresse distincte pour chaque réseau, de façon ce qu'il n'y ait jamais de risque d'ambiguïté dans le routage des messages lorsque l'on réunit plusieurs réseaux. La deuxième partie de l'adresse correspond aux adresses des stations sur les réseaux. Ces dernière années, on a cru arriver au bout des adresses IP, et une nouvelle version d'ip (IP version 6) a été standardisée. Cependant un nouveau découpage des adresses, plus n que celui de la gure 5.3 a permis de les économiser et l'arrivée de la nouvelle version est sans cesse repoussée. 56

5 VERSION IHL TYPE DE SERVICE LONGUEUR TOTALE IDENTIFICATION F FRAGMENT TTL PROTOCOLE CHECKSUM EN-TETE ADRESSE DE LA SOURCE ADRESSE DE LA DESTINATION OPTIONS BOURRAGE Fig. 5.4 En-tête IP Routage lâche et routage strict IP comprend une option qui permet d'inscrire, dans un datagramme, une liste de passerelles à franchir pour passer d'un expéditeur à un destinataire donnés. Le routage eectué selon cette méthode peut être strict ou lâche suivant que l'expéditeur exige que le datagramme passe par toutes les passerelles de la liste mais seulement celles-ci ou qu'il tolère qu'un certain nombre d'autres passerelles intermédiaires soient visitées. Une autre option permet d'enregistrer la liste des passerelles traversées dans un datagramme traversant plusieurs passerelles. Pour cela, une marque dans le datagramme indique au programme IP de placer l'adresse de la passerelle chaque fois que le datagramme passe par une passerelle, à la suite des adresses déjà récoltées. La liste obtenue en inversant la liste récoltée, permet de renvoyer un datagramme vers la source, en suivant le même chemin qu'à l'aller, par exemple pour des besoins de tests ou de diagnostics. La taille du bloc doit être susante pour contenir toutes les adresses car il n'est pas rallongé en cours de route Fragmentation des datagrammes Le protocole IP étant construit pour acheminer des datagrammes à travers des réseaux hétérogènes, il peut arriver qu'à cause des limitations de la taille des blocs sur un réseau intermédiaire il faille découper un datagramme en fragments pour l'acheminer plus loin. Les en-têtes possèdent des champs qui permettent d'indiquer si les blocs qui arrivent sont des fragments ou des datagrammes complets. Dans l'en-tête de chaque fragment, on trouve la position du premier byte de ce fragment dans le datagramme complet. Ceci permet de reconstruire les datagrammes même si l'ordre des fragments n'est pas conservé et de refragmenter les fragments s'ils doivent traverser un réseau imposant des tailles encore inférieures Paramètres prévus par IP Les paramètres prévus dans l'en-tête IP sont présentés ci-dessous, dans l'ordre de leur placement (Fig.??) Version : 4 bits sont réservés pour le numéro de version. La présente est la version 4. La version 6 est dénie, mais utilisée principalement pour des 57

6 tests. IHL : Internet header length. Ce champ de 4 bits contient la taille de l'entête du datagramme en multiple de 4 octets. Le nombre minimum de quadruplets est 5. TDS : Type de service. Ce paramètre indique les exigences de transmission du datagramme au sujet de la vitesse et de la abilité. Un exemple d'un service qui demande un délai minimum, même au prix d'une abilité moindre, est donné par les communications vocales. Les 8 bits du champ TDS sont utilisés comme suit : Priorité D T R 0 0 Priorité : : Contrôle du réseau : Contrôle inter-réseau : Standard Délai (D) 0 : normal 1 : inférieur Débit(T) 0 : normal 1 : supérieur Fiabilité(R) 0 : normal 1 : supérieur Ces trois derniers bits indiquent quelles sont les qualités à favoriser dans le compromis délai-débit-abilité. Il ne faut évidemment pas demander les trois qualités à la fois. Chaque passerelle doit traiter ces indications "au mieux", c'est-à-dire que ce traitement est laissé à l'appréciation du réalisateur du système. Si les délais sont facilement traités en organisant des queues de priorité, il n'en est pas forcément de même pour les autres exigences... Longueur totale : La longueur totale, variant de 20 à , indique la taille totale du datagramme, mesurée en octets. Identication : Ce paramètre identie de façon univoque les datagrammes qui proviennent de la même source. Ceci permet de reconstruire les datagrammes fragmentés (voir ci-dessous). F (Fanions) : Ces fanions, situés dans les 3 bits supérieurs, permettent de gérer la fragmentation des paquets. Bit (plus signicatif) : toujours Bit 1 : peut être fragmenté Bit 2 : 1 ne doit pas être fragmenté dernier fragment 1 autre fragment Les passerelles ont l'interdiction de fragmenter les datagrammes dont le bit 1 vaut 1. Ceci est destiné à des applications qui, pour des raisons quelconques, ne peuvent pas réassembler les fragments. Au cas où une station ne peut transmettre un datagramme sans le fragmenter et qu'il possède le fanion interdisant la fragmentation, elle doit renvoyer un message rapportant le problème à l'icmp de l'émetteur. En envoyant des datagrammes 58

7 de grandeurs croissantes, avec ce bit à 1, jusqu'à ce qu'on reçoive une indication d'erreur, on peut donc trouver la plus grande longueur de datagramme qui peut être envoyée à un partenaire. Placement du fragment : Indication du placement du fragment par la position du premier octet de ce fragment à l'intérieur du datagramme complet. Le premier fragment d'un datagramme ainsi qu'un datagramme complet a ce paramètre égal à. Le bit "dernier fragment" permet de savoir quand le datagramme est complet. TTL : (Time To Live) Durée de vie maximale prévue pour le datagramme. Ce paramètre doit être décrémenté à chaque passage dans une passerelle et s'il vient à s'annuler, le datagramme qui le porte doit être éliminé. Ceci est destiné à empêcher que des datagrammes ne circulent indéniment dans des boucles à cause de problèmes de routage par exemple. Protocole : Ce code indique à quel protocole le datagramme appartient. 0 IP : Internet Protocol 1 ICMP : Internet Control Message Protocol 6 TCP : Transmission Control Protocol 17 UDP : User Datagram Protocol Checksum de l'en-tête : ce paramètre contient le complément à 1 de la somme modulo (2 16-1) des octets de l'en-tête. Il permet de détecter des erreurs de transmission dans l'en-tête, mais non dans les données, de façon à pouvoir accepter des données même si elles sont entachées d'erreurs (transmission de voix, etc). Dans les cas usuels, le protocole s'en remet à la couche inférieure (Ethernet...) ou supérieure pour la vérication de l'intégrité des données. Adresses de source et de destination : Ces champs contiennent les adresses de la source et de la destination, codées selon la gure 5.3. Options : Ces options décrivent à quoi le datagramme sert : données, contrôle, test.... Dans le cas normal, ce champ est absent. Quant il est déni (au moyen du champ IHL), il contient un octet indiquant le type de l'option, suivi éventuellement par un octet de longueur et par la valeur du paramètre selon le format ci-dessous. octet 0 octet 1 octet 2 à (N+1) FC Classe Numéro N Valeurs FC : fanion de copie Classe : 00 : contrôle 10 : déverminage et mesure Numéro : 0 : fanion de n 1 : sans eet 2 : sécurité, utilisé par le DoD pour marquer les documents secrets. 3 : routage lâche 9 : routage strict 7 : enregistrement de la route 8 : identicateur de stream" 4 : récolte des instants de passages dans les passerelles. Valeurs : données correspondant aux paramètres Bourrage : 8 à 24 bits nuls pour compléter le dernier quadruplet. 59

8 5.3 UDP : USER DATAGRAM PROTOCOL Le protocole UDP (user datagram protocole) permet d'envoyer un bloc de données d'un programme à un autre. Ce protocole est une extension très simple de IP. Il ne réémet pas non plus les blocs en cas d'erreurs. Il a été déni pour qu'on puisse construire son propre protocole au niveau d'une application. Pour que plusieurs applications exécutées dans le même ordinateur puissent s'échanger de tels blocs, les blocs IP sont complétés par un en-tête minimal, indiqué ci-dessous. 0 En-tête IP 31 Port source Port destination Longueur checksum données Chacun des 4 champs a une longueur de 2 octets Le port destination est utilisé par le système d'exploitation pour envoyer le bloc à l'application qui a indiqué qu'elle était prête à les recevoir. Le port source est optionnel. Il représente, s'il est diérent de zéro, le port sur lequel il faut envoyer la réponse pour que l'émetteur la reçoive. La longueur inclut le nombre d'octets d'en-tête plus celui des données. Le checksum" permet de détecter des erreurs de transmission. 5.4 ARP : PROTOCOLE DE RESOLUTION D'ADRESSE Ce protocole a été déni après TCP/IP et il est utilisable par d'autres protocoles aussi. Il est utilisé sur les réseaux locaux d'ordinateurs (chapitre 6) pour découvrir où se trouve une station possédant une adresse IP donnée. En eet aucun matériel n'utilise directement les adresses IP car il ne peut que rarement y avoir correspondance directe entre le code d'adresse physique (celle qui est reconnue par l'interface électronique) et l'adresse IP, ces deux types d'adresses possédant toujours un nombre diérent de bits, des sous-champs délimités différemment, etc... Pour retrouver un destinataire par son adresse IP, il faut diuser (broadcast) cette dernière à toutes les stations du réseau local (g Ceci suppose évidemment que le réseau qu'on doit utiliser possède un procédé de diusion. Le paquet diusé contient un en-tête indiquant qu'il s'agit d'une recherche d'adresse IP, l'adresse physique et l'adresse IP du diuseur ainsi que l'adresse IP recherchée. Les stations IP qui reçoivent cet appel testent si c'est leur propre numéro qui est recherché. La station qui reconnaît son adresse répond en retournant le bloc après y avoir ajouté sa propre adresse physique. Les passerelles participent à cette diusion et en protent pour mettre à jour leur propre table de routage et y insérer les adresses IP et physiques des stations diusantes. Quand une passerelle reçoit un bloc ARP contenant une adresse qu'elle sait transmettre en direction de la destination, elle répond en donnant sa propre adresse physique. La station qui a émis le bloc lui envoie donc ses blocs IP sans 60

9 Fig. 5.5 Requête ARP pour déterminer une adresse physique qu'elle ait besoin de savoir s'il s'agit de la passerelle ou de la station destinataire. La gure 5.5 montre un bloc lancé par la station IPa, physa pour découvrir l'adresse physique de IP2. Le bloc ARP a la structure suivante : hdr : Identication du type de matériel (16 bits), 1 pour Ethernet, 3 pour AppleTalk, (Notons que le code indiqué correspond forcément au matériel supporté par l'interface, sinon celui-ci n'aurait pas pu le lire!) pro : Identication du protocole (16 bits) 0800 pour IP hln : Longueur de l'adresse physique (8 bits) pln : Longueur de l'adresse logique (IP) (8 bits) op : Code de la commande (16 bits), 1 pour une requête, 2 pour une réponse sha : Adresse physique de l'émetteur de ce paquet (hln octets) spa : Adresse logique de l'émetteur de ce paquet (pln octets) tha : Adresse physique du destinataire (hln octets) tpa : Adresse logique du destinataire (pln octets). L'adresse logique correspond à l'adresse sous laquelle la station considérée est vue par le protocole de type "pro". A l'émission, l'adresse physique du destinataire n'étant pas connue, elle est mise à 0. Pour que la source du message soit toujours en première position, il faut échanger les champs des adresses physiques et logiques de l'appelant et de l'appelé avant de retourner le bloc. 5.5 TCP : PROTOCOLE DE TRANSPORT Le protocole TCP est le protocole de base d'internet. C'est lui qui garantit que les données perdues dans les routeurs surchargés ou transmises dans un ordre diérent de leur émission, parce qu'elles n'ont pas pris le même chemin pour arriver à destination, arrivent nalement correctement à l'utilisateur. Ce protocole établit des connexions entre programmes, qu'on peut s'imaginer comme des tuyaux sans pertes, sans duplication et sans désordre, alors même que la sortie du tuyau est contrôlée par un robinet qui s'ouvre et se ferme de temps en temps. 61

10 L'extrémité du tuyau est située dans le système d'exploitation. On l'appelle socket lorsqu'on la considère depuis un programme. Vue du réseau, elle est identiée par son port, doté d'un numéro unique dans l'ordinateur. Les données sont emballées dans des datagrammes IP qui circulent sur le réseau. Chaque émetteur met dans chacun de ces datagrammes une adresse IP. Lorsqu'un datagramme est reçu par le destinataire, les bytes qu'il transporte sont déversés dans un tampon identié par le numéro de port, d'où ils seront lus par le programme. TCP réalise le réglage de bout en bout (end to end control) en traitant les aspects suivants : échange de paramètres à l'ouverture d'une connexion (taille des tampons...) récupération des erreurs par retransmission des blocs entachés d'erreurs réglage du ux entre les usagers au moyen d'un protocole à fenêtre glissante et à taille variable ; les numéros de séquence comptent les caractères, non les blocs identication des usagers dans une station (gestion de ports) et multiplexage des connexions sur la couche IP remise des données dans l'ordre Connexions multiples sur un numéro de port Il peut arriver que plusieurs applications doivent se connecter à un même serveur ou plutôt à des instanciations diérentes d'un même serveur. Par exemple tous les usagers externes qui veulent se connecter sur une entrée de terminal (Telnet) s'adressent au port 23 xé une fois pour toutes à cette valeur. Il faut donc trier les blocs qui arrivent sur ce port en fonction de leur provenance et ceci pour des applications distantes situées dans un même ordinateur ou dans des ordinateurs diérents. Deux appelants partant du même ordinateur doivent donc utiliser des numéros de port source diérents. La gure 5.6 décrit les identités de 3 connexions arrivant sur le même port. Comme chaque bloc de données contient les adresses IP de la source et de la destination et les numéros de port de la source et de la destination, tous les blocs sont ainsi parfaitement identiés Format des blocs Avant de détailler le protocole, voyons le format des blocs. Les blocs d'ouverture, de transmission de données et de fermeture de connexion ont tous la même forme. On peut donc très bien recevoir des données dans le bloc communiquant la demande d'ouverture d'un partenaire. Ce format est déni à la gure 5.7. Les champs s'expliquent d'eux-mêmes, à part le groupe de fanions, décrits ci-dessous, qui précisent quels sont les champs valides dans ce même bloc, et le "pointeur urgent" qui est lui décrit au paragraphe La fenêtre indique combien d'octets le récepteur admet après le numéro de séquence indiqué à la dernière ligne. Les fanions sont les suivants : ACK Le numéro d'acquittement situé dans le champ d'acquittement est valide 62

11 Serveur Telnet port 12 adresse physique 50 port 12 port 13 connexion 75,13 48,23 connexion 75,13 48,23 connexion 75,13 48,23 port 23 adresse physique 48 adresse physique 75 Fig. 5.6 Trois connexions sur un port PORT SOURCE PORT DESTINATION NUMERO DE SEQUENCE NUMERO D ACQUITTEMENT LONGUEUR U A R P S F EN-TETE RESERVE R C S S Y I FENETRE G K T H N N CHECKSUM DE L ENTETE POINTEUR URGENT OPTIONS DONNEES Fig. 5.7 En-tête TCP PSH Cette indication est positive si la couche supérieure a provoqué l'envoi du dernier bloc (voir Ÿ5.5.4). Elle n'est pas reçue par le programme destinataire. RST Demande la libération de la connexion SYN Le bloc transporte une ouverture de connexion. Le premier octet de données envoyé aura le numéro qui suit le numéro de séquence indiqué dans ce bloc. FIN Demande de fermeture de la connexion. S'il n'y a pas de données dans le même datagramme, le numéro attribué à l'ordre FIN est celui qui est indiqué dans le champ des numéros de séquence. S'il y en a, l'ordre reçoit comme numéro de séquence, le numéro qui suit le dernier octet du datagramme. Remarque : Syn et Fin ont donc leur propre numéro de séquence pointant juste avant, respectivement juste après les données. 63

12 ouverture active ouverture passive (SYN, SEQ=200) (SYN, SEQ=200, ACK=201) confirmation (ACK=551) confirmation Fig. 5.8 Echanges nécessaires à l'ouverture de TCP Ouverture, transfert des données et fermeture de TCP L'ouverture d'une connexion TCP est eectuée par trois échanges de messages (s'il n'y a pas d'erreurs de transmission). La gure 5.8 illustre les échanges sous une forme condensée. Le but de ces échanges est qu'on ait un transport des numéros de séquence initiaux (indiqués par le fanion SYN) de A vers B et de B vers A et qu'ils soient les deux acquittés, car les séquences ne commencent pas à 0 pour les raisons indiquées ci-dessous. Le message intermédiaire transporte à la fois le numéro initial et l'acquittement du message provenant de A. La fermeture est faite de la même façon, mais en remplaçant SYN par FIN. FIN recevant un numéro de séquence qui suit directement celui du dernier numéro de séquence, on est sûr que lorsque FIN est acquitté, le dernier caractère a été reçu lui aussi. Cela suppose que FIN soit acquitté dans le même ordre que les caractères. Les caractères sont transmis et acquittés au moyen d'un algorithme à fenêtre coulissante de taille variable (voir Ÿ4.2). La fenêtre indique le nombre de caractères qu'on peut envoyer en avance, avant d'avoir reçu un acquittement. Le numéro de séquence du dernier caractère pouvant être envoyé est égal à la somme du numéro d'acquittement et de la valeur déposée dans le champ de fenêtre dans les datagrammes reçus. Une fenêtre nulle indique donc qu'on ne peut momentanément plus recevoir de données. Il peut arriver qu'on utilise plusieurs fois de suite une connexion TCP entre les deux mêmes usagers, avec les mêmes ports. Par exemple pour transmettre plusieurs chiers. Si la connexion est chaque fois fermée et rouverte avec les mêmes numéros de séquence, il se pourrait très bien que des blocs de données d'une ancienne connexion soient acceptés dans la nouvelle connexion parce qu'ils ont été retardés par un chemin congestionné et qu'ils arrivent au moment où la nouvelle connexion est ouverte. Car comme on l'a vu, tous les blocs ne suivent 64

13 ACTIVE OPEN OR ACTIVE OPEN WITH DATA INIT SV. SEND SYN CLOSED UNSPECIFIED PASSIVE OPEN OR FULLY SPECIFIED PASSIVE OPEN INIT SV. CLOSE CLEAR SV CLOSE CLEAR SV SYN SENT RECV SYN SEND SYN ACK SYN RCVD RECV SYN SEND SYN ACK LISTEN RECV SYN ACK OF SYN SEND ACK ESTAB RECV FIN ACK OF SYN SEND ACK CLOSE SEND FIN RECV FIN CLEAR SV FIN WAIT CLOSE WAIT RECV ACK OF FIN RECV FIN SEND ACK CLOSE SEND FIN FIN WAIT 2 CLOSING LAST ACK RECV FIN SEND ACK RECV FIN ACK OF SYN SEND ACK RECV FIN ACK RECV ACK OF FIN TIME WAIT CLOSED Fig. 5.9 Automate TCP pas le même chemin et il est possible que dans l'ancienne connexion un bloc ait été considéré comme perdu et donc réenvoyé alors qu'il n'était que temporairement bloqué dans une passerelle congestionnée. Il y a deux moyens d'éviter ces accidents. Le premier est d'attendre un certain temps (2 minutes propose la norme) avant de réutiliser une connexion entre des ports identiques (mêmes usagers avec les mêmes ports). La deuxième est de continuer les numéros de séquences pour la connexion suivante. Ceci est possible, puisque les numéros de séquence initiaux sont communiqués au destinataire à l'ouverture (bloc SYN). Cependant comme la station peut être déclenchée entre les utilisations des deux connexions elle peut perdre ces numéros. Si la connexion est gelée pendant un certain temps et qu'on veuille établir des connexions entre deux stations sans attendre ce délai, il faut changer chaque fois de numéro de port. Heureusement il y en a susamment Formation des paquets La couche TCP transmet les données sous une forme qui se rapproche le plus possible d'un ux continu d'octets. L'utilisateur de TCP lui fournit des 65

14 groupes d'octets. TCP rassemble ces groupes ou les répartit à son gré dans les datagrammes. Le destinataire n'a pas connaissance des limites initiales des paquets. TCP peut décider d'envoyer un datagramme en fonction des critères suivants : Le datagramme est plein L'utilisateur a émis l'ordre push" L'utilisateur a émis des données marquées urgentes. Si l'utilisateur refournit des données avant que les précédentes n'aient pu être émises, elles sont ajoutées au datagramme encore en mémoire Données urgentes TCP fournit un mécanisme spécial traitant les données urgentes. L'utilisateur peut l'employer comme il l'entend, mais l'exemple suivant permettra de comprendre comment cela fonctionne. Cet exemple est celui de la purge des données d'une connexion. Si pour une raison ou une autre les données déjà injectées dans la connexion ne sont plus valables, l'émetteur envoie une marque prédéterminée en mode urgent. C'est-à-dire que le fanion urgent est enclenché dans les datagrammes, la position des dernières données urgentes est notée dans le champ correspondant et les datagrammes sont envoyés au plus vite". S'il y a plusieurs datagrammes en attente de transmission, le premier à partir, ou les acquittements si le récepteur a annoncé une fenêtre nulle, transmettra cette indication à l'autre extrémité. L'application du côté du récepteur a comme consigne de pomper et de jeter les données chaque fois qu'il détecte le mode urgent, et ceci jusqu'à la marque convenue. Cette marque est constituée par la position du caractère représentant le dernier caractère urgent, indiquée par la position relative de ce caractère par rapport au numéro de séquence. Cette valeur relative est placée dans le champ pointeur urgent". La position du caractère urgent est donc donnée par le numéro de séquence plus la valeur du pointeur urgent. Pour faciliter le travail du programme qui doit pomper les données devenues inutiles, il a été décidé que TCP fait obligatoirement une césure après le dernier caractère urgent et ne livre pas à l'usager dans le même bloc, les données jusqu'au caractère urgent et les données qui suivent, même si elles arrivent dans le même datagramme. Ainsi le programme qui appelle TCP peut faire des lectures de blocs de n caractères, avec n quelconque, jusqu'à ce que l'indication urgente ne lui soit plus indiquée Automate de TCP A titre d'information, l'automate gérant TCP est schématisé sur la gure 5.9. Dans les transitions, on trouve au-dessus de la ligne un événement et audessous l'action qu'il faut exécuter lorsque l'événement survient. La spécication du DOD précise exactement quels sont les événements attendus dans chaque état, quels sont les tests à faire sur les données apportées par l'événement, quel est le prochain état et quelles actions on exécute en fonction des résultats des tests. Sur ce diagramme, on reconna t les ouvertures actives (èches partant à gauche à partir de l'état central CLOSED) et les ouvertures passives (èches partant à droite). Si l'on imagine alors un automate utilisé en mode passif et un 66

15 autre en mode actif, on peut reconstruire les 3 échanges SYN et ACK reportés sur la gure 5.8. EXERCICE 1. Déterminer l'ordre dans lequel les transitions décrites dans l'automate de la gure 5.9 sont exécutées pour une ouverture puis une fermeture d'une connexion TCP Décodage de blocs IP EXERCICE 2. Les objectifs de l'exercice sont de savoir comment interpréter les paquets TCP circulant sur un réseau et d'être en mesure d'analyser un échange TCP de manière critique. On demande de décoder les trames suivantes observées sur un réseau Ethernet à partir des en-têtes décrits aux sections et Les paquets observés sont composés d'un en-tête Ethernet (6 octets d'adresse destination, 6 octets d'adresse source, et 2 octets de type de protocole), suivi de l'entête IP, l'entête TCP, etc. Remarquez que le bloc est plus long que la longueur indiquée dans l'en-tête IP, parce que les données occupent moins de 64 bytes et qu'il est donc agrandi articiellement. On a ci-dessous 60 octets + les 32 bits du code de détection d'erreur, qui ne sont pas achés, ce qui constitue la longueur minimale de 64 octets prévue par Ethernet. TCP from ltisun12.epfl.ch to disun45.epfl.ch c c db c 61 0c c cb 80 b2 95 1a 80 b2 4f 76 0b 0d d b TCP from disun45.epfl.ch to ltisun12.epfl.ch c db c c f6 7b a 06 a4 5b 80 b2 4f b2 95 1a b 0d d c6 b b TCP from ltisun12.epfl.ch to disun45.epfl.ch c c db e c cd 80 b2 95 1a 80 b2 4f 76 0b 0d d de b TCP from ltisun12.epfl.ch to disun45.epfl.ch c c db e 61 0f c c6 80 b2 95 1a 80 b2 4f 76 0b 0d d df 4c ff fd 03 ff fb 18 67

16 Fig Connexions à travers des routeurs 5.6 CONTROLE DE LA CONGESTION DES RE- SEAUX Introduction Les blocs IP sont envoyés à travers Internet sans avertissement préalable, donc sans réserver de ressources. On ne peut donc pas refuser l'établissement d'une communication à quelques utilisateurs, comme c'est le cas pour le téléphone par exemple, lorsqu'un grand nombre de ceux-ci décident de transmettre des informations à travers un même réseau, presque simultanément. Il est donc possible qu'à un certain moment, un routeur reçoive plus de messages IP qu'il ne peut en transmettre sur les lignes sur lesquelles le routeur doit envoyer les messages, et cela pendant un certain temps. Les transmissions vont donc ralentir, ce qui mènera à ce qu'on appelle une situation de congestion. On pourrait augmenter la taille de la mémoire des routeurs, mais cela n'empêcherait pas les délais de transmission de cro tre. Il viendra donc un instant où les mêmes messages seront émis une deuxième puis une troisième fois par les émetteurs, car ils ne reçoivent plus d'acquittements dans les temps prévus. Les routeurs ne sont prévus que pour transmettre les messages le mieux possible, compte tenu des circonstances, et n'utilisent pas de moyens pour réguler ces congestions. La seule chose qu'ils puissent faire pour diminuer les congestions est d'équilibrer les nombres de messages en transmission sur les lignes de transmissions au cas où il y aurait plusieurs chemins pour arriver à une destination (g. 5.19). Les organismes qui s'occupent de dénir les concepts sur lesquels le réseau Internet fonctionne ont décidé de ne pas compliquer les protocoles de routeurs et de laisser la gestion des congestions aux utilisateurs. Le moyen choisi pour cela est d'adapter la taille de fenêtre aux conditions de transmission du réseau. En eet, la taille de la fenêtre représente exactement le nombre de caractères qui peuvent se trouver en transmission entre la source et le récepteur et donc dans le réseau. La limite supérieure du nombre d'octets contenus dans le réseau, si l'on ne compte pas les ré-émissions, est donc égale à la somme des valeurs des fenêtres des transmissions actives. La gure 5.11 montre le principe de la gestion de la congestion. Lorsqu'un noeud atteint un certain niveau de congestion, il se met à perdre des paquets 68

17 Fig Reseau Fig Temps aller-retour (message-acquittement) IP (soit des acquittements, soit des blocs de données). L'émetteur détecte ces pertes en constatant qu'un ou plusieurs acquittements n'arrivent pas dans les temps prévus. Il doit alors diminuer d'un peu sa fenêtre. Le problème qui se pose maintenant est d'évaluer le temps après lequel un acquittement peut être considéré comme perdu et la taille de fenêtre optimale. Si les utilisateurs limitent leur taille de fenêtre, les congestions vont donc automatiquement diminuer. Cependant, le débit d'un utilisateur est égal à la taille de la fenêtre divisée par le temps aller-retour sur le réseau, appelé RTT (round-trip time, g. 5.12) : Debit F enetre/rt T cette expression s'expliquant par le fait que pendant un temps RTT, seuls un nombre F enetre de caractères ont pu être envoyés. Il ne faut donc pas trop diminuer la taille de la fenêtre. Notons que pour mesurer RTT, il sut de noter l'instant de départ des messages et l'instant d'arrivée des acquittements correspondants et de calculer la diérence entre ces deux valeurs (g. 5.12). Notons également que la façon la plus rapide de transmettre des informations est d'être le seul à ne pas respecter les algorithmes présentés dans les paragraphes qui suivent, puisque les routeurs ne font pas (pas encore) de vérications. Actuellement la communauté Ethernet fait conance aux abonnés. Cette remarque implique aussi que si l'on veut tester un nouvel algorithme, il 69

18 Fig Mesure erronée des temps aller-retour ne sut pas d'établir une communication améliorée" entre deux utilisateurs, mais il faut qu'elle améliore l'ensemble du réseau Détermination du temps estimé de retour de l'acquittement Voyons d'abord comment calculer le temps d'acquittement maximal. On pourrait utiliser pour ce temps d'acquittement, la valeur de RTT avec une petite marge, mais ce temps peut varier passablement d'un instant à l'autre, car les communications des autres utilisateurs varient constamment. Un première solution consiste à calculer plutôt une valeur moyenne, de la façon indiquée cidessous, et de considérer qu'un acquittement est perdu s'il n'est pas de retour dans un laps de temps égal à 2 DelaiMoy : avec DelaiMoy = α DelaiMoy + β DernierRT T α + β = 1 et 0.8 < α < 0.9 Ainsi si tous les RTT ont la même valeur, la valeur DelaiMoy tendra petit à petit vers cette valeur de RTT. S'il y a parmi ceux-ci un seul RTT un peu diérent des autres, la valeur moyenne ne changera qu'un peu pendant quelques instants, mais reviendra vers la valeur de RTT. Cet algorithme ltre donc les variations rapides mais non les lentes Algorithme de Karn/Partridge En utilisant simplement la diérence des temps de départ d'un message et le temps d'arrivée de l'acquittement correspondant pour estimer le temps allerretour, on peut faire une erreur importante au cas où un message a été répété, comme le montre la gure Suivant les circonstances, on peut calculer un temps beaucoup trop grand, ce qui ne porte pas à conséquence, mais on peut aussi calculer un temps trop court, ce qui provoquera de nouvelles retransmissions et donc des risques accrus de retrouver un temps court et risque fort d'établir une situation de mauvais fonctionnement qui se perpétue. Pour résoudre ce problème, Karn et Partridge ont proposé une extension de l'algorithme qui détermine la valeur pour le temporisateur de ré-envoi des 70

19 Fig Temps aller-retour sur le réseau messages. Lorsque le système suspecte une perte d'acquittement, il suppose que la raison en est une congestion et non une perte par erreur de transmission, ce qui est en eet beaucoup plus rare, et donc plutôt que de mettre à jour la valeur du délai au moyen du calcul précédent, il double la valeur de DelaiMoy, pour tenir compte de la situation de congestion (réelle ou supposée). Par la suite, la valeur DelaiMoy reviendra petitp à petit à sa valeur normale s'il n'y a plus de pertes Algorithme de Jacobson/Karel Comme l'illustre la gure 5.14, les valeurs du délai RTT varient au cours du temps. Si le nombre des usagers du réseau est stable, cette valeur ne uctue que peu et la valeur calculée au moyen des algorithmes précédent est relativement able. Par contre si le réseau est instable, il arrivera un moment où la valeur de pointe dépassera souvent le double de la valeur moyenne calculée au moyen de l'algorithme précédent. Pour calculer une valeur plus réaliste, il faut donc tenir compte du degré de uctuation du réseau. L'algorithme proposé par Jacobson et Karel ltre séparément d'une part la valeur moyenne et d'autre part la valeur moyenne des diérences entre la valeur moyenne et la valeur du dernier échantillon de RTT. ou avec α = 1 β DelaiMoy = α DelaiMoy + β DernierRT T DelaiMoy = (1 β) DelaiMoy + β DernierRT T (5.1) = DelaiMoy + β (DernierRT T DelaiMoy) (5.2) La diérence placée entre les dernières parenthèses représente la diérence indiquée sur la gure Pour ltrer la valeur de l'écart moyen, on peut utiliser le même algorithme, mais naturellement en prenant la valeur absolue de la diérence, car l'écart est toujours positif, que la valeur instantanée diminue ou augmente. Si l'on écrit Dierence = DernierRT T DelaiM oy on a la valeur ltrée de la déviation : 71

20 EcartMoy = EcartMoy + β ( Dierence EcartMoy) et l'on peut réécrire l'équation 5.2 de la façon suivante : DelaiMoy = DelaiMoy + β Dierence La délai dans lequel l'acquittement devrait être arrivé est maintenant estimé à : Delai = DelaiMoy + 4 EcartMoy Régulation de la fenêtre En plus du délai maximal, l'émetteur doit déterminer la taille de la fenêtre qu'il indique à son partenaire, d'une part en fonction de la place disponible dans sa propre mémoire F enetreannoncee et d'autre part en fonction de la congestion du réseau (F enetrecongestion). La taille de fenêtre insérée dans les messages est F enetreu tilisee = min(f enetreannoncee, F enetrecongestion) Fenêtre de congestion Pour trouver la taille de fenêtre de congestion optimale, on part d'une petite taille, égale à MSS (maximum segment size) et on augmente petit à petit la taille de la fenêtre jusqu'à ce qu'on détecte des pertes de message ou d'acquittement. On diminue alors cette taille d'une valeur importante et on l'agrandit à nouveau petit à petit à chaque acquittement d'un bloc, puisque la congestion pourrait être seulement temporaire. On réduit à nouveau la fenêtre de congestion à la première perte, passant ainsi alternativement d'augmentations à des diminutions et vice-versa. Les expériences et des simulations ont montré qu'en fait il fallait diminuer plus rapidement que ce que l'on augmentait pour obtenir les meilleurs résultats. Si l'on part avec une petite fenêtre dans un réseau peu chargé, on se limite sans améliorer les congestions mais par contre si l'on part avec une fenêtre trop grande, on peut transmettre beaucoup de messages d'un coup et l'on risque de voir tous les messages se perdre, sans que l'on ait rien appris sur le niveau exact de congestion. Pour tenir compte de toutes ces contraintes, diérents algorithmes se superposent, entrant en action dans les diverses circonstances décrites ci-dessous Augmentation additive, diminution multiplicative L'algorithme de base est l'augmentation additive, diminution multiplicative. Chaque fois qu'un acquittement est reçu correctement, on ajoute un petit incrément correspondant à la valeur indiquée ci-dessous et chaque fois qu'on constate une perte de message, on multiplie la taille de la fenêtre par un facteur, mais un facteur inférieur à 1, typiquement 1/2. Rappelons que l'adaptation du temps maximal d'acquittement discuté aux paragraphes précédents continue d'être effectuée. 72

21 Fig Courbe suivie par la taille de la fenêtre L'incrément ajouté vaut : increment = MSS MSS F enetrecongestion Cette expression s'explique de la façon suivante. Au départ, F enetrecongestion est peu diérente de MSS et donc la fraction vaut à peu près 1 et l'incrément à peu près MSS. Puis lorsque la fenêtre grandit, la fraction diminue, et les incréments ne valent donc plus qu'une fraction de MSS. La taille de la fenêtre suit donc une courbe en dent de scie telle celle qui est représentie sur la gure Slow start L'algorithme indiqué au paragraphe précédent est valable pour maintenir une taille de fenêtre à une bonne valeur en régime permanent, mais si l'on doit transmettre de petites quantités de données, on restera toujours dans les zones de petites fenêtres et si le réseau n'est pas chargé, on ralentira donc les utilisateurs inutilement. Pour trouver plus rapidement une valeur acceptable de fenêtre, on part d'une taille égale à MSS et on double la valeur de la fenêtre de congestion chaque fois qu'on reçoit un acquittement dans les temps. Au bout d'un certain temps, il y aura une perte d'acquittement si le réseau est congestionné. On réduit la valeur de la fenêtre à la moitié, c'est-à-dire à l'avant-dernière valeur et l'on passe sur l'algorithme d'augmentation additive diminution multiplicative. Notons que ce départ est plus rapide que dans le cas précédent, mais le nom de slow start est entendu par rapport à la situation initiale de TCP où l'on partait avec une grande fenêtre, pas par rapport à l'algorithme précédent. Le slow start est également utilisé dans une autre circonstance où il mérite mieux son nom. Il s'agit du cas où l'on ne détecte un perte d'acquittement qu'après avoir attendu un certain temps sans envoyer de messages. A cet instant, la fenêtre a une valeur donnée (la dernière valeur calculée divisée par 2). Plutôt que de repartir directement avec cette valeur de fenêtre on repart avec l'algorithme slow start, mais on limite cette fois-ci sa progression à la valeur de la fenêtre déterminièe par les phases précédentes (g. 5.16). 73

22 Fig Slow start, départ progressif Fig Reconnaissance d'un acquittement perdu Acquittement manquant Le récepteur envoie le numéro du prochain octet qu'il attend à chaque réception de message. Ainsi, si un message est perdu, les messages qui suivent sont acquittés avec le même numéro, jusqu'à ce que l'émetteur renvoie le message perdu, ce qu'il fera après que le temps aller-retour estimé ait été atteint sans l'acquittement du message perdu. L'émetteur a donc la possibilité de détecter cette situation (g. 5.17) en constatant l'apparition de plusieurs acquittements (en principe 3) avec la même valeur, sans attendre la n du délai d'attente de l'acquittement. Dans ce cas, le programme TCP doit évidemment diminuer sa fenêtre de congestion de moitié, et certaines versions de TCP continuent simplement avec la nouvelle fenêtre, alors que d'autres repartent avec un slow start limité à cette même valeur de fenêtre. Si l'on arrive à la n d'un délai sans l'arrivée de l'acquittement, on doit repartir avec un slow start. Cela ne para t pas très cohérent, puisqu'en cas de perte constatée au bout du délai, on pourrait se dire que l'utilisateur a déjà assez contribué à la baisse de la congestion simplement par l'attente supplémentaire. Toutefois si l'on ne reçoit pas les autres acquittements qui nous permettraient de constater la perte, on peut penser que la congestion est sévère. Notons que si la fenêtre est petite, il est peu probable que l'on pourra envoyer trois messages pour provoquer l'envoi de trois acquittements identiques. 74

23 5.7 GESTION DES ADRESSES IP Ainsi qu'on l'a vu, les adresses IP sont séparées en 4 classes diérentes. Les adresses de classe A ont toutes été réservées par le DoD à la mise en route du protocole. Les adresses de classe B ne fournissent que 16'000 réseaux de 64'000 stations et les adresses de classe C permettraient de dénir 2 21 réseaux de 255 stations. En attribuant les adresses selon ce schéma, on perd beaucoup d'adresses individuelles, car les réseaux n'ont pas souvent des nombres de stations proches de 64'000 ou de 255 et on a craint pendant un certain nombre d'années de voir s'épuiser rapidement le stock d'adresses. Le comité de l'ietf a donc préparé une nouvelle version d'ip (Ipv6) qui permet d'attribuer les adresses avec plus de souplesse. Cependant remplacer tous les programmes connectés à Internet serait aujourd'hui une tâche gigantesque et entre-temps, une autre façon de gérer les adresses IP a été mise au point. C'est le sujet du présent paragraphe. Les limites prévues par les classes B, C et D ne sont plus prises en compte, et on indique donc pour chaque adresse combien de bits il faut considérer pour l'adresse réseau, au moyen d'un masque, par exemple : (masque) (adresse) Tous les premiers bits du masque sont à 1. L'adresse réseau comporte donc dans le cas présenté ci-dessus les 26 premiers bits. Dans les routeurs, on mémorise pour chaque réseau (appelé alors subnet) la valeur du masque et la valeur du réseau, avec l'indication de l'endroit où il faut envoyer les blocs correspondant à cette adresse. Lorsque le routeur cherche où il doit envoyer un bloc IP, il scrute la table de routage et pour chaque entrée, il eectue l'intersection entre l'adresse du bloc IP et le masque indiqué dans l'entrée de la table (ET bit à bit des deux valeurs), puis il compare la valeur résultante avec l'adresse réseau de cette même entrée. Il est prévu que plusieurs masques de longueurs diérentes puissent correspondre, dans leur partie commune (correspondant donc au masque le plus court) à la même adresse réseau. Cependant une adresse IP qui correspond à l'adresse de réseau mémorisée sous le masque le plus long correspond forcément aussi à l'adresse réseau qui est dans l'adresse qui a le masque plus court, alors que l'endroit où il faut envoyer le bloc peut ne pas être la même. Dans ce cas, il est précisé que c'est l'adresse la plus longue qui est la bonne. Pour utiliser les bonnes adresses, il faut donc les déposer dans le bon ordre dans les tables (les adresses longues d'abord), ou utiliser des arbres adéquats qui ont été étudiés pour réaliser les recherches d'adresses dans ces tables. Quant à la recherche d'adresses eectuée par l'utilisateur, il faut diérencier les situations dans lesquelles il est sur une ligne téléphonique, auquel cas il envoie tous ses blocs sur la ligne et les situations dans lesquelles il est connecté à un réseau local (par exemple Ethernet). Dans ce cas, il conna t le numéro et le masque du réseau où il se trouve. S'il doit atteindre un partenaire sur le même réseau, il utilise le protocole ARP qui a été vu au début de ce chapitre. Sinon, il conna t l'adresse IP du premier routeur et il détermine son adresse physique à nouveau au moyen du protocole ARP. 75

24 A B C A B lcn 1 lcn 2 lcn 3 lcn a lcn b port 1 port 2 port 3 port a port b Adresse IP (1) Adresse IP (2) câble du réseau Fig Connexion entre 2 stations Service de noms de domaines On a l'habitude d'utiliser des adresses telles que Cette adresse logique correspond à un numéro IP. Pour retrouver ce numéro IP il faut envoyer un message à un serveur de nom (DNS, domain name server). Le numéro IP de ce serveur ne peut évidemment pas être retrouvé de la même manière que les autres numéros IP. Ce numéro, de même que le numéro IP du routeur le plus proche, fait donc partie des paramètres d'initialisation de chaque système d'exploitation placé sur un réseau. Les serveurs de noms connaissent un certain nombre de sous-domaines. Par exemple le serveur qui contient ch conna t tous les serveurs du domaine ch, en particulier ep. Ce dernier conna t in1sun12 ou ltisun4. Le serveur qui contient ch conna t également les serveurs com, ou fr, etc, et ces derniers connaissent les sous-domaines qui font partie de leurs domaines. Ainsi pour trouver une adresse IP quelque part dans le monde, un utilisateur envoie une demande à un premier serveur, qui lui indique l'adresse d'un autre serveur qui conna t le sous-domaine dont fait partie l'adresse recherchée. L'utilisateur doit donc faire une nouvelle demande à ce serveur qui peut lui fournir l'adresse d'un nouveau serveur, plus détaillé, ou l'adresse de la destination cherchée. Pour plus de renseignements voir : Peterson & Davie, Computer networks - a System approach, Morgan & Kaufmann Gestion d'une connexion TCP Une station qui veut établir une connexion avec une autre station doit naturellement connaître l'adresse IP du destinataire ainsi qu'une identication de l'application à l'intérieur de cette station. La gure 5.18 présente les identicateurs utilisés pour établir et maintenir ces connexions. Les applications (A, B, C et D, E) peuvent par exemple représenter des activités distinctes d'un même programme ou des tâches asynchrones. Pour établir une connexion entre deux applications, il faut qu'elles puissent 76

25 Ordinateur Ordinateur 2 serveur 1 accept 3 read/write 4 client données read / write 4 Fig Connexion TCP entre deux ordinateurs s'identier. Dans le cas de TCP/IP, l'application appelante doit connaître un numéro de port TCP. Ce numéro, qui est transmis avec chaque bloc, identie l'instanciation de TCP, qui gère l'autre extrémité de la connexion. Pour que le pilote du port TCP puisse transmettre les données en provenance du réseau à l'application identiée par le port, il faut que celle-ci ait préalablement manifesté son intention de les recevoir. Ainsi TCP dénit l'ouverture passive qui permet à une application de signaler qu'elle est prête à accepter des blocs dirigés sur un port donné. Cet appel prépare l'extrémité locale de la connexion. TCP dénit également l'ouverture active qui ouvre l'autre extrémité et émet le premier message en direction du port en état d'ouverture passive. Ce premier message contient un fanion indiquant qu'un partenaire désire établir une nouvelle connexion ainsi que le numéro de séquence initial des octets d'information. Ces deux types d'ouvertures étaient mentionnés sur le graphe de la gure 5.9. Les données sont entrées dans le tampon TCP ouvert dans le système d'exploitation et en sont ressorties sous forme d'un ux de bytes qui ne garde pas trace des limites de messages, comme quand on relit des caractères stockés dans un chier. Le programme ci-dessous montre comment établir une connexion entre deux programmes (g.??), comment créer des sockets et comment y envoyer des octets, respectivement comment les en sortir. La création d'une connexion passe par les étapes suivantes : 1. Créer d'un côté un socket serveur ou socket de contrôle (ou socket passif) qui attend les appels des clients. Un socket est l'entité qui contient les paramètres locaux d'une connexion (temporisateur, tampons de données, numéro de port...). Un socket est identié par un entier sous UNIX et par un objet dans l'environnement Java. 2. Du côté serveur, appeller la méthode accept du socket serveur. Cette méthode reste bloquée jusqu'à ce qu'un nouveau client (point 3 ci-dessous) appelle. Elle retourne l'identicateur d'un socket de données, qui est une copie du socket de contrôle. 3. Attendre un socket de données créé par l'appel d'un client. 4. Du côté client, créer un socket client (ou socket actif). Un socket client appelle automatiquement le serveur dont on a indiqué l'adresse (adresse IP, numéro de port) dans les paramètres. Lorsque le premier bloc de la connexion TCP atteint le bloc de contrôle préparé dans le serveur une copie 77

26 de ce bloc de contrôle est donc créée et son identication est retournée par la fonction accept. 5. Les données peuvent ensuite passer du socket du client au socket de données du serveur et vice-versa lorsque le client et le serveur écrivent/lisent dans ces sockets. Les instructions correspondant au serveur sont indiquées ci-dessous (en Java, mais dans UNIX les instructions sont très semblables). 1 ServerSocket tcp_socket ; 2 Socket tcp_soc ; 3 tcp_socket = new ServerSocket (portnb) ; 4 tcp_soc = tcp_socket.accept() ; La création de socket dans le client est indiquée ci-dessous 1 tcp_sd = new Socket(hostName, portnb) ; Après cette instruction la connexion a été établie et on peut transmettre des données à travers cette connexion au moyen des instructions ci-dessous. La ligne 4 lit les données provenant de la connexion dans un byte[] et les lignes 5 et 6 envoient les données placées dans le byte[] obtenu à partir d'une string au moyen de string.getbytes() dans la connexion. Si l'on écrit plusieurs des instructions de la ligne 5 avant celle de la ligne 6, les bytes sont transmis dans le même datagramme, s'il y a assez de place. Si l'on ne place pas la ligne 6, des données sont accumulées jusqu'à ce qu'un bloc soit plein. 1 try { 2 tcp_sin = new DataInputStream(tcp_sd.getInputStream()) ; 3 tcp_sout = new DataOutputStream(tcp_sd.getOutputStream()) ; 4 lengthread = tcp_sin.read(buffer, 0, bufferlength) ; 5 tcp_sout.write(st.getbytes(), 0, st.length()) ; 6 tcp_sout.flush() ; 7 } 8 catch (IOException e1) { 9 System.out.println("TCPSocket : "+e1.tostring()) ; 10 System.exit(-1) ; 11 } EXERCICE 3. Ecrire les instructions Java décrites ci-dessus, et qui permettent de transmettre des données d'un ordinateur A à un ordinateur B, sur deux colonnes et dans l'ordre d'exécution. On demande de placer une instruction par ligne, dans la colonne de gauche ou de droite, suivant l'instant et l'ordinateur où elle est exécutée. 78

27 5.8 TELNET : TERMINAL VIRTUEL Ayant TCP à disposition, on peut facilement relier un terminal à un ordinateur. Les problèmes du réglage du ux de données, de l'adressage et des pertes de données sont résolus. La plupart des ordinateurs connectés à un réseau local ont un accès de terminal sur le port TCP numéro 23. Pour obtenir un certain confort d'utilisation, quelques conventions ont été dénies. Il s'agit de l'encodage des ns de lignes, des caractères d'eacement, de la fonction d'écho, etc... Quelques-unes de ces conventions sont dénies dans les paragraphes qui suivent Empaquetage des données L'utilisation de Telnet implique la présence d'un programme qui transfère les données tapées au clavier sur la connexion TCP et qui ache les données arrivant de la connexion sur l'écran du terminal, ceci pour l'extrémité contenant le terminal. Le fait d'envoyer les caractères un par un sur le réseau risque de le surcharger inutilement et un envoi par groupes serait plus ecace. TCP essaie donc de remplir les datagrammes avant de les envoyer, mais ceci ne fait pas l'affaire de l'opérateur qui attend souvent une réponse après avoir entré une ligne de commande ou même quelques caractères seulement s'il est dans un éditeur interactif. Pour résoudre ce problème, le programme Telnet force l'émission des caractères accumulés, par l'instruction PUSH de TCP, lorsqu'un retour de ligne (CR) est frappé ou qu'aucun caractère n'est frappé pendant une période plus longue qu'un temps court donné (1/10 s par exemple). Ainsi si les caractères sont générés très rapidement, ils sont groupés et sinon le retard est si faible qu'il n'est pas remarqué par l'opérateur. Cette façon de faire était surtout utile lorsqu'on utilisait des terminaux capables d'envoyer une ligne de caractères préparée sur l'écran lorsque l'utilisateur le demandait en tapant une touche prévue pour cela Caractères et commandes La norme précise que les caractères admis sont les 95 caractères ASCII (32-126) plus les caractères suivants : NULL (0), LF (10), CR (13), Sonnerie (7), BS (8), HT (9), VT (11), FF (12) Les lignes sont terminées par CR LF, elles n'ont pas de longueur standard. Un certain nombre de commandes peuvent être encodées sur deux octets. Ce sont : IP : interrompre le processus (IAC = 255) + (IP = 244) Ce code correspond au CTRL-C d'unix AO : supprime l'achage jusqu'à la n de l'exécution du programme en cours (IAC = 225) + (AO = 245) Ce code correspond au CTRL-O du système d'unix. 79

28 AYT : Etes-vous là? (IAC = 225) + (AYT = 246) Cette commande devrait permettre d'acher un message qui montre à l'opérateur que son programme n'est pas mort. Par exemple le caractère CTRL-T sur certains systèmes d'exploitation ache le temps de processeur utilisé par le programme en cours, ce qui permet de vérier qu'il tourne encore. EC : eace le dernier caractère (IAC = 225) + (EC = 247) EL : eace toute la ligne sur laquelle le curseur se trouve (IAC = 255) + (EL = 248) Ceci est réalisé par CTRL-U sur UNIX Purge des données Lorsque l'ordinateur hôte reçoit la commande AO qui coupe l'achage, il doit purger la connexion en s'aidant du transfert de données urgentes oert par TCP. C'est-à-dire qu'il doit envoyer la commande à deux octets IAC (255) DM (242) et indiquer le mode urgent. Chaque fois qu'il voit TCP dans l'état urgent (Ÿ5.5.5), le récepteur doit pomper et abandonner toutes les données jusqu'à ce que le fanion urgent disparaisse et que la marque DM apparaisse. S'il n'y a pas coïncidence entre la marque et la disparition du fanion, la norme précise qu'il faut continuer jusqu'à la prochaine marque DM Options Telnet ore quelques possibilités supplémentaires : transmission binaire, échos, fonction "go ahead", achage des options enclenchées. Ces options sont présentées ci-dessous mais auparavant il faut comprendre la façon dont elles sont négociées. Pour enclencher une option, il faut que les deux extrémités d'une connexion se concertent, mais ce dialogue doit également fonctionner dans le cas où les deux extrémités demandent simultanément une option, éventuellement la même. C'est pourquoi les ordres et les acquittements sont identiques de façon que chaque ordre soit vu comme l'acquittement de l'autre lorsque deux ordres se croisent. Ils sont codés sur 3 caractères dont le premier est le caractère d'échappement IAC. On peut demander à l'autre extrémité d'activer une option chez elle par l'envoi de La réponse positive est (IAC = 255) + (DO = 253) + (code d'option) (IAC = 255) + (WILL = 251) + (code d'option) La réponse négative est 80

29 (IAC = 255) + (WON'T = 252) + (code d'option) Lorsque l'on enclenche chez soi une option qui aura des répercussions à l'autre extrémité, on envoie La réponse positive est (IAC = 255) + (WILL = 251) + (code d'option) La réponse négative est (IAC = 255) + (DO = 253) + (code d'option) (IAC = 255) + (DON'T = 254) + (code d'option) Si l'on veut supprimer une option, on remplace WILL par WON'T ou DO par DON'T dans la demande. Pour indiquer qu'on accepte une suppression, on renvoie évidemment la forme négative. De cette façon, s'il arrive que les deux extrémités passent une demande simultanée d'une même option, chaque demande correspond en fait à l'acquittement de la demande de l'autre et ainsi les échanges croisés ne portent pas à conséquence. Il y a toutefois une précaution à prendre. Si le programme répond systématiquement à toutes les demandes, il pourrait se créer une boucle innie, chaque extrémité répondant à ce qu'elle prend pour une commande. La convention est de ne pas répondre si l'on demande de se mettre dans un état dans lequel on se trouve déjà. Il ne faut pas oublier que les couches inférieures assurent la abilité de la liaison et que l'on n'est donc pas dépendant de cet acquittement pour savoir que la commande est arrivée. Transmission binaire : (code d'option 0) Cette option permet d'indiquer au processus qui reçoit les données de les considérer comme données binaires et donc de ne plus faire de test de parité, de traitement des retours de ligne, etc.... La couche Telnet ne prend en fait aucune action si ce n'est de transmettre la demande de transmission binaire en synchronisme avec les données et de la passer à l'utilisateur au bon moment. Pour que les deux sens soient mis en mode binaire, il faut envoyer la commande DO dans les deux sens, chacune acquittée si nécessaire par la commande WILL. Echo : (code d'option 1) Par cette commande, on peut demander à l'autre extrémité de renvoyer chaque caractère en écho. Supprime le "Go ahead" (code d'option 3) Cette commande est utilisée pour gérer des terminaux dont on peut bloquer le clavier tels ceux d'ibm. Etat (code d'option 5) Ce code permet de demander à l'autre extrémité si elle est capable d'envoyer son état, ce qui doit se faire de la façon suivante : Demande d'état Pour demander eectivement à l'autre extrémité d'envoyer son état, il faut transmettre la séquence suivante : 81

30 IAC SB STATUS SEND IAC SE (255) (250) (5) (1) (255) (240) La réponse est de la forme IAC SB STATUS IS... IAC SE (255) (250) (5) (0) (255) (240) La séquence... représente la liste d'options activées qui peut par exemple prendre la forme WILL ECHO DO BINARY. Les séquences IAC SB et IAC SE sont une façon standard d'envoyer des commandes complexes. Elles peuvent être utilisées dans d'autres cas semblables. 5.9 PROTOCOLE FTP Ce protocole utilise deux canaux TCP, un canal pour les commandes et un autre pour les données. Le canal de commandes reste ouvert pendant toute la durée de la session alors que le canal de données est fermé chaque fois que l'on veut indiquer la n d'une transmission (n de la transmission d'un chier par exemple). Tout serveur FTP maintient donc un socket serveur ayant un numéro de port égal à 21 ouvert en permanence Commandes de FTP FTP comprend un certain nombre de commandes permettant de se connecter, de s'identier, de gérer un répertoire (changement, création...) et d'établir les connexions de transfert. Ces commandes sont présentées succinctement cidessous. USER nom-d'utilisateur PASS mot-de-passe ACCT numéro-de compte Les trois commandes ci-dessus permettent de s'identier au système (login). Les deux dernières commandes ne sont pas exigées par tous les systèmes. CWD <identication-de-répertoire> Cela permet d'indiquer un nouveau répertoire de travail. PORT h 1, h 2, h 3, h 4, p 1, p 2 Cette commande demande d'établir une connexion avec le port (p 1 p 2 ) situé sur l'ordinateur d'adresse IP (h 1 à h 4 ). Les symboles h 1 à p 2 représentent des valeurs décimales valant chacune de 0 à 255. Attention, ces nombres sont séparés par des virgules pas par des points. PASV Cette commande ordonne au site qui la reçoit de se mettre en écoute passive sur un port quelconque et de renvoyer les numéros de IP et de port qu'il a choisis. RETR nom-de-chier Commande provoquant la lecture du chier nom-de-chier" du disque et son envoi sur la connexion de données. STOR nom-de-chier Commande provoquant la lecture de données provenant de la connexion de données et leur écriture dans le chier nom-de-chier". 82

31 NOOP Cet ordre ne provoque que le retour d'un message pour vérier que la connexion est en ordre. Pour lire un chier placé sur un autre ordinateur, le protocole FTP dénit les échanges de commandes suivants (commandes échangées entre les ordinateurs lors de l'utilisation du programme ftp) : Ouvrir une connexion TCP avec le port 21 (=FTP) de l'ordinateur distant Entrer les commandes de login (voir la signication des nombres plus loin) on envoie USER username on reçoit 300 Password Le 300 indiquant que le login doit continuer avec un mot de passe. On envoie PASS mot-de-passe on reçoit 200 user xxxx logged in on ouvre localement le port TCP sss, iii (sss comportant les 8 bits les plus signicatifs et iii les 8 bits les moins signicatifs en décimal), on envoie en mode passif PORT 128, 178, xxx, yyy, sss, iii du port, les 4 premiers nombres formant l'adresse IP locale et les 2 derniers les deux octets du port local qui vient d'être ouvert. on reçoit 200 port conect on envoie LIST on reçoit 100 au moment où l'ordinateur distant a pu ouvrir le port 200 au moment où l'ordinateur distant a terminé la transmission du répertoire courant on peut lire le contenu du répertoire sur le port local sss, iii. EXERCICE 4. Ouvrir deux fenêtres de terminal sur un ordinateur. Dans la première appeler telnet hostname 21", ce qui établit une connexion avec le serveur FTP hostname". Se loguer au moyen des commandes ci-dessus. Utiliser PASV plutôt que PORT. Le serveur retournera les numéros IP et les numéros de port qu'il a ouverts. Si les deux derniers nombres sont p1 et p2, le numéro de port est égal à p = p p2. Dans la deuxième fenêtre taper telnet h1. h2. h3. h4. p" (attention remplacer les virgules achées par le serveur par des points). Entrer dans la première fenêtre LIST", le contenu du répertoire devrait appara tre sur la deuxième. Essayer d'utiliser RETR ou STOR de la même manière Dialogue FTP Les réponses de FTP aux ordres lancés par l'usager sont dénies de façon qu'elles soient compréhensibles aussi bien par un opérateur que par un ordinateur. Elles commencent par un nombre à 3 chires et continuent par un message formé de caractères Telnet. 83

32 S'il faut faire une réponse de plusieurs lignes, on ajoute le signe après le numéro de la première ligne. La dernière ligne commence par le même numéro suivi d'un espace Exemple : 123 première ligne. 123 dernière ligne Les 3 chires caractérisent diérents aspects de la réponse. Le premier chire indique si l'ordre a été compris et eectué ou s'il y a eu erreur : 1 - réponse positive préliminaire (on a compris la commande d'envoi de chier) 2 - commande eectuée (l'envoi de chier est terminé) 3 - réponse positive intermédiaire (après avoir entré USER, il faut entrer PASS) 4 - la commande ne peut momentanément pas être accomplie 5 - réponse négative dénitive (erreur) Le deuxième chire précise de quel type d'erreur il s'agit (syntaxe, gestion de connexion, des chiers, etc...). Le troisième distingue des erreurs diérentes dont les 2 premiers codes seraient identiques Modes de transmission et de stockage des données Les systèmes d'exploitation utilisent toutes sortes de structures pour le stockage des données sur disque. FTP ore doncquelques moyens pour passer d'une structure à une autre ou pour stocker des données produites par un système d'exploitation X, sur un système d'exploitation Y plus ou moins compatible avec X et pour les reprendre ultérieurement sur X dans leur forme originale. Les données peuvent être stockées sous forme de chier plat", c'est-à-dire en une seule chaîne d'octets sans marques spéciales. Elles peuvent aussi l'être sous forme de blocs de tailles uniformes ou de tailles variables. Dans ce dernier cas, les ordres de lecture amènent au programme qui relit les données les mêmes enregistrements que ceux qui ont été écrits auparavant dans le chier. Pour les chiers de textes, les ns de lignes sont naturellement considérées comme marques de n d'enregistrement. Un enregistrement consiste alors en une ligne de texte. La gestion des formats de transmission et de stockage est déterminée par les ordres TYPE, MODE et STRU TYPE : forme des données transmises La commande précise s'il s'agit de données ASCII, EBCDIC ou de bits (images). Pour les deux premiers types, on peut encore préciser diérentes conventions pour les retours de ligne. Une dernière commande permet de transmettre des données qui ne sont pas alignées sur des octets. Commandes pour le texte : 84

33 TYPE A N - ASCII, normal TYPE A T - ASCII, Telnet TYPE A C - ASCII, FORTRAN TYPE E N - EBCDIC, normal TYPE E T - EBCDIC, Telnet TYPE E C - EBCDIC, FORTRAN Le paramètre normal indique que le ux de données ne contient pas de contrôles spéciaux à interpréter, si ce ne sont les caractères <CR> et <LF>. Le paramètre Telnet indique qu'il peut y avoir des tabulations verticales et des sauts de pages à respecter. Le format FORTRAN indique que les sauts de pages sont contrôlés selon le format de FORTRAN (saut de page = "1" en première colonne...) Commande pour image : TYPE I Les données sont considérées comme un ux continu de bits. Commande pour non-octets : TYPE L n (n = nombre décimal) Pour le transfert, les données sont envoyées comme un ux de bits, sans tenir compte des limites d'octets de la transmission. A la réception le ux de bits est découpé et déposé n par n dans des entités propres à l'ordinateur qui les reçoit (par exemple mots de 36 bits) MODE : mode de transmission Cette commande inuence la structure des données lors de la transmission. Elle doit être compatible avec la structure de stockage, mais il y a une certaine tolérance dans ces exigences. Commandes : MODE S (stream) MODE B (bloc) MODE C (comprimé) Le mode stream" est le mode utilisé par défaut. Il envoie les caractères tels quels sur la connexion TCP, de façon transparente. La seule façon de marquer la n du chier est de fermer la connexion TCP. Le mode bloc" permet de grouper les données dans des enregistrements. Les enregistrements possèdent des fanions qui permettent d'insérer et de reconnaître des commandes parmi les données et de marquer la n du chier (signaux hors bande). Chaque bloc est formé d'un descripteur de 8 bits pouvant contenir un ou plusieurs des fanions décrits ci-dessous, d'une indication de longueur (sur 16 bits) et des données. Fanions (les nombres correspondent à des bits) : 128 La n du bloc correspond à une n d'enregistrement 64 La n du bloc correspond à la n du chier 32 Le bloc risque de contenir des erreurs de transmission (utile dans certaines applications traitant des masses de signaux) 16 Le bloc est une marque qui permet à l'émetteur et au récepteur de se resynchroniser en cas de panne de transmission, sans reprendre tout au début de l'échange 85

34 Fig Structures du mode comprimé Le mode comprimé" permet d'optimiser la transmission lorsqu'il faut transférer des chiers contenant de grandes chaînes formées par le même caractère répété, en particulier par le caractère d'espacement. La séquence de caractères est également découpée en blocs dont la structure est donnée sur la gure Les caractères normaux sont mis dans des paquets successifs de la forme a. Un caractère qui se répète un certain nombre de fois peut être encodé sous la forme b. Les espaces qui arrivent souvent en longues chaînes prennent la forme c STRU : structure du chier stocké Cette commande détermine la forme sous laquelle le chier est stocké. En fait pour réaliser ces formes il faut choisir parmi les possibilités oertes par le système d'exploitation le type de chier qui contient susamment d'informations pour qu'il puisse être retransmis sous la même forme que celle sous laquelle il a été enregistré. STRU E ( chier plat ) STRU R ( chier à enregistrements ) STRU P ( chier découpé en pages ) Le chier plat est formé d'une séquence d'octets indiérenciés. Le chier à enregistrements est composé de blocs séquentiels. Le chier de pages a été prévu pour des installations particulières PROTOCOLE HTTP Le protocole HTTP (hypertext transfer protocol) est le protocole qui transmet les pages d'un site Web au client. Ce protocole est décrit en détail à l'adresse http :// Dans ce qui suit, nous allons nous concentrer sur la structure générale du protocole, ce qui devrait sure pour comprendre la norme complète par la suite. Contrairement au protocole FTP, le protocole HTTP n'utilise qu'une seule ligne de connexion et reçoit les données directement de la connexion qui a été ouverte pour envoyer les commandes Commande de lecture Les serveurs HTTP, qui reçoivent les requêtes pour lire des pages du Web, ouvrent un socket serveur à l'adresse 80. Si l'on veut adresser un serveur qui n'a pas l'adresse habituelle, il sut d'ajouter cette adresse à la suite du nom du serveur dans l'appel du browser. Supposons maintenant que l'on ait tapé dans un browser Web, la commande http ://ltisun4.ep.ch :8080/xxx. Dans ce cas le browser forme le texte indiqué ci-dessous et l'envoie à l'adresse indiquée dans la commande http. Le nom xxx est placé sur la première ligne. 86

35 1 GET /xxx HTTP/1.0 2 Connection : Keep-Alive 3 User-Agent : Mozilla/4.6 [fr] (WinNT ; I) 4 Host : ltisun4.epfl.ch : Accept : image/gif, image/x-xbitmap, */* 6 Accept-Encoding : gzip 7 Accept-Language : fr 8 Accept-Charset : iso ,*,utf-8 Le message envoyé par un browser à un serveur pour obtenir une page Web commence par l'indication GET. Cette commande est suivie du nom du chier que le browser demande et de la version du protocole HTTP utilisée par le browser. Les lignes qui suivent contiennent un certain nombre d'indications générales sur les possibilités du browser. Pour répondre à cette demande, le serveur envoie le contenu du chier indiqué dans la commande GET en retour sur la connexion qui a été ouverte par le browser. Lorsque le chier a été entièrement envoyé, le serveur ferme la connexion pour indiquer la n du chier. EXERCICE 5. Ouvrir telnet en direction d'un site Web connu en indiquant le port 80 : telnet Tapez ensuite GET/index.html. Vous obtenez le contenu du chier Entrées de données sur une page Web Les normes HTTP et HTML permettent de créer des pages qui contiennent des champs de texte et des boutons pouvant être remplis ou cliqués par l'utilisateur pour envoyer des données spéciques au serveur lorsque ce dernier doit traiter les réponses de l'utilisateur. Ci-dessous, on montre comment créer une page avec les diérents éléments qui permettent à l'utilisateur d'entrer des informations ainsi que le protocole qui est utilisé entre le browser et le serveur pour transmettre ces informations. Le texte ci-dessous forme une page HTML contenant une commande FORM aux lignes 6 à 14. (On suppose que vous connaissez les instruction de base de HTML). 1 <html> 2 <head> 3 <title>sondage</title> 4 </head> 87

36 5 <body> 6 <form METHOD="POST" action= 7 "http ://ltisun4.epfl.ch :8080/response.html"> 8 <input name="m_name" size=25> 9 <input name="m_first" size=25><p> 10 <input name="button" type=radio value=yes> Yes<P> 11 <input name="button" type=radio value=no> No <P> 12 <input type=submit value=submit> 13 <input type=reset value="resets texts and buttons"> 14 </form> 15 </body> 16 </html> Lorsque le browser ache cette page, elle appara t sous la forme indiquée à la gure On peut bien évidemment ajouter à ces indications toutes les images et titres ou textes que l'on désire. La ligne 6 du texte ci-dessus indique l'action qui doit être exécutée lorsque l'utilisateur renvoie la page. Le message renvoyé aura un en-tête semblable à celui qui demande un chier, mais il commencera dans le cas présent par l'indication POST. Ce message sera envoyée au serveur indiqué à côté du symbole action. Les lignes 8 et 9 ouvrent deux champs d'entrées de texte avec une longueur de 25 caractères. Les noms à côté de l'indication name= permettent de retrouver les champs dans la réponse. Les boutons dénis aux lignes 10 et 11 agissent comme des boutons de radio qui ont la particularité de ressortir les autres boutons enfoncés chaque fois qu'on en presse un. Dans le cas présent, ils ont le même nom "BUTTON". Il y a donc en permanence 0 ou 1 bouton de nom "BUTTON" qui sont enfoncés. L'indications à côté de value indique le nom qui sera retourné au serveur à côté du nom "BUTTON" lorsque le bouton correspondant aura été pressé. Les lignes 12 et 13 sont des boutons standards. Le premier, submit, est le bouton qui envoie la commande. Notons que s'il n'y a qu'un champ de texte, taper un retour de ligne dans ce champ a le même eet que le bouton submit. L'indication placée à côté de value est celle qui appara t sur l'écran dans le bouton submit. Le bouton reset remet à zéro tous les champs de texte et les boutons. Lorsque l'on a pressé le bouton submit, le browser retourne le message suivant au serveur : 88

37 Fig Page créée par la commande FORM 1 POST /Survey HTTP/1.0 2 Referer : http ://ltisun4.epfl.ch :8080/response.html 3 Connection : Keep-Alive 4 User-Agent : Mozilla/4.6 [fr] (WinNT ; I) 5 Host : ltisun4.epfl.ch : Accept : image/gif, image/jpeg, image/png, */* 7 Accept-Encoding : gzip 8 Accept-Language : fr 9 Accept-Charset : iso ,*,utf-8 10 Content-type : application/x-www-form-urlencoded 11 Content-length : m_name=aaaa+aaaa&m_first=bbbb&button=yes L'indication Keep-Alive de la ligne 3 indique que le serveur ne fermera pas la connexion à la n de la transmission de sa commande, mais qu'il la gardera ouverte et attendra la prochaine commande du client. Pour déterminer la n du message, il faut donc se référer à la ligne 11, qui indique le nombre d'octets qu'il y aura après la première ligne vide (2xCR) entre la ligne 11 et la ligne 12. Attention, le premier bloc que l'on lit sur le socket ne contient pas toujours la ligne 11 et il faut parfois attendre un deuxième bloc de données pour l'obtenir. Le message commence par le mot-clé POST. Les lignes qui suivent indiquent de nouveau quelques caractéristiques du serveur. La ligne 11 indique la longueur du corps du message (ligne 12). Suit une ligne vide qui marque la n de l'entête. La ligne 12 donne la liste des réponses entrées par l'utilisateur, chaque fois précédée du nom correspondant au champ ou au bouton. Dans le cas présent, l'utilisateur a tapé son nom, aaaa aaaa dans la première fenêtre, bbbb dans le champ m_first et il a cliqué le bouton marqué YES. Notons que si l'on tape un mot avec des espaces dans un champ de texte, ceux-ci apparaissent sous la forme d'un plus dans la réponse, comme ci-dessus. EXERCICE 6. Ouvrir un socket passif à l'adresse 8080 au moyen du programme passiveopen et appeler ce socket à partir d'un browser. Retourner un chier contenant une commande FORM semblable à celle qui est indiquée cidessus. Fermer le socket. Répondre dans le browser et presser submit. La réponse appara t dans la fenêtre du socket passif. Fermer le socket, après avoir éventuellement envoyé quelques données, pour libérer le browser. Tapez des noms avec des espaces, des accents ou des caractères spéciaux et voyez ce qui est retourné par le browser UTILISATION DES COOKIES La plupart des services des serveurs Web ne font que renvoyer des pages HTML qui sont ensuite achées sur l'écran du client. Dans ces cas, il n'y a pas besoin de mémoriser le fait que le client a déjà accédé à ce serveur auparavant. 89

38 Par contre certains serveurs orent des services plus sophistiqués et par exemple présentent des pages dans plusieurs langues. Il est donc intéressant dans ces cas de reconna tre les clients pour éviter de leur demander dans quelle langue acher les pages chaque fois qu'ils se reconnectent au site. C'est le but des cookies, qui permettent au serveur de retourner des paramètres au client, qui peut les stocker et les renvoyer automatiquement. Cela évite au serveur de gérer une base de données des clients. Note : il est possible que certains serveurs ne suivent pas exactement les règles indiquées ci-dessous Principe des cookies Quand un serveur retourne un objet HTTP à un client, il peut adjoindre dans l'en-tête une information spéciale, le cookie, qui contient les données attribuées au client et un espace d'url. Le client vérie que cet espace inclut l'adresse propre du serveur et, dans ce cas, mémorise le cookie sur son disque local pendant une période plus ou moins longue. Ensuite, chaque fois que le client demande un objet HTTP à une adresse qui fait partie de l'espace indiqué dans le cookie, il adjoint automatiquement les données dans l'en-tête de l'objet. Grâce à ce mécanisme, il est possible de mémoriser quelques paramètres qu'on ne doit donc plus demander chaque fois que le client accède aux mêmes serveurs. Ces cookies permettent également de créer des applications plus complexes, telles que la création d'une liste d'achat : chaque fois que le client fait une demande d'un nouveau produit, ce produit est ajouté dans les données du cookie, qui s'allonge ainsi au fur et à mesure des achats du client, éliminant partiellement la nécessité de mémoriser les données de chaque client dans le serveur. Remarquons toutefois que la base de données est de toutes façons nécessaire pour gérer la commande et la facturation et que si cette façon de faire est eectivement utilisée, il y a d'autres moyens que les cookies. Certaines personnes prétendent que ces cookies ouvrent la porte à un certain nombre d'abus dans l'exploitation des clients. Eectivement, on peut utiliser ces cookies pour identier les clients et ainsi étudier leurs habitudes pour cibler les ores de façon à leur vendre un maximum de produits. Cependant,il est de toutes façons nécessaire de garder les identités des clients qui achètent des produits, et ils doivent bien s'identier pour qu'on puisse facturer et délivrer les produits commandés. L'utilisation des cookies n'est en fait intéressante que pour établir l'équivalent d'une session liant les demandes d'un client lors de l'exécution d'un service, ou pour mémoriser quelques paramètres généraux (langue) qui partagent les clients en diérentes classes Spécication Le cookie est inséré dans un en-tête HTTP. Il possède la syntaxe suivante (sans retour à la ligne) : VALUE Set-Cookie: name=value; expires=date; path=path; domain=domain_name; secure 90

39 La valeur doit être faite d'une cha ne de caractères sans point-virgules, ni espace, ni virgule. S'il faut transmettre un tel caractère dans la cha ne, il faut le coder d'une façon qui n'est pas prescrite. On utilise souvent le style des URL : %xx où xx est le code hexadécimal ou octal du caractère à placer. C'est le seul paramètre obligatoire dans la ligne Set-Cookie indiquée ci-dessus. DATE Cet attribut indique la date jusqu'à laquelle le cookie doit être retenu dans le client. Après que cette date d'expiration a été atteinte, le cookie peut être eacé et ne plus être envoyé au serveur. Le format de la date est le suivant : Wdy, DD-Mon-YYYY HH:MM:SS GMT Cette syntaxe est basée sur les requests for comments" RFC 822, RFC 850, RFC1036 et RFC 1123, avec la diérence que la seule zone de temps légale est GMT et que les séparateurs dans la date doivent être des tirets". Le paramètre expires est optionnel. Note : une erreur dans les navigagteurs Netscape version 1.1 et antérieures, fait qu'il faut avoir au moins un /" dans le path pour que le cookie soit sauvé lorsqu'il possède un champ expires. DOMAIN_NAME S'il est déni, ce paramètre doit avoir deux ou trois points : par exemple mais il est optionnel. S'il n'appara t pas, le client lui attribue le domaine auquel il a envoyé la requête. PATH Le path correspond aux noms de répertoire et de chier qui suivent le nom de domaine. Le client fait les comparaisons de la façon suivante. Si le client a mémorisé.ep.ch et qu'il doivent envoyer une requête au serveur ou ltiwww.ep.ch, il ajoute un cookie avec les données, avec la syntaxe ci-dessous. Le domaine de l'url de la requête doit donc correspondre aux derniers noms du domaine mémorisé. Si le client a mémorisé /foo et que le domaine auquel il envoie son message correspond aux critères susmentionnés, il doit adjoindre le cookie si la requête contient les paths : /foobar et /foo/bar.html. secure Si un cookie comporte l'inscription secure, il ne peut être ajouté à la requête que si le système utilise un communication sécurisée : HTTPS ou SSL (secure socket layer) Syntaxe du cookie envoyé par le client Le cookie ajouté dans l'en-tête de la requête au serveur a la forme suivante. Cookie: NAME1=cha ne_opaque1; NAME2=cha ne_opaque; Complément d'information Ce paragraphe indique encore diverses particularités. 91

40 Si le client trouve plusieurs correspondances dans la liste des cookies mémorisés localement, il doit ajouter chacun des noms correspondants. Les noms doivent être placés dans l'ordre croissant des précisions : un cookie avec un path correspondant à /" doit être envoyé avant un cookie avec un path correspondant à /foo" Lorsqu'un client reçoit des cookies qui correspondent aux cookies déjà enregistrés, il écrit les nouveaux cookies à la place des anciens. La surcharge indiquée ci-dessus ne doit toutefois pas être réalisée si le nouveau path est plus spécique que le path mémorisé (path plus long). Le client n'est pas tenu de garder le cookie jusqu'à son expiration, ni de l'eacer à cet instant. Un serveur ne doit pas s'attendre à ce qu'un client mémorise un nombre illimité de cookies de longueurs illimitées. Les limites sont données cidessous. 300 cookies au total 4 kilobytes par cookie, où sont comptés les longueurs du nom et de la valeur correspondante 20 cookies par domaine ou serveur un serveur peut eacer un cookie en retournant un cookie semblable à celui qu'il doit eacer, mais en spéciant une date d'expiration dans le passé. Notons que cela rend dicile l'eacement d'un cookie qui a été délivré par un autre serveur. Les proxies ne doivent pas lire les données des requêtes qui contiennent des cookies dans leur mémoire-cache. Ils doivent les transmettre plus loin, qu'ils proviennent d'un serveur ou d'un client, et cela même si l'en-tête contient une indication de transmission conditionnelle Premier exemple Un client demande un document et reçoit dans la réponse : Set-Cookie: CUSTOMER=WILE$\_$E$\_$COYOTE; path=/; expires=wednesday, 09-Nov-99 23:12:40 GMT Quand le client demande une page dont l'url est dans ce serveur, sous le path /", il envoie : Cookie: CUSTOMER=WILE$\_$E$\_$COYOTE Le client demande un autre document et reçoit la réponse : Set-Cookie: PART$\_$NUMBER=ROCKET$\_$LAUNCHER$\_$0001; path=/ Quand le client fait une demande dont l'url est dans ce serveur, sous le path /", il envoie : Cookie: CUSTOMER=WILE$\_$E$\_$COYOTE; PART$\_$NUMBER=ROCKET$\_$LAUNCHER$\_$0001 Le client reçoit : Set-Cookie: SHIPPING=FEDEX; path=/foo 92

41 Quand le client demande une page dont l'url est dans ce serveur, sous le path /", il envoie : Cookie: CUSTOMER=WILE$\_$E$\_$COYOTE; PART$\_$NUMBER=ROCKET$\_$LAUNCHER$\_$0001 Quand le client demande une page dont l'url est dans ce serveur, sous le path /foo", il envoie : Cookie: CUSTOMER=WILE$\_$E$\_$COYOTE; PART$\_$NUMBER=ROCKET$\_$LAUNCHER$\_$0001; SHIPPING=FEDEX Deuxième exemple Nous supposons pour ce deuxième exemple que toutes les informations cidessus ont été éliminées. Le client reçoit : Set-Cookie: PART$\_$NUMBER=ROCKET$\_$LAUNCHER$\_$0001; path=/ Quand le client fait une demande dont l'url est dans ce serveur, sous le path /", il envoie : Cookie: PART$\_$NUMBER=ROCKET$\_$LAUNCHER$\_$0001 Le client reçoit : Set-Cookie: PART$\_$NUMBER=RIDING$\_$ROCKET$\_$0023; path=/ammo Quand le client demande une page dont l'url est dans ce serveur, sous le path /ammo", il envoie : Cookie: PART$\_$NUMBER=RIDING$\_$ROCKET$\_$0023; PART$\_$NUMBER=ROCKET$\_$LAUNCHER$\_$0001 Note : Il y a deux fois la valeur de nom PART_NUMBER dans le dernier cookie, parce que l'url correspondait à deux dénitions de cookies mémorisés APPELS DE METHODES A DISTANCE Pour transmettre des données d'un programme à un autre, à travers un réseau, on pourrait transmettre des objets à travers des connexions TCP. Cependant il faut encoder les objets proprement car tous les ordinateurs n'ont pas la même longueur d'entiers par exemple et les divers langages ou même diverses versions d'un même langage n'ont pas la même structure d'objets. C'est pourquoi on utilise des librairies qui savent exécuter des appels de méthodes à distance qui encodent de façon standard les diverses sortes de paramètres. Dans les sections suivantes, nous présenterons les RMI propres à Java. Ce protocole transmet ses données dans des connexions TCP. 93

42 Appels de méthodes à distance - RMI Cette section décrit le fonctionnement d'un appel RMI (Remote Method Invocation) et la génération des sources et chiers y relatifs, au moyen d'un exemple simple. La gure 5.22 montre un schéma d'un appel RMI. Dans cette gure, un serveur placé dans la station 2 (seconde zone grisée) mémorise la valeur d'un compteur et ore la méthode increment pour l'incrémenter et en retourner la valeur. Un client placé dans la station 1 (première zone grisée) appelle cette méthode. L'appel traverse le réseau grâce à des objets spéciques, le stub et le skeleton qui encapsule, respectivement décapsule les paramètres. Lorsque le serveur est chargé et enregistré dans le serveur de noms, un client peut créer, en cours d'exécution, l'objet-interface stub dont la classe est identiée dans le serveur de noms et appeler la méthode increment dans ce stub. Le stub encode les paramètres et les transmet au serveur. Du côté du serveur, l'objetinterface skeleton reçoit ces paramètres, eectue l'appel du service et retourne les résultats au stub qui peut eectuer le retour de méthode (3 èches notées 6). L'interface du serveur, tel qu'il est vu localement par un client est déni dans une classe interface, nommée Hello dans le cas présent. Cette interface doit être implémentée (implements) du côté du serveur, c'est-à-dire importée et pourvue de ses instructions, dans une autre classe, nommée ici HelloImpl. Un nom pour retrouver le serveur a également été choisi, HelloServer. Ce nom est utilisé par le skeleton pour s'enregistrer dans le serveur et par le stub pour retrouver le serveur. Ce nom est envoyé à un serveur de noms Java qui attend les ordres d'enregistrement et de recherche d'objets à travers un socket TCP dont le numéro de port est connu de tous. Ce serveur de noms est chargé et exécuté par la commande : rmiregistry& (socket par défaut = 1099) ou rmiregistry 2002& (socket 2002) Le programme rmiregistry doit être chargé sur le même ordinateur que le serveur, mais pas forcément par le même utilisateur. Le client peut évidemment être chargé sur un autre ordinateur. Le fonctionnement du service (initialisation, adressage, appel RMI) est géré par les appels ci-dessous, numérotés dans l'ordre d'exécution. Les numéros correspondent aux étapes notées dans la gure Charger le serveur de noms standard développé pour Java (rmiregistry). 2. Charger le serveur HelloImpl contenant la méthode increment (java HelloImpl). Le skeleton est automatiquement chargé par les méthodes que le programmeur doit importer dans HelloImpl. 3. Communiquer le nom et l'adresse du service au serveur de noms (automatique). 4. Charger le client (java HelloClient). 5. Le client demande l'adresse du service (ordinateur, port) au serveur de noms. La méthode appelée pour cela charge le stub (a) depuis le répertoire courant ou (b, voir Ÿ5.12.4) utilise un URL retourné par le serveur de noms pour le demander à un serveur HTTP. 6. Le client appelle la méthode increment dans le stub installé par l'appel précédent. 94

43 HelloImpl_Stub HelloImpl_Skel rmiregistry 1 5 Java naming service HelloClient x = obj.increment(); Hello obj; Client 6 increment(); 3 4 Station 1 Stub 6 2 HelloImpl Exrtends UnicastRemoteObject implements Hello Création Appel Skeleton 6 increment() { counter++; return counter; } Serveur Station 2 Fig Eléments actifs dans un RMI Création de l'application, serveur et client. L'interface Hello, placée ci-dessous, dénit le service oert par l'objet distant. Elle doit hériter Remote et prévoir qu'une exception de type RemoteException peut être générée. Rappelons qu'une interface ne contient aucun code. Les caractères ajoutés par le programmeur sont en gras. Hello.java 1 import java.rmi.remote ; 2 import java.rmi.remoteexception ; 3 public interface Hello extends Remote { 4 int increment() throws RemoteException ; 5 } Le code source ci-dessous implémente le service (lignes 11 à 14). Il inscrit le nom du service (HelloServer) dans le serveur de nom à la ligne 19. La ligne 5 gère le skeleton et les autres détails permettant au service d'être appelé de l'extérieur. Le numéro dans les commentaires correspond aux numéros de la liste de la gure HelloImpl.java 95

44 1 import java.rmi.naming ; 2 import java.rmi.remoteexception ; 3 import java.rmi.server.unicastremoteobject ; 4 5 public class HelloImpl extends UnicastRemoteObject 6 implements Hello { 7 int counter = 0 ; 8 public HelloImpl() throws RemoteException { // constructeur 9 super() ; 10 } 11 public int increment() { // service defini dans l'interface 12 counter++ ; 13 return counter ; 14 } 15 public static void main(string args[]) { 16 try { 17 HelloImpl obj = new HelloImpl() ; 18 // Bind this object to the name "HelloServer" (3.) 19 Naming.rebind("//ltisun15.ep.ch :2002/HelloServer",obj) ; 20 System.out.println("HelloServer bound in registry") ; 21 } catch (Exception e) { 22 System.out.println("HelloImpl err : " + e.getmessage()) ; 23 e.printstacktrace() ; 24 } 25 } 26 } Dans le programme ci-dessous, le client demande un objet de class Hello (= stub) au serveur (ligne 8). La fonction d'appel qui fait la demande instancie automatiquement l'objet retourné. Le programme appelle ensuite la méthode increment de cet objet (ligne 10). HelloClient.java 1 import java.rmi.naming ; 2 import java.rmi.remoteexception ; 3 public class HelloClient { 96

45 4 public static void main(string argv[]) { // main 5 String message = "blank" ; 6 Hello obj = null ; 7 try { (4.) 8 obj=(hello)naming.lookup( 9 "//ltisun15.ep.ch :2002/HelloServer") ; 10 message = "New value : " + obj.increment() + "\n" ; (6.) 11 System.out.println(message) ; 12 } catch (Exception e) { 13 System.out.println("Hello exception : " + e.getmessage()) ; 14 e.printstacktrace() ; 15 } 16 } 17 } Préparation et exécution des programmes Pour que les programmes retrouvent les liaisons entre les classes, on se positionne dans le même répertoire sur un serveur central depuis les deux ordinateurs à connecter. Le paragraphe montre comment faire autrement. On compile HelloImpl.java et HelloClient.java de la façon habituelle au moyen du compilateur javac 1. Cela crée les trois exécutables Hello.class, HelloImpl.class et HelloClient.class, Hello étant référencée par les deux autres. On appelle alors le programme de génération 2 du stub et du skeleton : rmic HelloImpl qui crée les deux chiers HelloImpl_Stub.class et HelloImpl_Skel.class. Le service de noms de Java est chargé au moyen de 3 : rmiregistry 2002& Ce programme doit avoir accès au stub, au skeleton et à l'interface Hello.class. Pour cela, exécuter rmiregistry à partir du répertoire qui contient ces chiers ou en indiquant le répertoire où ils se trouvent dans la variable CLASSPATH ou encore au moyen de l'option classpath. Le serveur est ensuite chargé comme tout programme Java. Il doit avoir accès au stub, au skeleton et à l'interface Hello.class. java HelloImpl Il faut ensuite déposer HelloImpl_Stub.class et Hello.class dans l'ordinateur dans lequel on veut exécuter le client, HelloClient.class. On peut alors taper java HelloClient Le client trouve la classe stub locale et l'instancie en appelant le serveur de noms. 7. Compiler et charger l'application qui réalise la fonction d'incré- EXERCICE mentation. 1 http ://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/javac.html 2 http ://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/rmic.html 3 http ://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/rmiregistry.html 97

46 Chargement du stub au moyen d'un serveur HTTP Il est possible de placer tous les chiers concernant le serveur dans un répertoire central (appelé webdir ci-après) accessible par un serveur HTTP. Cela évite de devoir placer le stub et HelloImpl_Stub.class, dans le répertoire du client. Dans ce cas, il faut alors ajouter un management de la sécurité dans les codes du serveur et du client, et dénir un chier (policy) décrivant la sécurité. Ce dernier chier peut également être déposé dans webdir. Pour insérer un manager de sécurité dans les chiers du client et du serveur, on ajoute la ligne suivante après la ligne 2, aussi bien dans HelloClient.java que dans HelloImpl.java. 1 import java.rmi.rmisecuritymanager ; De plus au début de chacun des mains on ajoute les lignes suivantes : 1 // Create and install a security manager 2 if (System.getSecurityManager() == null) { 3 System.setSecurityManager(new RMISecurityManager()) ; 4 } Dans webdir, on dépose Hello.class, HelloImpl.class et le chier policy. Le chier policy peut contenir les indications de sécurité suivantes pour un exemple (pas dans un programme en service réel!). 1 grant{ 2 // Allow everything for now 3 permission java.security.allpermission ; 4 } ; Dans le répertoire webdir, on exécute rmic HelloImpl pour créer HelloImpl_Stub.class et HelloImpl_Skel.class. Pour démarrer le nouveau système, on exécute alors les étapes suivantes : rmiregistry& ( Ne pas démarrer dans le répertoire WebDir sinon rmiregistry chargerait directement les stubs et les skeletons sans passer par HTTP et le chier policy ne serait pas utilisé! ) Le serveur HelloImpl est ensuite chargé au moyen de la commande suivante exécutée dans le répertoire webdir. java -Djava.rmi.server.codebase=http ://host.ch/ user/webdir/ -Djav a.security.policy=webdir/policy HelloImpl & 98

47 Fig Un réseau d'entreprise protégé par rewall les espaces étant notés au moyen de. Attention de mettre un / à la n du répertoire de codebase. L'adresse donnée dans codebase est utilisée par rmiregistry et par le serveur HelloImpl pour charger les stubs et les skeletons. Le répertoire indiqué dans le paramètre de policy est ici le même que celui qui est placé dans l'url de codebase. Le client peut maintenant être exécuté dans un répertoire qui ne contient que son exécutable HelloClient.class et le chier Hello.class. Il recevra toutes les indications pour construire son stub en utilisant le serveur de noms Compléments d'information L'exercice est tiré du tutorial référencé ci-dessous. Dans les explications données ci-dessus, tous les éléments qui ne faisaient pas strictement partie de la fonction RMI ont été éliminés pour simplier les explications au maximum. L'exercice du tutorial indique également comment créer un service qui n'est chargé que lorsqu'un client le demande (mode Activatable). http ://java.sun.com/products/jdk/rmi/index.html Un exemple encore plus complet est donné dans http ://java.sun.com/docs/books/tutorial/index.html 5.13 FIREWALLS Un rewall 4 est un ensemble d'ordinateurs et de logiciels qui limitent les messages qui passent entre le réseau interne d'une entreprise et le réseau Internet mondial en vue d'empêcher les attaques des systèmes informatiques de l'entreprise par des personnes malintentionnées (g. 5.23). Il y a diérents niveaux de protections, mais aucune solution n'est parfaite et plus on intervient dans le passage des messages, plus on gêne le personnel de l'institution protégée dans son utilisation du Web. D'autre part, on est bien obligé de laisser passer 4 Nous ne traduirons pas le nom de rewall car c'est sous ce nom qu'on trouve généralement le genre de système décrit dans cette section. 99

48 Fig Firewall composé de routeurs et d'un proxy le courrier, alors que c'est un des moyens les plus couramment utilisé pour introduire des virus dans les systèmes. Il y a donc un compromis a trouver entre des protections et des contraintes d'utilisation trop importantes. Le système de rewall le plus complet comporte un proxy placé entre deux routeurs selon la gure 5.24, mais suivant les besoins, on peut se contenter d'un proxy qui sait faire le routage ou d'un routeur qui possède quelques-unes des fonctions de ltrage dénies ci-dessous Routeurs Les routeurs n'ont pas d'adresse IP propre. Les paquets entrent dans le routeur et en ressortent avec la même adresse IP. Ils sont localisés au moyen du protocole ARP, (voir section 5.4). Les routeurs peuvent, en plus de leur fonction d'acheminement des données d'un réseau à l'autre, ltrer les paquets qui les traversent en fonction de leur adresse IP et de leur port TCP et bloquer les paquets qui ne correspondent pas à certains critères : par exemple ils ne laissent entrer que les paquets qui contiennent un numéro de port TCP de 80 (serveur Web) ou 25 (SMTP, le protocole du courrier électronique), de sorte que l'on ne puisse pas établir de l'extérieur une connection telnet, FTP ou toute autre connection à travers laquelle on pourrait modier les données internes du proxy ou d'un système de l'entreprise Proxy Le proxy est un ordinateur complet qui possède deux accès Internet diérents avec deux adresses IP. Les clients internes envoyent leurs paquets à l'adresse du proxy plutôt qu'à l'adresse du serveur de destination. Le serveur externe ne voit donc pas non plus l'adresse du client qui l'appelle. La gestion de la connection est généralement basée sur le protocole SOCKS selon le schéma représenté à la gure Selon ce protocole, le client demande au proxy (d'adresse IP et port : A, p) d'ouvrir une connection avec un serveur dont il donne l'adresse IP et le numéro de port (B, r). Le proxy teste si le client est autorisé à se connecter à ce serveur et dans l'armative, il se connecte luimême au serveur distant et retourne un numéro IP et un numéro de port (C, s) au client, puis copie tout ce qui vient de la connection liée au client dans celle qui est liée au serveur et tout ce qui vient de la connection du serveur distant dans la connection retournant au client. L'adresse IP C indiquée au client pourrait être identique au numéro A, mais ce genre de proxy gère souvent plusieurs adresses IP. 100

49 Fig Schéma d'utilisation de SOCKS Il est également possible de préparer une connection de l'intérieur et d'orir à un système de l'extérieur de s'y connecter. Ce système peut réaliser diérentes fonctions qui peuvent être classées dans les quatre catégories principales suivantes : Temps de réponse, économie de la bande passante Le premier rôle des proxys est la mise en cache des informations : une copie de chaque page demandée par un client est mise dans la mémoire du proxy, de sorte que si elle est demandée une deuxième fois par le même client ou par un autre client, il n'y a pas besoin de la repêcher sur le serveur initial. Cela rend la réponse beaucoup plus rapide et diminue le trac sur le réseau. Ce dernier point permet d'utiliser des connections avec moins de débit et donc d'économiser les cožts de transmissions (plusieurs millions de francs à l'epfl). Les mêmes pages sont souvent redemandées et le système peut avoir une ecacité de 20 à 70%. Cependant les pages peuvent changer sur le serveur soit par des mises à jour, soit par un programme qui peut générer certaines pages chaque fois qu'elles sont demandées (par exemple une page qui ache l'heure). Il faut donc avoir un critère qui indique combien de temps on peut garder une page en mémoire et quand il faut aller chercher une nouvelle version sur le serveur. Pour la gestion de ces page, l'en-tête du protocole HTTP dénit des champs qui indiquent quand la page retournée a été mise à jour, combien de temps elle sera encore valable ou si elle ne doit pas être mise en cache. Le client peut également spécier dans cet en-tête s'il tolère une page plus ou moins vieille ou s'il demande absolument la dernière version. Le proxy peut nalement envoyer une demande de retour conditionnel au serveur, en indiquant dans sa requête la date de la page qu'il possède dans son cache. Le serveur retourne dans ce cas une indication que la page n'a pas changé ou la page entière si elle a changé entre-temps. Contrôle d'accès Les proxys peuvent indentier les clients au moyen des protocoles d'autenti- cation et ainsi contrôler tout accès entre l'intérieur et l'extérieur de l'institution pour assurer sa sécurité. Filtrage avancé Certains proxys sont capables de comprendre les données manipulées par les applications des extrémités et d'interdire le passage à certaines informations délicates (pornographie, données secrètes). On peut ainsi limiter les sites acces- 101

50 sibles à partir d'une école qui veut donner un accès au Web à ses élèves. Les en-têtes HTTP contiennent certaines données qui ne sont pas indispensables, mais que l'institution peut ne pas vouloir divulguer : le champ FROM, par exemple, qui contient l'adresse du client. Il y a également des indications d'autentication qui peuvent passer par plusieurs proxys en cascade. Dans ce cas, le dernier proxy doit les enlever. Il est possible de réaliser des opérations similaires sur le protocole FTP, ou sur d'autres. Tous les protocoles qui ne sont pas traités par le proxy doivent en principe être bloqués, sinon il serait facile de passer à côté des mesures de sécurités. Journal et analyse Les proxys peuvent également enregistrer les demandes qui passent en vue de leur analyse. On peut en déduire les performances des systèmes, mais également bien sžr les performances du personnel de l'institution, par exemple analyser le temps passé à surfer sur le Web ou les sites visités par les employés. 102