Cours dintroduction ` TCP/IP a

Franois Laissus c <fr . laissus [at] laissus . fr> Version du 20 fvrier 2005 e

ii Copyright (c) 1999 - 2005 Franois Laissus <fr.laissus[at]laissus.fr> c

Les sources de ce document sont dites sous Unix (FreeBSD) ` laide de e e a lditeur de texte vi, et grs avec cvs. Lensemble du processus de fabricae ee tion est dcrit dans un chier Makefile (commande make). e A La mise en forme seectue grce au logiciel L TEX. Les gures sont desa sines sous X Window (X11) ` laide du logiciel xfig et intgres directement e a e e dans le document nal sous forme de PostScript encapsul. Les listings des e exemples de code C ont t fabriqus ` laide du logiciel a2ps et inclus dans ee e a le document nal galement en PostScript encapsul. e e La sortie papier a t imprime en PostScript sur une imprimante de type ee e laser, avec dvips. La version pdf est une transformation du format PostScript ` laide du logiciel pspdfm, enn la version HTML est traduite directement a A en HTML ` partir du format L TEX ` laide du logiciel latex2html. a a Tous les outils ou formats cits dans ce paragraphe sont en acc`s ou usage e e libre, sans versement de droit ` leurs auteurs respectifs. Quils en soient a remercis ! e Je remercie galement Jean-Jacques Dhnin et les nombreux lecteurs e e que je ne connais quau travers de leur e-mails, davoir bien voulu prendre le temps de relire lintgralit de ce cours et de me faire part des innombrables e e erreurs et coquilles typographiques quil comportait, merci encore !

Ce support de cours est en acc`s libre au format HTML ` lurl : e a http ://www.laissus.fr/cours/cours.html O` encore au format dvi, compress avec gzip : u e ftp ://ftp.laissus.fr/pub/cours/cours.dvi.gz O` encore au format PostScript (600 dpi), compress avec gzip : u e ftp ://ftp.laissus.fr/pub/cours/cours.ps.gz Le mme, mais compress avec bzip2 : e e ftp ://ftp.laissus.fr/pub/cours/cours.ps.bz2 O` encore au format pdf : u ftp ://ftp.laissus.fr/pub/cours/cours.pdf Le mme, mais compress avec zip : e e ftp ://ftp.laissus.fr/pub/cours/cours.pdf.zip
$Revision: 1.9 $ --- $Date: 2005/02/11 17:27:28 $ --- $Author: fla $

Table des mati`res e

Prface e xv

A
I

Introduction ` la pile ARPA a

Rseaux locaux e 1 Prambule . . . . . . . . . . . . . . . . . e 2 Gnralits - LANs . . . . . . . . . . . . e e e 2.1 Gnralits . . . . . . . . . . . . e e e 2.2 Mod`le de communication ISO . e 3 Rseaux locaux . . . . . . . . . . . . . . e 3.1 Quest-ce quun LAN ? . . . . . . 3.2 WAN - MAN . . . . . . . . . . . 3.3 Communications inter-rseaux . . e 4 Couche 2 - Liaison (Data Link) . . . . . 4.1 Caractristiques dEthernet . . . e 4.2 Dirences Ethernet - 802.2/802.3 e 5 Interconnexion - Technologie lmentaire ee 5.1 Raccordement . . . . . . . . . . . 5.2 Rpteur . . . . . . . . . . . . . . e e 5.3 Concentrateur . . . . . . . . . . . 5.4 Ponts . . . . . . . . . . . . . . . 5.5 Commutateurs . . . . . . . . . . 5.6 Passerelles Routeurs . . . . . . 6 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1
3 3 3 3 4 7 7 8 8 9 9 12 13 13 16 17 18 19 20 22 23 23 25 26 27 27 27 28 28 29

II Introduction ` IP a 1 TCP/IP et lInternet - Un peu dhistoire 2 Caractristiques de TCP/IP . . . . . . . e 3 Comparaison TCP/IP ISO . . . . . . 3.1 Couche Application Layer . . 3.2 Couche Transport Layer . . . 3.3 Couche Internet Layer . . . . 3.4 Couche Network Access . . . 4 Encapsulation dIP . . . . . . . . . . . . 5 Bibliographie . . . . . . . . . . . . . . .

iv

` TABLE DES MATIERES III Anatomie dune adresse IP 1 Adressage IP . . . . . . . . . . . . . . . . 1.1 Unicit de ladresse . . . . . . . . . e 1.2 Dlivrance des adresses IPv4 . . . . e 2 Anatomie dune adresse IP . . . . . . . . . 2.1 Dcomposition en classes . . . . . . e 2.2 Adresses particuli`res . . . . . . . . e 2.3 Sous-rseaux . . . . . . . . . . . . . e 2.4 CIDR . . . . . . . . . . . . . . . . 2.5 Prcisions sur le broadcast . . . . . e 3 Adressage multicast . . . . . . . . . . . . . 3.1 Adresse de groupe multicast . . . . 3.2 Adresse multicast et adresse MAC . 4 Conclusion et bibliographie . . . . . . . . . 31 31 31 32 33 33 34 35 37 38 39 39 40 41 43 43 44 47 50 50 52 53 53 54 54 55 56 58 58 59 60 61 62 64 66 68 69 70 71 73

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IV Protocole IP 1 Datagramme IP . . . . . . . . . . . . . . . . 1.1 Description de len-tte . . . . . . . . e 1.2 Fragmentation IP . . . . . . . . . . . 2 Protocole ARP . . . . . . . . . . . . . . . . 2.1 Fonctionnement . . . . . . . . . . . . 2.2 Format du datagramme . . . . . . . 2.3 Proxy ARP . . . . . . . . . . . . . . . 3 Protocole RARP . . . . . . . . . . . . . . . 4 Protocole ICMP . . . . . . . . . . . . . . . . 4.1 Le syst`me de messages derreur . . . e 4.2 Format des messages ICMP . . . . . 4.3 Quelques types de messages ICMP . . 5 Protocole IGMP . . . . . . . . . . . . . . . . 5.1 Description de len-tte . . . . . . . . e 5.2 Fonctionnement du protocole . . . . 5.3 Fonctionnement du Mbone . . . . . . 6 Routage IP . . . . . . . . . . . . . . . . . . 6.1 Table de routage . . . . . . . . . . . 6.2 Routage statique . . . . . . . . . . . 6.3 Routage dynamique . . . . . . . . . . 6.4 Dcouverte de routeur et propagation e 6.5 Message ICMP redirect . . . . . 6.6 Interface de loopback . . . . . . 7 Finalement, comment a marche ? . . . . . . c 8 Bibliographie . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . de routes . . . . . . . . . . . . . . . . . . . . . . . .

V Protocole UDP 75 1 UDP User Datagram Protocol . . . . . . . . . . . . . . . . . 75 1.1 Identication de la destination . . . . . . . . . . . . . . 75

` TABLE DES MATIERES 1.2 Description de len-tte . . . . . . . . . . . . . . . . . . 77 e 1.3 Ports rservs ports disponibles . . . . . . . . . . . 79 e e Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 83 83 85 88 88 89 91 91 92 95 95 96 96 97 100

VI Protocole TCP 1 TCP Transport Control Protocol . . . . 1.1 Caractristiques de TCP . . . . . . e 1.2 Description de len-tte . . . . . . . e 2 Dbut et clture dune connexion . . . . . e o 2.1 Etablissement dune connexion . . 2.2 Clture dune connexion . . . . . . o 3 Contrle du transport . . . . . . . . . . . o 3.1 Mcanisme de lacquittement . . . e 3.2 Fentres glissantes . . . . . . . . . e 4 Complments sur le fonctionnement de TCP e 4.1 Algorithme de Nagle . . . . . . . . 4.2 Dpart lent . . . . . . . . . . . . . e 4.3 Evitement de congestion . . . . . . 5 Paquets capturs, comments . . . . . . . e e 6 Bibliographie . . . . . . . . . . . . . . . .

Protocoles applicatifs
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

101
103 . 103 . 103 . 104 . 107 . 107 . 108 . 109 . 112 . 112 . 114 . 114 . 115 . 116 . 116 . 117 . 118 . 118 . 119 . 119 . 119 . 120

VII Serveur de noms - DNS 1 Gnralits sur le serveur de noms . . . . . . . . . e e e 1.1 Bref historique . . . . . . . . . . . . . . . 1.2 Syst`me hirarchis de nommage . . . . . e e e 2 Fonctionnement du DNS . . . . . . . . . . . . . . 2.1 Convention de nommage . . . . . . . . . . 2.2 Le Resolver . . . . . . . . . . . . . . . 2.3 Stratgie de fonctionnement . . . . . . . . e 2.4 Hirarchie de serveurs . . . . . . . . . . . e 2.5 Conversion dadresses IP en noms . . . . . 2.6 Conclusion . . . . . . . . . . . . . . . . . . 3 Scurisation du DNS . . . . . . . . . . . . . . . . e 3.1 TSIG/TKEY pour scuriser les transferts . e 3.2 DNSSEC pour scuriser les interrogations e 4 Mise ` jour dynamique . . . . . . . . . . . . . . . a 5 Format des Resource Record . . . . . . . . . . 5.1 RR de type SOA . . . . . . . . . . . . . . . 5.2 RR de type NS . . . . . . . . . . . . . . . 5.3 RR de type A . . . . . . . . . . . . . . . . 5.4 RR de type PTR . . . . . . . . . . . . . . . 5.5 RR de type MX . . . . . . . . . . . . . . . 5.6 RR de type CNAME . . . . . . . . . . . . .

vi

` TABLE DES MATIERES 5.7 Autres RR. . . . . . . . . . . . . . . BIND de lISC . . . . . . . . . . . . . . . . 6.1 Architecture du daemon named Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 121 121 122 125 125 125 126 127 129 129 131 133 135 137 137 139 142 143 143 143 146 147

6 7

VIII Courrier lectronique e 1 Gnralits sur le courrier lectronique . . . . . . . . e e e e 1.1 Mtaphore du courrier postal . . . . . . . . . e 1.2 Adresse lectronique . . . . . . . . . . . . . . e 2 Format dun E-mail - RFC 822 . . . . . . . . . . . 3 Protocole SMTP - RFC 821 . . . . . . . . . . . . . . 3.1 Protocole SMTP . . . . . . . . . . . . . . . . . 3.2 Principales commandes de SMTP . . . . . . . 3.3 Propagation du courrier lectronique . . . . . e 3.4 Courriers indsirables - Le spam . . . . . . . . e 4 Exemple de MTA - Sendmail et son environnement 4.1 Relations avec le DNS . . . . . . . . . . . . . 4.2 Relations avec lOS . . . . . . . . . . . . . . . 4.3 Le cas de POP . . . . . . . . . . . . . . . . . 4.4 Le cas de IMAP . . . . . . . . . . . . . . . . . 5 Conguration du Sendmail . . . . . . . . . . . . . . . 5.1 R`gles de recriture . . . . . . . . . . . . . . . e e 5.2 Exemple de sortie de debug . . . . . . . . . . 6 Bibliographie . . . . . . . . . . . . . . . . . . . . . . IX Anatomie dun serveur Web 1 Le protocole HTTP . . . . . . . . . . . . . . . 1.1 Exemple dchange avec http . . . . . e 1.2 Structure dun change . . . . . . . . . e 2 URIs et URLs . . . . . . . . . . . . . . . . . . 2.1 Scheme http . . . . . . . . . . . . . . . 3 Architecture interne du serveur Apache . . . . 3.1 Environnement dutilisation . . . . . . 3.2 Architecture interne . . . . . . . . . . 4 Principe de fonctionnement des CGIs . . . . . 4.1 CGI Mthode GET, sans argument e 4.2 CGI Mthode GET, avec arguments e 4.3 CGI Mthode POST . . . . . . . . e 4.4 Ecriture dune CGI en Perl . . . . . . 5 Conclusion Bibliographie . . . . . . . . . . . e X Elments de rseaux e 1 Htes ou services virtuels . . . . . . . o 2 Tunnel IP . . . . . . . . . . . . . . . 2.1 Tunnel IP avec linterface gif 2.2 IPsec et VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

149 . 149 . 150 . 150 . 154 . 154 . 156 . 156 . 158 . 169 . 169 . 170 . 171 . 172 . 173 . . . . 175 175 176 177 180

` TABLE DES MATIERES 3 4 5 6 7 Proxy . . . . . . . . . . . . . . . Translation dadresses . . . . . . 4.1 Cas de NATD . . . . . . . . Filtrage IP . . . . . . . . . . . . . 5.1 Le cas dipfw de FreeBSD Exemple complet . . . . . . . . . Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 185 187 189 189 192 195

vii

Programmation des sockets de Berkeley

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

197
. . . . . . . . . . . . . . . . 199 199 200 202 202 204 205 206 208 209 209 210 211 212 212 215 217

XI Gnralits sur les sockets de Berkeley e e e 1 Gnralits . . . . . . . . . . . . . . . . e e e 2 Prsentation des sockets . . . . . . . . . e 3 Etude des primitives . . . . . . . . . . . 4 Cration dune socket . . . . . . . . . . . e 5 Spcication dune adresse . . . . . . . . e 6 Connexion ` une adresse distante . . . . a 7 Envoyer des donnes . . . . . . . . . . . e 8 Recevoir des donnes . . . . . . . . . . . e 9 Spcier une le dattente . . . . . . . . e 10 Accepter une connexion . . . . . . . . . 11 Terminer une connexion . . . . . . . . . 12 Schma gnral dune connexion . . . . . e e e 13 Exemples de code client . . . . . . . 13.1 Client TCP DTCPcli . . . . . 13.2 Client UDP DUDPcli . . . . . 14 Conclusion et Bibliographie . . . . . . .

XII Complments sur les sockets Berkeley e 1 Rservation des ports . . . . . . . . . . . . . . . . e 1.1 Rservation de port Ancienne mthode e e 1.2 Rservation de port Nouvelle mthode . e e 2 Ordre des octets sur le rseau . . . . . . . . . . . e 3 Oprations sur les octets . . . . . . . . . . . . . . e 4 Conversion dadresses . . . . . . . . . . . . . . . . 5 Conversion hte adresse IP . . . . . . . . . . . . o 5.1 Une adresse IP ` partir dun nom dhte . a o 5.2 Un nom dhte ` partir dune adresse IP . o a 6 Conversion N de port service . . . . . . . . . . 6.1 Le numro ` partir du nom . . . . . . . . e a 6.2 Le nom ` partir du numro . . . . . . . . a e 7 Conversion nom de protocole N de protocole . 8 Diagnostic . . . . . . . . . . . . . . . . . . . . . . 9 Exemples de mise en application . . . . . . . . . . 10 Conclusion et bibliographie . . . . . . . . . . . . .

219 . 219 . 220 . 220 . 221 . 222 . 223 . 223 . 223 . 225 . 226 . 226 . 227 . 228 . 229 . 231 . 236

viii

` TABLE DES MATIERES e XIII Elments de serveurs 1 Type de serveurs . . . . . . . . . . . . 1.1 Serveurs itratif et concourant . e 1.2 Le choix dun protocole . . . . . 1.3 Quatre mod`les de serveurs . . e 2 Technologie lmentaire . . . . . . . . ee 2.1 Gestion des taches esclaves . 2.2 fork, vfork et rfork . . . . . . . 2.3 Processus lgers, les threads e 2.4 Programmation asynchrone . . 2.5 La primitive select . . . . . . 2.6 La primitive poll . . . . . . . . 3 Fonctionnement des daemons . . . . . 3.1 Programmation dun daemon . 3.2 Daemon syslogd . . . . . . . . 3.3 Fichier syslog.conf . . . . . . 3.4 Fonctions syslog . . . . . . . . 4 Exemple de daemon inetd . . . . . 4.1 Prsentation de inetd . . . . . e 5 Bibliographie . . . . . . . . . . . . . . 237 . 237 . 237 . 238 . 239 . 242 . 242 . 243 . 244 . 246 . 247 . 249 . 250 . 250 . 251 . 253 . 253 . 255 . 255 . 258

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

Table des gures

I.01 I.02 I.03 I.04 I.05 I.06 I.07 I.08 I.09 I.10 I.11 I.12 I.13 I.14 Mod`le en 7 couche de lOSI . . . . . . . e Exemple de LANs . . . . . . . . . . . . . trame Ethernet . . . . . . . . . . . . . . Dirences Ethernet 802.2/802.3 . . . . . e Interconnexion - Technologie lmentaire ee Prise vampire . . . . . . . . . . . . . . . Technologie de liaison . . . . . . . . . . . Rpteur . . . . . . . . . . . . . . . . . . e e Concentrateur . . . . . . . . . . . . . . . Dialogue sans pont . . . . . . . . . . . . Dialogue avec pont . . . . . . . . . . . . Commutateur . . . . . . . . . . . . . . . Fonction routage . . . . . . . . . . . . . Traduction de protocoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7 10 12 13 13 16 16 17 18 18 20 21 21

II.01 Comparaison ISO-ARPA . . . . . . . . . . . . . . . . . . . . . 26 II.02 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . 26 II.03 Encapsulation dIP . . . . . . . . . . . . . . . . . . . . . . . . 28 III.01 Dcomposition en classes . . . . . . . e III.02 Sous-rseaux . . . . . . . . . . . . . . e III.03 Puissances de 2 . . . . . . . . . . . . . III.04 Adresses de multicast . . . . . . . . . III.05 Adresse physique de multicast . . . . III.06 Usage combin des Adresses logique et e IV.01 Structure du datagramme IP . IV.02 Big endian - Little endian IV.03 Fragmentation IP . . . . . . . IV.04 Fragment ` transmettre . . . . a IV.05 Rsum de la fragmentation . . e e IV.06 Question ARP . . . . . . . . . IV.07 Rponse ARP . . . . . . . . . e IV.08 Datagramme ARP . . . . . . . IV.09 Message ICMP . . . . . . . . . IV.10 Format dun message ICMP . . IV.11 Echo request - Echo reply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 35 35 39 40 41 43 44 47 48 49 50 51 52 55 55 56

TABLE DES FIGURES IV.12 En-tte IGMP . . . . . . . . . . . . . . e IV.13 Fonctionnement IGMP . . . . . . . . . IV.14 Table de routage . . . . . . . . . . . . . IV.15 Situation rseau lors du netstat . . . . e IV.16 Exemple pour routage statique . . . . . IV.17 Exemple pour routage dynamique . . . IV.18 Topologie pour routage dynamique . . . IV.21 ICMP redirect . . . . . . . . . . . . IV.22 Interface de loopback . . . . . . . . IV.23 Illustration du routage direct et indirect V.01 V.02 V.03 V.04 V.05 Numro de port comme numro de e e UDP encapsul dans IP . . . . . . e Structure de len-tte UDP . . . . e Cas du checksum non nul . . . . . Quelques exemples de services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 59 62 64 65 66 67 69 70 71 76 77 78 78 79 83 85 88 89 90 91 92 93 99 106 109 109 110 111 121 127 133 134 137 139 142 144 151 156 162 164 165

service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

VI.01 TCP encapsul dans IP . . . . e VI.02 Structure de len-tte TCP . . e VI.03 Etablissement dune connexion VI.04 Clture dune connexion . . . . o VI.05 Emission dun rst . . . . . . . VI.06 Mcanisme de lacquittement . e VI.07 Principe de la fentre glissante e VI.08 Dtail de la fentre glissante . e e VI.09 Exemple de fentre glissante . e

VII.01 Organisation hirarchique des domaines e VII.02 Le resolver . . . . . . . . . . . . . . VII.03 Subdivision hirarchique des domaines e VII.03 Interrogation locale . . . . . . . . . . . VII.05 Interrogation distante . . . . . . . . . . VII.06 BIND de lISC . . . . . . . . . . . . . . VIII.01 Format dun e-mail . . . . . . . VIII.02 MUA - MTA - OS . . . . . . . VIII.03 Trajet dun mail . . . . . . . . VIII.04 MX primaire et secondaires . . VIII.05 Relation entre Sendmail et lOS VIII.06 Le cas de POP . . . . . . . . . VIII.07 R`gles de recriture . . . . . . e e IX.01 IX.02 IX.03 IX.04 IX.05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Structure dun message HTTP . . . Environnement syst`me . . . . . . . e Algorithme de gestion des processus Usage de la score board . . . . . Deux type de CGIs . . . . . . . . .

TABLE DES FIGURES X.01 X.02 X.03 X.04 X.05 X.06 X.07 X.08 X.04 X.10 X.11 X.12 X.13 X.14 X.15 XI.01 XI.02 XI.03 XI.04 XI.05 Serveur HTTP virtuel . . . . . Tunnel IP - Principe . . . . . . Tunnel IP - cas concrt . . . . e En-ttes dIPsec . . . . . . . . e Association 1 . . . . . . . . . . Association 2 . . . . . . . . . . Association 3 . . . . . . . . . . Association 4 . . . . . . . . . . Proxy . . . . . . . . . . . . . . Machine NAT en routeur . . . Natd sous FreeBSD . . . . . . Static Nat . . . . . . . . . . . . Conguration multiservices . . Conguration simple de ltrage Translation dadresse et ltrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 176 178 182 182 183 183 183 185 185 187 188 188 190 192 199 200 205 211 211

xi

Les sockets une famille de primitives . . . . . . . Relation stack IP, numro de port et process ID e Structure dadresse . . . . . . . . . . . . . . . . Relation clientserveur en mode connect . . . . e Relation clientserveur en mode non connect . e

XII.01 Ordre des octets sur le rseau . . . . . . . . . . . . . . . . . 221 e XIII.01 Quatre types de serveurs . . . . XIII.02 Excution avec et sans threads e XIII.03 Syslogd . . . . . . . . . . . . . XIII.04 Inetd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 244 252 256

xii

TABLE DES FIGURES

Liste des tableaux

xiv

LISTE DES TABLEAUX

Prface e
Attention ! Ce document nest quun support de cours, cest ` dire quil ne remplace pas les documents a cits dans la bibliographie qui termine chacun des chae pitres qui le composent.
Evidement imparfaites, pleines derreurs involontaires, et surtout incompl`tes, ces pages rclament avant tout votre indulgence de lecteur biene e veillant : rien nest constant, tout change comme le disait dj` Lao Tseu, ea 400 ans avant JC. Que dirait-il alors aujourdhui, concernant des rseaux ! ! e Ces cours saccompagnent de travaux pratiques dont le texte ne gure pas ici, ils sont principalement destins au Mast`re SIO, (Syst`mes Informatiques e e e Ouverts http ://www.sio.ecp.fr/), et sont orients Unix . e

Ce support est en acc`s libre, cest ` dire mis ` la dise a a position de tous pour un usage personnel ou collectif, sans but lucratif. Sa revente, sil y a lieu, ne peut tre e envisage que pour couvrir les frais induits par sa ree production. Enn, sa redistribution sous quelque forme que ce soit, ne peut se concevoir sans cette prface. e
Ne pas hsiter ` me contacter (<fr.laissus[at]laissus.fr>) en cas de doute e a sur lusage. En aucun cas lauteur ne pourra tre tenu responsable des consquences e e de lusage de ce document, qui est fourni tel quel et sans garantie daucune sorte. Lusage des informations contenues est donc plac sous la responsabilit e e pleine et enti`re du lecteur. e Enn, si vous pensez que la lecture de ce support vous a apport quelque e chose, que vous avez une remarque ` me faire, ou tout simplement me coma plimenter (a fait toujours plaisir quoi que lon puisse en dire ! :) sentez-vous c libres de menvoyer un courrier lectronique, je suis toujours ravi dapprendre e que ce travail a pu servir !

xvi

Prface e

Premi`re partie e Introduction ` la pile ARPA a

Chapitre I Rseaux locaux e

1 Prambule e

Ce cours nest pas un cours gnral sur les rseaux mais une prsentation e e e e minimale de cette technologie pour pouvoir aborder le cours de concepts et programmation TCP/IP sous UNIX. TCP/IP est le protocole le plus rpandu dans le monde grce ` lInternet. e a a En 1980 il ne comptait que quelques dizaines dhtes, en juin 1996 ce o nombre tait de 12 millions de machines, rparties en pr`s de 500 000 rseaux e e e e (Par comparaison, en fvrier 1995, les mmes chires taient 4 850 000 mae e e chines pour plus de 71 000 rseaux locaux). e Actuellement dans le monde (janvier 2003), le nombre de machines1 directement accessibles sur le rseau serait de 180 000 000 selon lISC2 . Pour e la france lAFNIC propose galement quelques statisques3 . . .Il nexiste pas e de botin gnral du rseau, par contre Bill Cheswick des Bell labs la e e e cartographi : e http ://www.cs.bell-labs.com/who/ches/map/gallery/index.html

2
2.1

Gnralits - LANs e e e
Gnralits e e e

Un rseau informatique met en relation des ordinateurs, comme un rseau e e tlphonique met en relation des personnes. ee Des ordinateurs sont dits en rseaux d`s lors quils partagent une e e technologie qui leur permet de communiquer ensemble. Le plus souvent cette technologie se matrialise physiquement par une e liaison avec un cble conducteur. Sur ce type de support, un signal lectrique a e vhicule les messages informatiques. Il existe dautres types de supports en e
1 2

Source http ://www.isc.org/ds/ Internet Software consortium 3 http ://www.nic.fr/statistiques/

Rseaux locaux e pleine expansion comme les liaisons par ondes hertziennes, rayon laser, infrarouge. . . Sans connaissance pralable concernant les rseaux informatiques on peut e e imaginer quantit dinterrogations ` partir de cette hypoth`se de raccordee a e ment : Comment reconnaitre un correspondant ? Comment dialoguer avec ? Comment diuser linformation ` plusieurs correspondants ? a Comment viter la cacophonie ? e Il y a til une hirarchie des machines ? e Il y a til un chef dorchestre ? ... Toutes ces questions (et bien dautres) trouveront une rponse dans ce e cycle de cours. Ces rponses sont gnralement formules dans un proe e e e tocole , une sorte de mode demploi des rseaux. Il y a des centaines de e protocoles dirents sur lInternet, certains sont tr`s populaires, dautres abe e solument pas.

2.2

Mod`le de communication ISO e

Le concept de base de tout ce cours est celui de la commutation de paquets , une vieille ide de linformatique4 contrairement ` lapproche par e a circuits virtuels plus utilise en tlphonie. e ee Les donnes ` transmettre dune machine ` une autre sont fragmentes e a a e ` lmission en petit blocs de quelques centaines doctets munis de ladresse a e du destinataire, envoyes sur le rseau et r-assembles ` la rception pour e e e e a e reproduire les donnes dorigine. e Ce concept facilite le partage des possibilits physiques du rseaux (bande e e passante) et est parfaitement adapt pour une implmentation sur machines e e squentielles travaillant en temps partag (plusieurs communications peuvent e e alors avoir lieux simultanment et sur une mme machine). e e Partant de ce concept, un mod`le darchitecture pour les protocoles de e communication a t dvelopp par lISO (International Standards Organisaee e e tion) entre 1977 et 1984. Ce mod`le sert souvent de rfrence pour dcrire la e ee e structure et le fonctionnement des protocoles de communication, mais nest pas une contrainte de spcication. e Ce mod`le se nomme OSI comme Open Systems Interconnect Reference e Model . Les constituants de ce mod`le sont si largement employs quil est e e dicile de parler de rseaux sans y faire rfrence. e ee ` Le mod`le OSI est constitu de sept couches. A chaque couche est ase e socie une fonction bien prcise, linformation traverse ces couches, chacune e e y apporte sa particularit. e Cette forme dorganisation nest pas de au hasard, cest celle sur lau quelle les informaticiens ont beaucoup travaill dans les annes soixantes e e
4

Conu par lAmricain Paul Baran et publi en 1964 c e e

Gnralits - LANs e e e pour dnir les caractristiques des syst`mes dexploitation. e e e Une couche ne dnit pas un protocole, elle dlimite un service qui peut e e tre ralis par plusieurs protocoles de direntes origines. Ainsi chaque e e e e couche peut contenir tous les protocoles que lon veut, pourvu que ceux-ci fournissent le service demand ` ce niveau du mod`le. ea e Un des intrts majeurs du mod`le en couches est de sparer la notion de ee e e communication, des probl`mes lis ` la technologie employe pour vhiculer e e a e e les donnes. e Pour mmoire (gure I.01) : e 7 La couche application (Application layer) est constitue des programmes e dapplication ou services, qui se servent du rseau. Ils ne sont pas e forcment accessibles ` lutilisateur car ils peuvent tre rservs ` un e a e e e a usage dadministration. 6 La couche de prsentation (Prsentation layer) met en forme les donnes e e e suivant les standards locaux ou particuliers ` lapplication. Comme, a par exemple passer dune reprsentation big endian ou ` une e a reprsentation little endian ou encore plus complexe comme celle e dcrite pas les XdR (eXternal Data Representation). e 5 La couche de session (Session layer) eectue laiguillage entre les divers services (7) qui communiquent simultanment ` travers le mme ordie a e nateur connect et le mme rseau. Deux utilisateurs dune mme mae e e e chine peuvent utiliser la mme application sans risque dinter-actions e parasites. 4 La couche de transport (Transport layer) garantie que le destinataire obtient exactement linformation qui lui a t envoye. Cette couche met ee e par exemple en uvre des r`gles de renvoi de linformation en cas dere reur de rception. e 3 La couche rseau (Network layer) isole les couches hautes du mod`le qui e e ne soccupent que de lutilisation du rseau, des couches basses qui ne e soccupent que de la transmission de linformation. 2 La couche de donne (Data link layer) eectue le travail de transmission e des donnes dune machine ` une autre. e a 1 La couche Physique (Physical layer) dnit les caractristiques du matriel e e e ncessaire pour mettre en oeuvre le signal de transmission, comme des e tensions, des frquences, la description dune prise. . . e

6 Mod`le en 7 couche de lOSI e

Rseaux locaux e

Protocole

Application Prsentation Session

S Protocole

Application Prsentation Session

S

Protocole

Transport
T S

Protocole

Transport
S T

Rseau
R T S

Protocole

Rseau
S T R

Liaison
L R T S

Protocole

Liaison
S T R L

Physique
L R T S

Protocole

Physique
S T R L

gure I.01

Du niveau 7 de lapplication, au niveau 4 du transport, linformation circule dans ce que lon appelle un message , au niveau 3 elle se nomme packet , puis frame au niveau 2 et signal au niveau 1. Chaque couche ne voit et ne sait communiquer quavec la couche qui la prc`de et celle qui la suit, avec le cas particulier des couches 1 et 7. e e Lintrt de travailler en couches est que lorsque les modalits dchanges ee e e entre chacune dentres elles sont prcisment dcrites, on peut changer lime e e plmentation et les spcicits de la couche elle-mme sans que cela aecte e e e e le reste de ldice. e Cest sur ce principe quest btie la suite de protocoles dsigne par a e e TCP/IP Quand deux applications A et B discutent entre-elles via le rseau, les e informations circulent de la couche 7 vers la couche 2 quand lapplication A envoie de linformation sur le rseau, et de la couche 2 vers la couche 7 pour e que lapplication B reoive linformation de A. c Le principe de base de cette discussion repose sur le fait que chaque couche du mod`le de la machine A est en relation uniquement avec son homologue e du mme niveau de la machine B. e Quand linformation descend de la couche 7 vers la couche 1, chaque couche en-capsule les donnes reues avant de les transmettre. Ainsi le e c volume dinformations sest accr de quelques centaines doctets arriv ` la u ea couche 1. De mani`re symtrique, quand linformation remonte de la couche phye e sique vers la couche Application, chaque couche prl`ve les octets qui lui sont ee propres, ainsi lapplication B ne voit-elle que les octets envoys par lapplie cation A, sans le dtail de lacheminement. e

3 Rseaux locaux e

Rseaux locaux e

Le probl`me intuitif et pratique qui se pose est de relier entre elles par un e cble toutes les machines qui veulent communiquer : cest impossible dabord a pour des raisons techniques, le monde est vaste, puis de politique demploi des ressources du rseau, tel rseau qui sert ` lenseignement ne doit pas pas e e a perturber le fonctionnement de tel processus industriel. La consquence est que les rseaux se dveloppent dabord en local, autour e e e dun centre dintrt commun, avant de se tourner (parfois) vers lextrieur. ee e

3.1

Quest-ce quun LAN ?

Le terme rseau local nest pas clairement dni, cependant tout le e e monde saccorde ` baptiser de la sorte un rseau, d`s lors quon lui reconnait a e e les caractristiques suivantes : e Cohabitation de plusieurs protocoles, Un mme mdia (mme cble par exemple) qui raccorde de multiples e e e a machines, peut tre de caractristiques direntes, e e e Une bande passante leve, partage par tous les htes e e e o La capacit de faire du broadcasting et du multicasting , e Une extension gographique de moins en moins limit, e e Un nombre de machines raccordes limit, e e Des relations entre les machines places sur un mode dgalit, (et non e e e par exemple sur un mode Ma tre/Esclave comme dans un rseau dont e la topologie serait en toile), e Une mise en uvre qui reste du domaine priv, cest ` dire qui ne e a dpend pas dun oprateur ociel de tlcommunications. e e ee Notez que les notions de bande passante et nombre limit (etc. . .) e sont volontairement qualitatives. Elles voluent rapidement avec le temps. e

Machine sur le LAN

gure I.02 Exemple de types de technologies utilises dans les LANs : e Token ring

8 IEEE 802 LANs Ethernet et Fast-Ethernet FDDI (anneau en bre optique) ATM 802.11b (wireless) ...

Rseaux locaux e

3.2

WAN - MAN

Un WAN (Wide Area Network) dsigne des ordinateurs connects entre e e direntes villes (Metropolitan Area Network) ou pays. La technologie utie lise est traditionnellement moins performante que celle dun LAN, cest par e exemple une ligne tlphonique loue fonctionnant ` 64 kbps, une liaison ee e a RNIS, ou encore une liaison transatlantique ` 1Mbits/secondes. a Les amliorations technologiques apportes aux LANs permettent de les e e tendre de plus en plus gographiquement, celles apportes aux WAN auge e e mentent considrablement les bandes passantes, ces deux tendances font que e la distinction entre ces deux types de rseaux est de moins en moins claire. e

3.3

Communications inter-rseaux e

Les rseaux sont appels ` communiquer entres eux et quand cela se e e a produit on parle de communications inter-rseaux ( internetworking ). e Le rle dune communication inter-rseaux est de gommer les ventuelles o e e dirences de technologie dchange pour permettre ` deux rseaux, ou plus, e e a e le partage de ressources communes, lchange dinformations. e Un moyen de faire communiquer deux rseaux distincts passe par lutilie sation de gateway ou passerelle. Un tel dispositif est parfois appel routeur (router), mais cest un abus e de langage. Les hommes se connectent sur les ordinateurs Les ordinateurs se connectent sur un rseau e Les rseaux sinter-connectent dans un internet e

4 Couche 2 - Liaison (Data Link)

Couche 2 - Liaison (Data Link)

La couche 2 la plus populaire est celle que lon identie sous le vocable Ethernet . On parle dun cble Ethernet, dune liaison Ethernet. . . a Ethernet est un standard publi en 1982 par DEC, Intel Corp. et Xee rox. Cette technique repose sur une mthode dacc`s et de contrle dite e e o CSMA/CD pour Carrier Sense, Multiple Access with Collision Detection Plus tard lIEEE (Institute of Electrical and Electronics Engineers) sous linstance de son commit 802, publia un ensemble de standards lg`rement e e e dirents, les plus connus pour TCP/IP sont 802.2 (Contrle logique de la e o liaison LLC5 ) et 802.3 (CSMA/CD) Dans le monde TCP/IP, lencapsulation des datagrammes IP est dcrite e dans la RFC 894 [Hornig 1984] pour les rseaux Ethernet et dans la RFC 1042 e [Postel et Reynolds 1988] pour les rseaux 802. e En r`gle gnrale, toute machine utilisant TCP/IP sur ce type de rseaux e e e e doit : 1. tre capable denvoyer et de recevoir un paquet conforme ` la RFC 894, e a 2. tre capable de recevoir des paquets conformes aux deux standards, e 3. Par contre il est seulement souhaitable que cette machine soit capable denvoyer des paquets conformes ` la RFC 1042. a Par dfaut le standard est donc celui de la RFC 894, si une machine peut e faire les deux, cela doit tre congurable. e

4.1

Caractristiques dEthernet e

Quelques principes fondamentaux 1. Le support de transmission est un Segment = bus = cble coaxial. Il a ny a pas de topologie particuli`re (boucle, toile, etc. . .). e e 2. Un quipement est raccord sur un cble par un transceiver : e e a Transmitter + receiver = transceiver (coupleur ou transducteur). On parle alors dune station Ethernet, celle-ci a une adresse unique. 3. Sur le cable circulent des trames, autant de paquets de bits. Il ny a pas de multiplexage en frquence, pas de full duplex 6 . Une trame mise e e par une station est reue par tous les coupleurs du rseau Ethernet, elle c e contient ladresse de lmetteur et celle du destinataire. e 4. Un coupleur doit tre ` lcoute des trames qui circulent sur le cble. Un e a e a coupleur connait sa propre adresse, ainsi si une trame lui est destine e il la prend, sinon il nen fait rien.
Logical Link Control les cartes Ethernet modernes utilisent 4 ls au lieu de deux et orent ansi des possibilits de full duplex que navaient pas leurs anctres des annes 80 e e e
6 5

10

Rseaux locaux e 5. Une station qui veut mettre attend que toutes les autres stations se e taisent. Autrement dit, si le cble est libre elle envoie sa trame, sinon a elle attend. Si deux stations mettent en mme temps il y a collision. Les deux e e trames sont alors inexploitables, les deux (ou plus) stations dtectent e ce fait et remettent ultrieurement leur paquet en attente. e e 6. Un rseau Ethernet est donc un rseau ` caract`re probabiliste car il ny e e a e a pas de chef dorchestre pour synchroniser les missions. Cette absence e conduit ` dire que cest un rseau galitaire, une sorte de runion sans a e e e animateur entre personnes polies En conclusion, la technologie Ethernet est simple, sa mise en uvre se fait ` faible cot. Points ` retenir : a u a Simplicit et faible cot e u Peu de fonctions optionnelles Pas de priorit e Pas de contrle sur lattitude des voisins o Dbit dau moins 10Mb/s (jusqu` 1000Mb/s thorique). e a e Performances peu dpendantes de la charge, sauf en cas de collisions e trop importantes. Format dune Frame Ethernet
Encapsulation Ethernet (RFC 894) Donnes encapsules

46 1500

Type des donnes Adresse de la source Adresse de la destination Prambule de synchronisation

Checksum

gure I.03 Quelques considrations en vrac : e D au dbit global de 10Mbits/seconde, le dbit est de 10 bits par u e e micro-seconde (en gros un facteur 1000 avec un cpu). Une trame a une longueur minimale (72) et une longueur maximale (1526). Si les donnes ne sont pas assez longues (46 octets) des carace t`res de remplissage sont ajouts ( padding ). e e Les octets circulent du premier octet du prambule au dernier octet du e CRC.

Couche 2 - Liaison (Data Link) A lintrieur de chaque octet le premier bit envoy est celui de poids e e faible, etc.. Le prambule et le SFD ( Start Frame Delimiter ) servent ` la syne a chronisation. Adresses dorigine et de destination sont celles respectivement de la machine mettrice et de la machine destinatrice. e Remarque importante : il faut conna ladresse de son correspondant tre ` pour pouvoir lui envoyer un paquet ! A ce stade de lexpos on ne sait e pas encore comment faire quand on ignore cette information. Le champ type est deux octets qui dsignent le type des donnes e e encapsules : e Type Donnes e 0800 IP 0806 ARP 0835 RARP 6000 DEC 6009 DEC 8019 DOMAIN ... ... Adresses IEEE802.3 ou Ethernet Quel que soit le standard ladressage est sur 6 octets, 48 bits. En fait cette adresse est divise en deux parties, les trois premiers octets e dsignent le constructeur, les trois derniers dsignent le numro de carte. e e e LIEEE assure lunicit des numro de constructeurs, par tranche de 224 e e 7 cartes Chaque constructeur assure lunicit du numro de chaque carte fae e 24 brique. En gros 2 cartes par classe dadresses. e On parle alors dadresse physique, ou hardware addresse . Pour le bon fonctionnement dun LAN il est absolument indispensable que toutes les stations aient une adresse physique dirente. Dans le cas contraire le rseau e e aura un comportement imprvisible, entre ne pas fonctionner du tout et des e comportements tr`s bizarres pour les applicatifs. e Nous reparlerons de lunicit de ladresse au cours de la prsentation des e e protocoles ARP et RARP (cf cours ARP/RARP pages 50 et 53). Exemple dadresse physique en reprsentation hexadcimale : e e 08 :00 :09 :35 :d5 :0b 08 :00 :09 est attribu ` HP8 . ea 35 :d5 :0b est ladresse de la carte

11

Dautres constructeurs, saisis au hasard des rseaux : e

On pourra consulter la RFC 1700 page 172 ETHERNET VENDOR ADDRESS COMPONENTS pour une liste exhaustive des constructeurs et leurs numros e
7

12 00 08 AA 00 ... :00 :00 :00 :10 :0C :20 :04 :5A Cisco Sun DEC 9 3Com ...

Rseaux locaux e

Attention, si tous les bits dadresse sont ` 1, cest une adresse de broada cast. Dans ce cas toutes les stations dun rseau sont destinatrices du paquet. e

4.2

Dirences Ethernet - 802.2/802.3 e

MAC dest. source

LLC 1 1 1

SNAP 3 2

Donnes 38 1492

6
dest.

6
source

RFC 894

gure I.04

On remarque que le champ taille de la frame 802.3 est ` la place a du champ type de la frame Ethernet. La direnciation seectue e ` partir de la valeur de ces deux octets. On remarque galement que a e le commit 802 a choisi de subdiviser la couche 2 ISO en deux sous e couches : MAC et LLC. Tous les numros de protocole sont suprieurs ` 150010 qui est la lone e a gueur maximale des donnes encapsules. Donc une valeur infrieure e e e ou gale ` ce seuil indique une frame 802.3. e a MAC = Medium Access Control LLC = Logical Link Control

Le plus petit numro de protocole est celui dIP : 0800 hexadcimal. Ce qui fait en e e dcimal : 8 162 + 0 161 + 0 160 = 2048 e

10

5 Interconnexion - Technologie lmentaire ee

13

Interconnexion - Technologie lmentaire ee

LLC MAC Cable transceiver Carte coupleur Ethernet Cable coaxial

Bus de station

Couche rseau

Couche liaison

Couche physique

gure I.05 Linterconnexion ne se limite pas au niveau Ethernet. Quelques notions de technologie de base et donc tr`s succintes sont e ncessaires pour bien comprendre la suite de ce cours. e

5.1

Raccordement

Une machine est raccorde ` un rseau en gnral par lintermdiaire de e a e e e e deux constituants :
Rseau local Prise "vampire" Transceiver

Carte rseau

Bus informatique

gure I.06 Dans cette technologie de raccordement le support est un gros cble jaune, a dit encore Thick Ethernet ou Ethernet standard, ou encore 10Base5 (10 comme 10Mbits/s, Base comme Baseband , 5 comme 500 m`tres). e 10Base5 Quelques particularits du 10Base5 : e

14

Rseaux locaux e Longueur maxi est 500 m`tres, pour un maximum de 100 stations. e Cest une vieille technologie tr`s bien normalise mais dpasse. e e e e Pas de perturbation quand on ajoute une station : la pose dune nouvelle prise ninterrompt pas la continuit du rseau. e e Cot non ngligeable. u e Dplacement dune station non ais, en plus on perd la prise vampire, e e elle reste sur le cble. a Pour les cblages rapides on prf`re le 10Base2 ou Thin Ethernet ou a ee encore Ethernet n (2 comme 200 m`tres). e 10Base2 Quelques particularits du 10Base2 : e Longueur maxi de 185 m`tres avec un maximum de 30 stations. e La topologie impose de mettre les stations en srie avec un minimum e de 0.5 m`tre entre chaque. e Le raccord se fait avec un transceiver en T (BNC bien connu des lectroniciens). e Il faut un bouchon de 50 ohms ` chaque extrmit du rseau (2). a e e e Technique tr`s bon march, souple, les cartes int`grent le transducteur. e e e Il faut rompre la continuit du rseau pour ajouter une nouvelle stae e tion, ce qui lempche de fonctionner durant lopration. Cest un ine e convnient de taille sur un rseau tr`s utilis. e e e e Cette technique est en outre assez sensible aux perturbations lectroe magntiques. e Les dsavantages du 10Base2 imposent gnralement lusage du 10BaseT e e e dans toute structure dpassant quelques machines (5 ` 10). Le 10BaseT r`gle e a e dnitivement le probl`me de lajout ou du retrait dune machine sur le LAN e e (T comme Twisted Pair ou paires torsades). e Cette technique impose lusage dune boite noire rseau nomme e e 11 HUB ou moyeu. Celle-ci simule la continuit dans le cas du retrait e dune station. 10BaseT Quelques particularits du 10BaseT : e Une double paire torsade de cble sut. e a La longueur maximale entre le moyeu et la station est de 100 m`tres. e Le moyeu impose une architecture en toile. e Le raccordement au transducteur se fait ` laide dune prise du type a RJ45, tr`s fragile (ne pas marcher dessus ! :). Le raccordement du HUB e au reste du rseau se fait par 10Base2, en bre optique, ou tout sime plement par cha nage avec un autre HUB ( Daisy chain ).
11

Voir le paragraphe V.3

Interconnexion - Technologie lmentaire ee Cette technique est dune tr`s grande souplesse dutilisation elle impose e nanmoins lachat de HUB, de lordre de 150  pour un 12 ports. e Cette technique des paires torsades est tr`s sensible aux perturbations e e lectromagntiques. lectromagntiques. e e e e Aujourdhui le 100BaseT quipe la majeur partie des quipements proe e fessionnels, 100 comme 100 Mbits/s. Enn la bre optique est utilise de plus en plus souvent pour eectuer e les liaisons point ` point. a Fibre optique Quelques particularits de la bre optique : e La plus utilise est la bre multimode 62.5/125.0 m e Usage dun transducteur optique pour assurer la transformation entre le signal lumineux (un laser) et le signal lectrique. e La distance maximale entre deux points est 1,5 km. La bre est insensible aux perturbations lectromagntiques, elle pere e met en outre le cblage de site important (plusieurs km2 ). a La bre permet datteindre des vitesses de transmission suprieures e aux 10Mbits/100Mbits/1000Mbits maintenant courants sur des paires de ls en cuivre. Les nouvelles technologies issues des recherches les plus rcentes proe mettent des bres multifrquences (1024 canaux par bre) avec pour e chaque canal une bande passante de plusieurs giga-octets. Ces nouveaux mdias auront une bande passante de plusieurs tra-octets par e e secondes. . . Son principal dsaventage est un cot lev au m`tre (de lordre dune e u e e e dizaine d pour un cble dun m`tre cinquante) et la ncessit davoir a e e e des transducteurs au raccordement de tous les appareils contenant de llectronique (serveur, switch, routeur). Un tel module peut coter de e u lordre de 500 ` 1000  . . . a Conclusion LEthernet est un jeu de construction tr`s bien maitris, une sorte de e e mcano car tous les supports sont mixables. e Sauf besoin ponctuel ne plus installer de 10Base5, utiliser plutt du o 10Base2 pour les structures exprimentales de quelques machines, avec des e utilisateurs responsables. Sinon il vaut mieux avoir des commutateurs (Cf V.5) pour relier les diverses machines du rseau, avec un pr-cblage en 10BaseT. Entre les e e a btiments utiliser de la bre optique. a Le cblage constitue les fondations dun rseau, le faire proprement a e dembl vite une source continuelle dennuis pas la suite ! Les besoins en e e bande passante daujourdhui ne prgurent sans doute pas encore les bee soins de demain (vido haute dnition sur tous les postes. . .), il faut donc e e

15

16 prvoir tr`s large d`s la conception initiale. e e e

Rseaux locaux e

Machine A

Machine B

Rseau physique

Ethernet 802.2 802.3 Technologie de liaison : ... Raccordement ==> drivation du rseau

gure I.07

5.2

Rpteur e e

` A une technologie particuli`re correspond forcment des limitations dues e e aux lois de la physique. Par exemple en technologie Ethernet la longueur maximale dun brin ne peut pas excder 180 m`tres. Pour pallier ` cette e e a dcience on utilise des rpteurs ( repeaters ). e e e Un rpteur : e e

R Rpteur R

Brins physiques diffrents mais meme LAN

gure I.08 Agit uniquement au niveau de la couche 1 ISO, cest un amplicateur de ligne avec ses avantages et aussi linconvnient de transmettre le e bruit sans discernement : il ny a aucun ltrage sur le contenu.

Interconnexion - Technologie lmentaire ee Relie deux brins dune mme technologie en un seul LAN car les trames e sont reproduites ` lidentique. a En 10Base5, lusage dun rpteur fait passer la limite des 500 m`tres e e e ` 1000 m`tres... a e Il ny a aucune administration particuli`re, sinon de brancher la boite e ` un emplacement pertinent. a Cest un lment bon march . ee e

17

5.3

Concentrateur

Un concentrateur (ou HUB , moyeu) :

Liaison "backbone"

HUB

Prises RJ45

Stations raccorder au rseau local

gure I.09 Est aussi nomm toile ou multirpteur. ee e e Les HUB nont pas dadresse Ethernet, sauf certains mod`les volus, e e e grables ` distance (TELNET,SNMP,. . .). On parle alors de hubs e a intelligents parcequils permettent dassocier des ports entres-eux. Un hub rp`te simplement les informations dun port ou du backbone e e vers tous les autres ports raccordables (le nombre de ports est une caracte ristique du hub). En cela il ne limite pas les collisions et namliore pas lusage e de la bande passante. Son seul intrt est de permettre le branchement ou ee le dbranchement des stations sans perturber le fonctionnement global du e rseau. En corollaire une station raccorde via un hub est vue sur le rseau e e e comme si elle tait raccorde comme par exemple en 10Base2. e e Les hubs peuvent tre cha es entres-eux ; souvent ils sont relis au backe n e bone local par une autre technologie que la paire torsade (bre optique, e 10Base2,. . .). Dans le cas de hubs intelligents les ports sont associs les uns aux e autres par groupes de fonctionnement.

18

Rseaux locaux e

5.4

Ponts

La technologie CSMA/CD atteint vite ses limites quand le rseau est ene combr. Une amlioration possible quand on ne peut pas changer de technoloe e gie (augmentation du dbit) est dutiliser un ou plusieurs ponts ( bridges ) e pour regrouper des machines qui ont entre-elles un dialogue privilgi. e e De nos jours le pont en tant que tel est de moins en moins utilis par e contre le principe de son fonctionnement se retrouve, entres autres, dans les commutateurs (paragraphe suivant) et dans les points dacc`s sans l e ( wireless ). Dialogue entre deux stations, sans pont :

Le dialogue entre A et B perturbe lventuel dialogue entre D et E.

gure I.10 Dialogue entre deux stations, avec pont :

Pont intelligent

Meme rseau local

gure I.11 Un pont : Agit au niveau de la couche 2, donc au niveau de la trame physique. Son action est plus que physique elle est aussi logique puisquil y a lecture et interprtation des octets vhiculs. Le rsultat de ce travail e e e e logique (apprentissage) consiste ` isoler le trac sur certains tronons a c dun LAN. A cause de ce travail on parle gnralement de ponts e e intelligents ou de ponts transparents car la phase dapprentissage est automatique ! Rduit le taux de collisions en rduisant le trac inutile, donc amliore e e e lusage de la bande passante. Sur la gure I.11 les machines A et B peuvent dialoguer sans pertuber le dialogue entre les machines D et E. Par contre dans le cas dun dialogue entre A et E le pont ne sert ` rien. a

Interconnexion - Technologie lmentaire ee Moins cher quun routeur et plus rapide (services rendus moins complets). Relie deux segments (ou plus) en un seul LAN, les trames transmises sont reproduites ` lidentique. a Un pont contient un cpu, il est en gnral administrable ` distance car e e a on peut agir sur la table de ltrages (ajout, contraintes de ltrages, etc...). Dans ce cas un pont a une adresse Ethernet. Les ponts interdisent que les rseaux aient des boucles, un protocole e nomm STP ( Spanning Tree Protocol ) dsactive automatiquement e e le ou les ponts qui occasionne(nt) un bouclage des trames. Il existe des ponts entre Ethernet et Token-ring, on parle alors de ponts ` translations . a Attention, un pont ne ltre pas broadcast et multicast .

19

5.5

Commutateurs

Aligner des stations sur un mme rseau local constitue une premi`re e e e tape simple et de faible cot pour un rseau local dentreprise. Le revers e u e dune telle architecture est que le nombre de collisions cro tr`s vite avec t e le trac, do` une baisse tr`s sensible de la rapidit des changes de ` ce u e e e u a gaspillage de la bande passante. Lusage de ponts peut constituer une premi`re solution mais elle nest pas e totalement satisfaisante dans tous les cas de gure, comme nous avons pu le remarquer au paragraphe prcdent. e e Depuis plusieures annes est apparue une nouvelle technologie nomme e e Intelligent Switching Hub (ISH) commutateur intelligent qui utilise le concept de commutation parall`le. e Daspect extrieur ces quipements se prsentent comme un hub mais ont e e e en interne un cpu susamment puissant pour mettre en uvre une logique de commutation rane. e Lorsquune trame se prsente sur lun des ports du commutateur elle est e (ou nest pas) re-route vers un autre port en fonction de ladresse physique e du destinataire. Il existe plusieurs dirences entre un pont et un commutae teur : Un commutateur peut mettre simultanment plusieurs ports en relae tion, sans que le dbit de chacun en soure. Par exemple un commue tateur de 4 ports en 10BaseT peut supporter deux connexions port source/port destination simultanes ` 10 Mbit/s chacune, ce qui donne e a un dbit global de 20 Mbit/s. e Dun point de vue plus thorique, un commutateur ` N ports ` 10 e a a Mbit/s chacun a un dbit maximum de N 10/2 = 20M bit/s. e Si une trame est ` destination dun port dj` occup, le commutateur a ea e la mmorise pour la dlivrer sitt le port disponible. e e o Un commutateur fonctionne comme un pont pour tablir sa carte des e adresses mais il peut aussi travailler ` partir dune table prcongure. a e e

20

Rseaux locaux e Un commutateur peut fonctionner par port (une seule station Ethernet par port) ou par segment (plusieurs stations Ethernet par port). Avec un commutateur, il est ais dorganiser un rseau en fonction de e e la porte des serveurs des postes clients associs. La gure I.12 illustre ce e e principe :

S1

S2

Serveurs gnraux

Commutateur intelligent

Hub

Client 1

Serveur local

Client 2

gure I.12

Le trac rseau entre le client 1 et le serveur S2 ne perturbe pas e le trac entre le client 2 et le serveur S1 . De mme le trac entre le e client 1 et le serveur local nest pas vu du client 2 . Les commutateurs tiquettent les trames avec un identicateur du VLAN e auquel elles appartiennent. Cette tiquette se rsume par deux octets ajouts e e e dans la trame, selon les recommandations du comit 802 (norme 802.1Q). e

5.6

Passerelles Routeurs

Pour raccorder deux LANs non forcment contigus il faut faire appel ` e a ce que lon dsigne une passerelle ( gateway ). Son rle est de prendre e o une dcision sur la route ` suivre et de convertir le format des donnes pour e a e tre compatible avec le rseau ` atteindre (en fonction de la route). e e a Souvent, et cest le cas avec TCP/IP, la fonction de conversion nest pas utilise, la fonction de routage donne alors son nom ` lappareil en question e a (ponyme), qui devient un routeur ( router ). e Le probl`me du routage entre A et B : e

Interconnexion - Technologie lmentaire ee

21

G A

Plusieurs chemins sont possibles pour aller de A B, do la ncessit dune stratgie.

gure I.13 La fonction passerelle consiste aussi en traduction de protocoles :

A G G G X25 Ethernet B

Modem Token ring Liaison rtc

gure I.14 Un routeur : Agit au niveau de la couche 3. Il prend des dcisions de destination. e Poss`de au moins deux interfaces rseau (pas forcment identiques). e e e Contient un cpu et un programme tr`s volu, il est administrable ` e e e a distance. Remplit galement les fonctions dun pont (B-routeur) mais les brins e ainsi relis ne forment en gnral plus un LAN car les adresses physiques e e e contenues dans les trames ne servent plus ` identier le destinataire. Il a faut une autre adresse qui dpend de la pile au-dessus (exemple adresse e IP). Il existe cependant des possibilits de simuler un mme LAN bien e e que les trame traversent un routeur (cf cours ARP (page 50)).

22

Rseaux locaux e

Bibliographie

Pour en savoir plus : RFC 0894 S C. Hornig, Standard for the transmission of IP datagrams over Ethernet networks , 04/01/1984. (Pages=3) (Format=.txt) RFC 1042 S J. Postel, J. Reynolds, Standard for the transmission of IP datagrams over IEEE 802 networks , 02/01/1988. (Pages=15) (Format=.txt) (Obsoletes RFC0948) Radia Perlman Interconnections Briges and Routeurs AddisonWesley Radia Perlman Interconnections Second Edition Briges, Routeurs, Switches, and Internetworking Protocoles AddisonWesley

Chapitre II Introduction ` IP a
1 TCP/IP et lInternet - Un peu dhistoire

En 1969 aux Etats Unis, lagence gouvernementale DARPA lance un projet de rseau exprimental, bas sur la commutation de paquets. Ce rseau, e e e e nomm ARPANET, fut construit dans le but dtudier les technologies de e e communications, indpendamment de toute contrainte commerciale1 e Un grand nombre de techniques de communication par modems datent de cette poque. e Lexprience dARPANET est alors si concluante que toutes les organie sations qui lui sont rattaches lutilisent quotidiennement pour pour leurs e messages de service. En 1975, le rseau passe ociellement du stade exprimental au stade e e oprationnel. e Le dveloppement dARPANET ne sarrte pas pour autant, les bases des e e protocoles TCP/IP sont dvelopps ` ce moment, donc apr`s que ARPANET e e a e soit oprationnel. e En Juin 1978 Jon Postel2 dnit IPv4 et en 1981 IP est standardis dans e e la RFC 791 [J. Postel 1981]. En 1983 les protocoles TCP/IP sont adopts comme un standard mie litaire et toutes les machines sur le rseau commencent ` lutiliser. Pour e a faciliter cette reconversion, la DARPA demande ` luniversit de Berkeley a e dimplmenter ces protocoles dans leur version (BSD) dunix. Ainsi come mence le mariage entre Unix et les protocoles TCP/IP. Lapport de lUniversit de Berkeley est majeur, tant au niveau thorique e e (concept des sockets) quau niveau de lutilisateur, avec des utilitaires tr`s e homog`nes avec ceux dj` existants sous Unix (rcp, rsh, rlogin. . .). e ea
Lanc en France en 1972, le projet Cyclades , sous la responsabilit de Louis Pouzin, e e tait galement bas sur la commutation de paquets et lusage de datagrammes. Il reliait e e e quelques grands centres universitaires en France (Lille, Paris, Grenoble,. . .) et en Europe. Il est rest oprationnel jusquen 1978, date ` laquelle faute de crdit il a t abandonn e e a e ee e au prot de X25, prfr par les oprateurs de tlcoms nationaux. eee e ee 2 Jon Postel est dcd le 16 Octobre 1998 ` lge de 55 ans, cest le premier pionner de e e e a a lInternet dcd, on peut consulter par exemple : http ://www.isi.edu/postel.html e e e
1

24

Introduction ` IP a Depuis cette poque, un nouveau terme est apparu pour dsigner cette e e interconnexion de rseaux, lInternet, avec un i majuscule. e Le succ`s de cette technologie est alors tr`s important et suscite un e e intrt croissant de la part dacteurs tr`s divers, et en particulier La Naee e tional Science Foundation qui y voit un intrt majeur pour la recherche ee scientique et soutient donc ce nouveau moyen de mettre en communication tous les chercheurs. Depuis 1990, ARPANET nest plus, pourtant le terme Internet demeure il dsigne maintenant un espace de communication qui englobe la plan`te e e tout enti`re. Des centaines de milliers de sites aux Etats Unis, en Europe et e en Asie y sont connects. e Depuis 1994, lInternet sest ouvert au commerce, surtout avec lapparition en 1991 dun nouvel outil de consultation, le World Wide Web ou Web et ses interfaces populaires : Mosaic3 , Netscape, Mozilla, Firefox, Konqueror. . .La liste nest pas exhaustive ! Depuis 1995, pour faire face ` sa popularit fortement croissante et aux a e demandes de transactions scurises, le protocole volue et une nouvelle vere e e sion, la version 6 (IPng), est dnie et en cours de dploiement exprimental4 . e e e Les protocoles dsigns par TCP/IP ont galement envahi les rseaux e e e e locaux eux-mmes, car il est plus facile dutiliser les mmes protocoles en e e interne et en externe. Pour les utilisateurs, lacc`s ` lInternet est possible ` laide dune collece a a tion de programmes spcialiss si faciles ` utiliser que lon peut ignorer tout e e a (ou presque) de leur fonctionnement interne. Seul les programmeurs dapplications rseaux et les administrateurs de e syst`mes ont besoin den conna les arcanes. e tre Les services rseaux les plus populaires sont principalement : e Le courrier lectronique qui permet lchange de messages entres usae e gers. Les dizaines de milliers de forums de discussion ( news ). Le transfert de chiers entre machines ( ftp et ses drivs comme e e fetch ou wget ). Le remote login , ou ses quivalents, qui permet ` un utilisateur de e a se connecter sur un site distant, depuis son calculateur local. Les serveurs inter-actifs. Les anciens se nommaient archie, gopher, veronica, wais... Dsormais ils sont rendus obsol`tes par le web e e (protocole http). Puis maintenant la radio, la vidoconfrence, la ralit virtuelle avec le e e e e VRML, le chat , les bourses dchanges point ` point. . . e a En conclusion de ce paragraphe sur lhistorique on peut dire que lInternet est une collection apparemment anarchique (il ny a pas de structure hie rarchique et centralise) de rseaux inter-connects et appartenant ` divers e e e a
http ://archive.ncsa.uiuc.edu/SDG/Software/Mosaic/NCSAMosaicHome.html Un rcent discours de ministre tente dailleurs de lui donner un impulsion noue velle :http ://www.recherche.gouv.fr/discours/2002/dhourtin.htm
4 3

2 Caractristiques de TCP/IP e propritaires. e On distingue trois niveaux : les rseaux au sein des organisations (lans), e les rseaux rgionaux et les rseaux de transit. e e e Le site de lassociation Fnet indique quelques pointeurs intressants sur e 5 lhistorique de lInternet (en anglais).

25

Caractristiques de TCP/IP e

Le succ`s de TCP/IP, sil vient dabord dun choix du gouvernement e amricain, sappuit ensuite sur des caractristiques intressantes : e e e 1. Cest un protocole ouvert, les sources (C) en sont disponibles gratuitement et ont t dvelopps indpendamment dune architecture paree e e e ticuli`re, dun syst`me dexploitation particulier, dune structure come e merciale propritaire. Ils sont donc thoriquement transportables sur e e nimporte quel type de plate-forme, ce qui est prouv de nos jours. e 2. Ce protocole est indpendant du support physique du rseau. Cela pere e met ` TCP/IP dtre vhicul par des supports et des technologies a e e e aussi dirents quune ligne srie, un cble coaxial Ethernet, une liaie e a son loue, un rseau token-ring, une liaison radio (satellites, wireless e e 802.11a/b/g), une liaison FDDI 600Mbits, une liaison par rayon laser, infrarouge, xDSL, ATM, bre optique, la liste des supports et des technologies nest pas exhaustive. . . 3. Le mode dadressage est commun ` tous les utilisateurs de TCP/IP a quelle que soit la plate-forme qui lutilise. Si lunicit de ladresse est e respecte, les communications aboutissent mme si les htes sont aux e e o antipodes. 4. Les protocoles de hauts niveaux sont standardiss ce qui permet des e dveloppements largement rpandus sur tous types de machines. e e La majeurs partie des informations relatives ` ces protocoles sont publies a e dans les RFCs (Requests For Comments). Les RFCs contiennent les derni`res e versions des spcications de tous les protocoles TCP/IP, ainsi que bien e dautres informations comme des propositions damliorations des outils ace tuels, la description de nouveaux protocoles, des commentaires sur la gestion des rseaux, la liste nest pas exhaustive. e

http ://www.fnet.fr/history/

26

Introduction ` IP a

Comparaison TCP/IP ISO

La suite de protocoles dsigne par TCP/IP, ou encore pile ARPA , e e est construite sur un mod`le en couches moins complet que la proposition e de lISO. Quatre couches sont susantes pour dnir larchitecture de ce e protocole. 4 Couche Application (Application layer). 3 Couche Transport (Transport layer). 2 Couche Internet (Internet layer). 1 Couche interface rseau (Network access layer). e 0 Matriel (nest pas une couche comprise dans le protocole). e

Application Prsentation Session Transport Rseau Liaison Physique 4 3 2 1 0 Application Transport Internet Interface Matriel

Pile Arpa

gure II.01 La gure II.01 met en comparaison les fonctionnalits des couches du e mod`le OSI et celles des protocoles TCP/IP. e

telnet

X11 TCP

http t/tcp

dns

nfs xdr rpc UDP

arp rarp Ethernet ATM

IP fibre optique

igmp

icmp ...

gure II.02

Comparaison TCP/IP ISO La gure II.02 donne une vue densemble de larchitecture logicielle avec protocoles dapplications de la famille IP. Ils sont tr`s nombreux, non tous e ici reprsents et il sen faut de beaucoup. e e IP Internet Protocol TCP Transport Control Protocol UDP User Datagram Protocol Les autres protocoles ne sont pas dtaills, nous aurons loccasion den e e parler ultrieurement. e

27

3.1

Couche Application Layer

Au plus haut niveau les utilisateurs invoquent les programmes qui permettent lacc`s au rseau. e e Chaque programme dapplication interagit avec la couche de transport pour envoyer ou recevoir des donnes. En fonction des caractristiques de e e lchange le programme a choisi un mode de transmission ` la couche de e a transport. La plus grande proportion des applications laissent ` la couche de transa port le soin deectuer le travail de Session , nanmoins il est possible e pour certaines applications de court-circuiter cette fonctionnalit pour agir e directement au niveau Rseau , comme on peut lobserver sur la gure e II.02 ` droite. a

3.2

Couche Transport Layer

La principale tche de la couche de transport est de fournir la communia cation dun programme dapplication ` un autre. Une telle communication a est souvent qualie de point ` point . e a Cette couche peut avoir ` rguler le ot de donnes et ` assurer la abilit a e e a e du transfert : les octets reus doivent tre identiques aux octets envoys. Cest c e e pourquoi cette couche doit grer des checksums et savoir re-mettre des e e paquets mal arrivs. e Cette couche divise le ux de donnes en paquets (terminologie de lISO) e et passe chacun avec une adresse de destination au niveau infrieur. e De plus, et cest surtout valable pour les syst`mes dexploitation multie tches multi-utilisateurs (Unix,. . .), de multiples processus appartenant ` a a des utilisateurs dirents et pour des programmes dapplications dirents, e e acc`dent au rseau au mme moment, ce qui implique la capacit de multie e e e plexer et de dmultiplexer les donnes, suivant quelles vont vers le rseaux e e e ou vers les programmes dapplication ( Session ).

3.3

Couche Internet Layer

Cette couche reoit des data-grammes en provenance de la couche rseau, c e quelle doit analyser pour dterminer sils lui sont adresss ou pas. Dans e e

28

Introduction ` IP a le premier cas elle doit dcapsuler son en-tte du data-gramme pour e e transmettre les donnes ` la couche de transport et au bon protocole de e a cette couche (TCP, UDP...), dans le deuxi`me cas elle les ignore. e Cette couche prend aussi en charge la communication de machine ` maa chine. Elle accepte des requtes venant de la couche de transport avec une e identication de la machine vers laquelle le paquet doit tre envoy. e e Elle utilise alors lalgorithme de routage (page 65) pour dcider si le pae quet doit tre envoy vers une passerelle ou vers une machine directement e e accessible. Enn cette couche g`re les datagrammes des protocoles ICMP et IGMP. e

3.4

Couche Network Access

Le protocole dans cette couche dnit le moyen pour un syst`me de e e dlivrer linformation ` un autre syst`me physiquement reli. Il dnit come a e e e ment les data-grammes IP sont transmis. La dnition de ceux-ci reste e indpendante de la couche rseau, ce qui leur permet de sadapter ` chaque e e a nouvelle technologie au fur et ` mesure de leur apparition. a Avant de sintresser au dtail des data-grammes IP, nous allons examiner e e le probl`me de ladressage IP, dans le chapitre suivant. e

Encapsulation dIP
A Application Message Transport Paquet Internet Datagramme Network Trame Network Internet Transport B Application

Rseau physique

gure II.03 Comme nous lavons dcrit avec le mod`le des couches OSI, les couches e e IP fonctionnent par encapsulations progressives.

5 Bibliographie Chaque couche en-capsule la prcdente avec les informations de contrle e e o quelle destine ` la couche de mme niveau sur la machine distante. a e Cet ajout est nomm header (en-tte) parce-quil est plac en tte des e e e e donnes ` transmettre. e a Application Transport Internet Network | | Header | | Header | Header | | Header | Header | Header | datas datas datas datas | | | |

29

La taille des headers dpend des protocoles utiliss. Pour la couche e e IP le protocole comporte en standard 5 mots de 32 bits, mme chose pour la e 6 couche TCP .

Bibliographie

Pour en savoir plus :

RFC 0791 S J. Postel, Internet Protocol , 09/01/1981. (Pages=45) (Format=.txt) (Obsoletes RFC0760) La Recherche Numro spcial Internet numro 238 de fvrier 2000 e e e e

5 mots de 32 bits = 5 4 octets = 20 octets

30

Introduction ` IP a

Chapitre III Anatomie dune adresse IP

1 Adressage IP

Nous avons dit que lInternet est un rseau virtuel, construit par intercone nexion de rseaux physiques via des passerelles. Ce chapitre parle de ladrese sage, le maillon essentiel des protocoles TCP/IP pour rendre transparents les dtails physiques des rseaux et faire apparaitre lInternet comme une entit e e e uniforme.

1.1

Unicit de ladresse e

Un syst`me de communication doit pouvoir permettre ` nimporte quel e a hte de se mettre en relation avec nimporte quel autre. An quil ny ait o pas dambigu e pour la reconnaissance des htes possibles, il est absolument t o ncssaire dadmettre un principe gnral didentication. e e e e Lorsque lon veut tablir une communication, il est intuitivement indise pensable de possder trois informations : e 1. Le nom de la machine distante, 2. son adresse, 3. la route ` suivre pour y parvenir. a Le nom dit qui est lhte distant, ladresse nous dit o` il se trouve o u et la route comment on y parvient. En r`gle gnrale les utilisateurs prf`rent des noms symboliques pour e e e ee identier les machines tandis que les processeurs des machines sont plus ` a laise avec les nombres. Les adresses IP (version 4) sont standardises sous forme dun nombre e de 32 bits qui permet ` la fois lidentication de chaque hte et du rseau a o e auquel il appartient. Le choix des nombres composants une adresse IP nest pas laiss au hasard, au contraire il fait lobjet dune attention particuli`re e e notamment pour faciliter les oprations de routage. e Nous remettons ` plus tard la correspondance entre ce nombre et une a ventuelle reprsentation symbolique. e e

32

Anatomie dune adresse IP Chaque adresse IP contient donc deux informations basiques, une adresse de rseau et une adresse dhte. La combinaison des deux dsigne de mani`re e o e e unique une machine et une seule sur lInternet.

1.2

Dlivrance des adresses IPv4 e

On distingue deux types dadresses IP. Les adresses prives que tout admie nistrateur de rseau peut sattribuer librement pourvu quelle ne soient pas e routes sur lInternet, et les adresses publiques, dlivres par une structure e e e mondiale qui en assure lunicit. Ce dernier point est capital pour assurer e lecience du routage, comme nous le verrons au chapitre suivant. Les adresses ` utiliser sur les rseaux privs sont dcrites par la RFC 1918 a e e e [Y. Rekhter,. . .1996] : 10.0.0.0 10.255.255.255 (ancien Arpanet !) 172.16.0.0 172.31.255.255 192.168.0.0 192.168.255.255 Les adresses publiques (souvent une seule), sont le plus gnralement foure e 1 nies par le FAI . Quelles soient dlivres de mani`re temporaire ou attribues e e e e pour le long terme, elles doivent tre uniques sur le rseau. La question est e e donc de savoir de qui le FAI les obtient. Cest LICANN (Internet Corporation for Assigned Names and Numbers)2 qui est charg au niveau mondial de la gestion de lespace dadressage e IP. Il dnit les procdures dattribution et de rsolution de conits dans e e e lattribution des adresses, mais dl`gue le dtail de la gestion de ces resee e sources ` des instances rgionales puis locales, dans chaque pays, appeles a e e Regional Internet Registries ou RIR. Il y a actuellement trois Regional Internet Registries oprationnels : e 3 4 lAPNIC pour la rgion Asie-Pacique, lARIN pour lAmrique et enn e e 5 le RIPE NCC pour lEurope (lAfriNIC pour lAfrique ainsi que le LACNIC pour lAmrique Latine sont en cours de cration). Pour ce qui nous e e concerne en Europe cest donc le RIPE NCC (Rseaux IP europen Network e e Coordination Centre) qui dlivre les adresses que nous utilisons. e Les adresses IP sont alloues ` lutilisateur nal qui en fait la demande e a par un Local Internet Registry , ou LIR, autoris par le RIPE NCC. e Un LIR est gnralement un FAI ou une grande organisation (entreprise e e multinationale). Il est sous lautorit de linstance rgionale de gestion de e e ladressage. Ainsi pour un utilisateur (quelle que soit sa taille) changer de FAI implique aussi de changer de plan dadressage IP, lorsque celles-ci ont
1 2

Fournisseur dAcc`s Internet e http ://www.icann.org 3 http ://www.apnic.net 4 http ://www.arin.net/ 5 http ://www.ripe.net/

2 Anatomie dune adresse IP t alloues statiquement par le LIR. Les adresses IP sont alors restitues ee e e puis r-attribues ` dautres utilisateurs. e e a On compte plus de 2000 de LIRs orant leurs services en Europe selon le RIPE NCC6

33

Anatomie dune adresse IP

Une adresse IP est un nombre de 32 bits que lon a coutume de reprsenter e sous forme de quatre entiers de huit bits, spars par des points (comme au e e paragraphe 1.2 ci-dessus). La partie rseau de ladresse IP vient toujours en tte, la partie hte est e e o donc toujours en queue. Lintrt de cette reprsentation est immdiat quand on sait que la partie ee e e rseau et donc la partie hte sont presque toujours codes sur un nombre e o e entier doctets. Ainsi, on a principalement les trois formes suivantes : Classe A Un octet rseau, trois octets dhtes. e o Classe B Deux octets rseau, deux octets dhtes. e o Classe C Trois octets rseau, un octet dhte. e o

2.1
Classe

Dcomposition en classes e
Nombre de rseaux/machines

Si le premier bit est 0, ladresse est de classe A. On dispose de 7 bits 1.x.y.z 127.x.y.z A 127 rseaux pour identier le rseau et de 24 bits e 16 777 216 machines (2^24) pour identier lhte. On a donc les o rseaux de 1 ` 127 et 224 htes pose a o 128.0.x.y 191.255.x.y 16 384 rseaux (2^14) sibles, cest ` dire 16 777 216 maa B 65536 machines (2^16) chines direntes (de 0 ` 16 777 215). e a 192.0.0.z 223.255.255.z Les lecteurs attentifs auront remarqu que le rseau 0 nest pas utie e C 2 097 152 rseaux (2^21) 256 machines (2^8) lis, il a une signication particuli`re e e ( tous les rseaux ) comme on le e D 224.0.0.0 239.255.255.255 prcisera au paragraphe suivant. e De mme, la machine 0 nest pas e utilise, tout comme la machine ayant e E 240.0.0.0 247.255.255.255 le plus fort numro dans le rseau e e (tous les bits de la partie hte ` o a gure III.01 1, ici 16 777 215), ce qui rduit de e deux units le nombre des machines e Pour distinguer les classes A, B, nommables. Il reste donc seulement C, D et E il faut examiner les bits de 16 777 214 machines adressables dans une classe A ! poids fort de loctet de poids fort :
6

Voir http ://www.ripe.net/ripe/docs/ar2003.html

34

Anatomie dune adresse IP Si les deux premiers bits sont 10 , ladresse est de classe B. Il reste 14 bits pour identier le rseau et 16 bits pour identier la machine. Ce e 14 qui fait 2 = 16 384 rseaux (128.0 ` 191.255) et 65 534 (65 536 2) e a machines. Si les trois premiers bits sont 110 , ladresse est de classe C. Il reste 21 bits pour identier le rseau et 8 bits pour identier la machine. Ce qui e 21 fait 2 = 2 097 152 rseaux (de 192.0.0 ` 223.255.255) et 254 (256 2) e a machines. Si les quatre premiers bits de ladresse sont 1110 , il sagit dune classe dadressage spciale, la classe D. Cette classe est prvue pour e e faire du multicast , ou multipoint. (RFC 1112 [S. Deering, 1989]), contrairement aux trois premi`res classes qui sont ddies ` l unicast e e e a ou point ` point. a Ces adresses forment une catgorie ` part, nous en reparlons au parae a graphe 3. Si les quatre premiers bits de ladresse sont 1111 , il sagit dune classe exprimentale, la classe E. La RFC 1700 prcise Class E ade e dresses are reserved for future use mais nindique pas de quel futur il sagit. . . Enn, pour conclure ce paragraphe, calculons le nombre dhtes adreso sables thoriquement ` laide des classes A, B et C : e a 127 16777212 + 16384 65534 + 2097152 254 = 3737091588
7

Ce total, pour tre plus exact, doit tre amput des 17 890 780 htes des e e e o rseaux privs prvus dans la RFC 19188 , soit donc tout de mme au total e e e e 3 719 200 808 htes adressables en utilisant IPv4 ! o

2.2

Adresses particuli`res e

Certaines adresses IP ont une signication particuli`re ! e Par convention le numro 0 dhte nest pas attribu. Si une adresse IP e o e contient cette zone nulle cela signie que lon adresse le rseau lui-mme e e et aucun hte en particulier, donc en r`gle gnrale lhte lui-mme. Par o e e e o e exemple, sur toutes les machines, ladresse 127.0.0.0 indique la machine ellemme (loopback Cf chapitre IP page 43), indpendamment de ladresse e e rseau sur lequel elle est connecte. e e ` A linverse, si tous les bits de la partie hte sont ` 1, cela dsigne toutes o a e les machines du rseaux, cest ce que lon appele une adresse de broadcast , e cest ` dire une information adresse ` tout le monde. a e a On vite au maximum lusage dune telle adresse IP sur les rseaux, pour e e des raisons decacit (encombrement de la bande passante). e
7 8

Sous shell, tapez : echo "127*16777212+16384*65534+2097152*254"|bc 16777212 + 16 65534 + 256 254 = 17890780

Sous-rseaux e Quelques exemples dadresses avec une signication particuli`re : e 0.0.0.0 0.0.0.1 255.255.255.255 138.195.52.1 138.195.0.0 193.104.1.255 127.0.0.1 Hte inconnu, sur ce rseau o e Lhte 1 de ce rseau o e Tous les htes o Lhte 52.1 du rseau 138.195.0.0 o e Cet hte sur le 138.195.0.0 o Tous les htes du 193.104.1.0 o Cet hte (boucle locale). o

35

Remarque : les deux premi`res adresses, avec un numro de rseau gal ` e e e e a 0, ne peuvent gurer que comme adresse source dans des cas bien particuliers comme le dmarrage dune station (cf chapitre IP page 43 et les travaux e pratiques associs). e

2.3

Sous-rseaux e

En 1984 un troisi`me niveau de hirarchie est mis en place : le subnet e e ou sous-rseau. pour permettre aux administrateurs de grer plus nement e e de grands rseaux. La RFC 950 [J. Mogul, J. Postel, 1985] donne plus de e prcisions, la RFC 1878 [T. Pummill & B. Manning, 1995] est une table de e tous les sous-rseaux possibles. e
Hostid de la classe C 31 24 23 16 15 193 104 1 8 76 5 0 hostid (6 bits) rduit des 2 bits du subnet id

Netid de la la classe C

subnet id (2 bits) netmask (les 2 bits de poids fort) : 255.255.255.192 = 0xFFFFFFC0

gure III.02 Le subnet utilise les bits de poids fort de la partie hte de o ladresse IP, pour dsigner un rseau. e e Le nombre de bits employs est laiss e e ` linitiative de ladministrateur. a

Dans la gure III.02 ci-contre, les bits 6 et 7 de la partie host sont utiliss pour caractriser un souse e rseau. e Quelques rvisions des proprits e ee des puissances de 29 sont souvent ncessaires pour bien assimiler ce pae ragraphe. La gure suivante en rappelle les valeurs pour les huit premiers exposants : gure III.03
7 128 6 64 5 32 4 16 3 8 2 4 1 2 0 1

Dcomposition unique : 255 = 128 + 64 + 32 + 16 +8 + 4 + 2 + 1

et plus gnralement de la dcomposition dun nombre en ses facteurs premiers. . . e e e

36

Anatomie dune adresse IP Nous avons dune part 27 + 26 = 192, et dautre part 25 + 24 + 23 + 22 + 21 + 20 = 6310 . Ce qui permet de caractriser 4 sous-rseaux de 62 machines e e (63 moins ladresse de broascast, le 0 ntant pas compt). Le calcul des e e masques et des adresses de diusion est expliqu dans le tableau suivant : e Numro du rseau e e 193.104.1.00 193.104.1.64 193.104.1.128 193.104.1.192 Netmask Broadcast Adressage hte o 255.255.255.192 00 + 63 = 63 .1 ` .62 a 255.255.255.192 64 + 63 = 127 .65 ` .126 a 255.255.255.192 128 + 63 = 191 .129 ` .190 a 255.255.255.192 192 + 63 = 255 .193 ` .254 a

Soit un total de 62 4 = 248 htes possibles pour cette classe C avec un o 11 masque de sous-rseau , au lieu des 254 htes sans. e o La machine dadresse 1 sur chaque sous-rseau, aura comme adresse IP : e Sous-rseau Adresse e Dcomposition e 00 193.104.1.1 00 + 1 = 1 01 193.104.1.65 64 + 1 = 65 10 193.104.1.129 128 + 1 = 129 11 193.104.1.193 192 + 1 = 193 Si vous pensez avoir tout compris, le remplissage du tableau suivant dans le cas de la classe C 192.168.192.0 et avec 3 bits pour dnir les sous-rseaux e e ne devrait pas vous poser de probl`me. . . e Numro e du subnet 000(0) 001(1) 010(2) 011(3) 100(4) 101(5) 110(6) 111(7) Numro e du rseau e 192.168.192. 192.168.192. 192.168.192. 192.168.192. 192.168.192. 192.168.192. 192.168.192. 192.168.192. Adresse de broadcast 192.168.192. 192.168.192. 192.168.192. 192.168.192. 192.168.192. 192.168.192. 192.168.192. 192.168.192. Premi`re Derni`re e e machine machine

` A toutes ces adresses il faudra appliquer le masque de sous-rseau : e 0xFFFFFF soit encore 255.255.255. Remarque : On pourra vrifer que la perte despace dadressage pour e des htes se calcule avec la relation (2n 1) 2, o` n est le nombre de bits o u du masque. Ainsi avec 3 bits de masque de sous-rseau, la perte despace e dadressage sl`ve ` 14 htes ! Les 254 possibilits (256 moins 0 et 255) de ee a o e nommage de la classe C se rduisent ` 240, amputes de 31, 32, 63, 64, 95, e a e 96, 127, 128, 159, 160, 191, 192, 223 et 224.
10 11

Donc 64 valeurs possibles de 0 ` 63 a netmask

CIDR

37

2.4

CIDR

En 1992 la moiti des classes B taient alloues, et si le rythme avait e e e continu, au dbut de 1994 il ny aurait plus eu de classe B disponible et e e lInternet aurait bien pu mourrir par asphyxie ! De plus la croissance du nombre de rseaux se traduisait par un usage aux limites des routeurs, e proches de la saturation car non prvus au dpart pour un tel volume de e e routes (voir les RFC 1518 et RFC 1519). Deux considrations qui ont conduit lIETF a mettre en place le CIDR e ( Classless InterDomain Routing ou routage Internet sans classe) bas sur e une constatation de simple bon sens : Sil est courant de rencontrer une organisation ayant plus de 254 htes, o il est moins courant den rencontrer une de plus de quelques milliers. Les adresses alloues sont donc des classes C contiges, attribues par e u e rgion ou par continent. En gnrale, 8 ` 16 classes C mises bout ` e e e a a bout susent pour une entreprise. Ces blocs de numros sont souvent e appells supernet . e Ainsi par exemple il est courant dentendre les administrateurs de rseaux parler dun slash 22 (/22) pour dsigner un bloc de quatre e e classes C conscutives. . . e Il est plus facile de prvoir une table de routage pour un bloc dadresses e contiges quadresse par adresse, en plus cela all`ge les tables. u e Plus prcisement, trois caractristiques sont requises pour pouvoir utiliser e e ce concept : 1. Pour tre runies dans une mme route, des adresses IP multiples e e e doivent avoir les mmes bits de poids fort. e 2. Les tables de routages et algorithmes doivent prendre en compte un masque de 32 bits, ` appliquer sur les adresses. a 3. Les protocoles de routage doivent ajouter un masque 32 bits pour chaque adresse IP (Cet ajout double le volume dinformations) transmise. OSPF, RIP-2, BGP-4 le font. Ce masque se manifeste concrtement comme dans la recriture du e e tableau du paragraphe 1.2 : 10.0.0.0 10.255.255.255 172.16.0.0 172.31.255.255 192.168.0.0 192.168.255.255 10/8 172.16/12 192.168/16

Le terme classless vient de ce fait, le routage nest plus bas unie quement sur la partie rseau des adresses. e

38

Anatomie dune adresse IP Les agrgations dadresses sont ventiles selon le tableau suivant12 : e e Multirgionales e Europe Autres Amrique du Nord e Amrique centrale, e Amrique du Sud e Zone Pacique Autres Autres 192.0.0.0 194.0.0.0 196.0.0.0 198.0.0.0 200.0.0.0 202.0.0.0 204.0.0.0 206.0.0.0 193.255.255.255 195.255.255.255 197.255.255.255 199.255.255.255 201.255.255.255 203.255.255.255 205.255.255.255 207.255.255.255

2.5

Prcisions sur le broadcast e

Tout dabord il faut prciser quune adresse de broadcast est forcment e e une adresse de destination, elle ne peut jamais appara comme une adresse tre source dans un usage normal des rseaux. e Il y a quatre formes possibles de broadcast : Limited broadcast (255.255.255.255) Une telle adresse ne peut servir que sur le brin local et ne devrait jamais franchir un routeur. Ce nest malheureusement pas le cas (prcisions en cours). e Lusage de cette adresse est normalement limite ` un hte en phase e a o dinitialisation, quand il ne connait rien du rseau sur lequel il est e connect. e Net-directed broadcast Tous les bits de la partie hte sont ` 1. Un o a routeur propage ce type de broadcast, sur option. Subnet-directed broadcast Cest le mme cas que ci-dessus mais e avec une adresses IP comportant des subnets. All-subnets-directed broadcast Cest le cas o` tous les bits des subu nets et htes sont ` 1. Ce cas possible thoriquement est rendu obsol`te o a e e depuis la RFC 922 (1993).

Ce tableau est tr`s synthtique, pour une information plus dtaille et ` jour consultez e e e e a le site de lIANA http ://www.iana.org/assignments/ipv4-address-space

12

3 Adressage multicast

39

Adressage multicast

En r`gle gnrale ladressage multicast est employ pour sadresser en une e e e e seule fois ` un groupe de machines. a Dans le cas dun serveur vido/audio, cette approche induit une conomie e e de moyen et de bande passante vidente quand on la compare ` une dmarche e a e unicast : un seul datagramme est rout vers tous les clients intresss au e e e lieu dun envoi massif dautant de datagrammes quil y a de clients. Les adresses de type multicast ont donc la facult didentier un e groupe de machines qui partagent un protocole commun par opposition ` un a groupe de machines qui partagent un rseau commun. e La plupart des adresses multicast alloues le sont pour des applications e particuli`res comme par exemple la dcouverte de routeurs (que nous verrons e e ultrieurement lors du routage IP) ou encore la radio ou le tlphone/vido e ee e sur Internet ( Mbone ). Les plus couramment utilises13 sur un lan sont : e 224.0.0.1 224.0.0.2 Toutes les machines sur ce sous-rseau e Tous les routeurs sur ce sous-rseau e

3.1

Adresse de groupe multicast

Si une adresse multicast dmarre avec les bits 1110 par contre pour les 28 e bits suivants son organisation interne di`re de celle des classes A, B et C. e
"Multicast group address"

1 1 1 0

4 bits

28 bits "Multicast group ID"

gure III.04 Les 28 bits nont pas de structure particuli`re par contre on continue ` e a utiliser la notation dcimale pointe : 224.0.0.0 ` 239.255.255.255. e e a Un groupe dhtes qui partagent un protocole commun utilisant une o adresse multicast commune peuvent tre rpartis nimporte o` sur le e e u rseau. e Lappartenance ` un groupe est dynamique, les htes qui le dsirent a o e rejoignent et quittent le groupe comme ils veulent. Il ny a pas de restriction sur le nombre dhtes dans un groupe et o un hte na pas besoin dappartenir ` un groupe pour lui envoyer un o a message.
13

Pour plus de prcisions on pourra se reporter page 56 de la RFC 1700 e

40

Anatomie dune adresse IP

3.2

Adresse multicast et adresse MAC

Une station Ethernet quelconque doit tre congure pour accepter le e e multicast, cest ` dire pour accepter les trames contenant un datagramme a munis dune adresse IP de destination qui est une adresse multicast. Cette opration sous entend ` juste titre que la carte rseau sait faire e a e le tri entre les trames. En eet les trames multicast ont une adresse MAC particuli`re : elles commencent forcment par les trois octets 01 :00 :5E14 . e e Ceux-ci ne dsignent pas un constructeur en particulier mais sont possds e e e par lICANN (ex IANA). Restent trois octets, soit 24 bits dont le premier est forcment ` 0 pour e a dsigner les adresses de multicast (contrainte de la RFC 1700), ce qui conduit e au schma suivant : e
5 bits inutilisables dans ladresse MAC.
0 1 1 10 7 8 15 16 23 24 31

01

00

5E

Les 23 bits de poids faible du "group Id" de ladresse

0 00 0 0 0 01 0 0 0 0 0 0 0 0 01 01 1 1 1 0 0

gure III.05 Du fait quil ny a pas assez de place dans ladresse MAC pour faire tenir les 28 bits du groupe multicast, cette adresse nest pas unique. On peut mme e prciser que pour chaque trame comportant une adresse multicast il y a 25 e adresses IP de groupes multicast possibles ! Ce qui signie que si les 23 bits de poids faible ne susent pas ` discria miner la trame il faudra faire appel au pilote de priphrique ou ` la couche e e a IP pour lever lambigu e. t Quand une trame de type multicast est lue par la station Ethernet puis par le pilote de priphrique, si ladresse correspond ` lune des adresses e e a de groupe multicast pralablement congures, le datagramme franchit la e e couche IP et une copie des donnes est dlivre aux processus qui ont joint e e e le groupe multicast . La question est de savoir comment les trames de type multicast atteignent justement cette station Ethernet ? La rponse se trouve dans un protocole e nomm IGMP et que nous examinerons dans le prochain chapitre concernant e IP.

14

Cf RFC 1700 page 171

4 Conclusion et bibliographie

41

Conclusion et bibliographie

Pour conclure ce chapitre sur ladressage IP, il faut nous donner quelques prcisions supplmentaires. e e Jusqu` prsent nous avons dsign un hte par son adresse IP. Cette a e e e o dmarche nest pas exacte si on consid`re par exemple le cas dune passerelle, e e connecte physiquement ` au moins deux rseaux dirents, avec une adresse e a e e IP dans chacun de ces rseaux. e On dira donc maintenant quune adresse IP identie non pas un hte o mais un interface. La rciproque nest pas vraie car un mme interface peut e e collectionner plusieurs adresses IP. Toutes permettent datteindre cet interface, on parle alors d alias IP et de rseaux virtuels . . .Nous aurons e loccasion de revenir sur ces notions ` la n de ce cours. a On dit dune machine ayant au moins deux adresses IP quelle est du type multi-homed . En gnral une passerelle qui met en relation n rseaux poss`de n adresses e e e e IP direntes (une dans chaque rseau), mais ce nest pas une obligation (nous e e verrons quelle peut en tre lutilit ` la n de ce cours). e ea
A Application Messages identiques Transport Transport B Application

Paquets identiques Passerelle G

Internet

Internet

Internet

Rseau

Rseau

Rseau

Rseau physique 1

Rseau physique 2

gure III.06 La gure III.06 met en situation deux htes, A et B, en relation via une o passerelle G. Si les messages et les paquets sont identiques, par contre les datagrammes et les trames di`rent puisquil ne sagit plus du e mme rseau physique. D`s que nous aurons examin le fonctionnement de e e e e la couche IP nous reviendrons sur cette gure pour en expliquer le fonctionnement (voir page 71).

42 Pour en savoir plus :

Anatomie dune adresse IP

RFC 0950 S J. Mogul, J. Postel, Internet standard subnetting procedure , 08/01/1985. (Pages=18) (Format=.txt) (STD 5) RFC 1112 S S. Deering, Host extensions for IP multicasting , 08/01/1989. (Pages=17) (Format=.txt) (Obsoletes RFC0988) (STD 5) RFC 1518 An Architecture for IP Address Allocation with CIDR Y. Rekhter, T. Li. September 1993. (Format : TXT=72609 bytes) (Status : PROPOSED STANDARD) RFC 1519 PS V. Fuller, T. Li, J. Yu, K. Varadhan, Classless InterDomain Routing (CIDR) : an Address Assignment and Aggregation Strategy , 09/24/1993. (Pages=24) (Format=.txt) (Obsoletes RFC1338) RFC 1466 I E. Gerich, Guidelines for Management of IP Address Space , 05/26/1993. (Pages=10) (Format=.txt) (Obsoletes RFC1366) RFC 1467 Status of CIDR Deployment in the Internet. C. Topolcic. August 1993. (Format : TXT=20720 bytes) (Obsoletes RFC1367) (Status : INFORMATIONAL) RFC 1700 Assigned Numbers. J. Reynolds, J. Postel. October 1994. (Format : TXT=458860 bytes) (Obsoletes RFC1340) (Also STD0002) (Status : STANDARD) RFC 1878 Variable Length Subnet Table For IPv4. T. Pummill & B. Manning. December 1995. (Format : TXT=19414 bytes) (Obsoletes RFC1860) (Status : INFORMATIONAL) RFC 1918 Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot & E. Lear. February 1996. (Format : TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also BCP0005) (Status : BEST CURRENT PRACTICE) Quelques ouvrages qui font autorit : e W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols Addison-Wesley Douglas Comer - Internetworking with TCP/IP - Principles, protocols, and architecture - PrenticeHall Christian Huitema - Le routage dans lInternet - EYROLLES

Chapitre IV Protocole IP
1 Datagramme IP

IP est lacronyme de Internet Protocol , il est dni dans la RFC 791. e Les donnes qui franchissent la couche IP, alias couche Internet, sont e appelles datagramme IP , datagramme Internet ou datagramme tout e court.
31 28 27 24 23 SERVICE TYPE FLAGS 16 15 TOTAL LENGTH FRAGMENT OFFSET 0

VERS

HLEN

IDENTIFICATION

TTL

PROTO

HEADER CHECKSUM

SOURCE IP ADDRESS

DESTINATION IP ADDRESS

IP OPTIONS

PADDING

DATA

....

gure IV.01 La taille maximale dun datagramme dpend du support physique, cest e le MTU ( Maximum Transfert Unit ). Quelques caractristiques en vrac du protocole IP : e IP est le support de travail des protocoles de la couche de transport, TCP, UDP. IP ne donne aucune garantie quant au bon acheminement des donnes e quil envoie. Il nentretient aucun dialogue avec une autre couche IP distante, on dit aussi quil dlivre les datagramme au mieux . e

44

Protocole IP Chaque datagramme est gr indpendamment des autres dataee e grammes mme au sein du transfert des octets dun mme chier. Cela e e signie que les datagrammes peuvent tre mlangs, dupliqus, perdus e e e e ou altrs ! ee Ces probl`mes ne sont pas dtects par IP et donc il ne peut en informer e e e la couche de transport. Sur la gure IV.01 les bits les plus signicatifs de chaque mot de quatre octets sont ` gauche (31. . .). Ils sont dailleurs transmis sur le rseau a e dans cet ordre, cest un standard, cest le Network Byte Order . Toutes les architectures de CPU ne sont pas bties sur le mme mod`le : a e e
mot de deux octets 15 "Big endian" ... A+1 A octet 0 Octet 1 HP MOTOROLA 0 1 0 "Little endian" ... octet 1 octet 0 INTEL Croissance des adresses

gure IV.02 Len-tte IP minimale fait 5 mots de 4 octets, soit 20 octets. Sil y a e des options la taille maximale peut atteindre 60 octets.

1.1

Description de len-tte e

VERS 4 bits qui spcient la version du protocol IP. Lobjet de ce champ est la e vrication que lmetteur et le destinataire des datagrammes sont bien e e en phases avec la mme version. Actuellement cest la version 4 qui est e principalement utilis sur lInternet, bien que quelques implmentations e e 1 de la version 6 existent et soient dj` en exprimentation . ea e HLEN 4bits qui donnent la longueur de len-tte en mots de 4 octets. La e taille standard de cette en-tte fait 5 mots, la taille maximale fait : e (23 + 22 + 21 + 20 ) 4 = 60 octets2 TOTAL LENGTH Donne la taille du datagramme, en-tte plus donnes. Sil y e e fragmentation (voir plus loin) il sagit galement de la taille du fragment e (chaque datagramme est indpendant des autres). e
1 2

Nous examinerons les caractristiques de la version 6 dIP ` la n de ce cycle de cours e a On encore plus simple 24 1

Description de len-tte e La taille des donnes est donc ` calculer par soustraction de la taille de e a len-tte. e 16 bits autorisent la valeur 65535. . .La limitation vient le plus souvent du support physique (MTU) qui impose une taille plus petite, sauf sur les hyperchannel . TYPE OF SERVICE 8 bits (4 utiles) qui indiquent au routeur lattitude ` avoir a vis ` vis de ce datagramme. Suivant les valeurs de ce champ, le routeur a peut privilgier un datagramme par rapport ` un autre. e a Par exemple, des datagrammes dun transfert de chier (ftp) peuvent avoir ` laisser passer un datagramme repr comme contenant des caa ee ract`res frapps au clavier (session telnet). e e 0x00 0x02 0x04 0x10 0x08 Service normal Minimiser le cot u Maximiser la qualit e Minimiser le dlai e Maximiser le dbit e Transfert banal news (nntp) ICMP Session telnet Transfert ftp

45

IDENTIFICATION, FLAGS et FRAGMENT OFFSET Ces mots sont prvus pour e contrler la fragmentation des datagrammes. Les donnes sont frago e mentes car les datagrammes peuvent avoir ` traverser des rseaux avec e a e des MTU plus petits que celui du premier support physique employ. e Consulter la section suivante Fragmentation IP. TTL Time To Live 8 bits, 255 secondes maximum de temps de vie pour un datagramme sur le net. Prvu ` lorigine pour dcompter un temps, ce champ nest quun compe a e teur dcrment dune unit ` chaque passage dans un routeur. e e e ea Couramment la valeur de dpart est 32 ou mme 64. Son objet est e e dviter la prsence de paquets fantmes circulant indniment. . . e e o e Si un routeur passe le compteur ` zro avant dlivrance du datagramme, a e e un message derreur ICMP (consultez le paragraphe 4) est renvoy e ` lmetteur avec lindication du routeur. Le paquet en lui-mme est a e e perdu. PROTOCOL 8 bits pour identier le format et le contenu des donnes, un peu e comme le champ type dune trame Ethernet. Il permet ` IP dadresa ser les donnes extraites ` lune ou lautre des couches de transport. e a Dans le cadre de ce cours, nous utiliserons essentiellement ICMP, IGMP, UDP et TCP. HEADER CHECKSUM 16 bits pour sassurer de lintgrit de len-tte. Lors du e e e calcul de ce checksum ce champ est ` 0. a A la rception de chaque paquet, la couche calcule cette valeur, si elle ne e correspond pas ` celle trouve dans len-tte le datagramme est oubli a e e e ( discard ) sans message derreur. SOURCE ADDRESS Adresse IP de lmetteur, ` lorigine du datagramme. e a

46

Protocole IP DESTINATION ADDRESS Adresse IP du destinataire du datagramme. IP OPTIONS 24 bits pour prciser des options de comportement des e couches IP traverses et destinatrices. Les options les plus courantes e concernent : Des probl`mes de scurit e e e Des enregistrements de routes Des enregistrements dheure Des spcications de route ` suivre e a ... Historiquement ces options ont t prvues d`s le dbut mais leur ee e e e implmentation na pas t termine. e ee e Pour des raisons de scurit, la tendance est dignorer ce champ. Cere e tains sites consid`rent mme comme suspects les datagrammes contee e nants des IP OPTIONS ! PADDING Remplissage pour aligner sur 32 bits. . . En conclusion partielle que peut-on dire du travail de la couche IP ? 1. Il consiste ` router les datagrammes en les acheminant au mieux , a on verra plus loin de quelle mani`re. Cest son travail principal. e 2. Il peut avoir ` fragmenter les donnes de taille suprieure au MTU du a e e support physique ` employer. a

Fragmentation IP

47

1.2

Fragmentation IP

La couche de liaison (Couche 2 Link ) impose une taille limite, le Maximum Transfert Unit . Par exemple cette valeur est de 1500 pour une trame Ethernet, elle peut tre de 256 avec SLIP ( Serial Line IP ) sur e liaison srie (RS232. . .). e Dans ces conditions, si la couche IP doit transmettre un bloc de donnes e de taille suprieure au MTU ` employer, il y a fragmentation ! e a Par exemple, un bloc de 1481 octets sur Ethernet sera dcompos en un e e datagramme de 1480 (1480 + 20 = 1500) et un datagramme de 1 octet ! Il existe une exception ` cette opration, due ` la prsence active du bit a e a e Dont Fragment bit du champ FLAGS de len-tte IP. La prsence ` 1 de e e a ce bit interdit la fragmentation dudit datagramme par la couche IP qui en aurait besoin. Cest une situation de blocage, la couche mettrice est tenue e au courant par un message ICMP (consultez le paragraphe 4) Fragmentation needed but dont fragment bit set et bien sr le datagramme nest pas transmis u plus loin.

G1

802.2 (1492) X25 (128)

G2

Ethernet (1500)

gure IV.03 Fragmentation Quand un datagramme est fragment, il nest rassembl que par la e e e couche IP destinatrice nale. Cela implique trois remarques : 1. La taille des datagrammes reus par le destinataire nal est direcc tement dpendante du plus petit MTU rencontr. e e 2. Les fragments deviennent des datagrammes ` part enti`re. a e 3. Rien ne soppose ` ce quun fragment soit ` nouveau fragment. a a e Cette opration est absolument transparente pour les couches de transe port qui utilisent IP.

48

Protocole IP Quand un datagramme est fragment, chaque fragment est identi de e e mani`re unique, relativement au datagramme initial. Cette valeur est e inscrite dans le champ IDENTIFICATION. Sil y a encore des fragments, un des bits du champ FLAGS est positionn e ` 1 pour indiquer More fragment ! a Ce champ a une longueur de 3 bits. FRAGMENT OFFSET contient loset du fragment, relativement au datagramme initial. Cet oset est cod sur 13 bits. e
Offset : donnes transmises Ce qui reste transmettre

Le fragment transmettre

gure IV.04 Pour tous les fragments : Les donnes doivent faire un multiple de 8 octets, sauf pour le dernier e fragment, videment. e Le champ TOTAL LENGTH change. Chaque fragment est un datagramme indpendant, susceptible dtre e e ` son tour fragment. a e Pour le dernier fragment : FLAGS est remis ` zro. a e Les donnes ont une taille quelconque. e

Rassemblage e Tous les datagrammes issus dune fragmentation deviennent des datagrammes IP comme (presque) les autres. Ils arrivent ` destination, peut tre dans le dsordre, dupliqus. IP doit a e e e faire le tri. il y a susamment dinformation dans len-tte pour rassembler les e e fragments pars. e Mais si un fragment manque, la totalit du datagramme est perdu car e aucun mcanisme de contrle nest implment pour cela dans IP. e o e e La gure IV.05 rsume lopration de fragmentation dun datagramme e e IP.

Fragmentation IP
Datagramme initial
H 0 N multiple entier de 8 N1 N H1

49

5 datagrammes diffrents
H2 H3 H4 H5

2N

3N

4N

M, reste de la division entire de L par 8.

L octets transmettre

gure IV.05 IDENTIFICATION FLAG OFFSET TOTAL LENGTH HEADER CHECKSUM H1 I MF 0 H +N C1 H2 I MF N H +N C2 H3 I MF 2N H +N C3 H4 I MF 3N H +N C4 H5 I 0 4N H +M C5

Notez les variations de certains champs de len-tte : e 1. IDENTIFICATION est le mme pour tous e 2. FLAG est 0 pour le dernier datagramme 3. OFFSET cro de la taille du fragment, ici N. t 4. TOTAL LENGTH est gnralement dirent pour le dernier fragment, sauf e e e cas particulier. 5. HEADER CHECKSUM change ` chaque fois car lOFFSET change (rappel : a il ne tient pas compte des donnes). e

50

Protocole IP

Protocole ARP

ARP est lacronyme de Address Resolution Protocol , il est dnie dans e la RFC 826. Le probl`me ` rsoudre est issu de la constatation quune adresse IP e a e na de sens que pour la suite de protocole TCP/IP ; celle-ci tant e indpendante de la partie matrielle il faut avoir un moyen dtablir e e e un lien entre ces deux constituants. La norme Ethernet (vs IEEE) suppose lidentication unique de chaque carte construite et vendue3 . Sur une mme liaison physique (lire plus loin mme LAN ), Ethere e net par exemple, deux machines peuvent communiquer elles connaissent leurs adresses physiques respectives. On suppose quune machine connait sa propre adresse physique par un moyen qui nest pas dcrit ici (ne fait pas partie du protocole). e Remarque importante : Cette information na pas de sens dans le cadre dune liaison de type point ` point avec un protocole tel que ppp. a Lors du premier change entre 2 machines dun mme LAN, si les e e adresses physiques ne sont pas dj` connues (on verra pourquoi plus ea loin), la solution ` ce probl`me passe par lusage du protocole ARP. a e Lusage de ARP est compl`tement transparent pour lutilisateur. e

2.1

Fonctionnement
A demande toutes les stations : tant donn ladresse IP de B, que vaut son adresse physique ?

Broadcast Ethernet (vs IEEE)

gure IV.06 Sur la gure IV.06 la station Ethernet A (IA , PA ) a besoin de connaitre ladresse physique de la station Ethernet B (IB , PB ), pour ce faire elle envoie un datagramme de format spcial (cf paragraphe suivant), ddi ` ARP, qui e e ea lui permet de poser la question ( Arp question ) ` lensemble des machines a actives. Ladresse de la machine qui doit rpondre tant lobjet de la quese e tion, son adresse (champ destinataire) est donc remplace par une adresse de e broadcast (48 bits ` 1). a Toutes les machines du LAN coutent cet change et peuvent mettre ` e e a jour leur table de conversion (adresse IP adresse Ethernet) pour la machine
3

cf chapitre I Rseaux locaux e

Protocole ARP A. Le broadcast , coteux en bande passante, est ainsi utilis au maximum u e de ses possibilits. Sur la gure IV.07 la rponse de B est du type unicast . e e Remarque : quand une station Ethernet ne rpond plus (cf ICMP) il y a e suppression de lassociation adresse IP - adresse MAC.

51

Rponse unicast.

B rpond directement A en lui communiquant son adresse physique.

gure IV.07

Si la station B ne rpond pas, la station continuera ` poser la question ` e a a intervals rguliers pendant un temps inni. . . e Il nest pas besoin dutiliser ARP pralablement ` chaque change, car e a e heureusement le rsultat est mmoris. e e e En r`gle gnrale la dure de vie dune adresse en mmoire est de lordre e e e e e de 20 minutes et chaque utilisation remet ` jour ce compteur. a La commande arp -a sous Unix permet davoir le contenu de la table de la machine sur laquelle on se trouve, par exemple :

$ arp -a soupirs.chezmoi.fr espoirs.chezmoi.fr plethore.chezmoi.fr byzance.chezmoi.fr ramidus.chezmoi.fr desiree.chezmoi.fr pythie.chezmoi.fr ramidus.chezmoi.fr gateway.chezmoi.fr

(192.168.192.10) (192.168.192.11) (192.168.192.12) (192.168.192.13) (192.168.192.14) (192.168.192.33) (192.168.192.34) (192.168.192.35) (192.168.192.36)

at at at at at at at at at

8:0:9:85:76:9c 8:0:9:85:76:bd 8:0:9:a:f9:aa 8:0:9:a:f9:bc 0:4f:49:1:28:22 permanent 8:0:9:70:44:52 0:20:af:2f:8f:f1 0:4f:49:1:36:50 permanent 0:60:8c:81:d5:1b

Enn, et cest un point tr`s important, du fait de lutilisation de broade cast physiques, les messages ARP ne franchissent pas les routeurs. Il existe cependant un cas particulier : le proxy ARP, que nous voquerons succintee ment ` la n de ce paragraphe. a

52

Protocole IP

2.2

Format du datagramme
31 HARDWARE TYPE 16 15 PROTOCOL TYPE 0

HLEN 1

HLEN 2

OPERATION

SENDER HA (0 3)

SENDER HA (4,5) SENDER ADR (2,3)

SENDER ADR (0,1)

TARGET HA (0,1)

TARGET HA (2 5)

TARGET ADR (0 3)

gure IV.08 Le datagramme ci-dessus est encapsul dans une trame physique du type e 0x08064 . HARDWARE TYPE pour spcier le type dadresse physique dans les champs e SENDER HA et TARGET HA, cest 1 pour Ethernet. PROTOCOL TYPE pour spcier le type dadresse logique dans les champs e SENDER ADR et TARGET ADR, cest 0x0800 (mme valeur que dans la e trame Ethernet) pour des adresses IP. HLEN 1 pour spcier la longueur de ladresse physique (6 octets pour Ethere net). HLEN 2 pour spcier la longueur de ladresse logique (4 octets pour IP). e OPERATION ce champ prcise le type de lopration, il est ncessaire car la e e e trame est la mme pour toutes les oprations des deux protocoles qui e e lutilisent. Question 1 3 Rponse e 2 4

ARP RARP

SENDER HA adresse physique de lmetteur e SENDER ADR adresse logique de lmetteur e TARGET HA adresse physique du destinataire TARGET ADR adresse logique du destinataire
4

voir ou revoir la gure II.02 du chapitre dintroduction ` IP (page 23) a

3 Protocole RARP

53

2.3

Proxy ARP

Le proxy ARP permet lextension du lan ` des htes qui ne lui sont a o pas directement physiquement relis, mais qui sy rattachent par exemple au e travers dune passerelle. Un exemple tr`s courant est celui dun hte qui acc`de ` un rseau via un e o e a e dialup (rtc, numris,. . .). Le NetID de son adresse IP peut alors tre le mme e e e que celui du rseau rejoint, comme sil y tait physiquement raccord. Ce e e e subterfuge est rendu possible apr`s conguration adquate de la passerelle e e de raccordement.

Protocole RARP

RARP est lacronyme de Reverse Address Resolution Protocol , il est dni dans la RFC 903 (BOOTP et DHCP en sont des alternatives avec plus de e possibilits). e Normalement une machine qui dmarre obtient son adresse IP par lece ture dun chier sur son disque dur (ou depuis sa conguration ge e dans une mmoire non volatile). e Pour certains quipements cette opration nest pas possible voire e e mme non souhaite par ladministrateur du rseau : e e e Terminaux X Windows Stations de travail diskless Imprimante en rseau e Boites noires sans capacit autonome de dmarrage e e PC en rseau e ... Pour communiquer en TCP/IP une machine a besoin dau moins une adresse IP, lide de ce protocole est de la demander au rseau. e e Le protocole RARP est adapt de ARP : lmetteur envoie une requte e e e RARP spciant son adresse physique dans un datagramme de mme e e format que celui de ARP et avec une adresse de broadcast physique. Le champ OPERATION contient alors le code de RARP question Toutes les stations en activit reoivent la requte, celles qui sont hae c e bilits ` rpondre (serveurs RARP) compl`tent le datagramme et le rene a e e voient directement ( unicast ) ` lmetteur de la requte puisquelle a e e connaissent son adresse physique. Sur une machine Unix congure en serveur RARP les correspondances e entres adresses IP et adresses physiques sont enregistres dans un chier e nomm gnralement /etc/bootptab. e e e

54

Protocole IP

Protocole ICMP

ICMP est lacronyme de Internet Control Message Protocol , il est historiquement dni dans la RFC 950. e Nous avons vu que le protocole IP ne vrie pas si les paquets mis sont e e arrivs ` leur destinataire dans de bonnes conditions. e a Les paquets circulent dune passerelle vers un autre jusqu` en trouver a une qui puisse les dlivrer directement ` un hte. Si une passerelle ne peut e a o router ou dlivrer directement un paquet ou si un venement anormal arrive e e sur le rseau comme un trac trop important ou une machine indisponible, e il faut pouvoir en informer lhte qui a mis le paquet. Celui-ci pourra alors o e ragir en fonction du type de probl`me rencontr. e e e ICMP est un mcanisme de contrle des erreurs au niveau IP, mais la e o gure II.02 du chapitre dintroduction ` IP (page 23) montre que le niveau a Application peut galement avoir un acc`s direct ` ce protocole. e e a

4.1

Le syst`me de messages derreur e

Dans le syst`me que nous avons dcrit, chaque passerelle et chaque hte e e o op`re de mani`re autonome, route et dlivre les datagrammes qui arrivent e e e sans coordination avec lmetteur. e Le syst`me fonctionne parfaitement si toutes les machines sont en ordre e de marche et si toutes les tables de routage sont ` jour. Malheureusement a cest une situation idale. . . e Il peut y avoir des rupture de lignes de communication, des machines peuvent tre ` larrt, en pannes, dconnectes du rseau ou incapables de e a e e e e router les paquets parcequen surcharge. Des paquets IP peuvent alors ne pas tre dlivrs ` leur destinataire et e e e a le protocol IP lui-mme ne contient rien qui puisse permettre de dtecter cet e e chec de transmission. e Cest pourquoi est ajout systmatiquement un mcanisme de gestion des e e e erreurs connu sous le doux nom de ICMP. Il fait partie de la couche IP5 et porte le numro de protocole 1. e Ainsi, quand un message derreur arrive pour un paquet mis, cest la e couche IP elle-mme qui g`re le probl`me, la plupart des cas sans en informer e e e les couches suprieures (certaines applications utilisent ICMP6 ). e Initialement prvu pour permettre aux passerelles dinformer les htes sur e o des erreurs de transmission, ICMP nest pas restreint aux changes passerellese htes, des changes entres htes sont tout ` fait possibles. o e o a Le mme mcanisme est valable pour les deux types dchanges. e e e

5 6

voir ou revoir la gure II.02 du chapitre dintroduction ` IP (page 23) a Mme gure quau point prcdent e e e

Protocole ICMP

55

4.2

Format des messages ICMP

Chaque message ICMP traverse le rseau dans la partie DATA dun dae tagramme IP :
Entete IP Message ICMP

gure IV.09 La consquence directe est que les messages ICMP sont routs comme e e les autres paquets IP au travers le rseau. Il y a toutefois une exception : e il peut arriver quun paquet derreur rencontre lui-mme un probl`me de e e transmission, dans ce cas on ne gn`re pas derreur sur lerreur ! e e Il est important de bien voir que puisque les messages ICMP sont encapsuls dans un datagramme IP, ICMP nest pas considr comme un protocole e ee de niveau plus lev. e e La raison de lutilisation dIP pour dlivrer de telles informations, est que e les messages peuvent avoir ` traverser plusieurs rseaux avant darriver ` leur a e a destination nale. Il ntait donc pas possible de rester au niveau physique e du rseau (` linverse de ARP ou RARP). e a La gure IV.10 dcrit le format du message ICMP : e
31 TYPE 24 23 CODE 16 15 CHECKSUM 0

ENTETE du message original

..

gure IV.10 Chaque message ICMP a un type particulier qui caractrise le probl`me e e quil signale. Un en-tte de 32 bits est compos comme suit : e e TYPE contient le code derreur. CODE compl`te linformation du champ prcdent. e e e CHECKSUM est utilis avec le mme mcanisme de vrication que pour les e e e e datagrammes IP mais ici il ne porte que sur le message ICMP (rappel : le checksum de len-tte IP ne porte que sur son en-tte et non sur les e e donnes vhicules). e e e En addition, les messages ICMP donnent toujours len-tte IP et les 64 pree miers bits (les deux premiers mots de quatre octets) du datagramme qui est ` a lorigine du probl`me, pour permettre au destinataire du message didentier e quel paquet est ` lorigine du probl`me. a e

56

Protocole IP

4.3

Quelques types de messages ICMP

Ce paragraphe examine quelques uns des principaux types de messages ICMP, ceux qui sont le plus utiliss. Il existe onze valeurs de TYPE direntes. e e Echo Request (8), Echo reply (0) Une machine envoie un message ICMP echo request pour tester si son destinataire est accessible. Nimporte quelle machine qui reoit une telle requte doit formuler un c e 7 message ICMP echo reply en retour Ce mcanisme est extrmement utile, la plupart des implmentations e e e le propose sous forme dun utilitaire (ping sous Unix).
Echo request(8) IP

IP A

Echo reply(0) B Y

gure IV.11 Destination Unreachable (3) Quand une passerelle ne peut pas dlivrer un datagramme IP, elle envoie un message ICMP destination e unreachable ` lmetteur. a e Dans ce cas le champ CODE compl`te le message derreur avec : e 0 Network unreachable 1 Host unreachable 2 Protocol unreachable 3 Port unreachable 4 Fragmentation needed and DF set 5 Source route failed Source Quench (4) Quand un datagramme IP arrive trop vite pour une passerelle ou un hte, il est rejet. o e Un paquet arrive trop vite quand la machine qui doit le lire est congestionne, trop de trac ` suivre.. . . e a Dans ce cas la machine en question envoie un paquet ICMP source quench qui est interprt de la faon suivante : ee c Lmetteur ralenti le rythme denvoi de ses paquets jusqu` ce quil e a cesse de recevoir ce message derreur. La vitesse est donc ajuste par e une sorte dapprentissage rustique. Puis graduellement il augmente le dbit, aussi longtemps que le message source quench ne revient pas e .
7

Pour des raisons de scurit certaines machines peuvent ne pas rpondre. e e e

Protocole ICMP Ce type de paquet ICMP a donc tendance ` vouloir rguler le ux des daa e tagrammes au niveau IP alors que cest une fonctionnalit de la couche e de transport (TCP). Cest donc une srieuse entorse ` la r`gle dindpendance des couches. e a e e Redirect (5) Les tables de routage (Voir le paragraphe 6) des stations restent assez statiques durant de longues priodes. Le syst`me dexploie e tation les lit au dmarrage sur le syst`me de chiers et ladministrateur e e en change de temps en temps les lments. ee Si entre deux modications une destination change demplacement, la donne initiale dans la table de routage peut savrer incorrecte. e e Les passerelles connaissent de bien meilleures routes que les htes euxo mmes, ainsi quand une passerelle dtecte une erreur de routage, elle e e fait deux choses : 1. Elle envoie ` lmetteur du paquet un message ICMP redirect a e 2. Elle redirige le paquet vers la bonne destination. Cette redirection ne r`gle pas les probl`mes de routage car elle est lie e mite aux interactions entres passerelles et htes directement connects. e o e La propagation des routes aux travers des rseaux multiples est un e autre probl`me. e Le champ CODE du message ICMP peut avoir les valeurs suivantes : 0 Redirect datagram for the Net 1 Redirect datagram for the host 2 ... Router solicitation (10) vs Router advertisement (9) Il sagit dobtenir ou dannoncer des routes, nous verrons cela plus en dtail e dans le paragraphe 6.4. Time exceeded (11) Chaque datagramme contient un champ TTL dit TIME TO LIVE appell aussi hop count . e An de prvenir le cas ou un paquet circulerait ` linni dune passerelle e a ` une autre, chaque passerelle dcrmente ce compteur et rejette le a e e paquet quand le compteur arrive ` zro et envoie un message ICMP ` a e a lmetteur pour le tenir au courant. e

57

58

Protocole IP

Protocole IGMP

IGMP, lacronyme de Internet Group Management Protocol , est historiquement dnie dans lAnnexe I de la RFC 1112. e Sa raison dtre est que les datagrammes ayant une adresse multicast8 e sont ` destination dun groupe dutilisateurs dont lmetteur ne connait ni le a e nombre ni lemplacement. Lusage du multicast tant par construction ddi e e e 9 aux applications comme la radio ou la vido sur le rseau , donc consommae e trices de bande passante, il est primordial que les routeurs aient un moyen de savoir sil y a des utilisateurs de tel ou tel groupe sur les LANs directement accessibles pour ne pas encombrer les bandes passantes associes avec des e ux doctets que personne nutilise plus !

5.1

Description de len-tte e

IGMP est un protocole de communication entre les routeurs susceptibles de transmettre des datagrammes multicast et des htes qui veulent senregistrer o dans tel ou tel groupe. IGMP est encapsul dans IP10 avec le protocole numro e e 2. Comme le montre la gure IV.12, sa taille est xe (contrairement ` ICMP) : a seulement 2 mots de 4 octets.
31 28 27 24 23 16 15 0

Vers. Type

Inutilis

Checksum sur 16 bits

Adresse du groupe sur 32 bits

gure IV.12 Version Version 1. Type Ce champ prend deux valeurs, 1 pour dire quil sagit dune question (query dun routeur), 2 pour dire quil sagit de la rponse dun hte. e o Inutilis . . . e Checksum Le checksum est calcul comme celui dICMP. e Adresse Cest ladresse multicast (classe D) ` laquelle appartient lhte qui a o rpond. e

Voir page 39 La premi`re exprience ` grande chelle du multicast fut sans doute la confrence de e e a e e lIETF en mars 1992. Le papier ftp ://venera.isi.edu/ietf-audiocast-article.ps relate cette exprience. e 10 voir ou revoir la gure II.02 du chapitre I dintroduction ` IP (page 23) a
9

Protocole IGMP

59

5.2

Fonctionnement du protocole

La RFC 1112 prcise que les routeurs multicast envoient des messages e de questionnement (Type=Queries) pour reconna quels sont les ventuels tre e htes appartenant ` quel groupe. Ces questions sont envoyes ` tous les htes o a e a o des LANs directement raccords ` laide de ladresse multicast du groupe e a 11 224.0.0.1 encapsul dans un datagramme IP ayant un champ TTL=1. Tous e les htes susceptibles de joindre un groupe multicast coutent ce groupe par o e hypoth`se. e Les htes, dont les interfaces ont t correctement congures, rpondent o ee e e ` une question par autant de rponses que de groupes auxquels ils apa e partiennent sur linterface rseau qui a reu la question. An dviter une e c e tempte de rponses chaque hte met en uvre la stratgie suivante : e e o e 1. Un hte ne rpond pas immdiatement ` la question reue. Pour chaque o e e a c groupe auquel il appartient, il attend un dlais compris entre 0 et 10 see condes, calcul alatoirement ` partir de ladresse IP unicast de lintere e a face qui a reu la question, avant de renvoyer sa rponse. La gure IV.13 c e montre un tel change, remarquez au passage la valeur des adresses. e 2. La rponse envoye est coute par tous les membres du groupe appare e e e tenant au mme LAN. Tout ceux qui sapprtaient ` envoyer une telle e e a rponse au serveur en interrompent le processus pour viter une redite. e e Le routeur ne reoit ainsi quune seule rponse pour chaque groupe, et c e pour chaque LAN, ce qui lui sut pour justier le routage demand. e

Type= Report

TTL=1 Src=IP A Groupe=Adr. groupe M. Dst=Adr. groupe M.

TTL=1 Src= IPG Dst=224.0.0.1 IP

Type=Query Groupe=0.0.0.0 IGMP

gure IV.13 Il y a deux exceptions ` la stratgie ci-dessus. La premi`re est que si une a e e question est reue alors que le compte ` rebours pour rpondre ` une rponse c a e a e est en cours, il nest pas interrompu. La deuxi`me est quil ny a jamais de dlai appliqu pour lenvoi de dae e e tagramme portant ladresse du groupe de base 224.0.0.1. Pour rafra chir leur connaissance des besoins de routage les routeurs envoient leurs questions avec une frquence tr`s faible de lordre de la minute, e e
11

tous les htes du LAN o

60

Protocole IP an de prserver au maximum la bande passante du rseau. Si aucune rponse e e e ne leur parvient pour tel ou tel groupe demand prcdement, le routage sine e e terrompt. Quand un hte rejoint un groupe, il envoie immdiatement une rponse o e e (type=report) pour le groupe (les) qui lintresse, plutt que dattendre une e o question du routeur. Au cas o` cette rponse se perdrait il est recommand u e e deectuer une rmission dans un court dlai. ee e Remarques : 1. Sur un LAN sans routeur pour le multicast, le seul trac IGMP est celui des htes demandant ` rejoindre tel ou tel groupe. o a 2. Il ny a pas de report pour quitter un groupe. 3. La plage dadresses multicast entre 224.0.0.0 et 224.0.0.225 est ddie aux applications utilisant une valeur de 1 pour le champ TTL e e (administration et services au niveau du LAN). Les routeurs ne doivent pas transmettre de tels datagrammes. 4. Il ny a pas de message ICMP sur les datagrammes ayant une adresse de destination du type multicast. En consquence les applications qui utilisent le multicast (avec une e adresse suprieure ` 224.0.0.225) pour dcouvrir des services, doivent e a e avoir une stratgie pour augmenter la valeur du champ TTL en cas de e non rponse. e

5.3

Fonctionnement du Mbone

Prcisions en cours. . . e

6 Routage IP

61

Routage IP

Ce paragraphe dcrit de mani`re succincte le routage des datagrammes. e e Sur lInternet, ou au sein de toute entit qui utilise IP, les datagrammes ne e sont pas routs par des machines Unix, mais par des routeurs dont cest la e fonction par dnition (et qui sont donc plus ecace et plus perfectionns e e pour cette tche). Toutefois il est courant dans les petits rseaux , ou a e quand le probl`me ` rsoudre reste simple, de faire appel ` une machine e a e a Unix pour ce faire12 . Nous examinerons donc le probl`me (simpli) du routage dans ce dernier e e cas. Les lecteurs soucieux den savoir plus sur ce probl`me tr`s vaste pourront e e se repporter ` la bibliographie en n de chapitre. a Le routage des datagrammes se fait au niveau de la couche IP, et cest son travail le plus important. Toutes les machines multiprocessus sont thoriquement capables deectuer cette opration. e e La dirence entre un routeur et un hte est que le premier est e o capable de transmettre un datagramme dun interface ` un autre et pas le a deuxi`me. e Cette opration est dlicate si les machines qui doivent dialoguer sont e e connectes ` de multiples rseaux physiques. e a e Dun point de vue idal tablir une route pour des datagrammes dee e vrait tenir compte dlments comme la charge du rseau, la taille des daee e tagrammes, le type de service demand, les dlais de propagation, ltat des e e e liaisons, le trajet le plus court. . .La pratique est plus rudimentaire ! Il sagit de transporter des datagrammes aux travers de multiples rseaux e physiques, donc aux travers de multiples passerelles. On divise le routage en deux grandes familles : Le routage direct Il sagit de dlivrer un datagramme ` une machine race a corde au mme LAN. e e Lmetteur trouve ladresse physique du correspondant (ARP), encape sule le datagramme dans une trame et lenvoie. Le routage indirect Le destinataire nest pas sur le mme LAN comme e prcdement. Il est absolument ncessaire de franchir une passerelle e e e connue davance ou demployer un chemin par dfaut. e En eet, toutes les machines ` atteindre ne sont pas forcment sur le a e mme rseau physique. Cest le cas le plus courant, par exemple sur e e lInternet qui regroupe des centaines de milliers de rseaux dirents. e e Cette opration est beaucoup plus dlicate que la prcdente car il faut e e e e slectionner une passerelle. e Parceque le routage est une opration fondamentalement oriente e e rseau , le routage sappuie sur cette partie de ladresse IP du destinae
on peut consulter par exemple http ://www.freebsd.org/picobsd/, o` le site du u projet Zebra de GNU http ://www.zebra.org/
12

62

Protocole IP taire. La couche IP dtermine celle-ci en examinant les bits de poids fort qui e conditionnent la classe dadresse et donc la segmentation network.host . Dans certain cas (CIDR) le masque de sous rseau est aussi employ. e e Muni de ce numro de rseau, la couche IP examine les informations e e contenues dans sa table de routage :

6.1

Table de routage

Sous Unix toutes les oprations de routage se font grce ` une table, dite e a a table de routage , qui se trouve dans le noyau lui-mme. La gure IV.14 e rsume la situation : e

Dmons DHCP de routage

Commande route

Commande netstat

ICMP

Algorithme de routage Table de routage

Couche IP

gure IV.14 Cette table est tr`s frquemment utilise par IP : sur un serveur plusieurs e e e centaines de fois par secondes. Comment est-elle cre ? e Au dmarrage avec la commande route, invoque dans les scripts de e e lancement du syst`me, et en fonctionnement : e Au coup par coup avec la commande route, ` partir du shell (admia nistrateur syst`me uniquement). e Dynamiquement avec les dmons de routage routed ou gated e (la frquence de mise ` jour est typiquement de lordre de 30 sec.). e a Par des messages ICMP redirect .

Table de routage IP La commande netstat -rn permet de la visualiser au niveau de linterface utilisateur ( Application layer ) : $ netstat -rn Routing tables Internet: Destination default 127.0.0.1 192.168.192/27 192.168.192.10 192.168.192.11 192.168.192.12 192.168.192.13 192.168.192.14 192.168.192.15 192.168.192.32/27 192.168.192.33 192.168.192.34 192.168.192.35 192.168.192.36

63

Gateway 192.168.192.36 127.0.0.1 link#1 8:0:9:85:76:9c 8:0:9:85:76:bd 8:0:9:88:8e:31 8:0:9:a:f9:bc 0:4f:49:1:28:22 link#1 link#2 8:0:9:70:44:52 0:20:af:2f:8f:f1 0:4f:49:1:36:50 link#2

Flags UGS UH UC UHLW UHLW UHLW UHLW UHLW UHLW UC UHLW UHLW UHLW UHLW

On peut mmoriser cette table comme tant essentiellement compose e e e dune colonne origine, dune colonne destination. De plus, chaque route qui dsigne une passerelle (ici la route par dfaut) e e doit saccompagner dun nombre de sauts ( hop ), ou encore mtrique, qui e permet le choix dune route plutt quune autre en fonction de cette valeur. o Chaque franchissement dun routeur compte pour un saut. Dans la table ci-dessus, la mtrique de la route par dfaut est 1. e e Remarque : la sortie de la commande netstat -rn ci-dessus a t simee 13 plie. e Les drapeaux ( ags ) les plus courants : C c D G H L M S U W
13

La route est gnre par la machine, ` lusage. e ee a La route a t cre dynamiquement (dmons de routage). ee e e La route dsigne une passerelle, sinon cest une route directe. e La route est vers une machine, sinon elle est vers un rseau. e Dsigne la conversion vers une adresse physique (cf ARP). e La route a t modie par un redirect . ee e La route a t ajoute manuellement. ee e La route est active. La route est le rsultat dun clnage. e o

Des colonnes Refs, Use et Netif

64

Protocole IP La gure 15 prcise larchitecture du rseau autour de la machine sur e e laquelle a t excut le netstat. ee e e

Subnet 000

.14 link 1

.35 link 2

Subnet 001

.36

gure IV.15

6.2

Routage statique

Comme nous avons pu le deviner au paragraphe prcdent, les routes stae e tiques sont celles cres au dmarrage de la machine ou ajoutes manuellement e e e par ladministeur syst`me, en cours de fonctionnement. e Le nombre de machines possibles ` atteindre potentiellement sur lIna ternet est beaucoup trop lev pour que chaque machine puisse esprer en e e e conserver ladresse, qui plus est, mme si cela tait concevable, cette infore e mation ne serait jamais ` jour donc inutilisable. a Plutt que denvisager la situation prcdente on prf`re restreindre o e e ee ltendue du monde connu et utiliser la stratgie de proche en proche e e prcdement cite. e e e Si une machine ne peut pas router un datagramme, elle connait (ou est suppose conna e tre) ladresse dune passerelle suppose tre mieux informe e e e pour transmettre ce datagramme. Dans lexemple de sortie de la commande netstat du paragraphe 6.1, on peut reconna que ladministrateur syst`me na congur quune seule tre e e 14 route manuellement , toutes les autres lignes ont t dduites par la ee e couche IP elle-mme. e La gure IV.16 met en situation plusieurs rseaux et les passerelles qui e les relient.

Ce nest pas tout ` fait exact, nous verrons pourquoi au paragraphe concernant lina terface de loopback (6.6).

14

Routage statique
.251 R1 .10.1

65

172.16

.10.3 192.168.192 R2 .1.1.1

.1 A B 1.1.23 10

gure IV.16 Et voici une version tr`s simplie des tables de routage statiques : e e Machine A default : 192.168.192.251 Machine B default : 10.1.1.1 Routeur R1 10 : 172.16.10.3 Routeur R2 192.168.192 : 172.16.10.1 Algorithme de routage Cet algorithme simpli rsume les oprations de la couche IP pour choie e e sir une destination, en fonction de sa table de routage. Cette opration est e essentiellement base sur le numro de rseau, IN , extrait de ladresse IP, ID . e e e M dsigne la machine sur laquelle seectue le routage. e Si IN est un numro de rseau auquel M est directement relie : e e e Obtenir ladresse physique de la machine destinatrice Encapsuler le datagramme dans une trame physique et lenvoyer directement. Sinon Si ID apparait comme une machine ` laquelle une route spciale est a e attribue, router le datagramme en fonction. e Sinon Si IN apparait dans la table de routage, router le datagramme en fonction.

66

Protocole IP Sinon Sil existe une route par dfaut router le datagramme vers la e passerelle ainsi dsigne. e e Sinon Dclarer une erreur de routage (ICMP). e

6.3

Routage dynamique

Si la topologie dun rseau ore la possibilit de plusieurs routes pour e e atteindre une mme destination, sil est vaste et complexe, sujet ` des chane a gements frquents de conguration. . .Le routage dynamique est alors un bon e moyen dentretenir les tables de routages et de mani`re automatique. e Il existe de nombreux protocoles de routage dynamique dont certains sont aussi anciens que lInternet. Nanmoins tous ne conviennent pas ` tous les e a types de probl`me, il en existe une hirarchie. e e Schmatiquement on peut imaginer lInternet comme une hirarchie de e e routeurs. Les routeurs principaux ( core gateways ) de cette architecture utilisent entres-eux des protocoles comme GGP ( Gateway to Gateway Protocol ), lensemble de ces routeurs forment ce que lon nomme l Internet Core . En bordure de ces routeurs principaux se situent les routeurs qui marquent la fronti`re avec ce que lon nomme les Autonomous systems , e cest ` dire des syst`mes de routeurs et de rseaux qui poss`dent leurs a e e e mcanismes propres de propagation des routes. Le protocole utilis par ces e e routeurs limitrophes est souvent EGP ( Exterior Gateway Protocol ) ou BGP ( Border Gateway Protocol ).
Internet Core

GGP Core Gateway EGP,BGP Core Gateway

RIP,OSPF External gateways

Autonomous System

Autonomous System

gure IV.17 Au sein dun syst`me autonome on utilise un IGP ( Interior Gateway e Protocol ) cest ` dire un protocole de gateways intrieurs . Les protocoles a e

Routage dynamique les plus couramment employs sont RIP ( Routing Information Protocol ) e qui est simple ` comprendre et ` utiliser, ou encore OSPF ( Open Shortest a a Path First ) plus rcent, plus capable mais aussi beaucoup plus complexe ` e a comprendre dans son mode de fonctionnement. RIP RIP est apparu avec la version BSD dUnix, il est document dans la e RFC 1058 (1988 - Version 1 du protocole) et la RFC 1723 (1994 - Version 2 du protocole). Ce protocole est bas sur des travaux plus anciens mens par e e la rme Xerox. RIP utilise le concept de vecteur de distance , qui sappuie sur un algorithme de calcul du chemin le plus court dans un graphe. Le graphe est celui des routeurs, la longueur du chemin est tablie en nombre de sauts e ( hop ), ou mtrique, entre la source et la destination, cest ` dire en e a comptant toutes les liaisons. Cette distance est exprime comme un nombre e entier variant entre 1 et 15 ; la valeur 16 est considre comme linni et ee indique une mise ` lcart de la route. a e Chaque routeur met dans un datagramme portant une adresse IP de e broadcast, ` frquence xe (environ 30 secondes), le contenu de sa table de a e routage et coute celle des autres routeurs pour complter sa propre table. e e Ainsi se propagent les tables de routes dun bout ` lautre du rseau. Pour a e viter une temptes de mises ` jours , le dlais de 30 secondes est augment e e a e e dune valeur alatoire comprise entre 1 et 5 secondes. e Si une route nest pas annonce au moins une fois en trois minutes, la e distance devient innie , et la route sera retire un peu plus tard de la e table (elle est propage avec cette mtrique). e e Ladresse IP utilise est une adresse de multipoint ( multicast ) comme e nous verrons au paragraphe 6.4 Depuis la dnition de RIPv2 (RFC 1723) les routes peuvent tre accome e pagnes du masque de sous rseau qui les caractrise. Ainsi on peut avoir la e e e situation suivante :
Subnet 192.168.192.224 (netmask 0xFFFFFFE0)

67

R1 Subnet 192.168.10.0

R2 Subnet 192.168.11.0

R4

R3

Subnet 192.168.192.64 (netmask 0xFFFFFFE0)

gure IV.18

68

Protocole IP Apr`s propagation des routes, la table de routage du routeur R1 pourrait e bien ressembler ` : a Source 192.168.192.224 192.168.10.0 192.168.11.0 192.168.192.64 Destination R1 R1 R2 R3 Cot u 1 1 2 3

Avec une route par dfaut qui est le routeur R2. La constitution de cette e table nest possible quavec RIPv2 tant donn lexistence des deux souse e rseaux de la classe C 192.168.192. e OSPF Prcisions en cours. e

6.4

Dcouverte de routeur et propagation de routes e

Au dmarrage dune station, plutt que de congurer manuellement les e o routes statiques, surtout si elle sont susceptibles de changer et que le nombre de stations est grand, il peut tre intressant de faire de la dcouverte e e e automatique de routeurs (RFC 1256). ` A intervals rguliers les routeurs diusent des messages ICMP de type 9 e ( router advertisement ) dannonces de routes. Ces messages ont ladresse multicast 224.0.0.1, qui est a destination de tous les htes du LAN. o Toutes les stations capables de comprendre le multicast (et convenablement congures pour ce faire) coutent ces messages et mettent ` jour leur e e a table. Les stations qui dmarrent peuvent solliciter les routeurs si lattente est e trop longue (environ 7 minutes) avec un autre message ICMP, de type 10 ( router sollicitation ) et avec ladresse multicast 224.0.0.2 (` destination a de tous les routeurs de ce LAN). La rponse du ou des routeurs est du type e unicast , sauf si le routeur sapprtait ` mettre une annonce. e ae ` chaque route est associ un niveau de prfrence et une dure de vaA e ee e lidit, dnis par ladministrateur du rseau. Une validit nulle indique un e e e e routeur qui sarrte et donc une route qui doit tre supprime. e e e Si entre deux annonces une route change, le mcanisme de ICMP redie rect , examin au paragraphe suivant, corrige lerreur de route. e La dcouverte de routeur nest pas un protocole de routage, son objectif e est bien moins ambitieux : obtenir une route par dfaut. e

Message ICMP redirect

69

6.5

Message ICMP redirect

La table de routage peut tre modie dynamiquement par un message e e ICMP (IV). La situation est celle de la gure IV.21.
Station Datagramme 1 ICMP redirect Datagramme 2 R1 R2

gure IV.21 La station veut envoyer un datagramme et sa table de routage lui commande dutiliser la route qui passe par le routeur R1. Le routeur R1 reoit le datagramme, scrute sa table de routage et c sapperoit quil faut dsormais passer par R2. Pour se faire : c e 1. Il re-route le datagramme vers R2, ce qui vite quil soit mis deux e e fois sur le LAN. 2. Il envoie un message ICMP redirect (type 5) ` la station, lui a indiquant la nouvelle route vers R2. Ce travail seectue pour chaque datagramme reu de la station. c D`s que la station reoit le message ICMP redirect elle met ` jour sa e c a table de routage. La nouvelle route est employe pour les datagrammes e qui suivent (vers la mme direction). e La route modie est visible avec la commande netstat -r, elle gure e avec le drapeau M (modication dynamique). Pour des raisons videntes de scurit, cette possibilit nest valable que e e e e sur un mme LAN. e

70

Protocole IP

6.6

Interface de loopback

Toutes les implmentations dIP supportent une interface de type e loopback . Lobjet de cette interface est de pouvoir utiliser les outils du rseau en local, sans passer par un interface rseau rel (associ ` une e e e e a carte physique). La gure IV.22 ci-contre, montre que la couche IP peut utiliser, selon le routage, linterface standard du rseau, o` linterface de loopback. e u Le routage est ici bien sr bas u e sur ladresse IP associe ` chacune e a des interfaces. Cette association est eectue sur une machine Unix ` e a laide de la commande ifconfig, qui tablit une correspondance entre un e pilote de priphrique (repr par son e e ee chier spcial) et une adresse IP. e Dans le cas du pilote de loopback, ladresse est standardise ` nimporte e a quelle adresse valide du rseau 127 e (page 34).

Internet IP

Rseau

Pilote de "loopback" Pilote de carte rseau Rseau physique

gure IV.22

La valeur courante est 127.0.0.1, do` lexplication de la ligne ci-dessous u dj` rencontre (page 62) dans le cadre de la table de routage : ea e Routing tables Internet: Destination ... 127.0.0.1 ...

Gateway 127.0.0.1

Flags UH

Netif lo0

Dans toutes les machines Unix modernes cette conguration est dj` ea prvue demble dans les scripts de dmarrage. e e e Concr`tement, tout dialogue entre outils clients et serveurs sur une mme e e machine est possible et mme souhaitable sur cet interface pour amliorer les e e performances et parfois la scurit15 . e e Lexemple dusage le plus marquant est sans doute celui du serveur de noms (voir page 103) qui tient compte explicitement de cet interface dans sa conguration.

Nous verrons ultrieurement (cf chapitre X) que le ltrage IP sur le 127/8 est aussi e ais que sur nimporte quel autre rseau e e

15

7 Finalement, comment a marche ? c

71

Finalement, comment a marche ? c

Dans ce paragraphe nous reprenons la gure III.06 (page 41) et nous y apportons comme tait annonc une explication du fonctionnement qui tienne e e compte des protocoles principaux examins dans ce chapitre. Pour cela nous e utilisons deux rseaux privs de la RFC 1918 : 192.168.10.0 et 192.168.20.0 e e et nous faisons lhypoth`se que la passerelle fonctionne comme une machine e Unix qui ferait du routage entre deux de ses interfaces !
A Internet R Internet B Internet

Rseau .109 ifA ifR1 .249

Rseau ifR2 .249

Rseau ifB .69

192.168.10.0

192.168.20.0

gure IV.23 Ce tableau rsume ladressage physique et logique de la situation : e Interface ifA ifB ifR1 ifR2 Adresse MAC 08 :00 :20 :20 :cf :af 00 :01 :e6 :a1 :07 :64 00 :06 :5b :0f :5a :1f 00 :06 :5b :0f :5a :20 Adresse IP 192.168.10.109 192.168.20.69 192.168.10.249 192.168.20.249

Nous faisons en outre les hypoth`ses suivantes : e 1. Les caches arp des machines A, B et R sont vides 2. La machine A a connaissance dune route vers le rseau 192.168.20 e passant par 192.168.10.249 et rciproquement la machine B voit le e rseau 192.168.10.0 via le 192.168.20.249 e 3. La machine A a connaissance de ladresse IP de la machine B La machine A envoie un datagramme ` la machine B, que se a passe t-il sur le rseau ? e Etape 1 La machine A applique lalgorithme de routage (page 65) et sapperoit que la partie rseau de ladresse de B nest pas dans le mme c e e LAN (192.168.10/24 et 192.168.20/20 di`rent). e Lhypoth`se 2 entraine quune route route existe pour atteindre ce e rseau, passant par R. Ladresse IP de R est dans le mme LAN, e e A peut donc atteindre R par un routage direct. La consquence de e lhypoth`se 1 implique que pour atteindre R directement il nous faut e dabord dterminer son adresse physique. Le protocole ARP (page 50) e doit tre utiliser. e

72

Protocole IP A envoie en consquence une trame ARP (page 52 comportant les e lments suivants : ee SENDER SENDER TARGET TARGET HA ADR HA ADR 08 :00 :20 :20 :cf :af 192.168.10.109 : : : : : 192.168.10.249

Avec un champ OPERATION qui contient la valeur 1, comme question ARP . Remarquez quici ladresse IP destination est celle de R ! Etape 2 R rpond ` la question ARP par une rponse ARP e a e (OPERATION contient 2) et un champ compl`t : ee SENDER SENDER TARGET TARGET HA ADR HA ADR 00 :06 :5b :0f :5a :1f 192.168.10.249 08 :00 :20 :20 :cf :af 192.168.10.109

Etape 3 A est en mesure denvoyer son datagramme ` B en passant par R. a Il sagit de routage indirect puisque ladresse de B nest pas sur le mme e LAN. Les adresses physiques et logiques se rpartissent maintenant e comme ceci : IP SOURCE IP TARGET MAC SOURCE MAC TARGET 192.168.10.109 192.168.20.69 08 :00 :20 :20 :cf :af 00 :06 :5b :0f :5a :1f

Remarquez quici ladresse IP destination est celle de B ! Etape 4 R a reu le datagramme depuis A et ` destination de B. Celle-ci c a est sur un LAN dans lequel R se trouve galement, un routage direct e est donc le moyen de transfrrer le datagramme. Pour la mme raison e e qu` ltape 1 R na pas ladresse MAC de B et doit utiliser ARP pour a e obtenir cette adresse. Voici les lments de cette question ARP : ee SENDER SENDER TARGET TARGET HA ADR HA ADR 00 :06 :5b :0f :5a :20 192.168.20.249 : : : : : 192.168.20.69

Etape 5 Et la rponse ARP : e SENDER SENDER TARGET TARGET HA ADR HA ADR 00 :01 :e6 :a1 :07 :64 192.168.20.69 00 :06 :5b :0f :5a :20 192.168.20.249

Etape 6 Enn, dans cette derni`re tape, R envoie le datagramme en proe e venance de A, ` B : a

8 Bibliographie IP SOURCE IP TARGET MAC SOURCE MAC TARGET 192.168.10.109 192.168.20.69 00 :06 :5b :0f :5a :20 00 :01 :e6 :a1 :07 :64

73

Remarque, comparons avec le datagramme de ltape 3. Si les adresses e IP nont pas chang, les adresses MAC, elles, di`rent compl`tement ! e e e Remarque : Si A envoie un deuxi`me datagramme, les caches ARP ont e les adresses MAC utiles et donc les tape 1, 2, 4 et 5 deviennent inutiles. . . e

Bibliographie
:

Pour en savoir plus : RFC 791 Internet Protocol. J. Postel. Sep-01-1981. (Format TXT=97779 bytes) (Obsoletes RFC0760) (Status : STANDARD)

RFC 826 Ethernet Address Resolution Protocol : Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware. D.C. Plummer. Nov-01-1982. (Format : TXT=22026 bytes) (Status : STANDARD) RFC 903 Reverse Address Resolution Protocol. R. Finlayson, T. Mann, J.C. Mogul, M. Theimer. Jun-01-1984. (Format : TXT=9345 bytes) (Status : STANDARD) RFC 950 Internet Standard Subnetting Procedure. J.C. Mogul, J. Postel. Aug-01-1985. (Format : TXT=37985 bytes) (Updates RFC0792) (Status : STANDARD) RFC 1112 Host extensions for IP multicasting. S.E. Deering. Aug-011989. (Format : TXT=39904 bytes) (Obsoletes RFC0988, RFC1054) (Updated by RFC2236) (Also STD0005) (Status : STANDARD) RFC 1256 ICMP Router Discovery Messages. S. Deering. Sep-01-1991. (Format : TXT=43059 bytes) (Also RFC0792) (Status : PROPOSED STANDARD) W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols Addison-Wesley Douglas Comer - Internetworking with TCP/IP - Principles, protocols, and architecture - PrenticeHall Craig Hunt - TCP/IP Network Administration - OReilly & Associates, Inc. Christian Huitema - Le routage dans lInternet - EYROLLES

74

Protocole IP

Chapitre V Protocole UDP

1 UDP User Datagram Protocol

UDP est lacronyme de User Datagram Protocol, il est dni dans la e RFC 768 [Postel 1980]. Les donnes encapsules dans un en-tte UDP sont des e e e paquets UDP.

1.1

Identication de la destination

Rappel : Au niveau de la couche Internet les datagrammes sont routs e dune machine ` une autre en fonction des bits de ladresse IP qui identient le a numro de rseau. Lors de cette opration aucune distinction nest faite entre e e e les services ou les utilisateurs qui mettent ou recoivent des datagrammes, ie e tous les datagrammes sont mlangs. e e La couche UDP ajoute un mcanisme qui permet lidentication du service e (niveau Application). En eet, il est indispensable de faire un tri entre les divers applications (services) : plusieurs programmes de plusieurs utilisateurs peuvent utiliser simultanment la mme couche de transport et il ne doit pas e e y avoir de confusion entre eux. Pour le syst`me Unix les programmes sont identis de mani`re unique e e e par un numro de processus, mais ce numro est phm`re, non prvisible ` e e e e e e a distance, il ne peut servir ` cette fonction. a Lide est dassocier la destination ` la fonction quelle remplie. Cette e a identication se fait ` laide dun entier positif que lon baptise port. a Le syst`me dexploitation local a ` sa charge de dnir le mcanisme e a e e qui permet ` un processus daccder ` un port. a e a La plupart des syst`mes dexploitation fournissent le moyen dun acc`s e e synchrone ` un port. Ce logiciel doit alors assurer la possibilit de grer a e e la le dattente des paquets qui arrivent, jusqu` ce quun processus a 1 (Application) les lise. A linverse, lOS bloque un processus qui tente de lire une donne non encore disponible. e
1

Operating System

76

Protocole UDP Pour communiquer avec un service distant il faut donc avoir connaissance de son numro de port, en plus de ladresse IP de la machine elle-mme. e e On peut prvoir le numro de port en fonction du service ` atteindre, e e a cest lobjet du paragraphe 1.3. La gure 1 explicite la notion de port. La couche IP spare les datae 2 grammes TCP et UDP grce au champ PROTO de son en-tte, lassociation a e du protocole de transport et du numro de port identie un service sans e ambigu e. t Conceptuellement on sapperoit alors que rien ne soppose ` ce quun c a mme service (Numro de port) soit attribu conjointement aux deux protoe e e coles (pointill sur la gure). Cette situation est dailleurs courante dans la e ralit des serveurs. e e

Application

Port 1

Port 2

Port 3

Message

Transport
Paquet UDP

UDP

TCP

Internet

IP

gure V.01

Cf Protocole IP page 43

Description de len-tte e

77

1.2

Description de len-tte e

Un paquet UDP est conu pour tre encapsul dans un datagramme IP c e e et permettre un change de donnes entre deux applications, sans change e e e prliminaire. Ainsi, si les donnes ` transmettre nobligent pas IP ` frage e a a menter (cf page 47), un paquet UDP gn`re un datagramme IP et cest tout ! e e

Header IP

Paquet UDP = donnes dIP

PROTO

= UDP

gure V.02 UDP apporte un mcanisme de gestion des ports, au dessus de la couche e Internet. UDP est simplement une interface au dessus dIP, ainsi lmission e des messages se fait-elle sans garantie de bon acheminement. Plus gnralement, tous les dfauts dIP recenss au chapitre prcdent sont e e e e e e applicables ` UDP. a Plus particuli`rement, les paquets ` destination dune application UDP e a sont conservs dans une pile de type FIFO. Si lapplication destinae trice ne les consomme pas assez rapidement, les plus anciens paquets risquent dtre crass par les plus rcents. . .Un risque supplmentaire e e e e e (par rapport aux proprits dIP dj` connues) de perte de donnes. ee ea e Il ny a aucun retour dinformation au niveau du protocole pour apporter un quelconque moyen de contrle sur le bon acheminement des o donnes. e Cest au niveau applicatif quil convient de prendre en compte cette lacune. UDP est aussi dsign comme un mode de transport non connect, ou e e e encore mode datagramme, par opposition ` TCP que nous examinerons a dans le chapitre suivant. Parmis les utilisations les plus courantes dUDP on peut signaler le serveur de noms3 , base de donnes rpartie au niveau mondial, et qui saccomode e e tr`s bien de ce mode de transport. e En local dautres applications tr`s utiles comme tftp ou nfs sont e galement susceptibles demployer UDP. e

DNS RFC 1035 Ce service utilise UDP dans le cas dchanges de petits paquets e dinformations ( 512 octets) sinon il utilise TCP

78 La gure V.03 dcrit la structure de len-tte. e e

31 UDP SOURCE PORT MESSAGE LENGTH DATA .... ... 16 15

Protocole UDP

0 UDP DESTINATION PORT CHECKSUM

gure V.03 UDP SOURCE PORT Le numro de port de lmetteur du paquet. Ce champ e e est optionnel, quand il est spci il indique le numro de port que le e e e destinataire doit employer pour sa rponse. La valeur zro (0) indique e e quil est inutilis, le port 0 nest donc pas celui dun service valide. e UDP DESTINATION PORT Le numro de port du destinataire du paquet. e MESSAGE LENGTH Cest la longueur du paquet, donc comprennant len-tte e et le message. La longueur minimal est 8 La longueur maximale est 65 535 H(IP ). Dans le cas courant (IP sans option) cette taille maximale est donc de 65 515. CHECKSUM Le checksum est optionnel et toutes les implmentations ne lutie lisent pas. Sil est employ, il porte sur un pseudo en-tte constitu de e e e la mani`re suivante : e
31 24 23 16 15 Source Address 8 7 0

zero

Destination Address Protocol UDP length UDP destination port CHECKSUM DATAS

UDP source port UDP length

gure V.04 Ce pseudo en-tte est prvu initialement pour apporter une protection e e en cas de datagrammes mal routs ! e

Ports rservs disponibles e e

79

1.3

Ports rservs ports disponibles e e

Le numro de port est un entier 16 bits non sign, les bornes sont donc e e [0, 65535], par construction. Nous avons vu prcdement que le port 0 nest e e pas exploitable en tant que dsignation de service valide, donc le segment e rellement exploitable est [1, 65535]. e Toute machine qui utilise la pile TCP/IP se doit de conna un certain tre nombre de services bien connus, reprs par une srie de ports bien connus ou ee e well known port numbers, pour pouvoir dialoguer avec les autres machines de lInternet (vs Intranet). Sur une machine Unix, cette liste de services est place dans le chier /etc/services et lisible par tous les utilisateurs et e toutes les applications. En eet, comme nous lexaminerons en dtail dans le cours de programe mation, un service (comprendre un programme au niveau applicatif) qui dmarre son activit rseau (et qui donc est considr comme ayant un rle e e e ee o de serveur) sattribue le (les) numro(s) de port qui lui revient (reviennent) e conformment ` cette table. e a Nom echo echo ftp-data ftp-data ftp ftp telnet telnet smtp smtp domain domain http http pop3 pop3 sunrpc sunrpc nntp nntp Port Proto 7 tcp 7 udp 20 tcp 20 udp 21 tcp 21 udp 23 tcp 23 udp 25 tcp 25 udp 53 tcp 53 udp 80 tcp 80 udp 110 tcp 110 udp 111 tcp 111 udp 119 tcp 119 udp Commentaire

#File #File #File #File

Transfer Transfer Transfer Transfer

[Default Data] [Default Data] [Control] [Control]

mail #Simple Mail Transfer mail #Simple Mail Transfer #Domain Name Server #Domain Name Server www www-http #World Wide Web HTTP www www-http #World Wide Web HTTP #Post Office Protocol - Version 3 #Post Office Protocol - Version 3 rpcbind #SUN Remote Procedure Call rpcbind #SUN Remote Procedure Call usenet #Network News Transfer Protocol usenet #Network News Transfer Protocol gure V.05

Le tableau de la gure V.05 indique quelques uns des plus connus et plus utiliss ports bien connus, il y en a quantit dautres. . . e e

80

Protocole UDP Une autorit, lIANA4 , centralise et diuse linformation relative ` tous e a les nombres utiliss sur lInternet via une RFC. La derni`re en date est la e e RFC 1700, elle fait plus de 200 pages ! Par voie de consquence cette RFC concerne aussi les numros de ports. e e Attribution des ports ancienne mthode e Historiquement les ports de 1 ` 255 sont rservs aux services bien connus, a e e plus rcemment, ce segment ` t largi ` [1, 1023]. Aucune application ne e aeee a peut sattribuer durablement et au niveau de lInternet un numro de port e dans ce segment, sans en rfrrer ` lIANA, qui en contrle lusage. ee a o ` A partir de 1024 et jusqu` 65535, lIANA se contente denregistrer les a demandes dusage et signale les ventuels conits. e Attribution des ports nouvelle mthode e Devant lexplosion du nombre des services enregistr lIANA a modi la e e 5 segmentation qui prc`de. Dsormais les numros de ports sont classs selon e e e e e les trois catgories suivantes : e 1. Le segment [1, 1023] est toujours rservs aux services bien connus. e e Les services bien connus sont dsigns par lIANA et sont mis en uvre e e par des applications qui sexcutent avec des droits privilgis (root sur e e e une machine Unix) 2. Le segment [1024, 49151] est celui des services enregistrs. e Ils sont numrs par lIANA et peuvent tre employs par des procese ee e e sus ayant des droits ordinaires. Par exemple : Nom Port Proto Commentaire bpcd 13782 tcp VERITAS NetBackup bpcd 13782 udp VERITAS NetBackup 3. Le segment [49152, 65535] est celui des attributions dynamiques et des services privs ; nous en examinerons lusage dans le cours de proe grammation.

4 5

Internet Assigned Numbers Authority http ://www.iana.org/assignments/port-numbers

2 Bibliographie

81

Bibliographie

Pour en savoir plus : RFC 768 User Datagram Protocol. J. Postel. Aug-28-1980. (Format : TXT=5896 bytes) (Status : STANDARD) RFC 1035 Domain names - concepts and facilities. P.V. Mockapetris. Nov-01-1987. (Format : TXT=129180 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Obsoleted by RFC1065, RFC2065) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181) (Status : STANDARD) RFC 1700 ASSIGNED NUMBERS. J. Reynolds,J. Postel. October 1994. (Format : TXT=458860 bytes) (Obsoletes RFC1340) (Also STD0002) (Status : STANDARD) RFC 1918 Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot & E. Lear. February 1996. (Format : TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also BCP0005) (Status : BEST CURRENT PRACTICE) Sans oublier : W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols Addison-Wesley 1994 Douglas Comer - Internetworking with TCP/IP - Principles, protocols, and architecture - PrenticeHall

82

Protocole UDP

Chapitre VI Protocole TCP

1 TCP Transport Control Protocol

TCP est lacronyme de Transport Control Protocol , il est dni dans e la RFC 793 [Postel 1981c]. Les donnes encapsules dans un en-tte TCP sont e e e des paquets TCP .
Header IP Segment TCP = donnes IP

PROTO

= TCP

gure VI.01

1.1

Caractristiques de TCP e

TCP est bien plus compliqu1 quUDP examin au chapitre prcdent, il e e e e apporte en contrepartie des services beaucoup plus labors. e e Cinq points principaux caractrisent ce protocole : e 1. TCP contient un mcanisme pour assurer le bon acheminement des e donnes. Cette possibilit est absolument indispensable d`s lors que e e e les applications doivent transmettre de gros volumes de donnes et de e faon able. c Il faut prciser que les paquets de donnes sont acquitts de bout en e e e bout et non de point en point. Dune mani`re gnrale le rseau assure e e e e lacheminement et les extrmits le contrle (Dave Clark). e e o 2. Le protocole TCP permet ltablissement dun circuit virtuel entre e les deux points qui changent de linformation. On dit aussi que TCP e
Une simple comparaison du volume des RFC initiales est parlante : 85 pages pour TCP, 3 pour UDP !
1

84

Protocole TCP fonctionne en mode connect (par opposition ` UDP qui est en mode e a non connect ou encore mode datagramme). e Avant le transfert les 2 applications se mettent en relation avec leurs OS2 respectifs, les informent de leurs dsirs dtablir ou de recevoir e e une communication. Pratiquement, lune des deux applications doit eectuer un appel que lautre doit accepter. Les protocoles des 2 OS communiquent alors en senvoyant des messages au travers du rseau pour vrier que le transfert est possible e e (autoris) et que les deux applications sont prtes pour leurs rles. e e o Une fois ces prliminaires tablis, les modules de protocole informent e e les applications respectives que la connexion est tablie et que le e transfert peut dbuter. e Durant le transfert, le dialogue entre les protocoles continue, pour vrier le bon acheminement des donnes. e e Conceptuellement, pour tablir une connexion un circuit virtuel e il faut avoir runis les lments du quintuplet : e ee Le protocole Cest TCP mais il y pourrait y avoir dautres transports qui assurent le mme service. . . e IP locale Adresse de la machine qui met. e Port local Le numro de port associ au processus. Il est impos ou e e e est dtermin automatiquement comme nous le verrons dans le e e cours de programmation. IP distante Adresse de la machine distante. Port distant Le numro de port associ au service ` atteindre. Il est e e a obligatoire de le conna prcisement. tre e Lensemble de ces cinq lments dnit un circuit virtuel unique. Que ee e lun deux change et il sagit dune autre connexion ! 3. TCP a la capacit de mmoriser3 des donnes : e e e Aux deux extrmits du circuit virtuel, les applications senvoient e e des volumes de donnes absolument quelconques, allant de 0 octet ` e a des centaines (ou plus) de Mo. ` A la rception, le protocole dlivre les octets exactement comme ils e e ont t envoys. ee e Le protocole est libre de fragmenter le ux de donnes en paquets e de tailles adaptes aux rseaux traverss. Il lui incombe cependant e e e deectuer le rassemblage et donc de stocker temporairement les e fragments avant de les prsenter dans le bon ordre ` lapplication. e a 4. TCP est indpendant vis ` vis des donnes transportes, cest un e a e e ux doctets non structur sur lequel il nagit pas. e
2 3

Operating System dans un buer

Description de len-tte e 5. TCP simule une connexion en full duplex . Pour chacune des deux applications en connexion par un circuit virtuel, lopration qui consiste e ` lire des donnes peut seectuer indpendamment de celle qui consiste a e e ` en crire. a e Le protocole autorise la clture du ot dans une direction tandis que o lautre continue ` tre active. Le circuit virtuel est rompu quand les a e deux parties ont clos le ux.

85

1.2

Description de len-tte e

La gure suivante montre la structure dun en-tte TCP. Sa taille normale e est de 20 octets, ` moins que des options soient prsentes. a e
31 21 16 15 87 TCP SOURCE PORT TCP DESTINATION PORT SEQUENCE NUMBER ACKNOWLEDGEMENT NUMBER OFF RESERVED CODE CHECKSUM OPTIONS DATA ... WINDOW URGENT POINTER PADDING 0

gure VI.02 TCP SOURCE PORT Le numro de port de lapplication locale. e TCP DESTINATION PORT Le numro de port de lapplication distante. e SEQUENCE NUMBER Cest un nombre qui identie la position des donnes ` e a transmettre par rapport au segment original. Au dmarrage de chaque e connexion, ce champ contient une valeur non nulle et non facilement prvisible, cest la squence initiale ou ISN4 e e TCP numrote chaque octet transmis en incrmentant ce nombre 32 bits e e non sign. Il repasse ` 0 apr`s avoir atteint 232 1 (4 294 967 295). e a e Pour le premier octet des donnes transmis ce nombre est incrment e e e de un, et ainsi de suite. . . ACKNOWLEDGEMENT NUMBER Cest un numro qui identie la position du dere nier octet reu dans le ux entrant. c Il doit saccompagner du drapeau ACK (voir plus loin). OFF pour OFFSET, il sagit dun dplacement qui permet datteindre les e donnes quand il y a des options. Cod sur 4 bits, il sagit du nombre e e de mots de 4 octets qui composent len-tte. Le dplacement maximum e e 4 est donc de 60 octets (2 1 4 octets). Dans le cas dun en-tte e sans option, ce champ porte la valeur 5. 10 mots de 4 octets sont donc possibles pour les options.
4

Initial Sequence Number

86 RESERVED Six bits rservs pour un usage futur ! e e

Protocole TCP

CODE Six bits pour inuer sur le comportement de TCP en caractrisant e lusage du segment : URG Le champ URGENT POINTER doit tre exploit. e e ACK Le champ ACNOWLEDGMENT NUMBER doit tre exploit. e e PSH Cest une notication de lmetteur au rcepteur, pour e e lui indiquer que toutes les donnes collectes doivent tre e e e transmises ` lapplication sans attendre les ventuelles a e donnes qui suivent. e RST SYN FIN Re-initialisation de la connexion Le champ SEQUENCE NUMBER contient la valeur de dbut de connexion. e Lmetteur du segment a ni dmettre. e e

En fonctionnement normal un seul bit est activ ` la fois mais ce nest ea pas une obligation. La RFC 1024 [Postel 1987] dcrit lexistence de e paquets tcp dnomms Christmas tree ou paquet kamikaze e e comprenant les bits SYN+URG+PSH+FIN ! WINDOW Le ux TCP est control de part et dautre pour les octets come pris dans une zone bien dlimite et nomme fentre . La taille e e e e de celle-ci est dnie par un entier non sign de 16 bits, qui en limite e e donc thoriquement la taille ` 65 535 octets (ce nest pas compl`tement e a e exact, voir plus loin loption wscale). Chaque partie annonce ainsi la taille de son buer de rception. Par e construction, lmetteur nenvoie pas plus de donnes que le rcepteur e e e ne peut en accepter. Cette valeur varie en fonction de la nature du rseau et surtout de la e bande passante devine ` laide de statistiques sur la valeur du RTT. e a Nous y reviendrons au paragraphe 4. CHECKSUM Un calcul qui porte sur la totalit du segment, en-tte et donnes. e e e URGENT POINTER Ce champ nest valide que si le drapeau URG est arm. Ce e pointeur contient alors un oset ` ajouter ` la valeur de SEQUENCE a a NUMBER du segment en cours pour dlimiter la zone des donnes urgentes e e ` transmettre ` lapplication. a a Le mcanisme de transmission ` lapplication dpend du syst`me dexe a e e ploitation. OPTIONS Cest un param`trage de TCP. Sa prsence est dtecte d`s lors que e e e e e lOFFSET est suprieur ` 5. e a Les options utilises : e

Description de len-tte e mss La taille maximale du segment5 des donnes applicatives que e lmetteur accepte de recevoir. Au moment de ltablissement e e dune connexion (paquet comportant le ag SYN), chaque partie annonce sa taille de MSS. Ce nest pas une ngociation. Pour e de lEthernet la valeur est 1460 ( = M T U 2 20). timestamp pour calculer la dure dun aller et retour (RTT ou e round trip time ). wscale Facteur dchelle ( shift ) pour augmenter la taille de la e fentre au del` des 16 bits du champ WINDOW (> 65535). e a Quand cette valeur nest pas nulle, la taille de la fentre est de e 65535 2shif t . Par exemple si shift vaut 1 la taille de la fentre e est de 131072 octets soit encore 128 ko. nop Les options utilisent un nombre quelconque doctets par contre les paquet TCP sont toujours aligns sur une taille de mot de quatre e octets ; ` cet eet une option No Operation ou nop, code sur a e 1 seul octet, est prvue pour complter les mots. e e PADDING Remplissage pour se caler sur un mot de 32 bits. DATAS Les donnes transportes. Cette partie est de longueur nulle ` e e a ltablissement de la connexion, elle peut galement tre nulle par choix e e e de lapplication.

87

MSS= Maximum Segment Size

88

Protocole TCP

2
2.1

Dbut et clture dune connexion e o

Etablissement dune connexion

Ltablissement dune connexion TCP seectue en trois temps, comme le e schma de la gure 3 lexplicite. e
Emetteur
SYN (seq=x)

Rcepteur

SYN (seq=y) ACK (seq=x+1)

ACK(seq=y+1)

Temps

gure VI.03 On suppose que lmetteur du premier paquet avec le bit SYN a connaise sance du couple (adresse IP du rcepteur, numro de port du service soue e hait). e Lmetteur du premier paquet est ` lorigine de ltablissement du circuit e a e virtuel, cest une attitude gnralement qualie de cliente . On dit aussi e e e que le client eectue une ouverture active (active open). Le rcepteur du premier paquet accepte ltablissement de la connexion, e e ce qui suppose quil tait prt ` le faire avant que la partie cliente en prenne e e a linitiative. Cest une attitude de serveur . On dit aussi que le serveur eectue une ouverture passive (passive open). 1. Le client envoie un segment comportant le drapeau SYN, avec sa squence initiale (ISN = x). e 2. Le serveur rpond avec sa propre squence (ISN = y), mais il doit e e galement acquitter le paquet prcdent, ce quil fait avec ACK (seq = e e e x + 1). 3. Le client doit acquitter le deuxi`me segment avec ACK (seq = y + 1). e

Clture dune connexion o Une fois acheve cette phase nomme three-way handshake , les deux e e applications sont en mesure dchanger les octets qui justient ltablissement e e de la connexion.

89

2.2

Clture dune connexion o

Clture canonique o Un change de trois segments est ncessaire pour ltablissement de la e e e connexion ; il en faut quatre pour quelle sach`ve de mani`re canonique ( ore e derly release ).

Emetteur
close FIN (seq=x)

Rcepteur
Envoi dun EOF ACK (seq = x + 1) lapplication

Flux de donnes du rcepteur vers lmetteur FIN (seq = y) Envoi dun EOF lapplication ACK (seq = y + 1) Temps close

Dernier segment de la connexion

gure VI.04 La raison est quune connexion TCP est full-duplex , ce qui implique que les donnes circulent indpendamment dans un sens et dans lautre. Les deux e e directions doivent donc pouvoir tre interrompues indpendamment lune de e e lautre. Lapplication qui envoie un paquet avec le drapeau FIN indique ` la couche a TCP de la machine distante quelle nenverra plus de donne. La machine e distante doit acquitter ce segment, comme il est indiqu sur la gure VI.04, e en incrmentant dune unit le sequence number . e e La connexion est vritablement termine quand les deux applications ont e e eectu ce travail. Il y a donc change de 4 paquets pour terminer la cone e nexion.

90

Protocole TCP Au total, sans compter les changes propres au transfert des donnes, les e e deux couches TCP doivent grer 7 paquets, il faut en tenir compte lors de la e conception des applications ! Sur la gure on constate que le serveur continue denvoyer des donnes e bien que le client ait termin ses envois. Le serveur a dtect cette attitude e e e par la rception dun caract`re de EOF (en C sous Unix). e e Cette possibilit a son utilit, notamment dans le cas des traitements dise e tants qui doivent saccomplir une fois toutes les donnes transmises, comme e par exemple pour un tri. Clture abrupte o Au lieu dun change de quatre paquets comme prcdement, un e e e mcanisme de reset est prvu pour terminer une connexion au plus vite (abore e tive release). Ce type darrt est typiquement gr par la couche TCP elle-mme quand e ee e lapplication est brutalement interrompue sans avoir eectu un appel ` e a la primitive close(2), comme par exemple lors dun appel ` la primitive a abort(2), ou apr`s avoir rencontr une exception non prise en compte ( core e e dump . . .). Lextremit qui arrte brutalement la connexion met un paquet assorti e e e du bit RST, apr`s avoir (ou non) envoy les derniers octets en attente6 . Ce e e paquet clt lchange. Il ne reoit aucun acquittement. o e c Lextrmit qui reoit le paquet de reset (bit RST), transmet les ventuelles e e c e derni`res donnes ` lapplication et provoque une sortie derreur du type e e a Connection reset par peer pour la primitive de lecture rseau. Comme e cest le dernier change, si des donnes restaient ` transmettre ` lapplication e e a a qui a envoy le RST elles peuvent tre dtruites. e e e

Emetteur
RST

Rcepteur

gure VI.05
6

Voir dans le cours de programmation, loption SO LINGER

3 Contrle du transport o

91

Contrle du transport o

Le bon acheminement des donnes applicatives est assur par un e e mcanisme dacquittement des paquets, comme nous avons dj` pu lexae ea miner partiellement au paragraphe prcdent. e e

3.1

Mcanisme de lacquittement e
Emetteur
Paquet i Horloge

Rcepteur

RTT

ACK Paquet i+1

gure VI.06 Au dpart du Paquet i une horloge se dclenche. Si cette horloge dpasse e e e une valeur limite avant rception de lACK le Paquet i est retransmis e Cette valeur limite est base sur la constante MSL7 qui est un choix e dimplmentation, gnralement de 30 secondes ` 2 minutes. Le temps e e e a maximum dattente est donc de 2 M SL. Le temps qui scoule entre lmission dun paquet et la rception de son e e e 8 acquittement est le RTT , il doit donc tre infrieur ` 2 M SL. Il est e e a courant sur lInternet actuel davoir un RTT de lordre de la seconde. Il faut noter que le RTT est la somme des temps de transit entre chaque routeur et du temps pass dans les diverses les dattente sur les roue teurs. Lmetteur conserve la trace du Paquet i pour ventuellement le rene e voyer. Si on consid`re des dlais de transmission de lordre de 500 ms (voire plus), e e un tel mcanisme est totalement inadapt au transfert de ux de donnes. e e e On peut aussi remarquer quil sous-emploi la bande passante du rseau. e
7 8

Maximum Segment Lifetime Round Trip Time

92

Protocole TCP

3.2

Fentres glissantes e

Cette attente de lacquittement est pnalisante, sauf si on utilise un e 9 mcanisme de fentres glissantes , comme le sugg`re la gure VI.07 : e e e

Emetteur
Paquet i Paquet i+1 Paquet i+2 Paquet i+3 ACK(i) Paquet i+4

Rcepteur

Dure maximale dattente pour lacquittement sur le Paquet i

gure VI.07 Avec ce principe, la bande passante du rseau est beaucoup mieux e employe. e Si lun des paquets doit tre remis, la couche TCP du destinataire aura e e toute linformation pour le replacer dans le bon ordre. ` A chaque paquet est associe une horloge comme sur la gure VI.05. e Le nombre de paquets ` envoyer avant dattendre le premier acquittea ment est en fonction de deux param`tres : e 1. La largeur de la fentre est prcise dans le champ WINDOW de e e e len-tte. Des valeurs courantes sont de lordre de 4096, 8192 ou e 16384. Elle change dynamiquement pour deux raisons : (a) Lapplication change la taille du buer de la socket 10 qui correspond ` la taille de cette fentre. a e (b) Chaque acquittement ACK envoy est assorti dune nouvelle e valeur de taille de la fentre, permettant ainsi ` lmetteur e a e dajuster ` tout instant le nombre de segment quil peut ena voyer simultanment. e
9 10

sliding windows voir le cours de programmation

Fentres glissantes e 2. La taille maximale des donnes, ou MSS11 vaut 512 octets par e dfaut. Cest la plus grande taille du segment de donnes que TCP e e enverra. Le datagramme IP a donc une taille gale au MSS augmente de e e 40 octets (20 + 20), en labsence doption de TCP. Cette option apparait uniquement dans un paquet assorti du drapeau SYN, donc ` ltablissement de la connexion. a e Comme de bien entendu cette valeur est fortement dpendante du e 12 support physique et plus particuli`rement du MTU . e Sur de lEthernet la valeur maximale est 1500220 = 1460, avec des trames lencapsultation 802.3 de lIEEE un calcul similaire conduit ` une longueur de 1452 octets. a Chaque couche TCP envoie sa valeur de MSS en mme temps que le e paquet de synchronisation, comme une option de len-tte. Cette e valeur est calcule pour viter absolument la fragmentation de IP e e au dpart des datagrammes. e

93

MSS accept par le destinataire

Fentre possible pour le destinataire (dernier acquittement) Fentre utilisable

10

...

Dj envoys, ACK reus.

Envoys, ACK non reus.

Peuvent tre envoys

Ne peuvent pas encore tre envoys, il faut attendre que la fentre se dplace.

gure VI.08 Le dbit obtenu dpend de la taille de la fentre et bien sr de la bande e e e u passante disponible. On conoit aisment quentre la situation de la gure c e VI.06 et celle de la gure VI.07 lusage de la bande passante samliore. Par e contre lagrandissement de la taille de la fentre ne se conoit que jusqu` une e c a limite optimale au dela de laquelle des paquets sont perdus parcequenvoys e trop rapidement pour tre reus par le destinataire. Or, pour fonctionner de e c mani`re optimale, TCP se doit de limiter au maximum la perte de paquets et e donc leur remission. e
11 12

Maximum Segment Size Maximum Transfert Unit

94

Protocole TCP Cette taille limite optimale de la largeur de la fentre est, comme on e peut le deviner, fonction de la bande passante thorique du rseau et surtout e e de son taux doccupation instantann. Cette derni`re donne est uctuante, e e e aussi TCP doit-il asservir continuement les tailles de fentre pour en tenir e compte.

4 Complments sur le fonctionnement de TCP e

95

Complments sur le fonctionnement de TCP e

Lusage du protocole TCP di`re considrablement en fonction des applie e cations mises en uvre et des rseaux ` parcourir. e a Dapr`s [W. Richard Stevens], 10% des donnes changes sur le e e e e rseau concernent des applications interactives et 90% des applications qui e changent des ux de donnes. e e Si le protocole TCP reste le mme pour tous, les algorithmes qui le pilotent e sajustent en fonction de lusage. Pour le trac en volume ( bulk data ), TCP tente dutiliser des paquets les plus larges possibles pour maximiser le dbit, alors que le trac interactif e utilise des paquets quasiment vides mis le plus souvent ` la frquence de e a e frappe des utilisateurs ou au rythme des mouvements dune souris. Un exemple typique est celui de lapplication telnet pour laquelle les caract`res sont envoys un ` un dans un paquet dirent, chaque caract`re e e a e e tant ` lorigine de quatre paquets : mission dun caract`re, acquittement, e a e e retour de lcho du caract`re, acquittement. e e Si ce comportement nest absolument pas pnalisant sur un rseau rapide e e (LAN) par contre d`s que la bande passante commence ` tre stature il e a e e est prfrable de regrouper un maximum doctets (deux ou trois en pratique) ee dans un seul paquet pour en diminuer le nombre. Cest ce que fait lalgorithme de Nagle.

4.1

Algorithme de Nagle

Pour rduire le trac de ces tinygrams (RFC 896), lalgorithme de e Nagle (1984) dit quune connextion TCP ne peut pas attendre plus dun acquittement. Deux cas se prsentent donc : e 1. Le rseau est lent. Dans ce cas TCP accumule dans un mme buer les e e octets en partance. D`s rception de lacquittement il y a mission du e e e contenu du buer en un seul paquet. 2. Le rseau est rapide. Les acquittements arrivent rapidement les agrgats e e doctets peuvent tendre vers un seul caract`re par paquet. e La qualit lent/rapide du rseau est calcule ` partir du timestamp e e e a envoy dans les options de TCP et qui est tabli d`s le premier change (puis e e e e revalue statistiquement par la suite). e e Llgance de cet algorithme est quil est tr`s simple et quil sauto-rgule ee e e suivant le dlais de propagation. e Certaines applications dsactivent cet algorithme13 comme le serveur e Apache ou le syst`me de multi-fentrage X11. e e
13

` laide de loption TCP NODELAY a

96

Protocole TCP

4.2

Dpart lent e

Un paquet est remis parcequil arrive corrompu ou parcequil narrive e jamais. Une remission entraine un blocage de lavancement de la fentre e e glissante , pnalisant pour le dbit. e e TCP consid`re quun paquet perdu est la consquence dun routeur (ou e e plus) congestionn, cest ` dire pour lequel les les dattente ne sont pas e a assez larges pour absorber tous les paquets entrants14 Dans ce contexte, on comprend bien quil vaut mieux ne pas envoyer la totalit du contenu de la fentre d`s le dbut de la connexion. Au contraire, e e e e TCP utilise un algorithme nomm slow start qui asservit lmission des e e paquets au rythme de la rception de leurs acquittements, plutt que de les e o mettre dun coup aussi rapidement que lautorise le syst`me ou le dbit e e e thorique du rseau. e e Ainsi, au dbut de chaque connexion ou apr`s une priode de calme e e e ( idle ) lmetteur envoie un premier paquet de taille maximale (le mss e du destinataire), et attend son acquittement. Quand celui-ci est reu, il enc voie deux paquets, puis quatre, et ainsi de suite jusqu` atteindre louverture a maximale de la fentre. e Durant cette progression, si des paquets sont perdus, il y a congestion suppose sur lun des routeurs franchis et louverture de la fentre est rduite e e e pour retrouver un dbit qui minimise le taux de retransmission. e Louverture de la fentre est nomme fentre de congestion ou encore e e e congestion window .

4.3

Evitement de congestion

Le contrle du ux voqu prcdement, pour viter la congestion des o e e e e e routeurs, est implment ` laide dune variable (cwnd) nomme congestion e ea e window que lon traduit par fentre de congestion. e Concr`tement, le nombre maximum de segments de donnes (M SS en e e octets) que lmetteur peut envoyer avant den recevoir le premier acquite tement est le minimum entre cette variable (cwnd) et la taille de la fentre e annonce par le rcepteur ` chaque acquittement de paquet. e e a Le contenu de cette variable est pilot par les algorithmes de dpart lent e e slow start , voir 4.2 et dvitement de congestion ( congestion e avoidance ) examin ici. e La limite de croissance de la variable cwnd est la taille de la fentre ane nonce par le rcepteur. Une fois la capacit de dbit maximale atteinte, e e e e si un paquet est perdu lalgorithme dvitement de congestion en diminue e linairement la valeur (contrairement au slow start qui laugmente expoe nentiellement).

14

Ce cas arrive frquemment quand un routeur spare un rseau rapide dun rseau lent e e e e

5 Paquets capturs, comments e e

97

Paquets capturs, comments e e

Le premier exemple montre un change de paquets de synchronisae tion (SYN) et de n (FIN) entre la machine clnt.chezmoi et la machine srv.chezmoi. Ltablissement de la connexion se fait ` laide de la commande e a telnet sur le port discard (9) du serveur srv.chezmoi. La machine qui est ` lorigine de ltablissement de la connexion est dite cliente, et celle qui a e est suppose prte ` rpondre, serveur. Pour information, le service discard e e a e peut tre considr comme lquivalent du chier /dev/null sur le rseau : e ee e e les octets quon lui envoie sont oublis ( discard ). e Lutilisateur tape : $ telnet srv discard Trying... Connected to srv.chezmoi. Escape character is ^]. telnet> quit Connection closed. Et loutil danalyse rseau15 permet la capture pour lobservation des e changes suivants. Le numro qui gure en tte de chaque ligne a t ajout e e e ee e manuellement, le nom de domaine chezmoi a t retir, le tout pour ee e faciliter la lecture :
0 1 2 3 4 5 6 13:52:30.274009 clnt.1159 > srv.discard: S 55104001:55104001(0) win 8192 <mss 1460> 13:52:30.275114 srv.discard > clnt.1159: S 2072448001:2072448001(0) ack 55104002 win 4096 <mss 1024> 13:52:30.275903 clnt.1159 > srv.discard: . ack 1 win 8192 13:52:33.456899 clnt.1159 > srv.discard: F 1:1(0) ack 1 win 8192 13:52:33.457559 srv.discard > clnt.1159: . ack 2 win 4096 13:52:33.458887 srv.discard > clnt.1159: F 1:1(0) ack 2 win 4096 13:52:33.459598 clnt.1159 > srv.discard: . ack 2 win 8192 Simultanment e la capture des paquets est lance, e par exemple dans une autre fentre xterm. e

Plusieurs remarques simposent : 1. Pour amliorer la lisibilit les numros de squences vrais ne sont ine e e e diqus quau premier change. Les suivants sont relatifs. Ainsi le ack 1 e e de la ligne 2 doit tre lu 2072448002 (2072448001 + 1). e ` chaque change la valeur entre parenth`se indique le nombre doctets A e e changs. e e 2. Les tailles de fentre (win) et de segment maximum (mss) ne sont pas e identiques. Le telnet du client fonctionne sur HP-UX alors que le serveur telnetd fonctionne sur une machine BSD. 3. La symbole > qui marque le sens du transfert.
15

tcpdump que nous aurons loccasion dutiliser en TP

98 4. Le port source 1159 et le port destination discard.

Protocole TCP

5. Les ags F et S. Labsence de ag, repr par un point. ee Le deuxi`me exemple montre une situation de transfert de chier avec e 16 loutil ftp . Il faut remarquer que ltablissement de la connexion TCP est ici ` linie a tiative du serveur, ce qui peut laisser le lecteur perplexe. . .Lexplication est simple. En fait le protocole ftp fonctionne avec deux connexions TCP, la premi`re, non montre ici, est tablie du client vers le serveur, suppos ` e e e e a lcoute sur le port 21. Elle sert au client pour assurer le contrle du transfert. e o Lorsquun transfert de chier est demand via cette premi`re connexion, le e e serveur tablit une connexion temporaire vers le client. Cest cette connexion e que nous examinons ici. Elle est cloture d`s que le dernier octet demand e e e est transfrr. e e Extrait du chier /etc/services, concernant ftp :
ftp-data ftp-data ftp ftp 20/tcp 20/udp 21/tcp 21/udp #File #File #File #File Transfer Transfer Transfer Transfer [Default Data] [Default Data] [Control] [Control]

Dans cette exemple nous pouvons suivre le fonctionnement du mcanisme e des fentres glissantes. Les lignes ont t numrotes manuellement et la date e ee e e associe ` chaque paquet supprime. e a e
0 srv.20 > clnt.1158: S 1469312001:1469312001(0) win 4096 <mss 1024> [tos 0x8] 1 clnt.1158 > srv.20: S 53888001:53888001(0) ack 1469312002 win 8192 <mss 1460> 2 srv.20 > clnt.1158: . ack 1 win 4096 [tos 0x8] 3 srv.20 > clnt.1158: P 1:1025(1024) ack 1 win 4096 [tos 0x8] 4 clnt.1158 > srv.20: . ack 1025 win 8192 5 srv.20 > clnt.1158: . 1025:2049(1024) ack 1 win 4096 [tos 0x8] 6 srv.20 > clnt.1158: . 2049:3073(1024) ack 1 win 4096 [tos 0x8] 7 clnt.1158 > srv.20: . ack 3073 win 8192 8 srv.20 > clnt.1158: . 3073:4097(1024) ack 1 win 4096 [tos 0x8] 9 srv.20 > clnt.1158: P 4097:5121(1024) ack 1 win 4096 [tos 0x8] 10 srv.20 > clnt.1158: P 5121:6145(1024) ack 1 win 4096 [tos 0x8] 11 clnt.1158 > srv.20: . ack 5121 win 8192 12 srv.20 > clnt.1158: P 6145:7169(1024) ack 1 win 4096 [tos 0x8] 13 srv.20 > clnt.1158: P 7169:8193(1024) ack 1 win 4096 [tos 0x8] 14 clnt.1158 > srv.20: . ack 7169 win 8192 15 srv.20 > clnt.1158: P 8193:9217(1024) ack 1 win 4096 [tos 0x8] 16 srv.20 > clnt.1158: P 9217:10241(1024) ack 1 win 4096 [tos 0x8] 17 clnt.1158 > srv.20: . ack 9217 win 8192 18 srv.20 > clnt.1158: P 10241:11265(1024) ack 1 win 4096 [tos 0x8] 19 srv.20 > clnt.1158: P 11265:12289(1024) ack 1 win 4096 [tos 0x8] 20 clnt.1158 > srv.20: . ack 11265 win 8192 ... ... ...
16

du nom du protocole applicatif utilis : File Transfert Protocol e

Exemples de ux
21 22 23 24 25 26 27 28 29 30 31 32 srv.20 > clnt.1158: clnt.1158 > srv.20: srv.20 > clnt.1158: srv.20 > clnt.1158: srv.20 > clnt.1158: clnt.1158 > srv.20: clnt.1158 > srv.20: srv.20 > clnt.1158: srv.20 > clnt.1158: clnt.1158 > srv.20: clnt.1158 > srv.20: srv.20 > clnt.1158: P . P P P . . P F . F . 1178625:1179649(1024) ack 1 win 4096 [tos 0x8] ack 1178625 win 8192 1212417:1213441(1024) ack 1 win 4096 [tos 0x8] 1213441:1214465(1024) ack 1 win 4096 [tos 0x8] 1214465:1215489(1024) ack 1 win 4096 [tos 0x8] ack 1213441 win 8192 ack 1215489 win 8192 1215489:1215738(249) ack 1 win 4096 [tos 0x8] 1215738:1215738(0) ack 1 win 4096 [tos 0x8] ack 1215739 win 8192 1:1(0) ack 1215739 win 8192 ack 2 win 4096 [tos 0x8]

99

Remarques : 1. Le P symbolise le drapeau PSH. La couche TCP qui reoit un tel paquet c est informe quelle doit transmettre ` lapplication toutes les donnes e a e reues, y compris celles transmises dans ce paquet. c Le positionnement de ce drapeau est ` linitiative de la couche TCP a mettrice et non ` lapplication. e a 2. Le type de service ( Type Of service tos 0x8) est demand par e lapplication pour maximiser le dbit (consulter le cours IP page 45). e
Donnes transmettre, par segment de 1024 octets Numros des lignes 1024 3 5,6 8,9,10 12,13 15,16 18,19 4 7 11 14 17 20

gure VI.09

100

Protocole TCP

Bibliographie

RFC 793 Transmission Control Protocol. J. Postel. Sep-01-1981. (Format : TXT=177957 bytes) (Status : STANDARD) RFC 1025 TCP and IP bake o. J. Postel. Sep-01-1987. (Format : TXT=11648 bytes) (Status : UNKNOWN) RFC 1700 ASSIGNED NUMBERS. J. Reynolds,J. Postel. October 1994. (Format : TXT=458860 bytes) (Obsoletes RFC1340) (Also STD0002) (Status : STANDARD) Sans oublier : W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols Addison-Wesley Douglas Comer - Internetworking with TCP/IP - Principles, protocols, and architecture - PrenticeHall McKusick Bostic Karels Quaterman The Design and implementation of the 4.4 BSD Operating System (chapitre 13) AddisonWesley 1996

Deuxi`me partie e Protocoles applicatifs

Chapitre VII Serveur de noms - DNS

1 Gnralits sur le serveur de noms e e e

Sil est obligatoire dattribuer au moins une adresse IP ` une pile ARPA a pour pouvoir linterconnecter en rseau avec dautres piles de mme nature, e e en revanche, lui attribuer un nom symbolique nest absolument pas ncessaire e au bon fonctionnement de ses trois couches basses. Ce nommage symbolique est simplement beaucoup plus naturel pour les humains que la manipulation des adresses IP, mme sous forme dcimale e e pointe (adresses IP page 31). Il nintervient donc quau niveau applicatif, e ainsi la majeure partie des applications rseaux font usage de noms symboe liques avec, de mani`re sous-jacente, une rfrence implicite ` leur(s) correse ee a pondant(s) numrique(s). e Ce chapitre explore les grandes lignes du fonctionnement de ce que lon nomme le serveur de noms , lien entre cette symbolique et ladressage IP qui lui est associ . e Pour terminer cette introduction, il nest pas innocent de prciser que le e serveur de noms est en gnral le premier service mis en route sur un rseau, e e e tout simplement parceque beaucoup de services le requi`rent pour accepter e de fonctionner (le courrier lectronique en est un exemple majeur). Cest la e raison pour laquelle lusage dadresses IP sous la forme dcimale pointe reste e e de mise lors de la conguration des lments de commutation et de routage1 . ee

1.1

Bref historique

Au dbut de lhistoire de lInternet, la correspondance entre le nom (les e noms sil y a des synonymes ou alias ) et ladresse (il peut y en avoir plusieurs associes ` un seul nom) dune machine est place dans le chier e a e /etc/hosts, prsent sur toutes les machines unix dotes dune pile Arpa. e e Ci-apr`s le chier en question, prlev (et tronqu partiellement) sur une e e e e 2 machine FreeBSD ` jour. On y remarque quil ne contient plus que ladresse a
1 2

Eviter un blocage d ` linterrogation des serveurs de noms ua www.freebsd.org

104 de loopback en ipv6 et ipv4.

Serveur de noms - DNS

# $FreeBSD: src/etc/hosts,v 1.11.2.4 2003/02/06 20:36:58 dbaker Exp $ # # Host Database # # This file should contain the addresses and aliases for local hosts that # share this file. Replace my.domain below with the domainname of your # machine. # # In the presence of the domain name service or NIS, this file may # not be consulted at all; see /etc/host.conf for the resolution order. # # ::1 localhost localhost.my.domain 127.0.0.1 localhost localhost.my.domain

Au dbut des annes 1980 cest le NIC3 qui g`re la mise ` jour continuelle e e e a de cette table (HOSTS.TXT), avec les inconvnients suivants : e Absence de structure claire dans le nommage do` de nombreux conits u entre les noms des stations. Par exemple entre les dieux de la mythologie grecque, les plan`tes du syst`me solaire, les hros historiques ou de e e e bandes dessines. . . e Centralisation des mises ` jour, ce qui entraine : a 1. Une lourdeur du processus de mise ` jour : il faut passer par un a intermdiaire pour attribuer un nom ` ses machines. e a 2. Un trac rseau (ftp) en forte croissance (N 2 si N est le nombre e de machines dans cette table) et qui devient rapidement ingrable e au vu des bandes passantes de lpoque (quelques kilo bits par e seconde), et surtout jamais ` jour compte tenu des changements a continuels. Dapr`s Douglas E. Comer, au milieu des annes 1980 (1986) la liste e e ocielle des htes de lInternet contient 3100 noms et 6500 alias ! o La forte croissance du nombre des machines, a rendu obsol`te e cette approche.

1.2

Syst`me hirarchis de nommage e e e

Lespace de noms, pralablement non structur, est dsormais rorganis e e e e e de mani`re hirarchique, sous forme dun arbre (et non dun graphe). e e Cette organisation entraine une hirarchisation des noms de machines et e des autorits qui ont le pouvoir de les nommer, de les maintenir. e Chaque nud de larbre porte un nom, la racine nen a pas. Les machines, feuilles de larbre, sont nommes ` laide du chemin parcouru de la feuille e a (machine) ` la racine (non nomme). a e
3

Network Information Center (http ://www.internic.net/)

Syst`me hirarchis de nommage e e e Le sparateur entre chaque embranchement, ou nud, est le point e dcimal. Voici un exemple de nom de machine : e www.sio.ecp.fr Derri`re ce nom il faut imaginer un point (.) qui est omis la plupart du e temps car il est implicite4 . La lecture seectue naturellement de gauche ` a droite, par contre la hirarchie de noms sobserve de droite ` gauche. e a Domaine & zone Le rseau peut tre considr comme une hirarchie de domaines. Lespace e e ee e des noms y est organis en tenant compte des limites administratives ou e organisationnelles. Chaque nud, appel un domaine, est baptis par une e e cha de caract`res et le nom de ce domaine est la concatnation de toutes ne e e les tiquettes de nuds lues depuis la racine, donc de droite ` gauche. Par e a exemple : fr ecp.fr sio.ecp.fr Domaine fr Domaine ecp.fr sous domaine du fr Domaine sio.ecp.fr sous domaine de ecp.fr

105

Par construction, tout nud est un domaine, mme sil est terminal, cest e ` dire na pas de sous domaine. Un sous domaine est un domaine ` part enti`re a a e et, excepte la racine, tout domaine est un sous domaine dun autre. e Bien que le serveur de noms, Domain Name Server fasse rfrence ee explicitement au concept de domaine, pour bien comprendre la conguration dun tel service il faut galement comprendre la notion de zone . e Une zone est un point de dlgation dans larbre DNS, autrement dit une ee zone concerne un sous arbre du DNS dont ladministration lui est propre. Ce sous arbre peut comprendre plusieurs niveaux, cest ` dire plusieurs sous a domaines. Une zone peut tre confondue avec le domaine dans les cas les plus e simples. Dans les exemples ci-dessus, on peut parler de zone sio.ecp.fr puisque celle-ci est gre de mani`re autonome par rapport ` la zone ecp.fr. ee e a Le serveur de noms est concern par les zones . Ses chiers de cone guration5 prcisent la porte de la zone et non du domaine. e e Chaque zone doit avoir un serveur principal ( primary server ) qui dtient ses informations dun chier congur manuellement ou semi mae e nuellement (DNS dynamique). Plusieurs serveurs secondaires ( secondary server ) recoivent une copie de la zone via le rseau et pour assurer la contie nuit du service (par la redondance des serveurs). e Le fait dadministrer une zone est le rsultat dune dlguation de pouvoir e ee de ladministrateur de la zone parente et se concrtise par la responsabilit e e de congurer et dentretenir le champ SOA ( start of authority , page 118) de la-dite zone.
4 5

Sauf justement dans les chiers de conguration du serveur de noms, voir plus loin named.boot vs named.conf

106 Hirarchie des domaines e

Serveur de noms - DNS

Cette organisation du nommage pallie aux inconvnients de la premi`re e e mthode : e Le NIC g`re le plus haut niveau de la hirarchie, appel aussi celui des e e e top levels domains (TLD). Les instances rgionales du NIC g`rent les domaines qui leur sont e e dvolus. Par exemple le NIC France 6 g`re le contenu de la zone .fr. e e Le nommage sur deux lettres des pays est issu de la norme ISO 31667 . Chaque administrateur de domaine (universits, entreprises, associae tions, entits administratives,. . .) est en charge de son domaine et des e sous domaines quil cre. Sa responsabilit est nomminative vis ` vis e e a du NIC. On dit aussi quil a lautorit sur son domaine ( authoritative e 8 for the domain )

Racine non nomme Sens de lecture com

arpa

edu

gov

int

mil

net

org

ae Emirats Arabes Unis

fr

zw Zimbabwe

Domaines du niveau le plus lev (TLD)

inaddr

Domaines du second niveau

ecp

138

Contour de zone

cti

sio

195

Domaines gnriques

Domaines nationaux

10

52

52.10.195.138.inaddr.arpa.

gure VII.01
http ://www.nic.fr/ On peut les voir en dtail ` cette adresse http ://www.nw.com/zone/iso-country-codes e a 8 Une base de donnes sur les administrateurs de DNS est entretenue par les NICs, e cest la base whois , interrogeable par lutilitaire du mme nom. Consulter le site e http ://www.ripe.net/ pour plus dinformations, galement man whois sur une mae chine unix
7 6

2 Fonctionnement du DNS Les ventuels conits de nommage sont ` la charge des administrateurs e a de domaine. Du fait de la hirarchisation, des machines de mme nom e e peuvent se trouver dans des domaines dirents sans que cela pose le e moindre probl`me. e Le nom www est de loin le plus employ 9 , pourtant il ny a aucune e confusion possible entres ces machines, comme par exemple entres les machines www.ecp.fr et www.sio.ecp.fr. Chaque domaine entretient une base de donnes sur le nommage de e ses machines. Celle-ci est mise ` disposition de tous les utilisateurs du a rseau. e Chaque site raccord de mani`re permanente proc`de de cette mani`re, e e e e ainsi il ny a pas une base de donnes pour lInternet mais un ensemble e structur de bases de donnes relies entres elles et formant une gigane e e tesque base de donnes distribue. e e

107

2
2.1

Fonctionnement du DNS
Convention de nommage

La RFC 1034 prcise que les noms de machines sont dvelopps un peu e e e comme les noms de chiers dun syst`me hirarchis (Unix,. . .). e e e Le . est le sparateur e Chaque nud ne peut faire que 63 caract`res au maximum ; le bon e usage les limite ` 12 caract`res et commenant par une lettre. a e c Les majuscules et minuscules sont indirencies. e e Les chires [0-9] et le tiret peuvent tre utiliss, le soulign ( ) est un e e e abus dusage. Le point . et le blanc sont proscrits. Les cha nes de caract`res comme NIC ou dautres acronymes bien e connus sont ` viter absolument, mme encadres par dautres caa e e e ract`res. e Les noms complets ne doivent pas faire plus de 255 caract`res de long. e Il y a des noms relatifs et des noms absolus , comme des chemins dans un syst`me de chiers. Lusage du . en n de nom, qui indique un e nommage absolu10 , est rserv ` certains outils comme ping ou traceroute e ea et aux chiers de conguration du serveur de noms. En r`gle gnrale il nest e e e pas utile de lemployer.

901 961 instances en janvier 2003 contre 1 203 856 instances en janvier 2002, selon le site du Network Wizards Internet Domain Suvey (www.nw.com), Top 100 Host Names 10 FQDN, comme Fully Qualied Domain Name

108 Completion

Serveur de noms - DNS

Sur un mme rseau logique on a coutume de ne pas utiliser le nom e e complet des machines auxquelles on sadresse couramment et pourtant a c fonctionne ! La raison est que le resolver , partie du syst`me qui est en charge e de rsoudre les probl`mes de conversion entre un nom de machine et son e e adresse IP, utilise un mcanisme de compltion ( domain completion ) e e pour complter le nom de machine simpli, jusqu` trouver un nom plus e e a complet que le serveur de noms saura reconna dans sa base de donnes. tre e Le resolver connait par hypoth`se le nom de domaine courant (lu dans e le chier de conguration /etc/resolv.conf). Exemple dun tel chier : domain search nameserver nameserver nameserver sio.ecp.fr sio.ecp.fr., ecp.fr. 138.195.52.68 138.195.52.69 138.195.52.132

Plus gnralement ce nom de domaine se prsente sous forme d1 .d2 ...dn . e e e Ainsi, en prsence dun nom symbolique x, le resolver teste pour chaque i, e i {1, 2, . . . , n} lexistence de x.di .di+1 ...dn et sarrte si celle-ci est reconnue. e Dans le cas contraire la machine en question nest pas atteignable. Exemple, avec le domaine ci-dessus : a) machine = www (requte) e www.sio.ecp.fr = Succ`s ! e b) machine = www.sio (requte) e www.sio.sio.ecp.fr = Echec ! www.sio.ecp.fr = Succ`s ! e

2.2

Le Resolver

Le resolver dsigne un ensemble de fonctions11 places dans la bie e blioth`que standard (gethostbyname vu en cours de programmation invoque e les fonctions du resolver ) qui font linterface entre les applications et les serveurs de noms. Par construction les fonctions du resolver sont compiles avec lapplication qui les utilise (physiquement dans la libc, donc e accessibles par dfaut). e Le resolver applique la stratgie locale de recherche, dnie par ladmie e nistrateur de la machine, pour rsoudre les requtes de rsolution de noms. e e e Pour cela il sappuie sur son chier de conguration /etc/resolv.conf et sur la stratgie locale (voir paragraphe suivant) demploi des possibilits (serveur e e de noms, chier /etc/hosts, NIS,. . .).
res query, res search, res mkquery, res send, res init, dn comp, dn expand - Faire man resolver sur une machine unix
11

Stratgie de fonctionnement e

109

Application Code utilisateur /etc/resolv.conf Requete UDP "Resolver" Reponse UDP

Serveur(s) de noms distant(s)

gure VII.02 Le chier /etc/resolv.conf prcise au moins le domaine local assorti e de directives optionnelles.

2.3

Stratgie de fonctionnement e

La gure VII.03 illustre le fait que chaque serveur de noms a la ma trise de ses donnes mais doit interroger ses voisins d`s quune requte concerne e e e une zone sur laquelle il na pas lautorit de nommage. e Ainsi, un hte du domaine R2 qui veut rsoudre une adresse du o e domaine R1 doit ncessairement passer par un serveur intermdiaire e e pour obtenir linformation. Cette dmarche sappuie sur plusieurs stratgies e e possibles, que nous examinons dans les paragraphes suivants.
Subdivistion hirarchiques des domaines

Domaine R1 Domaines

Domaine R2

gure VII.03

110 Interrogation locale

Serveur de noms - DNS

La gure ci-dessous illustre la recherche dun nom dans le domaine local.

1 Processus

Serveur de noms local

gure VII.04 Un processus ( browser http par exemple) recherche ladresse dun nom de serveur. Sur les machines Unix cela se traduit par lappel ` la fonca tion gethostbyname. Cette fonction est systmatiquement prsente dans la e e biblioth`que standard (libc) et est donc accessible potentiellement ` tout e a excutable lors dune compilation. e La fonction gethostbyname fait systmatiquement appel au resolver e dj` cit. Cest donc toujours en passant par ce mcanisme que les processus ea e e acc`dent ` lespace de noms. Le resolver utilise une stratgie gnrale ` e a e e e a la machine (donc qui a t choisie par son administrateur) pour rsoudre de ee e telles requtes : e 1. Interrogation du serveur de noms (DNS) si prsent e 2. Utilisation des services type YP (NIS) si congurs e 3. Utilisation du chier /etc/hosts Cette stratgie est param`trable en fonction du constructeur. Le e e nsswitch sous HP-UX12 ou Solaris13 permet de passer de lun ` lautre en cas a dindisponibilit, le chier /etc/host.conf sous FreeBSD eectue un travail e assez proche. Enn, quelle que soit larchitecture logicielle le resolver est congur e ` laide du chier /etc/resolv.conf. a Sur la gure VII.04 : 1. Le processus demande ladresse IP dun serveur. Le resolver envoie la demande au serveur local. 2. Le serveur local reoit la demande, parcequil a lautorit sur le domaine c e demand (le sien), il rpond directement au resolver . e e Interrogation distante 1. Un processus demande ladresse IP dune machine. Le resolver envoie sa requte au serveur local. e
12 13

Unix de Hewlett-Packard Unix de Sun Microsystem

Stratgie de fonctionnement e 2. Le serveur local reoit la requte et dans ce deuxi`me cas il ne peut pas c e e rpondre directement car la machine nest pas dans sa zone dautorit. e e Pour lever lindtermination il interroge alors un serveur racine pour e avoir ladresse dun serveur qui a lautorit sur la zone demande par e e le processus. 3. Le serveur racine renvoie ladresse dun serveur qui a ociellement lautorit sur la zone e 4. Le serveur local interroge ce nouveau serveur distant. 5. Le serveur distant renvoie linformation demande au serveur local. e 6. Le serveur local retourne la rponse au resolver e

111

Serveur de noms racine

Processus

1 6

Serveur de noms local

4 5

Serveur de noms distant

gure VII.05 Remarques importantes : Un mcanisme de cache accl`re le processus ci-dessus : Si un processus e ee redemande la mme machine distante on se retrouve dans le cas dune e interrogation locale , du moins pendant la dure de validit des e e donnes (cf page 121). e Si un processus demande une machine du mme domaine que la e prcdente (mais pas du mme nom ! :), les tapes 2 et 3 deviennent e e e e inutiles et le serveur local interroge alors directement le serveur distant. La dure de vie de ladresse du serveur distant est elle aussi assortie e dune date limite dutilisation. Dans le cas gnral les serveurs racines ne voient pas plus de 1 ou deux e e niveaux en dessous. Ainsi, si un processus demande A.B.C.D.net : 1. Le serveur racine donne ladresse dun serveur pour D 2. Le serveur pour D donnera peut tre ladresse dun serveur pour e C et ainsi jouera le rle de serveur racine de ltape prcdente. o e e e Interrogation par procuration Le processus de recherche dcrit au paragraphe prcdent ne convient pas e e e dans tous les cas, notamment vis ` vis des deux crit`res suivants : a e

112 1. Scurit dun domaine e e 2. Conservation de la bande passante

Serveur de noms - DNS

1. La gure VII.05 montre le serveur local qui interroge directement les serveurs distants, cette dmarche pose des probl`mes de scurit dans le cas e e e e dun domaine au sein duquel seuls un ou deux serveurs sont autoriss. e Par exemple le serveur de noms du domaine sio.ecp.fr ninterroge pas directement le serveur racine, il passe par le serveur ociel qui est piston.ecp.fr (138.195.33.3). 2. Le trac destin au serveur de noms peut consommer une partie non e ngligeable de la bande passante, cest pourquoi il peut tre stratgique de e e e concentrer les demandes vers un seul serveur rgional et donc de bncier e e e au maximum de leet de cache dcrit prcdement. e e e

2.4

Hirarchie de serveurs e

Si tous les serveurs de noms traitent de donnes dun format identique, e leur position dans larborescence leur conf`re un statut qui se nomme : e serveur racine ( root name server ) Un serveur ayant autorit sur la e racine de lespace de nommage. Actuellement il y a 13 serveurs de ce type, nomms [A-M].ROOT-SERVERS.NET14 e serveur primaire ( primary server ) Un serveur de noms qui a lautorit e pour un ou plusieurs domaines (est dtenteur dautant de SOA Voir e page 118). Il lit ses donnes dans un chier stock sur disque dur, ` son e e a dmarrage. e Ladministrateur du (des) domaine(s) met ` jour les informations des a domaines concerns depuis cette machine. e serveur secondaire ( secondary server ) Dans le cas dune panne ou dun engorgement du serveur primaire, les serveurs secondaires reoivent en c prvision une copie de la base de donnes. e e Stratgiquement il est prfrable de les placer en dehors du domaine, e ee sur le rseau dun autre FAI. Il peut y avoir autant de serveurs secone daires que souhait, de lordre de trois ou quatre est souvent recontr. e e Au dmarrage ils reoivent les informations du serveur primaire, ou e c ils les lisent sur leur disque dur sils ont eu le temps de les y stocker au prcdent arrt du serveur, et si elles sont encore valides. e e e Par exemple, le serveur PISTON.ECP.FR a comme serveurs secondaires NS2.NIC.FR, SOLEIL.UVSQ.FR, NADIA.IRCAM.FR.

2.5
14

Conversion dadresses IP en noms

On dit aussi questions inverses ( inverse queries ).

chier named.root, par exemple dans le rpertoire /etc/namedb e

Conversion dadresses IP en noms Cette possibilit est indique comme optionnelle dans la RFC 1034 mais e e est nanmoins bien commode voire mme frquement requise pour le client e e e rseau de services comme le courrier lectronique ou mme les serveurs e e e de chiers anonymes (ftp). Si une machine est enregistre dans le TLD e in-addr.arpa, cela signie cette idresse ip est administre, ce qui ne prouve e rien quant aux bonnes intentions de son utilisateur mais est un gage de bonne conduite au niveau du rseau. e Il faut ajouter que le bon usage sur les rseaux est de prvoir une entre e e e dans la zone reverse pour toutes les machines utiles et utilises dun rseau e e accessible de lInternet. Le contraire provoque bien souvent la grogne (` juste a titre) des administrateurs. ` Il faut reconsidrer la gure VII.01. A gauche de la gure on distingue e un domaine un peu particulier in-addr.arpa . Toutes les adresses sont exprimes dans le top level domain : e in-addr.arpa Du fait de la lecture inverse de larbre, les adresses IP sont exprimes en e mirroir de la ralit. Par exemple pour la classe B de lecp : e e 195.138.in-addr.arpa (Classe B 138.195) Le fonctionnement par dlgation est calqu sur celui utilis pour les ee e e noms symboliques (cest la justication de son insertion dans la gure VII.01). Ainsi on peut obtenir quels sont les serveurs qui ont autorit e sur le 195.138.in-addr.arpa en questionnant dabord les serveurs du TLD in-addr.arpa puis ceux pour la zone 138.in-addr.arpa,. . . Chaque administrateur de zone peut aussi tre en charge de ladministrae tion des zones reverses , portion du domaine arpa , des classes dadresses dont il dispose pour nommer ses machines, sil en reoit la dlgation (celle-ci c ee est indpendante des autres noms de domaines). e Il faut noter que la notion de sous rseau (cf page 35) nest pas applicable e au domaine in-addr.arpa , ce qui signie que les adresses selon les contours naturels des octets. Ainsi, pour les clients de fournisseurs dacc`s nayant comme adresses IP e ocielles que celles dlimites par un masque de sous rseau large seulement e e e que de quelques units (< 254), la gestion de la zone reverse reste du domaine e du prestataire et non de son client.

113

114

Serveur de noms - DNS

2.6

Conclusion

Quest-ce quun DNS ? Un serveur de noms repose sur trois constituants : 1. Un espace de noms et une base de donnes qui associe de mani`re e e structure des noms ` des adresses IP. e a 2. Des serveurs de noms, qui sont comptents pour rpondre sur une ou e e plusieurs zones. 3. Des resolver capables dinterroger les serveurs avec une stratgie e dnie par ladministrateur du syst`me. e e TCP ou UDP ? Le port 53 bien connu pour le serveur de noms est prvu pour fonce tionner avec les deux protocoles. Normalement la majeure partie du trac se fait avec UDP, mais si la taille dune rponse dpasse les 512 octets, un drapeau de len-tte du e e e protocole lindique au client qui reformule sans question en utilisant TCP. Quand un serveur secondaire dmarre son activit, il eectue une cone e nexion TCP vers le serveur primaire pour obtenir sa copie de la base de donnes. En gnral, toutes les trois heures (cest une valeur courante) e e e il eectue cette dmarche. e

Scurisation du DNS e

Le serveur de noms est la clef de vote des rseaux, et cest en mme temps u e e un de ses talons dAchille parceque les programmes que nous employons quotidiennement utilisent sans discernement linformation acquise du rseau. En e eet, quest-ce qui vous assure que le site web de votre banque sur lequel vous venez de taper votre mot de passe est bien le vrai site ociel de cet tablissement ? Lapparence de la page de garde ? e Typiquement il y a deux situations de vulnrabilit : e e 1. Dialogue serveur ` serveur, notament lors de transferts de zones. a 2. Interrogation dun serveur par un resolveur Pour faire conance en ce que vous dit le serveur de noms interrog il faut e dune part que vous soyez certains dinterroger la bonne machine et dautre part que celle-ci soit dtentrice dune information incontestable. e Cest une cha de conance, comme toujours en scurit, qui rene e e monte par construction du fonctionnement du serveur de noms interrog e par votre application (comme nous lavons examin dans les paragraphes qui e prc`dent) jusquaux serveurs racines. e e La version ISC (consultez le paragraphe 6) du programme BIND utilise deux stratgies direntes, selon les cas ci-dessus. Dans le premier cas il sagit e e dun mcanisme nomm TSIG/TKEY, dans le deuxi`me DNSSEC. e e e

TSIG/TKEY pour scuriser les transferts e TSIG/TKEY utilisent une clef symtrique, donc partage par les deux e e serveurs (cette clef leur est connue par des mcanismes dirents). DNSSEC e e utilise un mcanisme bas sur le principe dun change de clefs publiques. e e e

115

3.1

TSIG/TKEY pour scuriser les transferts e

Lusage dune clef symtrique indique quil sagit dun secret partag entre e e 2 serveurs. La mme clef sert au chirement et au dchirement des donnes. e e e Le bon usage veut que lon ddie une clef ` un certain type de transaction (par e a exemple le transfert dune zone) entre deux serveurs donns. Cette mani`re e e de procder se traduit donc rapidement par un grand nombre de clefs ` grer e a e ce qui interdit un dploiement gnralis sur lInternet. e e e e Pour viter de trop longs temps de chirement, ce ne sont pas les donnes e e ` transfrer qui sont chires (ce ne sont pas des donnes condentielles), a e e e mais leur signature avec un algorithme de type MD515 Le serveur qui reoit un tel paquet sign, calcule la signature du paquet c e avec le mme algorithme (MD5), dchire la signature jointe avec la clef e e secr`te partage et compare les deux signatures. Le rsultat de cette compae e e raison dit si les donnes sont valides ou non. e Lintrt de ces transferts signs est que les serveurs secondaires sont ee e certains de mettre ` jour leur zones avec des donnes qui proviennent bien a e du dtenteur du SOA et qui sont absolument semblables ` ce qui a t mis. e a eee TSIG TSIG comme Transaction SIGnature est la mthode dcrite dans e e la RFC 2845 et base sur lusage dune clef symtrique. La gnration e e e e de cette clef peut tre manuelle ou automatise avec le programme e e dnssec-keygen . La propagation de cette clef est manuelle (scp. . .Eviter absolument lusage de tout protocole diusant un mot de passe en clair sur le rseau), e donc mise en place au coup par coup. TSIG sert galement ` la mise ` jour dynamique ( dynamic update ), e a a la connaissance de la clef par le client sert ` la fois ` lauthentier et ` signer a a a les donnes 16 . e TKEY TKEY, dcrit dans la RFC 2930, rend les mmes services que TSIG tout e e en vitant le transport du secret (TSIG). Cette caractristique est base e e e sur le calcul la clef symtrique automatiquement avec lalgorithme de Diee Hellman plutt que par un change manuel 17 . o e
Ne pas hsiter ` faire un man md5 sur une machine Unix pour en savoir plus ! e a cf le programme nsupdate et la RFC 2136 17 On peut trouver une explication de cet algorithme sur ce site http ://www.rsasecurity.com/rsalabs/faq/3-6-1.html
16 15

116

Serveur de noms - DNS Par contre, cet algorithme ` base du tandem clef publique clef prive a e suppose lajout dun champ KEY dans les chiers de conguration du serveur. Comme dailleurs le mcanisme suivant. . . e

3.2

DNSSEC pour scuriser les interrogations e

DNSSEC dcrit dans la RFC 2535 permet : e 1. La distribution dune clef publique (champ KEY) 2. La certication de lorigine des donnes e 3. Lauthentication des transactions (transferts, requtes) e Mis en place, le DNSSEC permet de construire une cha de conance, ne depuis le top level jusquau serveur interrog par votre station de travail. e

Mise ` jour dynamique a

La mise ` jour dynamique de serveur de noms (RFC 2136) est une fonca tionnalit assez rcente sur le rseau, elle permet comme son nom lindique e e e de mettre ` jour la base de donne rpartie. a e e Aussi bien au niveau du rseau local qu` lchelle de lInternet il sagit le e a e plus souvent de faire correspondre un nom de machine xe avec une adresse ip changeante. Cest typiquement le cas dun tout petit site qui a enregistr son e domaine chez un vendeur quelconque et qui au gr des changements dadresse e ip (attribue dynamiquement par exemple avec DHCP18 ) par son fournisseur e dacc`s, met ` jour le serveur de noms pour tre toujours accessible. e a e Avec comme mot clef dyndns , les moteurs de recherche indiquent lexistence de sites commerciaux ou ` caract`re associatif, qui proposent cette a e fonctionnalit. e

18

Cf http ://www.isc.org/products/DHCP/

5 Format des Resource Record

117

Format des Resource Record

Comme pour toute base de donnes, le serveur de nom a un format pour e ses champs, ou Resource Record , RR dans la suite de ce texte, dni ` e a lorigine dans la RFC 1035. En pratique toutes les distributions (commerciales ou libres) du serveur de noms conservent ce format de base de donnes, la mise en uvre du serveur e seule change (chier de conguration du daemon). Un serveur de noms a autorit (responsabilit du SOA) sur une ou plusieurs e e zones, celles-ci sont repres dans ses chiers de conguration (named.conf ee ou named.boot selon les versions). Sil est serveur primaire dune ou plusieurs zones, le contenu de ces zones est inscrit dans des chiers ASCII ; leur syntaxe est succintement dcrite dans le paragraphe suivant. e Sil est serveur secondaire, le chier de conguration indique au server de quelle(s) zone(s) il est secondaire (il peut tre secondaire dun grand nombre e de zones) et donc o` (adresse IP) il devra aller chercher cette information. u Cette action se traduit par ce que lon nomme un transfert de zone . Ce transfert est eectu automatiquement ` la frquence prvue par ladminise a e e trateur du champ SOA et donc connue d`s le premier transfert. En cas de e changement sur le serveur principal, celui-ci avertit ( Notify ) ses serveurs secondaires de la ncessit de recharger la zone pour tre ` jour. e e e a Le propos de ce qui suit nest pas de se substituer ` une documentaa tion nombreuse et bien faite sur le sujet, mais dapporter quelques lments ee fondamentaux pour en aider la lecture. Le constituant de base dun serveur de noms est une paire de chiers ASCII contenant les enregistrements, les Resource Record . Ceux-ci sont en gnral crits sur une seule ligne de texte (sauf pour e e e le champ SOA qui stale sur plusieurs lignes. Le marqueur de n de ligne e (CR+LF) est aussi celui de la n de lenregistrement. Le contenu gnral e e dun tel enregistrement a la forme suivante (les accolades indique des donnes e optionnelles) :
{name} {ttl} addr-class Record Type Record Specific data

Cinq enregistrements, ou Resource Record , ou en RR, sont absolument fondamentaux pour faire fonctionner un serveur de noms : SOA, NS, A, MX et PTR.

118

Serveur de noms - DNS

5.1

RR de type SOA

$(ORIGIN) sio.ecp.fr. name {ttl} addrclass @ IN

SOA SOA

Origin Person in charge sio.ecp.fr. hostmaster.sio.ecp.fr. ( 2003110301 ; Serial 10800 ; Refresh (3h) 3600 ; Retry (1H) 3600000 ; Expire (5w6d16h) 86400 ) ; Minimum ttl (1D)

SOA est lacronyme de Start Of Authority et dsigne le dbut e e oblig et unique dune zone. Il doit gurer dans chaque chier db.domain et e db.adresse Le nom de cette zone est ici repr par le caract`re @ qui signie ee e la zone courante, repre par la ligne au dessus $(ORIGIN) sio.ecp.fr. . ee La ligne aurait galement pu scrire : e e
sio.ecp.fr. IN SOA sio.ecp.fr. hostmaster.sio.ecp.fr. ( ...

Un probl`me concernant cette zone devra tre signal par e-mail ` e e e a hostmaster@sio.ecp.fr (notez le . qui sest transform en @). e Les param`tres de ce SOA sont dcrits sur plusieurs lignes, regroupes e e e entres parenth`ses. Le caract`re ; marque le dbut dun commentaire, qui e e e sarrte ` la n de ligne. e a Les points en n de noms sont ncessaires. e Le numro de srie doit changer ` chaque mise ` jour de la zone (sur le e e a a serveur principal). Le Refresh indique la frquence, en secondes, ` laquelle e a les serveurs secondaires doivent consulter le primaire pour ventuellement e lancer un transfert de zone (si le numro de srie est plus grand). Le Retry e e indique combien de secondes un serveur secondaire doit attendre un transfert avant de le dclarer impossible. Le Expire indique le nombre de secondes e maximum pendant lesquelles un serveur secondaire peut se servir des donnes e du primaire en cas dchec du transfert. Minimum ttl est le nombre de e secondes par dfaut pour le champ TTL si celui-ci est omis dans les RR. e

5.2

RR de type NS

Il faut ajouter une ligne de ce type ( Name Server ) pour chaque serveur de noms pour le domaine. Notez bien que rien dans la syntaxe ne permet de distinguer le serveur principal de ses secondaires. Dans le chier db.domaine :

{name}

{ttl}

addrclass IN IN IN

NS NS NS NS

Name servers name nsmaster.sio.ecp.fr. nsslave1.sio.ecp.fr. nsslave2.sio.ecp.fr.

RR de type A Dans le chier qui renseigne la zone reverse , par exemple db.adresse, on trouvera :

119

52.195.138.inaddr.arpa. IN 52.195.138.inaddr.arpa. IN 52.195.138.inaddr.arpa. IN

NS NS NS

nsmaster.sio.ecp.fr. nsslave1.sio.ecp.fr. nsslave2.sio.ecp.fr.

5.3

RR de type A

Le RR de type A, ou encore Address record attribue une ou plusieurs adresses ` un nom, cest donc celui qui est potentiellement le plus frquement a e utilis. Il doit y avoir un RR de type A pour chaque adresse dune machine. e

{name} gwsio

{ttl}

addrclass IN IN IN

A A A A

address 138.195.52.2 138.195.52.33 138.195.52.65

5.4

RR de type PTR

Le RR de type PTR, ou encore PoinTeR record permet de spcier les adresses pour la rsolution inverse, donc dans le domaine spcial e e e IN-ADDR.ARPA. Notez le . en n de nom qui interdit la compltion (il sagit e bien du nom FQDN).

name 2 33 65

{ttl}

addrclass IN IN IN

PTR PTR PTR PTR

real name gwsio.sio.ecp.fr. gwsio.sio.ecp.fr. gwsio.sio.ecp.fr.

5.5

RR de type MX

Le RR de type MX, ou encore Mail eXchanger concerne les relations entre le serveur de noms et le courrier lectronique. Nous examinerons son e fonctionnement ultrieurement dans le chapitre sur le courrier lectronique e e (cf page 137).

sio.ecp.fr. sio.ecp.fr.

IN IN

MX MX

10 20

smtp.ecp.fr. mailhost.laissus.fr.

120

Serveur de noms - DNS

5.6

RR de type CNAME

Le RR de type CNAME, ou encore canonical name permet de distinguer le nom ociel dune machine de ses surnoms.

www.sio.ecp.fr.

IN

CNAME

srv.laissus.fr.

Dans lexemple ci-dessus, la machine www.sio.ecp.fr est un surnom de la machine srv.laissus.fr. On notera que les domaines nont rien ` voir a mais que a fonctionne quand mme parfaitement. c e Cette possibilit est tr`s employe pour constituer des machines virtuelles, e e e comme nous le verrons au chapitre X.

5.7

Autres RR. . .

Il existe dautres RR, entres autres HINFO , TXT, WKS et KEY, non traits e dans cette prsentation parcequils napportent rien ` la comprhension du e a e fonctionnement du serveur de noms. Le lecteur est fortement incit ` se e a reporter au Name Server Operations Guide pour plus dinformations.

6 BIND de lISC

121

BIND de lISC

LInternet Software Consortium19 est une organisation non commerciale qui dveloppe et favorise lemploi de loutil Open Source comme BIND e (acronyme de Berkeley Internet Name Domain ). Cette version libre du serveur de nom est la plus employe sur les machines e Unix du rseau, ce qui justie que lon sy intresse. Elle fournit une version e e du daemon named et un resolver intgr dans la libc. On peut e e aisment installer ce logiciel sur ` peu pr`s toutes les implmentations dunix e a e e connues (cf le chier INSTALL du rpertoire src). e
named nsupdate Rseau tcp/ip Transferts de zones, queries Mise jour dynamique de RRs
Signaux

Syslog

named rndc

named.conf named.root

localhost.rev db.192.168.192 db.terminal

/var/run/named.pid /var/run/ndc /var/tmp/* Contour logique du serveur de noms

gure VII.06

6.1

Architecture du daemon named

La gure VII.06 montre le schma gnral de lorganisation logicielle du e e e daemon named . Au dmarrage celui-ci lit sa conguration dans un chier qui peut se e nommer named.boot ou named.conf selon que lon est en version 4.9.11, 8.3.6 ou 9.2.3 et les suivantes du logiciel20 . named.conf Cest le chier de conguration lu au dmarrage. Sa structure e dpend de la version du logicielle, heureusement dans les deux cas la e smantique reste proche ! e
19 20

http ://www.isc.org/ taper named -v pour les discerner entre-elles

122

Serveur de noms - DNS named.root Ce chier contient la liste des serveurs de la racine, leur nom et adresse IP. localhost.rev Ce chier contient la base de donne du localhost . Pere sonne na la responsabilit du rseau 127, donc chacun doit le grer e e e pour lui-mme. Labsence de ce chier nempche pas le serveur de e e fonctionner, mais ne lui permet pas de rsoudre 127.0.0.xx (o` xx est e u le numro de la machine courante, souvent 1). e db.terminal Exemple de chier de base de donnes pour le domaine face tice terminal.fr qui est utile durant les travaux pratiques. Ce chier permet la convertion des noms en adresses IP. db.192.168.192 Ce chier contient la base de donnes de la zone reverse e pour le domaine terminal.fr, cest ` dire le chier qui permet au a logiciel de convertir les adresses IP en noms. rndc ou name server control utility est comme son nom lindique un outil dadministration du programme named lui-mme. Cest une e alternative ` lusage direct des signaux. Le canal de communication a entre les deux programmes est une socket unix AF UNIX vs AF LOCAL (cf cours de programmation page 199). Un certain nombre de signaux modient le comportement du serveur, ils seront examins en travaux pratiques, tout comme les chiers lus ou crits e e dans les rpertoires /var/run et /var/tmp/. e Enn la `che vers syslog signie que named utilise ce service pour laisser e une trace de son activit (cf cours sur larchitecture des serveurs). e Enn, le BOG, cest ` dire le Bind Operations Guide , dtaille le a e contenu des champs de la base de donnes. e

Bibliographie

Quand on sait dj` , la page de man de named sut ` vrier un ea a e point obscur ! Sinon il existe une documentation tr`s fournie sur le sujet, avec e notamment : Kein J. Dunlap & Michael J. Karels Name Server Operations Guide Ce document est accessible sur le serveur de lInternet Software Consortium 21 By the Nominum BIND Development Team BIND 9 Administrator Reference Manual Version 9.1.3 22 Douglas E. Comer Internetworking with TCP/IP Volume I (chapter 18) Prentice All 1988 Paul Albitz & Cricket Liu DNS and BIND OReilly & Associates, Inc. 1992
On trouve le BOG dans la distribution de bind ` cette adresse : a http ://www.isc.org/products/BIND/ 22 on trouve galement la derni`re version de ce document sur le site de lISC e e
21

Bibliographie Installing and Administering ARPA Services Hewlett Packard 1991 W. Richard Stevens TCP/IP Illustrated Volume I (chapter 14) Prentice All 1994 Et pour en savoir encore plus. . . RFC 1034 Domain names - concepts and facilities . P.V. Mockapetris. Nov-01-1987. (Format : TXT=129180 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Obsoleted by RFC1065, RFC2065) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181) (Status : STANDARD) RFC 1035 Domain names - implementation and specication . P.V. Mockapetris. Nov-01-1987. (Format : TXT=125626 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Obsoleted by RFC2065) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2181, RFC2136, RFC2137) (Status : STANDARD) RFC 1101 DNS encoding of network names and other types . P.V. Mockapetris. Apr-01-1989. (Format : TXT=28677 bytes) (Updates RFC1034, RFC1035) (Status : UNKNOWN) RFC 1123 Requirements for Internet hosts - application and support . R.T. Braden. Oct-01-1989. (Format : TXT=245503 bytes) (Updates RFC0822) (Updated by RFC2181) (Status : STANDARD) RFC 1713 Tools for DNS debugging . A. Romao. November 1994. (Format : TXT=33500 bytes) (Also FYI0027) (Status : INFORMATIONAL) RFC 2136 Dynamic Updates in the Domain Name System (DNS UPDATE) . P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. (Format : TXT=56354 bytes) (Updates RFC1035) (Updated by RFC3007) (Status : PROPOSED STANDARD) RFC 2535 Domain Name System Security Extensions . D. Eastlake 3rd. March 1999. (Format : TXT=110958 bytes) (Obsoletes RFC2065) (Updates RFC2181, RFC1035, RFC1034) (Updated by RFC2931, RFC3007, RFC3008, RFC3090, RFC3226, RFC3445) (Status : PROPOSED STANDARD) RFC 2845 Secret Key Transaction Authentication for DNS (TSIG) P. Vixie, O. Gudmundsson, B. Wellington. May 2000. (Format : TXT=32272 bytes) (Updates RFC1035) (Status : PROPOSED STANDARD) RFC 2930 Secret Key Establishment for DNS (TKEY RR) D. Eastlake 3rd. September 2000. (Format : TXT=34894 bytes) (Status : PROPOSED STANDARD)

123

124

Serveur de noms - DNS

Chapitre VIII Courrier lectronique e

1 Gnralits sur le courrier lectronique e e e e

Le courrier lectronique, ou mail est lun des deux services les plus e populaires sur le rseau, avec le web. e Cest aussi lun des plus vieux services du rseau, bien avant que le e rseau existe sous la forme que lon pratique aujourdhui1 . La prface de e e la [RFC 822], document fondamental parmi les documents fondamentaux pour ce chapitre, laisse supposer lexistence de nombreux formats dchanges e lectroniques sur lArpanet, et ce avant 1977. e Sa popularit repose sur sa grande souplesse et rapidit demploi. Il pere e met aussi bien les changes professionnels que les changes privs ; son mode e e e dadressage donne la possibilit denvoyer un courrier ` une personne comme e a ` une liste de personnes ou encore ` un automate capable de rediuser vers a a un groupe (mailing-list). De nombreux outils dvelopps, ` lorigine essentiellement sur le syst`me e e a e Unix, autour de ce concept ouvrent un vaste champs de possibilits aux utilie sateurs de tous les syst`mes dexploitation, comme la ventilation des courriers e par th`me, le renvoi automatique, le rpondeur (pendant les absences), lacc`s e e e ` sa boite aux lettres depuis des endroits dirents, la rception de fax,. . .La a e e liste ne peut pas tre exhaustive ! e Cest souvent pour avoir lusage du courrier lectronique que les entree prises acc`dent ` lInternet. Les autres services viennent apr`s. e a e

1.1

Mtaphore du courrier postal e

Un courrier postal (ou de surface, s-mail) a besoin de ladresse du destinataire, de ladresse de lmetteur (pour la rponse), dun timbre et dune e e enveloppe. Une fois dans la bo aux lettres, lenveloppe est route de la poste locale te e vers la poste la plus proche du destinataire, pour tre nalement dlivre par e e e un facteur.
1

Un historique intressant http ://www.fnet.fr/history/ e

126

Courrier lectronique e Pour un courrier lectronique cest la mme chose ! e e Il existe de tr`s nombreux outils pour lire/crire un mail, des outils pour e e jouer le rle du bureau de poste et/ou du facteur. Sous Unix le facteur est le o syst`me lui-mme, le bureau de poste un programme nomm sendmail2 . e e e Il existe deux autres alternatives non abordes dans ce document, ` savoir le e a 3 4 programme qmail ou encore le programme postx .

1.2

Adresse lectronique e

Tous les courriers lectroniques ont un destinataire prcis par son adresse e e e 5 lectronique, ou E-mail . Celle-ci prcise le nom du destinataire et le site e e o` il reoit son courrier lectronique. u c e Le nom du destinaire est une cha de caract`res. Traditionnellement ne e et pour des raisons techniques, sur le syst`me Unix, le login de lutilisateur e peut tre galement le nom de sa boite aux lettres. Cette possibilit est de e e e moins en moins vraie ` mesure que dautres syst`mes avec dautres logiques a e de fonctionnement font leur apparition sur le rseau (notamment la lecture e du mail via un interface html ou encore lorsque le mail est gr par une base ee de donnes). e Par exemple, il est assez frquent de voir employer le nom complet e (prnom et nom de famille) pour dsigner linterlocuteur distant. La convere e sion ultime entre cette convention et la bo aux lettres de lutilisateur est te laaire du bureau de poste le plus proche, cest ` dire le programme senda mail pour ce document (voir plus loin au paragraphe 4). Le caract`re @ (lire at ) spare lidenticateur du destinataire de e e la destination. La destination est peut tre vide (il sagit alors dun destinataire sur la e machine courante, ou dun alias que le sendmail local sait traiter), tre e un nom de machine du domaine local, le nom dun autre domaine ou dune machine sur un autre domaine. Les adresses suivantes ont un format valide : user1 Destinataire local. user2@nom de machine Destinataire sur une machine du domaine courant (rappellez-vous, il existe un mcanisme de compltion dans le ree e solver page 108 !). user3@nom de machine.domaine Destinataire sur une machine particuli`re dun domaine particulier (non forcment local). e e user4@domaine Destinataire sur un domaine particulier (mme remarque e que ci-dessus).
2 3

Version 8.12.9 en avril 2003 http ://www.sendmail.org/ http ://www.qmail.org/ 4 http ://postfix.eu.org/start.html 5 Terme francis en m`l , ou couriel pour les documents administratifs. . . ;-) e e

2 Format dun E-mail - RFC 822 On devine aisment que le fonctionnement du courrier lectronique sur e e une machine distante est fortement lie au bon fonctionnement du serveur e de noms (chapitre VII). Qui plus est, lorsque seul un nom de domaine est prcis ` droite du e e a caract`re @ , une information manque apparemment quant ` la machine e a susceptible de recevoir le mail. Le lecteur en qute de plus de prcisions trouvera une description exhause e tive de la syntaxe dune adresse au paragraphe 6 de la [RFC 822].

127

Format dun E-mail - RFC 822

Les octets qui composent un courrier lectronique obissent ` une struce e a ture bien dnie par la [RFC 822] de David H. Crocker : un en-tte et un e e 6 corps de message, spars par une ligne blanche (deux CRLF qui se suivent). e e Le contenu de len-tte dans son intgralit nest pas toujours spone e e tanment montr par les outils qui nous permettent de lire et denvoyer du e e courrier lectronique. Une option est toujours accessible pour ce faire, comme e h sous mutt 7 . Une partie de len-tte est gnre automatiquement par le programme e e ee qui se charge du transfert (le paragraphe suivant nous dira quil sagit dun MTA), une autre est ajoute par le programme qui permet de composer le e mail, le MUA, une autre enn est tape par lutilisateur lui-mme. e e

Entte Donnes (DATA) du protocole SMTP

Entte ajoute automatiquement Entte ajoute par lutilisateur Ligne blanche ajoute automatiquement

Corps

Le message (peut tre vide)

gure VIII.01
6 7

Il sagit respectivement des caract`res 13 et 10 de la table ASCII - cf man ascii e http ://www.mutt.org/ le MUA, voir paragraphe suivant, prfr de lauteur eee

128

Courrier lectronique e Len-tte est constitu de lignes construites sur le mod`le : e e e identicateur : [ valeur ] CRLF Lidenticateur ne peut pas contenir le caract`re : parcequil sert de e sparateur avec la partie droite. Il est constitu de caract`res ASCII cods e e e e sur 7 bits et imprimables (cest ` dire [33, 126]), except lespace. Valeur a e est optionnelle. Lusage des majuscules ou des minuscules est indirenci. e e Lordre dapparition de ces champs est quelconque. Seule lorganisation de la gure VIII.01 doit tre globalement respecte. Le lecteur soucieux dune e e description exhaustive de ce en quoi peut tre constitu un en-tte pourra se e e e repporter au paragraphe 4.1 de la RFC (SYNTAX). Len-tte dun mail donne des informations de nature varie sur le mese e sage lui-mme. On peut les apparenter, pour certaines dentres elles, aux e informations quon trouve sur les enveloppes des courriers postaux. Type dinformation Noms des champs

Cheminement du courrier Received, Return-Path Origine du courrier From, Sender, Reply-To Destinataire(s) du courrier To, Cc, Bcc Identication du courrier Message-Id, In-Reply-To Renvoi ResentAutres Subject, Date Champs tendus e X- ? Nous aurons loccasion dexaminer des en-ttes, notamment lors des trae vaux pratiques qui suivront ce cours.

3 Protocole SMTP - RFC 821

129

Protocole SMTP - RFC 821

Le protocole SMTP, ou Simple Mail Transfert Protocol a comme objet le transport du courrier lectronique de mani`re able et ecace. Il est dni e e e dans la [RFC 821] de Jonathan B. Postel. Indpendant par sa conception dun quelconque sous-syst`me de transe e port, il est principalement aujourdhui encapsul dans des paquets TCP ` e a destination du port 25 (cf le chier /etc/services). Dans un pass pas si loine tain lacc`s rseau de beaucoup de sites se rsumait au courrier lectronique e e e e encapsul dans des trames du protocole UUCP, donc sur liaison srie via moe e dem !

3.1

Protocole SMTP

SMTP est un protocole ASCII (7 bits, human readable). La partie cliente de la transaction se connecte sur le port 25 du serveur et envoie des commandes auxquelles le serveur rpond par des codes numriques qui e e indiquent le statut de la prise en compte de la commande. Cest pourquoi il est ais de se connecter sur un MTA avec un simple e 8 telnet :
$ telnet localhost 25 Connected to localhost. Escape character is ^]. 220 host.mondomain.fr ESMTP Sendmail 8.12.6; Mon, 20 Jan 2003 15:34:45 +0100 (CET) NOOP 250 2.0.0 OK QUIT 221 2.0.0 host.mondomain.fr closing connection Connection closed by foreign host.

Dans cet exemple le MTA est le programme Sendmail 9 , qui rpond ` la e a connexion par un code 220 pour dire que le service est oprationnel (service e ready), suivi du nom de la machine, de la banni`re du programme, de la e version de sa conguration, et de sa date courante. Puis lutilisateur a tap la commande NOOP qui na dautre eet que de e forcer le serveur ` rpondre et renvoyer un code (250) pour dire que tout va a e bien. Enn Lutilisateur a tap QUIT pour nir proprement la transaction. La e rponse du serveur est un code 221 pour signier la n canonique de la e connexion.
Attention toutefois de ne pas abuser de cette pratique car de nombreuses attaques de sites ont dmarr par le pass ` laide un dtournement de sendmail. Les administrateurs e e ea e rseaux sont donc attentifs au trac sur le port 25 ; il est prfrable de rserver ce genre e ee e de tests uniquement sur son propre site. 9 http ://www.sendmail.org/
8

130

Courrier lectronique e Dans un deuxi`me essai nous utilisons loption -v du programme mail, e pour visualiser les changes entre le MUA (machine athome.mondomain.fr) e et le MTA local (machine mailhub.mondomain.fr). Essayons :
$ sendmail -v user@mondomain.fr Subject: test Ca passe ? . <<<--- A taper pour marquer la fin du mail dans ce mode. EOT user@mondomain.fr... Connecting to mailhub.mondomain.fr. via relay... 220 mailhub.mondomain.fr HP Sendmail (1.37.109.4/user-2.1) ready at Mon, 26 Jan 98 14:08:57 +0100 >>> HELO athome.mondomain.fr 250 mailhub.mondomain.fr Hello athome.mondomain.fr, pleased to meet you >>> MAIL From:<user@mondomain.fr> 250 <user@mondomain.fr>... Sender ok >>> RCPT To:<user@mondomain.fr> 250 <user@mondomain.fr>... Recipient ok >>> DATA 354 Enter mail, end with "." on a line by itself >>> . 250 Ok user@mondomain.fr... Sent (Ok) Closing connection to mailhub.mondomain.fr. >>> QUIT 221 mailhub.mondomain.fr closing connection

Et le courrier reu, lu aussi avec mail : c

Message 208/208 User Lambda Jan 26, 98 02:09:06 pm +0100

From user@mondomain.fr Mon Jan 26 14:09:08 1998 Received: from mailhub.mondomain.fr by athome.mondomain.fr with SMTP (8.8.7/8.8.7/f la.2.1) id OAA27655; Mon, 26 Jan 1998 14:09:08 +0100 (CET) Received: from athome.mondomain.fr by mailhub.mondomain.fr with SMTP (1.37.109.4/fl a-2.1) id AA06996; Mon, 26 Jan 98 14:08:57 +0100 From: User Lambda <user@mondomain.fr> Received: by athome.mondomain.fr Date: Mon, 26 Jan 1998 14:09:06 +0100 (CET) Message-Id: <199801261309.OAA27653@athome.mondomain.fr> To: user@mondomain.fr Subject: test Ca passe ?

Manifestement, a passe ! :) c Il est galement intressant dobserver ` ce niveau que les caract`res du e e a e courrier ont t considrablement enrichis par un en-tte volumineux (relaee e e tivement). En eet, chaque nud travers (MTA), ajoute un champ Received e permettant apr`s coup de suivre le trajet du courrier. Les autres champs e

Protocole SMTP comme Date :, Subject : ou Message-Id : sont ajouts dans len-tte par e e le MUA de lcrivain du message. e Cette partie de len-tte ajoute par le MUA dorigine est souvent dese e tine ` piloter le comportement du MUA du destinataire du message plus e a que pour tre lue. Cette attitude sest gnralise au point de devenir assez e e e e complique et tre formalise dans un ensemble de r`gles baptises MIME e e e e e comme Multipurpose Internet Mail Extensions ([RFC 2184]). La fonction la plus rpandue et la plus simple de MIME est dautoriser e lusage des caract`res accentus (codage sur 8 bits ou plus) ` lintrieur du e e a e corps du message (len-tte SMTP reste code sur 7 bits). Lutilisateur voit e e alors appara des lignes supplmentaires comme celles-ci : tre e
X-Mime-Autoconverted: from 8bit to quoted-printable by bidule.domain id SAA23150 X-MIME-Autoconverted: from quoted-printable to 8bit by mamachine.ici id QAA29283

131

Le quoted-printable est une forme possible du codage des caract`res e accentus, dnie dans la [RFC 822]. Le plus souvent on trouve des lignes e e comme celles-ci :
Mime-version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfert-Encoding: quoted-printable Content-ID: Content-ID: <Pine.FBSD.3.14.1592654.19971998X.domain> Content-Description: pouet.c

Dautres formes de MIME peuvent conduire ` lexcution dun proa e gramme extrieur au MUA, ce qui constitue une dangereuse faille potentielle e dans la scurit des rseaux, donc ` viter. e e e ae

3.2

Principales commandes de SMTP

Exprimentalement nous avons dcouvert quelques uns des mots rservs e e e e du protocole : HELO, MAIL, RCPT, DATA, QUIT. Une implmentation minie male de SMTP en comprend deux autres en plus : RSET et NOOP. Cest donc un protocole assez simple, du moins dans sa version de base. Les codes de retour sont organiss sur trois chires, le premier chire e donne le sens gnral de la rponse, tr`s succintement ce qui dbute par 1,2 e e e e e ou 3 a une signication positive, 4 ou 5 signie une erreur. Une information plus dtaille se trouve ` lannexe E de la RFC. e e a Les cinq commandes dcouvertes prcdement sutilisent toujours dans e e e cet ordre. Examinons succintement leur usage : Commande HELO Synopsis : HELO <espace> <domaine> <CRLF> Cette commande est utilise pour identier lmetteur du mail. Largue e ment qui suit, domain est le nom de la machine ou du domaine do` provient u la connexion.

132

Courrier lectronique e En rponse le serveur envoie une banni`re dans laquelle il sidentie et e e donne la date courante. Cette information est optionnelle, ce qui compte cest le code de retour pour conrmer laptitude au travail du serveur ! Commande MAIL Synopsis : MAIL <espace> FROM : <chemin inverse> <CRLF> Cette commande dbute un transfert de mail. En argument sont transmis e (chemin inverse) ladresse e-mail de lmetteur et la liste des machines qui e ont relay le mail courant. La premi`re machine est la plus rcente. Cette ine e e formation est utilise pour renvoyer, sil y a lieu, une notication de probl`me e e ` lmetteur du mail. a e Par exemple : MAIL FROM :<@mailhub.ici :@mailhost.labas :Lambda@mondomain.fr> Commande RCPT Synopsis : RCPT <espace> TO : <destinataire> <CRLF> Cette commande est la deuxi`me tape dans la procdure denvoi dun e e e mail. Il y a une commande de ce type par destinataire du courrier ( recipient ). Par exemple : RCPT TO :<Lambda@mondomain.fr> Il est intressant de noter que les arguments de cette commande et ceux e de la prcdente (MAIL) forment lenveloppe du mail (expditeur et dese e e tinataire). Commande DATA Synopsis : DATA <CRLF> Apr`s rception de la commande, le serveur lit les lignes de texte en proe e venance du client jusqu` rencontrer la squence <CRLF>.<CRLF> qui a e marque la n du message. Il faut remarquer que celui-ci comprend lintgralit e e de la gure VIII.01. Commande QUIT Synopsis : QUIT <CRLF> Marque la n de la session et entraine la clture de la connexion. o

Protocole SMTP

133

3.3

Propagation du courrier lectronique e

SMTP est dni comme un protocole de transfert, donc un moyen pour e router et dlivrer le message ` son (ses) destinataire nal (naux). e a
MUA
utilisateur

MTA

MTA

MSA

OS

OS

SMTP/ESMTP MUA
utilisateur

gure VIII.02 MTA Mail Transfert Agent , cest le programme que prend en charge le transfert du courrier. Sous Unix cest un daemon. Par exemple : MMDF, Smail, Zmailer, sendmail, postfix, qmail... Les MTAs coutent le rseau sur le port 25 et dialoguent entre-eux avec e e le protocole SMTP (ESMTP10 ). MSA Mail Submission Agent , cest une nouveaut dnie par la e e [RFC 2476] et qui joue le rle dinterface entre le MUA et le MTA. o Lobjet du MSA est de sparer les fonctions de transfert du courrier e et dacceptation de nouveaux courriers mis depuis les MUA. Cette e sparation des tches amliore deux aspects : e a e La scurit Les nouveaux mails sont soumis ` un daemon qui ne e e a nexcutent pas avec les droits du root11 . e La conformit aux standards Les messages proviennent de MUAs e qui ne respectent pas forcment tous les prrequis de formulation e e des en-ttes. e Le rle du MSA est de vrier et de compl`ter ces en-ttes avant o e e e de soumettre les mails au MTA pour le routage. MUA Mail User Agent ou encore mailer, cest le programme qui permet de lire et crire le corps du courrier et de paramtrer quelques e e lments de len-tte, principalement ladresse du destinaire, et le sujet ee e du message.
10 11

Extented SMTP SUID bit

134

Courrier lectronique e Il existe un tr`s grand nombre de MUAs sous Unix, il est coue rant de rencontrer mail, mailx, elm, pine, mutt, mh, eudora, kmail, sylpheed... Il y en a pour tous les gots ! u OS Operating System, le syst`me dexploitation sur lequel fonctionnent e ces programmes. La gure 2 illustre la possibilit la plus simple dchange entre deux MTA : e e la connexion directe. Cela signie que le MTA de la station mettrice contacte e le MTA de la station rceptrice et lui dlivre directement le message. e e La vie relle est plus complique car elle tient compte de lorganisation e e hirarchique des rseaux et surtout de la scurit qui est un aspect devenu e e e e important sur lInternet. Cela se traduit par un emploi gnralis de machines e e e relais ou mailhub .

B@domaine2

MTA MTA
relay mail

Utilisateur A au travail.

MUA

SMTP/ TCP/IP

Station de lutilisateur A Stockage temporaire tant que le MTA du domaine 2 est inacessible.

Wild Internet !

SMTP/ TCP/IP Utilisateur B au travail.

MUA MTA MTA

relay mail

Stockage long terme sur le disque dur de la station.

Station de lutilisateur B Stockage temporaire tant que la station de B est inacessible.

gure VIII.03 Une telle machine concentre tous les courriers lectroniques dun site, vers e lextrieur et inversement. Elle a des avantages, notamment : e Avoir une politique de scurit concentre sur une machine plutt que e e e o sur toutes les stations du rseau : le routeur ltrant nautorise les acc`s e e extrieurs sur le port smtp que sur cette machine. e

Courriers indsirables - Le spam e Avoir une politique centralise de ltrage des contenus indsirables (vie e rus) et metteurs suspects (spam). e Limiter le nombre de congurations compliques de sendmail ` un pee a tit nombre de machines. Les stations des utilisateurs peuvent se contenter dune conguration standard plus facile ` distribuer et ` adapter a a automatiquement. Permettre de masquer plus facilement les machines internes du rseau e vis ` vis de lextrieur. En clair, les courriers auront lair de provenir a e de cette machine plutt que de la station dun utilisateur sur le rseau o e interne. Ladresse de lmetteur aura la forme : e user@domaine au lieu de : user@machine.domaine. Permettre le stockage intermdiaire du courrier en attente dune e dlivrance : les stations des utilisateurs ne sont pas toujours en fonce tionnement. Cette architecture est thorique, en pratique il peut y avoir une hirarchie e e de relay mail plus complique. Par exemple une machine distincte suivant e que le courrier entre ou sort du site, une arborescence de machines relais quand lentreprise est elle-mme rpartie sur plusieurs sites gographiques et e e e ne poss`de quune liaison vers lextrieur,. . . e e

135

3.4

Courriers indsirables - Le spam e

Le spam est laspect tr`s dsagrable du courrier lectronique. e e e e Par spam on dsigne ces innombrables courriers, le plus souvent ` e a caract`re commercial, qui envahissent nos boites aux lettres lectroniques. e e Certaines estimations tablent sur 30% de spam dans le trac mail. Deux questions se posent, comment le caractriser et surtout comment e lviter. e Caractristiques du spam e Un contenu commercial (ou nancier dune mani`re ou une autre) e Une importante liste de destinataires En-tte du message truque e e Un grand nombre dexemplaires du mme message envoy dans un court e e laps de temps Utilisation de ladresse dun destinataire sans son consentement explicite Usage dun site open mail relay pour lmission e Champs To et From de len-tte invalides e Pour mmoire, un site open mail relay autorise un RCPT qui ne dsigne e e pas un destinataire local. Le site sert alors en quelque sorte de tremplin pour

136

Courrier lectronique e le mail, avec un eet de dissimulation du site metteur vritable. Les versions e e modernes des MTA interdisent cette possibilit. e Eviter le spam Cest une question ouverte. . . Sil est vident que lil humain reconnait un tel courrier de mani`re e e quasi infaillible, il nen est pas de mme pour la machine. e Nanmoins des outils existent12 qui tablissent un pr-ltrage souvent e e e tr`s ecace mais laissant toujours un pourcentage de mails qui franchissent e les protections. Ces outils sont toujours bass sur un ltrage. Plus celui-ci est complexe, e plus le temps de traitement ` consacrer pour 1 courrier lectronique est ima e portant. Lidal tant videment de reconna la qualit dun e-mail en tr`s e e e tre e e peu de cycles machines. . . Il y a deux parties ` examiner dans un courrier, len-tte et le corps (gure a e VIII.01). Tout ce qui est vriable dans len-tte et qui concerne le rseau se e e e rsoud bien (dtection des sites open mail relay ou liste des utilisateurs e e indsirables). Cette approche nest pas susante car rien noblige dans le e protocole ` ce que les champs From : et To : de len-tte MIME soient en a e concordance avec les lments du protocole SMTP. On parle alors de fake ee mail . Lexemple qui suit illustre cette faille combien navrante : o
telnet mailhost.mondomain.fr 25 Connected to mailhost.mondomain.fr. Escape character is ^]. 220 mailhost.mondomain.fr ESMTP Sendmail 8.11.0/fla-2001-04-10; ... HELO UnSiteQuelconque.com 250 mailhost.mondomain.fr Hello UnSiteQuelconque.com, pleased to meet you MAIL From:<> 250 2.1.0 <>... Sender ok RCPT To:<tartempion@mondomain.fr> 250 2.1.5 <tartempion@mondomain.fr>... Recipient ok DATA 354 Enter mail, end with "." on a line by itself From:<NePasRepondre@XXX.com> To:<TuPeuxToujoursEssayer@YYY.com> Unsollicited Bulk Email (UBE) or Unsollicited Commercial Email (UCE). .

Et le mail sera dlivr dans la boite aux lettres de lutilisateur tarteme e pion avec des champs From : et To : compl`tement inexploitables. e
12

Cf documentation complmentaire distribue en cours e e

4 Exemple de MTA - Sendmail et son environnement Le ltrage sur le contenu du message est une autre possibilit mais qui e est beaucoup plus consommatrice de ressouces cpu, proportionnellement ` sa a taille et ` la complexit des parties (pi`ces jointes) qui peuvent le composer. a e e Les outils les plus performants restent ` crire... Loutil ultime sera celui qui ae comprendra le sens du texte et rejettera le courrier parcequindsirable. e

137

4
4.1

Exemple de MTA - Sendmail et son environnement

Relations avec le DNS

Comme nous lavons voqu au paragraphe ??, la relation entre le MTA et e e le DNS est troite. Sendmail a besoin du serveur de noms pour les oprations e e suivantes :
Sendmail Qui reoit le mail pour le domaine D ?

DNS Voici la liste des machines ayant un RR de type MX pour ce domaine et avec leur prfrence respective

Echec ! Sendmail machineA.domaineD

Echec ! Sendmail machineB.domaineD

Succs ! Sendmail machineC.domaineX

MTA pouvant rcuprer le courrier pour le domaine D

gure VIII.04 1. Transformer le nom de la machine distante en adresse IP 2. Canoniser le nom de la machine locale. 3. Canoniser le nom de la machine qui se connecte 4. Dterminer quelles sont les machines susceptibles de recevoir du coure rier pour le domaine ` atteindre. a Le quatri`me point est le plus crucial. Si le DNS du domaine ` atteindre e a (une adresse est toujours mise sous la forme nom@domain) ne dsigne pas e de machine capable de recevoir le courrier, le mail ne passera jamais pour ce domaine.

138

Courrier lectronique e Le champ RR (Resource Record) correspondant est du type MX (Mail Exchanger). Il spcie une liste dhtes pondrs par des prfrences, ` qui e o ee ee a on peut envoyer du courrier. La pondration indique lordre ` suivre pour e a les tentatives de connexions : il faut commencer par la valeur la plus basse. Si cette liste est explore de bout en bout sans succ`s il y a chec de la e e e transmission du courrier. Sil y a chec de la remission, le mail est conserv un certain temps, puis e e e est nalement rejet sil y a persistance de lchec. Le rsultat est matrialis e e e e e dans un chier nomm dead.letter e Figure 4, Le contenu du champ RR renvoy par le DNS pourrait avoir la e constitution suivante :
; ;[name] ; domaineD [ttl][class] MX preference IN IN IN MX MX MX 10 20 30 mail exchanger machineA.domaineD machineB.domaineD machineC.domaineX

Il est important de remarquer quune machine baptise MX par le DNS e nest pas forcment localise dans le domaine pour lequel elle reoit le coure e c rier, cest mme souvent le cas pour les machines relay . Cest le cas de la e troisi`me ligne, machineC.domaineX e

Relations avec lOS

139

4.2

Relations avec lOS

Sendmail a de multiples relations avec le syst`me dexploitation, comme e la gure 5 tente de le rsumer : e

UUCP

X.400

SMTP/ESMTP

syslogd

Outil externe pour dlivrer le mail aux utilisateurs Sendmail

... ...

$HOME/.forward

/var/mail/userX /etc/mail/sendmail.cf /etc/mail/userdb /etc/mail/aliases

File dattente des messages en /var/spool/mqueue

gure VIII.05 Lactivit oprationnelle de sendmail est consigne ` laide de syslog13 , e e e a ce qui explique la prsence de la ligne suivante trouve dans le chier e e /etc/syslog.conf :
mail.info /var/log/maillog

UUCP, X.400, SMTP sont autant de moyens de propager le courrier. Ces supports peuvent cohabiter au sein dune mme conguration ; autant e de Mailer slectionns en fonction de ladresse du destinataire (cf e e sendmail.cf). /etc/sendmail.cf est le chier de conguration de sendmail. Tout syst`me Unix est livr avec une conguration standard quil faut adape e ter ` la situation locale ; cest en gnral ` cet instant que les adminisa e e a trateurs syst`mes deviennent pensifs. . .(voir pourquoi au paragraphe e 5). /etc/aliases est une base de synonymes. Quand sendmail reoit un c courrier, il tente de reconna le nom du destinataire dans cette base tre et si cest le cas de lui appliquer la transformation prescrite. Un certain nombre dalias sont requis par la [RFC 1123], dautres sont conseills par la [RFC 2142]. Un court extrait du-dit chier : e
13

e Chapitre III du cours de programmation Elments de serveurs

140

Courrier lectronique e
# Basic system aliases -- these MUST be present MAILER-DAEMON: postmaster postmaster: root # Well-known aliases -- these should be filled in! root: user info: root marketing: root sales: root support: root www: webmaster webmaster: root ...

Cela signie par exemple que chaque fois qun courrier est envoy au e postmaster de ce site, sendmail transforme postmaster en root, puis root en user. Si cette derni`re cha ne fait pas lobjet dune e ne autre transformation par cette table, il sagit dun utilisateur de la machine courante. Lentretien de la table des alias est de la responsabilit de ladmie nistrateur de la machine. La table des alias dun domaine est un chier stratgique quil convient de mettre ` jour soigneusement (droits e a dacc`s, utilisateurs inexistants, boucles. . .). e ` chaque changement dans cette table ladministrateur doit fabriquer A une table dacc`s rapides (hash table) ` laide de la commande e a sendmail -bi souvent lie ` newaliases e a /etc/userdb Cette table, User Database permet au sendmail deffectuer une traduction de cha sur les noms des utilisateurs pour ne les courriers sortants. Cette disposition permet de traduire un nom de login en Prenom.Nom, donc davoir une adresse de retour de la forme Prenom.Nom@domaine ce qui fait toujours plus chic ! /var/spool/mqueue. Dans ce rpertoire sont stocks les mails en ate e tente dune dlivrance. Il peuvent y rester plusieurs jours (cest un e param`tre de la conguration du sendmail), on peut visualiser cette e le dattente avec la commande mailq. Si un grand nombre de courriers sont en attente, et a peut tre le c e cas pour les machines relais, la section du disque dur qui supporte cette partition (ici /var) doit faire lobjet dun dimensionnement en consquence, sous peine dobliger sendmail ` refuser les mails faute de e a place disque. /var/mail/userX. Chaque utilisateur de la machine locale (il peut ne pas y en avoir sur un serveur) a une bo aux lettres (mail box) te repre comme un chier ayant comme nom son login. Par exemple ee /var/spool/mail/root. Ce chier est mis ` jour automatiquement par le MTA local en cas a darrive de courrier. e De mme que pour le rpertoire de le dattente, le rpertoire des e e e bo aux lettres des utilisateurs doit faire lobjet dune attention partes

Relations avec lOS ticuli`re de la part de ladministrateur ; la prolifration des documents e e attachs aux courriers lectroniques est un aux contre lequel il est e e e dicile de se prmunir sauf ` agrandir perptuellement la taille de la e a e partition /var. . . ! :( ${HOME}/.forward : avant dtre nalement dlivr dans la bo aux e e e te lettres de lutilisateurs, sendmail lit le contenu de ce chier, ${HOME} tant le rpertoire racine des chiers de lutilisateur en question. e e Le chier .forward est la base personnelle dalias pour chaque utilisateur, a permet de renvoyer son courrier vers dautres sites, voire aussi c deectuer des transformations avant de stocker les mails (procmail). Si le .forward contient la cha suivante : ne
moi@un-autre-site.ailleurs

141

Tous les courriers envoy ` cette utilisateurs sont renvoys ` ladresse ea e a indique. e Ou encore :
"|exec /usr/local/bin/procmail"

Qui permet dinvoquer lusage du programme procmail, celui-ci est un puissant ltre qui permet de faire un tri des courriers lectroniques par e mots clefs (indispensable pour grer les mailing-listsabondantes). e Enn on peut remarquer quaucun signal nest prvu pour indiquer e ` sendmail quil faut relire son chier de conguration, cest voulu par a le concepteur. Lors de la mise au point de ce chier, il faut arrter ( e kill -TERM pid-du-sendmail) puis relancer (/usr/sbin/sendmail -bd -q30m) manuellement. . .

142

Courrier lectronique e

4.3

Le cas de POP

POP est lacronyme de Post Oce Protocol , il permet lacc`s ` un e a serveur de courrier depuis des clients PC sous Windows, voire mme des e stations unix distantes, par exemple via ppp, qui ne sont pas congures e pour faire du SMTP. POP dans sa version 3 est dni par la [RFC 1939]. e

Envoi : SMTP Serveur POP Client POP

MTA

Popd

MUA

SMTP

Lecture: POP3

Boite aux lettres de lutilisateur (mail box)

gure VIII.06 Les clients POP sont lgions sur les PCs et sur les stations de travail sous e Unix. Pour celles-ci citons : kmail14 , mh, pine, elm, mutt, gnus pour emacs, ou encore sylpheed. La liste nest pas exhaustive, loin sen faut. POP est un protocole tr`s simple qui fonctionne parfaitement mais qui e nest pas dnu de dfauts : e e e 1. Lauthentication (login/password) est change en clair sur le rseau e e e 2. Sur larchitecture Unix, lutilisateur doit avoir un compte sur la machine serveur 3. Les messages doivent tre rcuprs sur le poste client pour tre manie e ee e puls (en POP3 un double peut rester sur le serveur) e 4. La boite aux lettres ne peut tre consulte que par un seul client ` la e e a fois Ces points deviennent vite rdhibitoires quand le poste client doit accder e e au serveur au travers dun rseau non sr, et surtout lorsque le dtenteur de e u e la boite aux lettres veut consulter ses mails depuis des postes dirents. Ce e cas de gure est de plus la ralit des professionnels en dplacements. e e e Cest pourquoi dautres solutions se sont dveloppes et sont de plus en e e plus utilises : les messageries accessibles via un browser web (webmail), e donc qui utilisent comme support le protocole HTTP (voir page 149), ou un remplaant du procole POP, le protocole IMAP ! c
14

De lenvironnement de bureau KDE - http ://www.kde.org/

5 Conguration du Sendmail

143

4.4

Le cas de IMAP

Bien que largement dploy que depuis quelques annes, le protocole e e e IMAP Internet Message Access Protocol a t dvelopp ` luniveree e ea sit de Stanford en 1986. Cest actuellement la version 4rev1 qui est utilise, e e dnie dans la [RFC 2060]. e Larchitecture prsente gure VIII.06 reste valable, pratiquement il sut e e dy remplacer le mot POP par IMAP15 ! Les fonctionnalits sont plus riches et surtout pallient aux inconvnients e e lists pour POP. En clair, les points ngatifs lists pour POP sont tous rgls. e e e e e

Conguration du Sendmail

Cette section est une extraction libre et incompl`te du parae graphe 5 du document intitul Sendmail Installation and Operae tion Guide, disponible dans toute distribution de la V8. On peut galement trouver ce document dans la section System Managers Manual e (SMM) des syst`mes BSD16 . e La conguration de sendmail est contenue essentiellement dans le chier /etc/mail/sendmail.cf comme on peut le voir sur la gure 5. Le chier de conguration est organis comme une srie de lignes, le e e premier caract`re de chacune delles en prcise le type. Une ligne vide ou e e qui dbute par un # est ignore (commentaire), une ligne qui dbute par un e e e espace ou une tabulation est la continuation de la prcdente. e e

5.1

R`gles de recriture e e

Les r`gles de recritures sont reprables comme ces lignes qui dmarrent e e e e par un S (dbut dun paquet de r`gles) ou un par un R (simple r`gle). e e e Les paquets de r`gles (organisation densemble gure 7 ) ont comme but e essentiel danalyser puis de prendre les bonnes dcisions en fonction des e adresses trouves dans len-tte. Cest une dmarche purement formelle. e e e Ces r`gles utilisent une syntaxe dense qui rebute gnralement les admie e e nistrateurs. Il faut imaginer quelles sont intgralement analyses chaque fois e e que le programme sendmail est invoqu, cest ` dire en gros pour chaque e a e-mail entrant ou sortant. Elles doivent donc tre faciles ` analyser, mme e a e par un cpu de modeste performance (ou tr`s charg, ce qui revient nalement e e au mme). e Lensemble fonctionne comme un syst`me de production, cest ` dire e a qui consomme des r`gles lues squentiellement et les applique ` un jeux de e e a donnes initiales, ici une ou plusieurs adresses lectroniques. e e
Consultez http ://www.imap.org/ pour plus dinformations pour FreeBSD, NetBSD ou OpenBSD a se trouve c /usr/share/doc/smm/08.sendmailop/
16 15

dans

le

rpertoire e

144

Courrier lectronique e La partie gauche (ou lhs17 ) sert de dclencheur (pattern matching) e pour une r`gle. e La partie droite (ou rhs18 ) est dclenche si le motif de la partie gauche est e e reconnu dans le ux de donnes. Le rsultat produit, sil existe, est reinject e e e dans le syst`me de production et ce jusqu` puisement des possibilits. e ae e La gure 7 donne un aperu du fonctionnement de lautomate, les chires c (0,1,2,3,4) sont autant de ruleset, comprendre des paquets de r`gles qui e sont regroupes ensembles parcequelles traitent dun objectif commun. e

Adresse rsolue

Adresse

Message

D : Ajout du domaine de lmetteur S : Recrite spcifique au mailer, pour lmission R : Idem S mais pour la rception.

gure VIII.07 Les r`gles sont numrotes, le premier chire dit ` quel paquet elles ape e e a partiennent. Le paquet de r`gles 0 sert essentiellement ` dterminer le mailer cest e a e ` dire le moyen denvoyer le courrier (SMTP, ESMTP, UUCP. . .). a Les paquets de r`gles 1 et 2 sont appliqus respectivement ` len-tte des e e a e messages qui sortent (send) ou qui entrent (receive). Le paquet de r`gles 3 est appliqu systmatiquement ` toutes les adresses. e e e a Le paquet de r`gles 4 est appliqu ` toutes les adresses dans le message, e ea typiquement pour passer dune forme interne ` une forme externe. a Le paquet de r`gles 5, non reprsent sur lautomate, sert ` traiter les e e e a adresses locales apr`s que les aliases aient t appliqus. e ee e Les paquets de r`gles sont reprs par la lettre S, qui en balise le nom, e ee comme dans :
###################################### ### Ruleset 0 -- Parse Address ### ###################################### Sparse=0
17 18

left hand side right hand side

Conguration du Sendmail Quant aux r`gles, elles dmarrent toutes avec la lettre R, comme dans : e e
R$* R<@> R$* R$* $: $>Parse0 $1 $#local $: <@> $: $>ParseLocal $1 $: $>Parse1 $1 initial parsing special case error msgs handle local hacks final parsing

145

Deux remarques simposent : 1. Chaque ligne forme une r`gle, sur le mod`le : e e Rlhs rhs commentaire 2. Le sparateur de champ entre les trois partie de ces r`gles est la tabue e lation (une au minimum) Ladresse postmaster@mondomain.fr, par exemple, quand elle se prsente devant le paquet de r`gles 0 qui dmarre ci-dessus, a t mise sous e e e ee une forme canonique par dautres r`gles appliques pralablement (notament e e e dans la ruleset 3) : postmaster < @ mondomain . fr . > Le pattern matching va tenter de rapprocher cette suite de mots ou tokens de la partie gauche des r`gles (lhs) pour dterminer celles qui peuvent e e tre dclenches. e e e Dans la partie gauche $ sapplique ` toute suite de tokens, mme vide. a e Donc la premi`re ligne convient. La deuxi`me ne le pourrait pas car la cha e e ne postmaster prc`de le caract`re < et le @ est suivi de mondomain e e e . fr .. La troisi`me et la quatri`me r`gle sont galement dclenchables mais e e e e e prsentement lordre dapparition est galement lordre de dclenchement, e e e cette possiblit sera donc examine ventuellement plus tard. e e e La partie droite de la premi`re r`gle commence par $ : $>Parse0 ce qui e e signie lappel dun autre paquet de r`gles que lon pourra trouver plus loin e dans le chier sendmail.cf :
# # # # # # Parse0 -- do initial syntax checking and eliminate local addresses. This should either return with the (possibly modified) input or return with a #error mailer. It should not return with a #mailer other than the #error mailer.

SParse0

Le $1 signie que lon ne transmet que le premier des tokens reconnus dans la partie gauche (postmaster dans lexemple). . .

146

Courrier lectronique e

5.2

Exemple de sortie de debug

Il est utile davoir ce schma en tte quand on dbogue les r`gles : avec e e e e loption -bt de sendmail on peut suivre la progression de la transformation, r`gle par r`gle. e e
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 3,0 postmaster@mondomain.fr rewrite: ruleset 3 input: postmaster @ mondomain . fr rewrite: ruleset 96 input: postmaster < @ mondomain . fr > rewrite: ruleset 96 returns: postmaster < @ mondomain . fr . > rewrite: ruleset 3 returns: postmaster < @ mondomain . fr . > rewrite: ruleset 0 input: postmaster < @ mondomain . fr . > rewrite: ruleset 199 input: postmaster < @ mondomain . fr . > rewrite: ruleset 199 returns: postmaster < @ mondomain . fr . > rewrite: ruleset 98 input: postmaster < @ mondomain . fr . > rewrite: ruleset 98 returns: postmaster < @ mondomain . fr . > rewrite: ruleset 198 input: postmaster < @ mondomain . fr . > rewrite: ruleset 90 input: < mondomain . fr > postmaster < @ mondomain . fr . > rewrite: ruleset 90 input: mondomain . < fr > postmaster < @ mondomain . fr . > rewrite: ruleset 90 returns: postmaster < @ mondomain . fr . > rewrite: ruleset 90 returns: postmaster < @ mondomain . fr . > rewrite: ruleset 95 input: < mailhub . mondomain . fr > postmaster < @ mondomain . fr . > rewrite: ruleset 95 returns: $# relay $@ mailhub . mondomain . fr $: postmaster < @ mondomain . fr . > rewrite: ruleset 198 returns: $# relay $@ mailhub . mondomain . fr $: postmaster < @ mondomain . fr . > rewrite: ruleset 0 returns: $# relay $@ mailhub . mondomain . fr $: postmaster < @ mondomain . fr . > >

Plus en TP. . .

6 Bibliographie

147

Bibliographie

Pour en savoir davantage, on pourra consulter les bons auteurs suivants : Eric Allman Sendmail Installation and Operation Guide document au format PostScript jointe ` toutes les distributions de la V8.xx. a Bryan Costales with Eric Allman & Neil Rickert Sendmail OReilly & Associates Inc. 1994 Installing and Administering ARPA Services HewlettPackard 1991 Douglas E. Comer Internetworking with TCP/IP Volume I (chapter 19) Prentice All 1988 W. Richard Stevens TCP/IP Illustrated Volume I (chapter 28) Prentice All 1994 Et pour en savoir encore plus. . . RFC 821 Simple Mail Transfer Protocol. J. Postel. Aug-01-1982. (Format : TXT=124482 bytes) (Obsoletes RFC0788) (Also STD0010) (Status : STANDARD) RFC 822 Standard for the format of ARPA Internet text messages. D. Crocker. Aug-13-1982. (Format : TXT=109200 bytes) (Obsoletes RFC0733) (Updated by RFC1123, RFC1138, RFC1148, RFC1327) (Also STD0011) (Status : STANDARD) RFC 974 Mail routing and the domain system. C. Partridge. Jan-011986. (Format : TXT=18581 bytes) (Status : STANDARD) RFC 1123 Requirements for Internet hosts - application and support. R.T. Braden. Oct-01-1989. (Format : TXT=245503 bytes) (Updates RFC0822) (Updated by RFC2181) (Status : STANDARD) RFC 1652 SMTP Service Extension for 8bit-MIMEtransport. Klensin, N. Freed, M. Rose, E. Steerud & D. Crocker. July 1994. (Format : TXT=11842 bytes) (Obsoletes RFC1426) (Status : DRAFT STANDARD) RFC 1939 Post Oce Protocol - Version 3. J. Myers & M. Rose. May 1996. (Format : TXT=47018 bytes) (Obsoletes RFC1725) (Updated by RFC1957) (Also STD0053) (Status : STANDARD) RFC 2060 Internet Message Access Protocol - Version 4rev1. M. Crispin. December 1996. (Format : TXT=166513 bytes) (Obsoletes RFC1730) (Status : PROPOSED STANDARD) RFC 2184 MIME Parameter Value and Encoded Word Extensions : Character Sets, Languages, and Continuations. N. Freed, K. Moore. August 1997. (Format : TXT=17635 bytes) (Updates RFC2045, RFC2047, RFC2183) (Status : PROPOSED STANDARD) RFC 2476 Message Submission. R. Gellens, J. Klensin. December 1998. (Format : TXT=30050 bytes) (Status : PROPOSED STANDARD)

148

Courrier lectronique e RFC 2821 Simple Mail Transfer Protocol. J. Klensin, Ed.April 2001. (Format : TXT=192504 bytes) (Obsoletes RFC0821, RFC0974, RFC1869) (Status : PROPOSED STANDARD) RFC 2822 Internet Message Format. P. Resnick, Ed.April 2001. (Format : TXT=110695 bytes) (Obsoletes RFC0822) (Status : PROPOSED STANDARD)

Chapitre IX Anatomie dun serveur Web

1 Le protocole HTTP

Ce document est une prsentation succincte du protocole HTTP 1.0 et e du serveur Apache qui lutilise. Le protocole HTTP1 est le protocole dapplication utilis pour vhiculer, e e entres autres, de lHTML2 sur lInternet. Cest le protocole le plus utilis en volume depuis 1995, devant FTP, e NNTP et SMTP ; il accompagne lexplosion de lutilisation du syst`me global e dinformation WorldWide Web. Depuis 1990, date dapparition du Web, le protocole HTTP volue e doucement mais surement. Il est longtemps rest sous forme de draft. La e premi`re version dploye largement a t la 1.0, dnie dans la RFC 1945 e e e ee e de mai 1996. Depuis le dbut du mois de janvier 1997 est apparue la version e 1.1, deux fois plus volumineuse pour tenir compte des nouvelles orientations de lusage du service. Aujourdhui ce protocole est tellement rpandu que pour bon nombre de e nouveaux utilisateurs du rseau, lInternet cest le web ! e Techniquement, lusage de ce protocole se conoit comme une relation c entre un client et un serveur. Le client, appel gnriquement un browser, e e e un User Agent, ou encore butineur de toile, interroge un serveur connu par son url3 dont la syntaxe est bien dcrite dans la RFC 1738. e Par exemple la cha de caract`res http ://www.sio.ecp.fr/ est une ne e url ; il sut de la transmettre en tant quargument ` un quelconque outil a dexploration et celui-ci vous renverra (si tout se passe comme prvu !) ce qui e est prvu sur le serveur en question pour rpondre ` cette demande (car il e e a sagit bien dune requte comme nous le verrons plus loin dans ce chapitre). e Le serveur, suppos ` lcoute du rseau au moment o` la partie cliente ea e e u linterroge, utilise un port connu ` lavance. Le port 80 est ddi ociellement a e e
Hypertext Transfer Protocol Hypertext Markup Language Consulter les technical reports and publications du site : http ://www.w3.org/pub/WWW/TR/ 3 Uniform Resource Locator
2 1

150

Anatomie dun serveur Web au protocole http4 , mais ce nest pas une obligation (cette dcision est prise ` e a la conguration du serveur). Lurl qui dsigne un serveur peut contenir dans e sa syntaxe le numro de port sur lequel il faut linterroger, comme dans : e http ://www.sio.ecp.fr :11235/.

1.1

Exemple dchange avec http e

Le transport des octets est assur par TCP5 et le protocole est human e readable, ce qui nous autorise des essais de connexion avec le client tcp ` tout faire : telnet ! Bien entendu on pourrait utiliser un browser plus a classique, mais celui-ci grant pour nous le dtail des changes il ne serait e e e plus possible de les examiner.
$ telnet localhost 80 Trying... Connected to localhost. Escape character is ^]. GET / HTTP/1.0

Ce qui est tap par lutilisateur e et la rponse du serveur. e

La requte, suivie dune ligne e vide. HTTP/1.1 200 OK Enn la rponse du serveur, e Date: Fri, 01 Mar 2002 10:59:06 GMT Server: Apache/1.3.23 (Unix) que lon peut dcomposer en e Last-Modified: Sat, 10 Nov 2001 16:13:02 trois parties : GMT
ETag: "1381-8b-3bed520e" Accept-Ranges: bytes Content-Length: 79 Connection: close Content-Type: text/html

1. Un code (HTTP)

de

retour

2. Un en-tte MIME e 3. Des octets, ici ceux dune page crite en HTML. e Notons galement la decone nexion ` linitiative du sera veur, en n denvoi de la page HTML.

<HTML> <HEAD> <TITLE>Ceci est un titre</TITLE> </HEAD> <BODY> </BODY> </HTML> Connection closed by foreign host.

1.2

Structure dun change e

Lexemple qui prc`de est typique dun change entre le client et le sere e e veur : une question du client gn`re une rponse du serveur, le tout lors dune e e e connexion TCP qui se termine lors de lenvoi du dernier octet de la rponse e (clture ` linitiative du serveur). o a Le serveur ne conserve pas la mmoire des changes passs, on dit aussi e e e quil est sans tat, ou stateless. e
4 5

http ://www.iana.org/assignments/port-numbers page 83

Le protocole HTTP La question et la rponse sont bties sur un mod`le voisin : le message e a e HTTP.
Message HTTP

151

B
Dbut du message

D C

gure IX.01 Les parties A, B et C forment len-tte du message, et D le corps. e A La premi`re ligne du message, est soit la question pose (request-line), e e soit le statut de la rponse (status-line). e La question est une ligne termine par CRLF, elle se compose de trois e champs : Une mthode ` prendre dans GET, HEAD, ou POST. e a GET Plus de 99% des requtes ont cette mthode, elle retourne e e linformation demande dans lURL (ci-dessous). e HEAD La mme chose que GET, mais seul len-tte du serveur e e est envoy. Utile pour faire des tests daccessibilit sans sure e charger la bande passante. Utile galement pour vrier de e e la date de fraicheur dun document (information contenue dans len-tte). e POST Cette mthode permet denvoyer de linformation au sere veur, cest typiquement le contenu dun formulaire rempli par lutilisateur. Une ressource que lon dsigne par une URL6 . e Par exemple http ://www.site.org/. La version du protocole , sous forme HTTP-Numro de version. e Par exemple HTTP/1.1 ! La rponse. Cette premi`re ligne nest que le statut de la rponse, e e e les octets qui la dtaillent se trouvent plus loin, dans le corps du e message. Trois champs la composent, elle se termine par CRLF : La version du protocole , sous forme HTTP-Numro de version, e comme pour la question. Statut Cest une valeur numrique qui dcrit le statut de la rponse. e e e Le premier des trois digits donne le sens gnral : e e
6

Uniform Resource Locator, consulter la RFC 1630

152 1xx 2xx

Anatomie dun serveur Web Nest pas utilis Futur Use e Succ`s, laction demande a t comprise et excute e e ee e e correctement. 3xx Redirection. La partie cliente doit reprendre linterrogation, avec une autre formulation. 4xx Erreur cot client. La question comporte une erreur de e syntaxe ou ne peut tre accepte. e e 5xx Erreur cot serveur. Il peut sagir dune erreur interne, e due ` lOS ou ` la ressource devenue non accessible. a a Phrase Cest un petit commentaire (Reason- Phrase) qui accompagne le statut, par exemple le statut 200 est suivi gnralement e e du commentaire OK ! B Cest une partie optionnelle, qui contient des informations ` propos du a corps du message. Sa syntaxe est proche de celle employe dans le coure rier lectronique, et pour cause, elle repecte aussi le standard MIME7 . e Un en-tte de ce type est constitu dune suite dune ou plusieurs lignes e e (la n dune ligne est le marqueur CRLF) construite sur le mod`le : e Nom de champ : Valeur du champ CRLF Eventuellement le marqueur de n de ligne peut tre omis pour le e sparateur ;. e Exemple den-tte MIME : e
Date: Fri, 01 Mar 2002 10:59:06 GMT Server: Apache/1.3.23 (Unix) Last-Modified: Sat, 10 Nov 2001 16:13:02 GMT ETag: "1381-8b-3bed520e" Accept-Ranges: bytes Content-Length: 79 Connection: close Content-Type: text/html

Date : Cest la date ` laquelle le message a t envoy. Bien sr il sagit a ee e u de la date du serveur, il peut exister un dcalage incohrent si les e e machines ne sont pas synchronises (par exemple avec XNTP). e Server : Contient une information relative au serveur qui a fabriqu e la rponse. En gnrale la liste des outils logiciels et leur version. e e e Content-type : Ce champ permet didentier les octets du corps du message. Content-length : Dsigne la taille (en octets) du corps du message, e cest ` dire la partie D de la gure 1. a Last-modified : Il sagit de la date de derni`re modication du e chier demand, comme lillustre le rsultat de la commande ll e e (voir aussi la co ncidence de la taille du chier et la valeur du champ prcdent). e e
7

Multipurpose Internet Mail Extension, consulter la RFC 1521

Le protocole HTTP
-rw-r--r-1 web doc 139 Nov 10 17:13 index.html

153

ETag : Cest un identicateur du serveur, constant lors des changes. e Cest un moyen de maintenir le dialogue avec un serveur en particulier, par exemple quand ceux-ci sont en grappe pour quilibrer e la charge et assurer la redondance. C Une ligne vide (CRLF) qui est le marqueur de n den-tte. Il est donc e absolument obligatoire quelle gure dans le message. Son absence entraine une incapacit de traitement du message, par le serveur ou par e le client. D Le corps du message. Il est omis dans certains cas, comme une requte e avec la mthode GET ou une rponse ` une requte avec la mthode e e a e e HEAD. Cest dans cette partie du message que lon trouve par exemple les octets de lHTML, ou encore ceux dune image. . . Le type des octets est intimement li ` celui annonc dans len-tte, e a e e plus prcisement dans le champ Content-Type. e Par exemple : Content-Type : text/html = Le corps du message contient des octets ` interprter comme ceux dune page crite en HTML. a e e Content-Type : image/jpg = Le corps du message contient des octets ` interprter comme ceux dune image au format jpeg a e

154

Anatomie dun serveur Web

URIs et URLs

Le succ`s du web sappuie largement sur un syst`me de nommage des e e objets accessibles, qui en uniformise lacc`s, quils appartiennent ` la mae a chine sur laquelle on travaille ou distants sur une machine en un point quelconque du rseau (mais suppos accessible). Ce syst`me de nommage univere e e sel est lurl (Uniform Resource Locator RFC 1738) driv dun syst`me e e e de nommage plus gnral nomm uri (Universal Resource Identier e e e RFC 1630). La syntaxe gnrale dun(e) url est de la forme : e e <scheme> :<scheme-specic-part> Succintement la scheme est une mthode que lon spare ` laide du e e a caract`re : dune cha de caract`res ascii 7 bits dont la structure est e ne e essentiellement fonction de la scheme qui prc`de et que lon peut imaginer e e comme un argument. Une scheme est une squence de caract`res 7bits. Les lettres a ` z, e e a les chires de 0 ` 9, le signe +, le . et le - sont admis. Majuscules a et minuscules sont indirencis. e e Exemples de schemes : http, ftp, le, mailto, . . .Il en existe dautres (cf la RFC) non indispensables pour la comprhension de cet expos. e e 8 Globalement une url doit tre encode en ascii 7 bits sans caract`re e e e de contrle (cest ` dire entre les caract`res 20 et 7F), ce qui a comme o a e consquence que tous les autres caract`res doivent tre encods. e e e e La mthode dencodage transforme tout caract`re non utilisable direce e tement en un triplet form du caract`re % et de deux caract`res qui en e e e reprsente la valeur hexadcimale. Par exemple lespace (20 hex) doit tre e e e cod %20. e Un certain nombre de caract`res, bien que thoriquement reprsentables, e e e sont considrs comme non srs (unsafe) et devraient tre galement enee u e e cods de la mme mani`re que ci-dessus, ce sont : e e e % < > " # { } | \ ^ ~ [ ] Pour un certain nombre de schemes (http. . .) certains caract`res sont e rservs car ils ont une signication particuli`re. Ce sont : e e e ; / ? : @ = & Ainsi, sils apparaissent dans lurl sans faire partie de sa syntaxe, ils doivent tre encods. e e

2.1
8

Scheme http

Une url avec la scheme http bien forme doit tre de la forme : e e
man ascii sur toute machine unix

URIs et URLs http ://<host> :<port>/<path> ?<searchpath> path et searchpath sont optionnels. host Cest un nom de machine ou une adresse IP. port Le numro de port. Sil nest pas prcis, la valeur 80 est prise par e e e dfaut. e path Cest un slecteur au sens du protocole http. e searchpath Cest ce que lon appelle la query string, autrement dit la cha dinterrogation. ne ` A lintrieur de ces deux composantes, les caract`res / ; ? sont rservs, e e e e ce qui signie que sils doivent tre employs, ils doivent tre encods pour e e e e viter les ambigu es. e t ` Le ? marque la limite entre lobjet interrogeable et la query string. A lintrieur de cette cha dinterrogation le caract`re + est admis comme e ne e raccourci pour lespace (ascii 20 hex). Il doit donc tre encod sil doit tre e e e utilis en tant que tel. e De mme, ` lintrieur de la query string le caract`re = marque la e a e e sparation entre variable et valeur, le & marque la sparation entre les couples e e variable = valeur. Exemple rcapitulatif : e
http ://www.google.fr/search ?q=cours+r%E9seaux&hl=fr&start=10&sa=N

155

Notez le cod %E9, cest ` dire le caract`re de rang 1416+9 = 233. e e a e On peut galement observer quatre variables q, hl, start et sa dont la e signication peut tre partiellement devine, mais dont le remplissage reste e e ` la charge du serveur en question. a Le rle de la cha search est celui de ce que lon appelle une CGI ou o ne Common Gateway Interface, cest ` dire un programme qui eectue le lien a entre le serveur interrog et des programmes dapplication, ici une recherche e dans une base de donnes. Nous examinons succinctement le principe de e fonctionnement de tels programmes page 169.

156

Anatomie dun serveur Web

Architecture interne du serveur Apache

Cette partie se consacre ` ltude du fonctionnement du serveur Apache9 . a e Pour comprendre les mcanismes internes dun tel serveur il est absolue ment ncessaire de pouvoir en lire le code source, cette contrainte exclu les e produits commerciaux. Au mois de mars 2002, dapr`s le Netcraft Web Server Survey10 le e serveur le plus utilis (55%) est tr`s majoritairement celui du projet Apache. e e Dapr`s ses auteurs, le serveur Apache est une solution de continuit au e e serveur du NCSA11 . Il corrige des bugs et ajoute de nombreuses fonctionnalits, particul`rement un mcanisme dAPI pour permettre aux administrae e e teurs de sites de dvelopper de nouveaux modules adapts ` leurs besoins e e a propres. Plus gnralement, tout ce qui nest pas strictement dans les ate e tributions du serveur (gestion des processus, gestion mmoire, gese tion du rseau) est trait comme un module dextension. Le chier e e apache 1.3.23/htdocs/manual/misc/API.html de la distribution standard apporte des prcisions, le serveur http ://www.apacheweek.com/ pointe e galement sur grand nombre de documents tr`s utiles. e e Le serveur Apache introduit galement la possibilit de serveurs multie e domaines (domaines virtuels), ce qui est fort apprci des hbergeurs de sites. e e e

3.1

Environnement dutilisation

La gure 2 qui suit, synthtise lenvironnement dutilisation. e

SIGTERM SIGHUP

Serveur HTTPD
Accs clients HTTP

httpd.pid

access_log

error_log srm.conf httpd.conf access.conf

Arborescence des fichiers accessibles

Apache HTTP server project, http ://www.apache.org, http ://www.apacheweek.com/ est galement une source intressante dinformations e e 10 http ://www.netcraft.com/survey/ 11 National Center for Supercomputing Applications Universit de lIllinois, aux e Etats Unis

Architecture interne du serveur Apache Le serveur se met en uvre simplement. La compilation fournit un excutable, httpd, qui, pour sexcuter correctement, a besoin des trois e e chiers ASCII de conguration : srm.conf, access.conf, httpd.conf. Cest en fait dans celui-ci que sont eectus lessentiel des ajustements locaux e ` la conguration standard. a Lors de lexcution, trois chiers sont modis12 : e e httpd.pid (PidFile) contient le process ID du leader de groupe ; ` a utiliser avec le signal SIGHUP (cf gure 2) pour provoquer la re-lecture et le re-dmarrage ` chaud du serveur, ou avec SIGTERM pour mettre e a n ` son activit. a e access log (CustomLog) Qui contient le dtail des acc`s clients. Ce chier e e peut devenir tr`s volumineux. e error log (ErrorLog) Qui contient le dtail des acc`s infructueux et des e e ventuels probl`mes de fonctionnement du serveur. e e Le daemon httpd est soit du type (ServerType) standalone ou si son invocation est occasionnelle, ` la demande pilot par inetd (cf page 4). a e Il dmarre son activit par ouvrir le port (Port) dsign dans la cone e e e guration, puis sexcute avec les droits de lutilisateur User et du groupe e Group. Sa conguration se trouve dans le rpertoire conf sous-rpertoire de e e ServerRoot. Les chiers accessibles par les connexions clientes, eux, se situent dans le rpertoire DocumentRoot qui en est la racine, cest ` dire vue e a comme / par les browsers clients. Le chier httpd.pid contient un numro de processus leader de groupe e car en fait le serveur Apache, d`s son initialisation, dmarre un certain e e nombre de processus, autant de serveurs capables de comprendre les requtes e des clients. En voici un exemple : MinSpareServers 5 MaxSpareServers 10 StartServers 5 MaxClients 150 Cest le nombre minimum dinstances du serveur (non compris le processus ma tre) en attente dune connexion. Sil en manque, elles sont cres. ee Cest le nombre maximum dinstances du serveur (non compris le processus ma tre) en attente dune connexion. Sil y en a de trop elles sont supprimes. e Cest le nombre minimum dinstances du serveur (non compris le processus ma tre) au dmarrage. e Cest le nombre maximum de clients (requtes HTTP) e simultans. Cette constante peut tre augmente en e e e fonction de la puissance de la machine.

157

Un processus joue le rle de rgulateur, du point de vue Unix cest un o e processus chef de groupe (leader). La commande ps permet de visualiser une situation oprationnelle : e
Entre parenth`ses le nom de la variable du le chier httpd.conf qui permet den e modier le chemin
12

158
web root web web web web web web web web 17361 2794 17363 17270 17362 17401 17313 17312 17355 17314 2794 1 2794 2794 2794 2794 2794 2794 2794 2794 0 0 0 0 0 0 0 0 0 0 Mar Feb Mar Mar Mar Mar Mar Mar Mar Mar 13 23 13 13 13 13 13 13 13 13 ? ? ? ? ? ? ? ? ? ? 0:00 0:06 0:00 0:01 0:00 0:00 0:00 0:01 0:00 0:01

Anatomie dun serveur Web

/usr/local/bin/httpd /usr/local/bin/httpd /usr/local/bin/httpd /usr/local/bin/httpd /usr/local/bin/httpd /usr/local/bin/httpd /usr/local/bin/httpd /usr/local/bin/httpd /usr/local/bin/httpd /usr/local/bin/httpd -d -d -d -d -d -d -d -d -d -d /users/web /users/web /users/web /users/web /users/web /users/web /users/web /users/web /users/web /users/web

Ici il y a 9 instances du serveurs et le processus ma tre, quil est ais de e reconnaitre (2794) car il est le p`re des autres processus (ce qui nimplique pas e quil en est le chef de groupe, mais la suite de lanalyse nous le conrmera). La commande netstat -f inet -a | grep http ne donne quune ligne :
tcp 0 0 *.http *.* LISTEN

Cela signie quaucune connexion nest en cours sur ce serveur, et quune seule socket est en apparence ` lcoute du rseau. Cest une situation qui a e e peut sembler paradoxale eu gard au nombre de processus ci-dessus, le code e nous fournira une explication au paragraphe suivant. La commande tail -1 logs/access.log fournit la trace de la derni`re e requte : e
www.chezmoi.tld - - [01/Mar/2002:17:13:28 +0100] "GET / HTTP/1.0" 200 79

Il sagit de la trace de notre exemple dinterrogation du dbut de ce e chapitre !

3.2

Architecture interne

Attention, ce paragraphe concerne la version 1.1.1 du logiciel. Le fonctionnement de la version courante, 1.3.23, reste similaire mais le code ayant beaucoup chang, les numros de lignes sont devenus de fait e e compl`tement faux. e

Ce qui nous intresse plus particuli`rement pour expliquer le fonctione e nement du serveur se trouve dans le rpertoire src/, sous rpertoire du e e rpertoire principal de la distribution : e
$ ll apache_1.1.1/ total 19 -rw------- 1 fla -rw------- 1 fla -rw------- 1 fla drwxr-x--- 2 fla drwxr-x--- 2 fla drwxr-x--- 2 fla drwxr-x--- 2 fla drwxr-x--- 2 fla drwxr-x--- 2 fla drwxr-x--- 2 fla

users users users users users users users users users users

3738 2604 3059 512 512 512 2048 512 2048 512

Mar 12 1996 CHANGES Feb 22 1996 LICENSE Jul 3 1996 README Feb 7 22:14 cgi-bin Feb 7 22:14 conf Feb 7 22:14 htdocs Feb 7 22:14 icons Jul 8 1996 logs Mar 12 10:42 src Feb 7 22:15 support

Architecture interne du serveur Apache Dans ce rpertoire qui compte au moins 75 chier (wc -l *.[ch] e 27441 lignes) nous nous restreignons aux chiers essentiels dcrits dans le e README soit encore une petite dizaine dentres eux (wc -l 6821 lignes) : mod cgi.c, http protocol.c, http request.c, http core.c, http config.c, http log.c, http main.c, alloc.c Dans un premier temps nous allons examiner le fonctionnement de la gestion des processus, du mode de relation entre le p`re et ses ls. e Puis, dans un autre paragraphe, nous examinerons plus particuli`rement e ce qui se passe lors dune connexion, avec le cas particulier de lexcution e 13 dune CGI qui comme son nom lindique est le programme qui eectue linterface entre le serveur HTTP et un programme dapplication quelconque. Dans la suite de ce document le terme cgi employ seul dsigne ce type e e dapplication. Gestion des processus Au commencement est le main, et celui-ci se trouve dans le chier http main.c, comme il se doit ! ... 1035 1036 ... 1472 1473 1474 ... 1491 1492 1493

159

... pool *pconf; /* Pool for config stuff */ pool *ptrans; /* Pool for per-transaction stuff */ ... int main(int argc, char *argv[]) { ... init_alloc(); pconf = permanent_pool; ptrans = make_sub_pool(pconf);

La fonction init alloc appelle make sub pool qui initialise un intressant mcanisme de buers cha es, utilis tout au long du code d`s e e n e e lors quil y a besoin dallouer de la mmoire. e ... 1523 ... setup_prelinked_modules();

Les dirents modules du serveurs sont ajouts dans une liste cha ee. e e n 1524 1525 1526 1527 1528
13

server_conf = read_config (pconf, ptrans, server_confname); if(standalone) { clear_pool (pconf);

/* standalone_main rereads... */

Common Gateway Interface

160 1529 1530 1531 ... 1580 1581 1582 }

Anatomie dun serveur Web standalone_main(argc, argv); } else { ... } exit (0);

Standalone est ` 0 si le serveur est invoqu depuis inetd 14 . Son mode a e de fonctionnement le plus ecace reste avec ce param`tre ` 1 (voir le cours e a sur inetd), que nous supposons ici. La fonction standalone main (ligne 1362) prpare le processus ` son fue a tur rle de serveur. Pour bien comprendre le cette fonction, il faut imaginer o quelle est invoque au dmarrage, et ` chaud, pour lire et relire la cone e a guration. Ligne 1369 , la variable one process = 0 (sinon le processus est en mode debug) occasionne lappel ` la fonction detach (ligne 876). Celle-ci a transforme le processus en leader de groupe avec la succession bien connue fork + setsid (pour plus de dtails, voir le cours sur les e daemons). Ligne 1374 , la fonction sigsetjmp enregistre la position de la pile et ltat du masque dinterruption (deuxi`me argument non nul) dans e e e a restart buffer. Tout appel ultrieur ` siglongjmp forcera la reprise de lexcution en cette ligne. e Ligne 1377 On ignore tout signal de type SIGHUP, cela bloque toute tentative cumulative de relecture de la conguration. Ligne 1382 (one process = 0) on envoie un signal SIGHUP ` tous les proa cessus du groupe. Cette disposition nest utile que dans le cas dun re-dmarrage ` chaud. La variable pgrp est initialise par la fonction e a e detach (ligne 876), elle contient le PID du chef de groupe. Lintret davoir un groupe de processus est que le signal envoy ` son e ea leader est automatiquement envoy ` tous les processus y apparteea nant. Chaque processus qui reoit ce signal, sil est en mesure de le traiter, c e appelle la fonction just die qui excute un exit(0) (ligne 943). Donc tous les ls meurent, sauf le chef de groupe. Ligne 1390 , lappel ` la fonction reclaim child processes() eectue aua tant de wait quil y avait de processus ls, pour viter les zombis. e Ligne 1398 Relecture des chiers de conguration. Ligne 1400 set group privs (ligne 960) change le user id et le group id si ceux-ci ont t modis. ee e
Cette alternative est dcide dans le chier httpd.conf, conguration du param`tre e e e ServerType
14

Architecture interne du serveur Apache Ligne 1401 accept mutex init (ligne 166) fabrique un chier temporaire (/usr/tmp/htlock.XXXXXX), louvre, rduit son nombre de lien ` 0, de e a telle sorte quil sera supprim d`s la n du processus. Ce chier est le e e verrou dacc`s ` la socket principale, comme nous lexaminerons un peu e a plus loin. Ligne 1402 reinit scoreboard (ligne 596) Cette fonction remet ` zro, a e ou cre (setup shared mem ligne 432) la zone de mmoire commune e e entre le chef de groupe et ses processus ls. Cette zone mmoire est, e soit un segment de mmoire partage (IPC du syst`me V), soit de la e e e mmoire rendue commune par un appel ` la primitive mmap (Le choix e a est eectu par configure qui analyse les possibilits du syst`me, avant e e e compilation du serveur). La taille de cette zone est de HARD SERVER LIMIT sizeof(short score) octets, la structure short score, dnie e dans scoreboard.h, recueille les statistiques dutilisation de chaque serveur et son statut (par exemple SERVER READY, SERVER DEAD. . .). Cest par ce moyen que le serveur ma contrle les serveurs ls. tre o HARD SERVER LIMIT dnit le nombre maximum de connexions actives, e donc dinstances de serveur, ` un instant donn. En standard cette a e valeur est 150, elle peut tre augmente dans le chier de conguration e e httpd.conf (voir ci-dessus au paragraphe II.1) Enn la gure 4 montre son rle stratgique. o e Ligne 1413 (on suppose listeners = NULL), apr`s avoir initialis une e e structure dadresse, appel ` la fonction make sock (ligne 1298). Cellea ci cre et initialise une socket, et, dtail important, appelle par deux e e fois setsockopt, ce qui mrite un commentaire : e ... 1312 1313 ... 1318 1319 ...

161

... if((setsockopt(s, SOL_SOCKET,SO_REUSEADDR,(char *)&one,sizeof(one))) == -1) { ... if((setsockopt(s, SOL_SOCKET,SO_KEEPALIVE,(char *)&keepalive_value, sizeof(keepalive_value))) == -1) { ...

SO REUSEADDR Indique que la r`gle dexclusivit suivie par bind(2) e e pour lattribution dun port ne sapplique plus : un processus peut se servir dun mme port pour plusieurs usages dirents (comme e e par exemple le client ftp qui attaque les port 21 et 20 du serveur avec le mme port local), voire mme des processus dirents (cest e e e le cas ici) peuvent faire un bind avec le mme port sans rencontrer e la fatidique erreur 48 (Address already in use) ! Vue des clients HTTP, le serveur est accessible uniquement sur le port 80, ce que nous avons remarqu au paragraphe II.1 (netstat) e sans lexpliquer, voila qui est fait !

162

Anatomie dun serveur Web SO KEEPALIVE Indique ` la couche de transport, ici TCP, quelle doit a mettre ` interval rgulier (non congurable) un message ` destie a e a nation de la socket distante. Que celle-ci ny rponde pas et la proe chaine tentative dcriture sur la socket se solde par la rception e e dun SIGPIPE, indiquant la disparition de la socket distante (voir plus loin la gestion de ce signal dans la fonction child main, ligne 1139). Ligne 1430 set signals (1007) prvoit le comportement lors de la e rception des signaux : e SIGHUP SIGTERM Appel de restart Appel de sig term

Ligne 1438 et la suivante, cration dautant de processus ls quil en est e demand dans le chier de conguration (StartServers). La fonction e make child (1275) appelle fork, puis dans le ls modie le comportement face aux signaux SIGHUP et SIGTERM (just die appelle exit) avant dexcuter child main. e
main ()

standalone_main ()

Pour chaque fils demand Processus esclaves make_child () Processus maitre

child_main ()

Boucle infinie

accept () wait || make_child

read_request () process_request ()

gure IX.03 Arrivs ` ce stade, il nous faut analyser lattitude des deux types de e a processus. Le processus ma tre Ligne 1444 dmarre une boucle innie de surveillance. Seule la rception e e et le traitement dun signal peut linterrompre.

Architecture interne du serveur Apache Ligne 1458 Ici, si le nombre de serveurs disponibles est infrieur au nombre e minimal requis, il y regnration de ceux qui manquent avec la fonction e e make child

163

Les processus esclaves Ligne 1139 La gestion de ces processus, autant de serveurs Web oprationnels, dbute avec lappel de la fonction child main. e e Ligne 1167 Dbut de la boucle innie qui g`re cette instance du serveur. e e Au cours dune boucle le serveur g`re lacceptation dune requte et e e son traitement. Ligne 1174 Gestion du SIGPIPE donc des clients qui dconnectent avant e lheure ! Ligne 1180 Si le nombre de serveurs libres (count idle servers) est suprieur ` la limite congure, ou si e a e Ligne 1182 le nombre de requtes traites par ce processus a atteint la lie e mite max requests per child, le processus sarrte de lui-mme. Cest e e lauto-rgulation pour librer des ressources occupes par un trop grand e e e nombre de processus serveurs inutiles. Ligne 1190 Lappel ` la fonction accept mutex on vrouille lacc`s ` la a e e a ressource dnie prcdement avec accept mutex init (ligne 166). Ce e e e vrouillage est bloquant et exclusif. Cest ` dire quil faut quun autre e a processus en dvrouille lacc`s pour que le premier processus sur la e e e liste dattente (gre par le noyau Unix) y acc`de. ee e Ce fonctionnement est assur suivant la version dUnix par la primitive e flock ou par la primitive fcntl. Les smaphore du Syst`me V (semget, semctl, semop. . .) assurent e e la mme fonctionnalit, en plus complet, ils sont aussi plus complexes e e ` mettre en uvre. a Cette opration est ` rapprocher de loption SO REUSEADDR prise ligne e a 1312. Il faut viter que plusieurs processus serveurs disponibles ne e rpondent ` la requte. Il ny a quun seul processus prt ` rpondre e a e e a e ` la fois et d`s que le accept (ligne 1217) retourne dans le code utilia e sateur la ressource est dvrouille (on suppose toujours listeners = e e e 0). Ligne 1221 La fonction accept mutex off dvrouille lacc`s ` la socket. e e e a Ligne 1245 read request lit la requte du client, donc un message HTTP. e Ligne 1247 process request fabrique la rponse au client, donc un autre e message HTTP.

164

Anatomie dun serveur Web

Maitre

HARD_SERVER_LIMIT score_board

Accs la socket

httpd

httpd

... ...

httpd

MaxClients

gure IX.04 Prise en main des requtes e Le chier concern par la lecture de la requte est http protocol.c. e e La lecture de la premi`re ligne du message HTTP est assure par la e e 15 fonction read request line, ligne 329 . La lecture de len-tte MIME est assure par la fonction e e get mime headers, ligne 356. Attention, seule len-tte lue le corps du e message dans le cas de a mthode POST est lu plus tard, lors du traitement e du message, par le programme dapplication (CGI). Le chier concern par la formulation de la rponse est http request.c et e e la fonction principale process request, ligne 772. Celle-ci appelle en cascade process request internal, ligne 684. Cette derni`re eectue un certain nombre de tests avant de traiter eece tivement la requte. Parmi ceux-ci on peut relever, e Ligne 716 La fonction unescape url (util.c, ligne 593) assure le dcodage e des caract`res rservs et transcods comme il est spci par la RFC e e e e e e 1738. Ligne 723 La fonction getparents ltre les chemins (pathname) qui prtent ` confusion. e a Ligne 768 La fonction invoke handler est le point dentre dans le traitee ment de la requte. Cette fonction (http config.c, ligne 267) invoque e le programme (module) qui se charge de fabriquer la rponse, au vue e e du contenu du champ content type de la requte. Si celui est inexistant, comme dans notre exemple du paragraphe I, il est positionn par e dfaut ` la valeur html/text. e a
15

La mthode, lURL, et le protocole demand e e

Architecture interne du serveur Apache Deux types de CGIs Pour la suite nous supposons que la prise en main de la requte est e e faite par le module cgi, dni dans le chier mod cgi.c. Le point dentre e est la fonction cgi handler (ligne 207), cest ` dire celle qui appelle par a e invoke handler, vue au paragraphe ci-dessus. La lecture du code permet de dduire quil y a deux types de CGI, la e distinction est faite parle nom de la cgi elle-mme. e La gure 5 rsume les 2 situations possibles dexcution dune CGI. e e
Connexion client

165

HTTPD
Lecture client

HTTPD

1 cgi 2

0 Ecriture client

0 1 nphcgi 2

s>error_log (fichier error_log)

s>error_log (fichier error_log)

gure IX.05 Si le nom de lexcutable commence par nph-16 le comportement du sere veur http change. Dans le cas ordinaire (nom quelconque) les donnes transe mises depuis le client vers la cgi et rciproquement, passent par le processus e httpd et via un tube non nomm (pipe). e Dans le cas dune cgi nph, seules les donnes lues depuis le client (par e exemple avec la mthode POST) transitent par le processus httpd, la rponse, e e elle, est mise directement, ce qui amliore les performances en vitant une e e e squence lecture/criture inutile. Ce comportement est justi d`s que de e e e e gros volumes doctets sont ` transmettre au client (de grandes pages HTML, a des images. . .). Attention, dans ce dernier cas, cest ` la CGI de fabriquer lintgralit a e e du message HTTP, y compris len-tte MIME. A elle galement de grer la e e e dconnexion prmature du client (SIGPIPE). e e e Ces deux modes de fonctionnement ne sont pas clairement documents, e en fait il sagit dune caractristique du serveur du CERN, maintenue pour e assurer sans doute la compatibilit avec les applicatifs dj` crits. Il nest e ea e pas assur que cette possibilit existera dans les futures versions du serveur e e
16

Non Parse Header

166

Anatomie dun serveur Web Apache, notamment celles qui utiliseront la version 1.1 dHTTP. Examinons le code du chier mod cgi.c : 207 int cgi_handler (request_rec *r) 208 { 209 int nph; ... ... 222 nph = !(strncmp(argv0,"nph-",4)); ... ... La variable nph vaut 1 si la cgi est de ce type. ... 251 ... ... add_common_vars (r); ...

Ici on commence ` fabriquer lenvironnement dexcution de la cgi Cette a e fonction (chier util script.c, ligne 126) compl`te les variables qui ne e dpendent pas du contenu de la requte, par exemple SERVER SOFTWARE, e e REMOTE HOST,. . . ... 277 278 279 280 281 282 ... ... if (!spawn_child (r->connection->pool, cgi_child, (void *)&cld, nph ? just_wait : kill_after_timeout, &script_out, nph ? NULL : &script_in)) { log_reason ("couldnt spawn child process", r->filename, r); return SERVER_ERROR; } ...

Lappel de cette fonction provoque la cration dun processus ls, celui e qui nalement va excuter la cgi. Il faut remarquer le deuxi`me argument e e qui est un pointeur de fonction (cgi child), et le sixi`me qui est nul dans le e cas dune cgi du type nph. e script in et script out sont respectivement les canaux dentre et sortie des donnes depuis et vers le processus qui excute la cgi. Il parait donc e e logique que dans le cas dune cgi de type nph script in soit nul. Un mcanisme non encore analys duplique la sortie de ce processus vers le client e e plutt que vers le processus serveur. o Nous continuons la description du point de vue du processus p`re, donc e httpd. Ligne 295 et les suivantes, jusqu` la ligne 332, le processus lit ce que a le client lui envoie, si la mthode choisie est du type POST. Le contenu est e renvoy vers le processus ls, sans transformation : e

Architecture interne du serveur Apache 311 312 ... 335 if (fwrite (argsbuffer, 1, len_read, script_out) == 0) break; ... pfclose (r->connection->pool, script_out);

167

Il est donc clair que cest ` celui-ci dexploiter ce quenvoie le client, par a exemple le rsultat dune forme de saisie. e 337 338 ... 373 374 375 376 377 /* Handle script return... */ if (script_in && !nph) { ... send_http_header(r); if(!r->header_only) send_fd (script_in, r); kill_timeout (r); pfclose (r->connection->pool, script_in); }

Ce test traite le cas dune cgi normale, dont la sortie est lue par le serveur, puis renvoye au client (ligne 374). e Examinons maintenant comment se prpare et sexcute le processus ls : e e 101 void cgi_child (void *child_stuff) 102 { ... ... 126 add_cgi_vars (r); 127 env = create_environment (r->pool, r->subprocess_env); Ces deux derni`res lignes prparent lenvironnement du futur proe e cessus ls. Il sagit du tableau de variables accessibles depuis la variable externe environ, pour tout processus. La fonction add cgi vars (chier util script.c, ligne 192) ajoute, entres autres, les variables REQUEST METHOD et QUERY STRING ` lenvironnement. a Cette derni`re variable joue un rle majeur dans la transmission des are o guments ` la cgi quand la mthode choisie est GET. En eet, dans ce cas, a e le seul moyen pour le client denvoyer des arguments ` la cgi est dutiliser a lURL, comme par exemple dans :
http ://monweb.chez.moi/cgi-bin/nph-qtp ?base=datas&mot=acacia&champ=.MC

La syntaxe de lURL prvoit le caract`re ? comme sparateur entre le e e e nom et ses arguments. Chaque argument est ensuite crit sous la forme : e nom = valeur Les arguments sont spars les uns des autres par le caract`re &. e e e

168 135 136 ... 138

Anatomie dun serveur Web error_log2stderr (r->server); ... if (nph) client_to_stdout (r->connection);

Ligne 135, la sortie derreur est redirige vers le chier error log, et ligne e 138, la sortie standard du processus, cest la socket, donc envoye directement e vers le client ! 184 185 186 187

if((!r->args) || (!r->args[0]) || (ind(r->args,=) >= 0)) execle(r->filename, argv0, NULL, env); else execve(r->filename, create_argv(r->pool, argv0, r->args), env

Puis nalement on excute la cgi ! Bien sr, si le programme va au del` e u a de la ligne 187, il sagit dune erreur. . .

4 Principe de fonctionnement des CGIs

169

4
4.1

Principe de fonctionnement des CGIs

CGI Mthode GET, sans argument e

Dans ce paragraphe nous examinons ce qui se passe lors de lexcution e dune CGI tr`s simple (shell script, le source suit) que lon suppose place e e dans le rpertoire idoine, pour tre excute comme lors de la requte suie e e e e vante :
$ telnet localhost 80 Trying ... Connected to localhost. Escape character is ^]. GET /cgi-bin/nph-test-cgi HTTP/1.0 HTTP/1.0 200 OK Content-type: text/plain Server: Apache/1.1.1

La requte tape par lutilisateur. e e Len-tte du message HTTP rene voy par le serveur. La ligne de e statut est gnre par la cgi car il e ee sagit dune cgi de type nph-

CGI/1.0 test script report: argc is 0. argv is . SERVER_SOFTWARE = Apache/1.1.1 SERVER_NAME = www.chezmoi.tld GATEWAY_INTERFACE = CGI/1.1 SERVER_PROTOCOL = HTTP/1.0 SERVER_PORT = 80 REQUEST_METHOD = GET SCRIPT_NAME = /cgi-bin/nph-test-cgi QUERY_STRING = REMOTE_HOST = labas.tresloin.tld REMOTE_ADDR = 192.168.0.1 REMOTE_USER = CONTENT_TYPE = CONTENT_LENGTH = Connection closed by foreign host.

Le corps du message. Ces octets sont gnrs dynamiquement par e ee le programme nph-test-cgi.

Et voici le source de cet exemple (une modication du script de test livr e avec Apache) :
#!/bin/sh echo HTTP/1.0 200 OK echo Content-type: text/plain echo Server: $SERVER_SOFTWARE echo echo CGI/1.0 test script report: echo echo argc is $#. argv is "$*". echo

Remarquez la fabrication de lentte MIME, rduite mais sue e sante. Le echo seul gn`re une e e ligne vide, celle qui marque la limite avec le corps du message.

170
echo echo echo echo echo echo echo echo echo echo echo echo

Anatomie dun serveur Web

SERVER_SOFTWARE = $SERVER_SOFTWARE SERVER_NAME = $SERVER_NAME GATEWAY_INTERFACE = $GATEWAY_INTERFACE SERVER_PROTOCOL = $SERVER_PROTOCOL SERVER_PORT = $SERVER_PORT REQUEST_METHOD = $REQUEST_METHOD QUERY_STRING = $QUERY_STRING Toutes ces variables sont celles de REMOTE_HOST = $REMOTE_HOST lenvironnement gnr par le moe ee REMOTE_ADDR = $REMOTE_ADDR REMOTE_USER = $REMOTE_USER dule cgi handler avant deecCONTENT_TYPE = $CONTENT_TYPE tuer le exec. CONTENT_LENGTH = $CONTENT_LENGTH

4.2

CGI Mthode GET, avec arguments e

Examinons maintenant un cas plus compliqu, avec des arguments transe mis, ou query string. Celle-ci est transmise ` la cgi via la variable denvia ronnement QUERY STRING. Cest ` la cgi de lanalyser puisque son contenu a rel`ve de lapplicatif et non du serveur lui-mme. Essayons de coder la cgi de e e lexemple :
http ://www.chezmoi.tld/cgi-bin/query ?base=datas&mot=acacia&champ=.MC

Premi`re version : e #!/bin/sh echo Content-type: text/plain echo echo "QUERY_STRING=>"$QUERY_STRING "<=" exit 0 Linterrogation avec un telnet produit la sortie : QUERY_STRING=>base=datas&mot=acacia&champ=.MC<= Se trouve tr`s facilement sur les sites ftp le source dun outil nomm e e cgiparse17 , parfaitement adapt ` lanalyse de la cha transmise. Do` la ea ne u deuxi`me version : e
#!/bin/sh CGIBIN=~web/cgi-bin BASE=$CGIBIN/cgiparse -value base MOT=$CGIBIN/cgiparse -value mot CHAMP=$CGIBIN/cgiparse -value champ
17

Cette partie du code montre lanalyse du contenu de la variable QUERY STRING avec loutil cgiparse.

Il est dans la distribution standard du serveur httpd-3.0.tar.gz du CERN

Principe de fonctionnement des CGIs

echo Content-type: text/plain echo echo "BASE="$BASE echo "MOT="$MOT echo "CHAMP="$CHAMP exit 0

171

Et l`, la fabrication du message a renvoy. La cgi renvoie ses octets e via un tube au serveur, cest donc celui-ci qui se charge de fabriquer un en-tte MIME. e

Puis le rsultat de lexcution : e e BASE=datas MOT=acacia CHAMP=.MC

4.3

CGI Mthode POST e

La mthode POST autorise un client ` envoyer au serveur une liste de e a couples variable=valeur. Chaque couple est spar des autres par une n e e de ligne, cest ` dire (CR,LF). a Cette mthode est bien adapte ` la transmission dinformations cole e a lectes cot client dans une forme18 de saisie, et dont le volume est variable. e e La liste des couples est crite dans le corps du message, par le programme e client, et ne fait pas partie de lURL, comme cest le cas pour la mthode e GET. Il y a videment une limite au nombre maximum doctets envoy par e e 19 le client, cest le serveur qui en xe la valeur . Du cot du client, il faut e prvenir le serveur, dans len-tte du message HTTP, de la taille du corps du e e message. Cela seectue avec le champ Content-length :. Lexemple suivant ne fait que renvoyer la liste des couples lus, vers le client. Attention il ne fonctionne quavec telnet.
$ telnet www.chezmoi.tld 80 Trying 192.168.0.2... Connected to www.chezmoi.tld. Escape character is ^]. POST /cgi-bin/test-post HTTP/1.0 Content-length:14 areuh=tagada HTTP/1.0 200 OK Date: Mon, 24 Mar 1997 14:41:26 GMT Server: Apache/1.1.1 Content-type: text/plain REQUEST_METHOD = POST CONTENT_LENGTH = 14 Couple lu : areuh=tagada Connection closed by foreign host.
18 19

Le corps du message fait bien 14 caract`res si on compte la n de e ligne (CR+LF).

La rponse du serveur liste les e couples lus, ici un seul ! La variable globale REQUEST METHOD pourrait tre utilise pour adape e ter le comportement de la cgi en fonction de la mthode dee mande. e

Voir le tag FORM de lHTML e HUGE STRING LEN qui vaut 8192 en standard, dnie dans le chier httpd.h

172 Et voici le source de la cgi :

Anatomie dun serveur Web

#!/bin/sh # # Ce script teste la methode POST # echo Content-type: text/plain echo echo REQUEST_METHOD = $REQUEST_METHOD echo CONTENT_LENGTH = $CONTENT_LENGTH while read l do echo "Couple lu :" $l done exit 0

4.4

Ecriture dune CGI en Perl

Voir cours de Jean-Jacques Dhenin. . .

5 Conclusion Bibliographie

173

Conclusion Bibliographie

Rien nest constant, tout change. . .Et il faut tre constamment ` laut e a de la nouveaut dans ce domaine tr`s ractif quest celui du World Wide e e e Web. Les quelques rfrences bibliographique qui suivent illustrent ce cours, ee mais il est vident quelles sont bien insusantes pour couvrir tous les aspects e que le terme web sous-entend ! RFC 1521 N. Borenstein, N. Freed, MIME (Multipurpose Internet Mail Extensions) Part One : Mechanisms for Specifying and Describing the Format of Internet Message Bodies, 09/23/1993. (Pages=81) (Format=.txt, .ps) (Obsoletes RFC1341) (Updated by RFC1590) RFC 1590 J. Postel, Media Type Registration Procedure, 03/02/1994. (Pages=7) (Format=.txt) (Updates RFC1521) RFC 1630 T. Berners-Lee, Universal Resource Identiers in WWW : A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web, 06/09/1994. (Pages=28) (Format=.txt) RFC 1738 T. Berners-Lee, L. Masinter, M. McCahill, Uniform Resource Locators (URL), 12/20/1994. (Pages=25) (Format=.txt) RFC 1945 T. Berners-Lee, R. Fielding, H. Nielsen, Hypertext Transfer Protocol HTTP/1.0, 05/17/1996. (Pages=60) (Format=.txt) RFC 2068 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. BernersLee,Hypertext Transfer Protocol HTTP/1.1, 01/03/1997. (Pages=162) (Format=.txt) TCP/IP Illustrated Volume 3 W. Richard Stevens Addison-Wesley Janvier 1996.

174

Anatomie dun serveur Web

Chapitre X e Elments de rseaux e

1 Htes ou services virtuels o
HTTP

ipA

ipB ipWWW

ipC Traffic HTTP

ipD

gure X.01 : Serveur HTTP virtuel

La machine B (dadresse IP xe ipB) hberge par exemple le service e HTTP dadresse ip ipWWW. Cette opration est rendue possible si le e syst`me dexploitation de B autorise la notion dalias IP. e Si les machines A, C et D excutent galement un serveur HTTP, elles e e peuvent potentiellement prendre le relais de la machine B, d`s lors que e ladresse ipWWW aura t retire de la machine B pour tre recongure ee e e e sur lune dentres elles. Cette opration peut se faire manuellement ou via un outil dadministrae tion. Elle permet de faire transiter tr`s rapidement des services dune machine e ` une autre, sans rupture ou presque de la continuit. Vu des clients il sagit a e toujours de la mme machine, mais elle est virtuelle puisquelle nexiste pas e physiquement. Section en chantier, prcisions en cours. . . e

176

e Elments de rseaux e

Tunnel IP
A Encapsulation dIP dans IP

gure X.02 : Tunnel IP - Principe Le tunnel permet dencapsuler un protocole dans un autre de mme niveau e ou suprieur. Prcdemment, page 28, nous avons dj` analys lencapsulae e e ea e tion des couches de la pile Arpa selon une progression naturelle de fonctionnalits. Ici, si le principe dencapsulation est conserv, la logique initiale de e e construction, elle, est bouscule. Par exemple on peut envisager dencapsuler e IP dans de multiple protocole autres quEthernet, comme PPP1 , IP, dans une couche de transport comme TCP, voire mme dans une couche applicae tive comme HTTP. Ce dernier exemple peut para contre nature et tre pourtant cela fonctionne. . . Construire un tunnel a un cot : dune part celui de la perte desu pace de donnes dans le datagramme (il faut loger un ou plusieurs en-ttes e e supplmentaires et le MTU reste constant lui !) et dautre part celui du traie tement supplmentaire (dcapsulation, analyse) engendr par lajout de ces e e e nouveaux en-ttes. e En rsum, construire un tunnel se traduit par une perte despace pour e e les donnes dans les datagrammes et par une consommation accrue de cycles e cpus pour traiter les en-ttes supplmentaires. Heureusement le gain en fonce e tionnalits pour le rseau est substanciel, comme les exemples qui vont suivre e e lillustrent ! Les tunnels qui transitent par une couche de transport sont grs par ee une application (par exemple sshd ou httptunnel). Aussi le trac de datagrammes remonte au niveau applicatif pour redescendre au niveau IP, ce qui a lavantage de pouvoir tre mis en uvre par un utilisateur nayant pas e ncessairement les droits de ladministrateur2 , mais par contre, outre une e consommation supplmentaire de cycles cpu et des changements de contexte e inhrents ` larchitecture logicielle3 , a linconvnient dtre ddi ` un seul e a e e e ea
Point to Point Protocol , lui -mme ventuellement encapsul dans de lEthernet e e e (PPPoE RFC 2516) ou de lATM (PPPoA pour lADSL, RFC 2364) 2 Pour encapsuler IP dans IP par exemple, il faut pouvoir crire directement dans IP e ce qui ncessite une socket en mode raw et donc un uid 0 ` lexcution e a e 3 Rappelons que les processus applicatifs standards sexcutent en mode utilisateur, e et que les transferts entre la couche de transport (dans le noyau) et la couche applicative seectuent via un jeu de primitives du syst`me, voir la description des sockets de Berkeley e page 199
1

Tunnel IP avec linterface gif port (par exemple celui dune application non crypte comme pop au travers e 4 une liaison ssh) . Encapsuler IP dans IP a lavantage de rester gnraliste du point de e e vue des applications. Sur la gure ci-dessus le tunnel IP encapsule donc de lIP dans lui mme. Pour les routeurs qui acheminent ce trac il sagit de e datagrammes IP avec le type 4 (cf le chier /etc/protocols au lieux des types 1 (icmp) 6 (tcp) ou 17 (udp) plus habituels.

177

2.1

Tunnel IP avec linterface gif

La gure X.03 illustre lencapsulation dIP dans IP grce ` lusage du a a 5 generic tunnel interface . Il sagit dun pseudo-device (pas dinterface rel associ, comme cela pourrait tre le cas avec une carte rseau) tr`s e e e e e gnraliste, qui permet dencapsuler de lIP (version 4 ou 6) dans de lIP e e (version 4 ou 6)6 . Le but de cet exemple de tunnel est de montrer un routage de datagrammes issus dun rseau non ociellement rout, le 192.168.2.0/24 (RFC e e 1918), depuis la machine B (IPB ), vers la machine A (IPA ) et au travers dun rseau rout quelconque. e e Par hypoth`se la machine A sait comment router vers le 192.168.2.0/24. e Le rseau 192.168.249.0/30 (RFC 1918) sert de rseau dinterconnexion e e entre les deux machines. Concr`tement, il sagit dattribuer une adresse e IP ` chacun des pseudo-devices, qui ne soit pas dj` dans lun des a ea rseaux attachs ` chacune des machines. e e a Conceptuellement, il serait parfaitement possible dutiliser, par exemple, des adresses dans le 192.168.2.0/24. Lauteur prf`re lusage dun rseau dinterconnexion qui permet de ee e bien sparer ce qui concerne le tunnel de ce qui utilise le tunnel. De e plus, si on souhaite (et cest une quasi obligation quand on utilise des tunnels) ajouter un ltrage IP sur la machine B, il est beaucoup plus ais pour la conception des r`gles de ltrage de considrer lorigine des e e e datagrammes ayant une adresse source dans le 192.168.2.0/24 uniquement derri`re le ltre. e Examinons maintenant quelle pourrait tre la conguration spcique ` e e a ce tunnel, Sur la machine A :
ifconfig create gif0 ifconfig gif0 inet tunnel IP(A) IP(B) ifconfig gif0 inet 192.168.249.1 192.168.249.2 netmask 0xfffffffc route add -net 192.168.2.0 192.168.249.2 La mise en uvre dun tunnel au travers http pour contourner le ltrage en sortie dun site nest absolument pas recommande par lauteur de ces pages et laisse ` la compl`te e e a e responsabilit du lecteur e 5 man gif sous FreeBSD, NetBSD ou OpenBSD 6 Nous avons dj` rencontr un tel interface virtuel avec linterface de loopback lo0 ea e page 70
4

178 Puis sur la machine B :

e Elments de rseaux e

ifconfig create gif0 ifconfig gif0 inet tunnel IP(B) IP(A) ifconfig gif0 inet 192.168.249.2 192.168.254.1 netmask 0xfffffffc
A IP(A)
gif0

B 192.168.249.2
gif0 if0

IP(B)

.200 192.168.2.0/24

192.168.249.1

Datagrammes IPv4 non routables encapsuls dans des datagrammes IPv4 routables.

gure X.03 : Tunnel IP - cas concrt e Notez que la premi`re ligne de conguration prcise la source et la destie e nation relle des datagrammes alors que la deuxi`me indique ladresse locale e e et distante des extrmits du tunnel. Cest une criture particuli`re, adapte e e e e e au pilote de linterface gif0 pour la conguration des tunnels. Sur la machine B, on peut voir le rsultat de la conguration comme a : e c
$ ifconfig -a ... gif0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1280 tunnel inet IP(B) --> IP(A) inet 192.168.249.2 -> 192.168.249.1 netmask 0xfffffffc

Et sur la machine A :
$ ifconfig -a ... gif0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1280 tunnel inet IP(A) --> IP(B) inet 192.168.249.1 -> 192.168.249.2 netmask 0xfffffffc

Enn, si on examine7 sur les interfaces de B le passage de datagrammes dun ping, par exemple, envoy depuis A vers 192.168.2.200, on rel`ve les e e en-ttes IP du tableau qui suit. e Ainsi lobservation pratique rejoint la thorie : on retrouve bien sur le e linterface du tunnel (gif0) len-tte 2, dcapsul de son en-tte 1. Le dae e e e tagramme est alors disponible au niveau de la pile IP de B pour tre rout e e (routage direct8 ici) vers 192.168.2.200.
7 8

Avec tcpdump -i if0 puis tcpdump -i gif0 par exemple Cf page 61

Tunnel IP avec linterface gif En-tte 1 e Src IPA Dst IPB Code ipencap(4) En-tte 2 e 192.168.249.1 192.168.2.200 icmp

179

Sur linterface if0

Sur linterface gif0

En-tte e Src 192.168.249.1 Dst 192.168.2.200 Code icmp

Remarques : Attention, les routeurs ltrants doivent tre spcialement congurs pour e e e 9 laisser passer ce type de trac . Les core gateway le laisse passer sans probl`me. e Il est intressant de noter que le dploiement dIPv6 est dabord bas sur e e e lencapsulation de trames de la version 6 dans des trames de la version 4, en attendant que tous les routeurs soient capables de router IPv6 nativement. Enn pour conclure, est-il ncessaire de prciser que mme encape e e suls dans IP, nos datagrammes nen sont pas moins lisibles par des e yeux indiscrts ? Pour sen prmunir il nous faut examiner une technologie e e compltementaire. . .Dans le paragraphe suivant ! e

Pour un routeur de type cisco qui protgerait la machine B, il faudrait ajouter des e r`gles du genre permit ipinip host IPB IPA et permit ipinip host IPA IPB e

180

e Elments de rseaux e

2.2

IPsec et VPN

IPsec est un protocole de scurit inclus dans la couche IP elle-mme. Il e e e est dni dans la RFC 2401. Ce paragraphe aborde bri`vement la question e e du point de vue du protocole et de sa place dans la pile Arpa, tout en laissant volontairement dans un certain ou les aspects lis ` la cryptographie, e a 10 clairement absents des objectifs de ce cours . IPsec dans quel but ? IPsec est un point de passage oblig pour tout administrateur de rseau e e qui souhaite mettre en place une politique de scurit. Dailleurs, pour faire e e le lien avec le paragraphe qui prc`de, prcisons quIPsec encapsul dans IP e e e e (formellement, un tunnel) porte un nom, le VPN ( Virtual Private Network ) ! Nous avons examin comment un tunnel accro ltendue dun e t e rseau au travers dautres rseaux. Ajouter Ipsec introduit, entre autres, une e e dimension de scurit tr`s utilise pour relier des machines - ou des rseaux e e e e e - physiquement localiss nimporte o` il y a un acc`s IP, en rseaux virtuels e u e e scuriss ! Cest pour cette raison quIpsec est un artefact incontournable de e e la panoplie scuritaire sur les rseaux. e e Nous aurions pu conclure le chapitre sur IP page 43 par cette constatation que le protocole IP est lisible par tout le monde y compris par les indiscrts et e que quasiment nimporte quel bricoleur peut forger de faux datagrammes ( fake datagram ) pour empoisonner un rseau, voire dtourner les services e e dune machine. Ainsi, tout ce qui renforce la scurit IP est une bonne chose, e e surtout ` lheure des rseaux wi dont les limites de porte ne sont pas a e e ma trisables. IPsec renforce la scurit dIP sur plusieurs points : e e Condentialit Les donnes dIP (protocole de transport et donnes ape e e plicatives) sont cryptes, donc normalement non inspectables avec tout e outil danalyse de rseau. e Authentication La source du datagramme ne peut tre quun seul e metteur, et non un intermdiaire non prvu. e e e Intgrit La totalit des donnes est protge par une somme de contrle e e e e e e o (checksum), travail normalement dvolu ` la couche de transport mais e a qui au niveau dIP permet dcarter tout datagramme qui aurait t e ee modi pendant son transport. e Dispositif anti-rejeux pour viter les attaques du type man-in-thee middle consistants ` capturer un ou plusieurs datagrammes (crypts) a e dans le but de les envoyer ` nouveau pour bncier du mme eet a e e e produit que lenvoi initial.
Les RFCs donnes page 195 sont le bon point de dpart pour se documenter sur les e e aspects cryptographiques dIPsec
10

IPsec et VPN IPsec en rsum e e Ipsec (RFC 2401) est un assemblage de quatre protocoles : ESP ( Encapsulating Security Payload ) est dni par la RFC 2406. Il e assure la condentialit par lusage dalgorithmes de cryptage comme e DES (RFC 2405) , 3DES (RFC 2451), CAST-128 (RFC 2144) ou encore blowsh (RFC 2451), la liste nest pas exhaustive. . . Il faut juste noter quil sagit dalgorithmes bass sur lexistence un secret e partag (manuellement dans un chier ou cre dynamiquement avec e e IKE, voir plus bas) entre les parties qui changent des messages, et e non sur lchange dune clef publique. Cette remarque a un impact sur e la mani`re avec laquelle on doit les congurer ! e AH ( Authentication Header ) est dni par la RFC 2402. Il assure e lauthentication, cest ` dire quil cherche ` certier que les deux a a couches IP qui dialoguent sont bien celles quelles prtendent tre, puis e e lintgrit des donnes par le calcul dun checksum. Il faut noter que e e e ce dernier travail empi`te largement sur les attributions de la couche e de transport mais se justie compte-tenu des exigences inhrentes au e fonctionnement dIPsec. IPcomp ( IP payload compression ) sert ` compresser les donnes avant de a e les crypter. Son action est rendue ncessaire pour tenter de compenser e la perte de la place occupe par les en-ttes ajouts. Bien entendu e e e IPcomp peut tre utilis seul. e e IKE ( Internet Key Exchange ) est dni par la RFC 2409. Ce protocole e nest pas formellement indispensable au bon fonctionnement dIPsec mais lui apporte un mcanisme dchange de clefs, au dmarrage des e e e changes et au cours du temps. Ainsi la clef de chirement nest plus e dnie de mani`re statique dans un chier mais change continuellement e e au cours du temps, ce qui est meilleur du point de vue de la scurit. e e Du point de vue de ladministration syst`me et rseau, la mise en place e e 11 de ce protocole passe par lusage dun daemon , par exemple racoon, et par une ouverture de port UDP (isakmp/500) supplmentaire dans le e ltrage du rseau. Une ngociation dcrite dans la RFC 2409 se droule e e e e entre les htes qui doivent dialoguer, ce qui entraine une certaine lao tence au dbut des changes. e e Les 32 bits de ladresse IP de destination12 permettent thoriquement e dexprimer un adressage de type unicast ou multicast ou broadcast. Si ces cas de gures sont tous thoriquement possibles, les implmentations dIPsec ne e e supportent que lunicast. La consquence est importante sur le dploiement e e dIPsec, il est eectu point ` point plutt que gnralis pour tout un e a o e e e rseau. e
11 12

181

Voir page 250 pour le fonctionnement des daemons Rvision possible page 33 e

182 Ce travail est inclus dans ce qui est nomm politique de scurit e e e dans la RFC 2401. Pour AH comme pour ESP, lajout de donnes vient se placer e entre len-tte IP et les donnes. e e Les deux protocoles peuvent tre utie liss ensembles ou sparement, cest e e un choix qui rel`ve de la politique e de scurit. Pour en tenir compte, e e la ngociation qui a lieu lors de e ltablissement dIPsec repose sur ce e que la RFC appelle des SA ( Security Association ). Une SA est formellement un triplet unique constitu dun index e unique , le SPI

e Elments de rseaux e

gure X.04 : En-ttes dIPe sec

Standard IP TCP DATA code=6(tcp) Avec AH IP AH TCP code=51(ah) DATA Donnes authentifies DATA ESP Auth Donnes encryptes authentifies AH + ESP IP AH ESP TCP DATA ESP Auth

Avec ESP

IP ESP TCP code=50(esp)

code=6(tcp) code=50(esp) code=51(ah)

( Security Parameter Index ) sorte de numro didentication IP e 13 supplmentaire inclus dans len-tte AH ou ESP, de ladresse IP du dese e tinataire et du protocole ESP ou dAH. Si les deux protocoles doivent tre e utiliss, il faut ngocier deux SAs. e e Comment utiliser IPsec ? Aux deux protocoles AH et ESP, sajoutent deux mani`res dutiliser IPe sec, soit directement dune machine ` une autre, on parle alors de mode a transport soit encore en lencapsulant dans un tunnel comme vu au paragraphe 2 page 176 et on parle de mode tunnel , plus connu sous le vocable VPN . La RFC 2401 indique que toute implmentation se rclamant dIPsec doit e e supporter les 4 associations qui suivent. La scurit entre deux htes qui e e o supporte IPsec, au travers lInternet, en mode transport ou en mode tunnel. Les datagrammes peuvent avoir les structures suivantes :
Mode transport [IP1][AH][Transport][Data] [IP1][ESP][Transport][Data] [IP1][AH][ESP][Transport][Data]

gure X.05 : Association 1

Internet * H1 * H2

Mode tunnel [IP2][AH][IP1][Transport][Data] [IP2][ESP][IP1][Transport][Data]

13

intranet

intranet

Voir page 45

H=hote *=Supporte IPsec AH et/ou ESP

IPsec et VPN Remarque : En mode tunnel pour ce premier cas il ny a pas dobligation du support dAH et ESP simultanment. Quand ils sont appliqus tous les e e deux, il faut dabord appliquer ESP, puis AH aux datagrammes. gure X.06 : Association 2
Internet * G1 * G2

183

Le mode tunnel est le seul requis ici. Nous avons donc une structure de datagramme qui a ces formes possibles :
Mode tunnel [IP2][AH][IP1][Transport][Data] [IP2][ESP][IP1][Transport][Data]

H1 intranet G=passerelle H=hote *=Supporte IPsec

H2 intranet AH et/ou ESP

Cest la combinaison des deux premiers cas, on ajoute la scurit e e entre les htes terminaux ` celle dj` o a ea apporte par les routeurs. e La propagation du trac de type ISAKMP (protocole IKE) au travers les routeurs est un plus.

gure X.07 : Association 3

* G1 * G2

* H1 intranet Internet

* H2 intranet AH et/ou ESP

G=passerelle H=hote *=Supporte IPsec

gure X.08 : Association 4

Hote isol dialup/ppp * H1 * G1

Internet AH et/ou ESP G=passerelle H=hote *=Supporte IPsec

H2 intranet

Ce dernier cas est celui dun poste isol e qui se raccorde par exemple ` lintranet a de son entreprise via un modem ou un acc`s IP non sr, et qui utilise un protoe u cole non crypt comme AppleTalk, ou e PoP, par exemple. Le mode tunnel est seul requis entre lhte H1 et la passerelle G1. Ensuite, o entre H1 et H2 on revient au premier cas.

184 Implmentation dIPsec e

e Elments de rseaux e

Limplmentation dIPsec sur les machines FreeBSD et NetBSd est issue e du projet KAME14 et est ainsi fortement li au dveloppement de la pile e e IPv6. Les protocoles AH, ESP et IPcomp sont inclus dans le noyau directement. La gestion des clefs seectue via une commande externe, setkey qui pilote une table de gestion des clefs situe elle aussi dans le noyau, grce ` des e a a socket de type PF KEY Les clefs sont soit places de mani`re semi-dnitive dans le chier de e e e conguration dipsec lui-mme (par exemple /etc/ipsec.conf soit cone e e aux bons soins dun programme externe qui se charge de les cre et de les e propager ` laide du protocole IKE. Quelques daemons savent faire cela, noa tamment racoon du projet KAME. Si nous reconsidrons la gure X.03 les machines A et B jouent le rle e o des passerelles G1 et G2 de la gure X.06 (association 2). Les chiers de conguration IPsec pourraient tre : e Sur la machine A
spdadd IP(A) IP(B) any -P out ipsec esp/tunnel/192.168.249.1-192.168.249.2/require; spdadd IP(B) IP(A) any -P in ipsec esp/tunnel/192.168.249.2-192.168.249.1/require;

spdadd est une instruction de la commande setkey. Il faut dnir sa e politique de scurit, cest ` dire ce que lon souhaite en entre (in), en e e a e sortie (out) puis un choix de protocole (esp, ah, ipcomp), un mode (tunnel ici) avec lentre et la sortie du tunnel, enn un niveau dusage (require ici e indique que tous changes doivent utiliser IPsec). e Sur la machine B
spdadd IP(B) IP(A) any -P out ipsec esp/tunnel/192.168.249.2-192.168.249.1/require; spdadd IP(A) IP(B) any -P in ipsec esp/tunnel/192.168.249.1-192.168.249.2/require;

La clef de cryptage ne gure pas dans ce chier car lexemple utilise IKE pour cela, ` laide de loutil racoon. a Enn, un excellent document de conguration se trouve sur le site du projet NetBSD : http ://www.netbsd.org/Documentation/network/ipsec/

14

http ://www.kame.net/

3 Proxy

185

Proxy

gure X.09 : Proxy Le propos dun proxy est de concentrer le trac rseau via une seule e machine pour toute une varit de protocoles (telnet, http, smtp, . . .). Il ee existe des proxy spcialiss sur tel ou tel protocole, qui eectuent donc des e e tches potentiellement tr`s complexes (par exemple squid pour http) ou a e tr`s gnraux et donc moins performants sur chaque protocole (cf nat au e e e paragraphe suivant). Tout le trac rseau qui passe par un proxy sy arrte pour en repartir. Les e e conditions de ce rebond peuvent tre param`tres par des r`gles dacc`s, e e e e e ce qui en fait un lment utile en scurit des rseaux (voir la RFC 1919). ee e e e Section en chantier, prcisions en cours. . . e

Translation dadresses

La pnurie dadresses IP est ` lorigine du besoin de translation des e a adresses. Son principe se trouve dcrit dans la RFC 1631. e Le propos dun automate de translation dadresses est de convertir les adresses IP ` la vole au passage dun interface. a e Dans une conguration classique un tel automate isole un rseau compore tant des adresses IP non ocielles (RFC 1918) dun autre comportant des adresses ocielles et donc potentiellement routes sur lInternet. e
Adresses IP prives if_int 10.33.93.1 Internet A NAT 193.104.1.1 publiques if_ext 193.104.112.163 Adresses IP B

10.33.96.5

gure X.10 : Machine NAT en routeur Dans la gure 10, la machine NAT est par hypoth`se congure en e e routeur. On suppose galement que pour la machine A cest le routeur par e dfaut pour atteindre la machine B. e

186 Pour la machine A

e Elments de rseaux e

La machine A sadresse directement ` la machine 193.104.112.163 en a utilisant son routeur par dfaut. e Lutilisateur de la machine A voit la connexion soit la forme : {tcp, IP Hte A, port A, IP Hte B, port B} o o Pour la machine B La machine B voit une connexion arriver en provenance de NAT . La machine B na pas connaissance de la machine A, elle dialogue avec la machine NAT selon : {tcp, IP Hte B, port B, IP Hte NAT, port A} o o Pour la machine NAT La machine NAT a connaissance des 2 rseaux, elle translate dynamie quement les adresses dans les deux sens. La machine NAT fait le travail dun proxy transparent puisque chaque connexion sy arrte puis en repart sans conguration particuli`re de e e la part de ladministrateur de A ou de B. La translation (ou IP masquerading) seectue dynamiquement selon ladresse demande. e La translation dadresse seectue pour les datagrammes qui traversent linterface if ext. Le dialogue entre cette machine et les autres machines du rseau priv , via linterface if int ne fait pas lobjet e e dune translation dadresse. La situation de la machine A est plutt celle dun poste client car o non vu de lextrieur de son rseau. Etre serveur est toutefois possible e e comme il lest expliqu avec lusage de natd au paragraphe suivant. e Les routeurs modernes ont la fonction de translation dadresses incluse dans leurs fonctionnalits standards. e

Translation dadresse

187

4.1

Cas de NATD

Natd est loutil logiciel libre bien connu des administrateurs rseaux. Il e 15 fonctionne selon le mod`le de la gure 11 . e

Processus

natd

Noyau

6668 Rgles de translation (/etc/natd.conf) Interface plac sous la gestion de natd if_int if_ext

gure 11 : Natd sous FreeBSD Le processus natd ouvre une socket en mode raw pour communiquer directement avec la couche IP : divertInOut = socket (PF INET, SOCK RAW, IPPROTO DIVERT) ; Le noyau IP, muni du mcanisme adquat 16 redirige tout le trac ene e trant et sortant dun interface rseau, vers un numro de port convenu ` la e e a conguration, par exemple le port 6668, ` ajouter dans /etc/services : a natd 6668/divert # Network Address Translation socket Natd lit tous les datagrammes et ne retient pour traitements que ceux qui sont ` destination du port ddi. a e e Compte tenu du chier de conguration, les adresses IP des datagrammes ainsi que les numros de ports sont recrits et reinjects dans le noyau IP qui e e e les traite comme dautres datagrammes (routage, ltrage. . .). Natd convertit les adresses IP ` la vole, un datagramme entrant peut a e ainsi par jeux de recriture tre redirig sur une toute autre machine, sans e e e que son metteur puisse le souponner ! e c On distingue deux attitudes, soit tout le ux entrant est redirig sur une e seule machine, soit il est analys plus nement et la redirection (rsultat de e e la recriture) est eectue en fonction du port, donc du service demand. e e e ` linsu des utilisateurs de La littrature appelle ce cas le static nat. A e la machine NAT du rseau publique, tout le trac IP (cest ainsi quil faut e comprendre ladresse IP 0.0.0.0) est renvoy sur la machine S, et celle-ci e nest pas visible du rseau public. e
Les implmentation commerciales que lon trouve dans les routeurs, si elles ne se e congurent pas de la mme mani`re, ont des proprits tr`s voisines en fonctionnement e e ee e 16 Par exemple pour FreeBSD il faut ajoute loption IPDIVERT dans la conguration du noyau
15

188
Hote accessible

e Elments de rseaux e

Partie prive du rseau NAT IP(S)

Hote distant R

Partie publique du rseau

if_ext S Internet

gure X.12 : Static Nat La conguration du daemon pourrait tre : e natd -interface if ext -redirect address IP(S) 0.0.0.0 La gure 13 nous montre un trac clat en fonction du service demand, e e e ce qui permet une gestion beaucoup ne des ressources du rseau. e Une demande de connexion de lhte distant R sur la machine NAT et o au port 80 va tre rachemine vers la machine interne HTTP et sur le port e e e que lon souhaite, par exemple 8080. Mme remarque pour les deux autres services prsents. e e e La machine HTTP voit la connexion en provenance de la machine R sous sa forme exacte : {tcp, IP Hte R, Port R, IP Hte HTTP, 8080} o o La machine R ne voit que la partie publique de la connexion : {tcp, IP Hte R, Port R, IP Hte NAT, 80} o o La conguration de NAT pourrait ressembler ` : a
# # Configuration multiservices # redirect_port tcp http:8080 80 redirect_port tcp smtp:25 25 redirect_port tcp dns:domain domain redirect_port udp dns:domain domain
Hote accessible

Partie prive du rseau

http NAT

Hote distant R

Partie publique du rseau

smtp

dns

Internet

gure 13 : Conguration multiservices

5 Filtrage IP

189

Filtrage IP

Le propos du ltrage IP est dappliquer des r`gles de ltrage ` un ux de e a datagrammes IP an de prendre une dcision qui est le plus souvent binaire : e laisser passer ou ne pas laisser passer avec en option de conserver une trace de passage (des logs). Par son usage on cherche ` protger un site ou une machine dun ux a e de datagrammes pour lesquels on suspecte que tous ne sont pas envoys par e des utilisateurs bienveillants. Le ltre seorce dliminer le trac indsirable e e ` partir de considrations ` priori, mais il ne reprsente pas la panace en a e a e e mati`re de scurit sur les rseaux, autrement dit il ne faut pas penser quun e e e e ltre IP sut ` r`gler tous les probl`mes de scurit dun site ou dun hte. a e e e e o En eet, ` partir du moment o` le ltre laisse passer certains dataa u grammes, mme ` priori innocents, une porte est ouverte au dtournement e a e de lusage initial du service oert. Dans ces conditions il faut se rendre ` a 17 lvidence : il ny a pas de scurit absolue sur le rseau ! e e e e Dans la littrature, un routeur ltrant est nomm FireWall , quil faut e e traduire en pare-feux . Le ltrage IP est une caractristique essentielle de tout routeur digne de e ce nom ! Il est aussi possible de faire du ltrage IP avec les Unix libres, cest cette approche qui est choisie dans les paragraphes qui suivent parcequaccessible ` toutes les bourses. . . a Si les dtails de mise en uvre di`rent dune implmentation ` une autre, e e e a le fond du probl`me reste le mme. Limplmentation choisie ici est ipfw, le e e e ltre natif de FreeBSD18 . Il existe dautres ltre, notamment ipf, encore une fois le principe reste toujours le mme. e

5.1

Le cas dipfw de FreeBSD

Le ltre IP en question est implment dans le noyau, il est activ e e e d`s lors que loptions IPFIREWALL est ajoute dans le noyau. On peut e e galement y adjoindre loption IPFIREWALL VERBOSE pour le rendre bae vard19 , ce quapprcient par dessus tout les administrateurs rseaux, soucieux e e de tout conna sur la nature du trac. . . tre Le ltre est un module du noyau, charg au dmarrage, et qui se param`tre e e e ` laide de la commande ipfw. Celle-ci est utilise dans les scripts de dmara e e rage pour dicter au noyau les r`gles de ltrage, lues dans un chier nomm e e par defaut /etc/rc.firewall. les scripts de dmarrage pour dicter au noyau e les r`gles de ltrage, e Etablir des r`gles de ltrage IP sous-entend avoir une connaissance exe haustive de tous les lments qui sy rattachent : ee
17 18

Les seuls rseaux srs sont isols du monde extrieur dans une cage de Faraday. . . e u e e http ://www.freebsd.org 19 Via syslogd

190

e Elments de rseaux e Nom des interfaces rseaux impliques e e Protocoles rseaux employs (tcp, udp, icmp,. . .) e e Protocoles applicatifs autoriss (smtp, domain, http. . .) e Adresses IP, numro de ports, masque de sous-rseaux e e Sens du trac par rapport aux interfaces ci-dessus Il est assez ais de mettre en place un ltrage simple, par contre cette e opration peut devenir complexe d`s lors quon utilise des protocoles applie e catifs compliqus, mettant en jeux une stratgie dutilisation des ports et des e e adresses non triviale. Considrons un site simple, comme celui de la gure X.14. e La machine C acc`de depuis lextrieur ` la machine S, protge par e e a e e le ltrage IP activ sur la machine R, qui agit donc comme un routeur e ltrant.

Rseau protg R ipfw

193.104.1.225 193.104.1.228

Rseau publique

Interface ed1

C
193.104.1.1

http dns smtp ntp

Interface ed0

Internet

gure X.14

Adaptons-y les r`gles du mod`le de base, extraites du chier e e /etc/rc.firewall de la conguration standard dune machine FreeBSD rcente (cest un script shell). Lexamen de ces r`gles nous permet de e e dcouvrir la nature du trac autoris ou non. e e

Filtrage IP

191

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51

# Interface externe oif="ed0" onet="193.104.1.0" omask="255.255.255.224" oip="193.104.1.1" # Interface interne iif="ed1" inet="193.104.1.224" imask="255.255.255.224" iip="193.104.1.225" # Ne pas laisser passer le spoofing ipfw add deny all from ${inet}:${imask} to any in via ${oif} ipfw add deny all from ${onet}:${omask} to any in via ${iif} # Ne ipfw ipfw ipfw ipfw ipfw ipfw pas add add add add add add router les adresses de la RFC1918 deny all from 192.168.0.0:255.255.0.0 to any via ${oif} deny all from any to 192.168.0.0:255.255.0.0 via ${oif} deny all from 172.16.0.0:255.240.0.0 to any via ${oif} deny all from any to 172.16.0.0:255.240.0.0 via ${oif} deny all from 10.0.0.0:255.0.0.0 to any via ${oif} deny all from any to 10.0.0.0:255.0.0.0 via ${oif}

# Laisser passer les connexions TCP existantes ipfw add pass tcp from any to any established # Permettre larrivee du courrier SMTP ipfw add pass tcp from any to 193.104.1.228 25 setup # Permettre lacces au serveur HTTP ipfw add pass tcp from any to 193.104.1.228 80 setup # Rejetter et faire des logs de toutes les autres demandes de connexion ipfw add deny log tcp from any to any in via ${oif} setup # Permettre letablissement des autres connexions (via $iif). ipfw add pass tcp from any to any setup # Permettre le trafic UDP/DOMAIN vers/depuis les serveurs DNS externes ipfw add pass udp from any 53 to any 53 # Permettre le trafic NTP vers/depuis les serveurs de dates ipfw add pass udp from any 123 to any 123 # Permettre le passage de tous les paquets ICMP ipfw allow icmp from any to any # Tout ce qui nest pas explicitement autorise est # implicitement interdit ;) ipfw deny ip from any to any

Quelques considrations : e Les r`gles sont parcourues de la premi`re ` la derni`re, si aucune e e a e convient, laction par dfaut consiste ` bloquer le trac (peut tre e a e change). e D`s quune r`gle convient, elle est applique et le ltrage sarrte. e e e e Le ltrage IP consomme des ressources cpu, donc pour amliorer les e performances il vaut mieux placer en tte de liste les r`gles employes e e e le plus couramment. Il faut remarquer que la machine 193.104.1.228 est visible depuis lextrieure et utilise une adresse ociellement route. e e

192

e Elments de rseaux e Une tentative dacc`s sur un service non autoris se traduit par un mese e sage derreur (syslogd). Par exemple supposons que lutilisateur de la station C excute la commande suivante : e telnet 193.104.1.228 Il va obtenir le message :
telnet : Unable to connect to remote host : Connection timed out

Tandis que ladministrateur du rseau 193.104.1.0 va constater la tentae tive dintrusion par le message :
ipfw : 3310 Deny TCP Adr.IP H^te C :2735 193.104.1.228 :23 in via o ed0

Par contre, si lintrusion consiste ` dtourner lusage du service SMTP, a e ladministrateur du rseau 193.104.1.0 ne verra rien par ce biais puisque e lacc`s SMTP est autoris sur la machine 193.104.1.22820 e e

Exemple complet

Dans cette partie nous examinons le cas de la conguration de la gure X.15, synth`se des gures X.12, X.13 et X.14. Cest une conguration tr`s e e employe du fait de la distribution parcimonieuse dadresses IP par les foure nisseurs dacc`s. e
Rseau priv non visible de lextrieur Interface ed1
193.104.1.225 193.104.1.228

Rseau publique NAT R ipfw

193.104.1.1

http dns smtp ntp

Interface ed0

Internet

gure X.15 : Translation dadresse et ltrage IP Le propos est de mettre en place un routeur ltrant eectuant en plus la translation dadresses IP. La juxtaposition des deux services induit peu de changements dans la conguration des r`gles de ltrage. e

20

Toute ressemblance avec la conguration relle de ce rseau ne peut tre que fortuite e e e

Exemple complet Commenons par les r`gles de ltrage : c e

193

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62

# Interface externe oif="ed0" onet="193.104.1.0" omask="255.255.255.224" oip="193.104.1.1" # Interface interne iif="ed1" inet="193.104.1.224 imask="255.255.255.224" iip="193.104.1.225" # # Usage de natd pour transformer tout ce qui passe sur linterface # "ed0" donc le subnet public. ipfw add divert 8668 all from any to any via ${oif} # Ne pas laisser passer le spoofing ipfw add deny all from ${inet}:${imask} to any in via ${oif} ipfw add deny all from ${onet}:${omask} to any in via ${iif} # Ne ipfw ipfw ipfw ipfw ipfw ipfw pas add add add add add add router les adresses de la RFC1918 deny all from 192.168.0.0:255.255.0.0 to any via ${oif} deny all from any to 192.168.0.0:255.255.0.0 via ${oif} deny all from 172.16.0.0:255.240.0.0 to any via ${oif} deny all from any to 172.16.0.0:255.240.0.0 via ${oif} deny all from 10.0.0.0:255.0.0.0 to any via ${oif} deny all from any to 10.0.0.0:255.0.0.0 via ${oif}

# Laisser passer les connexions TCP existantes ipfw add pass tcp from any to any established # Permettre larrivee du courrier SMTP ipfw add pass tcp from any to 193.104.1.228 25 setup # Permettre le trafic TCP/DOMAIN ipfw add pass tcp from any to 193.104.1.228 53 setup # Permettre lacces au serveur HTTP ipfw add pass tcp from any to 193.104.1.228 80 setup # Rejetter et faire des logs de tout autre demande de connexion ipfw add deny log tcp from any to any in via ${oif} setup # Permettre letablissement des autres connexions (via $iif). ipfw add pass tcp from any to any setup # Permettre le trafic UDP/DOMAIN vers/depuis les forwarders ipfw add pass udp from any 53 to 193.104.1.228 53 ipfw add pass udp from 193.104.1.228 53 to any 53 # Permettre le trafic DTP/NTP ipfw add pass udp from any 123 to 193.104.1.228 123 ipfw add pass udp from 193.14.1.228 123 to any 123 # Permettre le passage des paquets ICMP (ping, traceroute...) ipfw add pass icmp from any to any via ${oif} icmptype 0,3,8,11 ipfw add pass udp from any 3276865535 to any 3276865535 out xmit ${oif} ipfw add log icmp from any to any in recv ${oif} ipfw add pass icmp from any to any via ${iif} # Tout ce qui nest pas explicitement autorise est # implicitement interdit ;)

Dans le principe lhte 193.104.1.228 nest plus visible de lextrieur, les o e services sont en apparence hbergs par la machine R qui se charge de e e

194

e Elments de rseaux e re-router les datagrammes en modiant dynamiquement ladresse de destination. Dans lordre des oprations, la translation dadresses est eectue avant e e le ltrage IP. Ce sont donc des adresses IP modies qui sont introduites e dans les r`gles de ltrage ! e Terminons avec la conguration de natd. Voici le contenu du chier /etc/natd.conf pour cette situation :
redirect_port redirect_port redirect_port redirect_port redirect_port tcp tcp tcp udp udp 193.104.1.228:80 80 193.104.1.228:25 25 193.104.1.228:53 53 193.104.1.228:53 53 193.104.1.228:123 123

O` lon sapperoit que la conguration na pratiquement pas chang u c e fondamentalement ormis par lintroduction de la r`gle : e ipfw add divert 6668 all from any to any via ${oif} Qui indique au ltre que tout ce qui provient de linterface oif est ` a lire sur le port 6668, donc a dj` subit la translation dadresse avant dtre ea e soumis au ltrage IP. Ainsi une demande de connexion sur le port 25 de la machine 193.104.1.1 sera transforme en une demande de connexion sur le e port 25 de la machine 193.104.1.228, qui est autoris. e Pour lutilisateur de la station C la machine 193.104.1.228 nest plus visible, seule la machine dadresse 193.104.1.1 semble cumuler tous les services !

7 Bibliographie

195

Bibliographie

RFC 1631 The IP Network Address Translator (NAT). K. Egevang & P. Francis. May 1994. (Format : TXT=22714 bytes) (Status : INFORMATIONAL) RFC 1918 Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J.de Groot & E. Lear. February 1996. (Format : TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also BCP0005) (Status : BEST CURRENT PRACTICE) RFC 1825 Security Architecture for the Internet Protocol. R. Atkinson. August 1995. (Format : TXT=56772 bytes) (Obsoleted by RFC2401) (Status : PROPOSED STANDARD) RFC 2364 PPP Over AAL5. G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens. July 1998. (Format : TXT=23539 bytes) (Status : PROPOSED STANDARD) RFC 2401 Security Architecture for the Internet Protocol. S. Kent, R. Atkinson. November 1998. (Format : TXT=168162 bytes) (Obsoletes RFC1825) (Updated by RFC3168) (Status : PROPOSED STANDARD) RFC 2402 IP Authentication Header. S. Kent, R. Atkinson. November 1998. (Format : TXT=52831 bytes) (Obsoletes RFC1826) (Status : PROPOSED STANDARD) RFC 2406 IP Encapsulating Security Payload (ESP). S. Kent, R. Atkinson. November 1998. (Format : TXT=54202 bytes) (Obsoletes RFC1827) (Status : PROPOSED STANDARD) RFC 2409 The Internet Key Exchange (IKE). D. Harkins, D. Carrel. November 1998. (Format : TXT=94949 bytes) (Status : PROPOSED STANDARD) RFC 2516 A Method for Transmitting PPP Over Ethernet (PPPoE). L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, R. Wheeler. February 1999. (Format : TXT=32537 bytes) (Status : INFORMATIONAL) RFC 3168 The Addition of Explicit Congestion Notication (ECN) to IP. K. Ramakrishnan, S. Floyd, D. Black. September 2001. (Format : TXT=170966 bytes) (Obsoletes RFC2481) (Updates RFC2474, RFC2401, RFC0793) (Status : PROPOSED STANDARD) RFC 1919 Classical versus Transparent IP Proxies. M. Chatel. March 1996. (Format : TXT=87374 bytes) (Status : INFORMATIONAL)

196 Sans oublier :

Protocole TCP

W. Richard Stevens - TCP/IP Illustrated, Volume 1 - The protocols Addison-Wesley Firewalls and Internet Security - William R. Cheswick, Steven M. Bellovin - Addison-Wesley 1994. Building Internet Firewalls - D. Brent Chapman and Elizabeth D. Zwicky - OReilly - 1995. Steven M. Bellovin - Addison-Wesley 1994.

Troisi`me partie e Programmation des sockets de Berkeley

Chapitre XI Gnralits sur les sockets de e e e Berkeley

1 Gnralits e e e

La version BSD 4.1c dUnix pour VAX, en 1982, a t la premi`re ` inclure ee e a TCP/IP dans le noyau du syst`me dexploitation et ` proposer une interface e a 1 de programmation de ces protocoles : les sockets . Les sockets sont ce que lon appelle une API (Application Program Interface) cest ` dire une interface entre les programmes dapplications et la a couche transport, par exemple TCP ou UDP. Nanmoins les sockets ne sont e pas lies ` TCP/IP et peuvent utiliser dautres protocoles comme AppleTalk, e a Xrox XNS, etc. . . e

Application Transport

Programmes applicatifs API = sockets Noyau UNIX

Internet Rseau

Pilotes de priphriques

Matriel

gure XI.01 Les deux principales API pour Unix sont les sockets Berkeley et les TLI System V. Ces deux interfaces ont t dveloppes en C. ee e e Les fonctionnalits des sockets que nous allons dcrire, sont celles appae e rues ` partir de la version 4.3 de BSD Unix, en 1986. Il faut noter que les a
Pour un historique tr`s intressant de cette priode on pourra consulter e e e http ://www.oreillynet.com/pub/a/network/2000/03/17/bsd.html
1

200

Sockets de Berkeley constructeurs de stations de travail comme HP, SUN2 , IBM, SGI, ont adopt e ces sockets, ainsi sont-elles devenues un standard de fait et une justication de leur tude. e Pour conforter ce point de vue il nest pas sans intrt dajouter que ee toutes les applications majeures (named, dhcpd, sendmail, ftpd, serveurs httpd,. . .) de lInternet, et dont lutilisateur peut lire le code source, sont programmes avec de telles sockets. e Enn, et avant dentrer dans le vif du sujet, le schma ci-dessous rappelle e les relations entre pile ARPA, N de port et processus.

Application

Processus utilisateurs

Application

...

Noyau Mcanisme de gestion des ports (session).

...

Transport Internet Rseau

Transport Internet Rseau

gure XI.02

Prsentation des sockets e

Les crateurs des sockets ont essay au maximum de conserver la e e smantique des primitives syst`mes dentres/sorties sur chiers comme open, e e e read, write, et close. Cependant, les mcanismes propres aux oprations e e sur les rseaux les ont conduits ` dvelopper des primitives complmentaires. e a e e Quand un processus ouvre un chier (open), le syst`me place un pointeur e sur les structures internes de donnes correspondantes dans la table des dese cripteurs ouverts de ce processus et renvoie lindice utilis dans cette table. e Par la suite, lutilisateur manipule ce chier uniquement par lintermdiaire e de lindice, aussi nomm descripteur de chier. e Comme pour un chier, chaque socket active est identie par un petit e entier appel descripteur de socket. Unix place ce descripteur dans la mme e e table que les descripteurs de chiers, ainsi une application ne peut-elle pas avoir un descripteur de chier et un descripteur de socket identique.
Les applications de ce constructeur utilisent les TLI, par contre il est possible dutiliser les sockets dans toutes les contributions locales
2

Prsentation des sockets e Pour crer une socket, une application utilisera la primitive socket et e non open, pour les raisons que nous allons examiner. En eet, il serait tr`s agrable si cette interface avec le rseau conservait la smantique des e e e e primitives de gestion du syst`me de chiers sous Unix, malheureusement e les entres/sorties sur rseau mettent en jeux plus de mcanismes que les e e e entres/sorties sur un syst`me de chiers. e e Par exemple, il faut considrer les points suivants : e Dans une relation du type client-serveur les relations ne sont pas symtriques. Dmarrer une telle relation suppose que le programme sait e e quel rle il doit jouer. o Une connexion rseau peut tre du type connect ou non. Dans le pree e e mier cas, une fois la connexion tablie le processus metteur discute e e uniquement avec le processus destinataire. Dans le cas dun mode non connect, un mme processus peut envoyer plusieurs data-grammes ` e e a plusieurs autres processus sur des machines direntes. e Une connexion est dnie par un quintuplet (cf cours TCP page 83) e qui est beaucoup plus compliqu quun simple nom de chier. e Linterface rseau supporte de multiples protocoles comme XNS, APe PLETALK3 , la liste nest pas exhaustive. Un sous syst`me de gestion e de chiers sous Unix ne supporte quun seul format. En conclusion de ce paragraphe on peut dire que le terme socket dsigne, e dune part un ensemble de primitives, on parle des sockets de Berkeley, et dautre part lextrmit dun canal de communication (point de communie e cation) par lequel un processus peut mettre ou recevoir des donnes. Ce e e point de communication est reprsent par une variable enti`re, similaire ` e e e a un descripteur de chier.

201

Linspection du chier /usr/include/sys/socket.h sous Unix en explicite une trentaine

202

Sockets de Berkeley

Etude des primitives

Ce chapitre est consacr ` une prsentation des primitives de base pour ea e programmer des applications en rseaux. Pour tre bien complet il est fore e tement souhaitable de doubler sa lecture avec celle des pages de man correspondantes.

Cration dune socket e

La cration e #include #include #include dune socket se fait <sys/types.h> <sys/socket.h> <netinet/in.h> par lappel syst`me socket. e /* Pour toutes les primitives */ /* de ce chapitre il faut */ /* inclure ces fichiers. */

int socket(int PF, int TYPE, int PROTOCOL) ;

PF Spcie la famille de protocole (Protocol Family) ` utiliser avec la e a socket. Sur tout syst`me qui permet lusage des sockets, on doit trouver e au moins les familles : PF PF PF PF PF PF PF INET INET6 CCITT LOCAL UNIX ROUTE KEY : : : : : : : Pour les sockets IPv4 Pour les sockets IPv6 Pour linterface avec X25 Pour rester en mode local (pipe). . . Idem AF LOCAL Acc`s ` la table de routage e a Acc`s ` une table de clefs (IPsec) e a

Mais il existe dautres implmentations notamment avec les protocoles : e PF APPLETALK PF NS PF ISO PF SNA PF IPX ... : : : : : : Pour les rseaux Apple e Pour le protocole Xerox NS Pour le protocole de lOSI Pour le protocole SNA dIBM Protocole Internet de Novell ...

Le prxe PF est la contraction de Protocol Family On peut e galement utiliser le prxe AF, pour Address Family. Les deux e e nommages sont possibles ; lquivalence est dnie dans le chier dene e tte socket.h. e TYPE Cet argument spcie le type de communication dsir. En fait avec e e e la famille PF INET, le type permet de faire le choix entre un mode connect, un mode non connect ou une intervention directe dans la e e couche IP :

4 Cration dune socket e SOCK STREAM SOCK DGRAM SOCK RAW : Mode connect e Couche transport : Mode non connect e Idem : Dialogue direct avec la couche IP

203

Faut-il reprciser que seules les sockets en mode connect permettent e e les liaisons full-duplex. PROTOCOL Ce troisi`me argument permet de spcier le protocole ` utie e a liser. Il peut tre du type UDP ou TCP sous Unix. e IPPROTO TCP IPPROTO UDP IPPROTO RAW, IPPROTO ICMP : TCP : UDP : uniquement avec SOCK RAW

PROTOCOL est typiquement mis ` zro car lassociation de la famille de a e protocole et du type de communication dnit explicitement le protoe cole de transport : PF INET + SOCK STREAM PF INET + SOCK DGRAM = = TCP = IPPROTO TCP UDP = IPPROTO UDP

La primitive socket retourne un entier qui est le descripteur de la socket nouvellement cre par cet appel. ee Par rapport ` la connexion future cette primitive ne fait que donner le a premier lment du quintuplet : ee {protocole, port local, adresse locale, port loign, adresse loigne} e e e e Si la primitive renvoie -1, la variable globale errno donne lindice du message derreur idoine dans la table sys errlist, que la biblioth`que standard e sait parfaitement exploiter 4 . Remarque importante : Comme pour les entres/sorties sur chiers, un appel syst`me fork due e plique la table des descripteurs de chiers ouverts du processus p`re dans le e processus ls. Ainsi les descripteurs de sockets sont galement transmis. e Le bon usage du descripteur de socket partag entre les deux processus e incombe donc ` la responsabilit du programmeur. a e Enn, quand un processus a ni dutiliser une socket il appelle la primitive close avec en argument le descripteur de la socket :
close(descripteur de socket) ;

Si un processus ayant ouvert des sockets vient ` sinterrompre pour une a raison quelconque, en interne la socket est ferme et si plus aucun processus e na de descripteur ouvert sur elle, le noyau la supprime.
4

cf la page de manuel de perror(3)

204

Sockets de Berkeley

Spcication dune adresse e

Il faut remarquer quune socket est cre sans adresse de lmetteur ni ee e celle du destinataire. Pour les protocoles de lInternet cela signie que la cration dune socket e est indpendante dun numro de port. e e Dans beaucoup dapplications, surtout des clients, on a pas besoin de sinquiter du numro de port, le protocole sous-jacent soccupe de choisir e e un numro de port pour lapplication. e Cependant un serveur qui fonctionne suivant un numro de port bien e connu doit tre capable de spcier un numro de port bien prcis. e e e e Une fois que la socket est cre, la primitive bind permet deectuer ce ee travail, cest ` dire dassocier une adresse IP et un numro de port ` une a e a socket :
int bind(int sockfd, struct sockaddr *myaddr, socklen t addrlen) ;

socket Est le descripteur de la socket, renvoy par socket. e myaddr Est une structure qui spcie ladresse locale avec laquelle bind doit e travailler. addrlen Est un entier qui donne la longueur de ladresse, en octets. La description de ladresse change dune famille de protocole (cf socket) ` une autre, cest pourquoi les concepteurs ont choisi de passer en argument a une structure plutot quun entier. Cette structure gnrique, est nomme e e e gnralement sockaddr. e e Elle commence gnralement par deux octets qui rappellent la famille de e e protocole, suivis de 14 octets qui dnissent ladresse en elle-mme : e e
struct sockaddr { unsigned short sa_family ; char sa_data[14] ; } ;

Pour la famille PF INET cette structure se nomme sockaddr in, elle est dnie de la faon suivante : e c
struct sockaddr_in { short sin_family ; /* PF_INET */ unsigned short sin_port ; /* No de port. */ struct in_addr sin_addr ; /* 32 bits. */ char sin_zero[8] ; /* Inutilises. */ } ; struct in_addr { unsigned long s_addr ; /* 32b Internet */ } ;

6 Connexion ` une adresse distante a

205

struct sockaddr sa_family sa_data

struct sockaddr_in sin_family sin_port sin_addr 16 octets

sin_zero

La structure gnrale

La structure pour pile ARPA

gure XI.03 La primitive bind ne permet pas toutes les associations de numros de e port, par exemple si un numro de port est dj` utilis par un autre processus, e ea e ou si ladresse Internet est invalide. Il y a trois utilisations de la primitive : 1. En gnral les serveurs ont des numros de port bien connus du syst`me e e e e (cf /etc/services. Bind dit au syst`me cest mon adresse, tout mese sage reu ` cette adresse doit mtre renvoy. Que cela soit en mode c a e e connect ou non, les serveurs ont besoin de le dire avant de pouvoir e accepter les connexions. 2. Un client peut prciser sa propre adresse, en mode connect ou non. e e 3. Un client en mode non connect a besoin que le syst`me lui assigne e e une adresse particuli`re, ce qui autorise lusage des primitives read et e write traditionnellement ddies au mode connect. e e e Bind retourne 0 si tout va bien, -1 si une erreur est intervenue. Dans ce cas la variable globale errno est positionne ` la bonne valeur. e a Cet appel syst`me compl`te ladresse locale et le numro de port du quine e e tuplet qui qualie une connexion. Avec bind+socket on a la moiti dune e connexion, ` savoir un protocole, un numro de port et une adresse IP : a e {protocole, port local, adresse locale, port loign, adresse loigne} e e e e

Connexion ` une adresse distante a

Linitiative de la demande de connexion est typiquement la proccupation e dun processus client. Quand une socket est cre, elle nest pas associe avec une quelconque ee e destination. Cest la primitive connect qui permet dtablir la connexion, si e le programmeur choisit un mode de fonctionnement connect, sinon elle e nest pas tr`s utile (voir plus loin). e

206

Sockets de Berkeley Pour les protocoles orients connexion, cet appel syst`me rend la main e e au code utilisateur une fois que la liaison entre les deux syst`mes est tablie. e e Durant cette phase des messages sont changs ; les deux syst`mes changent e e e e des informations sur les caractristiques de la liaison future (cf cours TCP e page 83). Tant que cette liaison nest pas dnie au niveau de la couche de transport, e la primitive connect ne rend pas la main. Dans le cas ou une impossibilit e se prsente elle retourne -1 et positionne errno ` la bonne valeur. Dans le e a cas ou tout va bien elle retourne 0. Les clients nont pas besoin de faire appel ` la primitive bind avant a dinvoquer connect car la connexion renseigne dun coup les lments qui ee manquent. Dans le cas dun client en mode non connect un appel ` connect nest e a pas faux mais il ne sert ` rien et redonne aussitt la main au code utilisateur. a o Le seul intrt que lon peut voir est que ladresse du destinataire est xe ee e et que lon peut alors utiliser les primitives read, write, recv et send, traditionnellement rserves au mode connect. e e e La primitive connect a le prototype suivant :
int connect(int sockfd,const struct sockaddr *servaddr,socklen t addrlen) ;

sockfd Est le descripteur de socket renvoy par la primitive socket. e servaddr est une structure qui dnit ladresse du destinataire, la mme e e structure que pour bind. addrlen Donne la longueur de ladresse, en octets. Le quintuplet est maintenant complet : {protocole, port local, adresse locale, port loign, adresse loigne} e e e e

Envoyer des donnes e

Une fois quun programme dapplication a cr une socket, il peut lutiliser ee pour transmettre des donnes. Il y a cinq primitives possibles pour ce faire : e send, write, writev, sendto, sendmsg Send, write et writev fonctionnent uniquement en mode connect, e parce-quelles norent pas la possibilit de prciser ladresse du destinataire. e e Les dirences entre ces trois primitives sont mineures. e
ssize t write(int descripteur, const void *buffer, size t longueur) ;

Quand on utilise write, le descripteur dsigne lentier renvoy par la e e primitive socket. Le buffer contient les octets ` transmettre, et longueur a leur cardinal.

Envoyer des donnes e Tous les octets ne sont pas forcment transmis dun seul coup, et ce nest e pas une condition derreur. En consquence il est absolument ncessaire de e e tenir compte de la valeur de retour de cette primitive, ngative ou non. e La primitive writev est sensiblement la mme que write simplement elle e permet denvoyer un tableau de structures du type iovec plutot quun simple buer, largument vectorlen spcie le nombre dentres dans iovector : e e
ssize t writev(int descriptor, const struct iovec *iovector, int vectorlen) ;

207

La primitive send ` la forme suivante : a

int send(int s, const void *msg, size t len, int flags) ;

s Dsigne lentier renvoy par la primitive socket. e e msg Donne ladresse du dbut de la suite doctets ` transmettre. e a len Spcie le nombre de ces octets. e flags Ce drapeau permet de param`trer la transmission du data-gramme, e notamment si le buer dcriture est plein ou si lon dsire, par exemple e e et avec TCP, faire un envoi en urgence (out-of-band) : 0 MSG OOB MSG PEEK : Non oprant, cest le cas le plus courant. e : Pour envoyer ou recevoir des messages out-of-band. : Permet daller voir quel message on a reu sans le lire, c cest ` dire sans quil soit eectivement retir des buers a e internes (ne sapplique qu` recv (page 208). a

Les deux autres primitives, sendto et sendmsg donnent la possibilit e denvoyer un message via une socket en mode non connect. Toutes deux e rclament que lon spcie le destinataire ` chaque appel. e e a
ssize t sendto(int s,const void *msg,size t len,int flags, const struct sockaddr *to, socklen t tolen) ;

Les quatre premiers arguments sont exactement les mmes que pour send, e les deux derniers permettent de spcier une adresse et sa longueur avec une e structure du type sockaddr, comme vu prcdemment avec bind. e e Le programmeur soucieux davoir un code plus lisible pourra utiliser la deuxi`me primitive : e
ssize t sendmsg(int sockfd, const struct msghdr *messagestruct,int flags) ;

O` messagestruct dsigne une structure contenant le message ` envoyer u e a sa longueur, ladresse du destinataire et sa longueur. Cette primitive est tr`s e commode ` employer avec son pendant recvmsg car elle travaille avec la a mme structure. e

208

Sockets de Berkeley

Recevoir des donnes e

Symtriquement aux cinq primitives denvoi, il existe cinq primitives de e rception : read, readv, recv, recvfrom, recvmsg. e La forme conventionnelle read dUnix nest possible quavec des sockets en mode connect car son retour dans le code utilisateur ne saccompagne e daucune prcision quant ` ladresse de lmetteur. Sa forme dutilisation est : e a e

ssize t read(int descripteur, void *buffer,size t longueur) ;

Bien sur, si cette primitive est utilise avec les sockets BSD, le descripteur e est lentier renvoy par un appel prcdent ` la primitive socket. buffer et e e e a longueur spcie respectivement le buer de lecture et la longueur de ce que e lon accepte de lire. Chaque lecture ne renvoie pas forcment le nombre doctets demands, e e mais peut tre un nombre infrieur. e e Mais le programmeur peut aussi employer le readv, avec la forme :
ssize t readv(int descripteur, const struct iovec *iov, int vectorlen) ;

Avec les mme caractristiques que pour le readv. e e En addition aux deux primitives conventionnelles, il y a trois primitives nouvelles pour lire des messages sur le rseau : e
ssize t recv(int s, void *buf, size t len, int flags) ;

s Lentier qui dsigne la socket. e buf Une adresse o` lon peut crire, en mmoire. u e e len La longueur du buer. flags Permet au lecteur deectuer un contrle sur les paquets lus. o
ssize t recvfrom(int s, void *buf,size t len, int flags,struct sockaddr *from, socklen t *fromlen) ;

Les deux arguments additionnels par rapport ` recv sont des pointeurs a vers une structure de type sockaddr et sa longueur. Le premier contient ladresse de lmetteur. Notons que la primitive sendto fournit une adresse e dans le mme format, ce qui facilite les rponses. e e La derni`re primitive recvmsg est faite pour fonctionner avec son homoe logue sendmsg :
ssize t recvmsg(int sockfd, struct msghdr *messagestruct,int flags) ;

La structure messagestruct est exactement la mme que pour sendmsg e ainsi ces deux primitives sont faites pour fonctionner de paire.

9 Spcier une le dattente e

209

Spcier une le dattente e

Imaginons un serveur en train de rpondre ` un client, si une requte e a e arrive dun autre client, le serveur tant occup, la requte nest pas prise en e e e compte, et le syst`me refuse la connexion. e La primitive listen est l` pour permettre la mise en le dattente des a demandes de connexions. Elle est gnralement utilise apr`s les appels de socket et de bind et e e e e immdiatement avant le accept. e
int listen(int sockfd, int backlog) ;

sockfd lentier qui dcrit la socket. e backlog Le nombre de connexions possibles en attente (quelques dizaines). La valeur maximale est fonction du param`trage du noyau. Sous e FreeBSD la valeur maximale par dfaut est de 128 (sans param`trage e e spcique du noyau), alors que sous Solaris 9, There is currently no e backlog limit . Le nombre de fois o` le noyau refuse une connexion est comptabiu lis et accessible au niveau de la ligne de commande via le rsultat e e de lexcution de la commande netstat -s -p tcp (chercher listen e queue overow ). Ce param`tre est important ` suivre dans le cas dun e a serveur tr`s sollicit. e e

10

Accepter une connexion

Comme nous lavons vu un serveur utilise les primitives socket, bind et listen pour se prparer ` recevoir les connexions. Il manque cependant e a ` ce trio le moyen de dire au protocole jaccepte dsormais les connexions a e entrantes. Ce moyen existe, il passe par lusage de la primitive accept. Quand le serveur invoque cette primitive il se met en attente bloquante dune connexion, la forme de la primitive est :
int accept(int sockfd, struct sockaddr *addr, socklen t *addrlen) ;

Qui sutilise comme suit :

int newsock ; newsock = accept(sockfd, addr, addrlen) ;

sockfd descripteur de la socket, renvoy par la primitive du mme nom. e e addr Un pointeur sur une structure du type sockaddr. addlen Un pointeur sur un entier.

210

Sockets de Berkeley Quand une connexion arrive, les couches sous-jacentes du protocole de transport remplissent la structure addr avec ladresse du client qui fait la demande de connexion. Addrlen contient alors la longueur de ladresse. Puis le syst`me cre une nouvelle socket dont il renvoie le descripteur, e e rcupr ici dans newsock. Ainsi la socket originale reste disponible pour e ee dventuelles autres connexions. e Donc, quand une connexion arrive, lappel ` la primitive accept retourne a dans le code utilisateur.

11

Terminer une connexion

Dans le cas du mode connect on termine une connexion avec la primitive e close ou shutdown.
int close(descripteur) ;

La primitive bien connue sous Unix peut tre aussi employe avec un dese e cripteur de socket. Si cette derni`re est en mode connect, le syst`me assure e e e que tous les octets en attente de transmission seront eectivement transmis dans de bonnes conditions. Normalement cet appel retourne immdiatement, e cependant le kernel peut attendre le temps de la transmission des derniers octets (transparent). Le moyen le plus classique de terminer une connexion est de passer par la primitive close, mais la primitive shutdown permet un plus grand contrle o sur les connexions en full-duplex.
int shutdown(int sockfd, int how) ;

Sockfd est le descripteur ` fermer, how permet de fermer partiellement le a descripteur suivant les valeurs quil prend : 0 Aucune donne ne peut plus tre reue par la socket. e e c 1 Aucune donne ne peut plus tre mise. e e e 2 Combinaison de 0 et de 1 (quivalent de close). e Enn, pour une socket en mode connect, si un processus est interrompu e de mani`re inopine (rception dun signal de n par exemple), un reset e e e (voir page 86) est envoy ` lhte distant ce qui provoque la n brutale de la ea o connexion. Les octets ventuellement en attente sont perdus. e

12 Schma gnral dune connexion e e e

211

12

Schma gnral dune connexion e e e

Il est temps pour nous de donner un aperu de la structure dun serveur et c dun client, puisque cest ainsi que nous appelerons dsormais les destinataire e et metteur. e Schma dune relation clientserveur en mode connect : e e
Serveur
fd=socket() bind(fd) listen(fd) fd=socket() fd2=accept(fd) Etablissement de la connexion write(fd) read(fd2) changes applicatifs write(fd2) read(fd) connect(fd)

Client

Fermeture de la close(fd2) connexion close(fd)

gure XI.04 Schma dune relation clientserveur en mode non connect : e e

Serveur
fd=socket() fd=socket() bind(fd) bind(fd) sendto(fd) recvfrom(fd) changes applicatifs sendto(fd) recvfrom(fd)

Client

close(fd)

close(fd)

gure XI.05

212

Sockets de Berkeley

13

Exemples de code client

Lobjectif de ces deux exemples est de montrer le codage en C et le fonctionnement dun client du serveur de date (RFC 867, daytime protocol ) prsent sur toute machine unix5 . e Ce serveur fonctionne en mode connect ou non, sur le port 13 qui lui est e rserv (/etc/services). Ici le serveur est une machine portant ladresse IP e e 192.168.52.232. La connaissance de ladresse IP du client nest absolument pas utile pour la comprhension de lexemple. e En mode TCP le simple fait de se connecter provoque lmission de la e cha ascii contenant la date vers le client et sa dconnexion. ne e En mode UDP il sut denvoyer un datagramme quelconque (1 caract`re) e au serveur puis dattendre sa rponse. e

13.1

Client TCP DTCPcli

Exemple dusage :
$ ./DTCPcli 192.168.52.232 Date(192.168.52.232) = Wed Dec 10 20:59:46 2003

Une capture des trames rseau changes lors de lexcution de cette e e e e commande se trouve page 215. ligne 28 Dclaration de la structure saddr du type sockaddr in, ` utiliser e a avec IPv4. Attention, il sagit bien dune structure et non dun pointeur de structure. ligne 34 La variable sfd, reoit la valeur du descripteur de socket. Celle-ci c est ddie au protocole TCP. e e ligne 38 Le champ sin family de la structure saddr indique que ce qui suit (dans la structure) concerne IPv4. ligne 39 Le champ sin port est aect ` la valeur du numro de port sur ea e lequel coute le serveur. Il faut remarquer lusage de la fonction htons e (en fait une macro du pr-processeur cpp) qui sassure que ce numro e e de port respecte bien le NBO ( network Byte Order ), car cette valeur est directement recopie dans le champ PORT DESTINATION e du protocole de transport employ (voir page 78 pour UDP et page 85 e pour TCP). Nous en dirons plus sur htons au chapitre suivant. Si le processeur courant est du type little endian (architecture Intel par exemple) les octets sont inverss (le NBO est du type big ene dian ). Vous croyez crire 13 alors quen ralit pour le rseau vous e e e e avez crit 3328 (0x0D00) ce qui bien videment ne conduit pas au mme e e e rsultat, sauf si un serveur de date coute galement sur le port 3328, e e e ce qui est tr`s peu probable car non conventionnel. e
5

Son activation est ventuellement ` faire ` partir du serveur de serveur inetd, page 255 e a a

13 Exemples de code client En rsum, si le programmeur nutilise pas la fonction htons, ce code e e nest utilisable que sur les machines darchitecture big endian .
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

213

/* $Id: DTCPcli.c,v 1.1 2002/11/24 16:52:50 fla Exp $ * * Client TCP pour se connecter au serveur de date (port 13 RFC 867). * La syntaxe dutilisation est : DTCPcli <adresse ip sous forme dcimale> * */ #include #include #include #include #include #include #include #include #include #define #define #define <stdio.h> <string.h> <unistd.h> <sysexits.h> <sys/types.h> <sys/socket.h> <sys/param.h> <netinet/in.h> <arpa/inet.h> USAGE MAXMSG NPORT "Usage:%s adresse_du_serveur\n" 1024 13

int main(int argc, char *argv[]) { int n, sfd ; char buf[MAXMSG] ; struct sockaddr_in saddr ; if (argc != 2) { (void)fprintf(stderr,USAGE,argv[0]) ; exit(EX_USAGE) ; } if ((sfd = socket(PF_INET,SOCK_STREAM,IPPROTO_TCP)) < 0) { perror("socket") ; exit(EX_OSERR) ; } saddr.sin_family = AF_INET ; saddr.sin_port = htons(NPORT) ; /* Attention au NBO ! saddr.sin_addr.s_addr = inet_addr(argv[1]) ; if (connect(sfd,(struct sockaddr *)&saddr,sizeof saddr) < 0) { perror("connect") ; exit(EX_OSERR) ; } if ((n = read(sfd, buf,MAXMSG1)) < 0) { perror("read") ; exit(EX_OSERR) ; } buf[n] = \0 ; (void)printf("Date(%s) = %s\n",argv[1],buf) ; exit(EX_OK) ; }

*/

/* close(sfd) implicite */

DTCPcli.c ligne 40 Le champ s addr de la structure sin addr se voit aect de e ladresse IP. Cest donc lcriture de quatre octets (IPv4), pouvant come porter un caract`re ascii 0, donc interprtable comme le caract`re de e e e n de cha du langage C. ne

214

Sockets de Berkeley Cest pourquoi ` cet endroit on ne peut pas employer les habituelles a fonctions de la biblioth`que standard (celles qui commencent par str). e Ici le probl`me se complique un peu dans la mesure o` lon dispose au e u dpart dune adresse IP sous sa forme dcimale pointe. e e e La fonction inet addr g`re parfaitement ce cas de gure. Nous en e dirons plus ` son sujet au chapitre suivant. a ligne 41 Appel ` la primitive connect pour tablir la connexion avec le a e serveur distant. Quand celle-ci retourne dans le code du programme, soit la connexion a chou et il faut traiter lerreur, soit la connexion e e est tablie. Lchange prliminaire des trois paquets sest eectu dans e e e e de bonnes conditions (page 88). Du point de vue TCP, les cinq lment du quintuplet qui caractrise la ee e connexion sont dnis (page ??). e Sur la capture des paquets de la page 215 nous sommes arrivs ` la e a ligne 6, cest ` dire lenvoi de lacquittement par le client du paquet de a synchronisation envoy par le serveur (ligne 3 et 4). e Il faut noter que bien que nous ayons transmis la structure saddr par adresse (caract`re &) et non par valeur, la primitive connect ne modie e pas son contenu pour autant. Notons galement lusage du cast du C pour forcer le type du e pointeur (le prototype de la primitive exige ` cet endroit un pointeur a de type sockaddr). ligne 45 Appel ` la primitive read pour lire le rsultat en provenance du a e serveur, ` laide du descripteur sfd. a Sur la capture dcran on voit ligne 8 (et 9) lenvoi de la date en proe venance du serveur, dune longueur de 26 caract`res. e Ce nombre de caract`res eectivement lus est aect ` la variable n. e ea Ce nombre ne peut excder le rsultat de lvaluation de e e e M AXM SG 1, qui correspond ` la taille du buer buf moins 1 a caract`re prvu pour ajouter le caract`re 0 de n de cha e e e ne. En eet, celui-ci fait partie de la convention de reprsentation des e cha nes de caract`res du langage C. Rien ne dit que le serveur qui e rpond ajoute un tel caract`re ` la n de sa rponse. Le contraire est e e a e mme certain puisque la RFC 867 ny fait pas mention. e Remarque : le buer buf est largement surdimensionn compte tenu e de la rponse attendue. La RFC 867 ne prvoit pas de taille maximum e e si ce nest implicitement celle de lexpression de la date du syst`me en e anglais, une quarantaine doctets au maximum. ligne 49 Ajout du caract`re de n de cha en utilisant le nombre de cae ne ract`res renvoys par read. e e ligne 52 La sortie du programme induit une clture de la socket cot client. o e Cot serveur elle est dj` ferme (squence write + close) comme on e ea e e peut le voir ligne 8 (ag FP, page 86) ci-apr`s dans la capture du trac e entre le client et le serveur.

13 Exemples de code client Remarque : rien nest explicitement prvu dans le code pour tablir la e e socket cot client, ` savoir lassociation dun numro de port et dune adresse e a e IP. En fait cest la primitive connect qui sen charge. Ladresse IP est celle de la machine. Le numro de port est choisi dans la zone dattribution autoe matique comme nous lavons examin page 79. e Il existe bien entendu une possibilit pour le programme davoir connaise sance de cette information : la primitive getsockname.
23:03:29.465183 client.2769 > serveur.daytime: S 2381636173:2381636173(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 299093825 0> (DF) 23:03:29.465361 serveur.daytime > client.2769: S 3179731077:3179731077(0) ack 2381636174 win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 4133222 299093825> (DF) 23:03:29.465397 client.2769 > serveur.daytime: . ack 1 win 57920 <nop,nop,timestamp 299093826 4133222> (DF) 23:03:29.466853 serveur.daytime > client.2769: FP 1:27(26) ack 1 win 57920 <nop,nop,timestamp 4133223 299093826> (DF) 23:03:29.466871 client.2769 > serveur.daytime: . ack 28 win 57894 <nop,nop,timestamp 299093826 4133223> (DF) 23:03:29.467146 client.2769 > serveur.daytime: F 1:1(0) ack 28 win 57920 <nop,nop,timestamp 299093826 4133223> (DF) 23:03:29.467296 serveur.daytime > client.2769: . ack 2 win 57920 <nop,nop,timestamp 4133223 299093826> (DF)

215

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Trac client-serveur TCP, captur avec tcpdump e

13.2

Client UDP DUDPcli

Exemple dusage :
$ ./DUDPcli 192.168.52.232 Date(192.168.52.232) = Wed Dec 10 20:56:58 2003

ligne 33 Ouvertude dune socket UDP, donc en mode non connect. e ligne 41 Envoit dun caract`re (NULL) au serveur, sans quoi il na aucun e moyen de conna notre existence. tre ligne 37, 38 et 39 Le remplissage de la structure saddr est identique ` a celui de la version TCP. ligne 45 Rception de caract`res en provenance du rseau. e e e Il faut remarquer que rien nassure que les octets lus sont bien en provenance du serveur de date interrog. e Nous aurions pu utiliser la primitive recvfrom dont un des arguments est une structure dadresse contenant justement ladresse de la socket qui envoie le datagramme (ici la rponse du serveur). e Le raisonnement sur la taille du buer est identique ` celui de la version a TCP. La capture de trames suivante montre lextrme simplicit de lchange e e e en comparaison avec celle de la version utilisant TCP !

216
1 2

Sockets de Berkeley
23:23:17.668689 client.4222 > serveur.daytime: udp 1 23:23:17.670175 serveur.daytime > client.4222: udp 26

Trac client-serveur UDP, captur avec tcpdump e

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

/* $Id: DUDPcli.c,v 1.1 2002/11/24 16:52:50 fla Exp $ * * Client UDP pour se connecter au serveur de date (port 13 RFC 867). * La syntaxe dutilisation est : DUDPcli <adresse ip sous forme dcimale> * */ #include <stdio.h> #include <string.h> #include <unistd.h> #include <sysexits.h> #include #include #include #include #include #define #define #define <sys/types.h> <sys/socket.h> <sys/param.h> <netinet/in.h> <arpa/inet.h> USAGE MAXMSG NPORT "Usage:%s adresse_du_serveur\n" 1024 13

int main(int argc, char *argv[]) { int n, sfd ; char buf[MAXMSG] ; struct sockaddr_in saddr ; if (argc != 2) { (void)fprintf(stderr,USAGE,argv[0]) ; exit(EX_USAGE) ; } if ((sfd = socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP)) < 0) { perror("socket") ; exit(EX_OSERR) ; } saddr.sin_family = AF_INET ; saddr.sin_port = htons(NPORT) ; /* Attention au NBO ! */ saddr.sin_addr.s_addr = inet_addr(argv[1]) ; buf[0] = \0 ; if (sendto(sfd,buf,1,0,(struct sockaddr *)&saddr, sizeof saddr) != 1) { perror("sendto") ; exit(EX_OSERR) ; } if ((n=recv(sfd,buf,MAXMSG1,0)) < 0) { perror("recv") ; exit(EX_OSERR) ; } buf[n] = \0 ; (void)printf("Date(%s) = %s\n",argv[1],buf) ; exit(EX_OK) ; } /* close(sfd) implicite */

DUDPcli.c

14 Conclusion et Bibliographie

217

14

Conclusion et Bibliographie
Protocole Adresses locale Adresse loigne e e et N de port. et N de port. bind listen, accept connect bind recvfrom bind sendto

En conclusion on peut tablir le tableau suivant : e

Serveur orient connexion e Client orient connexion e Serveur non orient connexion e Client non orient connexion e

socket socket socket socket

Concernant les exemples de code client, consulter cette RFC : RFC 867 Daytime Protocol . J. Postel. May-01-1983. (Format : TXT=2405 bytes) (Also STD0025) (Status : STANDARD) Pour en savoir davantage, outre les pages de man des primitives cites e dans ce chapitre, on pourra consulter les documents de rfrence suivants : ee Stuart Sechrest An Introductory 4.4BSD Interprocess Communication Tutorial Re imprim dans Programmers Supplementary e Documents OReilly & Associates, Inc. 19946 W. Richard Stevens Unix Network Programming Prentice All 1990 W. Richard Stevens Unix Network Programming Second edition Prentice All 1998 Douglas E. Comer David L. Stevens Internetworking with TCP/IP Volume III (BSD Socket version) Prentice All 1993 Stephen A. Rago Unix System V Network Programming AddisonWesley 1993 Et pour aller plus loin dans la comprhension des mcanismes internes : e e W. Richard Stevens TCP/IP Illustrated Volume 2 Prentice All 1995 McKusick Bostic Karels Quaterman The Design and implementation of the 4.4 BSD Operating System AddisonWesley 1996

On peut galement e trouver ce document dans /usr/share/doc/psd/20.ipctut/ des OS dinspiration Berkeley 4.4

le

rpertoire e

218

Sockets de Berkeley

Chapitre XII Complments sur les sockets e Berkeley

1 Rservation des ports e

Au chapitre prcdent nous avons utilis la primitive bind pour assigner e e e une adresse ` une socket, dans ce paragraphe nous prcisons comment choisir a e le numro de port qui va bien, selon le type dapplication envisag. Nous avons e e dj` examin ce point dans les grandes lignes page 79. ea e Il y a deux mani`res dassigner un N de port ` une socket : e a 1. Le processus spcie le numro. Cest typiquement ce que fait un sere e veur. On suppose bien videment que les clients sont au courant ou e quils disposent dun mcanisme qui peut les renseigner (cf cours sur e les RPC). 2. Le processus laisse le syst`me lui assigner automatiquement un numro e e de port. Cest typiquement ce que fait un client, sauf cas contraire exig e par le protocole dapplication (cf cours sur les remote execution). En r`gle gnrale le dveloppeur dapplication ne sattribue pas au hasard e e e e un (ou plus) numro de port. Il doit respecter quelques contraintes comme e ne pas utiliser les ports dj` attribus. Ceux-ci gurent dans une RFC parea e ticuli`re. La derni`re en date est la RFC 1700 [Reynolds & Postel 1994]) e e au paragraphe WELL KNOWN PORT NUMBERS. Plus simplement, sur toute machine Unix ` jour, une liste de ces ports se trouve dans le chier a 1 /etc/services . Cod sur deux octets non signs, le numro de port permet 65536 possibie e e lits de 0 ` 65535. Cette chelle est fragmente de deux mani`res, lancienne e a e e e ou la nouvelle mthode. Toutes les applications sur tous les syst`mes dexe e ploitation nont pas encore adopt la nouvelle approche, les deux vont donc e cohabiter un certain temps, ne serait-ce qu` cause de vieilles applications a non mises ` jour. a
http ://www.iana.org/assignments/port-numbers pour se tenir au courant des volutions de cette liste e
1

220

Complments sur les sockets Berkeley e

1.1

Rservation de port Ancienne mthode e e

Port N 0 Ce numro nest pas utilisable pour une application, cest une e sorte de jocker qui indique au syst`me que cest ` lui de complter e a e automatiquement le numro (voir plus loin de 1024 ` 5000). e a Port de 1 ` 255 Pour utiliser cette zone il faut avoir les droits du root ` a a lexcution pour que le bind ne retourne pas une erreur. Les serveurs e classiques (domain, ftp, smtp, telnet, ...) se situent tous dans cette partie. Ports de 256 ` 511 Jadis considr comme une rserve des serveurs oa ee e ciels commencent ` sy installer, faute de place dans la zone prcdente. a e e Il faut galement avoir les droits du root pour utiliser un numro de e e port dans cette zone. Port de 512 ` 1023 Une fonction rresvport permet lattribution automaa tique dun numro de port dans cette zone, pour des applications ayant e un U ID = 0. Par exemple, cest dans cette zone quinetd (cf cours sur les serveurs) attribue des ports automatiquement pour les outils en r de Berkeley (rlogin, rcp, rexec, rdist,...). Port de 1024 ` 5000 Zone dattribution automatique par bind. Lorsque a lutilisateur (non root) utilise 0 comme numro, cest le premier e port libre qui est employ. Si tous les utilisateurs peuvent sattribuer e manuellement un numro dans cette zone, il vaut mieux viter de le e e faire, la suivante est prvue pour cela. e 5001 ` 65535 Zone libre attention cependant car de tr`s nombreux sera e veurs y ont un port rserv, et pas des moindres comme le serveur X11 e e sur le port 6000 !

1.2

Rservation de port Nouvelle mthode e e

Port N 0 Ce numro nest pas utilisable pour une application, cest une e sorte de jocker qui indique au syst`me que cest ` lui de complter e a e automatiquement le numro (voir plus loin de 49152 ` 65535). e a Port de 1 ` 1023 Pour utiliser cette zone il faut avoir les droits du root ` a a lexcution pour que le bind ne retourne pas une erreur. Les serveurs e classiques (domain, ftp, smtp, telnet, ...) se situent tous dans cette partie. Port de 1024 ` 49151 est la zone des services enregistrs par lIANA et a e qui fonctionnent avec des droits ordinaires. Port de 49152 ` 65535 est la zone dattribution automatique des ports, a pour la partie cliente des connexions (si le protocole nimpose pas une valeur particuli`re) et pour les tests de serveurs locaux. e

2 Ordre des octets sur le rseau e

221

Ordre des octets sur le rseau e

Poids fort "Big endian"
... A+1 A octet 0 Octet 1

Poids faible

"Little endian"
... octet 1 octet 0

HP SUN MOTOROLA

INTEL

Croissance des adresses

gure XII.01 Le probl`me de lordre des octets sur le rseau est dautant plus crucial e e que lon travaille dans un environnement avec des architectures htrog`nes. ee e La couche Rseau (page 28) ne transforme pas les octets de la couche Ine ternet (page 27) qui elle mme ne modie pas ceux de la couche de Transport2 e (page 27). Pour cette raison, le numro de port inscrit dans len-tte TCP (vs UDP) e e de lmetteur est exploit tel quel par la couche de transport du rcepteur e e e et donc il convient de prendre certaines prcautions pour sassurer que les e couches de mme niveau se comprennent. e Dun point de vue plus gnral, les rseaux imposent le poids fort avant e e e le poids faible, cest le Network Byte Order. Les architectures qui travaillent naturellement avec cette reprsentation nont donc thoriquement e e pas besoin dutiliser les fonctions qui suivent, de mme pour les applications e qui doivent dialoguer avec dautres ayant la mme architecture matrielle. e e Nanmoins crire du code portable consiste ` utiliser ces macros dans e e a tous les cas3 ! Pour se souvenir de ces fonctions, il faut conna tre la signication des quatre lettres utiles : s short Entier court sur 16 bits, un numro de port par exemple. e l long Entier long sur 32 bits, une adresse IP par exemple. h host La machine sur laquelle sexcute le programme. e n network Le rseau sur lequel on envoie les donnes. e e #include <sys/types.h>
Nous nabordons pas ici la question de la transmission de donnes htrog`nes au e ee e niveau applicatif, elle sera examine dans le cours sur les XDR e 3 Pour les machines qui respectent naturellement le NBO, comme les stations HP ou SUN, ces fonctions sont des macros vides.
2

222 u u u u long short long short htonl htons ntohl ntohs (u (u (u (u

Complments sur les sockets Berkeley e long) ; /* host to network short) ; /* host to network long) ; /* network to host short) ; /* network to host --------long */ short */ long */ short */

Par exemple, pour aecter le numro de port 13 (service daytime) au e champ sin port dune structure de type sockaddr in : saddr.sin port = htons(13) ; Cette criture est valable quelle que soit larchitecture sur laquelle elle e est compile. Sil avait fallu se passer de la macro htons sur une architecture e Intel (little endian), pour laection du mme numro de port, il eut fallu e e crire : e saddr.sin port = 0x0D00 ; /* 0D hexadcimal == 13 dcimal */ e e

Oprations sur les octets e

Dans le mme ordre dide quau paragraphe prcdent, les rseaux ine e e e e terconnectent des architectures htrog`nes et donc aussi des conventions de ee e rprsentation des cha e e nes de caract`res direntes. Pour tre plus prcis, le e e e e caract`re NULL marqueur de n de cha bien connu des programmeurs C, e ne nest pas valide partout, voire mme est associ ` une autre signication ! e ea En consquence, pour toutes les fonctions et primitives qui lisent et e crivent des octets sur le rseau, les cha e e nes de caract`res sont toujours ase socies au nombre de caract`res qui les composent. e e Le corollaire est que les fonctions classiques de manipulation de cha nes en C (strcpy, strcat, ...) ne sont ` utiliser quavec une extrme prua e dence. Pour copier des octets dune zone vers une autre il faut utiliser bcopy, pour comparer deux buers, bcmp, enn pour mettre ` zro (remplir doctet a e NULL) une zone, bzero. #include <string.h> void bcopy (const void *src, void *dst, size t len) ; int bcmp (const void *b1, const void *b2, size t len) ; void bzero (const void *b, size t len) ; bcopy Attention, len octets de src sont copis dans dst et non linverse, e comme dans strcpy. bcmp Compare b1 et b2 et renvoie 0 si les len premiers octets sont identiques, sinon une valeur non nulle qui nest pas exploitable vis ` vis a dune quelconque relation dordre (` la dirence de strcmp qui supa e pose les caract`res dans la table ASCII). e

4 Conversion dadresses bzero Met des octets NULL (0) len fois ` ladresse b. a Il exite des outils similaires, issus du syst`me V : memcpy, memcmp, memset,.... e

223

Conversion dadresses

La plupart du temps les adresses IP sont fournies par lutilisateur dans le format dcimal point, or la structure dadresse (sockaddr in) a besoin e e dun entier non sign sur 32 bits. Une conversion est donc ncessaire pour e e passer dune reprsentation ` une autre. e a La fonction inet addr converti une adresse dcimale pointe en un entier e e long non sign et qui respecte le NBO. La fonction inet ntoa eectue le e travail inverse. #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> unsigned long inet addr (char *) ; char * inet ntoa (struct in addr) ; Remarque : Ces deux fonctions ne sont pas symtriques, le fait que e e inet addr ne renvoie pas une structure du type in addr semble tre une inconsistance. Exemple dutilisation : struct sockaddr_in saddr ; saddr.sin_addr.s_addr = inet_addr("138.195.52.130") ; printf("Adresse IP = %s\n",inet_ntoa(saddr.sin_addr.s_addr)) ;

Conversion hte adresse IP o

Se pose rguli`rement le probl`me de convertir un nom symbolique en e e e une adresse IP et inversement. Lorigine de cette information dpend de la e conguration de la station de travail : cest un serveur de noms (DNS), cest un chier (/etc/hosts) ou tout autre syst`me de propagation des informae tions (NIS. . .). Dans tous les cas linformation arrive ` un programme via a une entit nomme le resolver, qui unie les sources dinformations. e e

5.1

Une adresse IP ` partir dun nom dhte a o

(char *name) ;

#include <netdb.h> struct hostent * gethostbyname struct hostent {

224

Complments sur les sockets Berkeley e char *h_name ; /* Le nom officiel */ char **h_aliases ; /* Tableau de synonymes */ int h_addrtype ; /* PF_INET pour ARPA */ int h_length ; /* Long. de ladresse */ char **h_addr_list ; /* Adresses possibles */ } ; #define h_addr h_addr_list[0] la macro h addr sert ` assurer la compatibilit avec les premi`res versions a e e dans lesquelles il ny avait quune seule adresse IP possible par hte. o Le nom ociel soppose aux noms synonymes. Par exemple, soit une machine ociellement baptise pasglop.mon-domain.fr ; si pour rpondre e e au besoin dune certaine application ladministrateur du rseau lui donne le e surnom www.mon-domain.fr, celui-ci sera considr comme un alias vis ` ee a vis du nom ociel et donc lu dans h aliases. (voir page 120) La n du tableau de pointeurs est marque par un pointeur NULL. e La liste des adresses est un tableau de pointeurs, le marqueur de n de liste est galement un pointeur NULL. Chaque adresse est une zone de h length e octets (cf fonction impnet dans lexemple ci-apr`s). e Le programme dusage qui suit ache toutes les informations contenues dans cette structure pour les htes dont le nom est pass en argument (le o e code source de cet exemple, gethostbyname.c, est ` la page suivante). a $ gethostbyname puma.cti.ecp.fr isabelle.cti.ecp.fr Nom officiel : puma.cti.ecp.fr Type dadresse : 2 - Longueur : 4 Adresse Internet : 138.195.34.2 Nom officiel : isabelle.cti.ecp.fr Type dadresse : 2 - Longueur : 4 Adresse Internet : 138.195.33.49 $ gethostbyname anna.cti.ecp.fr anna.cti.ecp.fr : hote inconnu !

Conversion hte adresse IP o

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51

225

/* * $Id: gethostbyname.c,v 1.3 2001/12/02 15:08:24 fla Exp $ * Exemple dutilisation de la fonction "gethostbyname". */ #include <stdio.h> #include <sysexits.h> #include <sys/types.h> #include <sys/socket.h> /* AF_INET */ #include <netinet/in.h> /* struct in_addr */ #include <netdb.h> /* gethostbyname */ #include <arpa/inet.h> /* inet_ntoa */ #define USAGE "Usage:%s liste de machines distantes\n"

void impnet(struct in_addr **list) { struct in_addr *adr ; while ((adr = *list++)) (void)printf("Adresse Internet : %s\n",inet_ntoa(*adr)) ; } int main(int argc,char *argv[]) { register char *ptr ; register struct hostent *pth ; if (argc <2) { (void)fprintf(stderr,USAGE,argv[0]) ; exit(EX_USAGE) ; } while (argc > 0) { ptr = *++argv ; if (!(pth = gethostbyname(ptr))) { (void)fprintf(stderr,"%s : hote inconnu !\n",ptr) ; exit(EX_SOFTWARE) ; } printf ("Nom officiel : %s\n",pth>h_name) ; while ((ptr = *(pth>h_aliases))!=NULL) { (void)printf("\talias : %s\n",ptr) ; pth>h_aliases++ ; } (void)printf("Type dadresse : %d Longueur : %d\n", pth>h_addrtype, pth>h_length) ; if (pth>h_addrtype == PF_INET) impnet((struct in_addr **)pth>h_addr_list) ; else (void)printf("Type dadresse non reconnu !\n") ; } exit(EX_OK) ; }

gethostbyname.c

5.2

Un nom dhte ` partir dune adresse IP o a

le probl`me symtrique se rsoud avec la fonction gethostbyaddr. e e e La dnition du prototype se trouve au mme endroit que prcdement, e e e e la fonction renvoie un pointeur sur une structure du type hostent. #include <netdb.h> struct hostent * gethostbyaddr (char *addr, int len, int type) ; addr Pointe sur une structure du type in addr.

226 len Est la longueur de addr.

Complments sur les sockets Berkeley e

type PF INET quand on utilise la pile ARPA.

Conversion N de port service

Couramment les ports bien connus sont donns par leur nom plutt que e o par leur valeur numrique, comme par exemple dans les sorties de la come mande tcpdump.

6.1

Le numro ` partir du nom e a

Un tel programme a besoin de faire la conversion symbolique numrique, la fonction getservbyname eectue ce travail. Lutilisateur e rcup`re un pointeur sur une structure du type servent, NULL dans le e e cas dune impossibilit. La source dinformations se trouve dans le chier e /etc/services. #include <netdb.h> struct servent * getservbyname (char *name, char *proto) ; struct servent { char *s_name ; char **s_aliases ; int s_port ; char *s_proto ; } ; s name Le nom ociel du service. s aliases Un tableau de pointeurs sur les aliases possibles. Le marqueur de n de tableau est un pointeur ` NULL. a s port Le numro du port (il respecte le Network Byte Order). e s proto Le nom du protocole ` utiliser pour contacter le service (TCP vs a UDP). Voici un programme de mise en application de la fonction, le code source de lexemple, getservbyname.c se trouve ` la page suivante. a $ getservbyname domain Le service domain est reconnu dans /etc/services protocole :tcp - N de port :53 $ getservbyname domain udp Le service domain est reconnu dans /etc/services protocole :udp - N de port :53

Conversion N de port service

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

227

/* * $Id: getservbyname.c,v 1.3 2001/12/02 14:17:32 fla Exp $ * Exemple dutilisation de la fonction "getservbyname". */ #include <stdio.h> #include <sysexits.h> #include <sys/types.h> #include <netinet/in.h> /* Pour "ntohs" */ #include <netdb.h> /* Pour "getservbyname" */ #define USAGE "Usage:%s <nom de service> [<nom de protocole>]\n" #define MSG1 "Le service %s est reconnu dans /etc/services\nprotocole :%s N de port :%d\n" #define MSG2 "Le service %s (%s) est introuvable dans /etc/services !\n" int main(int argc,char *argv[]) { struct servent *serv ; if (argc <2) { (void)fprintf (stderr,USAGE,argv[0]) ; exit (EX_USAGE) ; } if (serv = getservbyname(argv[1],argv[2]?argv[2]:"tcp")) (void)printf(MSG1,serv>s_name,serv>s_proto,ntohs(serv>s_port)) ; else (void)printf(MSG2,argv[1],argv[2]?argv[2]:"") ; exit(EX_OK) ; }

getservbyname.c

6.2

Le nom ` partir du numro a e

Symtriquement la fonction getservbyport eectue le travail inverse. e Elle renvoie aussi un pointeur sur une structure servent, NULL dans le cas dune impossibilit. e #include <netdb.h> struct servent * getservbyport (int port, char *proto) ;

Exemples dusage :

$ getservbyport 53 Le port 53 correspond au service "domain" (protocole tcp). $ getservbyport 53 udp Le port 53 correspond au service "domain" (protocole udp).

Exemple de programmation :

228
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

Complments sur les sockets Berkeley e

/* * $Id: getservbyport.c,v 1.3 2001/12/02 14:26:01 fla Exp $ * Exemple dutilisation de la fonction "getservbyport". */ #include <stdio.h> #include <stdlib.h> /* Pour "atoi". */ #include <sysexits.h> #include <sys/types.h> #include <netinet/in.h> /* Pour "ntohs" */ #include <netdb.h> /* Pour "getservbyport" */ #define USAGE #define MSG1 #define MSG2 "Usage:%s <numro de port> [<nom de protocole>]\n" "Le port %d correspond au service \"%s\" (protocole %s).\n" "Le port %s (%s) est introuvable dans /etc/services !\n"

int main(int argc,char *argv[]) { struct servent *serv ; if (argc <2) { (void)fprintf(stderr,USAGE,argv[0]) ; exit(EX_USAGE) ; } if ((serv = getservbyport(atoi(argv[1]),argv[2]?argv[2]:"tcp"))) (void)printf(MSG1,ntohs(serv>s_port),serv>s_name,serv>s_proto) ; else (void)printf(MSG2,argv[1],argv[2]?argv[2]:"") ; exit(EX_OK) ; }

getservbyport.c

Conversion nom de protocole N de protocole

Les fonctions getservbyname et getservbyport dlivrent un nom de e protocole, donc un symbole. Lors de la dclaration dune socket le troisi`me argument est numrique, e e e il est donc ncessaire davoir un moyen pour convertir les numros de proe e tocoles (IPPROTO UDP, IPPROTO TCP, IPPROTO IP,IPPROTO ICMP,...) en symboles et rciproquement. e Le chiers /etc/protocols contient cette information, et la paire de fonctions getprotobyname et getprotobynumber lexploitent. #include <netdb.h> struct protoent *getprotobyname (char *name) ; struct protoent *getprotobynumber (char *proto) ; struct protoent { char *p_name ; char **p_aliases ; int p_proto ; } ; p name Le nom ociel du protocol.

8 Diagnostic p aliases La liste des synonymes, le dernier pointeurs est NULL. p proto Le numro du protocole, dans /etc/services. e
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

229

/* * $Id: getprotobyname.c,v 1.2 2001/11/29 18:45:39 fla Exp $ * Exemple dutilisation de la fonction "getprotobyname". */ #include <stdio.h> #include <sysexits.h> #include <netdb.h> /* Pour getprotobyname */ #define USAGE #define MSG1 #define MSG2 "Usage:%s <nom du protocole>\n" "Le protocole %s est reconnu dans /etc/protocols N : %d\n" "Le protocole %s est introuvable dans /etc/protocols !\n"

int main(int argc,char *argv[]) { struct protoent *proto ; if (argc <2) { (void)fprintf(stderr,USAGE,argv[0]) ; exit(EX_USAGE) ; } if (proto = getprotobyname(argv[1])) (void)printf(MSG1,proto>p_name,proto>p_proto) ; else (void)printf(MSG2,argv[1]) ; exit(EX_OK) ; }

getprotobyname.c Le source qui prc`de donne un exemple de programmation de la fonction e e getprotobyname. Usage de ce programme : $ getprotobyname ip Le protocole ip est reconnu dans /etc/protocols - N : 0 $ getprotobyname tcp Le protocole tcp est reconnu dans /etc/protocols - N : 6 $ getprotobyname vmtp Le protocole ipv6 est reconnu dans /etc/protocols - N : 41

Diagnostic

Chaque retour de primitive devrait tre soigneusement test, le code e e gnr nen est que plus able et les ventuels disfonctionnements plus aiss e ee e e ` dtecter. a e Quelques unes des erreurs ajoutes au chier den-tte errno.h e e

230 erreur ENOTSOCK EDESTADDRREQ EMSGSIZE EPROTOTYPE ENOPROTOOPT EPROTONOSUPPORT ESOCKTNOSUPPORT EOPNOTSUPP EAFNOSUPPOR EADDRINUSE EADDRNOTAVAIL ENETDOWN ENETUNREACH ENETRESET ECONNABORTED ECONNRESET ENOBUFS EISCONN ENOTCONN ESHUTDOWN ETIMEDOUT ECONNREFUSED EREMOTERELEASE EHOSTDOWN EHOSTUNREACH

Complments sur les sockets Berkeley e Description de lerreur Le descripteur nest pas celui dune socket Adresse de destination requise Le message est trop long Mauvais type de protocole pour une socket Protocole non disponible Protocole non support e Type de socket non support e Opration non supporte e e Famille dadresse non supporte e Adresse dj` utilise ea e Ladresse ne peut pas tre aecte e e Rseau hors service e Pas de route pour atteindre ce rseau e Connexion coupe par le rseau e e Connexion interrompue Connexion interrompue par lhte distant o Le buer est satur e La socket est dj` connecte ea e La socket nest pas connecte e Transmission apr`s un shutdown e time-out expir e Connexion refuse e Lhte distant a interrompue sa connexion o Lhte nest pas en marche o Pas de route vers cet hte o

9 Exemples de mise en application

231

Exemples de mise en application

Deux exemples de fonctions de connexion ` un serveur sont jointes ` ce a a cours : lune tcp open et lautre udp open. Toutes les deux renvoient un descripteur de socket prt ` lemploi, ou -1 en cas derreur (le message derreur e a doit tre gnr par les fonctions elles mmes). En voici les prototypes : e e ee e int tcp_open(char *host, char *service, int port) ; int udp_open(char *host, char *service, int port, int conn) ; Description des arguments : host Une cha de caract`res qui est ladresse de lhte distant. Cette ne e o adresse est soit sous forme dcimale pointe, soit cest un nom syme e bolique. Elle ne peut pas tre nulle. e service Si cette cha nest pas nulle, elle contient le nom symbolique du ne service distant sur lequel il faut se connecter. port Le numro du port distant. Sil est ngatif alors service est oblie e gatoirement non nulle. Dans le cas o` service est non nulle et u port > 0, cette derni`re valeur lemporte sur celle trouve dans le chier e e /etc/services. conn Cet argument na dusage que pour la fonction udp open. Egal ` un, a il prcise que la socket cre est ddie au serveur host (avec un bind), e e e e ie on pourra employer send et recv au lieu de sendto et recvfrom.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

/* $Id: open_tcp.c,v 1.4 2002/11/24 17:26:11 fla Exp $ * * Fonction "tcp_open" + exemple dutilisation avec "daytime" * et "time". */ #include <stdio.h> #include <unistd.h> #include <string.h> #include <errno.h> #include <sysexits.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netdb.h> #include <arpa/inet.h> #define USAGE "Usage:%s <nom de machine distante>\n" tcp_serv_addr ; /* Adresse Internet du serveur. */ tcp_serv_info ; /* Infos de "getservbyname". */ tcp_host_info ; /* Infos de "gethostbyname". */

struct sockaddr_in struct servent struct hostent

232
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64

Complments sur les sockets Berkeley e

int tcp_open(char *host,char *service,int port) { int fd ; unsigned long inaddr ; struct hostent *hp ; struct servent *sv ; bzero ((char *)&tcp_serv_addr, sizeof tcp_serv_addr) ; tcp_serv_addr.sin_family = AF_INET ; if (*service) { if (!(sv = getservbyname(service,"tcp"))) { (void)fprintf(stderr,"tcp_open:service inconnu:%s/tcp\n",service) ; return 1 ; } tcp_serv_info = *sv ; if (port > 0) tcp_serv_addr.sin_port = htons(port) ; else tcp_serv_addr.sin_port = sv>s_port ; } else { if (port <= 0) { (void)fprintf(stderr,"tcp_open:numro de port non spcifi !\n") ; return 1 ; } tcp_serv_addr.sin_port = htons(port) ; }

if ((inaddr = inet_addr(host)) != INADDR_NONE) { /* netid.hostid ? */ bcopy((char *)&inaddr,(char *)&tcp_serv_addr.sin_addr,sizeof inaddr) ; tcp_host_info.h_name = (char *)NULL ; } else { if (!(hp = gethostbyname(host))) { (void)fprintf(stderr,"tcp_open: erreur de nom de machine : %s : %s\n", host,strerror(errno)) ; return 1 ; } tcp_host_info = *hp ; bcopy(hp>h_addr,(char *)&tcp_serv_addr.sin_addr,hp>h_length) ; } if ((fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) { (void)fprintf(stderr,"tcp_open: impossible de crer la socket !\n") ; return 1 ; } if (connect(fd,(struct sockaddr *)&tcp_serv_addr,sizeof tcp_serv_addr)<0) (void)fprintf(stderr,"tcp_open: impossible de se connecter !\n") ; (void)close(fd) ; return 1 ; } return fd ; } int main(int argc,char *argv[]) { int sfd ; int n ; unsigned long temps ; char buf[256] ;

Exemples de mise en application

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

233

if (argc < 2) { (void)fprintf(stderr,USAGE,argv[0]) ; exit (EX_USAGE) ; } /* * Connexion au serveur de date */ if ((sfd = tcp_open(argv[1],"daytime",0)) < 0) exit(EX_SOFTWARE) ; if ((n=read(sfd,(void *)buf, sizeof(buf)1))< 0) perror("read/daytime") ; else { buf[n]=\0; (void)printf("Date(%s)=%s",argv[1],buf) ; } (void)close(sfd) ; /* * Connexion au serveur de temps */ if ((sfd = tcp_open(argv[1],"",37)) < 0) exit (EX_SOFTWARE) ; if (read(sfd,(void *)&temps, sizeof temps) < 0) perror("read/port 37") ; else (void)printf("Temps(%s)=%lu\n",argv[1],ntohl(temps)) ; exit (EX_OK) ; }

open tcp.c Exemple dusage : $ ./open_tcp localhost Date : Sun Dec 2 16:12:57 2001 Temps : 3216294777 Remarque : Pour transmettre la structure dadresse du serveur ` la fonca tion appelante, La fonction udp open compl`te une structure globale. e
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

/* $Id: open_udp.c,v 1.2 2001/12/02 15:08:24 fla Exp $ * * Fonction "udp_open" + exemple dutilisation avec "daytime" * et "time". */ #include <stdio.h> #include <unistd.h> #include <string.h> #include <errno.h> #include <sysexits.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netdb.h> #include <arpa/inet.h> #define USAGE "Usage:%s <nom de machine distante>\n" struct sockaddr_in udp_serv_addr ; /* Adresse Internet du serveur. */ struct sockaddr_in udp_cli_addr ; /* Adresse Internet du client. */ struct servent udp_serv_info ; /* Infos de "getservbyname". */

234
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67

Complments sur les sockets Berkeley e

int udp_open(char *host,char *service,int port,int conn) { int fd ; unsigned long inaddr ; struct hostent *hp ; struct servent *sv ; bzero ((char *)&udp_serv_addr, sizeof udp_serv_addr) ; udp_serv_addr.sin_family = AF_INET ; if (*service) { if (!(sv = getservbyname(service,"udp"))) { (void)fprintf(stderr,"udp_open:service inconnu:%s/udp\n",service) ; return 1 ; } udp_serv_info = *sv ; if (port > 0) udp_serv_addr.sin_port = htons(port) ; else udp_serv_addr.sin_port = sv>s_port ; } else { if (port <= 0) { (void)fprintf(stderr,"udp_open:numro de port non spcifi !\n") ; return 1 ; } udp_serv_addr.sin_port = htons(port) ; } if ((inaddr = inet_addr(host)) != INADDR_NONE) { /* netid.hostid ? */ bcopy ((char *)&inaddr,(char *)&udp_serv_addr.sin_addr,sizeof inaddr) udp_host_info.h_name = (char *)NULL ; } else { if (!(hp = gethostbyname(host))) { (void)fprintf(stderr,"udp_open:erreur de nom de machine:%s:%s\n", host,strerror(errno)) ; return 1 ; } udp_host_info = *hp ; bcopy(hp>h_addr,(char *)&udp_serv_addr.sin_addr,hp>h_length) ; } if ((fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) { (void)fprintf(stderr,"udp_open: impossible de crer la socket !\n") ; return 1 ; } bzero ((char *)&udp_cli_addr,sizeof udp_cli_addr) ; udp_cli_addr.sin_family = AF_INET ; udp_cli_addr.sin_addr.s_addr = htonl(INADDR_ANY) ; udp_cli_addr.sin_port = htons(0) ; if (bind(fd,(struct sockaddr *)&udp_cli_addr,sizeof udp_cli_addr) < 0) { (void)fprintf(stderr,"udp_open:erreur avec ladresse locale !\n") ; (void)close(fd) ; return 1 ; } if (conn == 1) { /* Figer ladresse du serveur. */ if (connect(fd,(struct sockaddr *)&udp_serv_addr, sizeof udp_serv_addr)<0) { (void)fprintf(stderr,"udp_open: connexion impossible avec %s !\n",\ host) (void)close(fd) ; return 1 ; } } return fd ; }

Exemples de mise en application

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

235

int main(int argc,char *argv[]) { int sfd ; int n ; unsigned long temps ; char buf[256] ; if (argc < 2) { (void)fprintf(stderr,USAGE,argv[0]) ; exit (EX_USAGE) ; } /* * Connexion au serveur de date */ if ((sfd = udp_open(argv[1],"daytime",0,1)) < 0) exit(EX_SOFTWARE) ; if (send(sfd,(void *)" ",1,0) < 0) perror("send") ; else if ((n=recv(sfd,(void *)buf, sizeof buf,0)) < 0) perror("recv") ; else { buf[n]=\0 ; (void)printf("Date(%s)=%s",argv[1],buf) ; } (void)close(sfd) ; /* * Connexion au serveur de temps */ if ((sfd = udp_open(argv[1],"",37,0)) < 0) exit(EX_SOFTWARE) ; n = sizeof udp_serv_addr ; if (sendto(sfd,(void *)" ",1,0,(void *)&udp_serv_addr, n) < 0) perror("sendto") ; else if (recvfrom(sfd,(void *)&temps,sizeof temps,0,\ (void *)&udp_serv_addr, &n) < 0) perror("recvfrom") ; else (void)printf("Temps(%s)=%lu\n",argv[1],ntohl(temps)) ; exit(EX_OK); }

open udp.c Exemple dusage : $ ./open_udp localhost Date : Sun Dec 2 16:12:17 2001 Temps : 3216294737

236

Complments sur les sockets Berkeley e

10

Conclusion et bibliographie

Lusage des fonctions vues dans ce chapitre peut se rsumer autour dune e structure dadresse de socket : short sin family ; u short sin port ; struct in addr sin char sin zero[8] ; Fonction gethostbyname getservbyname addr ; gethostbyname bzero Structure champ hostent h addrtype servent s port hostent h addr

Outre les pages de manuel (man) le lecteur pourra consulter avec grand prot les ouvrages suivants : RFC 1700 J. Reynolds, J. Postel, ASSIGNED NUMBERS, 10/20/1994. (Pages=230) (Format=.txt) (Obsoletes RFC1340) (STD 2) Samuel J. Leer, Robert S. Fabry, William N. Joy, Phil Lapsley An Advanced 4.4BSD Interprocess Communication Tutorial CSRG University of California, Berkeley Berkeley, California 94720. Ce document est redit dans Programmers Supplementary Documents e e diteur OReilly, ou sous forme de chier ascii dans le rpertoire : e e /usr/share/doc/psd/21.ipc/paper.ascii.gz W. Richard Stevens Unix Network Programming Prentice All 1990 W. Richard Stevens Unix Network Programming Second edition Prentice All 1998 Douglas E. Comer David L. Stevens Internetworking with TCP/IP Volume III (BSD Socket version) Prentice All 1993

Chapitre XIII e Elments de serveurs

Dans ce chapitre nous abordons quelques grands principes de fonctionnement des logiciels serveurs. Dabord nous tentons de rsumer leurs comportee ments selon une typologie en quatre mod`les gnriques, puis nous examinons e e e quelques points techniques remarquables de leur architecture logicielle comme la gestion des taches multiples, des descripteurs multiples, le fonctionnement en arri`re plan (les fameux daemon ), la gestion des logs. . . e Enn nous concluons ce chapitre avec une petite prsentation du serveur e de serveurs sous Unix, cest ` dire la commande inetd ! a

Type de serveurs

Lalgorithme intuitif dun serveur, dduit des schmas (revoir la page 211) e e dutilisation des sockets, pourrait tre celui-ci : e 1. Crer une socket, lui aecter une adresse locale avec un numro de port e e connu des clients potentiels. 2. Entrer dans une boucle innie qui accepte les requtes des clients, les e lit, formule une rponse et la renvoie au client. e Cette dmarche, que nous pourrions qualier de na e ve, ne peut convenir qu` des applications tr`s simples. Considrons lexemple dun serveur a e e de chiers fonctionnant sur ce mode. Un client rseau qui sy connecte et e tlcharge pour 10 Go de donnes accapare le serveur pendant un temps siee e gnicativement long, mme au regard des bandes passantes modernes. Un e deuxi`me client rseau qui attendrait la disponibilit du mme serveur pour e e e e transfrer 1Ko aurait des raisons de simpatienter ! e

1.1

Serveurs itratif et concourant e

Un serveur itratif ( iterative server ) dsigne une implmentation qui e e e traite une seule requte ` la fois. e a Un serveur concourant ( concurrent server ) dsigne une e implmentation capable de grer plusieurs taches en apparence simule e

238

e Elments de serveurs tanes. Attention, cette fonctionnalit nimplique pas ncessairement que e e e ces taches concourantes doivent toutes sexcuter en parall`le. . . e e Dans cette premi`re approche purement algorithmique nous nabordons e pas la mise en uvre technique, le paragraphe 2 sy consacrera ! Dun point de vue conceptuel, les serveurs itratifs sont plus faciles ` e a concevoir et ` programmer que les serveurs concourants, mais le rsultat a e nest pas toujours satisfaisant pour les clients. Au contraire, les serveurs concourants, sils sont dune conception plus savante, sont dun usage plus agrable pour les utilisateurs parceque naturellement plus disponibles. e

1.2

Le choix dun protocole

La pile ARPA nous donne le choix entre TCP et UDP. Lalternative nest pas triviale. Le protocole dapplication peut tre compl`tement boulevers e e e par le choix de lun ou de lautre. Avant toute chose il faut se souvenir des caractristiques les plus marquantes de lun et de lautre. e Mode connect e Le mode connect avec TCP est le plus facile ` programmer, de plus il e a assure que les donnes sont transmises, sans perte. e Par contre, Il tablit un circuit virtuel bi-directionnel ddi ` chaque e e e a client ce qui monopolise une socket, donc un descripteur, et interdit par construction toute possibilit de broadcast . e Ltablissement dune connexion et sa terminaison entra lchange de 7 e ne e paquets. Sil ny a que quelques octets ` changer entre le client et le serveur, ae cet change est un gaspillage des ressources du rseau. e e Il y a plus proccupant. Si la connexion est au repos , cest ` dire quil e a ny a plus dchange entre le client et le serveur, rien nindique ` celui-ci que e a le client est toujours l` ! TCP est silencieux si les deux parties nont rien ` a a schanger1 . e Si lapplication cliente a t interrompue accidentellement2 , rien nindique ee au serveur que cette connexion est termine et il maintient la socket et les e buers associs. Que cette opration se rp`te un grand nombre de fois et le e e e e serveur ne rpondra plus, faute de descripteur disponible, voire de mmoire e e libre au niveau de la couche de transport (allocation au niveau du noyau, en fonction de la mmoire totale et au dmarrage de la machine) ! e e Mode datagramme Le mode datagramme ou non connect avec UDP hrite de tous les e e dsagrments de IP, ` savoir perte, duplication et dsordre introduit dans e e a e lordre des datagrammes.
Nous verrons au chapitre suivant comment on peut modier ce comportement par dfaut e 2 crash du syst`me, retrait du rseau,. . . e e
1

Quatre mod`les de serveurs e Pourtant malgr ces inconvnients UDP reste un protocole qui ore des e e avantages par rapport ` TCP. Avec un seul descripteur de socket un serveur a peut traiter un nombre quelconque de clients sans perte de ressources due ` de a mauvaises dconnexions. Le broadcast et le multicast sont possibles. e Par contre les probl`mes de abilit du transport doivent tre grs au e e e ee niveau de lapplication. Gnralement cest la partie cliente qui est en charge e e de la remission de la requte si aucune rponse du serveur ne lui parvient. e e e La valeur du temps au del` duquel lapplication consid`re quil doit y avoir a e remission est videment dlicate ` tablir. Elle ne doit pas tre ge aux e e e a e e e caractristiques dun rseau local particulier et doit tre capable de sadapter e e e aux conditions changeantes dun internet.

239

1.3

Quatre mod`les de serveurs e

Deux comportements de serveurs et deux protocoles de transport combins gn`rent quatre mod`les de serveurs : e e e e
Itratif Datagramme Itratif Connect

Concourant Datagramme

Concourant Connect

gure XIII.01 La terminologie tache esclave employe dans les algorithmes qui suie vent se veut neutre quant au choix technologique retenu pour les implmenter. e Ce qui importe cest leur nature concourante avec la tache ma tre qui les engendre. Algorithme itratif - Mode data-gramme : e 1. Crer une socket, lui attribuer un port connu des clients. e 2. Rpter : e e Lire une requte dun client, e Formuler la rponse, e Envoyer la rponse, conformment au protocole dapplication. e e Critique : Cette forme de serveur est la plus simple, elle nest pas pour autant inutile. Elle est adapte quand il y a un tout petit volume dinformation ` changer et e ae en tout cas sans temps de calcul pour llaboration de la rponse. Le serveur e e de date daytime ou le serveur de temps time en sont dexcellents exemples.

240 Algorithme Itratif - Mode connect : e e

e Elments de serveurs

1. Crer une socket, lui attribuer un port connu des clients. e 2. Mettre la socket ` lcoute du rseau, en mode passif. a e e 3. Accepter la connexion entrante, obtenir une socket pour la traiter. 4. Entamer le dialogue avec le client, conformment au protocole e de lapplication. 5. Quand le dialogue est termin, fermer la connexion et aller en 3). e Critique : Ce type de serveur est peu utilis. Son usage pourrait tre ddi ` des e e e e a relations clients/serveurs mettant en jeu de petits volumes dinformations avec la ncessit den assurer ` coup sr le transport. Le temps dlaboration e e a u e de la rponse doit rester court. e Le temps dtablissement de la connexion nest pas ngligeable par rape e port au temps de rponse du serveur, ce qui le rend peu attractif. e Algorithme concourant - Mode datagramme : Ma tre : 1. Crer une socket, lui attribuer un port connu des clients. e 2. Rpter : e e Lire une requte dun client e Crer une tache esclave pour laborer la rponse. e e e Esclave : 1. Recevoir la demande du client, 2. Elaborer la rponse, e 3. Envoyer la rponse au client, conformment au protocole e e de lapplication, 4. Terminer la tache.

Quatre mod`les de serveurs e Critique : Si le temps dlaboration de la rponse est rendu indirent pour cause de e e e cration de processus esclave, par contre le cot de cration de ce processus e u e ls est prohibitif par rapport ` son usage : formuler une seule rponse et a e lenvoyer. Cet inconvnient lemporte gnralement sur lavantage apport e e e e par le paralllisme . e Nanmoins, dans le cas dun temps dlaboration de la rponse long par e e e rapport au temps de cration du processus esclave, cette solution se justie. e Algorithme concourant - Mode connect : e Ma tre : 1. Crer une socket, lui attribuer un port connu des clients. e 2. Mettre la socket ` lcoute du rseau, en mode passif. a e e 3. Rpter : e e Accepter la connexion entrante, obtenir une socket pour la traiter, Crer une tache esclave pour traiter la rponse. e e Esclave : 1. Recevoir la demande du client, 2. Amorcer le dialogue avec le client, conformment au protocole e de lapplication, 3. Terminer la connexion et la tache. Critique : Cest le type le plus gnral de serveur parce-quil ore les meilleurs cae e ractristiques de transport et de souplesse dutilisation pour le client. Il est e sur-dimensionn pour les petits services et sa programmation soigne e e nest pas toujours ` la porte du programmeur dbutant. a e e

241

242

e Elments sur les serveurs

Technologie lmentaire ee

De la partie algorithmique dcoulent des questions techniques sur le e comment le faire . Ce paragraphe donne quelques grandes indications tr`s e lmentaires que le lecteur soucieux dacqurir une vraie comptence devra ee e e complter par les lectures indiques au dernier paragraphe ; la Bibliographie e e du chapitre (page 258). Notamment il est ncessaire de consulter les ouvrages e de W. R. Stevens pour la partie syst`me et David R. Butenhof pour la e programmation des threads. La suite du texte va se consacrer ` clairer les points suivants : ae 1. Gestion des taches esclaves (paragraphes 2.1, 2.2, 2.3, 2.4) 2. Gestion de descripteurs multiples (paragraphes 2.5, 2.6) 3. Fonctionnement des processus en arri`re plan ou daemon (parae graphe 3)

2.1

Gestion des taches esclaves

La gestion des taches esclaves signales dans le paragraphe 1 induit que e le programme serveur est capable de grer plusieurs actions concourantes, e cest ` dire qui ont un comportement qui donne lillusion ` lutilisateur que a a sa requte est traite dans un dlai raisonnable, sans devoir patienter jusqu` e e e a lach`vement de la requte prcdente. e e e e Cest typiquement le comportement dun syst`me dexploitation qui ore donnance des processus entre-eux pour donner ` chacun deux un peu de la a puissance de calcul disponible ( time-sharing ). La dmarche qui parait la plus naturelle pour implmenter ces taches e e esclaves est donc de tirer partie des proprits mmes de la gestion des ee e processus du syst`me dexploitation. e Sur un syst`me Unix lusage de processus est une bonne solution dans un e premier choix car ce syst`me dispose de primitives (APIs) bien rodes pour e e les grer, en particulier fork(), vfork() et rfork(). e Nanmoins, comme le paragraphe suivant le rappelle, lusage de processus e ls nest pas la panace car cette solution comporte des dsagrments. Deux e e e autres voies existent, non toujours valables partout et dans tous les cas de gure. La premi`re passe par lusage de processus lgers ou threads , la e e deuxi`me par lusage du signal SIGIO qui autorise ce que lon nomme la e programmation asynchrone (cf 2.4). Pour conclure il faut prciser que des taches esclaves ou concourantes e peuvent sexcuter dans un ordre alatoire mais pas ncessairement en mme e e e e temps. Cette derni`re caractristique est celle des taches parall`les. Autree e e ment dit, les taches parall`les sont toutes concourantes mais linverse nest e pas vrai. Concr`tement il faut disposer dune machine avec plusieurs procese seurs pour avoir, par exemple, des processus (ou des threads kernel , si elles sont supportes) qui sexcutent vraiment de mani`re simultane donc sur e e e e

fork, vfork et rfork des processeurs dirents. Sur une architecture mono-processeur, les taches e ne peuvent tre que concourantes ! e

243

2.2

fork, vfork et rfork

Il ne sagit pas ici de faire un rappel sur la primitive fork() examine e dans le cadre du cours Unix, mais dexaminer lincidence de ses proprits ee sur larchitecture des serveurs. Le rsultat du fork() est la cration dun processus ls qui ne di`re de e e e son p`re que par les points suivants : e 1. Le code de retour de fork : 0 pour le ls, le pid du ls pour le p`re e 2. Le numro de processus (pid) ainsi que le numro de processus du e e processus p`re (ppid) e 3. Les compteurs de temps (utime, stime, . . .) qui sont remis ` zro a e 4. Les verrous (flock) qui ne sont pas transmis 5. Les signaux en attente non transmis galement e Tout le reste est doublonn, notamment la stack et surtout la heap e qui peuvent tre tr`s volumineuses et donc rendre cette opration pnalisante e e e e voire quasi redhibitoire sur un serveur tr`s charg (des milliers de processus e e et de connexions rseaux). e Si le but du fork dans le processus ls est deectuer un exec immdiatement, alors il tr`s intressant dutiliser plutt le vfork. Celui-ci e e e o ne fait que crer un processus ls sans copier les donnes. En consquence, e e e durant le temps de son excution avant le exec le ls partage strictement e les mmes donnes que le p`re (` utiliser avec prcaution). Jusqu` ce que le e e e a e a processus rencontre un exit ou un exec, le processus p`re reste bloqu (le e e vfork ne retourne pas). En allant plus loin dans la direction prise par vfork, le rfork3 autorise la continuation du processus p`re apr`s le fork, la consquence est que deux e e e processus partagent le mme espace dadressage simultanment. Largument e e dappel du rfork permet de param`trer ce qui est eectivement partag ou e e non. RFMEM, le principal dentre eux, indique au noyau que les deux processus partagent tout lespace dadressage. Si cette derni`re primitive est tr`s riche de potentialits4 , elle est e e e galement dlicate ` manipuler : deux (ou plus) entits logicielles excutant e e a e e le mme code et accdant aux mmes donnes sans prcaution particuli`re e e e e e e vont tr`s certainement converger vers de srieux ennuis de fonctionnement si e e le droulement de leurs oprations nest pas rigoureusement balis. e e e En eet, le soucis principal de ce type de programme multi-entits est e de veiller ` ce quaucune de ses composantes ne puisse changer les tats de a e
clone() sous Linux dailleurs limplmentation actuelle des threads sous Linux emploie cette primitive e avec des avantages et beaucoup dinconvnients par rapport ` ce que prvoit la norme e a e Posix et ` la gestion des processus a
4 3

244

e Elments sur les serveurs sa mmoire simultanment. Autrement dit, il faut introduire presque oblie e gatoirement un mcanisme de smaphore qui permette ` lune des entits e e a e logicielles de vrouiller lacc`s ` telle ou telle ressource mmoire pendant le e e a e temps ncessaire ` son usage. e a Cette opration de vrouillage elle-mme pose probl`me, parceque e e e e les entits logicielles pouvent sexcuter en parall`le (architecture multie e e processeurs) et donc il est indispensable que lacquisition du smaphore qui e prot`ge une ressource commune soit une opration atomique, cest ` dire qui e e a sexcute en une fois, sans quil y ait possibilit que deux (ou plus) entits e e e logicielles tentent avec succ`s de lacqurir. Cest toute la probl`matique des e e e mutex5 .

2.3

Processus lgers, les threads e

Les processus lgers ou threads sont une ide du milieu des annes e e e 80. La norme Posix a pos les bases de leur dveloppement durable en 1995 e e (Posix 1.c), on parle gnralement de pthreads. e e Lide fondatrice des threads est de ne pas faire de fork mais plutt e o de permettre le partage de lespace dadressage ` autant de contextes a 6 dexcution du mme code que lon souhaite. e e
Sans thread Avec threads

Stack Adresses croissantes Registres... CP

Registres... Thread 2 CP2 Registres... Thread 1 CP1

f2() f1() 0x00000000 Texte

f2() f1() Texte

gure XIII.02 Au lieu de crer un nouveau processus on cre une nouvelle thread, ce e e qui revient (en gros) ` ajouter un nouveau contexte dexcution sur la pile a e syst`me dans le processus. Lusage de mutex (cf paragraphe 2.2) est fore tement recommand pour srialiser les acc`s aux sections critiques du e e e code. Sur une machine ayant une architecture mono-processeur, le premier type de threads est susant, mais d`s que la machine est construite avec une are 7 chitecture smp (ce qui est de plus en plus le cas avec la banalisation des congurations bi-processeurs et plus) lusage de threads grables par le noyau e devient beaucoup plus intressant car il utilise au mieux les ressources de la e
5 6

mutual exclusion ordre de grandeur de quelques dizaines 7 Symmetric Multi Processor

Processus lgers, les threads e machine : un mme processus pourrait avoir deux threads, une sexcutant e e sur chacun des deux processeurs (ou plus bien entendu, sil y a plus de processeurs). Le principe tant pos, on distingue plusieurs familles dimplmentation. e e e Dun cot il y a les threads user land cest ` dire qui sont e a compl`tement gres par le processus utilisateur et de lautre les threads e ee kernel , qui sont gres par le noyau. Ces derni`res threads sont supee e portes par les constructeurs de machines ` architectures parall`les, tradie a e tionnellement Sun (Solaris) et Compaq (ex Digital, avec True64) et plus recement Hewlett-Packard avec la version 11.xx dHP-UX. Le probl`me est e tr`s complexe et chaque constructeur dveloppe ses propres stratgies. e e e Du cot des OS libres le probl`me navance pas vite car il monopolise e e beaucoup de programmeurs de haut niveau, non toujours disponibles pour des taches au long court. . . Les threads Linux utilisent rfork qui est simple et tr`s ecace. Cette e approche nest pas satisfaisante car chaque thread est excute dans un proe e cessus dirent (pid dirent donc) ce qui est contraire aux recommandations e e POSIX, dune part, et dautre par ne permet pas dutiliser les r`gles de prioe rit dnies galement par POSIX. Une application avec un grand nombre e e e de threads prend lavantage sur les autres applications par le fait quelle consomme en temps cumul bien plus que les autres processus mono-thread. e Actuellement les threads de FreeBSD sont encore du type user land mais un projet tr`s ambitieux et tr`s prometteur (dont lissue a t repousse e e ee e plusieurs fois) est en cours de dveloppement8 . e Conclusion : Les threads user land ne sexcutent que sur un seul processeur quelle e que soit larchitecture de la machine qui les supporte. Sur une machine de type smp il faut que le syst`me dexploitation supporte les threads kernel e pour quun mme processus puisse avoir des sous-taches sur tous les procese seurs existants.

245

http ://www.freebsd.org/smp/

246

e Elments sur les serveurs

2.4

Programmation asynchrone

Les paragraphes qui prc`dent utilisent un processus ou une thread pour e e pouvoir eectuer au moins deux taches simultanment : couter le rseau et e e e traiter une (ou plusieurs) requte(s). Dans le cas dun serveur peu sollicit e e il tout ` fait envisageable de mettre en uvre une autre technique appelle a e programmation asynchrone . La programmation asynchrone sappuie sur lusage du signal, SIGIO (SIGPOLL sur syst`me V), ignor par dfaut, qui prvient le processus dune e e e e activit sur un descripteur. e La gestion des entres/sorties sur le descripteur en question est alors e traite comme une exception, par un handler de signaux. e Le signal SIGIO est ignor par dfaut, il faut demander explicitement au e e noyau de le recevoir, ` laide dun appel ` la primitive fcntl. Une fois activ, a a e il nest pas reu pour les mmes raisons selon le protocole employ : c e e UDP : Arrive dun paquet pour la socket e Une erreur TCP : Une demande de connexion (attente sur un accept) qui arrive Une dconnexion e Une demi-dconnexion (shutdown) e Arrive de donnes sur une socket e e Fin de lmission de donnes (buer dmission vide) sur une socket e e e Une erreur O` lon voit que cette technique, du moins en TCP, ne peut tre envisage u e e pour que pour des serveurs peu sollicits. Un trop grand nombre dinterrupe tions possibles nuit ` lecacit du syst`me (changements de contexte). De a e e plus la distinction entre les causes du signal est dicile ` faire, donc ce signal a en TCP est quasi inexploitable. Conclusion : La dnomination programmation asynchrone base seulement sur e e lusae du signal SIGIO (versus SIGPOLL) est abusive. Pour tre vraiment e asynchrones, ces oprations de lecture et dcriture ne devraient pas tre ase e e sujetties au retour des primitives read ou write9 . Cette technique permet lcriture du code de petits serveurs bas sur le protocole UDP (En TCP e e les causes de rception dun tel signal sont trop nombreuses) sans fork ni e thread.

La norme POSIX permet un tel comportement avec les primitives aio read et aio write

La primitive select

247

2.5

La primitive select

Un serveur qui a la charge de grer simultanment plusieurs sockets (sere e veur multi-protocoles par exemple, comme inetd. . .) se trouve par construction dans une situation o` il doit examiner en mme temps plusieurs descripu e teurs (il pourrait sagir aussi de tubes de communication). Il est absolument dconseill dans cette situation de faire du polling. e e Cette activit consisterait ` examiner chaque descripteur lun apr`s lautre e a e dans une boucle innie qui devrait tre la plus rapide possible pour tre la e e plus ractive possible face aux requtes entrantes. Sous Unix cette opration e e e entra une consommation exagre des ressources cpu, au dtriment des ne ee e autres usagers et services. La primitive select (4.3 BSD) surveille un ensemble de descripteurs, si aucun nest actif le processus est endormi et ne consomme aucune ressource cpu. D`s que lun des descripteurs devient actif (il peut y en avoir plusieurs e ` la fois) le noyau rveille le processus et lappel de select rend la main a e ` la procdure appelante avec susemment dinformation pour que celle-ci a e puisse identier quel(s) descripteur(s) justie(nt) son rveil ! e
#include #include <sys/types.h> <sys/time.h> *readfs, *writefs, *exceptfs, timeval *timeout) ; /* /* /* /* Tous les bits a zero. Positionne fd dans fdset Retire fd de fdset Teste la presence de fd */ */ */ */ */ */ */

int select (int maxfd, fd_set fd_set fd_set struct

FD_ZERO(fd_set *fdset) ; FD_SET(int fd, fd_set *fdset) ; FD_CLR(int fd, fd_set *fdset) ; FD_ISSET(int fd, fd_set *fdset) ; struct timeval { long tv_sec ; long tv_usec ; } ;

/* Cf "time.h" /* Nombre de secondes. /* Nombre de micro-secondes.

Le type fd set est dcrit dans <sys/types.h>, ainsi que les macros e FD XXX. Le prototype de select est dans <sys/time.h>. La primitive select examine les masques readfs, writefs et exceptfs et se comporte en fonction de timeout : Si timeout est une structure existante (pointeur non nul), la primitive retourne immdiatement apr`s avoir test les descripteurs. Tous les e e e champs de timeout doivent tre ` 0 ( polling dans ce cas). e a Si timeout est une structure existante (pointeur non nul), et si ses champs sont non nuls, select retourne quand un des descripteurs est

248

e Elments sur les serveurs prt, et en tout cas jamais au del` de la valeur prcise par timeout e a e e (cf MAXALARM dans <sys/param.h>). Si timeout est un pointeur NULL, la primitive est bloquante jusqu` a ce quun descripteur soit prt (ou quun signal intervienne). e Remarque : select travaille au niveau de la micro-seconde, ce que ne fait pas sleep (seconde), do` un usage possible de timer de prcision. u e readfs descripteurs ` surveiller en lecture. a writefs descripteurs ` surveiller en criture. a e exceptfs Ce champ permet de traiter des evnements exceptionnels sur les e descripteurs dsigns. Par exemple : e e Donnes out-of-band sur une socket. e Contrle du statut sur un pseudo-tty ma o tre. maxfd prend ` lappel la valeur du plus grand descripteur ` tester, plus a a un. Potentiellement un syst`me BSD (4.3 et versions suivantes) permet e dexaminer jusqu` 256 descripteurs. a A lappel, le programme prcise quels sont les descripteurs ` surveiller e a dans readfs, writefs et exceptfs. Au retour, la primitive prcise quels sont les descripteurs qui sont e actifs dans les champs readfs, writefs et exceptfs. Il convient donc de conserver une copie des valeurs avant lappel si on veut pouvoir les rutiliser ultrieurement. La primitive renvoie -1 en cas derreur (` tester e e a systmatiquement) ; une cause derreur classique est la rception dun signal e e (errno==EINTR). La macro FD ISSET est utile au retour pour tester quel descripteur est actif et dans quel ensemble. Le serveur de serveurs inetd (page 4) est un excellent exemple dutilisation de la primitive.

La primitive poll

249

2.6

La primitive poll

La primitive poll (System V) permet la mme chose que la primitive e select, mais avec une approche dirente. e
#include <poll.h> int poll(struct pollfd *fds, unsigned int nfds, int timeout); struct pollfd { int fd ; /* Descripteur de fichier */ short events ; /* Evenements attendus */ short revents ; /* Evenements observes */ } ;

La primitive retourne le nombre de descripteurs rendus disponibles pour eectuer des oprations dentre/sortie. -1 indique une condition derreur. 0 e e indique lexpiration dun dlai ( time-out ). e fds est un pointeur sur la base dun tableau de nfds structures du type struct pollfd. Les champs events et revents sont des masques de bits qui param`trent respectivement les souhaits du programmeur et ce que le e noyau retourne. On utilise principalement : POLLIN POLLOUT POLLERR POLLHUP nfds Taille du vecteur. timeout Est un compteur de millisecondes qui prcise le comportement de e poll : Le nombre de millisecondes est positif strictement. Quand le temps prvu est coul, la primitive retourne dans le code de lutilisateur e e e mme si aucun vnement nest intervenu. e e e Le nombre de millisecondes est INFTIM (-1), la primitive est bloquante. 0. La primitive retourne immdiatement. e On sapperoit immdiatement que la valeur du param`tre de timeout c e e nest pas compatible ni en forme ni en comportement entre select et poll.

250

e Elments sur les serveurs

Fonctionnement des daemons

Sous Unix les serveurs sont implments le plus souvent sous forme de e e daemons10 . La raison principale est que ce type de processus est le plus adapt e ` cette forme de service, comme nous allons lexaminer. a

3.1

Programmation dun daemon

Les daemons sont des processus ordinaires, mais : ils ne sont pas rattachs ` un terminal particulier (ils sont en arri`re e a e plan ) ; ils sexcutent le plus souvent avec les droits du super-utilisateur , e voire, mieux, sous ceux dun pseudo-utilisateur sans mot de passe ni shell dni. e ils sont le plus souvent lancs au dmarrage du syst`me, lors de e e e lexcution des shell-scripts de conguration (par exemple ` partir de e a /etc/rc) ; ils ne sarrtent en principe jamais (sauf bien sr avec le syst`me !). e u e La conception dun daemon suit les r`gles suivantes : e 1. Excuter un fork, terminer lexcution du p`re et continuer celle du e e e ls qui est alors adopt par init (traditionnellement cest le processus e N 1). Le processus ls est alors dtach du terminal, ce que lon peut e e visualiser avec un ps -auxw (versus ps -edalf sur un syst`me V) en e examinant la colonne TT : elle contient ? ? ; 2. Appeler la primtive setsid pour que le processus courant devienne leader de groupe (il peut y avoir un seul processus dans un groupe) ; 3. Changer de rpertoire courant, gnralement la racine (/) ou tout autre e e e rpertoire ` la convenance de lapplication ; e a 4. Modier le masque de cration des chiers umask = 0 pour que le e troisi`me argument de open ne soit pas biais par la valeur du umask e e lorsque cette primitive sert aussi ` crer des chiers ; a e 5. Fermer tous les descripteurs devenus inutiles, et en particulier 0, 1 et 2 (entre et sorties standards nont plus de sens pour un processus e dtach dun terminal). e e le source ci-apr`s est un exemple de programmation de daemon, les appels e ` la fonction syslog font rfrence ` un autre daemon nomm syslogd que a ee a e nous examinons au paragraphe suivant.
Si lon en croit la premi`re dition de UNIX System Administration Handbook , e e Nemeth, Synder & Seebass, pp 403-404 :Many people equate the word daemon with the word demon implying some kind of Satanic connection between UNIX and the underworld. This is an egregious misunderstanding. Daemon is actually a much older form of demon ; daemons have no particular bias towards good or evil, but rather serve to help dene a persons character or personality.
10

Daemon syslogd
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

251

/* $Id: diable.c,v 1.2 2002/01/08 21:12:50 fla Exp $ * * Diablotin : exemple de dmon miniature... */ #include #include #include #include #include #include #include <stdio.h> <stdlib.h> <unistd.h> <sys/types.h> <sys/stat.h> <syslog.h> <errno.h>

int main() { switch (fork()) { case 1 : perror("fork") ; exit (1) ;

/* erreur du "fork".

*/

case 0 : /* Le futur "demon". */ (void)printf("Je suis infernal, je me transforme en demon !\n") ; (void)setsid() ; /* Devenir chef de groupe. */ (void)chdir("/") ; /* Repertoire de travail. */ (void)umask(0) ; (void)close(0) ; (void)close(1) ; (void)close(2) ; openlog("diablotin",LOG_PID|LOG_NDELAY,LOG_USER) ; syslog(LOG_INFO,"Attention, je suis un vrai daemon...\n") ; (void)sleep(1) ; (void)syslog(LOG_INFO,"Je me tue !\n") ; closelog() ; exit(EX_OK) ; default : exit(EX_OK) ; } }

diable.c

3.2

Daemon syslogd

Du fait de leur fonctionnement dtach dun terminal, les daemons ne e e peuvent plus dlivrer directement de message par les canaux habituels e (perror. . .). Pour pallier ` cette dcience un daemon est spcialis dans a e e e 11 lcoute des autres daemons (coute passive :), il sagit de syslogd . e e Pour dialoguer avec ce daemon un programme doit utiliser les fonctionnalits que le lecteur trouvera tr`s bien dcrites dans man syslog, sinon e e e le paragraphe 3.4 en donne un aperu rapide. c La gure 3 suivante schmatise le circuit de linformation dans le cas e dune utilisation de syslogd. Le chier /etc/syslog.conf est le chier standard de conguration du daemon syslogd. Il est constitu de lignes de deux champs : un dclencheur e e
11

Ce rle stratgique lui vaut dtre lanc le premier et dtre stopp le dernier o e e e e e

252

e Elments sur les serveurs (selector) et une action. Entre ces deux champs un nombre quelconque de tabulations.
processus 1 processus 2 processus 3

/dev/log syslogd distant (msg UDP)

Noyau

kill HUP cat /var/run/syslog.pid syslogd /etc/syslog.conf

/var/log/XXXX /dev/console

syslogd distant (msg UDP)

terminal utilisateur

gure XIII.03 Si les conditions du dclencheur sont remplies laction est excute, plus e e e prcisement : e Le dclencheur est un ltre qui associe un type de daemon avec un niveau e de message. Par exemple mail.debug signie les messages de niveau DEBUG pour le syst`me de routage du courrier. e Les mots clefs possibles pour le type de daemon sont auth, authpriv, cron, daemon, kern, lpr, mail, news, syslog, user, uucp, et local0 ` local7. Une toile ( ) ` la place, signie nimporte quel a e a mot clef. Le niveau de message est lun des mots clefs suivants : emerg, alert, crit, err, warning, notice, et debug. Une toile ( ) signie nime porte lequel. Un point () spare les deux parties du ltre, comme dans e mail.debug. Dans les syslog plus volus ladministrateur a la possibilit de drouter e e e e tous les messages contenant un nom de programme ( !nom du prog) ou un nom de machine (+nom de machine) Laction est soit : Un chier dsign par un chemin absolu, comme /var/log/syslog. e e Une liste de logins dutilisateurs, comme root,fla. . . Un nom de machine distante (@machine.domaine.fr) Tous les utilisateurs connects avec une toile . e e

Fichier syslog.conf

253

3.3

Fichier syslog.conf
/dev/console /var/log/messages /var/log/maillog /var/log/lpd-errs /var/cron/log root root root * |/usr/local/bin/traitinfo /var/log/diablotin.log

Exemple de chier /etc/syslog.conf :

*.err;kern.debug;auth.notice;mail.crit *.notice;kern.debug;lpr,auth.info;mail.crit mail.info lpr.info cron.* *.err *.notice;auth.debug *.alert *.emerg *.info !diablotin *.*

Rsultat de lexcution de diablotin sur la machine glups, et dans le e e chier /var/log/diablotin.log :

... Jan 27 18:52:02 glups diablotin[20254]: Attention, je suis un vrai daemon... Jan 27 18:52:03 glups diablotin[20254]: Je me tue ! ...

3.4

Fonctions syslog

Les prototypes et arguments des fonctions : #include <syslog.h> void openlog(const char *ident, int logopt, int facility) ; void syslog(int priority, const char *message, ...) ; void closelog(void) ; Comme dans lexemple de diablotin , un programme commence par dclarer son intention dutiliser le syst`me de log en faisant appel ` la fonce e a tion openlog : logopt Donne la possibilit de prciser o` le message est envoys et dans e e u e quelle condition. facility Est ltiquette par dfaut des futurs messages envoys par syslog. e e e logopt LOG LOG LOG LOG CONS NDELAY PERROR PID description Ecriture sur /dev/console. Ouverture immdiate de la connexion avec syslogd. e Ecriture dun double du message sur stderr. Identier chaque message avec le pid.

254 facility LOG LOG LOG LOG LOG LOG LOG LOG LOG LOG LOG LOG AUTH AUTHPRIV CRON DAEMON KERN LPR MAIL NEWS SYSLOG USER UUCP LOCAL0 description

e Elments sur les serveurs

Services dauthentication. Idem ci-dessus. Le daemon qui g`re les procdures batch. e e Tous les daemons du syst`me, comme gated. e Messages du noyau. Messages du gestionnaire dimprimante. Messages du gestionnaire de courrier. Messages du gestionnaire de news . Messages du daemon syslogd lui-mme. e Messages des processus utilisateur (defaut). Messages du syst`me de transfert de chiers. e Rserv pour un usage local. e e

Puis chaque appel ` la fonction syslog est compos dun message (gnr a e e ee par lapplication) et dun code de priorit, compos dun niveau durgence e e prcis par le tableau ci-dessous (niveaux dcroissants) et dune tiquette e e e e optionnelle, prise dans le tableau ci-dessus ; elle prime alors sur celle prcise e e lors du openlog. priority LOG LOG LOG LOG LOG LOG LOG LOG EMERG ALERT CRIT ERR WARNING NOTICE INFO DEBUG description Une condition de panic system . Intervention immdiate requise. e Probl`mes de matriels e e Erreurs. Messages davertissement. Messages qui ne sont pas des erreurs. Informations sans consquence. e Messages pour le debug.

Enn le closelog matrialise la n dutilisation de ce syst`me dans le e e code.

4 Exemple de daemon inetd

255

Exemple de daemon inetd

Dans cette partie nous allons tudier un serveur de serveurs nomm inetd e e qui est un tr`s bel exemple pour conclure ce chapitre. e Ce chapitre pourra se prolonger par la lecture du code source C dinetd.

4.1

Prsentation de inetd e

Sous Unix on peut imaginer facilement que chacun des services rseaux e oerts soient programms comme un daemon, avec une ou plusieurs sockets, e chacun surveillant son ou ses ports de communication. Un tel fonctionnement existe, gnralement repr par le vocabulaire e e ee stand alone . Avec cette stratgie, chaque service comme ftp , rlogin , e ou encore telnet fait lobjet dun processus daemon ( daemon ). Avant la version 4.3 de BSD, cest comme cela que tous les services fonctionnaient. Le probl`me est que pour faire fonctionner les services de base du e rseau on devait maintenir en mmoire (primaire en ram ou secondaire e e sur la zone de swap ) un grand nombre de processus souvent compl`tement e inutiles ` un instant donn, simplement au cas ou. . . a e Linconvnient de cette stratgie est la consommation importante de rese e sources surtout avec le nombre croissant des services rseaux de base . e De plus, on peut remarquer que lancs au dmarrage de la machine, tous e e ces processus eectuent des oprations similaires (cf 3), seuls di`rent les e e traitements propres aux serveurs eux-mmes cest ` dire ceux qui rel`vent du e a e protocole de lapplication. La version 4.3 de BSD a apport une simplication en introduisant une e nouvelle notion, celle de serveur de serveurs : The Internet superserver inetd . Cest un daemon que peuvent utiliser tous les serveurs TCP/UDP. Inetd fournit essentiellement deux services principaux : 1. Il permet ` un seul processus (celui dinetd) dattendre de multiples a demandes de connexions au lieu davoir 1 processus par type de connexion. Cette stratgie rduit dautant le nombre de processus. e e 2. Il simplie lcriture des serveurs eux-mmes, puisquil g`re toute la e e e prise en charge de la connexion. Les serveurs lisent les requtes sur leur e entre standard et crivent la rponse sur leur sortie standard. e e e Inetd est un serveur parall`le en mode connect ou data-gramme. De plus e e il combine des caractristiques particuli`res, puisquil est galement multie e e protocoles et multi-services. Un mme service peut y tre enregistr et accese e e sible en udp comme en tcp. Bien sr cela sous entend que le programmeur u de ce service ait prvu ce fonctionnement. e Le prix ` payer pour une telle souplesse est lev, inetd invoque fork a e e puis exec pour pratiquement tous les services quil ore (cf lecture de code). Sur les Unix ` architecture Berkeley, inetd est invoqu au dmarrage de a e e la machine, dans les scripts de lancement, /etc/rc par exemple. D`s le dbut e e de son excution il se transforme en daemon (cf paragraphe IV.5.3) et lit un e

256

e Elments sur les serveurs chier de conguration gnralement nomm /etc/inetd.conf. Ce chier e e e est en ASCII, il est lisible normalement par tous, cependant, sur certains sites et pour des raisons de scurit, il peut ne pas ltre. e e e La gure XIII.04 montre larchitecture gnrale (tr`s simplie) de fonce e e e tionnement.

socket () Pour chaque services bind () listen () (socket TCP) select () accept() (socket TCP) fork () pre close () (socket TCP) fils close() descr. autres que la socket. dup () socket vers 0,1 et 2 close (socket) setgid () setuid () (si non root) exec () (du serveur) trouv dans /etc/inetd.conf

gure XIII.04 Le chier /etc/inetd.conf est organis de la mani`re suivante : e e Un # en dbut de ligne indique un commentaire, comme pour un shelle script. Les lignes vides ne sont pas prises en compte. Les lignes bien formes sont constitues de 7 champs. Chaque ligne bien e e forme dcrit un serveur. e e Description des champs : 1. Le nom du service, qui doit galement se trouver dans le chier e /etc/services. Cest grce ` lui que inetd connait le numro de a a e port ` employer a 2. Le type de socket, connecte (stream) ou non (dgram). e

Exemple de daemon inetd 3. Le protocole qui doit tre tcp ou udp et doit en tout cas se troue ver dans le chier /etc/protocols. Ce dernier chier donne une correspondance numrique aux dirents protocoles. e e 4. wait ou nowait suivant que le serveur est itratif ou parall`le. e e 5. Le nom du propritaire (pour les droits ` lexcution). Le plus e a e souvent cest root, mais ce nest pas une r`gle gnrale. e e e 6. Le chemin absolu pour dsigner lexcutable du serveur. e e 7. Les arguments transmis ` cet excutable lors du exec, il y en a e a 20 au maximum dans les implmentations Berkeley de inetd e (certaines re-critures, comme celle dHP, limitent ce nombre). e

257

258

e Elments sur les serveurs

Bibliographie

Pour la partie architecture/conguration des serveurs : W. Richard Stevens Unix Network Programming Prentice All 1990 W. Richard Stevens Unix Network Programming Volume 1 & 2 Second edition Prentice All 1998 W. Richard Stevens Advanced Programming in the UNIX Environment AddisonWesley 1992 Douglas E. Comer David L. Stevens Internetworking with TCP/IP Volume III (BSD Socket version) Prentice All 1993 Stephen A. Rago Unix System V Network Programming AddisonWesley 1993 Man Unix de inetd, syslog, syslogd et syslog.conf. Pour la programmation des threads : David R. Butenhof Programming with POSIX Threads AddisonWesley 1997 Bradford Nichols, Dirsk Buttlar & Jacqueline Proulx Farell Pthreads programming OReilly & Associates, Inc. 1996 Et pour aller plus loin dans la comprhension des mcanismes internes : e e McKusick, Bostik, Karels, Quaterman The Design and implementation of the 4.4 BSD Operating System Addison Wesley 1996 Jim Mauro, Richard McDougall Solaris Internals Sun Microsystems Press 2001 Uresh Vahalia Unix Internals, the new frontiers Prentice Hall 1996

Index
aio read, 246 aio write, 246 close, 200, 203 exec, 243 fork, 203, 242, 250 open, 200 read, 200 rfork, 242 socket, 177, 201 vfork, 242, 243 write, 200 10Base2, 14, 14 10Base5, 13, 13--14 10BaseT, 14--15 RJ45, 14 127.0.0.1, 34 802.2, 9 802.3, 9 accept, 209--210 active open, voir ouverture active adresse de loopback, 34 Adresse IP, voir IP adresse IP prive, 32 e adresse IP publique, 32 AF, 202, voir Address Family AFNIC, voir Association Franaise pour le c Nommage Internet en Coopration e AfriNIC, 32 Algorithme concourant - Mode connect, 241 e Algorithme concourant - Mode datagramme, 240 algorithme de routage, voir routage Algorithme Itratif - Mode e connect, 240 e Algorithme itratif - Mode e data-gramme, 239 alias IP, 41, 175 API, voir Application Program Interface APNIC, 32 Application Program Interface, 199 ARIN, 32 ARP, 50, 55 Fonctionnement, 50 Format du datagramme, 52 HARDWARE TYPE, 52 HLEN 1, 52 HLEN 2, 52 OPERATION, 52, 53 PROTOCOL TYPE, 52 Proxy arp, 51, 53 SENDER ADR, 52 SENDER HA, 52 TARGET ADR, 52 TARGET HA, 52 arp, voir commande Arpanet, 23, 125 Association Franaise pour c le Nommage Internet en Coopration, 3 e Authentication Header, 181 base de donnes distribue, e e 107 bases whois, 106 bcmp, 222 bcopy, 222 Berkeley Internet Name Domain, 121

260 BGP-4, 37 big endian, 213, 221 BIND, voir Berkeley Internet Name Domain bind, 204--205, 206 Bind Operations Guide, 122 BOG, voir Bind Operations Guide brodcast, 19 BSD 4.1c, 199 BSD 4.3, 200, 255 bzero, 222 cache dns, 111 CIDR, voir Classless InterDomain Routing circuit virtuel, 83, 84, 238 Classless InterDomain Routing, 37 close, 210 closelog, 253 commande arp -a, 51 gated, 62 httptunnel, 177 ifconfig, 177 inetd, 237, 247, 255--257 init, 250 ipf, 189 ipfw, 189 mutt, 127 named, 121 natd, 187, 194 netstat -rn, 63 nsupdate, 115 ping, 107, 178 ps, 250 route, 62, 177 routed, 62 sendmail, 129 sshd, 177 syslogd, 189, 250 tcpdump, 178, 215, 216, 226 traceroute, 107

INDEX commutateur, 19--20 ISH, 19 VLAN, 20 Commutation de paquets, 4 concentrateur, 17 concurrent server, voir serveur concourant congestion avoidance, 96 congestion window, 96 connect, 205 CRLF, 127 CSMA/CD, 9, 18 Cyclades, 23 daemon, 181, 250--251 Darpa, 23 DATA, 132 datagramme, 41 Dave Clark, 83 David H. Crocker, 127 descripteur de socket, 200 DHCP, 116 diablotin, 253 Diffie-Hellman, 115 DNS, voir serveur de noms dns dynamique, 105 DNSSEC, 114 domain completion, 108 domaine, 105 Douglas E. Comer, 104 dynamic update, 115 dyndns, voir dns dynamique EINTR, 248 en-t^te e 802.2/802.3, 12 ARP, 52 Ethernet, 10 ICMP, 55 IGMP, 58 IP, 44 RARP, 52 TCP, 85 UDP, 78 Encapsulating Security Payload, 181

INDEX Ethernet, 9, 9--11 transceiver , 9 collision, 10 format dune trame, 10 Ethernet fin, voir 10Base2 Ethernet standard, voir 10Base5 FAI, voir Fournisseur dAcc`s e Internet fcntl, 246 FD CLR, 247 FD ISSET, 247, 248 FD SET, 247 FD ZERO, 247 fen^tres glissantes, 92 e Fibre optique, 15 fichier /etc/bootptab, 53 /etc/host.conf, 110 /etc/hosts, 103, 108, 223 /etc/inetd.conf, 256 /etc/nsswitch, 110 /etc/protocols, 177, 228, 257 /etc/rc, 250 /etc/rc.firewall, 189, 190 /etc/resolv.conf, 108, 108--109 /etc/services, 79, 129, 205, 212, 219, 256 /etc/syslog.conf, 252 /var/log/syslog, 252 named.boot, 117, 121 named.conf, 117, 121 named.root, 112 resolv.conf, 110 syslog.conf, 253 FIFO, voir pile FIFO Firefox, 24 Fournisseur dAcc`s Internet, e 32 FQDN, voir Fully Qualified Domain Name, 119 frame, voir trame full duplex, 85, 203 Fully Qualified Domain Name, 107 gated, voir commande gateway, voir passerelle generic tunnel interface, 177 gethostbyaddr, 226 gethostbyname, 108, 110, 224 getprotobyname, 228 getprotobynumber, 228 getservbyname, 226, 228 getservbyport, 227, 228 gif, voir generic tunnel interface HELO, 131 HUB, 14 hub, voir concentrateur IANA, 40, 80 ICANN, voir Internet Corporation for Assigned Names and Numbers IEEE802.x vs Ethernet, 11 IETF, 37 IMAP, 143 in-addr.arpa, 113 inaddr.arpa, 113--119 index addr, 223 inet ntoa, 223 Interface de loopback , 70 Internet Corporation for Assigned Names and Numbers, 32, 40 Internet Key Exchange, 181 Internet Software Consortium, 3, 121 inverse queries, voir question inverse IP, 43 adresse, 31--41 CIDR, 37--38 classe A, 33 classe B, 33 classe C, 33

261

262 classe exprimentale, 34 e de broadcast, 34, 38 multicast, 39--41 sous-rseaux, 35--36 e unicast, 34 DESTINATION ADDRESS, 46 FLAG, 49 FLAGS, 45, 48 Dont Fragment bit , 47 More fragment , 48 FRAGMENT OFFSET, 45, 48 fragmentation, 47, 77 HEADER CHECKSUM, 45, 49 HLEN, 44 ICMP, 28, 54 Destination Unreachable , 56 Echo Reply , 56 Echo Request , 56 Redirect , 57, 62 Router solicitation , 57 Source Quench , 57 Time exceeded , 57 router advertisement , 68 router sollicitation , 68 CHECKSUM, 55 CODE, 55, 57 Format des messages, 55 TYPE, 55 IDENTIFICATION, 45, 48, 49 IGMP, 28, 40, 58 protocole, 59 MTU, 43, 45--47, 77, 93, 176 OFFSET, 49 OPTIONS, 46 PADDING, 46 PROTOCOL, 45, 76 Rassemblage, 48 e SOURCE ADDRESS, 45 TOTAL LENGTH, 45, 48, 49

INDEX TTL, 45, 57, 60 TYPE OF SERVICE, 45 VERS, 44 IP aliasing, voir alias ip IP payload compression, 181 IPFIREWALL, 189 IPFIREWALL VERBOSE, 189 IPsec, 180--184 AH, voir Authentication Header ESP, voir Encapsulating Security Payload IKE, voir Internet Key Exchange IPcomp, voir IP payload compression mode transport, 182 mode tunnel, 182 SA, voir Security Association SPI, voir Security Parameter Index ipv6, 104, 184, 229 ISC, voir Internet Software Consortium ISN, voir Initial Sequence Number ISO 3166, 106 iterative server, voir serveur itratif e Jon Postel, 23, 75, 83 Jonathan B. Postel, 129 KAME, 184 Konqueror, 24 LACNIC, 32 LAN, 3, 7--8 libc, 108, 110, 121 LIR, voir Local Internet Registry listen, 209 little endian, 213, 221 Local Internet Registry, 33 Louis Pouzin, 23

INDEX MAIL, 132 mailing-list, 125 MAN, 8 Mbone, 60 md5, 115 memcmp, 223 memcpy, 223 memset, 223 message, 41 mode connect, 84, 203, 206, 208 e datagramme, 77, 84, 203, 206 mode connect, 238 e mode datagramme, 238 Mosaic, 24 Mozilla, 24 MSA, 133 MTA, 133 MUA, 133 multi-homed, 41 multicast, 19 224.0.0.1, 39, 59, 68 224.0.0.2, 39, 68 224.0.0.255, 60 adresse MAC, 40 groupe, 39 IGMP, voir IP IGMP mutex, 244 neud, 105 name daemon control program, 122 name server control utility, 122 National Science Foundation, 24 NBO, voir network Byte Order ndc, voir name daemon control program Netscape, 24 netstat, voir commande network Byte Order, 212 network byte order, 44, 221, 226 Network Information Center, 104, 106 NIC, voir Network Information Center NIS, 108, 223 nommage absolu, 107 nommage relatif, 107 notify, 117 NSF, voir National Science Foundation numro de port, 75, 200, 212, e 219 numro de service, voir numro e e de port open mail relay, 136 openlog, 253 orderly release, 89 OSI 7 couches de l, 5 application, 5 donne, 9 e donnes, 5, 12 e LLC, 12 MAC, 12 physique, 5 prsentation, 5 e rseau, 5 e session, 5, 27 transport, 5 OSPF, 37 ouverture active, 88 ouverture passive, 88 paires torsades, voir 10BaseT e paquet, 41 passerelle, 8, 20--21, 41 routeur, 20 passive open, voir ouverture passive Paul Baran, 4 PF, 202, voir Protocol Family pile ARPA, 26, 180, 238 pile FIFO, 77 poids faible, 221 poids fort, 221

263

264 Point to Point Protocol, 142 poll, 249 POLLERR, 249 POLLHUP, 249 POLLIN, 249 polling, 247 POLLOUT, 249 pont, 18--19 POP, voir Post Office Protocol, 142 port, voir numro de port e Post Office Protocol, 142 PPP, voir Point to Point Protocol primary server, voir serveur principal querie reverse, voir question inverse question inverse, 112 quintuplet, 84, 203, 205 QUIT, 132 rpteur, 16--17 e e rseau dinterconnexion, 177 e rseau virtuel, 41 e Rseaux IP europen, 32 e e RARP, 53, 55 bootp, 53 dhcp, 53 RCPT, 132, 136 read, 208 readv, 208 recv, 208 recvfrom, 208 recvmsg, 208 Regional Internet Registries, 32 relay mail, 134, 135 remote procedure call, 219 repeater, voir rpteur e e Requests For Comments, 25 resolver, 108, 108--109, 110, 223 Resource Record, voir RR, 138

INDEX RFC, voir Requests For Comments RFC 1025, 86 RFC 1034, 107, 113 RFC 1035, 77, 117 RFC 1042, 9 RFC 1112, 58 RFC 1631, 185 RFC 1700, 11, 34, 39, 40, 80 RFC 1878, 35 RFC 1918, 32, 177, 185 RFC 1919, 185 RFC 1939, 142 RFC 2030, 143 RFC 2136, 115 RFC 2144, 181 RFC 2364, 176 RFC 2401, 180, 181 RFC 2402, 181 RFC 2405, 181 RFC 2406, 181 RFC 2409, 181 RFC 2451, 181 RFC 2476, 133 RFC 2516, 176 RFC 2535, 116 RFC 2845, 115 RFC 2930, 115 RFC 768, 75 RFC 791, 23 RFC 793, 83 RFC 821, 129 RFC 822, 125, 127 RFC 826, 50 RFC 867, 212 RFC 894, 9 RFC 896, 95 RFC 903, 53 RFC 922, 38 RFC 950, 35, 54 RFC 1256, 68 RFC 1700, 219 RIP, voir routage RIP-2, 37 RIPE, voir Rseaux IP europen e e

INDEX RIR, voir Regional Internet Registries RJ45, voir 10BaseT rndc, voir name server control utility root name server, voir serveur racine round trip time, 87, 91 routage, 61--69 algorithme de, 65 classless, 37 dcouverte de routeurs, 68 e direct, 61 dynamique, 66 indirect, 61 OSPF, 68 redirection, 69 RIP, 67 statique, 64 table de, 62 routed, voir commande RPC, voir remote procedure call RR, 117 A, 117, 119 CNAME, 120 HINFO, 120 KEY, 116, 120 MX, 117, 119, 138 NS, 117, 118--119 PTR, 117, 119 SOA, 105, 112, 117, 118 TXT, 120 WKS, 120 RTT, voir round trip time s-mail, 125 sans fil, 18 secondary server, voir serveur secondaire Security Association, 182 Security Parameter Index, 182 select, 247--248 send, 206--207 sendmsg, 206--207 sendto, 206--207 serveur concourant, 238 serveur de noms, 223 serveur de serveurs, voir inetd serveur itratif, 237 e serveur principal, 105, 112 serveur racine, 112 serveur secondaire, 105, 112 setsid, 250 shutdown, 210 SIGIO, 242, 246 SIGPOLL, 246 Simple Mail Transfert Protocol, 129 sliding windows, voir fen^tres e glissantes slow start, 96 SMTP, voir Simple Mail Transfert Protocol SO LINGER, 90 socket, 202--203 IPPROTO ICMP, 203, 228 IPPROTO IP, 228 IPPROTO RAW, 203 IPPROTO TCP, 203, 228 IPPROTO UDP, 203, 228 PF APPLETALK, 202 PF CCITT, 202 PF INET, 202 PF INET6, 202 PF IPX, 202 PF ISO, 202 PF LOCAL, 202 PF SNA, 202 SOCK DGRAM, 203 SOCK RAW, 203 SOCK STREAM, 203 source gethostbyname.c, 224 spam, 135--137 Spanning Tree Protocol, 19 static nat, 187 STP, voir Spanning Tree Protocol structure sockaddr, 204

265

266 structure sockaddr in, 204 subnet address, voir Adresse de sous-rseau e switch, voir commutateur syslog, 122, voir commande syslogd, 253 syslogd, 251--252 table de routage, voir routage TCP, 83 ACKNOWLEDGEMENT NUMBER, 85 CHECKSUM, 86 CODE, 86 ACK, 85, 86 ACNOWLEDGMENT NUMBER, 86 FIN, 86 PUSH, 86 RST, 86, 210 SYN, 86, 93 URGENT POINTER, 86 DESTINATION PORT, 85 Initial Sequence Number, 85 OFFSET, 85 OPTIONS, 86 mss, 87, 93 nop, 87 timestamp, 87 PADDING, 87 RESERVED, 86 SEQUENCE NUMBER, 85, 89 SOURCE PORT, 85 URGENT POINTER, 86 WINDOW, 86, 93 the internet superserver, voir inetd Thick Ethernet, voir 10Base5 Thin Ethernet, voir 10Base2 threads kernel, 245 threads user land, 245 three-way handshake, 89 time sharing, 242 TKERY, voir Transaction Key TKEY, 114 TLD, voir top levels domains TLI, voir Transport Layer Interface

INDEX top levels domains, 106 trame, 41 Transaction Key, 115 Transaction SIGnature, 115 transfert de zone, 117 Transport Layer Interface, 199 TSIG, 114, voir Transaction SIGnature Tunnel IP, 176 Twisted Pair, voir 10BaseT UDP, 75 CHECKSUM, 78 DESTINATION PORT, 78 MESSAGE LENGTH, 78 SOURCE PORT, 78 umask, 250 Universit de Berkeley, 23 e UUCP, 129 Virtual Private Network, 180 VPN, voir Virtual Private Network, 182 W. Richard Stevens, 95 WAN, 8 wireless, voir sans fil write, 206--207 writev, 206--207 wscale, 86, 87 zone, 105 zone reverse, 113