Vous êtes sur la page 1sur 282

Cours dintroduction ` a TCP/IP

Fran cois Laissus <fr . laissus [at] laissus . fr> Version du 20 f evrier 2005

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

Les sources de ce document sont edit ees sous Unix (FreeBSD) ` a laide de l editeur de texte vi, et g er es avec cvs. Lensemble du processus de fabrication est d ecrit dans un chier Makefile (commande make). A La mise en forme seectue gr ace au logiciel L TEX. Les gures sont dessin ees sous X Window (X11) ` a laide du logiciel xfig et int egr ees directement dans le document nal sous forme de PostScript encapsul e. Les listings des exemples de code C ont et e fabriqu es ` a laide du logiciel a2ps et inclus dans le document nal egalement en PostScript encapsul e. La sortie papier a et e imprim ee en PostScript sur une imprimante de type laser, avec dvips. La version pdf est une transformation du format PostScript ` a laide du logiciel pspdfm, enn la version HTML est traduite directement A en HTML ` a partir du format L TEX ` a laide du logiciel latex2html. Tous les outils ou formats cit es dans ce paragraphe sont en acc` es ou usage libre, sans versement de droit ` a leurs auteurs respectifs. Quils en soient remerci es ! Je remercie egalement Jean-Jacques Dh enin et les nombreux lecteurs que je ne connais quau travers de leur e-mails, davoir bien voulu prendre le temps de relire lint egralit e de ce cours et de me faire part des innombrables erreurs et coquilles typographiques quil comportait, merci encore !

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

Table des mati` eres


Pr eface xv

A
I

Introduction ` a la pile ARPA


R eseaux locaux 1 Pr eambule . . . . . . . . . . . . . . . . . 2 G en eralit es - LANs . . . . . . . . . . . . 2.1 G en eralit es . . . . . . . . . . . . 2.2 Mod` ele de communication ISO . 3 R eseaux locaux . . . . . . . . . . . . . . 3.1 Quest-ce quun LAN ? . . . . . . 3.2 WAN - MAN . . . . . . . . . . . 3.3 Communications inter-r eseaux . . 4 Couche 2 - Liaison (Data Link) . . . . . 4.1 Caract eristiques dEthernet . . . 4.2 Di erences Ethernet - 802.2/802.3 5 Interconnexion - Technologie el ementaire 5.1 Raccordement . . . . . . . . . . . 5.2 R ep eteur . . . . . . . . . . . . . . 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 ` a IP 1 TCP/IP et lInternet - Un peu dhistoire 2 Caract eristiques de TCP/IP . . . . . . . 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 e de ladresse . . . . . . . . . 1.2 D elivrance des adresses IPv4 . . . . 2 Anatomie dune adresse IP . . . . . . . . . 2.1 D ecomposition en classes . . . . . . 2.2 Adresses particuli` eres . . . . . . . . 2.3 Sous-r eseaux . . . . . . . . . . . . . 2.4 CIDR . . . . . . . . . . . . . . . . 2.5 Pr ecisions sur le broadcast . . . . . 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-t ete . . . . . . . . 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` eme de messages derreur . . . 4.2 Format des messages ICMP . . . . . 4.3 Quelques types de messages ICMP . . 5 Protocole IGMP . . . . . . . . . . . . . . . . 5.1 Description de len-t ete . . . . . . . . 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 D ecouverte de routeur et propagation 6.5 Message ICMP redirect . . . . . 6.6 Interface de loopback . . . . . . 7 Finalement, comment ca marche ? . . . . . . 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-t ete . . . . . . . . . . . . . . . . . . 77 1.3 Ports r eserv es ports disponibles . . . . . . . . . . . 79 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 Caract eristiques de TCP . . . . . . 1.2 Description de len-t ete . . . . . . . 2 D ebut et cl oture dune connexion . . . . . 2.1 Etablissement dune connexion . . 2.2 Cl oture dune connexion . . . . . . 3 Contr ole du transport . . . . . . . . . . . 3.1 M ecanisme de lacquittement . . . 3.2 Fen etres glissantes . . . . . . . . . 4 Compl ements sur le fonctionnement de TCP 4.1 Algorithme de Nagle . . . . . . . . 4.2 D epart lent . . . . . . . . . . . . . 4.3 Evitement de congestion . . . . . . 5 Paquets captur es, comment es . . . . . . . 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 G en eralit es sur le serveur de noms . . . . . . . . . 1.1 Bref historique . . . . . . . . . . . . . . . 1.2 Syst` eme hi erarchis e de nommage . . . . . 2 Fonctionnement du DNS . . . . . . . . . . . . . . 2.1 Convention de nommage . . . . . . . . . . 2.2 Le Resolver . . . . . . . . . . . . . . . 2.3 Strat egie de fonctionnement . . . . . . . . 2.4 Hi erarchie de serveurs . . . . . . . . . . . 2.5 Conversion dadresses IP en noms . . . . . 2.6 Conclusion . . . . . . . . . . . . . . . . . . 3 S ecurisation du DNS . . . . . . . . . . . . . . . . 3.1 TSIG/TKEY pour s ecuriser les transferts . 3.2 DNSSEC pour s ecuriser les interrogations 4 Mise ` a jour dynamique . . . . . . . . . . . . . . . 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 electronique 1 G en eralit es sur le courrier electronique . . . . . . . . 1.1 M etaphore du courrier postal . . . . . . . . . 1.2 Adresse electronique . . . . . . . . . . . . . . 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 electronique . . . . . 3.4 Courriers ind esirables - Le spam . . . . . . . . 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` egles de re ecriture . . . . . . . . . . . . . . . 5.2 Exemple de sortie de debug . . . . . . . . . . 6 Bibliographie . . . . . . . . . . . . . . . . . . . . . . IX Anatomie dun serveur Web 1 Le protocole HTTP . . . . . . . . . . . . . . . 1.1 Exemple d echange avec http . . . . . 1.2 Structure dun echange . . . . . . . . . 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 M ethode GET, sans argument 4.2 CGI M ethode GET, avec arguments 4.3 CGI M ethode POST . . . . . . . . 4.4 Ecriture dune CGI en Perl . . . . . . 5 Conclusion Bibliographie . . . . . . . . . . . ements de r X El eseaux 1 H otes ou services virtuels . . . . . . . 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 G en eralit es sur les sockets de Berkeley 1 G en eralit es . . . . . . . . . . . . . . . . 2 Pr esentation des sockets . . . . . . . . . 3 Etude des primitives . . . . . . . . . . . 4 Cr eation dune socket . . . . . . . . . . . 5 Sp ecication dune adresse . . . . . . . . 6 Connexion ` a une adresse distante . . . . 7 Envoyer des donn ees . . . . . . . . . . . 8 Recevoir des donn ees . . . . . . . . . . . 9 Sp ecier une le dattente . . . . . . . . 10 Accepter une connexion . . . . . . . . . 11 Terminer une connexion . . . . . . . . . 12 Sch ema g en eral dune connexion . . . . . 13 Exemples de code client . . . . . . . 13.1 Client TCP DTCPcli . . . . . 13.2 Client UDP DUDPcli . . . . . 14 Conclusion et Bibliographie . . . . . . .

XII Compl ements sur les sockets Berkeley 1 R eservation des ports . . . . . . . . . . . . . . . . 1.1 R eservation de port Ancienne m ethode 1.2 R eservation de port Nouvelle m ethode . 2 Ordre des octets sur le r eseau . . . . . . . . . . . 3 Op erations sur les octets . . . . . . . . . . . . . . 4 Conversion dadresses . . . . . . . . . . . . . . . . 5 Conversion h ote adresse IP . . . . . . . . . . . . 5.1 Une adresse IP ` a partir dun nom dh ote . 5.2 Un nom dh ote ` a partir dune adresse IP . 6 Conversion N de port service . . . . . . . . . . 6.1 Le num ero ` a partir du nom . . . . . . . . 6.2 Le nom ` a partir du num ero . . . . . . . . 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 ements de serveurs XIII El 1 Type de serveurs . . . . . . . . . . . . 1.1 Serveurs it eratif et concourant . 1.2 Le choix dun protocole . . . . . 1.3 Quatre mod` eles de serveurs . . 2 Technologie el ementaire . . . . . . . . 2.1 Gestion des taches esclaves . 2.2 fork, vfork et rfork . . . . . . . 2.3 Processus l egers, les threads 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 Pr esentation de inetd . . . . . 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` ele en 7 couche de lOSI . . . . . . . Exemple de LANs . . . . . . . . . . . . . trame Ethernet . . . . . . . . . . . . . . Di erences Ethernet 802.2/802.3 . . . . . Interconnexion - Technologie el ementaire Prise vampire . . . . . . . . . . . . . . . Technologie de liaison . . . . . . . . . . . R ep eteur . . . . . . . . . . . . . . . . . . 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 D ecomposition en classes . . . . . . . III.02 Sous-r eseaux . . . . . . . . . . . . . . III.03 Puissances de 2 . . . . . . . . . . . . . III.04 Adresses de multicast . . . . . . . . . III.05 Adresse physique de multicast . . . . III.06 Usage combin e des Adresses logique et IV.01 Structure du datagramme IP . IV.02 Big endian - Little endian IV.03 Fragmentation IP . . . . . . . IV.04 Fragment ` a transmettre . . . . IV.05 R esum e de la fragmentation . . IV.06 Question ARP . . . . . . . . . IV.07 R eponse ARP . . . . . . . . . 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-t ete IGMP . . . . . . . . . . . . . . IV.13 Fonctionnement IGMP . . . . . . . . . IV.14 Table de routage . . . . . . . . . . . . . IV.15 Situation r eseau lors du netstat . . . . 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 Num ero de port comme num ero de UDP encapsul e dans IP . . . . . . Structure de len-t ete UDP . . . . 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 e dans IP . . . . VI.02 Structure de len-t ete TCP . . VI.03 Etablissement dune connexion VI.04 Cl oture dune connexion . . . . VI.05 Emission dun rst . . . . . . . VI.06 M ecanisme de lacquittement . VI.07 Principe de la fen etre glissante VI.08 D etail de la fen etre glissante . VI.09 Exemple de fen etre glissante .

VII.01 Organisation hi erarchique des domaines VII.02 Le resolver . . . . . . . . . . . . . . VII.03 Subdivision hi erarchique des domaines 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` egles de re ecriture . . . . . . IX.01 IX.02 IX.03 IX.04 IX.05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Structure dun message HTTP . . . Environnement syst` eme . . . . . . . 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 concr et . . . . En-t etes dIPsec . . . . . . . . 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, num ero de port et process ID Structure dadresse . . . . . . . . . . . . . . . . Relation clientserveur en mode connect e . . . . Relation clientserveur en mode non connect e .

XII.01 Ordre des octets sur le r eseau . . . . . . . . . . . . . . . . . 221 XIII.01 Quatre types de serveurs . . . . XIII.02 Ex ecution avec et sans threads XIII.03 Syslogd . . . . . . . . . . . . . XIII.04 Inetd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 244 252 256

xii

TABLE DES FIGURES

Liste des tableaux

xiv

LISTE DES TABLEAUX

Pr eface
Attention ! Ce document nest quun support de cours, cest ` a dire quil ne remplace pas les documents cit es dans la bibliographie qui termine chacun des chapitres qui le composent.
Evidement imparfaites, pleines derreurs involontaires, et surtout incompl` etes, ces pages r eclament avant tout votre indulgence de lecteur bienveillant : rien nest constant, tout change comme le disait d ej` a Lao Tseu, 400 ans avant JC. Que dirait-il alors aujourdhui, concernant des r eseaux ! ! Ces cours saccompagnent de travaux pratiques dont le texte ne gure pas ici, ils sont principalement destin es au Mast` ere SIO, (Syst` emes Informatiques Ouverts http ://www.sio.ecp.fr/), et sont orient es Unix .

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

xvi

Pr eface

Premi` ere partie Introduction ` a la pile ARPA

Chapitre I R eseaux locaux


1 Pr eambule

Ce cours nest pas un cours g en eral sur les r eseaux mais une pr esentation minimale de cette technologie pour pouvoir aborder le cours de concepts et programmation TCP/IP sous UNIX. TCP/IP est le protocole le plus r epandu dans le monde gr ace ` a lInternet. En 1980 il ne comptait que quelques dizaines dh otes, en juin 1996 ce nombre etait de 12 millions de machines, r eparties en pr` es de 500 000 r eseaux (Par comparaison, en f evrier 1995, les m emes chires etaient 4 850 000 machines pour plus de 71 000 r eseaux locaux). Actuellement dans le monde (janvier 2003), le nombre de machines1 directement accessibles sur le r eseau serait de 180 000 000 selon lISC2 . Pour la france lAFNIC propose egalement quelques statisques3 . . .Il nexiste pas de botin g en eral du r eseau, par contre Bill Cheswick des Bell labs la cartographi e: http ://www.cs.bell-labs.com/who/ches/map/gallery/index.html

2
2.1

G en eralit es - LANs
G en eralit es

Un r eseau informatique met en relation des ordinateurs, comme un r eseau t el ephonique met en relation des personnes. Des ordinateurs sont dits en r eseaux d` es lors quils partagent une technologie qui leur permet de communiquer ensemble. Le plus souvent cette technologie se mat erialise physiquement par une liaison avec un c able conducteur. Sur ce type de support, un signal electrique v ehicule les messages informatiques. Il existe dautres types de supports en
1 2

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

R eseaux locaux pleine expansion comme les liaisons par ondes hertziennes, rayon laser, infrarouge. . . Sans connaissance pr ealable concernant les r eseaux informatiques on peut imaginer quantit e dinterrogations ` a partir de cette hypoth` ese de raccordement : Comment reconnaitre un correspondant ? Comment dialoguer avec ? Comment diuser linformation ` a plusieurs correspondants ? Comment eviter la cacophonie ? Il y a til une hi erarchie des machines ? Il y a til un chef dorchestre ? ... Toutes ces questions (et bien dautres) trouveront une r eponse dans ce cycle de cours. Ces r eponses sont g en eralement formul ees dans un protocole , une sorte de mode demploi des r eseaux. Il y a des centaines de protocoles di erents sur lInternet, certains sont tr` es populaires, dautres absolument pas.

2.2

Mod` ele de communication ISO

Le concept de base de tout ce cours est celui de la commutation de paquets , une vieille id ee de linformatique4 contrairement ` a lapproche par circuits virtuels plus utilis ee en t el ephonie. Les donn ees ` a transmettre dune machine ` a une autre sont fragment ees ` a l emission en petit blocs de quelques centaines doctets munis de ladresse du destinataire, envoy ees sur le r eseau et r e-assembl ees ` a la r eception pour reproduire les donn ees dorigine. Ce concept facilite le partage des possibilit es physiques du r eseaux (bande passante) et est parfaitement adapt e pour une impl ementation sur machines s equentielles travaillant en temps partag e (plusieurs communications peuvent alors avoir lieux simultan ement et sur une m eme machine). Partant de ce concept, un mod` ele darchitecture pour les protocoles de communication a et e d evelopp e par lISO (International Standards Organisation) entre 1977 et 1984. Ce mod` ele sert souvent de r ef erence pour d ecrire la structure et le fonctionnement des protocoles de communication, mais nest pas une contrainte de sp ecication. Ce mod` ele se nomme OSI comme Open Systems Interconnect Reference Model . Les constituants de ce mod` ele sont si largement employ es quil est dicile de parler de r eseaux sans y faire r ef erence. ` chaque couche est asLe mod` ele OSI est constitu e de sept couches. A soci ee une fonction bien pr ecise, linformation traverse ces couches, chacune y apporte sa particularit e. Cette forme dorganisation nest pas d ue au hasard, cest celle sur laquelle les informaticiens ont beaucoup travaill e dans les ann ees soixantes
4

Con cu par lAm ericain Paul Baran et publi e en 1964

G en eralit es - LANs pour d enir les caract eristiques des syst` emes dexploitation. Une couche ne d enit pas un protocole, elle d elimite un service qui peut etre r ealis e par plusieurs protocoles de di erentes origines. Ainsi chaque couche peut contenir tous les protocoles que lon veut, pourvu que ceux-ci fournissent le service demand e` a ce niveau du mod` ele. Un des int er ets majeurs du mod` ele en couches est de s eparer la notion de communication, des probl` emes li es ` a la technologie employ ee pour v ehiculer les donn ees. Pour m emoire (gure I.01) : 7 La couche application (Application layer) est constitu ee des programmes dapplication ou services, qui se servent du r eseau. Ils ne sont pas forc ement accessibles ` a lutilisateur car ils peuvent etre r eserv es ` a un usage dadministration. 6 La couche de pr esentation (Pr esentation layer) met en forme les donn ees suivant les standards locaux ou particuliers ` a lapplication. Comme, par exemple passer dune repr esentation big endian ou ` a une repr esentation little endian ou encore plus complexe comme celle d ecrite pas les XdR (eXternal Data Representation). 5 La couche de session (Session layer) eectue laiguillage entre les divers services (7) qui communiquent simultan ement ` a travers le m eme ordinateur connect e et le m eme r eseau. Deux utilisateurs dune m eme machine peuvent utiliser la m eme application sans risque dinter-actions parasites. 4 La couche de transport (Transport layer) garantie que le destinataire obtient exactement linformation qui lui a et e envoy ee. Cette couche met par exemple en uvre des r` egles de renvoi de linformation en cas derreur de r eception. 3 La couche r eseau (Network layer) isole les couches hautes du mod` ele qui ne soccupent que de lutilisation du r eseau, des couches basses qui ne soccupent que de la transmission de linformation. 2 La couche de donn ee (Data link layer) eectue le travail de transmission des donn ees dune machine ` a une autre. 1 La couche Physique (Physical layer) d enit les caract eristiques du mat eriel n ecessaire pour mettre en oeuvre le signal de transmission, comme des tensions, des fr equences, la description dune prise. . .

6 Mod` ele en 7 couche de lOSI

R eseaux locaux

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 pr ec` ede et celle qui la suit, avec le cas particulier des couches 1 et 7. Lint er et de travailler en couches est que lorsque les modalit es d echanges entre chacune dentres elles sont pr ecis ement d ecrites, on peut changer limpl ementation et les sp ecicit es de la couche elle-m eme sans que cela aecte le reste de l edice. Cest sur ce principe quest b atie la suite de protocoles d esign ee par TCP/IP Quand deux applications A et B discutent entre-elles via le r eseau, les informations circulent de la couche 7 vers la couche 2 quand lapplication A envoie de linformation sur le r eseau, et de la couche 2 vers la couche 7 pour que lapplication B re coive linformation de A. Le principe de base de cette discussion repose sur le fait que chaque couche du mod` ele de la machine A est en relation uniquement avec son homologue du m eme niveau de la machine B. Quand linformation descend de la couche 7 vers la couche 1, chaque couche en-capsule les donn ees re cues avant de les transmettre. Ainsi le volume dinformations sest accr u de quelques centaines doctets arriv e` a la couche 1. De mani` ere sym etrique, quand linformation remonte de la couche physique vers la couche Application, chaque couche pr el` eve les octets qui lui sont propres, ainsi lapplication B ne voit-elle que les octets envoy es par lapplication A, sans le d etail de lacheminement.

3 R eseaux locaux

R eseaux locaux

Le probl` eme intuitif et pratique qui se pose est de relier entre elles par un c able toutes les machines qui veulent communiquer : cest impossible dabord pour des raisons techniques, le monde est vaste, puis de politique demploi des ressources du r eseau, tel r eseau qui sert ` a lenseignement ne doit pas pas perturber le fonctionnement de tel processus industriel. La cons equence est que les r eseaux se d eveloppent dabord en local, autour dun centre dint er et commun, avant de se tourner (parfois) vers lext erieur.

3.1

Quest-ce quun LAN ?

Le terme r eseau local nest pas clairement d eni, cependant tout le monde saccorde ` a baptiser de la sorte un r eseau, d` es lors quon lui reconnait les caract eristiques suivantes : Cohabitation de plusieurs protocoles, Un m eme m edia (m eme c able par exemple) qui raccorde de multiples machines, peut etre de caract eristiques di erentes, Une bande passante elev ee, partag ee par tous les h otes La capacit e de faire du broadcasting et du multicasting , Une extension g eographique de moins en moins limit e, Un nombre de machines raccord ees limit e, Des relations entre les machines plac ees sur un mode d egalit e, (et non par exemple sur un mode Ma tre/Esclave comme dans un r eseau dont la topologie serait en etoile), Une mise en uvre qui reste du domaine priv e, cest ` a dire qui ne d epend pas dun op erateur ociel de t el ecommunications. Notez que les notions de bande passante et nombre limit e (etc. . .) sont volontairement qualitatives. Elles evoluent rapidement avec le temps.

Machine sur le LAN

gure I.02 Exemple de types de technologies utilis ees dans les LANs : Token ring

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

R eseaux locaux

3.2

WAN - MAN

Un WAN (Wide Area Network) d esigne des ordinateurs connect es entre di erentes villes (Metropolitan Area Network) ou pays. La technologie utilis ee est traditionnellement moins performante que celle dun LAN, cest par exemple une ligne t el ephonique lou ee fonctionnant ` a 64 kbps, une liaison RNIS, ou encore une liaison transatlantique ` a 1Mbits/secondes. Les am eliorations technologiques apport ees aux LANs permettent de les etendre de plus en plus g eographiquement, celles apport ees aux WAN augmentent consid erablement les bandes passantes, ces deux tendances font que la distinction entre ces deux types de r eseaux est de moins en moins claire.

3.3

Communications inter-r eseaux

Les r eseaux sont appel es ` a communiquer entres eux et quand cela se produit on parle de communications inter-r eseaux ( internetworking ). Le r ole dune communication inter-r eseaux est de gommer les eventuelles di erences de technologie d echange pour permettre ` a deux r eseaux, ou plus, le partage de ressources communes, l echange dinformations. Un moyen de faire communiquer deux r eseaux distincts passe par lutilisation de gateway ou passerelle. Un tel dispositif est parfois appel e routeur (router), mais cest un abus de langage. Les hommes se connectent sur les ordinateurs Les ordinateurs se connectent sur un r eseau Les r eseaux sinter-connectent dans un internet

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 c able Ethernet, dune liaison Ethernet. . . Ethernet est un standard publi e en 1982 par DEC, Intel Corp. et Xerox. Cette technique repose sur une m ethode dacc` es et de contr ole dite CSMA/CD pour Carrier Sense, Multiple Access with Collision Detection Plus tard lIEEE (Institute of Electrical and Electronics Engineers) sous linstance de son commit e 802, publia un ensemble de standards l eg` erement di erents, les plus connus pour TCP/IP sont 802.2 (Contr ole logique de la liaison LLC5 ) et 802.3 (CSMA/CD) Dans le monde TCP/IP, lencapsulation des datagrammes IP est d ecrite dans la RFC 894 [Hornig 1984] pour les r eseaux Ethernet et dans la RFC 1042 [Postel et Reynolds 1988] pour les r eseaux 802. En r` egle g en erale, toute machine utilisant TCP/IP sur ce type de r eseaux doit : 1. etre capable denvoyer et de recevoir un paquet conforme ` a la RFC 894, 2. etre capable de recevoir des paquets conformes aux deux standards, 3. Par contre il est seulement souhaitable que cette machine soit capable denvoyer des paquets conformes ` a la RFC 1042. Par d efaut le standard est donc celui de la RFC 894, si une machine peut faire les deux, cela doit etre congurable.

4.1

Caract eristiques dEthernet

Quelques principes fondamentaux 1. Le support de transmission est un Segment = bus = c able coaxial. Il ny a pas de topologie particuli` ere (boucle, etoile, etc. . .). 2. Un equipement est raccord e sur un c able par un transceiver : 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 fr equence, pas de full duplex 6 . Une trame emise par une station est re cue par tous les coupleurs du r eseau Ethernet, elle contient ladresse de l emetteur et celle du destinataire. 4. Un coupleur doit etre ` a l ecoute des trames qui circulent sur le c able. Un coupleur connait sa propre adresse, ainsi si une trame lui est destin ee 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 possibilit es de full duplex que navaient pas leurs anc etres des ann ees 80
6 5

10

R eseaux locaux 5. Une station qui veut emettre attend que toutes les autres stations se taisent. Autrement dit, si le c able est libre elle envoie sa trame, sinon elle attend. Si deux stations emettent en m eme temps il y a collision. Les deux trames sont alors inexploitables, les deux (ou plus) stations d etectent ce fait et re emettent ult erieurement leur paquet en attente. 6. Un r eseau Ethernet est donc un r eseau ` a caract` ere probabiliste car il ny a pas de chef dorchestre pour synchroniser les emissions. Cette absence conduit ` a dire que cest un r eseau egalitaire, une sorte de r eunion sans animateur entre personnes polies En conclusion, la technologie Ethernet est simple, sa mise en uvre se fait ` a faible co ut. Points ` a retenir : Simplicit e et faible co ut Peu de fonctions optionnelles Pas de priorit e Pas de contr ole sur lattitude des voisins D ebit dau moins 10Mb/s (jusqu` a 1000Mb/s th eorique). Performances peu d ependantes de la charge, sauf en cas de collisions 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 consid erations en vrac : D u au d ebit global de 10Mbits/seconde, le d ebit est de 10 bits par micro-seconde (en gros un facteur 1000 avec un cpu). Une trame a une longueur minimale (72) et une longueur maximale (1526). Si les donn ees ne sont pas assez longues (46 octets) des caract` eres de remplissage sont ajout es ( padding ). Les octets circulent du premier octet du pr eambule au dernier octet du CRC.

Couche 2 - Liaison (Data Link) A lint erieur de chaque octet le premier bit envoy e est celui de poids faible, etc.. Le pr eambule et le SFD ( Start Frame Delimiter ) servent ` a la synchronisation. Adresses dorigine et de destination sont celles respectivement de la machine emettrice et de la machine destinatrice. Remarque importante : il faut conna tre ladresse de son correspondant ` ce stade de lexpos pour pouvoir lui envoyer un paquet ! A e on ne sait pas encore comment faire quand on ignore cette information. Le champ type est deux octets qui d esignent le type des donn ees encapsul ees : Type Donn ees 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 divis ee en deux parties, les trois premiers octets d esignent le constructeur, les trois derniers d esignent le num ero de carte. LIEEE assure lunicit e des num ero de constructeurs, par tranche de 224 cartes7 Chaque constructeur assure lunicit e du num ero de chaque carte fa24 briqu ee. En gros 2 cartes par classe dadresses. 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 di erente. Dans le cas contraire le r eseau aura un comportement impr evisible, entre ne pas fonctionner du tout et des comportements tr` es bizarres pour les applicatifs. Nous reparlerons de lunicit e de ladresse au cours de la pr esentation des protocoles ARP et RARP (cf cours ARP/RARP pages 50 et 53). Exemple dadresse physique en repr esentation hexad ecimale : 08 :00 :09 :35 :d5 :0b 08 :00 :09 est attribu e` a HP8 . 35 :d5 :0b est ladresse de la carte

11

Dautres constructeurs, saisis au hasard des r eseaux :


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

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

R eseaux locaux

Attention, si tous les bits dadresse sont ` a 1, cest une adresse de broadcast. Dans ce cas toutes les stations dun r eseau sont destinatrices du paquet.

4.2

Di erences Ethernet - 802.2/802.3

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 ` a la place du champ type de la frame Ethernet. La di erenciation seectue ` a partir de la valeur de ces deux octets. On remarque egalement que le commit e 802 a choisi de subdiviser la couche 2 ISO en deux sous couches : MAC et LLC. Tous les num eros de protocole sont sup erieurs ` a 150010 qui est la longueur maximale des donn ees encapsul ees. Donc une valeur inf erieure ou egale ` a ce seuil indique une frame 802.3. MAC = Medium Access Control LLC = Logical Link Control

Le plus petit num ero de protocole est celui dIP : 0800 hexad ecimal. Ce qui fait en d ecimal : 8 162 + 0 161 + 0 160 = 2048

10

5 Interconnexion - Technologie el ementaire

13

Interconnexion - Technologie el ementaire


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` es succintes sont n ecessaires pour bien comprendre la suite de ce cours.

5.1

Raccordement

Une machine est raccord ee ` a un r eseau en g en eral par linterm ediaire de deux constituants :
Rseau local Prise "vampire" Transceiver

Carte rseau

Bus informatique

gure I.06 Dans cette technologie de raccordement le support est un gros c able jaune, dit encore Thick Ethernet ou Ethernet standard, ou encore 10Base5 (10 comme 10Mbits/s, Base comme Baseband , 5 comme 500 m` etres). 10Base5 Quelques particularit es du 10Base5 :

14

R eseaux locaux Longueur maxi est 500 m` etres, pour un maximum de 100 stations. Cest une vieille technologie tr` es bien normalis ee mais d epass ee. Pas de perturbation quand on ajoute une station : la pose dune nouvelle prise ninterrompt pas la continuit e du r eseau. Co ut non n egligeable. D eplacement dune station non ais e, en plus on perd la prise vampire, elle reste sur le c able. Pour les c ablages rapides on pr ef` ere le 10Base2 ou Thin Ethernet ou encore Ethernet n (2 comme 200 m` etres). 10Base2 Quelques particularit es du 10Base2 : Longueur maxi de 185 m` etres avec un maximum de 30 stations. La topologie impose de mettre les stations en s erie avec un minimum de 0.5 m` etre entre chaque. Le raccord se fait avec un transceiver en T (BNC bien connu des electroniciens). Il faut un bouchon de 50 ohms ` a chaque extr emit e du r eseau (2). Technique tr` es bon march e, souple, les cartes int` egrent le transducteur. Il faut rompre la continuit e du r eseau pour ajouter une nouvelle station, ce qui lemp eche de fonctionner durant lop eration. Cest un inconv enient de taille sur un r eseau tr` es utilis e. Cette technique est en outre assez sensible aux perturbations electromagn etiques. Les d esavantages du 10Base2 imposent g en eralement lusage du 10BaseT dans toute structure d epassant quelques machines (5 ` a 10). Le 10BaseT r` egle d enitivement le probl` eme de lajout ou du retrait dune machine sur le LAN (T comme Twisted Pair ou paires torsad ees). Cette technique impose lusage dune boite noire r eseau nomm ee 11 HUB ou moyeu. Celle-ci simule la continuit e dans le cas du retrait dune station. 10BaseT Quelques particularit es du 10BaseT : Une double paire torsad ee de c able sut. La longueur maximale entre le moyeu et la station est de 100 m` etres. Le moyeu impose une architecture en etoile. Le raccordement au transducteur se fait ` a laide dune prise du type RJ45, tr` es fragile (ne pas marcher dessus ! :). Le raccordement du HUB au reste du r eseau se fait par 10Base2, en bre optique, ou tout simplement par cha nage avec un autre HUB ( Daisy chain ).
11

Voir le paragraphe V.3

Interconnexion - Technologie el ementaire Cette technique est dune tr` es grande souplesse dutilisation elle impose n eanmoins lachat de HUB, de lordre de 150  pour un 12 ports. Cette technique des paires torsad ees est tr` es sensible aux perturbations electromagn etiques. electromagn etiques. Aujourdhui le 100BaseT equipe la majeur partie des equipements professionnels, 100 comme 100 Mbits/s. Enn la bre optique est utilis ee de plus en plus souvent pour eectuer les liaisons point ` a point. Fibre optique Quelques particularit es de la bre optique : La plus utilis ee est la bre multimode 62.5/125.0 m Usage dun transducteur optique pour assurer la transformation entre le signal lumineux (un laser) et le signal electrique. La distance maximale entre deux points est 1,5 km. La bre est insensible aux perturbations electromagn etiques, elle permet en outre le c ablage de site important (plusieurs km2 ). La bre permet datteindre des vitesses de transmission sup erieures aux 10Mbits/100Mbits/1000Mbits maintenant courants sur des paires de ls en cuivre. Les nouvelles technologies issues des recherches les plus r ecentes promettent des bres multifr equences (1024 canaux par bre) avec pour chaque canal une bande passante de plusieurs giga-octets. Ces nouveaux m edias auront une bande passante de plusieurs t era-octets par secondes. . . Son principal d esaventage est un co ut elev e au m` etre (de lordre dune dizaine d pour un c able dun m` etre cinquante) et la n ecessit e davoir des transducteurs au raccordement de tous les appareils contenant de l electronique (serveur, switch, routeur). Un tel module peut co uter de lordre de 500 ` a 1000  . . . Conclusion LEthernet est un jeu de construction tr` es bien maitris e, une sorte de m ecano car tous les supports sont mixables. Sauf besoin ponctuel ne plus installer de 10Base5, utiliser plut ot du 10Base2 pour les structures exp erimentales de quelques machines, avec des utilisateurs responsables. Sinon il vaut mieux avoir des commutateurs (Cf V.5) pour relier les diverses machines du r eseau, avec un pr e-c ablage en 10BaseT. Entre les b atiments utiliser de la bre optique. Le c ablage constitue les fondations dun r eseau, le faire proprement dembl e evite une source continuelle dennuis pas la suite ! Les besoins en bande passante daujourdhui ne pr egurent sans doute pas encore les besoins de demain (vid eo haute d enition sur tous les postes. . .), il faut donc

15

16 pr evoir tr` es large d` es la conception initiale.

R eseaux locaux

Machine A

Machine B

Rseau physique

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

gure I.07

5.2

R ep eteur

` une technologie particuli` A ere correspond forc ement des limitations dues aux lois de la physique. Par exemple en technologie Ethernet la longueur maximale dun brin ne peut pas exc eder 180 m` etres. Pour pallier ` a cette d ecience on utilise des r ep eteurs ( repeaters ). Un r ep eteur :

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 linconv enient de transmettre le bruit sans discernement : il ny a aucun ltrage sur le contenu.

Interconnexion - Technologie el ementaire Relie deux brins dune m eme technologie en un seul LAN car les trames sont reproduites ` a lidentique. En 10Base5, lusage dun r ep eteur fait passer la limite des 500 m` etres ` a 1000 m` etres... Il ny a aucune administration particuli` ere, sinon de brancher la boite ` a un emplacement pertinent. Cest un el ement bon march 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 e etoile ou multir ep eteur. Les HUB nont pas dadresse Ethernet, sauf certains mod` eles evolu es, g erables ` a distance (TELNET,SNMP,. . .). On parle alors de hubs intelligents parcequils permettent dassocier des ports entres-eux. Un hub r ep` ete simplement les informations dun port ou du backbone vers tous les autres ports raccordables (le nombre de ports est une caract eristique du hub). En cela il ne limite pas les collisions et nam eliore pas lusage de la bande passante. Son seul int er et est de permettre le branchement ou le d ebranchement des stations sans perturber le fonctionnement global du r eseau. En corollaire une station raccord ee via un hub est vue sur le r eseau comme si elle etait raccord ee comme par exemple en 10Base2. Les hubs peuvent etre cha n es entres-eux ; souvent ils sont reli es au backbone local par une autre technologie que la paire torsad ee (bre optique, 10Base2,. . .). Dans le cas de hubs intelligents les ports sont associ es les uns aux autres par groupes de fonctionnement.

18

R eseaux locaux

5.4

Ponts

La technologie CSMA/CD atteint vite ses limites quand le r eseau est encombr e. Une am elioration possible quand on ne peut pas changer de technologie (augmentation du d ebit) est dutiliser un ou plusieurs ponts ( bridges ) pour regrouper des machines qui ont entre-elles un dialogue privil egi e. De nos jours le pont en tant que tel est de moins en moins utilis e par contre le principe de son fonctionnement se retrouve, entres autres, dans les commutateurs (paragraphe suivant) et dans les points dacc` es sans l ( 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 interpr etation des octets v ehicul es. Le r esultat de ce travail logique (apprentissage) consiste ` a isoler le trac sur certains tron cons dun LAN. A cause de ce travail on parle g en eralement de ponts intelligents ou de ponts transparents car la phase dapprentissage est automatique ! R eduit le taux de collisions en r eduisant le trac inutile, donc am eliore 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 ` a rien.

Interconnexion - Technologie el ementaire 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 ` a lidentique. Un pont contient un cpu, il est en g en eral administrable ` a distance car 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 r eseaux aient des boucles, un protocole nomm e STP ( Spanning Tree Protocol ) d esactive automatiquement 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 ` a translations . Attention, un pont ne ltre pas broadcast et multicast .

19

5.5

Commutateurs

Aligner des stations sur un m eme r eseau local constitue une premi` ere etape simple et de faible co ut pour un r eseau local dentreprise. Le revers dune telle architecture est que le nombre de collisions cro t tr` es vite avec le trac, do` u une baisse tr` es sensible de la rapidit e des echanges d ue ` a ce gaspillage de la bande passante. Lusage de ponts peut constituer une premi` ere solution mais elle nest pas totalement satisfaisante dans tous les cas de gure, comme nous avons pu le remarquer au paragraphe pr ec edent. Depuis plusieures ann ees est apparue une nouvelle technologie nomm ee Intelligent Switching Hub (ISH) commutateur intelligent qui utilise le concept de commutation parall` ele. Daspect ext erieur ces equipements se pr esentent comme un hub mais ont en interne un cpu susamment puissant pour mettre en uvre une logique de commutation ran ee. Lorsquune trame se pr esente sur lun des ports du commutateur elle est (ou nest pas) re-rout ee vers un autre port en fonction de ladresse physique du destinataire. Il existe plusieurs di erences entre un pont et un commutateur : Un commutateur peut mettre simultan ement plusieurs ports en relation, sans que le d ebit de chacun en soure. Par exemple un commutateur de 4 ports en 10BaseT peut supporter deux connexions port source/port destination simultan ees ` a 10 Mbit/s chacune, ce qui donne un d ebit global de 20 Mbit/s. Dun point de vue plus th eorique, un commutateur ` a N ports ` a 10 Mbit/s chacun a un d ebit maximum de N 10/2 = 20M bit/s. Si une trame est ` a destination dun port d ej` a occup e, le commutateur la m emorise pour la d elivrer sit ot le port disponible. Un commutateur fonctionne comme un pont pour etablir sa carte des adresses mais il peut aussi travailler ` a partir dune table pr econgur ee.

20

R eseaux locaux 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 e dorganiser un r eseau en fonction de la port ee des serveurs des postes clients associ es. La gure I.12 illustre ce principe :

S1

S2

Serveurs gnraux

Commutateur intelligent

Hub

Client 1

Serveur local

Client 2

gure I.12

Le trac r eseau entre le client 1 et le serveur S2 ne perturbe pas le trac entre le client 2 et le serveur S1 . De m eme le trac entre le client 1 et le serveur local nest pas vu du client 2 . Les commutateurs etiquettent les trames avec un identicateur du VLAN auquel elles appartiennent. Cette etiquette se r esume par deux octets ajout es dans la trame, selon les recommandations du comit e 802 (norme 802.1Q).

5.6

Passerelles Routeurs

Pour raccorder deux LANs non forc ement contigus il faut faire appel ` a ce que lon d esigne une passerelle ( gateway ). Son r ole est de prendre une d ecision sur la route ` a suivre et de convertir le format des donn ees pour etre compatible avec le r eseau ` a atteindre (en fonction de la route). Souvent, et cest le cas avec TCP/IP, la fonction de conversion nest pas utilis ee, la fonction de routage donne alors son nom ` a lappareil en question ( eponyme), qui devient un routeur ( router ). Le probl` eme du routage entre A et B :

Interconnexion - Technologie el ementaire

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 d ecisions de destination. Poss` ede au moins deux interfaces r eseau (pas forc ement identiques). Contient un cpu et un programme tr` es evolu e, il est administrable ` a distance. Remplit egalement les fonctions dun pont (B-routeur) mais les brins ainsi reli es ne forment en g en eral plus un LAN car les adresses physiques contenues dans les trames ne servent plus ` a identier le destinataire. Il faut une autre adresse qui d epend de la pile au-dessus (exemple adresse IP). Il existe cependant des possibilit es de simuler un m eme LAN bien que les trame traversent un routeur (cf cours ARP (page 50)).

22

R eseaux locaux

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 ` a IP
1 TCP/IP et lInternet - Un peu dhistoire

En 1969 aux Etats Unis, lagence gouvernementale DARPA lance un projet de r eseau exp erimental, bas e sur la commutation de paquets. Ce r eseau, nomm e ARPANET, fut construit dans le but d etudier les technologies de communications, ind ependamment de toute contrainte commerciale1 Un grand nombre de techniques de communication par modems datent de cette epoque. Lexp erience dARPANET est alors si concluante que toutes les organisations qui lui sont rattach ees lutilisent quotidiennement pour pour leurs messages de service. En 1975, le r eseau passe ociellement du stade exp erimental au stade op erationnel. Le d eveloppement dARPANET ne sarr ete pas pour autant, les bases des protocoles TCP/IP sont d evelopp es ` a ce moment, donc apr` es que ARPANET soit op erationnel. En Juin 1978 Jon Postel2 d enit IPv4 et en 1981 IP est standardis e dans la RFC 791 [J. Postel 1981]. En 1983 les protocoles TCP/IP sont adopt es comme un standard militaire et toutes les machines sur le r eseau commencent ` a lutiliser. Pour faciliter cette reconversion, la DARPA demande ` a luniversit e de Berkeley dimpl ementer ces protocoles dans leur version (BSD) dunix. Ainsi commence le mariage entre Unix et les protocoles TCP/IP. Lapport de lUniversit e de Berkeley est majeur, tant au niveau th eorique (concept des sockets) quau niveau de lutilisateur, avec des utilitaires tr` es homog` enes avec ceux d ej` a existants sous Unix (rcp, rsh, rlogin. . .).
Lanc e en France en 1972, le projet Cyclades , sous la responsabilit e de Louis Pouzin, etait egalement bas e sur la commutation de paquets et lusage de datagrammes. Il reliait quelques grands centres universitaires en France (Lille, Paris, Grenoble,. . .) et en Europe. Il est rest e op erationnel jusquen 1978, date ` a laquelle faute de cr edit il a et e abandonn e au prot de X25, pr ef er e par les op erateurs de t el ecoms nationaux. 2 Jon Postel est d ec ed e le 16 Octobre 1998 ` a l age de 55 ans, cest le premier pionner de lInternet d ec ed e, on peut consulter par exemple : http ://www.isi.edu/postel.html
1

24

Introduction ` a IP Depuis cette epoque, un nouveau terme est apparu pour d esigner cette interconnexion de r eseaux, lInternet, avec un i majuscule. Le succ` es de cette technologie est alors tr` es important et suscite un int er et croissant de la part dacteurs tr` es divers, et en particulier La National Science Foundation qui y voit un int er et majeur pour la recherche 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 d esigne maintenant un espace de communication qui englobe la plan` ete tout enti` ere. Des centaines de milliers de sites aux Etats Unis, en Europe et en Asie y sont connect es. 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 ` a sa popularit e fortement croissante et aux demandes de transactions s ecuris ees, le protocole evolue et une nouvelle version, la version 6 (IPng), est d enie et en cours de d eploiement exp erimental4 . Les protocoles d esign es par TCP/IP ont egalement envahi les r eseaux locaux eux-m emes, car il est plus facile dutiliser les m emes protocoles en interne et en externe. Pour les utilisateurs, lacc` es ` a lInternet est possible ` a laide dune collection de programmes sp ecialis es si faciles ` a utiliser que lon peut ignorer tout (ou presque) de leur fonctionnement interne. Seul les programmeurs dapplications r eseaux et les administrateurs de syst` emes ont besoin den conna tre les arcanes. Les services r eseaux les plus populaires sont principalement : Le courrier electronique qui permet l echange de messages entres usagers. Les dizaines de milliers de forums de discussion ( news ). Le transfert de chiers entre machines ( ftp et ses d eriv es comme fetch ou wget ). Le remote login , ou ses equivalents, qui permet ` a un utilisateur de se connecter sur un site distant, depuis son calculateur local. Les serveurs inter-actifs. Les anciens se nommaient archie, gopher, veronica, wais... D esormais ils sont rendus obsol` etes par le web (protocole http). Puis maintenant la radio, la vid eoconf erence, la r ealit e virtuelle avec le VRML, le chat , les bourses d echanges point ` a point. . . En conclusion de ce paragraphe sur lhistorique on peut dire que lInternet est une collection apparemment anarchique (il ny a pas de structure hi erarchique et centralis ee) de r eseaux inter-connect es et appartenant ` a divers
http ://archive.ncsa.uiuc.edu/SDG/Software/Mosaic/NCSAMosaicHome.html Un r ecent discours de ministre tente dailleurs de lui donner un impulsion nouvelle :http ://www.recherche.gouv.fr/discours/2002/dhourtin.htm
4 3

2 Caract eristiques de TCP/IP propri etaires. On distingue trois niveaux : les r eseaux au sein des organisations (lans), les r eseaux r egionaux et les r eseaux de transit. Le site de lassociation Fnet indique quelques pointeurs int eressants sur 5 lhistorique de lInternet (en anglais).

25

Caract eristiques de TCP/IP

Le succ` es de TCP/IP, sil vient dabord dun choix du gouvernement am ericain, sappuit ensuite sur des caract eristiques int eressantes : 1. Cest un protocole ouvert, les sources (C) en sont disponibles gratuitement et ont et e d evelopp es ind ependamment dune architecture particuli` ere, dun syst` eme dexploitation particulier, dune structure commerciale propri etaire. Ils sont donc th eoriquement transportables sur nimporte quel type de plate-forme, ce qui est prouv e de nos jours. 2. Ce protocole est ind ependant du support physique du r eseau. Cela permet ` a TCP/IP d etre v ehicul e par des supports et des technologies aussi di erents quune ligne s erie, un c able coaxial Ethernet, une liaison lou ee, un r eseau token-ring, une liaison radio (satellites, wireless 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 ` a tous les utilisateurs de TCP/IP quelle que soit la plate-forme qui lutilise. Si lunicit e de ladresse est respect ee, les communications aboutissent m eme si les h otes sont aux antipodes. 4. Les protocoles de hauts niveaux sont standardis es ce qui permet des d eveloppements largement r epandus sur tous types de machines. La majeurs partie des informations relatives ` a ces protocoles sont publi ees dans les RFCs (Requests For Comments). Les RFCs contiennent les derni` eres versions des sp ecications de tous les protocoles TCP/IP, ainsi que bien dautres informations comme des propositions dam eliorations des outils actuels, la description de nouveaux protocoles, des commentaires sur la gestion des r eseaux, la liste nest pas exhaustive.

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

26

Introduction ` a IP

Comparaison TCP/IP ISO

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

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 fonctionnalit es des couches du mod` ele OSI et celles des protocoles TCP/IP.

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` es nombreux, non tous ici repr esent es et il sen faut de beaucoup. IP Internet Protocol TCP Transport Control Protocol UDP User Datagram Protocol Les autres protocoles ne sont pas d etaill es, nous aurons loccasion den parler ult erieurement.

27

3.1

Couche Application Layer

Au plus haut niveau les utilisateurs invoquent les programmes qui permettent lacc` es au r eseau. Chaque programme dapplication interagit avec la couche de transport pour envoyer ou recevoir des donn ees. En fonction des caract eristiques de l echange le programme a choisi un mode de transmission ` a la couche de transport. La plus grande proportion des applications laissent ` a la couche de transport le soin deectuer le travail de Session , n eanmoins il est possible pour certaines applications de court-circuiter cette fonctionnalit e pour agir directement au niveau R eseau , comme on peut lobserver sur la gure II.02 ` a droite.

3.2

Couche Transport Layer

La principale t ache de la couche de transport est de fournir la communication dun programme dapplication ` a un autre. Une telle communication est souvent quali ee de point ` a point . Cette couche peut avoir ` a r eguler le ot de donn ees et ` a assurer la abilit e du transfert : les octets re cus doivent etre identiques aux octets envoy es. Cest pourquoi cette couche doit g erer des checksums et savoir re- emettre des paquets mal arriv es. Cette couche divise le ux de donn ees en paquets (terminologie de lISO) et passe chacun avec une adresse de destination au niveau inf erieur. De plus, et cest surtout valable pour les syst` emes dexploitation multit aches multi-utilisateurs (Unix,. . .), de multiples processus appartenant ` a des utilisateurs di erents et pour des programmes dapplications di erents, acc` edent au r eseau au m eme moment, ce qui implique la capacit e de multiplexer et de d emultiplexer les donn ees, suivant quelles vont vers le r eseaux ou vers les programmes dapplication ( Session ).

3.3

Couche Internet Layer

Cette couche re coit des data-grammes en provenance de la couche r eseau, quelle doit analyser pour d eterminer sils lui sont adress es ou pas. Dans

28

Introduction ` a IP le premier cas elle doit d ecapsuler son en-t ete du data-gramme pour transmettre les donn ees ` a la couche de transport et au bon protocole de cette couche (TCP, UDP...), dans le deuxi` eme cas elle les ignore. Cette couche prend aussi en charge la communication de machine ` a machine. Elle accepte des requ etes venant de la couche de transport avec une identication de la machine vers laquelle le paquet doit etre envoy e. Elle utilise alors lalgorithme de routage (page 65) pour d ecider si le paquet doit etre envoy e vers une passerelle ou vers une machine directement accessible. Enn cette couche g` ere les datagrammes des protocoles ICMP et IGMP.

3.4

Couche Network Access

Le protocole dans cette couche d enit le moyen pour un syst` eme de d elivrer linformation ` a un autre syst` eme physiquement reli e. Il d enit comment les data-grammes IP sont transmis. La d enition de ceux-ci reste ind ependante de la couche r eseau, ce qui leur permet de sadapter ` a chaque nouvelle technologie au fur et ` a mesure de leur apparition. Avant de sint eresser au d etail des data-grammes IP, nous allons examiner le probl` eme de ladressage IP, dans le chapitre suivant.

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

Rseau physique

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

5 Bibliographie Chaque couche en-capsule la pr ec edente avec les informations de contr ole quelle destine ` a la couche de m eme niveau sur la machine distante. Cet ajout est nomm e header (en-t ete) parce-quil est plac e en t ete des donn ees ` a transmettre. Application Transport Internet Network | | Header | | Header | Header | | Header | Header | Header | datas datas datas datas | | | |

29

La taille des headers d epend des protocoles utilis es. Pour la couche IP le protocole comporte en standard 5 mots de 32 bits, m eme chose pour la 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 Num ero sp ecial Internet num ero 238 de f evrier 2000

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

30

Introduction ` a IP

Chapitre III Anatomie dune adresse IP


1 Adressage IP

Nous avons dit que lInternet est un r eseau virtuel, construit par interconnexion de r eseaux physiques via des passerelles. Ce chapitre parle de ladressage, le maillon essentiel des protocoles TCP/IP pour rendre transparents les d etails physiques des r eseaux et faire apparaitre lInternet comme une entit e uniforme.

1.1

Unicit e de ladresse

Un syst` eme de communication doit pouvoir permettre ` a nimporte quel h ote de se mettre en relation avec nimporte quel autre. An quil ny ait pas dambigu t e pour la reconnaissance des h otes possibles, il est absolument n ec essaire dadmettre un principe g en eral didentication. Lorsque lon veut etablir une communication, il est intuitivement indispensable de poss eder trois informations : 1. Le nom de la machine distante, 2. son adresse, 3. la route ` a suivre pour y parvenir. Le nom dit qui est lh ote distant, ladresse nous dit o` u il se trouve et la route comment on y parvient. En r` egle g en erale les utilisateurs pr ef` erent des noms symboliques pour identier les machines tandis que les processeurs des machines sont plus ` a laise avec les nombres. Les adresses IP (version 4) sont standardis ees sous forme dun nombre de 32 bits qui permet ` a la fois lidentication de chaque h ote et du r eseau auquel il appartient. Le choix des nombres composants une adresse IP nest pas laiss e au hasard, au contraire il fait lobjet dune attention particuli` ere notamment pour faciliter les op erations de routage. Nous remettons ` a plus tard la correspondance entre ce nombre et une eventuelle repr esentation symbolique.

32

Anatomie dune adresse IP Chaque adresse IP contient donc deux informations basiques, une adresse de r eseau et une adresse dh ote. La combinaison des deux d esigne de mani` ere unique une machine et une seule sur lInternet.

1.2

D elivrance des adresses IPv4

On distingue deux types dadresses IP. Les adresses priv ees que tout administrateur de r eseau peut sattribuer librement pourvu quelle ne soient pas rout ees sur lInternet, et les adresses publiques, d elivr ees par une structure mondiale qui en assure lunicit e. Ce dernier point est capital pour assurer lecience du routage, comme nous le verrons au chapitre suivant. Les adresses ` a utiliser sur les r eseaux priv es sont d ecrites par la RFC 1918 [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 g en eralement four1 nies par le FAI . Quelles soient d elivr ees de mani` ere temporaire ou attribu ees pour le long terme, elles doivent etre uniques sur le r eseau. La question est donc de savoir de qui le FAI les obtient. Cest LICANN (Internet Corporation for Assigned Names and Numbers)2 qui est charg e au niveau mondial de la gestion de lespace dadressage IP. Il d enit les proc edures dattribution et de r esolution de conits dans lattribution des adresses, mais d el` egue le d etail de la gestion de ces ressources ` a des instances r egionales puis locales, dans chaque pays, appel ees Regional Internet Registries ou RIR. Il y a actuellement trois Regional Internet Registries op erationnels : 3 4 lAPNIC pour la r egion Asie-Pacique, lARIN pour lAm erique et enn 5 le RIPE NCC pour lEurope (lAfriNIC pour lAfrique ainsi que le LACNIC pour lAm erique Latine sont en cours de cr eation). Pour ce qui nous concerne en Europe cest donc le RIPE NCC (R eseaux IP europ een Network Coordination Centre) qui d elivre les adresses que nous utilisons. Les adresses IP sont allou ees ` a lutilisateur nal qui en fait la demande par un Local Internet Registry , ou LIR, autoris e par le RIPE NCC. Un LIR est g en eralement un FAI ou une grande organisation (entreprise multinationale). Il est sous lautorit e de linstance r egionale de gestion de 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` es Internet http ://www.icann.org 3 http ://www.apnic.net 4 http ://www.arin.net/ 5 http ://www.ripe.net/

2 Anatomie dune adresse IP et e allou ees statiquement par le LIR. Les adresses IP sont alors restitu ees puis r e-attribu ees ` a dautres utilisateurs. 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 repr esenter sous forme de quatre entiers de huit bits, s epar es par des points (comme au paragraphe 1.2 ci-dessus). La partie r eseau de ladresse IP vient toujours en t ete, la partie h ote est donc toujours en queue. Lint er et de cette repr esentation est imm ediat quand on sait que la partie r eseau et donc la partie h ote sont presque toujours cod ees sur un nombre entier doctets. Ainsi, on a principalement les trois formes suivantes : Classe A Un octet r eseau, trois octets dh otes. Classe B Deux octets r eseau, deux octets dh otes. Classe C Trois octets r eseau, un octet dh ote.

2.1
Classe

D ecomposition en classes
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 r eseau et de 24 bits 16 777 216 machines (2^24) pour identier lh ote. On a donc les r eseaux de 1 ` a 127 et 224 h otes pos128.0.x.y 191.255.x.y 16 384 rseaux (2^14) sibles, cest ` a dire 16 777 216 maB 65536 machines (2^16) chines di erentes (de 0 ` a 16 777 215). 192.0.0.z 223.255.255.z Les lecteurs attentifs auront remarqu e que le r eseau 0 nest pas utiC 2 097 152 rseaux (2^21) 256 machines (2^8) lis e, il a une signication particuli` ere ( tous les r eseaux ) comme on le D 224.0.0.0 239.255.255.255 pr ecisera au paragraphe suivant. De m eme, la machine 0 nest pas utilis ee, tout comme la machine ayant E 240.0.0.0 247.255.255.255 le plus fort num ero dans le r eseau (tous les bits de la partie h ote ` a gure III.01 1, ici 16 777 215), ce qui r eduit de deux unit es le nombre des machines 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 r eseau et 16 bits pour identier la machine. Ce 14 qui fait 2 = 16 384 r eseaux (128.0 ` a 191.255) et 65 534 (65 536 2) machines. Si les trois premiers bits sont 110 , ladresse est de classe C. Il reste 21 bits pour identier le r eseau et 8 bits pour identier la machine. Ce qui 21 fait 2 = 2 097 152 r eseaux (de 192.0.0 ` a 223.255.255) et 254 (256 2) machines. Si les quatre premiers bits de ladresse sont 1110 , il sagit dune classe dadressage sp eciale, la classe D. Cette classe est pr evue pour faire du multicast , ou multipoint. (RFC 1112 [S. Deering, 1989]), contrairement aux trois premi` eres classes qui sont d edi ees ` a l unicast ou point ` a point. Ces adresses forment une cat egorie ` a part, nous en reparlons au paragraphe 3. Si les quatre premiers bits de ladresse sont 1111 , il sagit dune classe exp erimentale, la classe E. La RFC 1700 pr ecise Class E addresses are reserved for future use mais nindique pas de quel futur il sagit. . . Enn, pour conclure ce paragraphe, calculons le nombre dh otes adressables th eoriquement ` a laide des classes A, B et C : 127 16777212 + 16384 65534 + 2097152 254 = 3737091588
7

Ce total, pour etre plus exact, doit etre amput e des 17 890 780 h otes des r eseaux priv es pr evus dans la RFC 19188 , soit donc tout de m eme au total 3 719 200 808 h otes adressables en utilisant IPv4 !

2.2

Adresses particuli` eres

Certaines adresses IP ont une signication particuli` ere ! Par convention le num ero 0 dh ote nest pas attribu e. Si une adresse IP contient cette zone nulle cela signie que lon adresse le r eseau lui-m eme et aucun h ote en particulier, donc en r` egle g en erale lh ote lui-m eme. Par exemple, sur toutes les machines, ladresse 127.0.0.0 indique la machine ellem eme (loopback Cf chapitre IP page 43), ind ependamment de ladresse r eseau sur lequel elle est connect ee. ` linverse, si tous les bits de la partie h A ote sont ` a 1, cela d esigne toutes les machines du r eseaux, cest ce que lon appele une adresse de broadcast , cest ` a dire une information adress ee ` a tout le monde. On evite au maximum lusage dune telle adresse IP sur les r eseaux, pour des raisons decacit e (encombrement de la bande passante).
7 8

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

Sous-r eseaux Quelques exemples dadresses avec une signication particuli` ere : 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 H ote inconnu, sur ce r eseau Lh ote 1 de ce r eseau Tous les h otes Lh ote 52.1 du r eseau 138.195.0.0 Cet h ote sur le 138.195.0.0 Tous les h otes du 193.104.1.0 Cet h ote (boucle locale).

35

Remarque : les deux premi` eres adresses, avec un num ero de r eseau egal ` a 0, ne peuvent gurer que comme adresse source dans des cas bien particuliers comme le d emarrage dune station (cf chapitre IP page 43 et les travaux pratiques associ es).

2.3

Sous-r eseaux

En 1984 un troisi` eme niveau de hi erarchie est mis en place : le subnet ou sous-r eseau. pour permettre aux administrateurs de g erer plus nement de grands r eseaux. La RFC 950 [J. Mogul, J. Postel, 1985] donne plus de pr ecisions, la RFC 1878 [T. Pummill & B. Manning, 1995] est une table de tous les sous-r eseaux possibles.
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 h ote de ladresse IP, pour d esigner un r eseau. Le nombre de bits employ es est laiss e ` a linitiative de ladministrateur.

Dans la gure III.02 ci-contre, les bits 6 et 7 de la partie host sont utilis es pour caract eriser un sousr eseau. Quelques r evisions des propri et es des puissances de 29 sont souvent n ecessaires pour bien assimiler ce paragraphe. 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 g en eralement de la d ecomposition dun nombre en ses facteurs premiers. . .

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 caract eriser 4 sous-r eseaux de 62 machines (63 moins ladresse de broascast, le 0 n etant pas compt e). Le calcul des masques et des adresses de diusion est expliqu e dans le tableau suivant : Num ero du r eseau 193.104.1.00 193.104.1.64 193.104.1.128 193.104.1.192 Netmask Broadcast Adressage h ote 255.255.255.192 00 + 63 = 63 .1 ` a .62 255.255.255.192 64 + 63 = 127 .65 ` a .126 255.255.255.192 128 + 63 = 191 .129 ` a .190 255.255.255.192 192 + 63 = 255 .193 ` a .254

Soit un total de 62 4 = 248 h otes possibles pour cette classe C avec un 11 masque de sous-r eseau , au lieu des 254 h otes sans. La machine dadresse 1 sur chaque sous-r eseau, aura comme adresse IP : Sous-r eseau Adresse D ecomposition 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 d enir les sous-r eseaux ne devrait pas vous poser de probl` eme. . . Num ero du subnet 000(0) 001(1) 010(2) 011(3) 100(4) 101(5) 110(6) 111(7) Num ero du r eseau 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` ere Derni` ere machine machine

` toutes ces adresses il faudra appliquer le masque de sous-r A eseau : 0xFFFFFF soit encore 255.255.255. Remarque : On pourra v erifer que la perte despace dadressage pour des h otes se calcule avec la relation (2n 1) 2, o` u n est le nombre de bits du masque. Ainsi avec 3 bits de masque de sous-r eseau, la perte despace dadressage s el` eve ` a 14 h otes ! Les 254 possibilit es (256 moins 0 et 255) de nommage de la classe C se r eduisent ` a 240, amput ees de 31, 32, 63, 64, 95, 96, 127, 128, 159, 160, 191, 192, 223 et 224.
10 11

Donc 64 valeurs possibles de 0 ` a 63 netmask

CIDR

37

2.4

CIDR

En 1992 la moiti e des classes B etaient allou ees, et si le rythme avait continu e, au d ebut de 1994 il ny aurait plus eu de classe B disponible et lInternet aurait bien pu mourrir par asphyxie ! De plus la croissance du nombre de r eseaux se traduisait par un usage aux limites des routeurs, proches de la saturation car non pr evus au d epart pour un tel volume de routes (voir les RFC 1518 et RFC 1519). Deux consid erations qui ont conduit lIETF a mettre en place le CIDR ( Classless InterDomain Routing ou routage Internet sans classe) bas e sur une constatation de simple bon sens : Sil est courant de rencontrer une organisation ayant plus de 254 h otes, il est moins courant den rencontrer une de plus de quelques milliers. Les adresses allou ees sont donc des classes C contig ues, attribu ees par r egion ou par continent. En g en erale, 8 ` a 16 classes C mises bout ` a bout susent pour une entreprise. Ces blocs de num eros sont souvent appell es supernet . Ainsi par exemple il est courant dentendre les administrateurs de r eseaux parler dun slash 22 (/22) pour d esigner un bloc de quatre classes C cons ecutives. . . Il est plus facile de pr evoir une table de routage pour un bloc dadresses contig ues quadresse par adresse, en plus cela all` ege les tables. Plus pr ecisement, trois caract eristiques sont requises pour pouvoir utiliser ce concept : 1. Pour etre r eunies dans une m eme route, des adresses IP multiples doivent avoir les m emes bits de poids fort. 2. Les tables de routages et algorithmes doivent prendre en compte un masque de 32 bits, ` a appliquer sur les adresses. 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 concr etement comme dans la re ecriture du 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 e uniquement sur la partie r eseau des adresses.

38

Anatomie dune adresse IP Les agr egations dadresses sont ventil ees selon le tableau suivant12 : Multir egionales Europe Autres Am erique du Nord Am erique centrale, Am erique du Sud 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

Pr ecisions sur le broadcast

Tout dabord il faut pr eciser quune adresse de broadcast est forc ement une adresse de destination, elle ne peut jamais appara tre comme une adresse source dans un usage normal des r eseaux. 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 (pr ecisions en cours). Lusage de cette adresse est normalement limit ee ` a un h ote en phase dinitialisation, quand il ne connait rien du r eseau sur lequel il est connect e. Net-directed broadcast Tous les bits de la partie h ote sont ` a 1. Un routeur propage ce type de broadcast, sur option. Subnet-directed broadcast Cest le m eme cas que ci-dessus mais avec une adresses IP comportant des subnets. All-subnets-directed broadcast Cest le cas o` u tous les bits des subnets et h otes sont ` a 1. Ce cas possible th eoriquement est rendu obsol` ete depuis la RFC 922 (1993).

Ce tableau est tr` es synth etique, pour une information plus d etaill ee et ` a jour consultez le site de lIANA http ://www.iana.org/assignments/ipv4-address-space

12

3 Adressage multicast

39

Adressage multicast

En r` egle g en erale ladressage multicast est employ e pour sadresser en une seule fois ` a un groupe de machines. Dans le cas dun serveur vid eo/audio, cette approche induit une economie de moyen et de bande passante evidente quand on la compare ` a une d emarche unicast : un seul datagramme est rout e vers tous les clients int eress es au lieu dun envoi massif dautant de datagrammes quil y a de clients. Les adresses de type multicast ont donc la facult e didentier un groupe de machines qui partagent un protocole commun par opposition ` a un groupe de machines qui partagent un r eseau commun. La plupart des adresses multicast allou ees le sont pour des applications particuli` eres comme par exemple la d ecouverte de routeurs (que nous verrons ult erieurement lors du routage IP) ou encore la radio ou le t el ephone/vid eo sur Internet ( Mbone ). Les plus couramment utilis ees13 sur un lan sont : 224.0.0.1 224.0.0.2 Toutes les machines sur ce sous-r eseau Tous les routeurs sur ce sous-r eseau

3.1

Adresse de groupe multicast

Si une adresse multicast d emarre avec les bits 1110 par contre pour les 28 bits suivants son organisation interne di` ere de celle des classes A, B et C.
"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` ere par contre on continue ` a utiliser la notation d ecimale point ee : 224.0.0.0 ` a 239.255.255.255. Un groupe dh otes qui partagent un protocole commun utilisant une adresse multicast commune peuvent etre r epartis nimporte o` u sur le r eseau. Lappartenance ` a un groupe est dynamique, les h otes qui le d esirent rejoignent et quittent le groupe comme ils veulent. Il ny a pas de restriction sur le nombre dh otes dans un groupe et un h ote na pas besoin dappartenir ` a un groupe pour lui envoyer un message.
13

Pour plus de pr ecisions on pourra se reporter page 56 de la RFC 1700

40

Anatomie dune adresse IP

3.2

Adresse multicast et adresse MAC

Une station Ethernet quelconque doit etre congur ee pour accepter le multicast, cest ` a dire pour accepter les trames contenant un datagramme munis dune adresse IP de destination qui est une adresse multicast. Cette op eration sous entend ` a juste titre que la carte r eseau sait faire le tri entre les trames. En eet les trames multicast ont une adresse MAC particuli` ere : elles commencent forc ement par les trois octets 01 :00 :5E14 . Ceux-ci ne d esignent pas un constructeur en particulier mais sont poss ed es par lICANN (ex IANA). Restent trois octets, soit 24 bits dont le premier est forc ement ` a 0 pour d esigner les adresses de multicast (contrainte de la RFC 1700), ce qui conduit au sch ema suivant :
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 m eme pr eciser que pour chaque trame comportant une adresse multicast il y a 25 adresses IP de groupes multicast possibles ! Ce qui signie que si les 23 bits de poids faible ne susent pas ` a discriminer la trame il faudra faire appel au pilote de p eriph erique ou ` a la couche IP pour lever lambigu t e. Quand une trame de type multicast est lue par la station Ethernet puis par le pilote de p eriph erique, si ladresse correspond ` a lune des adresses de groupe multicast pr ealablement congur ees, le datagramme franchit la couche IP et une copie des donn ees est d elivr ee aux processus qui ont joint le groupe multicast . La question est de savoir comment les trames de type multicast atteignent justement cette station Ethernet ? La r eponse se trouve dans un protocole nomm e IGMP et que nous examinerons dans le prochain chapitre concernant 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 pr ecisions suppl ementaires. Jusqu` a pr esent nous avons d esign e un h ote par son adresse IP. Cette d emarche nest pas exacte si on consid` ere par exemple le cas dune passerelle, connect ee physiquement ` a au moins deux r eseaux di erents, avec une adresse IP dans chacun de ces r eseaux. On dira donc maintenant quune adresse IP identie non pas un h ote mais un interface. La r eciproque nest pas vraie car un m eme interface peut collectionner plusieurs adresses IP. Toutes permettent datteindre cet interface, on parle alors d alias IP et de r eseaux virtuels . . .Nous aurons loccasion de revenir sur ces notions ` a la n de ce cours. On dit dune machine ayant au moins deux adresses IP quelle est du type multi-homed . En g en eral une passerelle qui met en relation n r eseaux poss` ede n adresses IP di erentes (une dans chaque r eseau), mais ce nest pas une obligation (nous verrons quelle peut en etre lutilit e` a la n de ce cours).
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 h otes, A et B, en relation via une passerelle G. Si les messages et les paquets sont identiques, par contre les datagrammes et les trames di` erent puisquil ne sagit plus du m eme r eseau physique. D` es que nous aurons examin e le fonctionnement de 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 d eni dans la RFC 791. Les donn ees qui franchissent la couche IP, alias couche Internet, sont appell ees datagramme IP , datagramme Internet ou datagramme tout 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 d epend du support physique, cest le MTU ( Maximum Transfert Unit ). Quelques caract eristiques en vrac du protocole IP : 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 donn ees quil envoie. Il nentretient aucun dialogue avec une autre couche IP distante, on dit aussi quil d elivre les datagramme au mieux .

44

Protocole IP Chaque datagramme est g er e ind ependamment des autres datagrammes m eme au sein du transfert des octets dun m eme chier. Cela signie que les datagrammes peuvent etre m elang es, dupliqu es, perdus ou alt er es ! Ces probl` emes ne sont pas d etect es par IP et donc il ne peut en informer la couche de transport. Sur la gure IV.01 les bits les plus signicatifs de chaque mot de quatre octets sont ` a gauche (31. . .). Ils sont dailleurs transmis sur le r eseau dans cet ordre, cest un standard, cest le Network Byte Order . Toutes les architectures de CPU ne sont pas b aties sur le m eme mod` ele :
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-t ete IP minimale fait 5 mots de 4 octets, soit 20 octets. Sil y a des options la taille maximale peut atteindre 60 octets.

1.1

Description de len-t ete

VERS 4 bits qui sp ecient la version du protocol IP. Lobjet de ce champ est la v erication que l emetteur et le destinataire des datagrammes sont bien en phases avec la m eme version. Actuellement cest la version 4 qui est principalement utilis e sur lInternet, bien que quelques impl ementations 1 de la version 6 existent et soient d ej` a en exp erimentation . HLEN 4bits qui donnent la longueur de len-t ete en mots de 4 octets. La taille standard de cette en-t ete fait 5 mots, la taille maximale fait : (23 + 22 + 21 + 20 ) 4 = 60 octets2 TOTAL LENGTH Donne la taille du datagramme, en-t ete plus donn ees. Sil y fragmentation (voir plus loin) il sagit egalement de la taille du fragment (chaque datagramme est ind ependant des autres).
1 2

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

Description de len-t ete La taille des donn ees est donc ` a calculer par soustraction de la taille de len-t ete. 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 ` a avoir vis ` a vis de ce datagramme. Suivant les valeurs de ce champ, le routeur peut privil egier un datagramme par rapport ` a un autre. Par exemple, des datagrammes dun transfert de chier (ftp) peuvent avoir ` a laisser passer un datagramme rep er e comme contenant des caract` eres frapp es au clavier (session telnet). 0x00 0x02 0x04 0x10 0x08 Service normal Minimiser le co ut Maximiser la qualit e Minimiser le d elai Maximiser le d ebit Transfert banal news (nntp) ICMP Session telnet Transfert ftp

45

IDENTIFICATION, FLAGS et FRAGMENT OFFSET Ces mots sont pr evus pour contr oler la fragmentation des datagrammes. Les donn ees sont fragment ees car les datagrammes peuvent avoir ` a traverser des r eseaux avec 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. Pr evu ` a lorigine pour d ecompter un temps, ce champ nest quun compteur d ecr ement e dune unit e` a chaque passage dans un routeur. Couramment la valeur de d epart est 32 ou m eme 64. Son objet est d eviter la pr esence de paquets fant omes circulant ind eniment. . . Si un routeur passe le compteur ` a z ero avant d elivrance du datagramme, un message derreur ICMP (consultez le paragraphe 4) est renvoy e ` a l emetteur avec lindication du routeur. Le paquet en lui-m eme est perdu. PROTOCOL 8 bits pour identier le format et le contenu des donn ees, un peu comme le champ type dune trame Ethernet. Il permet ` a IP dadresser les donn ees extraites ` a lune ou lautre des couches de transport. Dans le cadre de ce cours, nous utiliserons essentiellement ICMP, IGMP, UDP et TCP. HEADER CHECKSUM 16 bits pour sassurer de lint egrit e de len-t ete. Lors du calcul de ce checksum ce champ est ` a 0. A la r eception de chaque paquet, la couche calcule cette valeur, si elle ne correspond pas ` a celle trouv ee dans len-t ete le datagramme est oubli e ( discard ) sans message derreur. SOURCE ADDRESS Adresse IP de l emetteur, ` a lorigine du datagramme.

46

Protocole IP DESTINATION ADDRESS Adresse IP du destinataire du datagramme. IP OPTIONS 24 bits pour pr eciser des options de comportement des couches IP travers ees et destinatrices. Les options les plus courantes concernent : Des probl` emes de s ecurit e Des enregistrements de routes Des enregistrements dheure Des sp ecications de route ` a suivre ... Historiquement ces options ont et e pr evues d` es le d ebut mais leur impl ementation na pas et e termin ee. Pour des raisons de s ecurit e, la tendance est dignorer ce champ. Certains sites consid` erent m eme comme suspects les datagrammes contenants 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 ` a router les datagrammes en les acheminant au mieux , on verra plus loin de quelle mani` ere. Cest son travail principal. 2. Il peut avoir ` a fragmenter les donn ees de taille sup erieure au MTU du support physique ` a employer.

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 etre de 256 avec SLIP ( Serial Line IP ) sur liaison s erie (RS232. . .). Dans ces conditions, si la couche IP doit transmettre un bloc de donn ees de taille sup erieure au MTU ` a employer, il y a fragmentation ! Par exemple, un bloc de 1481 octets sur Ethernet sera d ecompos e en un datagramme de 1480 (1480 + 20 = 1500) et un datagramme de 1 octet ! Il existe une exception ` a cette op eration, due ` a la pr esence active du bit Dont Fragment bit du champ FLAGS de len-t ete IP. La pr esence ` a 1 de ce bit interdit la fragmentation dudit datagramme par la couche IP qui en aurait besoin. Cest une situation de blocage, la couche emettrice est tenue au courant par un message ICMP (consultez le paragraphe 4) Fragmentation needed but dont fragment bit set et bien s ur le datagramme nest pas transmis plus loin.

G1

802.2 (1492) X25 (128)

G2

Ethernet (1500)

gure IV.03 Fragmentation Quand un datagramme est fragment e, il nest r eassembl e que par la couche IP destinatrice nale. Cela implique trois remarques : 1. La taille des datagrammes re cus par le destinataire nal est directement d ependante du plus petit MTU rencontr e. 2. Les fragments deviennent des datagrammes ` a part enti` ere. 3. Rien ne soppose ` a ce quun fragment soit ` a nouveau fragment e. Cette op eration est absolument transparente pour les couches de transport qui utilisent IP.

48

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

Le fragment transmettre

gure IV.04 Pour tous les fragments : Les donn ees doivent faire un multiple de 8 octets, sauf pour le dernier fragment, evidement. Le champ TOTAL LENGTH change. Chaque fragment est un datagramme ind ependant, susceptible d etre ` a son tour fragment e. Pour le dernier fragment : FLAGS est remis ` a z ero. Les donn ees ont une taille quelconque.

R eassemblage Tous les datagrammes issus dune fragmentation deviennent des datagrammes IP comme (presque) les autres. Ils arrivent ` a destination, peut etre dans le d esordre, dupliqu es. IP doit faire le tri. il y a susamment dinformation dans len-t ete pour r eassembler les fragments epars. Mais si un fragment manque, la totalit e du datagramme est perdu car aucun m ecanisme de contr ole nest impl ement e pour cela dans IP. La gure IV.05 r esume lop eration de fragmentation dun datagramme 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-t ete : 1. IDENTIFICATION est le m eme pour tous 2. FLAG est 0 pour le dernier datagramme 3. OFFSET cro t de la taille du fragment, ici N. 4. TOTAL LENGTH est g en eralement di erent pour le dernier fragment, sauf cas particulier. 5. HEADER CHECKSUM change ` a chaque fois car lOFFSET change (rappel : il ne tient pas compte des donn ees).

50

Protocole IP

Protocole ARP

ARP est lacronyme de Address Resolution Protocol , il est d enie dans la RFC 826. Le probl` eme ` a r esoudre est issu de la constatation quune adresse IP na de sens que pour la suite de protocole TCP/IP ; celle-ci etant ind ependante de la partie mat erielle il faut avoir un moyen d etablir un lien entre ces deux constituants. La norme Ethernet (vs IEEE) suppose lidentication unique de chaque carte construite et vendue3 . Sur une m eme liaison physique (lire plus loin m eme LAN ), Ethernet 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 d ecrit ici (ne fait pas partie du protocole). Remarque importante : Cette information na pas de sens dans le cadre dune liaison de type point ` a point avec un protocole tel que ppp. Lors du premier echange entre 2 machines dun m eme LAN, si les adresses physiques ne sont pas d ej` a connues (on verra pourquoi plus loin), la solution ` a ce probl` eme passe par lusage du protocole ARP. Lusage de ARP est compl` etement transparent pour lutilisateur.

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 sp ecial (cf paragraphe suivant), d edi e` a ARP, qui lui permet de poser la question ( Arp question ) ` a lensemble des machines actives. Ladresse de la machine qui doit r epondre etant lobjet de la question, son adresse (champ destinataire) est donc remplac ee par une adresse de broadcast (48 bits ` a 1). Toutes les machines du LAN ecoutent cet echange et peuvent mettre ` a jour leur table de conversion (adresse IP adresse Ethernet) pour la machine
3

cf chapitre I R eseaux locaux

Protocole ARP A. Le broadcast , co uteux en bande passante, est ainsi utilis e au maximum de ses possibilit es. Sur la gure IV.07 la r eponse de B est du type unicast . Remarque : quand une station Ethernet ne r epond plus (cf ICMP) il y a 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 r epond pas, la station continuera ` a poser la question ` a intervals r eguliers pendant un temps inni. . . Il nest pas besoin dutiliser ARP pr ealablement ` a chaque echange, car heureusement le r esultat est m emoris e. En r` egle g en erale la dur ee de vie dune adresse en m emoire est de lordre de 20 minutes et chaque utilisation remet ` a jour ce compteur. 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` es important, du fait de lutilisation de broadcast physiques, les messages ARP ne franchissent pas les routeurs. Il existe cependant un cas particulier : le proxy ARP, que nous evoquerons succintement ` a la n de ce paragraphe.

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 e dans une trame physique du type 0x08064 . HARDWARE TYPE pour sp ecier le type dadresse physique dans les champs SENDER HA et TARGET HA, cest 1 pour Ethernet. PROTOCOL TYPE pour sp ecier le type dadresse logique dans les champs SENDER ADR et TARGET ADR, cest 0x0800 (m eme valeur que dans la trame Ethernet) pour des adresses IP. HLEN 1 pour sp ecier la longueur de ladresse physique (6 octets pour Ethernet). HLEN 2 pour sp ecier la longueur de ladresse logique (4 octets pour IP). OPERATION ce champ pr ecise le type de lop eration, il est n ecessaire car la trame est la m eme pour toutes les op erations des deux protocoles qui lutilisent. Question 1 3 R eponse 2 4

ARP RARP

SENDER HA adresse physique de l emetteur SENDER ADR adresse logique de l emetteur TARGET HA adresse physique du destinataire TARGET ADR adresse logique du destinataire
4

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

3 Protocole RARP

53

2.3

Proxy ARP

Le proxy ARP permet lextension du lan ` a des h otes qui ne lui sont pas directement physiquement reli es, mais qui sy rattachent par exemple au travers dune passerelle. Un exemple tr` es courant est celui dun h ote qui acc` ede ` a un r eseau via un dialup (rtc, num eris,. . .). Le NetID de son adresse IP peut alors etre le m eme que celui du r eseau rejoint, comme sil y etait physiquement raccord e. Ce subterfuge est rendu possible apr` es conguration ad equate de la passerelle de raccordement.

Protocole RARP

RARP est lacronyme de Reverse Address Resolution Protocol , il est d eni dans la RFC 903 (BOOTP et DHCP en sont des alternatives avec plus de possibilit es). Normalement une machine qui d emarre obtient son adresse IP par lecture dun chier sur son disque dur (ou depuis sa conguration g ee dans une m emoire non volatile). Pour certains equipements cette op eration nest pas possible voire m eme non souhait ee par ladministrateur du r eseau : Terminaux X Windows Stations de travail diskless Imprimante en r eseau Boites noires sans capacit e autonome de d emarrage PC en r eseau ... Pour communiquer en TCP/IP une machine a besoin dau moins une adresse IP, lid ee de ce protocole est de la demander au r eseau. Le protocole RARP est adapt e de ARP : l emetteur envoie une requ ete RARP sp eciant son adresse physique dans un datagramme de m eme 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 e re coivent la requ ete, celles qui sont habilit es ` a r epondre (serveurs RARP) compl` etent le datagramme et le renvoient directement ( unicast ) ` a l emetteur de la requ ete puisquelle connaissent son adresse physique. Sur une machine Unix congur ee en serveur RARP les correspondances entres adresses IP et adresses physiques sont enregistr ees dans un chier nomm e g en eralement /etc/bootptab.

54

Protocole IP

Protocole ICMP

ICMP est lacronyme de Internet Control Message Protocol , il est historiquement d eni dans la RFC 950. Nous avons vu que le protocole IP ne v erie pas si les paquets emis sont arriv es ` a leur destinataire dans de bonnes conditions. Les paquets circulent dune passerelle vers un autre jusqu` a en trouver une qui puisse les d elivrer directement ` a un h ote. Si une passerelle ne peut router ou d elivrer directement un paquet ou si un evenement anormal arrive sur le r eseau comme un trac trop important ou une machine indisponible, il faut pouvoir en informer lh ote qui a emis le paquet. Celui-ci pourra alors r eagir en fonction du type de probl` eme rencontr e. ICMP est un m ecanisme de contr ole des erreurs au niveau IP, mais la gure II.02 du chapitre dintroduction ` a IP (page 23) montre que le niveau Application peut egalement avoir un acc` es direct ` a ce protocole.

4.1

Le syst` eme de messages derreur

Dans le syst` eme que nous avons d ecrit, chaque passerelle et chaque h ote op` ere de mani` ere autonome, route et d elivre les datagrammes qui arrivent sans coordination avec l emetteur. Le syst` eme fonctionne parfaitement si toutes les machines sont en ordre de marche et si toutes les tables de routage sont ` a jour. Malheureusement cest une situation id eale. . . Il peut y avoir des rupture de lignes de communication, des machines peuvent etre ` a larr et, en pannes, d econnect ees du r eseau ou incapables de router les paquets parcequen surcharge. Des paquets IP peuvent alors ne pas etre d elivr es ` a leur destinataire et le protocol IP lui-m eme ne contient rien qui puisse permettre de d etecter cet echec de transmission. Cest pourquoi est ajout e syst ematiquement un m ecanisme de gestion des erreurs connu sous le doux nom de ICMP. Il fait partie de la couche IP5 et porte le num ero de protocole 1. Ainsi, quand un message derreur arrive pour un paquet emis, cest la couche IP elle-m eme qui g` ere le probl` eme, la plupart des cas sans en informer les couches sup erieures (certaines applications utilisent ICMP6 ). Initialement pr evu pour permettre aux passerelles dinformer les h otes sur des erreurs de transmission, ICMP nest pas restreint aux echanges passerellesh otes, des echanges entres h otes sont tout ` a fait possibles. Le m eme m ecanisme est valable pour les deux types d echanges.

5 6

voir ou revoir la gure II.02 du chapitre dintroduction ` a IP (page 23) M eme gure quau point pr ec edent

Protocole ICMP

55

4.2

Format des messages ICMP

Chaque message ICMP traverse le r eseau dans la partie DATA dun datagramme IP :
Entete IP Message ICMP

gure IV.09 La cons equence directe est que les messages ICMP sont rout es comme les autres paquets IP au travers le r eseau. Il y a toutefois une exception : il peut arriver quun paquet derreur rencontre lui-m eme un probl` eme de transmission, dans ce cas on ne g en` ere pas derreur sur lerreur ! Il est important de bien voir que puisque les messages ICMP sont encapsul es dans un datagramme IP, ICMP nest pas consid er e comme un protocole de niveau plus elev e. La raison de lutilisation dIP pour d elivrer de telles informations, est que les messages peuvent avoir ` a traverser plusieurs r eseaux avant darriver ` a leur destination nale. Il n etait donc pas possible de rester au niveau physique du r eseau (` a linverse de ARP ou RARP). La gure IV.10 d ecrit le format du message ICMP :
31 TYPE 24 23 CODE 16 15 CHECKSUM 0

ENTETE du message original

..

gure IV.10 Chaque message ICMP a un type particulier qui caract erise le probl` eme quil signale. Un en-t ete de 32 bits est compos e comme suit : TYPE contient le code derreur. CODE compl` ete linformation du champ pr ec edent. CHECKSUM est utilis e avec le m eme m ecanisme de v erication que pour les datagrammes IP mais ici il ne porte que sur le message ICMP (rappel : le checksum de len-t ete IP ne porte que sur son en-t ete et non sur les donn ees v ehicul ees). En addition, les messages ICMP donnent toujours len-t ete IP et les 64 premiers bits (les deux premiers mots de quatre octets) du datagramme qui est ` a lorigine du probl` eme, pour permettre au destinataire du message didentier quel paquet est ` a lorigine du probl` eme.

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 utilis es. Il existe onze valeurs de TYPE di erentes. 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 re coit une telle requ ete doit formuler un 7 message ICMP echo reply en retour Ce m ecanisme est extr emement utile, la plupart des impl ementations 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 d elivrer un datagramme IP, elle envoie un message ICMP destination unreachable ` a l emetteur. Dans ce cas le champ CODE compl` ete le message derreur avec : 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 h ote, il est rejet e. Un paquet arrive trop vite quand la machine qui doit le lire est congestionn ee, trop de trac ` a suivre.. . . Dans ce cas la machine en question envoie un paquet ICMP source quench qui est interpr et e de la fa con suivante : L emetteur ralenti le rythme denvoi de ses paquets jusqu` a ce quil cesse de recevoir ce message derreur. La vitesse est donc ajust ee par une sorte dapprentissage rustique. Puis graduellement il augmente le d ebit, aussi longtemps que le message source quench ne revient pas .
7

Pour des raisons de s ecurit e certaines machines peuvent ne pas r epondre.

Protocole ICMP Ce type de paquet ICMP a donc tendance ` a vouloir r eguler le ux des datagrammes au niveau IP alors que cest une fonctionnalit e de la couche de transport (TCP). Cest donc une s erieuse entorse ` a la r` egle dind ependance des couches. Redirect (5) Les tables de routage (Voir le paragraphe 6) des stations restent assez statiques durant de longues p eriodes. Le syst` eme dexploitation les lit au d emarrage sur le syst` eme de chiers et ladministrateur en change de temps en temps les el ements. Si entre deux modications une destination change demplacement, la donn ee initiale dans la table de routage peut sav erer incorrecte. Les passerelles connaissent de bien meilleures routes que les h otes euxm emes, ainsi quand une passerelle d etecte une erreur de routage, elle fait deux choses : 1. Elle envoie ` a l emetteur du paquet un message ICMP redirect 2. Elle redirige le paquet vers la bonne destination. Cette redirection ne r` egle pas les probl` emes de routage car elle est limit ee aux interactions entres passerelles et h otes directement connect es. La propagation des routes aux travers des r eseaux multiples est un autre probl` eme. 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 d etail dans le paragraphe 6.4. Time exceeded (11) Chaque datagramme contient un champ TTL dit TIME TO LIVE appell e aussi hop count . An de pr evenir le cas ou un paquet circulerait ` a linni dune passerelle ` a une autre, chaque passerelle d ecr emente ce compteur et rejette le paquet quand le compteur arrive ` a z ero et envoie un message ICMP ` a l emetteur pour le tenir au courant.

57

58

Protocole IP

Protocole IGMP

IGMP, lacronyme de Internet Group Management Protocol , est historiquement d enie dans lAnnexe I de la RFC 1112. Sa raison d etre est que les datagrammes ayant une adresse multicast8 sont ` a destination dun groupe dutilisateurs dont l emetteur ne connait ni le nombre ni lemplacement. Lusage du multicast etant par construction d edi e 9 aux applications comme la radio ou la vid eo sur le r eseau , donc consommatrices 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 associ ees avec des ux doctets que personne nutilise plus !

5.1

Description de len-t ete

IGMP est un protocole de communication entre les routeurs susceptibles de transmettre des datagrammes multicast et des h otes qui veulent senregistrer dans tel ou tel groupe. IGMP est encapsul e dans IP10 avec le protocole num ero 2. Comme le montre la gure IV.12, sa taille est xe (contrairement ` a ICMP) : 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 r eponse dun h ote. Inutilis e ... Checksum Le checksum est calcul e comme celui dICMP. Adresse Cest ladresse multicast (classe D) ` a laquelle appartient lh ote qui r epond.

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

Protocole IGMP

59

5.2

Fonctionnement du protocole

La RFC 1112 pr ecise que les routeurs multicast envoient des messages de questionnement (Type=Queries) pour reconna tre quels sont les eventuels h otes appartenant ` a quel groupe. Ces questions sont envoy ees ` a tous les h otes des LANs directement raccord es ` a laide de ladresse multicast du groupe 11 224.0.0.1 encapsul e dans un datagramme IP ayant un champ TTL=1. Tous les h otes susceptibles de joindre un groupe multicast ecoutent ce groupe par hypoth` ese. Les h otes, dont les interfaces ont et e correctement congur ees, r epondent ` a une question par autant de r eponses que de groupes auxquels ils appartiennent sur linterface r eseau qui a re cu la question. An d eviter une temp ete de r eponses chaque h ote met en uvre la strat egie suivante : 1. Un h ote ne r epond pas imm ediatement ` a la question re cue. Pour chaque groupe auquel il appartient, il attend un d elais compris entre 0 et 10 secondes, calcul e al eatoirement ` a partir de ladresse IP unicast de linterface qui a re cu la question, avant de renvoyer sa r eponse. La gure IV.13 montre un tel echange, remarquez au passage la valeur des adresses. 2. La r eponse envoy ee est ecout ee par tous les membres du groupe appartenant au m eme LAN. Tout ceux qui sappr etaient ` a envoyer une telle r eponse au serveur en interrompent le processus pour eviter une redite. Le routeur ne re coit ainsi quune seule r eponse pour chaque groupe, et 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 ` a la strat egie ci-dessus. La premi` ere est que si une question est re cue alors que le compte ` a rebours pour r epondre ` a une r eponse est en cours, il nest pas interrompu. La deuxi` eme est quil ny a jamais de d elai appliqu e pour lenvoi de datagramme 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 fr equence tr` es faible de lordre de la minute,
11

tous les h otes du LAN

60

Protocole IP an de pr eserver au maximum la bande passante du r eseau. Si aucune r eponse ne leur parvient pour tel ou tel groupe demand e pr ec edement, le routage sinterrompt. Quand un h ote rejoint un groupe, il envoie imm ediatement une r eponse (type=report) pour le groupe (les) qui lint eresse, plut ot que dattendre une question du routeur. Au cas o` u cette r eponse se perdrait il est recommand e deectuer une r e emission dans un court d elai. Remarques : 1. Sur un LAN sans routeur pour le multicast, le seul trac IGMP est celui des h otes demandant ` a rejoindre tel ou tel groupe. 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 d edi ee aux applications utilisant une valeur de 1 pour le champ TTL (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 cons equence les applications qui utilisent le multicast (avec une adresse sup erieure ` a 224.0.0.225) pour d ecouvrir des services, doivent avoir une strat egie pour augmenter la valeur du champ TTL en cas de non r eponse.

5.3

Fonctionnement du Mbone

Pr ecisions en cours. . .

6 Routage IP

61

Routage IP

Ce paragraphe d ecrit de mani` ere succincte le routage des datagrammes. Sur lInternet, ou au sein de toute entit e qui utilise IP, les datagrammes ne sont pas rout es par des machines Unix, mais par des routeurs dont cest la fonction par d enition (et qui sont donc plus ecace et plus perfectionn es pour cette t ache). Toutefois il est courant dans les petits r eseaux , ou quand le probl` eme ` a r esoudre reste simple, de faire appel ` a une machine Unix pour ce faire12 . Nous examinerons donc le probl` eme (simpli e) du routage dans ce dernier cas. Les lecteurs soucieux den savoir plus sur ce probl` eme tr` es vaste pourront se repporter ` a la bibliographie en n de chapitre. Le routage des datagrammes se fait au niveau de la couche IP, et cest son travail le plus important. Toutes les machines multiprocessus sont th eoriquement capables deectuer cette op eration. La di erence entre un routeur et un h ote est que le premier est capable de transmettre un datagramme dun interface ` a un autre et pas le deuxi` eme. Cette op eration est d elicate si les machines qui doivent dialoguer sont connect ees ` a de multiples r eseaux physiques. Dun point de vue id eal etablir une route pour des datagrammes devrait tenir compte d el ements comme la charge du r eseau, la taille des datagrammes, le type de service demand e, les d elais de propagation, l etat des liaisons, le trajet le plus court. . .La pratique est plus rudimentaire ! Il sagit de transporter des datagrammes aux travers de multiples r eseaux physiques, donc aux travers de multiples passerelles. On divise le routage en deux grandes familles : Le routage direct Il sagit de d elivrer un datagramme ` a une machine raccord ee au m eme LAN. L emetteur trouve ladresse physique du correspondant (ARP), encapsule le datagramme dans une trame et lenvoie. Le routage indirect Le destinataire nest pas sur le m eme LAN comme pr ec edement. Il est absolument n ecessaire de franchir une passerelle connue davance ou demployer un chemin par d efaut. En eet, toutes les machines ` a atteindre ne sont pas forc ement sur le m eme r eseau physique. Cest le cas le plus courant, par exemple sur lInternet qui regroupe des centaines de milliers de r eseaux di erents. Cette op eration est beaucoup plus d elicate que la pr ec edente car il faut s electionner une passerelle. Parceque le routage est une op eration fondamentalement orient ee r eseau , le routage sappuie sur cette partie de ladresse IP du destinaon peut consulter par exemple http ://www.freebsd.org/picobsd/, o` u le site du projet Zebra de GNU http ://www.zebra.org/
12

62

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

6.1

Table de routage

Sous Unix toutes les op erations de routage se font gr ace ` a une table, dite table de routage , qui se trouve dans le noyau lui-m eme. La gure IV.14 r esume la situation :

Dmons DHCP de routage

Commande route

Commande netstat

ICMP

Algorithme de routage Table de routage

Couche IP

gure IV.14 Cette table est tr` es fr equemment utilis ee par IP : sur un serveur plusieurs centaines de fois par secondes. Comment est-elle cr ee ? Au d emarrage avec la commande route, invoqu ee dans les scripts de lancement du syst` eme, et en fonctionnement : Au coup par coup avec la commande route, ` a partir du shell (administrateur syst` eme uniquement). Dynamiquement avec les d emons de routage routed ou gated (la fr equence de mise ` a jour est typiquement de lordre de 30 sec.). 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 m emoriser cette table comme etant essentiellement compos ee dune colonne origine, dune colonne destination. De plus, chaque route qui d esigne une passerelle (ici la route par d efaut) doit saccompagner dun nombre de sauts ( hop ), ou encore m etrique, qui permet le choix dune route plut ot quune autre en fonction de cette valeur. Chaque franchissement dun routeur compte pour un saut. Dans la table ci-dessus, la m etrique de la route par d efaut est 1. Remarque : la sortie de la commande netstat -rn ci-dessus a et e sim13 pli ee. Les drapeaux ( ags ) les plus courants : C c D G H L M S U W
13

La route est g en er ee par la machine, ` a lusage. La route a et e cr ee dynamiquement (d emons de routage). La route d esigne une passerelle, sinon cest une route directe. La route est vers une machine, sinon elle est vers un r eseau. D esigne la conversion vers une adresse physique (cf ARP). La route a et e modi ee par un redirect . La route a et e ajout ee manuellement. La route est active. La route est le r esultat dun cl onage.

Des colonnes Refs, Use et Netif

64

Protocole IP La gure 15 pr ecise larchitecture du r eseau autour de la machine sur laquelle a et e ex ecut e le netstat.

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 pr ec edent, les routes statiques sont celles cr ees au d emarrage de la machine ou ajout ees manuellement par ladministeur syst` eme, en cours de fonctionnement. Le nombre de machines possibles ` a atteindre potentiellement sur lInternet est beaucoup trop elev e pour que chaque machine puisse esp erer en conserver ladresse, qui plus est, m eme si cela etait concevable, cette information ne serait jamais ` a jour donc inutilisable. Plut ot que denvisager la situation pr ec edente on pr ef` ere restreindre l etendue du monde connu et utiliser la strat egie de proche en proche pr ec edement cit ee. Si une machine ne peut pas router un datagramme, elle connait (ou est suppos ee conna tre) ladresse dune passerelle suppos ee etre mieux inform ee pour transmettre ce datagramme. Dans lexemple de sortie de la commande netstat du paragraphe 6.1, on peut reconna tre que ladministrateur syst` eme na congur e quune seule 14 route manuellement , toutes les autres lignes ont et e d eduites par la couche IP elle-m eme. La gure IV.16 met en situation plusieurs r eseaux et les passerelles qui les relient.

Ce nest pas tout ` a fait exact, nous verrons pourquoi au paragraphe concernant linterface 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` es simpli ee des tables de routage statiques : 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 e r esume les op erations de la couche IP pour choisir une destination, en fonction de sa table de routage. Cette op eration est essentiellement bas ee sur le num ero de r eseau, IN , extrait de ladresse IP, ID . M d esigne la machine sur laquelle seectue le routage. Si IN est un num ero de r eseau auquel M est directement reli ee : Obtenir ladresse physique de la machine destinatrice Encapsuler le datagramme dans une trame physique et lenvoyer directement. Sinon Si ID apparait comme une machine ` a laquelle une route sp eciale est attribu ee, router le datagramme en fonction. Sinon Si IN apparait dans la table de routage, router le datagramme en fonction.

66

Protocole IP Sinon Sil existe une route par d efaut router le datagramme vers la passerelle ainsi d esign ee. Sinon D eclarer une erreur de routage (ICMP).

6.3

Routage dynamique

Si la topologie dun r eseau ore la possibilit e de plusieurs routes pour atteindre une m eme destination, sil est vaste et complexe, sujet ` a des changements fr equents de conguration. . .Le routage dynamique est alors un bon moyen dentretenir les tables de routages et de mani` ere automatique. Il existe de nombreux protocoles de routage dynamique dont certains sont aussi anciens que lInternet. N eanmoins tous ne conviennent pas ` a tous les types de probl` eme, il en existe une hi erarchie. Sch ematiquement on peut imaginer lInternet comme une hi erarchie de 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` ere avec ce que lon nomme les Autonomous systems , cest ` a dire des syst` emes de routeurs et de r eseaux qui poss` edent leurs m ecanismes propres de propagation des routes. Le protocole utilis e par ces 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` eme autonome on utilise un IGP ( Interior Gateway Protocol ) cest ` a dire un protocole de gateways int erieurs . Les protocoles

Routage dynamique les plus couramment employ es sont RIP ( Routing Information Protocol ) qui est simple ` a comprendre et ` a utiliser, ou encore OSPF ( Open Shortest Path First ) plus r ecent, plus capable mais aussi beaucoup plus complexe ` a comprendre dans son mode de fonctionnement. RIP RIP est apparu avec la version BSD dUnix, il est document e dans la RFC 1058 (1988 - Version 1 du protocole) et la RFC 1723 (1994 - Version 2 du protocole). Ce protocole est bas e sur des travaux plus anciens men es par 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 etablie en nombre de sauts ( hop ), ou m etrique, entre la source et la destination, cest ` a dire en comptant toutes les liaisons. Cette distance est exprim ee comme un nombre entier variant entre 1 et 15 ; la valeur 16 est consid er ee comme linni et indique une mise ` a l ecart de la route. Chaque routeur emet dans un datagramme portant une adresse IP de broadcast, ` a fr equence xe (environ 30 secondes), le contenu de sa table de routage et ecoute celle des autres routeurs pour compl eter sa propre table. Ainsi se propagent les tables de routes dun bout ` a lautre du r eseau. Pour eviter une temp etes de mises ` a jours , le d elais de 30 secondes est augment e dune valeur al eatoire comprise entre 1 et 5 secondes. Si une route nest pas annonc ee au moins une fois en trois minutes, la distance devient innie , et la route sera retir ee un peu plus tard de la table (elle est propag ee avec cette m etrique). Ladresse IP utilis ee est une adresse de multipoint ( multicast ) comme nous verrons au paragraphe 6.4 Depuis la d enition de RIPv2 (RFC 1723) les routes peuvent etre accompagn ees du masque de sous r eseau qui les caract erise. Ainsi on peut avoir la 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` es propagation des routes, la table de routage du routeur R1 pourrait 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 Co ut 1 1 2 3

Avec une route par d efaut qui est le routeur R2. La constitution de cette table nest possible quavec RIPv2 etant donn e lexistence des deux sousr eseaux de la classe C 192.168.192. OSPF Pr ecisions en cours.

6.4

D ecouverte de routeur et propagation de routes

Au d emarrage dune station, plut ot que de congurer manuellement les routes statiques, surtout si elle sont susceptibles de changer et que le nombre de stations est grand, il peut etre int eressant de faire de la d ecouverte automatique de routeurs (RFC 1256). ` intervals r A eguliers les routeurs diusent des messages ICMP de type 9 ( router advertisement ) dannonces de routes. Ces messages ont ladresse multicast 224.0.0.1, qui est a destination de tous les h otes du LAN. Toutes les stations capables de comprendre le multicast (et convenablement congur ees pour ce faire) ecoutent ces messages et mettent ` a jour leur table. Les stations qui d emarrent peuvent solliciter les routeurs si lattente est trop longue (environ 7 minutes) avec un autre message ICMP, de type 10 ( router sollicitation ) et avec ladresse multicast 224.0.0.2 (` a destination de tous les routeurs de ce LAN). La r eponse du ou des routeurs est du type unicast , sauf si le routeur sappr etait ` a emettre une annonce. ` A chaque route est associ e un niveau de pr ef erence et une dur ee de validit e, d enis par ladministrateur du r eseau. Une validit e nulle indique un routeur qui sarr ete et donc une route qui doit etre supprim ee. Si entre deux annonces une route change, le m ecanisme de ICMP redirect , examin e au paragraphe suivant, corrige lerreur de route. La d ecouverte de routeur nest pas un protocole de routage, son objectif est bien moins ambitieux : obtenir une route par d efaut.

Message ICMP redirect

69

6.5

Message ICMP redirect

La table de routage peut etre modi ee dynamiquement par un message 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 re coit le datagramme, scrute sa table de routage et sapper coit quil faut d esormais passer par R2. Pour se faire : 1. Il re-route le datagramme vers R2, ce qui evite quil soit emis deux fois sur le LAN. 2. Il envoie un message ICMP redirect (type 5) ` a la station, lui indiquant la nouvelle route vers R2. Ce travail seectue pour chaque datagramme re cu de la station. D` es que la station re coit le message ICMP redirect elle met ` a jour sa table de routage. La nouvelle route est employ ee pour les datagrammes qui suivent (vers la m eme direction). La route modi ee est visible avec la commande netstat -r, elle gure avec le drapeau M (modication dynamique). Pour des raisons evidentes de s ecurit e, cette possibilit e nest valable que sur un m eme LAN.

70

Protocole IP

6.6

Interface de loopback

Toutes les impl ementations dIP supportent une interface de type loopback . Lobjet de cette interface est de pouvoir utiliser les outils du r eseau en local, sans passer par un interface r eseau r eel (associ e ` a une carte physique). La gure IV.22 ci-contre, montre que la couche IP peut utiliser, selon le routage, linterface standard du r eseau, o` u linterface de loopback. Le routage est ici bien s ur bas e sur ladresse IP associ ee ` a chacune des interfaces. Cette association est eectu ee sur une machine Unix ` a laide de la commande ifconfig, qui etablit une correspondance entre un pilote de p eriph erique (rep er e par son chier sp ecial) et une adresse IP. Dans le cas du pilote de loopback, ladresse est standardis ee ` a nimporte quelle adresse valide du r eseau 127 (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` u lexplication de la ligne ci-dessous d ej` a rencontr ee (page 62) dans le cadre de la table de routage : 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 d ej` a pr evue dembl ee dans les scripts de d emarrage. Concr` etement, tout dialogue entre outils clients et serveurs sur une m eme machine est possible et m eme souhaitable sur cet interface pour am eliorer les performances et parfois la s ecurit e15 . 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 ult erieurement (cf chapitre X) que le ltrage IP sur le 127/8 est aussi ais e que sur nimporte quel autre r eseau

15

7 Finalement, comment ca marche ?

71

Finalement, comment ca marche ?

Dans ce paragraphe nous reprenons la gure III.06 (page 41) et nous y apportons comme etait annonc e une explication du fonctionnement qui tienne compte des protocoles principaux examin es dans ce chapitre. Pour cela nous utilisons deux r eseaux priv es de la RFC 1918 : 192.168.10.0 et 192.168.20.0 et nous faisons lhypoth` ese que la passerelle fonctionne comme une machine 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 r esume ladressage physique et logique de la situation : 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` eses suivantes : 1. Les caches arp des machines A, B et R sont vides 2. La machine A a connaissance dune route vers le r eseau 192.168.20 passant par 192.168.10.249 et r eciproquement la machine B voit le r eseau 192.168.10.0 via le 192.168.20.249 3. La machine A a connaissance de ladresse IP de la machine B La machine A envoie un datagramme ` a la machine B, que se passe t-il sur le r eseau ? Etape 1 La machine A applique lalgorithme de routage (page 65) et sapper coit que la partie r eseau de ladresse de B nest pas dans le m eme LAN (192.168.10/24 et 192.168.20/20 di` erent). Lhypoth` ese 2 entraine quune route route existe pour atteindre ce r eseau, passant par R. Ladresse IP de R est dans le m eme LAN, A peut donc atteindre R par un routage direct. La cons equence de lhypoth` ese 1 implique que pour atteindre R directement il nous faut dabord d eterminer son adresse physique. Le protocole ARP (page 50) doit etre utiliser.

72

Protocole IP A envoie en cons equence une trame ARP (page 52 comportant les el ements suivants : 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 r epond ` a la question ARP par une r eponse ARP (OPERATION contient 2) et un champ compl` et e: 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 ` a B en passant par R. Il sagit de routage indirect puisque ladresse de B nest pas sur le m eme LAN. Les adresses physiques et logiques se r epartissent maintenant 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 re cu le datagramme depuis A et ` a destination de B. Celle-ci est sur un LAN dans lequel R se trouve egalement, un routage direct est donc le moyen de transf errer le datagramme. Pour la m eme raison qu` a l etape 1 R na pas ladresse MAC de B et doit utiliser ARP pour obtenir cette adresse. Voici les el ements de cette question ARP : 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 r eponse ARP : 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` ere etape, R envoie le datagramme en provenance de A, ` aB:

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 l etape 3. Si les adresses IP nont pas chang e, les adresses MAC, elles, di` erent compl` etement ! Remarque : Si A envoie un deuxi` eme datagramme, les caches ARP ont les adresses MAC utiles et donc les etape 1, 2, 4 et 5 deviennent inutiles. . .

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 d eni dans la RFC 768 [Postel 1980]. Les donn ees encapsul ees dans un en-t ete UDP sont des paquets UDP.

1.1

Identication de la destination

Rappel : Au niveau de la couche Internet les datagrammes sont rout es dune machine ` a une autre en fonction des bits de ladresse IP qui identient le num ero de r eseau. Lors de cette op eration aucune distinction nest faite entre les services ou les utilisateurs qui emettent ou recoivent des datagrammes, ie tous les datagrammes sont m elang es. La couche UDP ajoute un m ecanisme qui permet lidentication du service (niveau Application). En eet, il est indispensable de faire un tri entre les divers applications (services) : plusieurs programmes de plusieurs utilisateurs peuvent utiliser simultan ement la m eme couche de transport et il ne doit pas y avoir de confusion entre eux. Pour le syst` eme Unix les programmes sont identi es de mani` ere unique par un num ero de processus, mais ce num ero est eph em` ere, non pr evisible ` a distance, il ne peut servir ` a cette fonction. Lid ee est dassocier la destination ` a la fonction quelle remplie. Cette identication se fait ` a laide dun entier positif que lon baptise port. Le syst` eme dexploitation local a ` a sa charge de d enir le m ecanisme qui permet ` a un processus dacc eder ` a un port. La plupart des syst` emes dexploitation fournissent le moyen dun acc` es synchrone ` a un port. Ce logiciel doit alors assurer la possibilit e de g erer la le dattente des paquets qui arrivent, jusqu` a ce quun processus 1 (Application) les lise. A linverse, lOS bloque un processus qui tente de lire une donn ee non encore disponible.
1

Operating System

76

Protocole UDP Pour communiquer avec un service distant il faut donc avoir connaissance de son num ero de port, en plus de ladresse IP de la machine elle-m eme. On peut pr evoir le num ero de port en fonction du service ` a atteindre, cest lobjet du paragraphe 1.3. La gure 1 explicite la notion de port. La couche IP s epare les data2 grammes TCP et UDP gr ace au champ PROTO de son en-t ete, lassociation du protocole de transport et du num ero de port identie un service sans ambigu t e. Conceptuellement on sapper coit alors que rien ne soppose ` a ce quun m eme service (Num ero de port) soit attribu e conjointement aux deux protocoles (pointill e sur la gure). Cette situation est dailleurs courante dans la r ealit e des serveurs.

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-t ete

77

1.2

Description de len-t ete

Un paquet UDP est con cu pour etre encapsul e dans un datagramme IP et permettre un echange de donn ees entre deux applications, sans echange pr eliminaire. Ainsi, si les donn ees ` a transmettre nobligent pas IP ` a fragmenter (cf page 47), un paquet UDP g en` ere un datagramme IP et cest tout !

Header IP

Paquet UDP = donnes dIP

PROTO

= UDP

gure V.02 UDP apporte un m ecanisme de gestion des ports, au dessus de la couche Internet. UDP est simplement une interface au dessus dIP, ainsi l emission des messages se fait-elle sans garantie de bon acheminement. Plus g en eralement, tous les d efauts dIP recens es au chapitre pr ec edent sont applicables ` a UDP. Plus particuli` erement, les paquets ` a destination dune application UDP sont conserv es dans une pile de type FIFO. Si lapplication destinatrice ne les consomme pas assez rapidement, les plus anciens paquets risquent d etre ecras es par les plus r ecents. . .Un risque suppl ementaire (par rapport aux propri et es dIP d ej` a connues) de perte de donn ees. Il ny a aucun retour dinformation au niveau du protocole pour apporter un quelconque moyen de contr ole sur le bon acheminement des donn ees. Cest au niveau applicatif quil convient de prendre en compte cette lacune. UDP est aussi d esign e comme un mode de transport non connect e, ou encore mode datagramme, par opposition ` a TCP que nous examinerons dans le chapitre suivant. Parmis les utilisations les plus courantes dUDP on peut signaler le serveur de noms3 , base de donn ees r epartie au niveau mondial, et qui saccomode tr` es bien de ce mode de transport. En local dautres applications tr` es utiles comme tftp ou nfs sont egalement susceptibles demployer UDP.

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

78 La gure V.03 d ecrit la structure de len-t ete.


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

Protocole UDP

0 UDP DESTINATION PORT CHECKSUM

gure V.03 UDP SOURCE PORT Le num ero de port de l emetteur du paquet. Ce champ est optionnel, quand il est sp eci e il indique le num ero de port que le destinataire doit employer pour sa r eponse. La valeur z ero (0) indique quil est inutilis e, le port 0 nest donc pas celui dun service valide. UDP DESTINATION PORT Le num ero de port du destinataire du paquet. MESSAGE LENGTH Cest la longueur du paquet, donc comprennant len-t ete 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 impl ementations ne lutilisent pas. Sil est employ e, il porte sur un pseudo en-t ete constitu e de la mani` ere suivante :
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-t ete est pr evu initialement pour apporter une protection en cas de datagrammes mal rout es !

Ports r eserv es disponibles

79

1.3

Ports r eserv es ports disponibles

Le num ero de port est un entier 16 bits non sign e, les bornes sont donc [0, 65535], par construction. Nous avons vu pr ec edement que le port 0 nest pas exploitable en tant que d esignation de service valide, donc le segment r eellement exploitable est [1, 65535]. Toute machine qui utilise la pile TCP/IP se doit de conna tre un certain nombre de services bien connus, rep er es par une s erie de ports bien connus ou well known port numbers, pour pouvoir dialoguer avec les autres machines de lInternet (vs Intranet). Sur une machine Unix, cette liste de services est plac ee dans le chier /etc/services et lisible par tous les utilisateurs et toutes les applications. En eet, comme nous lexaminerons en d etail dans le cours de programmation, un service (comprendre un programme au niveau applicatif) qui d emarre son activit e r eseau (et qui donc est consid er e comme ayant un r ole de serveur) sattribue le (les) num ero(s) de port qui lui revient (reviennent) conform ement ` a cette table. 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 utilis es ports bien connus, il y en a quantit e dautres. . .

80

Protocole UDP Une autorit e, lIANA4 , centralise et diuse linformation relative ` a tous les nombres utilis es sur lInternet via une RFC. La derni` ere en date est la RFC 1700, elle fait plus de 200 pages ! Par voie de cons equence cette RFC concerne aussi les num eros de ports. Attribution des ports ancienne m ethode Historiquement les ports de 1 ` a 255 sont r eserv es aux services bien connus, plus r ecemment, ce segment ` a et e elargi ` a [1, 1023]. Aucune application ne peut sattribuer durablement et au niveau de lInternet un num ero de port dans ce segment, sans en r ef errer ` a lIANA, qui en contr ole lusage. ` partir de 1024 et jusqu` A a 65535, lIANA se contente denregistrer les demandes dusage et signale les eventuels conits. Attribution des ports nouvelle m ethode Devant lexplosion du nombre des services enregistr e lIANA a modi e la 5 segmentation qui pr ec` ede. D esormais les num eros de ports sont class es selon les trois cat egories suivantes : 1. Le segment [1, 1023] est toujours r eserv es aux services bien connus. Les services bien connus sont d esign es par lIANA et sont mis en uvre par des applications qui sex ecutent avec des droits privil egi es (root sur une machine Unix) 2. Le segment [1024, 49151] est celui des services enregistr es. Ils sont enum er es par lIANA et peuvent etre employ es par des processus 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 priv es ; nous en examinerons lusage dans le cours de programmation.

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 d eni dans la RFC 793 [Postel 1981c]. Les donn ees encapsul ees dans un en-t ete TCP sont des paquets TCP .
Header IP Segment TCP = donnes IP

PROTO

= TCP

gure VI.01

1.1

Caract eristiques de TCP

TCP est bien plus compliqu e1 quUDP examin e au chapitre pr ec edent, il apporte en contrepartie des services beaucoup plus elabor es. Cinq points principaux caract erisent ce protocole : 1. TCP contient un m ecanisme pour assurer le bon acheminement des donn ees. Cette possibilit e est absolument indispensable d` es lors que les applications doivent transmettre de gros volumes de donn ees et de fa con able. Il faut pr eciser que les paquets de donn ees sont acquitt es de bout en bout et non de point en point. Dune mani` ere g en erale le r eseau assure lacheminement et les extr emit es le contr ole (Dave Clark). 2. Le protocole TCP permet l etablissement dun circuit virtuel entre les deux points qui echangent de linformation. On dit aussi que TCP
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 e (par opposition ` a UDP qui est en mode non connect e ou encore mode datagramme). Avant le transfert les 2 applications se mettent en relation avec leurs OS2 respectifs, les informent de leurs d esirs d etablir ou de recevoir 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 r eseau pour v erier que le transfert est possible (autoris e) et que les deux applications sont pr etes pour leurs r oles. Une fois ces pr eliminaires etablis, les modules de protocole informent les applications respectives que la connexion est etablie et que le transfert peut d ebuter. Durant le transfert, le dialogue entre les protocoles continue, pour v erier le bon acheminement des donn ees. Conceptuellement, pour etablir une connexion un circuit virtuel il faut avoir r eunis les el ements du quintuplet : Le protocole Cest TCP mais il y pourrait y avoir dautres transports qui assurent le m eme service. . . IP locale Adresse de la machine qui emet. Port local Le num ero de port associ e au processus. Il est impos e ou est d etermin e automatiquement comme nous le verrons dans le cours de programmation. IP distante Adresse de la machine distante. Port distant Le num ero de port associ e au service ` a atteindre. Il est obligatoire de le conna tre pr ecisement. Lensemble de ces cinq el ements d enit un circuit virtuel unique. Que lun deux change et il sagit dune autre connexion ! 3. TCP a la capacit e de m emoriser3 des donn ees : Aux deux extr emit es du circuit virtuel, les applications senvoient des volumes de donn ees absolument quelconques, allant de 0 octet ` a des centaines (ou plus) de Mo. ` la r A eception, le protocole d elivre les octets exactement comme ils ont et e envoy es. Le protocole est libre de fragmenter le ux de donn ees en paquets de tailles adapt ees aux r eseaux travers es. Il lui incombe cependant deectuer le r eassemblage et donc de stocker temporairement les fragments avant de les pr esenter dans le bon ordre ` a lapplication. 4. TCP est ind ependant vis ` a vis des donn ees transport ees, cest un ux doctets non structur e sur lequel il nagit pas.
2 3

Operating System dans un buer

Description de len-t ete 5. TCP simule une connexion en full duplex . Pour chacune des deux applications en connexion par un circuit virtuel, lop eration qui consiste ` a lire des donn ees peut seectuer ind ependamment de celle qui consiste ` a en ecrire. Le protocole autorise la cl oture du ot dans une direction tandis que lautre continue ` a etre active. Le circuit virtuel est rompu quand les deux parties ont clos le ux.

85

1.2

Description de len-t ete

La gure suivante montre la structure dun en-t ete TCP. Sa taille normale est de 20 octets, ` a moins que des options soient pr esentes.
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 num ero de port de lapplication locale. TCP DESTINATION PORT Le num ero de port de lapplication distante. SEQUENCE NUMBER Cest un nombre qui identie la position des donn ees ` a transmettre par rapport au segment original. Au d emarrage de chaque connexion, ce champ contient une valeur non nulle et non facilement pr evisible, cest la s equence initiale ou ISN4 TCP num erote chaque octet transmis en incr ementant ce nombre 32 bits non sign e. Il repasse ` a 0 apr` es avoir atteint 232 1 (4 294 967 295). Pour le premier octet des donn ees transmis ce nombre est incr ement e de un, et ainsi de suite. . . ACKNOWLEDGEMENT NUMBER Cest un num ero qui identie la position du dernier octet re cu dans le ux entrant. Il doit saccompagner du drapeau ACK (voir plus loin). OFF pour OFFSET, il sagit dun d eplacement qui permet datteindre les donn ees quand il y a des options. Cod e sur 4 bits, il sagit du nombre de mots de 4 octets qui composent len-t ete. Le d eplacement maximum 4 est donc de 60 octets (2 1 4 octets). Dans le cas dun en-t ete 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 r eserv es pour un usage futur !

Protocole TCP

CODE Six bits pour inuer sur le comportement de TCP en caract erisant lusage du segment : URG Le champ URGENT POINTER doit etre exploit e. ACK Le champ ACNOWLEDGMENT NUMBER doit etre exploit e. PSH Cest une notication de l emetteur au r ecepteur, pour lui indiquer que toutes les donn ees collect ees doivent etre transmises ` a lapplication sans attendre les eventuelles donn ees qui suivent. RST SYN FIN Re-initialisation de la connexion Le champ SEQUENCE NUMBER contient la valeur de d ebut de connexion. L emetteur du segment a ni d emettre.

En fonctionnement normal un seul bit est activ e` a la fois mais ce nest pas une obligation. La RFC 1024 [Postel 1987] d ecrit lexistence de paquets tcp d enomm es Christmas tree ou paquet kamikaze comprenant les bits SYN+URG+PSH+FIN ! WINDOW Le ux TCP est control e de part et dautre pour les octets compris dans une zone bien d elimit ee et nomm ee fen etre . La taille de celle-ci est d enie par un entier non sign e de 16 bits, qui en limite donc th eoriquement la taille ` a 65 535 octets (ce nest pas compl` etement exact, voir plus loin loption wscale). Chaque partie annonce ainsi la taille de son buer de r eception. Par construction, l emetteur nenvoie pas plus de donn ees que le r ecepteur ne peut en accepter. Cette valeur varie en fonction de la nature du r eseau et surtout de la bande passante devin ee ` a laide de statistiques sur la valeur du RTT. Nous y reviendrons au paragraphe 4. CHECKSUM Un calcul qui porte sur la totalit e du segment, en-t ete et donn ees. URGENT POINTER Ce champ nest valide que si le drapeau URG est arm e. Ce pointeur contient alors un oset ` a ajouter ` a la valeur de SEQUENCE NUMBER du segment en cours pour d elimiter la zone des donn ees urgentes ` a transmettre ` a lapplication. Le m ecanisme de transmission ` a lapplication d epend du syst` eme dexploitation. OPTIONS Cest un param` etrage de TCP. Sa pr esence est d etect ee d` es lors que lOFFSET est sup erieur ` a 5. Les options utilis ees :

Description de len-t ete mss La taille maximale du segment5 des donn ees applicatives que l emetteur accepte de recevoir. Au moment de l etablissement dune connexion (paquet comportant le ag SYN), chaque partie annonce sa taille de MSS. Ce nest pas une n egociation. Pour de lEthernet la valeur est 1460 ( = M T U 2 20). timestamp pour calculer la dur ee dun aller et retour (RTT ou round trip time ). wscale Facteur d echelle ( shift ) pour augmenter la taille de la fen etre au del` a des 16 bits du champ WINDOW (> 65535). Quand cette valeur nest pas nulle, la taille de la fen etre est de 65535 2shif t . Par exemple si shift vaut 1 la taille de la fen etre est de 131072 octets soit encore 128 ko. nop Les options utilisent un nombre quelconque doctets par contre les paquet TCP sont toujours align es sur une taille de mot de quatre octets ; ` a cet eet une option No Operation ou nop, cod ee sur 1 seul octet, est pr evue pour compl eter les mots. PADDING Remplissage pour se caler sur un mot de 32 bits. DATAS Les donn ees transport ees. Cette partie est de longueur nulle ` a l etablissement de la connexion, elle peut egalement etre nulle par choix de lapplication.

87

MSS= Maximum Segment Size

88

Protocole TCP

2
2.1

D ebut et cl oture dune connexion


Etablissement dune connexion

L etablissement dune connexion TCP seectue en trois temps, comme le sch ema de la gure 3 lexplicite.
Emetteur
SYN (seq=x)

Rcepteur

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

ACK(seq=y+1)

Temps

gure VI.03 On suppose que l emetteur du premier paquet avec le bit SYN a connaissance du couple (adresse IP du r ecepteur, num ero de port du service souhait e). L emetteur du premier paquet est ` a lorigine de l etablissement du circuit virtuel, cest une attitude g en eralement quali ee de cliente . On dit aussi que le client eectue une ouverture active (active open). Le r ecepteur du premier paquet accepte l etablissement de la connexion, ce qui suppose quil etait pr et ` a le faire avant que la partie cliente en prenne 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 s equence initiale (ISN = x). 2. Le serveur r epond avec sa propre s equence (ISN = y ), mais il doit egalement acquitter le paquet pr ec edent, ce quil fait avec ACK (seq = x + 1). 3. Le client doit acquitter le deuxi` eme segment avec ACK (seq = y + 1).

Cl oture dune connexion Une fois achev ee cette phase nomm ee three-way handshake , les deux applications sont en mesure d echanger les octets qui justient l etablissement de la connexion.

89

2.2

Cl oture dune connexion

Cl oture canonique Un echange de trois segments est n ecessaire pour l etablissement de la connexion ; il en faut quatre pour quelle sach` eve de mani` ere canonique ( orderly 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 donn ees circulent ind ependamment dans un sens et dans lautre. Les deux directions doivent donc pouvoir etre interrompues ind ependamment lune de lautre. Lapplication qui envoie un paquet avec le drapeau FIN indique ` a la couche TCP de la machine distante quelle nenverra plus de donn ee. La machine distante doit acquitter ce segment, comme il est indiqu e sur la gure VI.04, en incr ementant dune unit e le sequence number . La connexion est v eritablement termin ee quand les deux applications ont eectu e ce travail. Il y a donc echange de 4 paquets pour terminer la connexion.

90

Protocole TCP Au total, sans compter les echanges propres au transfert des donn ees, les deux couches TCP doivent g erer 7 paquets, il faut en tenir compte lors de la conception des applications ! Sur la gure on constate que le serveur continue denvoyer des donn ees bien que le client ait termin e ses envois. Le serveur a d etect e cette attitude par la r eception dun caract` ere de EOF (en C sous Unix). Cette possibilit e a son utilit e, notamment dans le cas des traitements distants qui doivent saccomplir une fois toutes les donn ees transmises, comme par exemple pour un tri. Cl oture abrupte Au lieu dun echange de quatre paquets comme pr ec edement, un m ecanisme de reset est pr evu pour terminer une connexion au plus vite (abortive release). Ce type darr et est typiquement g er e par la couche TCP elle-m eme quand lapplication est brutalement interrompue sans avoir eectu e un appel ` a la primitive close(2), comme par exemple lors dun appel ` a la primitive abort(2), ou apr` es avoir rencontr e une exception non prise en compte ( core dump . . .). Lextremit e qui arr ete brutalement la connexion emet un paquet assorti du bit RST, apr` es avoir (ou non) envoy e les derniers octets en attente6 . Ce paquet cl ot l echange. Il ne re coit aucun acquittement. Lextr emit e qui re coit le paquet de reset (bit RST), transmet les eventuelles derni` eres donn ees ` a lapplication et provoque une sortie derreur du type Connection reset par peer pour la primitive de lecture r eseau. Comme cest le dernier echange, si des donn ees restaient ` a transmettre ` a lapplication qui a envoy e le RST elles peuvent etre d etruites.

Emetteur
RST

Rcepteur

gure VI.05
6

Voir dans le cours de programmation, loption SO LINGER

3 Contr ole du transport

91

Contr ole du transport

Le bon acheminement des donn ees applicatives est assur e par un m ecanisme dacquittement des paquets, comme nous avons d ej` a pu lexaminer partiellement au paragraphe pr ec edent.

3.1

M ecanisme de lacquittement
Emetteur
Paquet i Horloge

Rcepteur

RTT

ACK Paquet i+1

gure VI.06 Au d epart du Paquet i une horloge se d eclenche. Si cette horloge d epasse une valeur limite avant r eception de lACK le Paquet i est retransmis Cette valeur limite est bas ee sur la constante MSL7 qui est un choix dimpl ementation, g en eralement de 30 secondes ` a 2 minutes. Le temps maximum dattente est donc de 2 M SL. Le temps qui s ecoule entre l emission dun paquet et la r eception de son 8 acquittement est le RTT , il doit donc etre inf erieur ` a 2 M SL. Il est 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 e dans les diverses les dattente sur les routeurs. L emetteur conserve la trace du Paquet i pour eventuellement le renvoyer. Si on consid` ere des d elais de transmission de lordre de 500 ms (voire plus), un tel m ecanisme est totalement inadapt e au transfert de ux de donn ees. On peut aussi remarquer quil sous-emploi la bande passante du r eseau.
7 8

Maximum Segment Lifetime Round Trip Time

92

Protocole TCP

3.2

Fen etres glissantes

Cette attente de lacquittement est p enalisante, sauf si on utilise un 9 m ecanisme de fen etres glissantes , comme le sugg` ere la gure VI.07 :

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 r eseau est beaucoup mieux employ ee. Si lun des paquets doit etre re emis, la couche TCP du destinataire aura toute linformation pour le replacer dans le bon ordre. ` chaque paquet est associ A ee une horloge comme sur la gure VI.05. Le nombre de paquets ` a envoyer avant dattendre le premier acquittement est en fonction de deux param` etres : 1. La largeur de la fen etre est pr ecis ee dans le champ WINDOW de len-t ete. Des valeurs courantes sont de lordre de 4096, 8192 ou 16384. Elle change dynamiquement pour deux raisons : (a) Lapplication change la taille du buer de la socket 10 qui correspond ` a la taille de cette fen etre. (b) Chaque acquittement ACK envoy e est assorti dune nouvelle valeur de taille de la fen etre, permettant ainsi ` a l emetteur dajuster ` a tout instant le nombre de segment quil peut envoyer simultan ement.
9 10

sliding windows voir le cours de programmation

Fen etres glissantes 2. La taille maximale des donn ees, ou MSS11 vaut 512 octets par d efaut. Cest la plus grande taille du segment de donn ees que TCP enverra. Le datagramme IP a donc une taille egale au MSS augment ee de 40 octets (20 + 20), en labsence doption de TCP. Cette option apparait uniquement dans un paquet assorti du drapeau SYN, donc ` a l etablissement de la connexion. Comme de bien entendu cette valeur est fortement d ependante du 12 support physique et plus particuli` erement du MTU . Sur de lEthernet la valeur maximale est 1500 2 20 = 1460, avec des trames lencapsultation 802.3 de lIEEE un calcul similaire conduit ` a une longueur de 1452 octets. Chaque couche TCP envoie sa valeur de MSS en m eme temps que le paquet de synchronisation, comme une option de len-t ete. Cette valeur est calcul ee pour eviter absolument la fragmentation de IP au d epart des datagrammes.

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 d ebit obtenu d epend de la taille de la fen etre et bien s ur de la bande passante disponible. On con coit ais ement quentre la situation de la gure VI.06 et celle de la gure VI.07 lusage de la bande passante sam eliore. Par contre lagrandissement de la taille de la fen etre ne se con coit que jusqu` a une limite optimale au dela de laquelle des paquets sont perdus parcequenvoy es trop rapidement pour etre re cus par le destinataire. Or, pour fonctionner de mani` ere optimale, TCP se doit de limiter au maximum la perte de paquets et donc leur re emission.
11 12

Maximum Segment Size Maximum Transfert Unit

94

Protocole TCP Cette taille limite optimale de la largeur de la fen etre est, comme on peut le deviner, fonction de la bande passante th eorique du r eseau et surtout de son taux doccupation instantann e. Cette derni` ere donn ee est uctuante, aussi TCP doit-il asservir continuement les tailles de fen etre pour en tenir compte.

4 Compl ements sur le fonctionnement de TCP

95

Compl ements sur le fonctionnement de TCP

Lusage du protocole TCP di` ere consid erablement en fonction des applications mises en uvre et des r eseaux ` a parcourir. Dapr` es [W. Richard Stevens], 10% des donn ees echang ees sur le r eseau concernent des applications interactives et 90% des applications qui echangent des ux de donn ees. Si le protocole TCP reste le m eme pour tous, les algorithmes qui le pilotent sajustent en fonction de lusage. Pour le trac en volume ( bulk data ), TCP tente dutiliser des paquets les plus larges possibles pour maximiser le d ebit, alors que le trac interactif utilise des paquets quasiment vides emis le plus souvent ` a la fr equence de frappe des utilisateurs ou au rythme des mouvements dune souris. Un exemple typique est celui de lapplication telnet pour laquelle les caract` eres sont envoy es un ` a un dans un paquet di erent, chaque caract` ere etant ` a lorigine de quatre paquets : emission dun caract` ere, acquittement, retour de l echo du caract` ere, acquittement. Si ce comportement nest absolument pas p enalisant sur un r eseau rapide (LAN) par contre d` es que la bande passante commence ` a etre statur ee il est pr ef erable de regrouper un maximum doctets (deux ou trois en pratique) dans un seul paquet pour en diminuer le nombre. Cest ce que fait lalgorithme de Nagle.

4.1

Algorithme de Nagle

Pour r eduire le trac de ces tinygrams (RFC 896), lalgorithme de Nagle (1984) dit quune connextion TCP ne peut pas attendre plus dun acquittement. Deux cas se pr esentent donc : 1. Le r eseau est lent. Dans ce cas TCP accumule dans un m eme buer les octets en partance. D` es r eception de lacquittement il y a emission du contenu du buer en un seul paquet. 2. Le r eseau est rapide. Les acquittements arrivent rapidement les agr egats doctets peuvent tendre vers un seul caract` ere par paquet. La qualit e lent/rapide du r eseau est calcul ee ` a partir du timestamp envoy e dans les options de TCP et qui est etabli d` es le premier echange (puis re evalu ee statistiquement par la suite). L el egance de cet algorithme est quil est tr` es simple et quil sauto-r egule suivant le d elais de propagation. Certaines applications d esactivent cet algorithme13 comme le serveur Apache ou le syst` eme de multi-fen etrage X11.
13

` a laide de loption TCP NODELAY

96

Protocole TCP

4.2

D epart lent

Un paquet est re emis parcequil arrive corrompu ou parcequil narrive jamais. Une re emission entraine un blocage de lavancement de la fen etre glissante , p enalisant pour le d ebit. TCP consid` ere quun paquet perdu est la cons equence dun routeur (ou plus) congestionn e, cest ` a dire pour lequel les les dattente ne sont pas assez larges pour absorber tous les paquets entrants14 Dans ce contexte, on comprend bien quil vaut mieux ne pas envoyer la totalit e du contenu de la fen etre d` es le d ebut de la connexion. Au contraire, TCP utilise un algorithme nomm e slow start qui asservit l emission des paquets au rythme de la r eception de leurs acquittements, plut ot que de les emettre dun coup aussi rapidement que lautorise le syst` eme ou le d ebit th eorique du r eseau. Ainsi, au d ebut de chaque connexion ou apr` es une p eriode de calme ( idle ) l emetteur envoie un premier paquet de taille maximale (le mss du destinataire), et attend son acquittement. Quand celui-ci est re cu, il envoie deux paquets, puis quatre, et ainsi de suite jusqu` a atteindre louverture maximale de la fen etre. Durant cette progression, si des paquets sont perdus, il y a congestion suppos ee sur lun des routeurs franchis et louverture de la fen etre est r eduite pour retrouver un d ebit qui minimise le taux de retransmission. Louverture de la fen etre est nomm ee fen etre de congestion ou encore congestion window .

4.3

Evitement de congestion

Le contr ole du ux evoqu e pr ec edement, pour eviter la congestion des routeurs, est impl ement e` a laide dune variable (cwnd) nomm ee congestion window que lon traduit par fen etre de congestion. Concr` etement, le nombre maximum de segments de donn ees (M SS en octets) que l emetteur peut envoyer avant den recevoir le premier acquittement est le minimum entre cette variable (cwnd) et la taille de la fen etre annonc ee par le r ecepteur ` a chaque acquittement de paquet. Le contenu de cette variable est pilot e par les algorithmes de d epart lent slow start , voir 4.2 et d evitement de congestion ( congestion avoidance ) examin e ici. La limite de croissance de la variable cwnd est la taille de la fen etre annonc ee par le r ecepteur. Une fois la capacit e de d ebit maximale atteinte, si un paquet est perdu lalgorithme d evitement de congestion en diminue lin eairement la valeur (contrairement au slow start qui laugmente exponentiellement).

14

Ce cas arrive fr equemment quand un routeur s epare un r eseau rapide dun r eseau lent

5 Paquets captur es, comment es

97

Paquets captur es, comment es

Le premier exemple montre un echange de paquets de synchronisation (SYN) et de n (FIN) entre la machine clnt.chezmoi et la machine srv.chezmoi. L etablissement de la connexion se fait ` a laide de la commande telnet sur le port discard (9) du serveur srv.chezmoi. La machine qui est ` a lorigine de l etablissement de la connexion est dite cliente, et celle qui est suppos ee pr ete ` a r epondre, serveur. Pour information, le service discard peut etre consid er e comme l equivalent du chier /dev/null sur le r eseau : les octets quon lui envoie sont oubli es ( discard ). Lutilisateur tape : $ telnet srv discard Trying... Connected to srv.chezmoi. Escape character is ^]. telnet> quit Connection closed. Et loutil danalyse r eseau15 permet la capture pour lobservation des echanges suivants. Le num ero qui gure en t ete de chaque ligne a et e ajout e manuellement, le nom de domaine chezmoi a et e retir e, le tout pour 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 Simultan ement la capture des paquets est lanc ee, par exemple dans une autre fen etre xterm.

Plusieurs remarques simposent : 1. Pour am eliorer la lisibilit e les num eros de s equences vrais ne sont indiqu es quau premier echange. Les suivants sont relatifs. Ainsi le ack 1 de la ligne 2 doit etre lu 2072448002 (2072448001 + 1). ` A chaque echange la valeur entre parenth` ese indique le nombre doctets echang es. 2. Les tailles de fen etre (win) et de segment maximum (mss) ne sont pas 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, rep er e par un point. Le deuxi` eme exemple montre une situation de transfert de chier avec 16 loutil ftp . Il faut remarquer que l etablissement de la connexion TCP est ici ` a linitiative du serveur, ce qui peut laisser le lecteur perplexe. . .Lexplication est simple. En fait le protocole ftp fonctionne avec deux connexions TCP, la premi` ere, non montr ee ici, est etablie du client vers le serveur, suppos e ` a l ecoute sur le port 21. Elle sert au client pour assurer le contr ole du transfert. Lorsquun transfert de chier est demand e via cette premi` ere connexion, le serveur etablit une connexion temporaire vers le client. Cest cette connexion que nous examinons ici. Elle est clotur ee d` es que le dernier octet demand e est transf err 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 m ecanisme des fen etres glissantes. Les lignes ont et e num erot ees manuellement et la date associ ee ` a chaque paquet supprim ee.
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 e : File Transfert Protocol

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 re coit un tel paquet est inform ee quelle doit transmettre ` a lapplication toutes les donn ees re cues, y compris celles transmises dans ce paquet. Le positionnement de ce drapeau est ` a linitiative de la couche TCP emettrice et non ` a lapplication. 2. Le type de service ( Type Of service tos 0x8) est demand e par lapplication pour maximiser le d ebit (consulter le cours IP page 45).
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` eme partie Protocoles applicatifs

Chapitre VII Serveur de noms - DNS


1 G en eralit es sur le serveur de noms

Sil est obligatoire dattribuer au moins une adresse IP ` a une pile ARPA pour pouvoir linterconnecter en r eseau avec dautres piles de m eme nature, en revanche, lui attribuer un nom symbolique nest absolument pas n ecessaire 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, m eme sous forme d ecimale point ee (adresses IP page 31). Il nintervient donc quau niveau applicatif, ainsi la majeure partie des applications r eseaux font usage de noms symboliques avec, de mani` ere sous-jacente, une r ef erence implicite ` a leur(s) correspondant(s) num erique(s). 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 pr eciser que le serveur de noms est en g en eral le premier service mis en route sur un r eseau, tout simplement parceque beaucoup de services le requi` erent pour accepter de fonctionner (le courrier electronique en est un exemple majeur). Cest la raison pour laquelle lusage dadresses IP sous la forme d ecimale point ee reste de mise lors de la conguration des el ements de commutation et de routage1 .

1.1

Bref historique

Au d ebut de lhistoire de lInternet, la correspondance entre le nom (les noms sil y a des synonymes ou alias ) et ladresse (il peut y en avoir plusieurs associ ees ` a un seul nom) dune machine est plac ee dans le chier /etc/hosts, pr esent sur toutes les machines unix dot ees dune pile Arpa. Ci-apr` es le chier en question, pr elev e (et tronqu e partiellement) sur une 2 machine FreeBSD ` a jour. On y remarque quil ne contient plus que ladresse
1 2

Eviter un blocage d u` a linterrogation des serveurs de noms 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 d ebut des ann ees 1980 cest le NIC3 qui g` ere la mise ` a jour continuelle de cette table (HOSTS.TXT), avec les inconv enients suivants : Absence de structure claire dans le nommage do` u de nombreux conits entre les noms des stations. Par exemple entre les dieux de la mythologie grecque, les plan` etes du syst` eme solaire, les h eros historiques ou de bandes dessin ees. . . Centralisation des mises ` a jour, ce qui entraine : 1. Une lourdeur du processus de mise ` a jour : il faut passer par un interm ediaire pour attribuer un nom ` a ses machines. 2. Un trac r eseau (ftp) en forte croissance (N 2 si N est le nombre de machines dans cette table) et qui devient rapidement ing erable au vu des bandes passantes de l epoque (quelques kilo bits par seconde), et surtout jamais ` a jour compte tenu des changements continuels. Dapr` es Douglas E. Comer, au milieu des ann ees 1980 (1986) la liste ocielle des h otes de lInternet contient 3100 noms et 6500 alias ! La forte croissance du nombre des machines, a rendu obsol` ete cette approche.

1.2

Syst` eme hi erarchis e de nommage

Lespace de noms, pr ealablement non structur e, est d esormais r eorganis e de mani` ere hi erarchique, sous forme dun arbre (et non dun graphe). Cette organisation entraine une hi erarchisation des noms de machines et des autorit es qui ont le pouvoir de les nommer, de les maintenir. Chaque nud de larbre porte un nom, la racine nen a pas. Les machines, feuilles de larbre, sont nomm ees ` a laide du chemin parcouru de la feuille (machine) ` a la racine (non nomm ee).
3

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

Syst` eme hi erarchis e de nommage Le s eparateur entre chaque embranchement, ou nud, est le point d ecimal. Voici un exemple de nom de machine : www.sio.ecp.fr Derri` ere ce nom il faut imaginer un point (.) qui est omis la plupart du temps car il est implicite4 . La lecture seectue naturellement de gauche ` a droite, par contre la hi erarchie de noms sobserve de droite ` a gauche. Domaine & zone Le r eseau peut etre consid er e comme une hi erarchie de domaines. Lespace des noms y est organis e en tenant compte des limites administratives ou organisationnelles. Chaque nud, appel e un domaine, est baptis e par une cha ne de caract` eres et le nom de ce domaine est la concat enation de toutes les etiquettes de nuds lues depuis la racine, donc de droite ` a gauche. Par 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, m eme sil est terminal, cest ` a dire na pas de sous domaine. Un sous domaine est un domaine ` a part enti` ere et, except ee la racine, tout domaine est un sous domaine dun autre. Bien que le serveur de noms, Domain Name Server fasse r ef erence explicitement au concept de domaine, pour bien comprendre la conguration dun tel service il faut egalement comprendre la notion de zone . Une zone est un point de d el egation dans larbre DNS, autrement dit une zone concerne un sous arbre du DNS dont ladministration lui est propre. Ce sous arbre peut comprendre plusieurs niveaux, cest ` a dire plusieurs sous domaines. Une zone peut etre confondue avec le domaine dans les cas les plus simples. Dans les exemples ci-dessus, on peut parler de zone sio.ecp.fr puisque celle-ci est g er ee de mani` ere autonome par rapport ` a la zone ecp.fr. Le serveur de noms est concern e par les zones . Ses chiers de conguration5 pr ecisent la port ee de la zone et non du domaine. Chaque zone doit avoir un serveur principal ( primary server ) qui d etient ses informations dun chier congur e manuellement ou semi manuellement (DNS dynamique). Plusieurs serveurs secondaires ( secondary server ) recoivent une copie de la zone via le r eseau et pour assurer la continuit e du service (par la redondance des serveurs). Le fait dadministrer une zone est le r esultat dune d el eguation de pouvoir de ladministrateur de la zone parente et se concr etise par la responsabilit 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 Hi erarchie des domaines

Serveur de noms - DNS

Cette organisation du nommage pallie aux inconv enients de la premi` ere m ethode : Le NIC g` ere le plus haut niveau de la hi erarchie, appel e aussi celui des top levels domains (TLD). Les instances r egionales du NIC g` erent les domaines qui leur sont d evolus. Par exemple le NIC France 6 g` ere le contenu de la zone .fr. Le nommage sur deux lettres des pays est issu de la norme ISO 31667 . Chaque administrateur de domaine (universit es, entreprises, associations, entit es administratives,. . .) est en charge de son domaine et des sous domaines quil cr ee. Sa responsabilit e est nomminative vis ` a vis du NIC. On dit aussi quil a lautorit e sur son domaine ( authoritative 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 d etail ` a cette adresse http ://www.nw.com/zone/iso-country-codes 8 Une base de donn ees sur les administrateurs de DNS est entretenue par les NICs, cest la base whois , interrogeable par lutilitaire du m eme nom. Consulter le site http ://www.ripe.net/ pour plus dinformations, egalement man whois sur une machine unix
7 6

2 Fonctionnement du DNS Les eventuels conits de nommage sont ` a la charge des administrateurs de domaine. Du fait de la hi erarchisation, des machines de m eme nom peuvent se trouver dans des domaines di erents sans que cela pose le moindre probl` eme. Le nom www est de loin le plus employ e 9 , pourtant il ny a aucune 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 donn ees sur le nommage de ses machines. Celle-ci est mise ` a disposition de tous les utilisateurs du r eseau. Chaque site raccord e de mani` ere permanente proc` ede de cette mani` ere, ainsi il ny a pas une base de donn ees pour lInternet mais un ensemble structur e de bases de donn ees reli ees entres elles et formant une gigantesque base de donn ees distribu ee .

107

2
2.1

Fonctionnement du DNS
Convention de nommage

La RFC 1034 pr ecise que les noms de machines sont d evelopp es un peu comme les noms de chiers dun syst` eme hi erarchis e (Unix,. . .). Le . est le s eparateur Chaque nud ne peut faire que 63 caract` eres au maximum ; le bon usage les limite ` a 12 caract` eres et commen cant par une lettre. Les majuscules et minuscules sont indi erenci ees. Les chires [0-9] et le tiret peuvent etre utilis es, le soulign e ( ) est un abus dusage. Le point . et le blanc sont proscrits. Les cha nes de caract` eres comme NIC ou dautres acronymes bien connus sont ` a eviter absolument, m eme encadr ees par dautres caract` eres. Les noms complets ne doivent pas faire plus de 255 caract` eres de long. Il y a des noms relatifs et des noms absolus , comme des chemins dans un syst` eme de chiers. Lusage du . en n de nom, qui indique un nommage absolu10 , est r eserv e` a certains outils comme ping ou traceroute et aux chiers de conguration du serveur de noms. En r` egle g en erale il nest 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 m eme r eseau logique on a coutume de ne pas utiliser le nom complet des machines auxquelles on sadresse couramment et pourtant ca fonctionne ! La raison est que le resolver , partie du syst` eme qui est en charge de r esoudre les probl` emes de conversion entre un nom de machine et son adresse IP, utilise un m ecanisme de compl etion ( domain completion ) pour compl eter le nom de machine simpli e, jusqu` a trouver un nom plus complet que le serveur de noms saura reconna tre dans sa base de donn ees. Le resolver connait par hypoth` ese le nom de domaine courant (lu dans 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 g en eralement ce nom de domaine se pr esente sous forme d1 .d2 ...dn . Ainsi, en pr esence dun nom symbolique x, le resolver teste pour chaque i, i {1, 2, . . . , n} lexistence de x.di .di+1 ...dn et sarr ete si celle-ci est reconnue. Dans le cas contraire la machine en question nest pas atteignable. Exemple, avec le domaine ci-dessus : a) machine = www (requ ete) www.sio.ecp.fr = Succ` es ! b) machine = www.sio (requ ete) www.sio.sio.ecp.fr = Echec ! www.sio.ecp.fr = Succ` es !

2.2

Le Resolver

Le resolver d esigne un ensemble de fonctions11 plac ees dans la biblioth` eque standard (gethostbyname vu en cours de programmation invoque les fonctions du resolver ) qui font linterface entre les applications et les serveurs de noms. Par construction les fonctions du resolver sont compil ees avec lapplication qui les utilise (physiquement dans la libc, donc accessibles par d efaut). Le resolver applique la strat egie locale de recherche, d enie par ladministrateur de la machine, pour r esoudre les requ etes de r esolution de noms. Pour cela il sappuie sur son chier de conguration /etc/resolv.conf et sur la strat egie locale (voir paragraphe suivant) demploi des possibilit es (serveur 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

Strat egie de fonctionnement

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 pr ecise au moins le domaine local assorti de directives optionnelles.

2.3

Strat egie de fonctionnement

La gure VII.03 illustre le fait que chaque serveur de noms a la ma trise de ses donn ees mais doit interroger ses voisins d` es quune requ ete concerne une zone sur laquelle il na pas lautorit e de nommage. Ainsi, un h ote du domaine R2 qui veut r esoudre une adresse du domaine R1 doit n ecessairement passer par un serveur interm ediaire pour obtenir linformation. Cette d emarche sappuie sur plusieurs strat egies 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 ` a la fonction gethostbyname. Cette fonction est syst ematiquement pr esente dans la biblioth` eque standard (libc) et est donc accessible potentiellement ` a tout ex ecutable lors dune compilation. La fonction gethostbyname fait syst ematiquement appel au resolver d ej` a cit e. Cest donc toujours en passant par ce m ecanisme que les processus acc` edent ` a lespace de noms. Le resolver utilise une strat egie g en erale ` a la machine (donc qui a et e choisie par son administrateur) pour r esoudre de telles requ etes : 1. Interrogation du serveur de noms (DNS) si pr esent 2. Utilisation des services type YP (NIS) si congur es 3. Utilisation du chier /etc/hosts Cette strat egie est param` etrable en fonction du constructeur. Le nsswitch sous HP-UX12 ou Solaris13 permet de passer de lun ` a lautre en cas dindisponibilit e, le chier /etc/host.conf sous FreeBSD eectue un travail assez proche. Enn, quelle que soit larchitecture logicielle le resolver est congur e ` a laide du chier /etc/resolv.conf. 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 re coit la demande, parcequil a lautorit e sur le domaine demand e (le sien), il r epond directement au resolver . Interrogation distante 1. Un processus demande ladresse IP dune machine. Le resolver envoie sa requ ete au serveur local.
12 13

Unix de Hewlett-Packard Unix de Sun Microsystem

Strat egie de fonctionnement 2. Le serveur local re coit la requ ete et dans ce deuxi` eme cas il ne peut pas r epondre directement car la machine nest pas dans sa zone dautorit e. Pour lever lind etermination il interroge alors un serveur racine pour avoir ladresse dun serveur qui a lautorit e sur la zone demand ee par le processus. 3. Le serveur racine renvoie ladresse dun serveur qui a ociellement lautorit e sur la zone 4. Le serveur local interroge ce nouveau serveur distant. 5. Le serveur distant renvoie linformation demand ee au serveur local. 6. Le serveur local retourne la r eponse au resolver

111

Serveur de noms racine

Processus

1 6

Serveur de noms local

4 5

Serveur de noms distant

gure VII.05 Remarques importantes : Un m ecanisme de cache acc el` ere le processus ci-dessus : Si un processus redemande la m eme machine distante on se retrouve dans le cas dune interrogation locale , du moins pendant la dur ee de validit e des donn ees (cf page 121). Si un processus demande une machine du m eme domaine que la pr ec edente (mais pas du m eme nom ! :), les etapes 2 et 3 deviennent inutiles et le serveur local interroge alors directement le serveur distant. La dur ee de vie de ladresse du serveur distant est elle aussi assortie dune date limite dutilisation. Dans le cas g en eral les serveurs racines ne voient pas plus de 1 ou deux 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 etre ladresse dun serveur pour C et ainsi jouera le r ole de serveur racine de l etape pr ec edente. Interrogation par procuration Le processus de recherche d ecrit au paragraphe pr ec edent ne convient pas dans tous les cas, notamment vis ` a vis des deux crit` eres suivants :

112 1. S ecurit e dun domaine 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 d emarche pose des probl` emes de s ecurit e dans le cas dun domaine au sein duquel seuls un ou deux serveurs sont autoris es. 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 e au serveur de noms peut consommer une partie non n egligeable de la bande passante, cest pourquoi il peut etre strat egique de concentrer les demandes vers un seul serveur r egional et donc de b en ecier au maximum de leet de cache d ecrit pr ec edement.

2.4

Hi erarchie de serveurs

Si tous les serveurs de noms traitent de donn ees dun format identique, leur position dans larborescence leur conf` ere un statut qui se nomme : serveur racine ( root name server ) Un serveur ayant autorit e sur la racine de lespace de nommage. Actuellement il y a 13 serveurs de ce type, nomm es [A-M].ROOT-SERVERS.NET14 serveur primaire ( primary server ) Un serveur de noms qui a lautorit e pour un ou plusieurs domaines (est d etenteur dautant de SOA Voir page 118). Il lit ses donn ees dans un chier stock e sur disque dur, ` a son d emarrage. Ladministrateur du (des) domaine(s) met ` a jour les informations des domaines concern es depuis cette machine. serveur secondaire ( secondary server ) Dans le cas dune panne ou dun engorgement du serveur primaire, les serveurs secondaires re coivent en pr evision une copie de la base de donn ees. Strat egiquement il est pr ef erable de les placer en dehors du domaine, sur le r eseau dun autre FAI. Il peut y avoir autant de serveurs secondaires que souhait e, de lordre de trois ou quatre est souvent recontr e. Au d emarrage ils re coivent les informations du serveur primaire, ou ils les lisent sur leur disque dur sils ont eu le temps de les y stocker au pr ec edent arr et du serveur, et si elles sont encore valides. 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 r epertoire /etc/namedb

Conversion dadresses IP en noms Cette possibilit e est indiqu ee comme optionnelle dans la RFC 1034 mais est n eanmoins bien commode voire m eme fr equement requise pour le client r eseau de services comme le courrier electronique ou m eme les serveurs de chiers anonymes (ftp). Si une machine est enregistr ee dans le TLD in-addr.arpa, cela signie cette idresse ip est administr ee, ce qui ne prouve rien quant aux bonnes intentions de son utilisateur mais est un gage de bonne conduite au niveau du r eseau. Il faut ajouter que le bon usage sur les r eseaux est de pr evoir une entr ee dans la zone reverse pour toutes les machines utiles et utilis ees dun r eseau accessible de lInternet. Le contraire provoque bien souvent la grogne (` a juste titre) des administrateurs. ` gauche de la gure on distingue Il faut reconsid erer la gure VII.01. A un domaine un peu particulier in-addr.arpa . Toutes les adresses sont exprim ees dans le top level domain : in-addr.arpa Du fait de la lecture inverse de larbre, les adresses IP sont exprim ees en mirroir de la r ealit e. Par exemple pour la classe B de lecp : 195.138.in-addr.arpa (Classe B 138.195) Le fonctionnement par d el egation est calqu e sur celui utilis e pour les 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 etre en charge de ladministration des zones reverses , portion du domaine arpa , des classes dadresses dont il dispose pour nommer ses machines, sil en re coit la d el egation (celle-ci est ind ependante des autres noms de domaines). Il faut noter que la notion de sous r eseau (cf page 35) nest pas applicable au domaine in-addr.arpa , ce qui signie que les adresses selon les contours naturels des octets. Ainsi, pour les clients de fournisseurs dacc` es nayant comme adresses IP ocielles que celles d elimit ees par un masque de sous r eseau large seulement que de quelques unit es (< 254), la gestion de la zone reverse reste du domaine 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 donn ees qui associe de mani` ere structur ee des noms ` a des adresses IP. 2. Des serveurs de noms, qui sont comp etents pour r epondre sur une ou plusieurs zones. 3. Des resolver capables dinterroger les serveurs avec une strat egie d enie par ladministrateur du syst` eme. TCP ou UDP ? Le port 53 bien connu pour le serveur de noms est pr evu pour fonctionner avec les deux protocoles. Normalement la majeure partie du trac se fait avec UDP, mais si la taille dune r eponse d epasse les 512 octets, un drapeau de len-t ete du protocole lindique au client qui reformule sans question en utilisant TCP. Quand un serveur secondaire d emarre son activit e, il eectue une connexion TCP vers le serveur primaire pour obtenir sa copie de la base de donn ees. En g en eral, toutes les trois heures (cest une valeur courante) il eectue cette d emarche.

S ecurisation du DNS

Le serveur de noms est la clef de vo ute des r eseaux, et cest en m eme temps un de ses talons dAchille parceque les programmes que nous employons quotidiennement utilisent sans discernement linformation acquise du r eseau. En 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 etablissement ? Lapparence de la page de garde ? Typiquement il y a deux situations de vuln erabilit e: 1. Dialogue serveur ` a serveur, notament lors de transferts de zones. 2. Interrogation dun serveur par un resolveur Pour faire conance en ce que vous dit le serveur de noms interrog e il faut dune part que vous soyez certains dinterroger la bonne machine et dautre part que celle-ci soit d etentrice dune information incontestable. Cest une cha ne de conance, comme toujours en s ecurit e, qui remonte par construction du fonctionnement du serveur de noms interrog e par votre application (comme nous lavons examin e dans les paragraphes qui pr ec` edent) jusquaux serveurs racines. La version ISC (consultez le paragraphe 6) du programme BIND utilise deux strat egies di erentes, selon les cas ci-dessus. Dans le premier cas il sagit dun m ecanisme nomm e TSIG/TKEY, dans le deuxi` eme DNSSEC.

TSIG/TKEY pour s ecuriser les transferts TSIG/TKEY utilisent une clef sym etrique, donc partag ee par les deux serveurs (cette clef leur est connue par des m ecanismes di erents). DNSSEC utilise un m ecanisme bas e sur le principe dun echange de clefs publiques.

115

3.1

TSIG/TKEY pour s ecuriser les transferts

Lusage dune clef sym etrique indique quil sagit dun secret partag e entre 2 serveurs. La m eme clef sert au chirement et au d echirement des donn ees. Le bon usage veut que lon d edie une clef ` a un certain type de transaction (par exemple le transfert dune zone) entre deux serveurs donn es. Cette mani` ere de proc eder se traduit donc rapidement par un grand nombre de clefs ` a g erer ce qui interdit un d eploiement g en eralis e sur lInternet. Pour eviter de trop longs temps de chirement, ce ne sont pas les donn ees ` a transf erer qui sont chir ees (ce ne sont pas des donn ees condentielles), mais leur signature avec un algorithme de type MD515 Le serveur qui re coit un tel paquet sign e, calcule la signature du paquet avec le m eme algorithme (MD5), d echire la signature jointe avec la clef secr` ete partag ee et compare les deux signatures. Le r esultat de cette comparaison dit si les donn ees sont valides ou non. Lint er et de ces transferts sign es est que les serveurs secondaires sont certains de mettre ` a jour leur zones avec des donn ees qui proviennent bien du d etenteur du SOA et qui sont absolument semblables ` a ce qui a et e emis. TSIG TSIG comme Transaction SIGnature est la m ethode d ecrite dans la RFC 2845 et bas ee sur lusage dune clef sym etrique. La g en eration de cette clef peut etre manuelle ou automatis ee avec le programme 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 r eseau), donc mise en place au coup par coup. TSIG sert egalement ` a la mise ` a jour dynamique ( dynamic update ), la connaissance de la clef par le client sert ` a la fois ` a lauthentier et ` a signer les donn ees 16 . TKEY TKEY, d ecrit dans la RFC 2930, rend les m emes services que TSIG tout en evitant le transport du secret (TSIG). Cette caract eristique est bas ee sur le calcul la clef sym etrique automatiquement avec lalgorithme de DieHellman plut ot que par un echange manuel 17 .
Ne pas h esiter ` a faire un man md5 sur une machine Unix pour en savoir plus ! 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 ` a base du tandem clef publique clef priv ee suppose lajout dun champ KEY dans les chiers de conguration du serveur. Comme dailleurs le m ecanisme suivant. . .

3.2

DNSSEC pour s ecuriser les interrogations

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

Mise ` a jour dynamique

La mise ` a jour dynamique de serveur de noms (RFC 2136) est une fonctionnalit e assez r ecente sur le r eseau, elle permet comme son nom lindique de mettre ` a jour la base de donn ee r epartie. Aussi bien au niveau du r eseau local qu` a l echelle de lInternet il sagit le 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 e son domaine chez un vendeur quelconque et qui au gr e des changements dadresse ip (attribu ee dynamiquement par exemple avec DHCP18 ) par son fournisseur dacc` es, met ` a jour le serveur de noms pour etre toujours accessible. Avec comme mot clef dyndns , les moteurs de recherche indiquent lexistence de sites commerciaux ou ` a caract` ere associatif, qui proposent cette 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 donn ees, le serveur de nom a un format pour ses champs, ou Resource Record , RR dans la suite de ce texte, d eni ` a lorigine dans la RFC 1035. En pratique toutes les distributions (commerciales ou libres) du serveur de noms conservent ce format de base de donn ees, la mise en uvre du serveur seule change (chier de conguration du daemon). Un serveur de noms a autorit e (responsabilit e du SOA) sur une ou plusieurs zones, celles-ci sont rep er ees dans ses chiers de conguration (named.conf 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 d ecrite dans le paragraphe suivant. Sil est serveur secondaire, le chier de conguration indique au server de quelle(s) zone(s) il est secondaire (il peut etre secondaire dun grand nombre de zones) et donc o` u (adresse IP) il devra aller chercher cette information. Cette action se traduit par ce que lon nomme un transfert de zone . Ce transfert est eectu e automatiquement ` a la fr equence pr evue par ladministrateur du champ SOA et donc connue d` es le premier transfert. En cas de changement sur le serveur principal, celui-ci avertit ( Notify ) ses serveurs secondaires de la n ecessit e de recharger la zone pour etre ` a jour. Le propos de ce qui suit nest pas de se substituer ` a une documentation nombreuse et bien faite sur le sujet, mais dapporter quelques el ements 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 g en eral ecrits sur une seule ligne de texte (sauf pour le champ SOA qui s etale sur plusieurs lignes. Le marqueur de n de ligne (CR+LF) est aussi celui de la n de lenregistrement. Le contenu g en eral dun tel enregistrement a la forme suivante (les accolades indique des donn ees 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 d esigne le d ebut oblig e et unique dune zone. Il doit gurer dans chaque chier db.domain et db.adresse Le nom de cette zone est ici rep er e par le caract` ere @ qui signie la zone courante, rep er ee par la ligne au dessus $(ORIGIN) sio.ecp.fr. . La ligne aurait egalement pu s ecrire :
sio.ecp.fr. IN SOA sio.ecp.fr. hostmaster.sio.ecp.fr. ( ...

Un probl` eme concernant cette zone devra etre signal e par e-mail ` a hostmaster@sio.ecp.fr (notez le . qui sest transform e en @). Les param` etres de ce SOA sont d ecrits sur plusieurs lignes, regroup ees entres parenth` eses. Le caract` ere ; marque le d ebut dun commentaire, qui sarr ete ` a la n de ligne. Les points en n de noms sont n ecessaires. Le num ero de s erie doit changer ` a chaque mise ` a jour de la zone (sur le serveur principal). Le Refresh indique la fr equence, en secondes, ` a laquelle les serveurs secondaires doivent consulter le primaire pour eventuellement lancer un transfert de zone (si le num ero de s erie est plus grand). Le Retry indique combien de secondes un serveur secondaire doit attendre un transfert avant de le d eclarer impossible. Le Expire indique le nombre de secondes maximum pendant lesquelles un serveur secondaire peut se servir des donn ees du primaire en cas d echec du transfert. Minimum ttl est le nombre de secondes par d efaut pour le champ TTL si celui-ci est omis dans les RR.

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 ` a un nom, cest donc celui qui est potentiellement le plus fr equement utilis e. Il doit y avoir un RR de type A pour chaque adresse dune machine.

{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 sp ecier les adresses pour la r esolution inverse, donc dans le domaine sp ecial IN-ADDR.ARPA. Notez le . en n de nom qui interdit la compl etion (il sagit 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 electronique. Nous examinerons son fonctionnement ult erieurement dans le chapitre sur le courrier electronique (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 ` a voir mais que ca fonctionne quand m eme parfaitement. Cette possibilit e est tr` es employ ee pour constituer des machines virtuelles, comme nous le verrons au chapitre X.

5.7

Autres RR. . .

Il existe dautres RR, entres autres HINFO , TXT, WKS et KEY, non trait es dans cette pr esentation parcequils napportent rien ` a la compr ehension du fonctionnement du serveur de noms. Le lecteur est fortement incit e ` a se 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 d eveloppe et favorise lemploi de loutil Open Source comme BIND (acronyme de Berkeley Internet Name Domain ). Cette version libre du serveur de nom est la plus employ ee sur les machines Unix du r eseau, ce qui justie que lon sy int eresse. Elle fournit une version du daemon named et un resolver int egr e dans la libc. On peut ais ement installer ce logiciel sur ` a peu pr` es toutes les impl ementations dunix connues (cf le chier INSTALL du r epertoire src).
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 sch ema g en eral de lorganisation logicielle du daemon named . Au d emarrage celui-ci lit sa conguration dans un chier qui peut se 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 d emarrage. Sa structure d epend de la version du logicielle, heureusement dans les deux cas la s emantique reste proche !
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 donn ee du localhost . Personne na la responsabilit e du r eseau 127, donc chacun doit le g erer pour lui-m eme. Labsence de ce chier nemp eche pas le serveur de fonctionner, mais ne lui permet pas de r esoudre 127.0.0.xx (o` u xx est le num ero de la machine courante, souvent 1). db.terminal Exemple de chier de base de donn ees pour le domaine factice 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 donn ees de la zone reverse pour le domaine terminal.fr, cest ` a dire le chier qui permet au 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-m eme. Cest une alternative ` a lusage direct des signaux. Le canal de communication 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 examin es en travaux pratiques, tout comme les chiers lus ou ecrits dans les r epertoires /var/run et /var/tmp/. Enn la ` eche vers syslog signie que named utilise ce service pour laisser une trace de son activit e (cf cours sur larchitecture des serveurs). Enn, le BOG, cest ` a dire le Bind Operations Guide , d etaille le contenu des champs de la base de donn ees.

Bibliographie

Quand on sait d ej` a , la page de man de named sut ` a v erier un point obscur ! Sinon il existe une documentation tr` es fournie sur le sujet, avec 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 ` a cette adresse : http ://www.isc.org/products/BIND/ 22 on trouve egalement la derni` ere version de ce document sur le site de lISC
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 electronique


1 G en eralit es sur le courrier electronique

Le courrier electronique, ou mail est lun des deux services les plus populaires sur le r eseau, avec le web. Cest aussi lun des plus vieux services du r eseau, bien avant que le r eseau existe sous la forme que lon pratique aujourdhui1 . La pr eface de la [RFC 822], document fondamental parmi les documents fondamentaux pour ce chapitre, laisse supposer lexistence de nombreux formats d echanges electroniques sur lArpanet, et ce avant 1977. Sa popularit e repose sur sa grande souplesse et rapidit e demploi. Il permet aussi bien les echanges professionnels que les echanges priv es ; son mode dadressage donne la possibilit e denvoyer un courrier ` a une personne comme ` a une liste de personnes ou encore ` a un automate capable de rediuser vers un groupe (mailing-list). De nombreux outils d evelopp es, ` a lorigine essentiellement sur le syst` eme Unix, autour de ce concept ouvrent un vaste champs de possibilit es aux utilisateurs de tous les syst` emes dexploitation, comme la ventilation des courriers par th` eme, le renvoi automatique, le r epondeur (pendant les absences), lacc` es ` a sa boite aux lettres depuis des endroits di erents, la r eception de fax,. . .La liste ne peut pas etre exhaustive ! Cest souvent pour avoir lusage du courrier electronique que les entreprises acc` edent ` a lInternet. Les autres services viennent apr` es.

1.1

M etaphore du courrier postal

Un courrier postal (ou de surface, s-mail) a besoin de ladresse du destinataire, de ladresse de l emetteur (pour la r eponse), dun timbre et dune enveloppe. Une fois dans la bo te aux lettres, lenveloppe est rout ee de la poste locale vers la poste la plus proche du destinataire, pour etre nalement d elivr ee par un facteur.
1

Un historique int eressant http ://www.fnet.fr/history/

126

Courrier electronique Pour un courrier electronique cest la m eme chose ! Il existe de tr` es nombreux outils pour lire/ ecrire un mail, des outils pour jouer le r ole du bureau de poste et/ou du facteur. Sous Unix le facteur est le syst` eme lui-m eme, le bureau de poste un programme nomm e sendmail2 . Il existe deux autres alternatives non abord ees dans ce document, ` a savoir le 3 4 programme qmail ou encore le programme postx .

1.2

Adresse electronique

Tous les courriers electroniques ont un destinataire pr ecis e par son adresse 5 electronique, ou E-mail . Celle-ci pr ecise le nom du destinataire et le site o` u il re coit son courrier electronique. Le nom du destinaire est une cha ne de caract` eres. Traditionnellement et pour des raisons techniques, sur le syst` eme Unix, le login de lutilisateur peut etre egalement le nom de sa boite aux lettres. Cette possibilit e est de moins en moins vraie ` a mesure que dautres syst` emes avec dautres logiques de fonctionnement font leur apparition sur le r eseau (notamment la lecture du mail via un interface html ou encore lorsque le mail est g er e par une base de donn ees). Par exemple, il est assez fr equent de voir employer le nom complet (pr enom et nom de famille) pour d esigner linterlocuteur distant. La conversion ultime entre cette convention et la bo te aux lettres de lutilisateur est laaire du bureau de poste le plus proche, cest ` a dire le programme sendmail pour ce document (voir plus loin au paragraphe 4). Le caract` ere @ (lire at ) s epare lidenticateur du destinataire de la destination. La destination est peut etre vide (il sagit alors dun destinataire sur la machine courante, ou dun alias que le sendmail local sait traiter), etre 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 m ecanisme de compl etion dans le resolver page 108 !). user3@nom de machine.domaine Destinataire sur une machine particuli` ere dun domaine particulier (non forc ement local). user4@domaine Destinataire sur un domaine particulier (m eme remarque 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 e en m` el , ou couriel pour les documents administratifs. . . ;-)

2 Format dun E-mail - RFC 822 On devine ais ement que le fonctionnement du courrier electronique sur une machine distante est fortement li ee au bon fonctionnement du serveur de noms (chapitre VII). Qui plus est, lorsque seul un nom de domaine est pr ecis e ` a droite du caract` ere @ , une information manque apparemment quant ` a la machine susceptible de recevoir le mail. Le lecteur en qu ete de plus de pr ecisions trouvera une description exhaustive 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 electronique ob eissent ` a une structure bien d enie par la [RFC 822] de David H. Crocker : un en-t ete et un 6 corps de message, s epar es par une ligne blanche (deux CRLF qui se suivent). Le contenu de len-t ete dans son int egralit e nest pas toujours spontan ement montr e par les outils qui nous permettent de lire et denvoyer du courrier electronique. Une option est toujours accessible pour ce faire, comme h sous mutt 7 . Une partie de len-t ete est g en er ee automatiquement par le programme qui se charge du transfert (le paragraphe suivant nous dira quil sagit dun MTA), une autre est ajout ee par le programme qui permet de composer le mail, le MUA, une autre enn est tap ee par lutilisateur lui-m eme.

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` eres 13 et 10 de la table ASCII - cf man ascii http ://www.mutt.org/ le MUA, voir paragraphe suivant, pr ef er e de lauteur

128

Courrier electronique Len-t ete est constitu e de lignes construites sur le mod` ele : identicateur : [ valeur ] CRLF Lidenticateur ne peut pas contenir le caract` ere : parcequil sert de s eparateur avec la partie droite. Il est constitu e de caract` eres ASCII cod es sur 7 bits et imprimables (cest ` a dire [33, 126]), except e lespace. Valeur est optionnelle. Lusage des majuscules ou des minuscules est indi erenci e. Lordre dapparition de ces champs est quelconque. Seule lorganisation de la gure VIII.01 doit etre globalement respect ee. Le lecteur soucieux dune description exhaustive de ce en quoi peut etre constitu e un en-t ete pourra se repporter au paragraphe 4.1 de la RFC (SYNTAX). Len-t ete dun mail donne des informations de nature vari ee sur le message lui-m eme. On peut les apparenter, pour certaines dentres elles, aux 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 etendus X- ? Nous aurons loccasion dexaminer des en-t etes, notamment lors des travaux 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 electronique de mani` ere able et ecace. Il est d eni dans la [RFC 821] de Jonathan B. Postel. Ind ependant par sa conception dun quelconque sous-syst` eme de transport, il est principalement aujourdhui encapsul e dans des paquets TCP ` a destination du port 25 (cf le chier /etc/services). Dans un pass e pas si lointain lacc` es r eseau de beaucoup de sites se r esumait au courrier electronique encapsul e dans des trames du protocole UUCP, donc sur liaison s erie via modem !

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 r epond par des codes num eriques qui indiquent le statut de la prise en compte de la commande. Cest pourquoi il est ais e de se connecter sur un MTA avec un simple 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 r epond ` a la connexion par un code 220 pour dire que le service est op erationnel (service ready), suivi du nom de la machine, de la banni` ere du programme, de la version de sa conguration, et de sa date courante. Puis lutilisateur a tap e la commande NOOP qui na dautre eet que de forcer le serveur ` a r epondre et renvoyer un code (250) pour dire que tout va bien. Enn Lutilisateur a tap e QUIT pour nir proprement la transaction. La r eponse du serveur est un code 221 pour signier la n canonique de la connexion.
Attention toutefois de ne pas abuser de cette pratique car de nombreuses attaques de sites ont d emarr e par le pass e` a laide un d etournement de sendmail. Les administrateurs r eseaux sont donc attentifs au trac sur le port 25 ; il est pr ef erable de r eserver ce genre de tests uniquement sur son propre site. 9 http ://www.sendmail.org/
8

130

Courrier electronique Dans un deuxi` eme essai nous utilisons loption -v du programme mail, pour visualiser les echanges entre le MUA (machine athome.mondomain.fr) 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 re cu, lu aussi avec mail :


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, ca passe ! :) Il est egalement int eressant dobserver ` a ce niveau que les caract` eres du courrier ont et e consid erablement enrichis par un en-t ete volumineux (relativement). En eet, chaque nud travers e (MTA), ajoute un champ Received permettant apr` es coup de suivre le trajet du courrier. Les autres champs

Protocole SMTP comme Date :, Subject : ou Message-Id : sont ajout es dans len-t ete par le MUA de l ecrivain du message. Cette partie de len-t ete ajout ee par le MUA dorigine est souvent destin ee ` a piloter le comportement du MUA du destinataire du message plus que pour etre lue. Cette attitude sest g en eralis ee au point de devenir assez compliqu ee et etre formalis ee dans un ensemble de r` egles baptis ees MIME comme Multipurpose Internet Mail Extensions ([RFC 2184]). La fonction la plus r epandue et la plus simple de MIME est dautoriser lusage des caract` eres accentu es (codage sur 8 bits ou plus) ` a lint erieur du corps du message (len-t ete SMTP reste cod ee sur 7 bits). Lutilisateur voit alors appara tre des lignes suppl ementaires comme celles-ci :
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` eres accentu es, d enie dans la [RFC 822]. Le plus souvent on trouve des lignes 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 ` a lex ecution dun programme ext erieur au MUA, ce qui constitue une dangereuse faille potentielle dans la s ecurit e des r eseaux, donc ` a eviter.

3.2

Principales commandes de SMTP

Exp erimentalement nous avons d ecouvert quelques uns des mots r eserv es du protocole : HELO, MAIL, RCPT, DATA, QUIT. Une impl ementation minimale 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 organis es sur trois chires, le premier chire donne le sens g en eral de la r eponse, tr` es succintement ce qui d ebute par 1,2 ou 3 a une signication positive, 4 ou 5 signie une erreur. Une information plus d etaill ee se trouve ` a lannexe E de la RFC. Les cinq commandes d ecouvertes pr ec edement sutilisent toujours dans cet ordre. Examinons succintement leur usage : Commande HELO Synopsis : HELO <espace> <domaine> <CRLF> Cette commande est utilis ee pour identier l emetteur du mail. Largument qui suit, domain est le nom de la machine ou du domaine do` u provient la connexion.

132

Courrier electronique En r eponse le serveur envoie une banni` ere dans laquelle il sidentie et 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 d ebute un transfert de mail. En argument sont transmis (chemin inverse) ladresse e-mail de l emetteur et la liste des machines qui ont relay e le mail courant. La premi` ere machine est la plus r ecente. Cette information est utilis ee pour renvoyer, sil y a lieu, une notication de probl` eme ` a l emetteur du mail. Par exemple : MAIL FROM :<@mailhub.ici :@mailhost.labas :Lambda@mondomain.fr> Commande RCPT Synopsis : RCPT <espace> TO : <destinataire> <CRLF> Cette commande est la deuxi` eme etape dans la proc edure denvoi dun mail. Il y a une commande de ce type par destinataire du courrier ( recipient ). Par exemple : RCPT TO :<Lambda@mondomain.fr> Il est int eressant de noter que les arguments de cette commande et ceux de la pr ec edente (MAIL) forment lenveloppe du mail (exp editeur et destinataire). Commande DATA Synopsis : DATA <CRLF> Apr` es r eception de la commande, le serveur lit les lignes de texte en provenance du client jusqu` a rencontrer la s equence <CRLF>.<CRLF> qui marque la n du message. Il faut remarquer que celui-ci comprend lint egralit e de la gure VIII.01. Commande QUIT Synopsis : QUIT <CRLF> Marque la n de la session et entraine la cl oture de la connexion.

Protocole SMTP

133

3.3

Propagation du courrier electronique

SMTP est d eni comme un protocole de transfert, donc un moyen pour router et d elivrer le message ` a son (ses) destinataire nal (naux).
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 ecoutent le r eseau sur le port 25 et dialoguent entre-eux avec le protocole SMTP (ESMTP10 ). MSA Mail Submission Agent , cest une nouveaut e d enie par la [RFC 2476] et qui joue le r ole dinterface entre le MUA et le MTA. Lobjet du MSA est de s eparer les fonctions de transfert du courrier et dacceptation de nouveaux courriers emis depuis les MUA. Cette s eparation des t aches am eliore deux aspects : La s ecurit e Les nouveaux mails sont soumis ` a un daemon qui ne nex ecutent pas avec les droits du root11 . La conformit e aux standards Les messages proviennent de MUAs qui ne respectent pas forc ement tous les pr erequis de formulation des en-t etes. Le r ole du MSA est de v erier et de compl` eter ces en-t etes avant de soumettre les mails au MTA pour le routage. MUA Mail User Agent ou encore mailer, cest le programme qui permet de lire et ecrire le corps du courrier et de param etrer quelques el ements de len-t ete, principalement ladresse du destinaire, et le sujet du message.
10 11

Extented SMTP SUID bit

134

Courrier electronique Il existe un tr` es grand nombre de MUAs sous Unix, il est courant de rencontrer mail, mailx, elm, pine, mutt, mh, eudora, kmail, sylpheed... Il y en a pour tous les go uts ! OS Operating System, le syst` eme dexploitation sur lequel fonctionnent ces programmes. La gure 2 illustre la possibilit e la plus simple d echange entre deux MTA : la connexion directe. Cela signie que le MTA de la station emettrice contacte le MTA de la station r eceptrice et lui d elivre directement le message. La vie r eelle est plus compliqu ee car elle tient compte de lorganisation hi erarchique des r eseaux et surtout de la s ecurit e qui est un aspect devenu important sur lInternet. Cela se traduit par un emploi g en eralis e de machines 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 electroniques dun site, vers lext erieur et inversement. Elle a des avantages, notamment : Avoir une politique de s ecurit e concentr ee sur une machine plut ot que sur toutes les stations du r eseau : le routeur ltrant nautorise les acc` es ext erieurs sur le port smtp que sur cette machine.

Courriers ind esirables - Le spam Avoir une politique centralis ee de ltrage des contenus ind esirables (virus) et emetteurs suspects (spam). Limiter le nombre de congurations compliqu ees de sendmail ` a un petit nombre de machines. Les stations des utilisateurs peuvent se contenter dune conguration standard plus facile ` a distribuer et ` a adapter automatiquement. Permettre de masquer plus facilement les machines internes du r eseau vis ` a vis de lext erieur. En clair, les courriers auront lair de provenir de cette machine plut ot que de la station dun utilisateur sur le r eseau interne. Ladresse de l emetteur aura la forme : user@domaine au lieu de : user@machine.domaine. Permettre le stockage interm ediaire du courrier en attente dune d elivrance : les stations des utilisateurs ne sont pas toujours en fonctionnement. Cette architecture est th eorique, en pratique il peut y avoir une hi erarchie de relay mail plus compliqu ee. Par exemple une machine distincte suivant que le courrier entre ou sort du site, une arborescence de machines relais quand lentreprise est elle-m eme r epartie sur plusieurs sites g eographiques et ne poss` ede quune liaison vers lext erieur,. . .

135

3.4

Courriers ind esirables - Le spam

Le spam est laspect tr` es d esagr eable du courrier electronique. Par spam on d esigne ces innombrables courriers, le plus souvent ` a caract` ere commercial, qui envahissent nos boites aux lettres electroniques. Certaines estimations tablent sur 30% de spam dans le trac mail. Deux questions se posent, comment le caract eriser et surtout comment l eviter. Caract eristiques du spam Un contenu commercial (ou nancier dune mani` ere ou une autre) Une importante liste de destinataires En-t ete du message truqu ee Un grand nombre dexemplaires du m eme message envoy e dans un court laps de temps Utilisation de ladresse dun destinataire sans son consentement explicite Usage dun site open mail relay pour l emission Champs To et From de len-t ete invalides Pour m emoire, un site open mail relay autorise un RCPT qui ne d esigne pas un destinataire local. Le site sert alors en quelque sorte de tremplin pour

136

Courrier electronique le mail, avec un eet de dissimulation du site emetteur v eritable. Les versions modernes des MTA interdisent cette possibilit e. Eviter le spam Cest une question ouverte. . . Sil est evident que lil humain reconnait un tel courrier de mani` ere quasi infaillible, il nen est pas de m eme pour la machine. N eanmoins des outils existent12 qui etablissent un pr e-ltrage souvent tr` es ecace mais laissant toujours un pourcentage de mails qui franchissent les protections. Ces outils sont toujours bas es sur un ltrage. Plus celui-ci est complexe, plus le temps de traitement ` a consacrer pour 1 courrier electronique est important. Lid eal etant evidement de reconna tre la qualit e dun e-mail en tr` es peu de cycles machines. . . Il y a deux parties ` a examiner dans un courrier, len-t ete et le corps (gure VIII.01). Tout ce qui est v eriable dans len-t ete et qui concerne le r eseau se r esoud bien (d etection des sites open mail relay ou liste des utilisateurs ind esirables). Cette approche nest pas susante car rien noblige dans le protocole ` a ce que les champs From : et To : de len-t ete MIME soient en concordance avec les el ements du protocole SMTP. On parle alors de fake mail . Lexemple qui suit illustre cette faille o combien navrante :
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 d elivr e dans la boite aux lettres de lutilisateur tartempion avec des champs From : et To : compl` etement inexploitables.
12

Cf documentation compl ementaire distribu ee en cours

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

137

4
4.1

Exemple de MTA - Sendmail et son environnement


Relations avec le DNS

Comme nous lavons evoqu e au paragraphe ??, la relation entre le MTA et le DNS est etroite. Sendmail a besoin du serveur de noms pour les op erations 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. D eterminer quelles sont les machines susceptibles de recevoir du courrier pour le domaine ` a atteindre. Le quatri` eme point est le plus crucial. Si le DNS du domaine ` a atteindre (une adresse est toujours mise sous la forme nom@domain) ne d esigne pas de machine capable de recevoir le courrier, le mail ne passera jamais pour ce domaine.

138

Courrier electronique Le champ RR (Resource Record) correspondant est du type MX (Mail Exchanger). Il sp ecie une liste dh otes pond er es par des pr ef erences, ` a qui on peut envoyer du courrier. La pond eration indique lordre ` a suivre pour les tentatives de connexions : il faut commencer par la valeur la plus basse. Si cette liste est explor ee de bout en bout sans succ` es il y a echec de la transmission du courrier. Sil y a echec de la re emission, le mail est conserv e un certain temps, puis est nalement rejet e sil y a persistance de l echec. Le r esultat est mat erialis e dans un chier nomm e dead.letter Figure 4, Le contenu du champ RR renvoy e par le DNS pourrait avoir la 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 baptis ee MX par le DNS nest pas forc ement localis ee dans le domaine pour lequel elle re coit le courrier, cest m eme souvent le cas pour les machines relay . Cest le cas de la troisi` eme ligne, machineC.domaineX

Relations avec lOS

139

4.2

Relations avec lOS

Sendmail a de multiples relations avec le syst` eme dexploitation, comme la gure 5 tente de le r esumer :

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 e op erationnelle de sendmail est consign ee ` a laide de syslog13 , ce qui explique la pr esence de la ligne suivante trouv ee dans le chier /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 m eme conguration ; autant de Mailer s electionn es en fonction de ladresse du destinataire (cf sendmail.cf). /etc/sendmail.cf est le chier de conguration de sendmail. Tout syst` eme Unix est livr e avec une conguration standard quil faut adapter ` a la situation locale ; cest en g en eral ` a cet instant que les administrateurs syst` emes deviennent pensifs. . .(voir pourquoi au paragraphe 5). /etc/aliases est une base de synonymes. Quand sendmail re coit un courrier, il tente de reconna tre le nom du destinataire dans cette base et si cest le cas de lui appliquer la transformation prescrite. Un certain nombre dalias sont requis par la [RFC 1123], dautres sont conseill es par la [RFC 2142]. Un court extrait du-dit chier :
13

ements de serveurs Chapitre III du cours de programmation El

140

Courrier electronique
# 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 e au postmaster de ce site, sendmail transforme postmaster en root, puis root en user. Si cette derni` ere cha ne ne fait pas lobjet dune autre transformation par cette table, il sagit dun utilisateur de la machine courante. Lentretien de la table des alias est de la responsabilit e de ladministrateur de la machine. La table des alias dun domaine est un chier strat egique quil convient de mettre ` a jour soigneusement (droits dacc` es, utilisateurs inexistants, boucles. . .). ` A chaque changement dans cette table ladministrateur doit fabriquer une table dacc` es rapides (hash table) ` a laide de la commande sendmail -bi souvent li ee ` a newaliases /etc/userdb Cette table, User Database permet au sendmail deffectuer une traduction de cha ne sur les noms des utilisateurs pour 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 r epertoire sont stock es les mails en attente dune d elivrance. Il peuvent y rester plusieurs jours (cest un param` etre de la conguration du sendmail), on peut visualiser cette le dattente avec la commande mailq. Si un grand nombre de courriers sont en attente, et ca peut etre le cas pour les machines relais, la section du disque dur qui supporte cette partition (ici /var) doit faire lobjet dun dimensionnement en cons equence, sous peine dobliger sendmail ` a refuser les mails faute de place disque. /var/mail/userX. Chaque utilisateur de la machine locale (il peut ne pas y en avoir sur un serveur) a une bo te aux lettres (mail box) rep er ee comme un chier ayant comme nom son login. Par exemple /var/spool/mail/root. Ce chier est mis ` a jour automatiquement par le MTA local en cas darriv ee de courrier. De m eme que pour le r epertoire de le dattente, le r epertoire des bo tes aux lettres des utilisateurs doit faire lobjet dune attention par-

Relations avec lOS ticuli` ere de la part de ladministrateur ; la prolif eration des documents attach es aux courriers electroniques est un eaux contre lequel il est dicile de se pr emunir sauf ` a agrandir perp etuellement la taille de la partition /var. . . ! :( ${HOME}/.forward : avant d etre nalement d elivr e dans la bo te aux lettres de lutilisateurs, sendmail lit le contenu de ce chier, ${HOME} etant le r epertoire racine des chiers de lutilisateur en question. Le chier .forward est la base personnelle dalias pour chaque utilisateur, ca permet de renvoyer son courrier vers dautres sites, voire aussi deectuer des transformations avant de stocker les mails (procmail). Si le .forward contient la cha ne suivante :
moi@un-autre-site.ailleurs

141

Tous les courriers envoy e` a cette utilisateurs sont renvoy es ` a ladresse indiqu ee. 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 electroniques par mots clefs (indispensable pour g erer les mailing-listsabondantes). Enn on peut remarquer quaucun signal nest pr evu pour indiquer ` a sendmail quil faut relire son chier de conguration, cest voulu par le concepteur. Lors de la mise au point de ce chier, il faut arr eter ( kill -TERM pid-du-sendmail) puis relancer (/usr/sbin/sendmail -bd -q30m) manuellement. . .

142

Courrier electronique

4.3

Le cas de POP

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

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 l egions sur les PCs et sur les stations de travail sous 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` es simple qui fonctionne parfaitement mais qui nest pas d enu e de d efauts : 1. Lauthentication (login/password) est echang ee en clair sur le r eseau 2. Sur larchitecture Unix, lutilisateur doit avoir un compte sur la machine serveur 3. Les messages doivent etre r ecup er es sur le poste client pour etre manipul es (en POP3 un double peut rester sur le serveur) 4. La boite aux lettres ne peut etre consult ee que par un seul client ` a la fois Ces points deviennent vite r edhibitoires quand le poste client doit acc eder au serveur au travers dun r eseau non s ur, et surtout lorsque le d etenteur de la boite aux lettres veut consulter ses mails depuis des postes di erents. Ce cas de gure est de plus la r ealit e des professionnels en d eplacements. Cest pourquoi dautres solutions se sont d evelopp ees et sont de plus en plus utilis ees : les messageries accessibles via un browser web (webmail), donc qui utilisent comme support le protocole HTTP (voir page 149), ou un rempla cant du procole POP, le protocole IMAP !
14

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

5 Conguration du Sendmail

143

4.4

Le cas de IMAP

Bien que largement d eploy e que depuis quelques ann ees, le protocole IMAP Internet Message Access Protocol a et e d evelopp e` a luniversit e de Stanford en 1986. Cest actuellement la version 4rev1 qui est utilis ee, d enie dans la [RFC 2060]. Larchitecture pr esent ee gure VIII.06 reste valable, pratiquement il sut dy remplacer le mot POP par IMAP15 ! Les fonctionnalit es sont plus riches et surtout pallient aux inconv enients list es pour POP. En clair, les points n egatifs list es pour POP sont tous r egl es.

Conguration du Sendmail

Cette section est une extraction libre et incompl` ete du paragraphe 5 du document intitul e Sendmail Installation and Operation Guide, disponible dans toute distribution de la V8. On peut egalement trouver ce document dans la section System Managers Manual (SMM) des syst` emes BSD16 . 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 e comme une s erie de lignes, le premier caract` ere de chacune delles en pr ecise le type. Une ligne vide ou qui d ebute par un # est ignor ee (commentaire), une ligne qui d ebute par un espace ou une tabulation est la continuation de la pr ec edente.

5.1

R` egles de re ecriture

Les r` egles de re ecritures sont rep erables comme ces lignes qui d emarrent par un S (d ebut dun paquet de r` egles) ou un par un R (simple r` egle). Les paquets de r` egles (organisation densemble gure 7 ) ont comme but essentiel danalyser puis de prendre les bonnes d ecisions en fonction des adresses trouv ees dans len-t ete. Cest une d emarche purement formelle. Ces r` egles utilisent une syntaxe dense qui rebute g en eralement les administrateurs. Il faut imaginer quelles sont int egralement analys ees chaque fois que le programme sendmail est invoqu e, cest ` a dire en gros pour chaque e-mail entrant ou sortant. Elles doivent donc etre faciles ` a analyser, m eme par un cpu de modeste performance (ou tr` es charg e, ce qui revient nalement au m eme). Lensemble fonctionne comme un syst` eme de production, cest ` a dire qui consomme des r` egles lues s equentiellement et les applique ` a un jeux de donn ees initiales, ici une ou plusieurs adresses electroniques.
Consultez http ://www.imap.org/ pour plus dinformations pour FreeBSD, NetBSD ou OpenBSD ca se trouve /usr/share/doc/smm/08.sendmailop/
16 15

dans

le

r epertoire

144

Courrier electronique La partie gauche (ou lhs17 ) sert de d eclencheur (pattern matching) pour une r` egle. La partie droite (ou rhs18 ) est d eclench ee si le motif de la partie gauche est reconnu dans le ux de donn ees. Le r esultat produit, sil existe, est reinject e dans le syst` eme de production et ce jusqu` a epuisement des possibilit es. La gure 7 donne un aper cu du fonctionnement de lautomate, les chires (0,1,2,3,4) sont autant de ruleset, comprendre des paquets de r` egles qui sont regroup ees ensembles parcequelles traitent dun objectif commun.

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` egles sont num erot ees, le premier chire dit ` a quel paquet elles appartiennent. Le paquet de r` egles 0 sert essentiellement ` a d eterminer le mailer cest ` a dire le moyen denvoyer le courrier (SMTP, ESMTP, UUCP. . .). Les paquets de r` egles 1 et 2 sont appliqu es respectivement ` a len-t ete des messages qui sortent (send) ou qui entrent (receive). Le paquet de r` egles 3 est appliqu e syst ematiquement ` a toutes les adresses. Le paquet de r` egles 4 est appliqu e` a toutes les adresses dans le message, typiquement pour passer dune forme interne ` a une forme externe. Le paquet de r` egles 5, non repr esent e sur lautomate, sert ` a traiter les adresses locales apr` es que les aliases aient et e appliqu es. Les paquets de r` egles sont rep er es par la lettre S, qui en balise le nom, comme dans :
###################################### ### Ruleset 0 -- Parse Address ### ###################################### Sparse=0
17 18

left hand side right hand side

Conguration du Sendmail Quant aux r` egles, elles d emarrent toutes avec la lettre R, comme dans :
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` egle, sur le mod` ele : Rlhs rhs commentaire 2. Le s eparateur de champ entre les trois partie de ces r` egles est la tabulation (une au minimum) Ladresse postmaster@mondomain.fr, par exemple, quand elle se pr esente devant le paquet de r` egles 0 qui d emarre ci-dessus, a et e mise sous une forme canonique par dautres r` egles appliqu ees pr ealablement (notament 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` egles (lhs) pour d eterminer celles qui peuvent etre d eclench ees. Dans la partie gauche $ sapplique ` a toute suite de tokens, m eme vide. Donc la premi` ere ligne convient. La deuxi` eme ne le pourrait pas car la cha ne postmaster pr ec` ede le caract` ere < et le @ est suivi de mondomain . fr .. La troisi` eme et la quatri` eme r` egle sont egalement d eclenchables mais pr esentement lordre dapparition est egalement lordre de d eclenchement, cette possiblit e sera donc examin ee eventuellement plus tard. La partie droite de la premi` ere r` egle commence par $ : $>Parse0 ce qui signie lappel dun autre paquet de r` egles que lon pourra trouver plus loin 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 electronique

5.2

Exemple de sortie de debug

Il est utile davoir ce sch ema en t ete quand on d ebogue les r` egles : avec loption -bt de sendmail on peut suivre la progression de la transformation, r` egle par r` egle.
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 ` a toutes les distributions de la V8.xx. 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 electronique 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 pr esentation succincte du protocole HTTP 1.0 et du serveur Apache qui lutilise. Le protocole HTTP1 est le protocole dapplication utilis e pour v ehiculer, entres autres, de lHTML2 sur lInternet. Cest le protocole le plus utilis e en volume depuis 1995, devant FTP, NNTP et SMTP ; il accompagne lexplosion de lutilisation du syst` eme global dinformation WorldWide Web. Depuis 1990, date dapparition du Web, le protocole HTTP evolue doucement mais surement. Il est longtemps rest e sous forme de draft. La premi` ere version d eploy ee largement a et e la 1.0, d enie dans la RFC 1945 de mai 1996. Depuis le d ebut du mois de janvier 1997 est apparue la version 1.1, deux fois plus volumineuse pour tenir compte des nouvelles orientations de lusage du service. Aujourdhui ce protocole est tellement r epandu que pour bon nombre de nouveaux utilisateurs du r eseau, lInternet cest le web ! Techniquement, lusage de ce protocole se con coit comme une relation entre un client et un serveur. Le client, appel e g en eriquement un browser, un User Agent, ou encore butineur de toile, interroge un serveur connu par son url3 dont la syntaxe est bien d ecrite dans la RFC 1738. Par exemple la cha ne de caract` eres http ://www.sio.ecp.fr/ est une url ; il sut de la transmettre en tant quargument ` a un quelconque outil dexploration et celui-ci vous renverra (si tout se passe comme pr evu !) ce qui est pr evu sur le serveur en question pour r epondre ` a cette demande (car il sagit bien dune requ ete comme nous le verrons plus loin dans ce chapitre). Le serveur, suppos e` a l ecoute du r eseau au moment o` u la partie cliente linterroge, utilise un port connu ` a lavance. Le port 80 est d edi e ociellement
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 d ecision est prise ` a la conguration du serveur). Lurl qui d esigne un serveur peut contenir dans sa syntaxe le num ero de port sur lequel il faut linterroger, comme dans : http ://www.sio.ecp.fr :11235/.

1.1

Exemple d echange avec http

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

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

La requ ete, suivie dune ligne vide. HTTP/1.1 200 OK Enn la r eponse du serveur, Date: Fri, 01 Mar 2002 10:59:06 GMT Server: Apache/1.3.23 (Unix) que lon peut d ecomposer en Last-Modified: Sat, 10 Nov 2001 16:13:02 trois GMT parties :
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-t ete MIME 3. Des octets, ici ceux dune page ecrite en HTML. Notons egalement la deconnexion ` a linitiative du serveur, 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 echange

Lexemple qui pr ec` ede est typique dun echange entre le client et le serveur : une question du client g en` ere une r eponse du serveur, le tout lors dune connexion TCP qui se termine lors de lenvoi du dernier octet de la r eponse (cl oture ` a linitiative du serveur). Le serveur ne conserve pas la m emoire des echanges pass es, on dit aussi quil est sans etat, ou stateless.
4 5

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

Le protocole HTTP La question et la r eponse sont b aties sur un mod` ele voisin : le message HTTP.
Message HTTP

151

B
Dbut du message

D C

gure IX.01 Les parties A, B et C forment len-t ete du message, et D le corps. A La premi` ere ligne du message, est soit la question pos ee (request-line), soit le statut de la r eponse (status-line). La question est une ligne termin ee par CRLF, elle se compose de trois champs : Une m ethode ` a prendre dans GET, HEAD, ou POST. GET Plus de 99% des requ etes ont cette m ethode, elle retourne linformation demand ee dans lURL (ci-dessous). HEAD La m eme chose que GET, mais seul len-t ete du serveur est envoy e. Utile pour faire des tests daccessibilit e sans surcharger la bande passante. Utile egalement pour v erier de la date de fraicheur dun document (information contenue dans len-t ete). POST Cette m ethode permet denvoyer de linformation au serveur, cest typiquement le contenu dun formulaire rempli par lutilisateur. Une ressource que lon d esigne par une URL6 . Par exemple http ://www.site.org/. La version du protocole , sous forme HTTP-Num ero de version. Par exemple HTTP/1.1 ! La r eponse. Cette premi` ere ligne nest que le statut de la r eponse, les octets qui la d etaillent se trouvent plus loin, dans le corps du message. Trois champs la composent, elle se termine par CRLF : La version du protocole , sous forme HTTP-Num ero de version, comme pour la question. Statut Cest une valeur num erique qui d ecrit le statut de la r eponse. Le premier des trois digits donne le sens g en eral :
6

Uniform Resource Locator, consulter la RFC 1630

152 1xx 2xx

Anatomie dun serveur Web Nest pas utilis e Futur Use Succ` es, laction demand ee a et e comprise et ex ecut ee correctement. 3xx Redirection. La partie cliente doit reprendre linterrogation, avec une autre formulation. 4xx Erreur cot e client. La question comporte une erreur de syntaxe ou ne peut etre accept ee. 5xx Erreur cot e serveur. Il peut sagir dune erreur interne, due ` a lOS ou ` a la ressource devenue non accessible. Phrase Cest un petit commentaire (Reason- Phrase) qui accompagne le statut, par exemple le statut 200 est suivi g en eralement du commentaire OK ! B Cest une partie optionnelle, qui contient des informations ` a propos du corps du message. Sa syntaxe est proche de celle employ ee dans le courrier electronique, et pour cause, elle repecte aussi le standard MIME7 . Un en-t ete de ce type est constitu e dune suite dune ou plusieurs lignes (la n dune ligne est le marqueur CRLF) construite sur le mod` ele : Nom de champ : Valeur du champ CRLF Eventuellement le marqueur de n de ligne peut etre omis pour le s eparateur ;. Exemple den-t ete MIME :
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 ` a laquelle le message a et e envoy e. Bien s ur il sagit de la date du serveur, il peut exister un d ecalage incoh erent si les machines ne sont pas synchronis ees (par exemple avec XNTP). Server : Contient une information relative au serveur qui a fabriqu e la r eponse. En g en erale la liste des outils logiciels et leur version. Content-type : Ce champ permet didentier les octets du corps du message. Content-length : D esigne la taille (en octets) du corps du message, cest ` a dire la partie D de la gure 1. Last-modified : Il sagit de la date de derni` ere modication du chier demand e, comme lillustre le r esultat de la commande ll (voir aussi la co ncidence de la taille du chier et la valeur du champ pr ec edent).
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 echanges. Cest un moyen de maintenir le dialogue avec un serveur en particulier, par exemple quand ceux-ci sont en grappe pour equilibrer la charge et assurer la redondance. C Une ligne vide (CRLF) qui est le marqueur de n den-t ete. Il est donc absolument obligatoire quelle gure dans le message. Son absence entraine une incapacit e de traitement du message, par le serveur ou par le client. D Le corps du message. Il est omis dans certains cas, comme une requ ete avec la m ethode GET ou une r eponse ` a une requ ete avec la m ethode 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 e ` a celui annonc e dans len-t ete, plus pr ecisement dans le champ Content-Type. Par exemple : Content-Type : text/html = Le corps du message contient des octets ` a interpr eter comme ceux dune page ecrite en HTML. Content-Type : image/jpg = Le corps du message contient des octets ` a interpr eter comme ceux dune image au format jpeg

154

Anatomie dun serveur Web

URIs et URLs

Le succ` es du web sappuie largement sur un syst` eme de nommage des objets accessibles, qui en uniformise lacc` es, quils appartiennent ` a la machine sur laquelle on travaille ou distants sur une machine en un point quelconque du r eseau (mais suppos e accessible). Ce syst` eme de nommage universel est lurl (Uniform Resource Locator RFC 1738) d eriv e dun syst` eme de nommage plus g en eral nomm e uri (Universal Resource Identier RFC 1630). La syntaxe g en erale dun(e) url est de la forme : <scheme> :<scheme-specic-part> Succintement la scheme est une m ethode que lon s epare ` a laide du caract` ere : dune cha ne de caract` eres ascii 7 bits dont la structure est essentiellement fonction de la scheme qui pr ec` ede et que lon peut imaginer comme un argument. Une scheme est une s equence de caract` eres 7bits. Les lettres a ` a z, les chires de 0 ` a 9, le signe +, le . et le - sont admis. Majuscules et minuscules sont indi erenci es. Exemples de schemes : http, ftp, le, mailto, . . .Il en existe dautres (cf la RFC) non indispensables pour la compr ehension de cet expos e. 8 Globalement une url doit etre encod ee en ascii 7 bits sans caract` ere de contr ole (cest ` a dire entre les caract` eres 20 et 7F), ce qui a comme cons equence que tous les autres caract` eres doivent etre encod es. La m ethode dencodage transforme tout caract` ere non utilisable directement en un triplet form e du caract` ere % et de deux caract` eres qui en repr esente la valeur hexad ecimale. Par exemple lespace (20 hex) doit etre cod e %20. Un certain nombre de caract` eres, bien que th eoriquement repr esentables, sont consid er es comme non s urs (unsafe) et devraient etre egalement encod es de la m eme mani` ere que ci-dessus, ce sont : % < > " # { } | \ ^ ~ [ ] Pour un certain nombre de schemes (http. . .) certains caract` eres sont r eserv es car ils ont une signication particuli` ere. Ce sont : ; / ? : @ = & Ainsi, sils apparaissent dans lurl sans faire partie de sa syntaxe, ils doivent etre encod es.

2.1
8

Scheme http

Une url avec la scheme http bien form ee doit etre de la forme :
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 num ero de port. Sil nest pas pr ecis e, la valeur 80 est prise par d efaut. path Cest un s electeur au sens du protocole http. searchpath Cest ce que lon appelle la query string, autrement dit la cha ne dinterrogation. ` lint A erieur de ces deux composantes, les caract` eres / ; ? sont r eserv es, ce qui signie que sils doivent etre employ es, ils doivent etre encod es pour eviter les ambigu t es. ` Le ? marque la limite entre lobjet interrogeable et la query string. A lint erieur de cette cha ne dinterrogation le caract` ere + est admis comme raccourci pour lespace (ascii 20 hex). Il doit donc etre encod e sil doit etre utilis e en tant que tel. De m eme, ` a lint erieur de la query string le caract` ere = marque la s eparation entre variable et valeur, le & marque la s eparation entre les couples variable = valeur. Exemple r ecapitulatif :
http ://www.google.fr/search ?q=cours+r%E9seaux&hl=fr&start=10&sa=N

155

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

156

Anatomie dun serveur Web

Architecture interne du serveur Apache

Cette partie se consacre ` a l etude du fonctionnement du serveur Apache9 . Pour comprendre les m ecanismes internes dun tel serveur il est absolument n ecessaire de pouvoir en lire le code source, cette contrainte exclu les produits commerciaux. Au mois de mars 2002, dapr` es le Netcraft Web Server Survey10 le serveur le plus utilis e (55%) est tr` es majoritairement celui du projet Apache. Dapr` es ses auteurs, le serveur Apache est une solution de continuit e au serveur du NCSA11 . Il corrige des bugs et ajoute de nombreuses fonctionnalit es, particul` erement un m ecanisme dAPI pour permettre aux administrateurs de sites de d evelopper de nouveaux modules adapt es ` a leurs besoins propres. Plus g en eralement, tout ce qui nest pas strictement dans les attributions du serveur (gestion des processus, gestion m emoire, gestion du r eseau) est trait e comme un module dextension. Le chier apache 1.3.23/htdocs/manual/misc/API.html de la distribution standard apporte des pr ecisions, le serveur http ://www.apacheweek.com/ pointe egalement sur grand nombre de documents tr` es utiles. Le serveur Apache introduit egalement la possibilit e de serveurs multidomaines (domaines virtuels), ce qui est fort appr eci e des h ebergeurs de sites.

3.1

Environnement dutilisation

La gure 2 qui suit, synth etise lenvironnement dutilisation.


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 egalement une source int eressante dinformations 10 http ://www.netcraft.com/survey/ 11 National Center for Supercomputing Applications Universit e de lIllinois, aux Etats Unis

Architecture interne du serveur Apache Le serveur se met en uvre simplement. La compilation fournit un ex ecutable, httpd, qui, pour sex ecuter correctement, a besoin des trois chiers ASCII de conguration : srm.conf, access.conf, httpd.conf. Cest en fait dans celui-ci que sont eectu es lessentiel des ajustements locaux ` a la conguration standard. Lors de lex ecution, trois chiers sont modi es12 : 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-d emarrage ` a chaud du serveur, ou avec SIGTERM pour mettre n ` a son activit e. access log (CustomLog) Qui contient le d etail des acc` es clients. Ce chier peut devenir tr` es volumineux. error log (ErrorLog) Qui contient le d etail des acc` es infructueux et des eventuels probl` emes de fonctionnement du serveur. Le daemon httpd est soit du type (ServerType) standalone ou si son invocation est occasionnelle, ` a la demande pilot e par inetd (cf page 4). Il d emarre son activit e par ouvrir le port (Port) d esign e dans la conguration, puis sex ecute avec les droits de lutilisateur User et du groupe Group. Sa conguration se trouve dans le r epertoire conf sous-r epertoire de ServerRoot. Les chiers accessibles par les connexions clientes, eux, se situent dans le r epertoire DocumentRoot qui en est la racine, cest ` a dire vue comme / par les browsers clients. Le chier httpd.pid contient un num ero de processus leader de groupe car en fait le serveur Apache, d` es son initialisation, d emarre un certain nombre de processus, autant de serveurs capables de comprendre les requ etes 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 cr e ees. 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 supprim ees. Cest le nombre minimum dinstances du serveur (non compris le processus ma tre) au d emarrage. Cest le nombre maximum de clients (requ etes HTTP) simultan es. Cette constante peut etre augment ee en fonction de la puissance de la machine.

157

Un processus joue le r ole de r egulateur, du point de vue Unix cest un processus chef de groupe (leader). La commande ps permet de visualiser une situation op erationnelle :
Entre parenth` eses le nom de la variable du le chier httpd.conf qui permet den 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 e de reconnaitre (2794) car il est le p` ere des autres processus (ce qui nimplique pas 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 ` a l ecoute du r eseau. Cest une situation qui peut sembler paradoxale eu egard au nombre de processus ci-dessus, le code nous fournira une explication au paragraphe suivant. La commande tail -1 logs/access.log fournit la trace de la derni` ere requ ete :
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 d ebut de ce 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 e, les num eros de lignes sont devenus de fait compl` etement faux.

Ce qui nous int eresse plus particuli` erement pour expliquer le fonctionnement du serveur se trouve dans le r epertoire src/, sous r epertoire du r epertoire principal de la distribution :
$ 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 r epertoire qui compte au moins 75 chier (wc -l *.[ch] 27441 lignes) nous nous restreignons aux chiers essentiels d ecrits dans le 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` ere et ses ls. Puis, dans un autre paragraphe, nous examinerons plus particuli` erement ce qui se passe lors dune connexion, avec le cas particulier de lex ecution 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 e seul d esigne ce type 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 int eressant m ecanisme de buers cha n es, utilis e tout au long du code d` es lors quil y a besoin dallouer de la m emoire. ... 1523 ... setup_prelinked_modules();

Les di erents modules du serveurs sont ajout es dans une liste cha n ee. 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 ` a 0 si le serveur est invoqu e depuis inetd 14 . Son mode de fonctionnement le plus ecace reste avec ce param` etre ` a 1 (voir le cours sur inetd), que nous supposons ici. La fonction standalone main (ligne 1362) pr epare le processus ` a son futur r ole de serveur. Pour bien comprendre le cette fonction, il faut imaginer quelle est invoqu ee au d emarrage, et ` a chaud, pour lire et relire la conguration. Ligne 1369 , la variable one process = 0 (sinon le processus est en mode debug) occasionne lappel ` a la fonction detach (ligne 876). Celle-ci transforme le processus en leader de groupe avec la succession bien connue fork + setsid (pour plus de d etails, voir le cours sur les daemons). Ligne 1374 , la fonction sigsetjmp enregistre la position de la pile et l etat du masque dinterruption (deuxi` eme argument non nul) dans erieur ` a siglongjmp forcera la reprise restart buffer. Tout appel ult de lex ecution en cette ligne. 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 ` a tous les processus du groupe. Cette disposition nest utile que dans le cas dun re-d emarrage ` a chaud. La variable pgrp est initialis ee par la fonction detach (ligne 876), elle contient le PID du chef de groupe. Lint eret davoir un groupe de processus est que le signal envoy e` a son leader est automatiquement envoy e` a tous les processus y appartenant. Chaque processus qui re coit ce signal, sil est en mesure de le traiter, ecute un exit(0) (ligne 943). Donc appelle la fonction just die qui ex tous les ls meurent, sauf le chef de groupe. Ligne 1390 , lappel ` a la fonction reclaim child processes() eectue autant de wait quil y avait de processus ls, pour eviter les zombis. 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 et e modi es.
Cette alternative est d ecid ee dans le chier httpd.conf, conguration du param` etre ServerType
14

Architecture interne du serveur Apache Ligne 1401 accept mutex init (ligne 166) fabrique un chier temporaire (/usr/tmp/htlock.XXXXXX), louvre, r eduit son nombre de lien ` a 0, de telle sorte quil sera supprim e d` es la n du processus. Ce chier est le verrou dacc` es ` a la socket principale, comme nous lexaminerons un peu plus loin. Ligne 1402 reinit scoreboard (ligne 596) Cette fonction remet ` a z ero, ou cr ee (setup shared mem ligne 432) la zone de m emoire commune entre le chef de groupe et ses processus ls. Cette zone m emoire est, soit un segment de m emoire partag ee (IPC du syst` eme V), soit de la m emoire rendue commune par un appel ` a la primitive mmap (Le choix est eectu e par configure qui analyse les possibilit es du syst` eme, avant compilation du serveur). La taille de cette zone est de HARD SERVER LIMIT sizeof(short score) octets, la structure short score, d enie 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 tre contr ole les serveurs ls. HARD SERVER LIMIT d enit le nombre maximum de connexions actives, donc dinstances de serveur, ` a un instant donn e. En standard cette valeur est 150, elle peut etre augment ee dans le chier de conguration httpd.conf (voir ci-dessus au paragraphe II.1) Enn la gure 4 montre son r ole strat egique. Ligne 1413 (on suppose listeners = NULL), apr` es avoir initialis e une structure dadresse, appel ` a la fonction make sock (ligne 1298). Celleci cr ee et initialise une socket, et, d etail important, appelle par deux fois setsockopt, ce qui m erite un commentaire : ... 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` egle dexclusivit e suivie par bind(2) pour lattribution dun port ne sapplique plus : un processus peut se servir dun m eme port pour plusieurs usages di erents (comme par exemple le client ftp qui attaque les port 21 et 20 du serveur avec le m eme port local), voire m eme des processus di erents (cest le cas ici) peuvent faire un bind avec le m eme port sans rencontrer 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 e au paragraphe II.1 (netstat) sans lexpliquer, voila qui est fait !

162

Anatomie dun serveur Web SO KEEPALIVE Indique ` a la couche de transport, ici TCP, quelle doit emettre ` a interval r egulier (non congurable) un message ` a destination de la socket distante. Que celle-ci ny r eponde pas et la prochaine tentative d ecriture sur la socket se solde par la r eception 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) pr evoit le comportement lors de la r eception des signaux : SIGHUP SIGTERM Appel de restart Appel de sig term

Ligne 1438 et la suivante, cr eation dautant de processus ls quil en est demand e dans le chier de conguration (StartServers). La fonction make child (1275) appelle fork, puis dans le ls modie le comportement face aux signaux SIGHUP et SIGTERM (just die appelle exit) avant dex ecuter child main.
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 Arriv es ` a ce stade, il nous faut analyser lattitude des deux types de processus. Le processus ma tre Ligne 1444 d emarre une boucle innie de surveillance. Seule la r eception et le traitement dun signal peut linterrompre.

Architecture interne du serveur Apache Ligne 1458 Ici, si le nombre de serveurs disponibles est inf erieur au nombre minimal requis, il y reg en eration de ceux qui manquent avec la fonction make child

163

Les processus esclaves Ligne 1139 La gestion de ces processus, autant de serveurs Web op erationnels, d ebute avec lappel de la fonction child main. Ligne 1167 D ebut de la boucle innie qui g` ere cette instance du serveur. Au cours dune boucle le serveur g` ere lacceptation dune requ ete et son traitement. Ligne 1174 Gestion du SIGPIPE donc des clients qui d econnectent avant lheure ! Ligne 1180 Si le nombre de serveurs libres (count idle servers) est sup erieur ` a la limite congur ee, ou si Ligne 1182 le nombre de requ etes trait ees par ce processus a atteint la limite max requests per child, le processus sarr ete de lui-m eme. Cest lauto-r egulation pour lib erer des ressources occup ees par un trop grand nombre de processus serveurs inutiles. Ligne 1190 Lappel ` a la fonction accept mutex on v erouille lacc` es ` a la ressource d enie pr ec edement avec accept mutex init (ligne 166). Ce v erouillage est bloquant et exclusif. Cest ` a dire quil faut quun autre processus en d ev erouille lacc` es pour que le premier processus sur la liste dattente (g er ee par le noyau Unix) y acc` ede. Ce fonctionnement est assur e suivant la version dUnix par la primitive flock ou par la primitive fcntl. Les s emaphore du Syst` eme V (semget, semctl, semop. . .) assurent la m eme fonctionnalit e, en plus complet, ils sont aussi plus complexes ` a mettre en uvre. Cette op eration est ` a rapprocher de loption SO REUSEADDR prise ligne 1312. Il faut eviter que plusieurs processus serveurs disponibles ne r epondent ` a la requ ete. Il ny a quun seul processus pr et ` a r epondre ` a la fois et d` es que le accept (ligne 1217) retourne dans le code utilisateur la ressource est d ev erouill ee (on suppose toujours listeners = 0). Ligne 1221 La fonction accept mutex off d ev erouille lacc` es ` a la socket. Ligne 1245 read request lit la requ ete du client, donc un message HTTP. Ligne 1247 process request fabrique la r eponse au client, donc un autre 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 requ etes Le chier concern e par la lecture de la requ ete est http protocol.c. La lecture de la premi` ere ligne du message HTTP est assur ee par la 15 fonction read request line, ligne 329 . La lecture de len-t ete MIME est assur ee par la fonction get mime headers, ligne 356. Attention, seule len-t ete lue le corps du message dans le cas de a m ethode POST est lu plus tard, lors du traitement du message, par le programme dapplication (CGI). Le chier concern e par la formulation de la r eponse est http request.c et la fonction principale process request, ligne 772. Celle-ci appelle en cascade process request internal, ligne 684. Cette derni` ere eectue un certain nombre de tests avant de traiter eectivement la requ ete. Parmi ceux-ci on peut relever, Ligne 716 La fonction unescape url (util.c, ligne 593) assure le d ecodage des caract` eres r eserv es et transcod es comme il est sp eci e par la RFC 1738. Ligne 723 La fonction getparents ltre les chemins (pathname) qui pr etent ` a confusion. Ligne 768 La fonction invoke handler est le point dentr ee dans le traitement de la requ ete. Cette fonction (http config.c, ligne 267) invoque le programme (module) qui se charge de fabriquer la r eponse, au vue ete. Si celui est inexisdu contenu du champ content type de la requ tant, comme dans notre exemple du paragraphe I, il est positionn e par d efaut ` a la valeur html/text.
15

La m ethode, lURL, et le protocole demand e

Architecture interne du serveur Apache Deux types de CGIs Pour la suite nous supposons que la prise en main de la requ ete est ee faite par le module cgi, d eni dans le chier mod cgi.c. Le point dentr est la fonction cgi handler (ligne 207), cest ` a dire celle qui appell ee par invoke handler, vue au paragraphe ci-dessus. La lecture du code permet de d eduire quil y a deux types de CGI, la distinction est faite parle nom de la cgi elle-m eme. La gure 5 r esume les 2 situations possibles dex ecution dune CGI.
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 lex ecutable commence par nph-16 le comportement du serveur http change. Dans le cas ordinaire (nom quelconque) les donn ees transmises depuis le client vers la cgi et r eciproquement, passent par le processus httpd et via un tube non nomm e (pipe). Dans le cas dune cgi nph, seules les donn ees lues depuis le client (par exemple avec la m ethode POST) transitent par le processus httpd, la r eponse, elle, est emise directement, ce qui am eliore les performances en evitant une s equence lecture/ ecriture inutile. Ce comportement est justi e d` es que de gros volumes doctets sont ` a transmettre au client (de grandes pages HTML, des images. . .). Attention, dans ce dernier cas, cest ` a la CGI de fabriquer lint egralit e du message HTTP, y compris len-t ete MIME. A elle egalement de g erer la d econnexion pr ematur ee du client (SIGPIPE). Ces deux modes de fonctionnement ne sont pas clairement document es, en fait il sagit dune caract eristique du serveur du CERN, maintenue pour assurer sans doute la compatibilit e avec les applicatifs d ej` a ecrits. Il nest pas assur e que cette possibilit e existera dans les futures versions du serveur
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 ` a fabriquer lenvironnement dex ecution de la cgi Cette fonction (chier util script.c, ligne 126) compl` ete les variables qui ne d ependent pas du contenu de la requ ete, par exemple SERVER SOFTWARE, 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 cr eation dun processus ls, celui qui nalement va ex ecuter la cgi. Il faut remarquer le deuxi` eme argument qui est un pointeur de fonction (cgi child), et le sixi` eme qui est nul dans le cas dune cgi du type nph. ee et sorscript in et script out sont respectivement les canaux dentr tie des donn ees depuis et vers le processus qui ex ecute la cgi. Il parait donc logique que dans le cas dune cgi de type nph script in soit nul. Un m ecanisme non encore analys e duplique la sortie de ce processus vers le client plut ot que vers le processus serveur. Nous continuons la description du point de vue du processus p` ere, donc httpd. Ligne 295 et les suivantes, jusqu` a la ligne 332, le processus lit ce que le client lui envoie, si la m ethode choisie est du type POST. Le contenu est renvoy e vers le processus ls, sans transformation :

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 ` a celui-ci dexploiter ce quenvoie le client, par exemple le r esultat dune forme de saisie. 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 renvoy ee au client (ligne 374). Examinons maintenant comment se pr epare et sex ecute le processus ls : 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` eres lignes pr eparent lenvironnement du futur processus 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 ` a lenvironnement. Cette derni` ere variable joue un r ole majeur dans la transmission des arguments ` a la cgi quand la m ethode choisie est GET. En eet, dans ce cas, le seul moyen pour le client denvoyer des arguments ` a la cgi est dutiliser lURL, comme par exemple dans :
http ://monweb.chez.moi/cgi-bin/nph-qtp ?base=datas&mot=acacia&champ=.MC

La syntaxe de lURL pr evoit le caract` ere ? comme s eparateur entre le nom et ses arguments. Chaque argument est ensuite ecrit sous la forme : nom = valeur Les arguments sont s epar es les uns des autres par le caract` ere &.

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 redirig ee vers le chier error log, et ligne 138, la sortie standard du processus, cest la socket, donc envoy ee directement 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 ex ecute la cgi ! Bien s ur, si le programme va au del` 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 M ethode GET, sans argument

Dans ce paragraphe nous examinons ce qui se passe lors de lex ecution dune CGI tr` es simple (shell script, le source suit) que lon suppose plac ee dans le r epertoire idoine, pour etre ex ecut ee comme lors de la requ ete suivante :
$ 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 requ ete tap ee par lutilisateur. Len-t ete du message HTTP renvoy e par le serveur. La ligne de statut est g en er ee par la cgi car il 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 g en er es dynamiquement par 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 lent ete MIME, r eduite mais susante. Le echo seul g en` ere une 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 g en er e par le moREMOTE_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 M ethode GET, avec arguments

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

Premi` ere version : #!/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` es facilement sur les sites ftp le source dun outil nomm e cgiparse17 , parfaitement adapt e` a lanalyse de la cha ne transmise. Do` u la deuxi` eme version :
#!/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` a, la fabrication du message renvoy e. La cgi renvoie ses octets via un tube au serveur, cest donc celui-ci qui se charge de fabriquer un en-t ete MIME.

Puis le r esultat de lex ecution : BASE=datas MOT=acacia CHAMP=.MC

4.3

CGI M ethode POST

La m ethode POST autorise un client ` a envoyer au serveur une liste de couples variable=valeur. Chaque couple est s epar e des autres par une n de ligne, cest ` a dire (CR,LF). Cette m ethode est bien adapt ee ` a la transmission dinformations collect ees cot e client dans une forme18 de saisie, et dont le volume est variable. La liste des couples est ecrite dans le corps du message, par le programme client, et ne fait pas partie de lURL, comme cest le cas pour la m ethode GET. Il y a evidement une limite au nombre maximum doctets envoy e par 19 le client, cest le serveur qui en xe la valeur . Du cot e du client, il faut pr evenir le serveur, dans len-t ete du message HTTP, de la taille du corps du 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` eres si on compte la n de ligne (CR+LF).

La r eponse du serveur liste les couples lus, ici un seul ! La variable globale REQUEST METHOD pourrait etre utilis ee pour adapter le comportement de la cgi en fonction de la m ethode demand ee.

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

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 etre constamment ` a laut de la nouveaut e dans ce domaine tr` es r eactif quest celui du World Wide Web. Les quelques r ef erences bibliographique qui suivent illustrent ce cours, mais il est evident quelles sont bien insusantes pour couvrir tous les aspects 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 ements de r El eseaux


1 H otes ou services virtuels
HTTP

ipA

ipB ipWWW

ipC Traffic HTTP

ipD

gure X.01 : Serveur HTTP virtuel

La machine B (dadresse IP xe ipB) h eberge par exemple le service HTTP dadresse ip ipWWW. Cette op eration est rendue possible si le syst` eme dexploitation de B autorise la notion dalias IP. Si les machines A, C et D ex ecutent egalement un serveur HTTP, elles peuvent potentiellement prendre le relais de la machine B, d` es lors que ladresse ipWWW aura et e retir ee de la machine B pour etre recongur ee sur lune dentres elles. Cette op eration peut se faire manuellement ou via un outil dadministration. Elle permet de faire transiter tr` es rapidement des services dune machine ` a une autre, sans rupture ou presque de la continuit e. Vu des clients il sagit toujours de la m eme machine, mais elle est virtuelle puisquelle nexiste pas physiquement. Section en chantier, pr ecisions en cours. . .

176

ements de r El eseaux

Tunnel IP
A Encapsulation dIP dans IP

gure X.02 : Tunnel IP - Principe Le tunnel permet dencapsuler un protocole dans un autre de m eme niveau ou sup erieur. Pr ec edemment, page 28, nous avons d ej` a analys e lencapsulation des couches de la pile Arpa selon une progression naturelle de fonctionnalit es. Ici, si le principe dencapsulation est conserv e, la logique initiale de construction, elle, est bouscul ee. Par exemple on peut envisager dencapsuler IP dans de multiple protocole autres quEthernet, comme PPP1 , IP, dans une couche de transport comme TCP, voire m eme dans une couche applicative comme HTTP. Ce dernier exemple peut para tre contre nature et pourtant cela fonctionne. . . Construire un tunnel a un co ut : dune part celui de la perte despace de donn ees dans le datagramme (il faut loger un ou plusieurs en-t etes suppl ementaires et le MTU reste constant lui !) et dautre part celui du traitement suppl ementaire (d ecapsulation, analyse) engendr e par lajout de ces nouveaux en-t etes. En r esum e, construire un tunnel se traduit par une perte despace pour les donn ees dans les datagrammes et par une consommation accrue de cycles cpus pour traiter les en-t etes suppl ementaires. Heureusement le gain en fonctionnalit es pour le r eseau est substanciel, comme les exemples qui vont suivre lillustrent ! Les tunnels qui transitent par une couche de transport sont g er es par 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 etre mis en uvre par un utilisateur nayant pas n ecessairement les droits de ladministrateur2 , mais par contre, outre une consommation suppl ementaire de cycles cpu et des changements de contexte inh erents ` a larchitecture logicielle3 , a linconv enient d etre d edi e` a un seul
Point to Point Protocol , lui -m eme eventuellement encapsul e dans de lEthernet (PPPoE RFC 2516) ou de lATM (PPPoA pour lADSL, RFC 2364) 2 Pour encapsuler IP dans IP par exemple, il faut pouvoir ecrire directement dans IP ce qui n ecessite une socket en mode raw et donc un uid 0 ` a lex ecution 3 Rappelons que les processus applicatifs standards sex ecutent en mode utilisateur, et que les transferts entre la couche de transport (dans le noyau) et la couche applicative seectuent via un jeu de primitives du syst` eme, voir la description des sockets de Berkeley page 199
1

Tunnel IP avec linterface gif port (par exemple celui dune application non crypt ee comme pop au travers 4 une liaison ssh) . Encapsuler IP dans IP a lavantage de rester g en eraliste du point de vue des applications. Sur la gure ci-dessus le tunnel IP encapsule donc de lIP dans lui m eme. Pour les routeurs qui acheminent ce trac il sagit de 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 gr ace ` a lusage du 5 generic tunnel interface . Il sagit dun pseudo-device (pas dinterface r eel associ e, comme cela pourrait etre le cas avec une carte r eseau) tr` es g en eraliste, qui permet dencapsuler de lIP (version 4 ou 6) dans de lIP (version 4 ou 6)6 . Le but de cet exemple de tunnel est de montrer un routage de datagrammes issus dun r eseau non ociellement rout e, le 192.168.2.0/24 (RFC 1918), depuis la machine B (IPB ), vers la machine A (IPA ) et au travers dun r eseau rout e quelconque. Par hypoth` ese la machine A sait comment router vers le 192.168.2.0/24. Le r eseau 192.168.249.0/30 (RFC 1918) sert de r eseau dinterconnexion entre les deux machines. Concr` etement, il sagit dattribuer une adresse IP ` a chacun des pseudo-devices, qui ne soit pas d ej` a dans lun des r eseaux attach es ` a chacune des machines. Conceptuellement, il serait parfaitement possible dutiliser, par exemple, des adresses dans le 192.168.2.0/24. Lauteur pr ef` ere lusage dun r eseau dinterconnexion qui permet de bien s eparer ce qui concerne le tunnel de ce qui utilise le tunnel. De 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 e pour la conception des r` egles de ltrage de consid erer lorigine des datagrammes ayant une adresse source dans le 192.168.2.0/24 uniquement derri` ere le ltre. Examinons maintenant quelle pourrait etre la conguration sp ecique ` 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 recommand ee par lauteur de ces pages et laiss ee ` a la compl` ete responsabilit e du lecteur 5 man gif sous FreeBSD, NetBSD ou OpenBSD 6 Nous avons d ej` a rencontr e un tel interface virtuel avec linterface de loopback lo0 page 70
4

178 Puis sur la machine B :

ements de r El eseaux

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 concr et Notez que la premi` ere ligne de conguration pr ecise la source et la destination r eelle des datagrammes alors que la deuxi` eme indique ladresse locale et distante des extr emit es du tunnel. Cest une ecriture particuli` ere, adapt ee au pilote de linterface gif0 pour la conguration des tunnels. Sur la machine B, on peut voir le r esultat de la conguration comme ca :
$ 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 e depuis A vers 192.168.2.200, on rel` eve les en-t etes IP du tableau qui suit. Ainsi lobservation pratique rejoint la th eorie : on retrouve bien sur le linterface du tunnel (gif0) len-t ete 2, d ecapsul e de son en-t ete 1. Le datagramme est alors disponible au niveau de la pile IP de B pour etre rout 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-t ete 1 Src IPA Dst IPB Code ipencap(4) En-t ete 2 192.168.249.1 192.168.2.200 icmp

179

Sur linterface if0

Sur linterface gif0

En-t ete Src 192.168.249.1 Dst 192.168.2.200 Code icmp

Remarques : Attention, les routeurs ltrants doivent etre sp ecialement congur es pour 9 laisser passer ce type de trac . Les core gateway le laisse passer sans probl` eme. Il est int eressant de noter que le d eploiement dIPv6 est dabord bas e sur 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 n ecessaire de pr eciser que m eme encapsul es dans IP, nos datagrammes nen sont pas moins lisibles par des yeux indiscr ets ? Pour sen pr emunir il nous faut examiner une technologie compl etementaire. . .Dans le paragraphe suivant !

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

180

ements de r El eseaux

2.2

IPsec et VPN

IPsec est un protocole de s ecurit e inclus dans la couche IP elle-m eme. Il est d eni dans la RFC 2401. Ce paragraphe aborde bri` evement la question du point de vue du protocole et de sa place dans la pile Arpa, tout en laissant volontairement dans un certain ou les aspects li es ` a la cryptographie, 10 clairement absents des objectifs de ce cours . IPsec dans quel but ? IPsec est un point de passage oblig e pour tout administrateur de r eseau qui souhaite mettre en place une politique de s ecurit e. Dailleurs, pour faire le lien avec le paragraphe qui pr ec` ede, pr ecisons quIPsec encapsul e dans IP (formellement, un tunnel) porte un nom, le VPN ( Virtual Private Network ) ! Nous avons examin e comment un tunnel accro t l etendue dun r eseau au travers dautres r eseaux. Ajouter Ipsec introduit, entre autres, une dimension de s ecurit e tr` es utilis ee pour relier des machines - ou des r eseaux - physiquement localis es nimporte o` u il y a un acc` es IP, en r eseaux virtuels s ecuris es ! Cest pour cette raison quIpsec est un artefact incontournable de la panoplie s ecuritaire sur les r eseaux. 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 indiscr ets et que quasiment nimporte quel bricoleur peut forger de faux datagrammes ( fake datagram ) pour empoisonner un r eseau, voire d etourner les services dune machine. Ainsi, tout ce qui renforce la s ecurit e IP est une bonne chose, surtout ` a lheure des r eseaux wi dont les limites de port ee ne sont pas ma trisables. IPsec renforce la s ecurit e dIP sur plusieurs points : Condentialit e Les donn ees dIP (protocole de transport et donn ees applicatives) sont crypt ees, donc normalement non inspectables avec tout outil danalyse de r eseau. Authentication La source du datagramme ne peut etre quun seul emetteur, et non un interm ediaire non pr evu. Int egrit e La totalit e des donn ees est prot eg ee par une somme de contr ole (checksum), travail normalement d evolu ` a la couche de transport mais qui au niveau dIP permet d ecarter tout datagramme qui aurait et e modi e pendant son transport. Dispositif anti-rejeux pour eviter les attaques du type man-in-themiddle consistants ` a capturer un ou plusieurs datagrammes (crypt es) dans le but de les envoyer ` a nouveau pour b en ecier du m eme eet produit que lenvoi initial.
Les RFCs donn ees page 195 sont le bon point de d epart pour se documenter sur les aspects cryptographiques dIPsec
10

IPsec et VPN IPsec en r esum e Ipsec (RFC 2401) est un assemblage de quatre protocoles : ESP ( Encapsulating Security Payload ) est d eni par la RFC 2406. Il assure la condentialit e par lusage dalgorithmes de cryptage comme 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 bas es sur lexistence un secret partag e (manuellement dans un chier ou cr ee dynamiquement avec IKE, voir plus bas) entre les parties qui echangent des messages, et non sur l echange dune clef publique. Cette remarque a un impact sur la mani` ere avec laquelle on doit les congurer ! AH ( Authentication Header ) est d eni par la RFC 2402. Il assure lauthentication, cest ` a dire quil cherche ` a certier que les deux couches IP qui dialoguent sont bien celles quelles pr etendent etre, puis lint egrit e des donn ees par le calcul dun checksum. Il faut noter que ce dernier travail empi` ete largement sur les attributions de la couche de transport mais se justie compte-tenu des exigences inh erentes au fonctionnement dIPsec. IPcomp ( IP payload compression ) sert ` a compresser les donn ees avant de les crypter. Son action est rendue n ecessaire pour tenter de compenser la perte de la place occup ee par les en-t etes ajout es. Bien entendu IPcomp peut etre utilis e seul. IKE ( Internet Key Exchange ) est d eni par la RFC 2409. Ce protocole nest pas formellement indispensable au bon fonctionnement dIPsec mais lui apporte un m ecanisme d echange de clefs, au d emarrage des echanges et au cours du temps. Ainsi la clef de chirement nest plus d enie de mani` ere statique dans un chier mais change continuellement au cours du temps, ce qui est meilleur du point de vue de la s ecurit e. Du point de vue de ladministration syst` eme et r eseau, la mise en place 11 de ce protocole passe par lusage dun daemon , par exemple racoon, et par une ouverture de port UDP (isakmp/500) suppl ementaire dans le ltrage du r eseau. Une n egociation d ecrite dans la RFC 2409 se d eroule entre les h otes qui doivent dialoguer, ce qui entraine une certaine latence au d ebut des echanges. Les 32 bits de ladresse IP de destination12 permettent th eoriquement dexprimer un adressage de type unicast ou multicast ou broadcast. Si ces cas de gures sont tous th eoriquement possibles, les impl ementations dIPsec ne supportent que lunicast. La cons equence est importante sur le d eploiement dIPsec, il est eectu e point ` a point plut ot que g en eralis e pour tout un r eseau.
11 12

181

Voir page 250 pour le fonctionnement des daemons R evision possible page 33

182 Ce travail est inclus dans ce qui est nomm e politique de s ecurit e dans la RFC 2401. Pour AH comme pour ESP, lajout de donn ees vient se placer entre len-t ete IP et les donn ees. Les deux protocoles peuvent etre utilis es ensembles ou s eparement, cest un choix qui rel` eve de la politique de s ecurit e. Pour en tenir compte, la n egociation qui a lieu lors de l etablissement dIPsec repose sur ce que la RFC appelle des SA ( Security Association ). Une SA est formellement un triplet unique constitu e dun index unique , le SPI

ements de r El eseaux

gure X.04 : En-t etes dIPsec


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 num ero didentication IP 13 suppl ementaire inclus dans len-t ete AH ou ESP, de ladresse IP du destinataire et du protocole ESP ou dAH. Si les deux protocoles doivent etre utilis es, il faut n egocier deux SAs. Comment utiliser IPsec ? Aux deux protocoles AH et ESP, sajoutent deux mani` eres dutiliser IPsec, soit directement dune machine ` a une autre, on parle alors de mode 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 impl ementation se r eclamant dIPsec doit supporter les 4 associations qui suivent. La s ecurit e entre deux h otes qui 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 simultan ement. Quand ils sont appliqu es tous les 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 s ecurit e entre les h otes terminaux ` a celle d ej` a apport ee par les routeurs. 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 ` a lintranet de son entreprise via un modem ou un acc` es IP non s ur, et qui utilise un protocole non crypt e comme AppleTalk, ou PoP, par exemple. Le mode tunnel est seul requis entre lh ote H1 et la passerelle G1. Ensuite, entre H1 et H2 on revient au premier cas.

184 Impl ementation dIPsec

ements de r El eseaux

Limpl ementation dIPsec sur les machines FreeBSD et NetBSd est issue du projet KAME14 et est ainsi fortement li e au d eveloppement de la pile 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 situ ee elle aussi dans le noyau, gr ace ` a des socket de type PF KEY Les clefs sont soit plac ees de mani` ere semi-d enitive dans le chier de conguration dipsec lui-m eme (par exemple /etc/ipsec.conf soit con ee aux bons soins dun programme externe qui se charge de les cr ee et de les propager ` a laide du protocole IKE. Quelques daemons savent faire cela, notamment racoon du projet KAME. Si nous reconsid erons la gure X.03 les machines A et B jouent le r ole des passerelles G1 et G2 de la gure X.06 (association 2). Les chiers de conguration IPsec pourraient etre : 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 d enir sa politique de s ecurit e, cest ` a dire ce que lon souhaite en entr ee (in), en sortie (out) puis un choix de protocole (esp, ah, ipcomp), un mode (tunnel ici) avec lentr ee et la sortie du tunnel, enn un niveau dusage (require ici indique que tous echanges doivent utiliser IPsec). 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, ` a laide de loutil racoon. 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 r eseau via une seule machine pour toute une vari et e de protocoles (telnet, http, smtp, . . .). Il existe des proxy sp ecialis es sur tel ou tel protocole, qui eectuent donc des t aches potentiellement tr` es complexes (par exemple squid pour http) ou tr` es g en eraux et donc moins performants sur chaque protocole (cf nat au paragraphe suivant). Tout le trac r eseau qui passe par un proxy sy arr ete pour en repartir. Les conditions de ce rebond peuvent etre param` etr ees par des r` egles dacc` es, ce qui en fait un el ement utile en s ecurit e des r eseaux (voir la RFC 1919). Section en chantier, pr ecisions en cours. . .

Translation dadresses

La p enurie dadresses IP est ` a lorigine du besoin de translation des adresses. Son principe se trouve d ecrit dans la RFC 1631. Le propos dun automate de translation dadresses est de convertir les adresses IP ` a la vol ee au passage dun interface. Dans une conguration classique un tel automate isole un r eseau comportant des adresses IP non ocielles (RFC 1918) dun autre comportant des adresses ocielles et donc potentiellement rout ees sur lInternet.
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` ese congur ee en routeur. On suppose egalement que pour la machine A cest le routeur par d efaut pour atteindre la machine B.

186 Pour la machine A

ements de r El eseaux

La machine A sadresse directement ` a la machine 193.104.112.163 en utilisant son routeur par d efaut. Lutilisateur de la machine A voit la connexion soit la forme : {tcp, IP H ote A, port A, IP H ote B, port B} 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 H ote B, port B, IP H ote NAT, port A} Pour la machine NAT La machine NAT a connaissance des 2 r eseaux, elle translate dynamiquement les adresses dans les deux sens. La machine NAT fait le travail dun proxy transparent puisque chaque connexion sy arr ete puis en repart sans conguration particuli` ere de la part de ladministrateur de A ou de B. La translation (ou IP masquerading) seectue dynamiquement selon ladresse demand ee. La translation dadresse seectue pour les datagrammes qui traversent linterface if ext. Le dialogue entre cette machine et les autres machines du r eseau priv e , via linterface if int ne fait pas lobjet dune translation dadresse. La situation de la machine A est plut ot celle dun poste client car non vu de lext erieur de son r eseau. Etre serveur est toutefois possible comme il lest expliqu e avec lusage de natd au paragraphe suivant. Les routeurs modernes ont la fonction de translation dadresses incluse dans leurs fonctionnalit es standards.

Translation dadresse

187

4.1

Cas de NATD

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

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 m ecanisme ad equat 16 redirige tout le trac entrant et sortant dun interface r eseau, vers un num ero de port convenu ` a la conguration, par exemple le port 6668, ` a ajouter dans /etc/services : natd 6668/divert # Network Address Translation socket Natd lit tous les datagrammes et ne retient pour traitements que ceux qui sont ` a destination du port d edi e. Compte tenu du chier de conguration, les adresses IP des datagrammes ainsi que les num eros de ports sont re ecrits et reinject es dans le noyau IP qui les traite comme dautres datagrammes (routage, ltrage. . .). Natd convertit les adresses IP ` a la vol ee, un datagramme entrant peut ainsi par jeux de re ecriture etre redirig e sur une toute autre machine, sans que son emetteur puisse le soup conner ! On distingue deux attitudes, soit tout le ux entrant est redirig e sur une seule machine, soit il est analys e plus nement et la redirection (r esultat de la re ecriture) est eectu ee en fonction du port, donc du service demand e. ` La litt erature appelle ce cas le static nat. A linsu des utilisateurs de la machine NAT du r eseau publique, tout le trac IP (cest ainsi quil faut comprendre ladresse IP 0.0.0.0) est renvoy e sur la machine S, et celle-ci nest pas visible du r eseau public.
Les impl ementation commerciales que lon trouve dans les routeurs, si elles ne se congurent pas de la m eme mani` ere, ont des propri et es tr` es voisines en fonctionnement 16 Par exemple pour FreeBSD il faut ajoute loption IPDIVERT dans la conguration du noyau
15

188
Hote accessible

ements de r El eseaux

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 etre : natd -interface if ext -redirect address IP(S) 0.0.0.0 La gure 13 nous montre un trac eclat e en fonction du service demand e, ce qui permet une gestion beaucoup ne des ressources du r eseau. Une demande de connexion de lh ote distant R sur la machine NAT et au port 80 va etre r eachemin ee vers la machine interne HTTP et sur le port que lon souhaite, par exemple 8080. M eme remarque pour les deux autres services pr esent es. La machine HTTP voit la connexion en provenance de la machine R sous sa forme exacte : {tcp, IP H ote R, Port R, IP H ote HTTP, 8080} La machine R ne voit que la partie publique de la connexion : {tcp, IP H ote R, Port R, IP H ote NAT, 80} 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` egles de ltrage ` a un ux de datagrammes IP an de prendre une d ecision qui est le plus souvent binaire : laisser passer ou ne pas laisser passer avec en option de conserver une trace de passage (des logs). Par son usage on cherche ` a prot eger un site ou une machine dun ux de datagrammes pour lesquels on suspecte que tous ne sont pas envoy es par des utilisateurs bienveillants. Le ltre seorce d eliminer le trac ind esirable ` a partir de consid erations ` a priori, mais il ne repr esente pas la panac ee en mati` ere de s ecurit e sur les r eseaux, autrement dit il ne faut pas penser quun ltre IP sut ` a r` egler tous les probl` emes de s ecurit e dun site ou dun h ote. En eet, ` a partir du moment o` u le ltre laisse passer certains datagrammes, m eme ` a priori innocents, une porte est ouverte au d etournement de lusage initial du service oert. Dans ces conditions il faut se rendre ` a 17 l evidence : il ny a pas de s ecurit e absolue sur le r eseau ! Dans la litt erature, un routeur ltrant est nomm e FireWall , quil faut traduire en pare-feux . Le ltrage IP est une caract eristique essentielle de tout routeur digne de 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 ` a toutes les bourses. . . Si les d etails de mise en uvre di` erent dune impl ementation ` a une autre, le fond du probl` eme reste le m eme. Limpl ementation choisie ici est ipfw, le ltre natif de FreeBSD18 . Il existe dautres ltre, notamment ipf, encore une fois le principe reste toujours le m eme.

5.1

Le cas dipfw de FreeBSD

Le ltre IP en question est impl ement e dans le noyau, il est activ e d` es lors que loptions IPFIREWALL est ajout ee dans le noyau. On peut egalement y adjoindre loption IPFIREWALL VERBOSE pour le rendre bavard19 , ce quappr ecient par dessus tout les administrateurs r eseaux, soucieux de tout conna tre sur la nature du trac. . . Le ltre est un module du noyau, charg e au d emarrage, et qui se param` etre ` a laide de la commande ipfw. Celle-ci est utilis ee dans les scripts de d emarrage pour dicter au noyau les r` egles de ltrage, lues dans un chier nomm e par defaut /etc/rc.firewall. les scripts de d emarrage pour dicter au noyau les r` egles de ltrage, Etablir des r` egles de ltrage IP sous-entend avoir une connaissance exhaustive de tous les el ements qui sy rattachent :
17 18

Les seuls r eseaux s urs sont isol es du monde ext erieur dans une cage de Faraday. . . http ://www.freebsd.org 19 Via syslogd

190

ements de r El eseaux Nom des interfaces r eseaux impliqu ees Protocoles r eseaux employ es (tcp, udp, icmp,. . .) Protocoles applicatifs autoris es (smtp, domain, http. . .) Adresses IP, num ero de ports, masque de sous-r eseaux Sens du trac par rapport aux interfaces ci-dessus Il est assez ais e de mettre en place un ltrage simple, par contre cette op eration peut devenir complexe d` es lors quon utilise des protocoles applicatifs compliqu es, mettant en jeux une strat egie dutilisation des ports et des adresses non triviale. Consid erons un site simple, comme celui de la gure X.14. La machine C acc` ede depuis lext erieur ` a la machine S, prot eg ee par le ltrage IP activ e sur la machine R, qui agit donc comme un routeur 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` egles du mod` ele de base, extraites du chier /etc/rc.firewall de la conguration standard dune machine FreeBSD r ecente (cest un script shell). Lexamen de ces r` egles nous permet de d ecouvrir la nature du trac autoris e ou non.

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 consid erations : Les r` egles sont parcourues de la premi` ere ` a la derni` ere, si aucune convient, laction par d efaut consiste ` a bloquer le trac (peut etre chang ee). D` es quune r` egle convient, elle est appliqu ee et le ltrage sarr ete. Le ltrage IP consomme des ressources cpu, donc pour am eliorer les performances il vaut mieux placer en t ete de liste les r` egles employ ees le plus couramment. Il faut remarquer que la machine 193.104.1.228 est visible depuis lext erieure et utilise une adresse ociellement rout ee.

192

ements de r El eseaux Une tentative dacc` es sur un service non autoris e se traduit par un message derreur (syslogd). Par exemple supposons que lutilisateur de la station C ex ecute la commande suivante : telnet 193.104.1.228 Il va obtenir le message :
telnet : Unable to connect to remote host : Connection timed out

Tandis que ladministrateur du r eseau 193.104.1.0 va constater la tentative dintrusion par le message :
ipfw : 3310 Deny TCP Adr.IP H^ ote C :2735 193.104.1.228 :23 in via ed0

Par contre, si lintrusion consiste ` a d etourner lusage du service SMTP, ladministrateur du r eseau 193.104.1.0 ne verra rien par ce biais puisque lacc` es SMTP est autoris e sur la machine 193.104.1.22820

Exemple complet

Dans cette partie nous examinons le cas de la conguration de la gure X.15, synth` ese des gures X.12, X.13 et X.14. Cest une conguration tr` es employ ee du fait de la distribution parcimonieuse dadresses IP par les fournisseurs dacc` es.
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` egles de ltrage.

20

Toute ressemblance avec la conguration r eelle de ce r eseau ne peut etre que fortuite

Exemple complet Commen cons par les r` egles de ltrage :

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 lh ote 193.104.1.228 nest plus visible de lext erieur, les services sont en apparence h eberg es par la machine R qui se charge de

194

ements de r El eseaux re-router les datagrammes en modiant dynamiquement ladresse de destination. Dans lordre des op erations, la translation dadresses est eectu ee avant le ltrage IP. Ce sont donc des adresses IP modi ees qui sont introduites dans les r` egles de ltrage ! 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` u lon sapper coit que la conguration na pratiquement pas chang e fondamentalement ormis par lintroduction de la r` egle : 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 d ej` a subit la translation dadresse avant d etre soumis au ltrage IP. Ainsi une demande de connexion sur le port 25 de la machine 193.104.1.1 sera transform ee en une demande de connexion sur le 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. Groot & E. Lear. February 1996. Moskowitz, D. Karrenberg, G. J.de (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` eme partie Programmation des sockets de Berkeley

Chapitre XI G en eralit es sur les sockets de Berkeley


1 G en eralit es

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

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 et e d evelopp ees en C. Les fonctionnalit es des sockets que nous allons d ecrire, sont celles apparues ` a partir de la version 4.3 de BSD Unix, en 1986. Il faut noter que les
Pour un historique tr` es int eressant de cette p eriode on pourra consulter 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 etude. Pour conforter ce point de vue il nest pas sans int er et dajouter que toutes les applications majeures (named, dhcpd, sendmail, ftpd, serveurs httpd,. . .) de lInternet, et dont lutilisateur peut lire le code source, sont programm ees avec de telles sockets. Enn, et avant dentrer dans le vif du sujet, le sch ema ci-dessous rappelle 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

Pr esentation des sockets

Les cr eateurs des sockets ont essay e au maximum de conserver la s emantique des primitives syst` emes dentr ees/sorties sur chiers comme open, read, write, et close. Cependant, les m ecanismes propres aux op erations sur les r eseaux les ont conduits ` a d evelopper des primitives compl ementaires. Quand un processus ouvre un chier (open), le syst` eme place un pointeur sur les structures internes de donn ees correspondantes dans la table des descripteurs ouverts de ce processus et renvoie lindice utilis e dans cette table. Par la suite, lutilisateur manipule ce chier uniquement par linterm ediaire de lindice, aussi nomm e descripteur de chier. Comme pour un chier, chaque socket active est identi ee par un petit entier appel e descripteur de socket. Unix place ce descripteur dans la m eme 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

Pr esentation des sockets Pour cr eer une socket, une application utilisera la primitive socket et non open, pour les raisons que nous allons examiner. En eet, il serait tr` es agr eable si cette interface avec le r eseau conservait la s emantique des primitives de gestion du syst` eme de chiers sous Unix, malheureusement les entr ees/sorties sur r eseau mettent en jeux plus de m ecanismes que les entr ees/sorties sur un syst` eme de chiers. Par exemple, il faut consid erer les points suivants : Dans une relation du type client-serveur les relations ne sont pas sym etriques. D emarrer une telle relation suppose que le programme sait quel r ole il doit jouer. Une connexion r eseau peut etre du type connect e ou non. Dans le premier cas, une fois la connexion etablie le processus emetteur discute uniquement avec le processus destinataire. Dans le cas dun mode non connect e, un m eme processus peut envoyer plusieurs data-grammes ` a plusieurs autres processus sur des machines di erentes. Une connexion est d enie par un quintuplet (cf cours TCP page 83) qui est beaucoup plus compliqu e quun simple nom de chier. Linterface r eseau supporte de multiples protocoles comme XNS, APPLETALK3 , la liste nest pas exhaustive. Un sous syst` eme de gestion de chiers sous Unix ne supporte quun seul format. En conclusion de ce paragraphe on peut dire que le terme socket d esigne, dune part un ensemble de primitives, on parle des sockets de Berkeley, et dautre part lextr emit e dun canal de communication (point de communication) par lequel un processus peut emettre ou recevoir des donn ees. Ce point de communication est repr esent e par une variable enti` ere, similaire ` 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 e` a une pr esentation des primitives de base pour programmer des applications en r eseaux. Pour etre bien complet il est fortement souhaitable de doubler sa lecture avec celle des pages de man correspondantes.

Cr eation dune socket


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

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

PF Sp ecie la famille de protocole (Protocol Family) ` a utiliser avec la socket. Sur tout syst` eme qui permet lusage des sockets, on doit trouver 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` es ` a la table de routage Acc` es ` a une table de clefs (IPsec)

Mais il existe dautres impl ementations notamment avec les protocoles : PF APPLETALK PF NS PF ISO PF SNA PF IPX ... : : : : : : Pour les r eseaux Apple Pour le protocole Xerox NS Pour le protocole de lOSI Pour le protocole SNA dIBM Protocole Internet de Novell ...

Le pr exe PF est la contraction de Protocol Family On peut egalement utiliser le pr exe AF, pour Address Family. Les deux nommages sont possibles ; l equivalence est d enie dans le chier dent ete socket.h. TYPE Cet argument sp ecie le type de communication d esir e. En fait avec la famille PF INET, le type permet de faire le choix entre un mode connect e, un mode non connect e ou une intervention directe dans la couche IP :

4 Cr eation dune socket 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 repr eciser que seules les sockets en mode connect e permettent les liaisons full-duplex. PROTOCOL Ce troisi` eme argument permet de sp ecier le protocole ` a utiliser. Il peut etre du type UDP ou TCP sous Unix. IPPROTO TCP IPPROTO UDP IPPROTO RAW, IPPROTO ICMP : TCP : UDP : uniquement avec SOCK RAW

PROTOCOL est typiquement mis ` a z ero car lassociation de la famille de protocole et du type de communication d enit explicitement le protocole 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 cr e ee par cet appel. Par rapport ` a la connexion future cette primitive ne fait que donner le premier el ement du quintuplet : {protocole, port local, adresse locale, port eloign e, adresse eloign ee } Si la primitive renvoie -1, la variable globale errno donne lindice du message derreur idoine dans la table sys errlist, que la biblioth` eque standard sait parfaitement exploiter 4 . Remarque importante : Comme pour les entr ees/sorties sur chiers, un appel syst` eme fork duplique la table des descripteurs de chiers ouverts du processus p` ere dans le processus ls. Ainsi les descripteurs de sockets sont egalement transmis. Le bon usage du descripteur de socket partag e entre les deux processus incombe donc ` a la responsabilit e du programmeur. 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 ` a sinterrompre pour une raison quelconque, en interne la socket est ferm ee et si plus aucun processus na de descripteur ouvert sur elle, le noyau la supprime.
4

cf la page de manuel de perror(3)

204

Sockets de Berkeley

Sp ecication dune adresse

Il faut remarquer quune socket est cr e ee sans adresse de l emetteur ni celle du destinataire. Pour les protocoles de lInternet cela signie que la cr eation dune socket est ind ependante dun num ero de port. Dans beaucoup dapplications, surtout des clients, on a pas besoin de sinqui eter du num ero de port, le protocole sous-jacent soccupe de choisir un num ero de port pour lapplication. Cependant un serveur qui fonctionne suivant un num ero de port bien connu doit etre capable de sp ecier un num ero de port bien pr ecis. Une fois que la socket est cr e ee, la primitive bind permet deectuer ce travail, cest ` a dire dassocier une adresse IP et un num ero de port ` a une socket :
int bind(int sockfd, struct sockaddr *myaddr, socklen t addrlen) ;

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

Pour la famille PF INET cette structure se nomme sockaddr in, elle est d enie de la fa con suivante :
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 ` a une adresse distante

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 num eros de port, par exemple si un num ero de port est d ej` a utilis e par un autre processus, ou si ladresse Internet est invalide. Il y a trois utilisations de la primitive : 1. En g en eral les serveurs ont des num eros de port bien connus du syst` eme (cf /etc/services. Bind dit au syst` eme cest mon adresse, tout message re cu ` a cette adresse doit m etre renvoy e. Que cela soit en mode connect e ou non, les serveurs ont besoin de le dire avant de pouvoir accepter les connexions. 2. Un client peut pr eciser sa propre adresse, en mode connect e ou non. 3. Un client en mode non connect e a besoin que le syst` eme lui assigne une adresse particuli` ere, ce qui autorise lusage des primitives read et write traditionnellement d edi ees au mode connect e. Bind retourne 0 si tout va bien, -1 si une erreur est intervenue. Dans ce cas la variable globale errno est positionn ee ` a la bonne valeur. Cet appel syst` eme compl` ete ladresse locale et le num ero de port du quintuplet qui qualie une connexion. Avec bind+socket on a la moiti e dune connexion, ` a savoir un protocole, un num ero de port et une adresse IP : {protocole, port local, adresse locale, port eloign e, adresse eloign ee }

Connexion ` a une adresse distante

Linitiative de la demande de connexion est typiquement la pr eoccupation dun processus client. Quand une socket est cr e ee, elle nest pas associ ee avec une quelconque destination. Cest la primitive connect qui permet d etablir la connexion, si le programmeur choisit un mode de fonctionnement connect e, sinon elle nest pas tr` es utile (voir plus loin).

206

Sockets de Berkeley Pour les protocoles orient es connexion, cet appel syst` eme rend la main au code utilisateur une fois que la liaison entre les deux syst` emes est etablie. Durant cette phase des messages sont echang es ; les deux syst` emes echangent des informations sur les caract eristiques de la liaison future (cf cours TCP page 83). Tant que cette liaison nest pas d enie au niveau de la couche de transport, la primitive connect ne rend pas la main. Dans le cas ou une impossibilit e se pr esente elle retourne -1 et positionne errno ` a la bonne valeur. Dans le cas ou tout va bien elle retourne 0. Les clients nont pas besoin de faire appel ` a la primitive bind avant dinvoquer connect car la connexion renseigne dun coup les el ements qui manquent. Dans le cas dun client en mode non connect e un appel ` a connect nest pas faux mais il ne sert ` a rien et redonne aussit ot la main au code utilisateur. Le seul int er et que lon peut voir est que ladresse du destinataire est x ee et que lon peut alors utiliser les primitives read, write, recv et send, traditionnellement r eserv ees au mode connect 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 e par la primitive socket. servaddr est une structure qui d enit ladresse du destinataire, la m eme structure que pour bind. addrlen Donne la longueur de ladresse, en octets. Le quintuplet est maintenant complet : {protocole, port local, adresse locale, port eloign e, adresse eloign ee}

Envoyer des donn ees

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

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

Envoyer des donn ees Tous les octets ne sont pas forc ement transmis dun seul coup, et ce nest pas une condition derreur. En cons equence il est absolument n ecessaire de tenir compte de la valeur de retour de cette primitive, n egative ou non. La primitive writev est sensiblement la m eme que write simplement elle permet denvoyer un tableau de structures du type iovec plutot quun simple buer, largument vectorlen sp ecie le nombre dentr ees dans iovector :
ssize t writev(int descriptor, const struct iovec *iovector, int vectorlen) ;

207

La primitive send ` a la forme suivante :


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

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

Les deux autres primitives, sendto et sendmsg donnent la possibilit e denvoyer un message via une socket en mode non connect e. Toutes deux r eclament que lon sp ecie le destinataire ` a chaque appel.
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 m emes que pour send, les deux derniers permettent de sp ecier une adresse et sa longueur avec une structure du type sockaddr, comme vu pr ec edemment avec bind. Le programmeur soucieux davoir un code plus lisible pourra utiliser la deuxi` eme primitive :
ssize t sendmsg(int sockfd, const struct msghdr *messagestruct,int flags) ;

O` u messagestruct d esigne une structure contenant le message ` a envoyer sa longueur, ladresse du destinataire et sa longueur. Cette primitive est tr` es commode ` a employer avec son pendant recvmsg car elle travaille avec la m eme structure.

208

Sockets de Berkeley

Recevoir des donn ees

Sym etriquement aux cinq primitives denvoi, il existe cinq primitives de r eception : read, readv, recv, recvfrom, recvmsg. La forme conventionnelle read dUnix nest possible quavec des sockets en mode connect e car son retour dans le code utilisateur ne saccompagne daucune pr ecision quant ` a ladresse de l emetteur. Sa forme dutilisation est :

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

Bien sur, si cette primitive est utilis ee avec les sockets BSD, le descripteur est lentier renvoy e par un appel pr ec edent ` a la primitive socket. buffer et longueur sp ecie respectivement le buer de lecture et la longueur de ce que lon accepte de lire. Chaque lecture ne renvoie pas forc ement le nombre doctets demand es, mais peut etre un nombre inf erieur. Mais le programmeur peut aussi employer le readv, avec la forme :
ssize t readv(int descripteur, const struct iovec *iov, int vectorlen) ;

Avec les m eme caract eristiques que pour le readv. En addition aux deux primitives conventionnelles, il y a trois primitives nouvelles pour lire des messages sur le r eseau :
ssize t recv(int s, void *buf, size t len, int flags) ;

s Lentier qui d esigne la socket. buf Une adresse o` u lon peut ecrire, en m emoire. len La longueur du buer. flags Permet au lecteur deectuer un contr ole sur les paquets lus.
ssize t recvfrom(int s, void *buf,size t len, int flags,struct sockaddr *from, socklen t *fromlen) ;

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

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

9 Sp ecier une le dattente

209

Sp ecier une le dattente

Imaginons un serveur en train de r epondre ` a un client, si une requ ete arrive dun autre client, le serveur etant occup e, la requ ete nest pas prise en compte, et le syst` eme refuse la connexion. La primitive listen est l` a pour permettre la mise en le dattente des demandes de connexions. Elle est g en eralement utilis ee apr` es les appels de socket et de bind et imm ediatement avant le accept.
int listen(int sockfd, int backlog) ;

sockfd lentier qui d ecrit la socket. backlog Le nombre de connexions possibles en attente (quelques dizaines). La valeur maximale est fonction du param` etrage du noyau. Sous FreeBSD la valeur maximale par d efaut est de 128 (sans param` etrage sp ecique du noyau), alors que sous Solaris 9, There is currently no backlog limit . Le nombre de fois o` u le noyau refuse une connexion est comptabilis e et accessible au niveau de la ligne de commande via le r esultat de lex ecution de la commande netstat -s -p tcp (chercher listen queue overow ). Ce param` etre est important ` a suivre dans le cas dun serveur tr` es sollicit e.

10

Accepter une connexion

Comme nous lavons vu un serveur utilise les primitives socket, bind et listen pour se pr eparer ` a recevoir les connexions. Il manque cependant ` a ce trio le moyen de dire au protocole jaccepte d esormais les connexions 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 e par la primitive du m eme nom. 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` eme cr ee une nouvelle socket dont il renvoie le descripteur, r ecup er e ici dans newsock. Ainsi la socket originale reste disponible pour d eventuelles autres connexions. Donc, quand une connexion arrive, lappel ` a la primitive accept retourne dans le code utilisateur.

11

Terminer une connexion

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

La primitive bien connue sous Unix peut etre aussi employ ee avec un descripteur de socket. Si cette derni` ere est en mode connect e, le syst` eme assure que tous les octets en attente de transmission seront eectivement transmis dans de bonnes conditions. Normalement cet appel retourne imm ediatement, 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 contr ole sur les connexions en full-duplex.
int shutdown(int sockfd, int how) ;

Sockfd est le descripteur ` a fermer, how permet de fermer partiellement le descripteur suivant les valeurs quil prend : 0 Aucune donn ee ne peut plus etre re cue par la socket. 1 Aucune donn ee ne peut plus etre emise. 2 Combinaison de 0 et de 1 ( equivalent de close). Enn, pour une socket en mode connect e, si un processus est interrompu de mani` ere inopin ee (r eception dun signal de n par exemple), un reset (voir page 86) est envoy e` a lh ote distant ce qui provoque la n brutale de la connexion. Les octets eventuellement en attente sont perdus.

12 Sch ema g en eral dune connexion

211

12

Sch ema g en eral dune connexion

Il est temps pour nous de donner un aper cu de la structure dun serveur et dun client, puisque cest ainsi que nous appelerons d esormais les destinataire et emetteur. Sch ema dune relation clientserveur en mode connect 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 Sch ema dune relation clientserveur en mode non connect 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 ) pr esent sur toute machine unix5 . Ce serveur fonctionne en mode connect e ou non, sur le port 13 qui lui est r eserv e (/etc/services). Ici le serveur est une machine portant ladresse IP 192.168.52.232. La connaissance de ladresse IP du client nest absolument pas utile pour la compr ehension de lexemple. En mode TCP le simple fait de se connecter provoque l emission de la cha ne ascii contenant la date vers le client et sa d econnexion. En mode UDP il sut denvoyer un datagramme quelconque (1 caract` ere) au serveur puis dattendre sa r eponse.

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 r eseau echang ees lors de lex ecution de cette commande se trouve page 215. ligne 28 D eclaration de la structure saddr du type sockaddr in, ` a utiliser avec IPv4. Attention, il sagit bien dune structure et non dun pointeur de structure. ligne 34 La variable sfd, re coit la valeur du descripteur de socket. Celle-ci est d edi ee au protocole TCP. 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 e` a la valeur du num ero de port sur lequel ecoute le serveur. Il faut remarquer lusage de la fonction htons (en fait une macro du pr e-processeur cpp) qui sassure que ce num ero de port respecte bien le NBO ( network Byte Order ), car cette valeur est directement recopi ee dans le champ PORT DESTINATION du protocole de transport employ e (voir page 78 pour UDP et page 85 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 invers es (le NBO est du type big endian ). Vous croyez ecrire 13 alors quen r ealit e pour le r eseau vous avez ecrit 3328 (0x0D00) ce qui bien evidement ne conduit pas au m eme r esultat, sauf si un serveur de date ecoute egalement sur le port 3328, ce qui est tr` es peu probable car non conventionnel.
5

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

13 Exemples de code client En r esum e, si le programmeur nutilise pas la fonction htons, ce code 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 e de ladresse IP. Cest donc l ecriture de quatre octets (IPv4), pouvant comporter un caract` ere ascii 0, donc interpr etable comme le caract` ere de n de cha ne du langage C.

214

Sockets de Berkeley Cest pourquoi ` a cet endroit on ne peut pas employer les habituelles fonctions de la biblioth` eque standard (celles qui commencent par str). Ici le probl` eme se complique un peu dans la mesure o` u lon dispose au d epart dune adresse IP sous sa forme d ecimale point ee. La fonction inet addr g` ere parfaitement ce cas de gure. Nous en dirons plus ` a son sujet au chapitre suivant. ligne 41 Appel ` a la primitive connect pour etablir la connexion avec le serveur distant. Quand celle-ci retourne dans le code du programme, soit la connexion a echou e et il faut traiter lerreur, soit la connexion est etablie. L echange pr eliminaire des trois paquets sest eectu e dans de bonnes conditions (page 88). Du point de vue TCP, les cinq el ement du quintuplet qui caract erise la connexion sont d enis (page ??). Sur la capture des paquets de la page 215 nous sommes arriv es ` a la ligne 6, cest ` a dire lenvoi de lacquittement par le client du paquet de synchronisation envoy e par le serveur (ligne 3 et 4). Il faut noter que bien que nous ayons transmis la structure saddr par adresse (caract` ere &) et non par valeur, la primitive connect ne modie pas son contenu pour autant. Notons egalement lusage du cast du C pour forcer le type du pointeur (le prototype de la primitive exige ` a cet endroit un pointeur de type sockaddr). ligne 45 Appel ` a la primitive read pour lire le r esultat en provenance du serveur, ` a laide du descripteur sfd. Sur la capture d ecran on voit ligne 8 (et 9) lenvoi de la date en provenance du serveur, dune longueur de 26 caract` eres. Ce nombre de caract` eres eectivement lus est aect e` a la variable n. Ce nombre ne peut exc eder le r esultat de l evaluation de M AXM SG 1, qui correspond ` a la taille du buer buf moins 1 caract` ere pr evu pour ajouter le caract` ere 0 de n de cha ne. En eet, celui-ci fait partie de la convention de repr esentation des cha nes de caract` eres du langage C. Rien ne dit que le serveur qui r epond ajoute un tel caract` ere ` a la n de sa r eponse. Le contraire est m eme certain puisque la RFC 867 ny fait pas mention. Remarque : le buer buf est largement surdimensionn e compte tenu de la r eponse attendue. La RFC 867 ne pr evoit pas de taille maximum si ce nest implicitement celle de lexpression de la date du syst` eme en anglais, une quarantaine doctets au maximum. ligne 49 Ajout du caract` ere de n de cha ne en utilisant le nombre de caract` eres renvoy es par read. ligne 52 La sortie du programme induit une cl oture de la socket cot e client. Cot e serveur elle est d ej` a ferm ee (s equence write + close) comme on peut le voir ligne 8 (ag FP, page 86) ci-apr` es dans la capture du trac entre le client et le serveur.

13 Exemples de code client Remarque : rien nest explicitement pr evu dans le code pour etablir la socket cot e client, ` a savoir lassociation dun num ero de port et dune adresse IP. En fait cest la primitive connect qui sen charge. Ladresse IP est celle de la machine. Le num ero de port est choisi dans la zone dattribution automatique comme nous lavons examin e page 79. Il existe bien entendu une possibilit e pour le programme davoir connaissance 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 e avec tcpdump

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` ere (NULL) au serveur, sans quoi il na aucun moyen de conna tre notre existence. ligne 37, 38 et 39 Le remplissage de la structure saddr est identique ` a celui de la version TCP. ligne 45 R eception de caract` eres en provenance du r eseau. 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 r eponse du serveur). Le raisonnement sur la taille du buer est identique ` a celui de la version TCP. La capture de trames suivante montre lextr eme simplicit e de l echange 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 e avec tcpdump

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 eloign ee et N de port. et N de port. bind listen, accept connect bind recvfrom bind sendto

En conclusion on peut etablir le tableau suivant :

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

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 cit ees dans ce chapitre, on pourra consulter les documents de r ef erence suivants : Stuart Sechrest An Introductory 4.4BSD Interprocess Communication Tutorial Re imprim e dans Programmers Supplementary 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 compr ehension des m ecanismes internes : 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 egalement trouver ce document dans /usr/share/doc/psd/20.ipctut/ des OS dinspiration Berkeley 4.4

le

r epertoire

218

Sockets de Berkeley

Chapitre XII Compl ements sur les sockets Berkeley


1 R eservation des ports

Au chapitre pr ec edent nous avons utilis e la primitive bind pour assigner une adresse ` a une socket, dans ce paragraphe nous pr ecisons comment choisir le num ero de port qui va bien, selon le type dapplication envisag e. Nous avons d ej` a examin e ce point dans les grandes lignes page 79. Il y a deux mani` eres dassigner un N de port ` a une socket : 1. Le processus sp ecie le num ero. Cest typiquement ce que fait un serveur. On suppose bien evidement que les clients sont au courant ou quils disposent dun m ecanisme qui peut les renseigner (cf cours sur les RPC). 2. Le processus laisse le syst` eme lui assigner automatiquement un num ero 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` egle g en erale le d eveloppeur dapplication ne sattribue pas au hasard un (ou plus) num ero de port. Il doit respecter quelques contraintes comme ne pas utiliser les ports d ej` a attribu es. Ceux-ci gurent dans une RFC particuli` ere. La derni` ere en date est la RFC 1700 [Reynolds & Postel 1994]) au paragraphe WELL KNOWN PORT NUMBERS. Plus simplement, sur toute machine Unix ` a jour, une liste de ces ports se trouve dans le chier 1 /etc/services . Cod e sur deux octets non sign es, le num ero de port permet 65536 possibilit es de 0 ` a 65535. Cette echelle est fragment ee de deux mani` eres, lancienne ou la nouvelle m ethode. Toutes les applications sur tous les syst` emes dexploitation nont pas encore adopt e la nouvelle approche, les deux vont donc cohabiter un certain temps, ne serait-ce qu` a cause de vieilles applications non mises ` a jour.
http ://www.iana.org/assignments/port-numbers pour se tenir au courant des evolutions de cette liste
1

220

Compl ements sur les sockets Berkeley

1.1

R eservation de port Ancienne m ethode

Port N 0 Ce num ero nest pas utilisable pour une application, cest une sorte de jocker qui indique au syst` eme que cest ` a lui de compl eter automatiquement le num ero (voir plus loin de 1024 ` a 5000). Port de 1 ` a 255 Pour utiliser cette zone il faut avoir les droits du root ` a lex ecution pour que le bind ne retourne pas une erreur. Les serveurs classiques (domain, ftp, smtp, telnet, ...) se situent tous dans cette partie. Ports de 256 ` a 511 Jadis consid er e comme une r eserve des serveurs ociels commencent ` a sy installer, faute de place dans la zone pr ec edente. Il faut egalement avoir les droits du root pour utiliser un num ero de port dans cette zone. Port de 512 ` a 1023 Une fonction rresvport permet lattribution automatique dun num ero de port dans cette zone, pour des applications ayant 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 ` a 5000 Zone dattribution automatique par bind. Lorsque lutilisateur (non root) utilise 0 comme num ero, cest le premier port libre qui est employ e. Si tous les utilisateurs peuvent sattribuer manuellement un num ero dans cette zone, il vaut mieux eviter de le faire, la suivante est pr evue pour cela. 5001 ` a 65535 Zone libre attention cependant car de tr` es nombreux serveurs y ont un port r eserv e, et pas des moindres comme le serveur X11 sur le port 6000 !

1.2

R eservation de port Nouvelle m ethode

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

2 Ordre des octets sur le r eseau

221

Ordre des octets sur le r eseau


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` eme de lordre des octets sur le r eseau est dautant plus crucial que lon travaille dans un environnement avec des architectures h et erog` enes. La couche R eseau (page 28) ne transforme pas les octets de la couche Internet (page 27) qui elle m eme ne modie pas ceux de la couche de Transport2 (page 27). Pour cette raison, le num ero de port inscrit dans len-t ete TCP (vs UDP) de l emetteur est exploit e tel quel par la couche de transport du r ecepteur et donc il convient de prendre certaines pr ecautions pour sassurer que les couches de m eme niveau se comprennent. Dun point de vue plus g en eral, les r eseaux imposent le poids fort avant le poids faible, cest le Network Byte Order. Les architectures qui travaillent naturellement avec cette repr esentation nont donc th eoriquement pas besoin dutiliser les fonctions qui suivent, de m eme pour les applications qui doivent dialoguer avec dautres ayant la m eme architecture mat erielle. N eanmoins ecrire du code portable consiste ` a utiliser ces macros dans 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 num ero de port par exemple. l long Entier long sur 32 bits, une adresse IP par exemple. h host La machine sur laquelle sex ecute le programme. n network Le r eseau sur lequel on envoie les donn ees. #include <sys/types.h>
Nous nabordons pas ici la question de la transmission de donn ees h et erog` enes au niveau applicatif, elle sera examin ee dans le cours sur les XDR 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

Compl ements sur les sockets Berkeley 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 num ero de port 13 (service daytime) au champ sin port dune structure de type sockaddr in : saddr.sin port = htons(13) ; Cette ecriture est valable quelle que soit larchitecture sur laquelle elle est compil ee. Sil avait fallu se passer de la macro htons sur une architecture Intel (little endian), pour laection du m eme num ero de port, il eut fallu ecrire : saddr.sin port = 0x0D00 ; /* 0D hexad ecimal == 13 d ecimal */

Op erations sur les octets

Dans le m eme ordre did ee quau paragraphe pr ec edent, les r eseaux interconnectent des architectures h et erog` enes et donc aussi des conventions de r epr esentation des cha nes de caract` eres di erentes. Pour etre plus pr ecis, le caract` ere NULL marqueur de n de cha ne bien connu des programmeurs C, nest pas valide partout, voire m eme est associ e` a une autre signication ! En cons equence, pour toutes les fonctions et primitives qui lisent et ecrivent des octets sur le r eseau, les cha nes de caract` eres sont toujours associ ees au nombre de caract` eres qui les composent. Le corollaire est que les fonctions classiques de manipulation de cha nes en C (strcpy, strcat, ...) ne sont ` a utiliser quavec une extr eme prudence. Pour copier des octets dune zone vers une autre il faut utiliser bcopy, pour comparer deux buers, bcmp, enn pour mettre ` a z ero (remplir doctet 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 copi es dans dst et non linverse, 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 ` a vis dune quelconque relation dordre (` a la di erence de strcmp qui suppose les caract` eres dans la table ASCII).

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

223

Conversion dadresses

La plupart du temps les adresses IP sont fournies par lutilisateur dans le format d ecimal point e, or la structure dadresse (sockaddr in) a besoin dun entier non sign e sur 32 bits. Une conversion est donc n ecessaire pour passer dune repr esentation ` a une autre. La fonction inet addr converti une adresse d ecimale point ee en un entier long non sign e et qui respecte le NBO. La fonction inet ntoa eectue le 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 sym etriques, le fait que etre une inet addr ne renvoie pas une structure du type in addr semble 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 h ote adresse IP

Se pose r eguli` erement le probl` eme de convertir un nom symbolique en une adresse IP et inversement. Lorigine de cette information d epend de la conguration de la station de travail : cest un serveur de noms (DNS), cest un chier (/etc/hosts) ou tout autre syst` eme de propagation des informations (NIS. . .). Dans tous les cas linformation arrive ` a un programme via une entit e nomm ee le resolver, qui unie les sources dinformations.

5.1

Une adresse IP ` a partir dun nom dh ote


(char *name) ;

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

224

Compl ements sur les sockets Berkeley 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 ` a assurer la compatibilit e avec les premi` eres versions dans lesquelles il ny avait quune seule adresse IP possible par h ote. Le nom ociel soppose aux noms synonymes. Par exemple, soit une machine ociellement baptis ee pasglop.mon-domain.fr ; si pour r epondre au besoin dune certaine application ladministrateur du r eseau lui donne le surnom www.mon-domain.fr, celui-ci sera consid er e comme un alias vis ` a vis du nom ociel et donc lu dans h aliases. (voir page 120) La n du tableau de pointeurs est marqu ee par un pointeur NULL. La liste des adresses est un tableau de pointeurs, le marqueur de n de liste est egalement un pointeur NULL. Chaque adresse est une zone de h length octets (cf fonction impnet dans lexemple ci-apr` es). Le programme dusage qui suit ache toutes les informations contenues dans cette structure pour les h otes dont le nom est pass e en argument (le code source de cet exemple, gethostbyname.c, est ` a la page suivante). $ 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 h ote adresse IP


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 dh ote ` a partir dune adresse IP

le probl` eme sym etrique se r esoud avec la fonction gethostbyaddr. La d enition du prototype se trouve au m eme endroit que pr ec edement, 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.

Compl ements sur les sockets Berkeley

type PF INET quand on utilise la pile ARPA.

Conversion N de port service

Couramment les ports bien connus sont donn es par leur nom plut ot que par leur valeur num erique, comme par exemple dans les sorties de la commande tcpdump.

6.1

Le num ero ` a partir du nom

Un tel programme a besoin de faire la conversion symbolique num erique, la fonction getservbyname eectue ce travail. Lutilisateur r ecup` ere un pointeur sur une structure du type servent, NULL dans le cas dune impossibilit e. La source dinformations se trouve dans le chier /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 ` a NULL. s port Le num ero du port (il respecte le Network Byte Order). s proto Le nom du protocole ` a utiliser pour contacter le service (TCP vs UDP). Voici un programme de mise en application de la fonction, le code source de lexemple, getservbyname.c se trouve ` a la page suivante. $ 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 ` a partir du num ero

Sym etriquement la fonction getservbyport eectue le travail inverse. 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

Compl ements sur les sockets Berkeley


/* * $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 d elivrent un nom de protocole, donc un symbole. Lors de la d eclaration dune socket le troisi` eme argument est num erique, il est donc n ecessaire davoir un moyen pour convertir les num eros de protocoles (IPPROTO UDP, IPPROTO TCP, IPPROTO IP,IPPROTO ICMP,...) en symboles et r eciproquement. 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 num ero du protocole, dans /etc/services.
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 pr ec` ede donne un exemple de programmation de la fonction 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 etre soigneusement test e, le code g en er e nen est que plus able et les eventuels disfonctionnements plus ais es ` a d etecter. Quelques unes des erreurs ajout ees au chier den-t ete errno.h

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

Compl ements sur les sockets Berkeley 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 Op eration non support ee Famille dadresse non support ee Adresse d ej` a utilis ee Ladresse ne peut pas etre aect ee R eseau hors service Pas de route pour atteindre ce r eseau Connexion coup ee par le r eseau Connexion interrompue Connexion interrompue par lh ote distant Le buer est satur e La socket est d ej` a connect ee La socket nest pas connect ee Transmission apr` es un shutdown time-out expir e Connexion refus ee Lh ote distant a interrompue sa connexion Lh ote nest pas en marche Pas de route vers cet h ote

9 Exemples de mise en application

231

Exemples de mise en application

Deux exemples de fonctions de connexion ` a un serveur sont jointes ` a ce cours : lune tcp open et lautre udp open. Toutes les deux renvoient un descripteur de socket pr et ` a lemploi, ou -1 en cas derreur (le message derreur doit etre g en er e par les fonctions elles m emes). En voici les prototypes : 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 ne de caract` eres qui est ladresse de lh ote distant. Cette adresse est soit sous forme d ecimale point ee, soit cest un nom symbolique. Elle ne peut pas etre nulle. service Si cette cha ne nest pas nulle, elle contient le nom symbolique du service distant sur lequel il faut se connecter. port Le num ero du port distant. Sil est n egatif alors service est obligatoirement non nulle. Dans le cas o` u service est non nulle et port > 0, cette derni` ere valeur lemporte sur celle trouv ee dans le chier /etc/services. conn Cet argument na dusage que pour la fonction udp open. Egal ` a un, il pr ecise que la socket cr ee est d edi ee au serveur host (avec un bind), 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

Compl ements sur les sockets Berkeley


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 ` a la fonction appelante, La fonction udp open compl` ete une structure globale.
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

Compl ements sur les sockets Berkeley

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

Compl ements sur les sockets Berkeley

10

Conclusion et bibliographie

Lusage des fonctions vues dans ce chapitre peut se r esumer autour dune 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 re edit e dans Programmers Supplementary Documents editeur OReilly, ou sous forme de chier ascii dans le r epertoire : /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 ements de serveurs El


Dans ce chapitre nous abordons quelques grands principes de fonctionnement des logiciels serveurs. Dabord nous tentons de r esumer leurs comportements selon une typologie en quatre mod` eles g en eriques, puis nous examinons quelques points techniques remarquables de leur architecture logicielle comme la gestion des taches multiples, des descripteurs multiples, le fonctionnement en arri` ere plan (les fameux daemon ), la gestion des logs. . . Enn nous concluons ce chapitre avec une petite pr esentation du serveur de serveurs sous Unix, cest ` a dire la commande inetd !

Type de serveurs

Lalgorithme intuitif dun serveur, d eduit des sch emas (revoir la page 211) dutilisation des sockets, pourrait etre celui-ci : 1. Cr eer une socket, lui aecter une adresse locale avec un num ero de port connu des clients potentiels. 2. Entrer dans une boucle innie qui accepte les requ etes des clients, les lit, formule une r eponse et la renvoie au client. Cette d emarche, que nous pourrions qualier de na ve, ne peut convenir qu` a des applications tr` es simples. Consid erons lexemple dun serveur de chiers fonctionnant sur ce mode. Un client r eseau qui sy connecte et t el echarge pour 10 Go de donn ees accapare le serveur pendant un temps signicativement long, m eme au regard des bandes passantes modernes. Un deuxi` eme client r eseau qui attendrait la disponibilit e du m eme serveur pour transf erer 1Ko aurait des raisons de simpatienter !

1.1

Serveurs it eratif et concourant

Un serveur it eratif ( iterative server ) d esigne une impl ementation qui traite une seule requ ete ` a la fois. Un serveur concourant ( concurrent server ) d esigne une impl ementation capable de g erer plusieurs taches en apparence simul-

238

ements de serveurs El tan ees. Attention, cette fonctionnalit e nimplique pas n ecessairement que ces taches concourantes doivent toutes sex ecuter en parall` ele. . . Dans cette premi` ere approche purement algorithmique nous nabordons pas la mise en uvre technique, le paragraphe 2 sy consacrera ! Dun point de vue conceptuel, les serveurs it eratifs sont plus faciles ` a concevoir et ` a programmer que les serveurs concourants, mais le r esultat nest pas toujours satisfaisant pour les clients. Au contraire, les serveurs concourants, sils sont dune conception plus savante, sont dun usage plus agr eable pour les utilisateurs parceque naturellement plus disponibles.

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 etre compl` etement boulevers e par le choix de lun ou de lautre. Avant toute chose il faut se souvenir des caract eristiques les plus marquantes de lun et de lautre. Mode connect e Le mode connect e avec TCP est le plus facile ` a programmer, de plus il assure que les donn ees sont transmises, sans perte. Par contre, Il etablit un circuit virtuel bi-directionnel d edi e ` a chaque client ce qui monopolise une socket, donc un descripteur, et interdit par construction toute possibilit e de broadcast . L etablissement dune connexion et sa terminaison entra ne l echange de 7 paquets. Sil ny a que quelques octets ` a echanger entre le client et le serveur, cet echange est un gaspillage des ressources du r eseau. Il y a plus pr eoccupant. Si la connexion est au repos , cest ` a dire quil ny a plus d echange entre le client et le serveur, rien nindique ` a celui-ci que le client est toujours l` a ! TCP est silencieux si les deux parties nont rien ` a s echanger1 . Si lapplication cliente a et e interrompue accidentellement2 , rien nindique au serveur que cette connexion est termin ee et il maintient la socket et les buers associ es. Que cette op eration se r ep` ete un grand nombre de fois et le serveur ne r epondra plus, faute de descripteur disponible, voire de m emoire libre au niveau de la couche de transport (allocation au niveau du noyau, en fonction de la m emoire totale et au d emarrage de la machine) ! Mode datagramme Le mode datagramme ou non connect e avec UDP h erite de tous les d esagr ements de IP, ` a savoir perte, duplication et d esordre introduit dans lordre des datagrammes.
Nous verrons au chapitre suivant comment on peut modier ce comportement par d efaut 2 crash du syst` eme, retrait du r eseau,. . .
1

Quatre mod` eles de serveurs Pourtant malgr e ces inconv enients UDP reste un protocole qui ore des avantages par rapport ` a TCP. Avec un seul descripteur de socket un serveur peut traiter un nombre quelconque de clients sans perte de ressources due ` a de mauvaises d econnexions. Le broadcast et le multicast sont possibles. Par contre les probl` emes de abilit e du transport doivent etre g er es au niveau de lapplication. G en eralement cest la partie cliente qui est en charge de la re emission de la requ ete si aucune r eponse du serveur ne lui parvient. La valeur du temps au del` a duquel lapplication consid` ere quil doit y avoir re emission est evidement d elicate ` a etablir. Elle ne doit pas etre g ee aux caract eristiques dun r eseau local particulier et doit etre capable de sadapter aux conditions changeantes dun internet.

239

1.3

Quatre mod` eles de serveurs

Deux comportements de serveurs et deux protocoles de transport combin es g en` erent quatre mod` eles de serveurs :
Itratif Datagramme Itratif Connect

Concourant Datagramme

Concourant Connect

gure XIII.01 La terminologie tache esclave employ ee dans les algorithmes qui suivent se veut neutre quant au choix technologique retenu pour les impl ementer. Ce qui importe cest leur nature concourante avec la tache ma tre qui les engendre. Algorithme it eratif - Mode data-gramme : 1. Cr eer une socket, lui attribuer un port connu des clients. 2. R ep eter : Lire une requ ete dun client, Formuler la r eponse, Envoyer la r eponse, conform ement au protocole dapplication. Critique : Cette forme de serveur est la plus simple, elle nest pas pour autant inutile. Elle est adapt ee quand il y a un tout petit volume dinformation ` a echanger et en tout cas sans temps de calcul pour l elaboration de la r eponse. Le serveur de date daytime ou le serveur de temps time en sont dexcellents exemples.

240 Algorithme It eratif - Mode connect e:

ements de serveurs El

1. Cr eer une socket, lui attribuer un port connu des clients. 2. Mettre la socket ` a l ecoute du r eseau, en mode passif. 3. Accepter la connexion entrante, obtenir une socket pour la traiter. 4. Entamer le dialogue avec le client, conform ement au protocole de lapplication. 5. Quand le dialogue est termin e, fermer la connexion et aller en 3). Critique : Ce type de serveur est peu utilis e. Son usage pourrait etre d edi e ` a des relations clients/serveurs mettant en jeu de petits volumes dinformations avec la n ecessit e den assurer ` a coup s ur le transport. Le temps d elaboration de la r eponse doit rester court. Le temps d etablissement de la connexion nest pas n egligeable par rapport au temps de r eponse du serveur, ce qui le rend peu attractif. Algorithme concourant - Mode datagramme : Ma tre : 1. Cr eer une socket, lui attribuer un port connu des clients. 2. R ep eter : Lire une requ ete dun client Cr eer une tache esclave pour elaborer la r eponse. Esclave : 1. Recevoir la demande du client, 2. Elaborer la r eponse, 3. Envoyer la r eponse au client, conform ement au protocole de lapplication, 4. Terminer la tache.

Quatre mod` eles de serveurs Critique : Si le temps d elaboration de la r eponse est rendu indi erent pour cause de cr eation de processus esclave, par contre le co ut de cr eation de ce processus ls est prohibitif par rapport ` a son usage : formuler une seule r eponse et lenvoyer. Cet inconv enient lemporte g en eralement sur lavantage apport e par le parall elisme . N eanmoins, dans le cas dun temps d elaboration de la r eponse long par rapport au temps de cr eation du processus esclave, cette solution se justie. Algorithme concourant - Mode connect e: Ma tre : 1. Cr eer une socket, lui attribuer un port connu des clients. 2. Mettre la socket ` a l ecoute du r eseau, en mode passif. 3. R ep eter : Accepter la connexion entrante, obtenir une socket pour la traiter, Cr eer une tache esclave pour traiter la r eponse. Esclave : 1. Recevoir la demande du client, 2. Amorcer le dialogue avec le client, conform ement au protocole de lapplication, 3. Terminer la connexion et la tache. Critique : Cest le type le plus g en eral de serveur parce-quil ore les meilleurs caract eristiques de transport et de souplesse dutilisation pour le client. Il est sur-dimensionn e pour les petits services et sa programmation soign ee nest pas toujours ` a la port ee du programmeur d ebutant.

241

242

ements sur les serveurs El

Technologie el ementaire

De la partie algorithmique d ecoulent des questions techniques sur le comment le faire . Ce paragraphe donne quelques grandes indications tr` es el ementaires que le lecteur soucieux dacqu erir une vraie comp etence devra compl eter par les lectures indiqu ees au dernier paragraphe ; la Bibliographie du chapitre (page 258). Notamment il est n ecessaire de consulter les ouvrages de W. R. Stevens pour la partie syst` eme et David R. Butenhof pour la programmation des threads. La suite du texte va se consacrer ` a eclairer les points suivants : 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` ere plan ou daemon (paragraphe 3)

2.1

Gestion des taches esclaves

La gestion des taches esclaves signal ees dans le paragraphe 1 induit que le programme serveur est capable de g erer plusieurs actions concourantes, cest ` a dire qui ont un comportement qui donne lillusion ` a lutilisateur que sa requ ete est trait ee dans un d elai raisonnable, sans devoir patienter jusqu` a lach` evement de la requ ete pr ec edente. Cest typiquement le comportement dun syst` eme dexploitation qui ordonnance des processus entre-eux pour donner ` a chacun deux un peu de la puissance de calcul disponible ( time-sharing ). La d emarche qui parait la plus naturelle pour impl ementer ces taches esclaves est donc de tirer partie des propri et es m emes de la gestion des processus du syst` eme dexploitation. Sur un syst` eme Unix lusage de processus est une bonne solution dans un premier choix car ce syst` eme dispose de primitives (APIs) bien rod ees pour les g erer, en particulier fork(), vfork() et rfork(). N eanmoins, comme le paragraphe suivant le rappelle, lusage de processus ls nest pas la panac ee car cette solution comporte des d esagr ements. Deux autres voies existent, non toujours valables partout et dans tous les cas de gure. La premi` ere passe par lusage de processus l egers ou threads , la deuxi` eme par lusage du signal SIGIO qui autorise ce que lon nomme la programmation asynchrone (cf 2.4). Pour conclure il faut pr eciser que des taches esclaves ou concourantes peuvent sex ecuter dans un ordre al eatoire mais pas n ecessairement en m eme temps. Cette derni` ere caract eristique est celle des taches parall` eles. Autrement dit, les taches parall` eles sont toutes concourantes mais linverse nest pas vrai. Concr` etement il faut disposer dune machine avec plusieurs processeurs pour avoir, par exemple, des processus (ou des threads kernel , si elles sont support ees) qui sex ecutent vraiment de mani` ere simultan ee donc sur

fork, vfork et rfork des processeurs di erents. Sur une architecture mono-processeur, les taches ne peuvent etre que concourantes !

243

2.2

fork, vfork et rfork

Il ne sagit pas ici de faire un rappel sur la primitive fork() examin ee dans le cadre du cours Unix, mais dexaminer lincidence de ses propri et es sur larchitecture des serveurs. Le r esultat du fork() est la cr eation dun processus ls qui ne di` ere de son p` ere que par les points suivants : 1. Le code de retour de fork : 0 pour le ls, le pid du ls pour le p` ere 2. Le num ero de processus (pid) ainsi que le num ero de processus du processus p` ere (ppid) 3. Les compteurs de temps (utime, stime, . . .) qui sont remis ` a z ero 4. Les verrous (flock) qui ne sont pas transmis 5. Les signaux en attente non transmis egalement Tout le reste est doublonn e, notamment la stack et surtout la heap qui peuvent etre tr` es volumineuses et donc rendre cette op eration p enalisante voire quasi redhibitoire sur un serveur tr` es charg e (des milliers de processus et de connexions r eseaux). Si le but du fork dans le processus ls est deectuer un exec imm ediatement, alors il tr` es int eressant dutiliser plut ot le vfork. Celui-ci ne fait que cr eer un processus ls sans copier les donn ees. En cons equence, durant le temps de son ex ecution avant le exec le ls partage strictement les m emes donn ees que le p` ere (` a utiliser avec pr ecaution). Jusqu` a ce que le processus rencontre un exit ou un exec, le processus p` ere reste bloqu e (le vfork ne retourne pas). En allant plus loin dans la direction prise par vfork, le rfork3 autorise la continuation du processus p` ere apr` es le fork, la cons equence est que deux processus partagent le m eme espace dadressage simultan ement. Largument dappel du rfork permet de param` etrer ce qui est eectivement partag e ou non. RFMEM, le principal dentre eux, indique au noyau que les deux processus partagent tout lespace dadressage. Si cette derni` ere primitive est tr` es riche de potentialit es4 , elle est egalement d elicate ` a manipuler : deux (ou plus) entit es logicielles ex ecutant le m eme code et acc edant aux m emes donn ees sans pr ecaution particuli` ere vont tr` es certainement converger vers de s erieux ennuis de fonctionnement si le d eroulement de leurs op erations nest pas rigoureusement balis e. En eet, le soucis principal de ce type de programme multi-entit es est de veiller ` a ce quaucune de ses composantes ne puisse changer les etats de
clone() sous Linux dailleurs limpl ementation actuelle des threads sous Linux emploie cette primitive avec des avantages et beaucoup dinconv enients par rapport ` a ce que pr evoit la norme Posix et ` a la gestion des processus
4 3

244

ements sur les serveurs El sa m emoire simultan ement. Autrement dit, il faut introduire presque obligatoirement un m ecanisme de s emaphore qui permette ` a lune des entit es logicielles de v erouiller lacc` es ` a telle ou telle ressource m emoire pendant le temps n ecessaire ` a son usage. Cette op eration de v erouillage elle-m eme pose probl` eme, parceque les entit es logicielles pouvent sex ecuter en parall` ele (architecture multiprocesseurs) et donc il est indispensable que lacquisition du s emaphore qui prot` ege une ressource commune soit une op eration atomique, cest ` a dire qui sex ecute en une fois, sans quil y ait possibilit e que deux (ou plus) entit es logicielles tentent avec succ` es de lacqu erir. Cest toute la probl` ematique des mutex5 .

2.3

Processus l egers, les threads

Les processus l egers ou threads sont une id ee du milieu des ann ees 80. La norme Posix a pos e les bases de leur d eveloppement durable en 1995 (Posix 1.c), on parle g en eralement de pthreads. Lid ee fondatrice des threads est de ne pas faire de fork mais plut ot de permettre le partage de lespace dadressage ` a autant de contextes 6 dex ecution du m eme code que lon souhaite.
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 cr eer un nouveau processus on cr ee une nouvelle thread, ce qui revient (en gros) ` a ajouter un nouveau contexte dex ecution sur la pile syst` eme dans le processus. Lusage de mutex (cf paragraphe 2.2) est fortement recommand e pour s erialiser les acc` es aux sections critiques du code. Sur une machine ayant une architecture mono-processeur, le premier type de threads est susant, mais d` es que la machine est construite avec une ar7 chitecture smp (ce qui est de plus en plus le cas avec la banalisation des congurations bi-processeurs et plus) lusage de threads g erables par le noyau devient beaucoup plus int eressant car il utilise au mieux les ressources de la
5 6

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

Processus l egers, les threads machine : un m eme processus pourrait avoir deux threads, une sex ecutant sur chacun des deux processeurs (ou plus bien entendu, sil y a plus de processeurs). Le principe etant pos e, on distingue plusieurs familles dimpl ementation. Dun cot e il y a les threads user land cest ` a dire qui sont compl` etement g er ees par le processus utilisateur et de lautre les threads kernel , qui sont g er ees par le noyau. Ces derni` eres threads sont support ees par les constructeurs de machines ` a architectures parall` eles, traditionnellement Sun (Solaris) et Compaq (ex Digital, avec True64) et plus recement Hewlett-Packard avec la version 11.xx dHP-UX. Le probl` eme est tr` es complexe et chaque constructeur d eveloppe ses propres strat egies. Du cot e des OS libres le probl` eme navance pas vite car il monopolise 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` es ecace. Cette approche nest pas satisfaisante car chaque thread est ex ecut ee dans un processus di erent (pid di erent donc) ce qui est contraire aux recommandations POSIX, dune part, et dautre par ne permet pas dutiliser les r` egles de priorit e d enies egalement par POSIX. Une application avec un grand nombre de threads prend lavantage sur les autres applications par le fait quelle consomme en temps cumul e bien plus que les autres processus mono-thread. Actuellement les threads de FreeBSD sont encore du type user land mais un projet tr` es ambitieux et tr` es prometteur (dont lissue a et e repouss ee plusieurs fois) est en cours de d eveloppement8 . Conclusion : Les threads user land ne sex ecutent que sur un seul processeur quelle que soit larchitecture de la machine qui les supporte. Sur une machine de type smp il faut que le syst` eme dexploitation supporte les threads kernel pour quun m eme processus puisse avoir des sous-taches sur tous les processeurs existants.

245

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

246

ements sur les serveurs El

2.4

Programmation asynchrone

Les paragraphes qui pr ec` edent utilisent un processus ou une thread pour pouvoir eectuer au moins deux taches simultan ement : ecouter le r eseau et traiter une (ou plusieurs) requ ete(s). Dans le cas dun serveur peu sollicit e il tout ` a fait envisageable de mettre en uvre une autre technique appell ee programmation asynchrone . La programmation asynchrone sappuie sur lusage du signal, SIGIO (SIGPOLL sur syst` eme V), ignor e par d efaut, qui pr evient le processus dune activit e sur un descripteur. La gestion des entr ees/sorties sur le descripteur en question est alors trait ee comme une exception, par un handler de signaux. Le signal SIGIO est ignor e par d efaut, il faut demander explicitement au noyau de le recevoir, ` a laide dun appel ` a la primitive fcntl. Une fois activ e, il nest pas re cu pour les m emes raisons selon le protocole employ e: UDP : Arriv ee dun paquet pour la socket Une erreur TCP : Une demande de connexion (attente sur un accept) qui arrive Une d econnexion Une demi-d econnexion (shutdown) Arriv ee de donn ees sur une socket Fin de l emission de donn ees (buer d emission vide) sur une socket Une erreur O` u lon voit que cette technique, du moins en TCP, ne peut etre envisag ee pour que pour des serveurs peu sollicit es. Un trop grand nombre dinterruptions possibles nuit ` a lecacit e du syst` eme (changements de contexte). De plus la distinction entre les causes du signal est dicile ` a faire, donc ce signal en TCP est quasi inexploitable. Conclusion : La d enomination programmation asynchrone bas ee seulement sur lusae du signal SIGIO (versus SIGPOLL) est abusive. Pour etre vraiment asynchrones, ces op erations de lecture et d ecriture ne devraient pas etre assujetties au retour des primitives read ou write9 . Cette technique permet l ecriture du code de petits serveurs bas e sur le protocole UDP (En TCP les causes de r eception dun tel signal sont trop nombreuses) sans fork ni 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 g erer simultan ement plusieurs sockets (serveur multi-protocoles par exemple, comme inetd. . .) se trouve par construction dans une situation o` u il doit examiner en m eme temps plusieurs descripteurs (il pourrait sagir aussi de tubes de communication). Il est absolument d econseill e dans cette situation de faire du polling. Cette activit e consisterait ` a examiner chaque descripteur lun apr` es lautre dans une boucle innie qui devrait etre la plus rapide possible pour etre la plus r eactive possible face aux requ etes entrantes. Sous Unix cette op eration entra ne une consommation exag er ee des ressources cpu, au d etriment des 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` es que lun des descripteurs devient actif (il peut y en avoir plusieurs ` a la fois) le noyau r eveille le processus et lappel de select rend la main ` a la proc edure appelante avec susemment dinformation pour que celle-ci puisse identier quel(s) descripteur(s) justie(nt) son r eveil !
#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 d ecrit dans <sys/types.h>, ainsi que les macros 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 imm ediatement apr` es avoir test e les descripteurs. Tous les champs de timeout doivent etre ` a 0 ( polling dans ce cas). Si timeout est une structure existante (pointeur non nul), et si ses champs sont non nuls, select retourne quand un des descripteurs est

248

ements sur les serveurs El pr et, et en tout cas jamais au del` a de la valeur pr ecis ee par timeout (cf MAXALARM dans <sys/param.h>). Si timeout est un pointeur NULL, la primitive est bloquante jusqu` a ce quun descripteur soit pr et (ou quun signal intervienne). Remarque : select travaille au niveau de la micro-seconde, ce que ne fait pas sleep (seconde), do` u un usage possible de timer de pr ecision. readfs descripteurs ` a surveiller en lecture. writefs descripteurs ` a surveiller en ecriture. exceptfs Ce champ permet de traiter des ev enements exceptionnels sur les descripteurs d esign es. Par exemple : Donn ees out-of-band sur une socket. Contr ole du statut sur un pseudo-tty ma tre. maxfd prend ` a lappel la valeur du plus grand descripteur ` a tester, plus un. Potentiellement un syst` eme BSD (4.3 et versions suivantes) permet dexaminer jusqu` a 256 descripteurs. A lappel, le programme pr ecise quels sont les descripteurs ` a surveiller dans readfs, writefs et exceptfs. Au retour, la primitive pr ecise quels sont les descripteurs qui sont actifs dans les champs readfs, writefs et exceptfs. Il convient donc de conserver une copie des valeurs avant lappel si on veut pouvoir les r eutiliser ult erieurement. La primitive renvoie -1 en cas derreur (` a tester syst ematiquement) ; une cause derreur classique est la r eception dun signal (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 m eme chose que la primitive select, mais avec une approche di erente.
#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 op erations dentr ee/sortie. -1 indique une condition derreur. 0 indique lexpiration dun d elai ( time-out ). 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` etrent respectivement les souhaits du programmeur et ce que le noyau retourne. On utilise principalement : POLLIN POLLOUT POLLERR POLLHUP nfds Taille du vecteur. timeout Est un compteur de millisecondes qui pr ecise le comportement de poll : Le nombre de millisecondes est positif strictement. Quand le temps pr evu est ecoul e, la primitive retourne dans le code de lutilisateur m eme si aucun ev enement nest intervenu. Le nombre de millisecondes est INFTIM (-1), la primitive est bloquante. 0. La primitive retourne imm ediatement. On sapper coit imm ediatement que la valeur du param` etre de timeout nest pas compatible ni en forme ni en comportement entre select et poll.

250

ements sur les serveurs El

Fonctionnement des daemons

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

3.1

Programmation dun daemon

Les daemons sont des processus ordinaires, mais : ils ne sont pas rattach es ` a un terminal particulier (ils sont en arri` ere plan ) ; ils sex ecutent le plus souvent avec les droits du super-utilisateur , voire, mieux, sous ceux dun pseudo-utilisateur sans mot de passe ni shell d eni. ils sont le plus souvent lanc es au d emarrage du syst` eme, lors de lex ecution des shell-scripts de conguration (par exemple ` a partir de /etc/rc) ; ils ne sarr etent en principe jamais (sauf bien s ur avec le syst` eme !). La conception dun daemon suit les r` egles suivantes : 1. Ex ecuter un fork, terminer lex ecution du p` ere et continuer celle du ls qui est alors adopt e par init (traditionnellement cest le processus N 1). Le processus ls est alors d etach e du terminal, ce que lon peut visualiser avec un ps -auxw (versus ps -edalf sur un syst` eme V) en 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 r epertoire courant, g en eralement la racine (/) ou tout autre r epertoire ` a la convenance de lapplication ; 4. Modier le masque de cr eation des chiers umask = 0 pour que le troisi` eme argument de open ne soit pas biais e par la valeur du umask lorsque cette primitive sert aussi ` a cr eer des chiers ; 5. Fermer tous les descripteurs devenus inutiles, et en particulier 0, 1 et 2 (entr ee et sorties standards nont plus de sens pour un processus d etach e dun terminal). le source ci-apr` es est un exemple de programmation de daemon, les appels ` a la fonction syslog font r ef erence ` a un autre daemon nomm e syslogd que nous examinons au paragraphe suivant.
Si lon en croit la premi` ere edition de UNIX System Administration Handbook , 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 d etach e dun terminal, les daemons ne peuvent plus d elivrer directement de message par les canaux habituels (perror. . .). Pour pallier ` a cette d ecience un daemon est sp ecialis e dans 11 l ecoute des autres daemons ( ecoute passive :), il sagit de syslogd . Pour dialoguer avec ce daemon un programme doit utiliser les fonctionnalit es que le lecteur trouvera tr` es bien d ecrites dans man syslog, sinon le paragraphe 3.4 en donne un aper cu rapide. La gure 3 suivante sch ematise le circuit de linformation dans le cas dune utilisation de syslogd. Le chier /etc/syslog.conf est le chier standard de conguration du daemon syslogd. Il est constitu e de lignes de deux champs : un d eclencheur
11

Ce r ole strat egique lui vaut d etre lanc e le premier et d etre stopp e le dernier

252

ements sur les serveurs El (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 d eclencheur sont remplies laction est ex ecut ee, plus pr ecisement : Le d eclencheur est un ltre qui associe un type de daemon avec un niveau de message. Par exemple mail.debug signie les messages de niveau DEBUG pour le syst` eme de routage du courrier. Les mots clefs possibles pour le type de daemon sont auth, authpriv, cron, daemon, kern, lpr, mail, news, syslog, user, uucp, et local0 ` a local7. Une etoile ( ) ` a la place, signie nimporte quel mot clef. Le niveau de message est lun des mots clefs suivants : emerg, alert, crit, err, warning, notice, et debug. Une etoile ( ) signie nimporte lequel. Un point () s epare les deux parties du ltre, comme dans mail.debug. Dans les syslog plus evolu es ladministrateur a la possibilit e de d erouter tous les messages contenant un nom de programme ( !nom du prog) ou un nom de machine (+nom de machine) Laction est soit : Un chier d esign e par un chemin absolu, comme /var/log/syslog. Une liste de logins dutilisateurs, comme root,fla. . . Un nom de machine distante (@machine.domaine.fr) Tous les utilisateurs connect es avec une etoile .

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 *.*

R esultat de lex ecution de diablotin sur la machine glups, et dans le 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 d eclarer son intention dutiliser le syst` eme de log en faisant appel ` a la fonction openlog : logopt Donne la possibilit e de pr eciser o` u le message est envoy es et dans quelle condition. facility Est l etiquette par d efaut des futurs messages envoy es par syslog. logopt LOG LOG LOG LOG CONS NDELAY PERROR PID description Ecriture sur /dev/console. Ouverture imm ediate de la connexion avec syslogd. 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

ements sur les serveurs El

Services dauthentication. Idem ci-dessus. Le daemon qui g` ere les proc edures batch. Tous les daemons du syst` eme, comme gated. Messages du noyau. Messages du gestionnaire dimprimante. Messages du gestionnaire de courrier. Messages du gestionnaire de news . Messages du daemon syslogd lui-m eme. Messages des processus utilisateur (defaut). Messages du syst` eme de transfert de chiers. R eserv e pour un usage local.

Puis chaque appel ` a la fonction syslog est compos e dun message (g en er e par lapplication) et dun code de priorit e, compos e dun niveau durgence pr ecis e par le tableau ci-dessous (niveaux d ecroissants) et dune etiquette optionnelle, prise dans le tableau ci-dessus ; elle prime alors sur celle pr ecis ee 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 imm ediate requise. Probl` emes de mat eriels Erreurs. Messages davertissement. Messages qui ne sont pas des erreurs. Informations sans cons equence. Messages pour le debug.

Enn le closelog mat erialise la n dutilisation de ce syst` eme dans le code.

4 Exemple de daemon inetd

255

Exemple de daemon inetd

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

4.1

Pr esentation de inetd

Sous Unix on peut imaginer facilement que chacun des services r eseaux oerts soient programm es comme un daemon, avec une ou plusieurs sockets, chacun surveillant son ou ses ports de communication. Un tel fonctionnement existe, g en eralement rep er e par le vocabulaire stand alone . Avec cette strat egie, chaque service comme ftp , rlogin , 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` eme est que pour faire fonctionner les services de base du r eseau on devait maintenir en m emoire (primaire en ram ou secondaire sur la zone de swap ) un grand nombre de processus souvent compl` etement inutiles ` a un instant donn e, simplement au cas ou. . . Linconv enient de cette strat egie est la consommation importante de ressources surtout avec le nombre croissant des services r eseaux de base . De plus, on peut remarquer que lanc es au d emarrage de la machine, tous ces processus eectuent des op erations similaires (cf 3), seuls di` erent les traitements propres aux serveurs eux-m emes cest ` a dire ceux qui rel` event du protocole de lapplication. La version 4.3 de BSD a apport e une simplication en introduisant une 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 ` a un seul processus (celui dinetd) dattendre de multiples demandes de connexions au lieu davoir 1 processus par type de connexion. Cette strat egie r eduit dautant le nombre de processus. 2. Il simplie l ecriture des serveurs eux-m emes, puisquil g` ere toute la prise en charge de la connexion. Les serveurs lisent les requ etes sur leur entr ee standard et ecrivent la r eponse sur leur sortie standard. Inetd est un serveur parall` ele en mode connect e ou data-gramme. De plus il combine des caract eristiques particuli` eres, puisquil est egalement multiprotocoles et multi-services. Un m eme service peut y etre enregistr e et accessible en udp comme en tcp. Bien s ur cela sous entend que le programmeur de ce service ait pr evu ce fonctionnement. Le prix ` a payer pour une telle souplesse est elev e, inetd invoque fork puis exec pour pratiquement tous les services quil ore (cf lecture de code). Sur les Unix ` a architecture Berkeley, inetd est invoqu e au d emarrage de la machine, dans les scripts de lancement, /etc/rc par exemple. D` es le d ebut de son ex ecution il se transforme en daemon (cf paragraphe IV.5.3) et lit un

256

ements sur les serveurs El chier de conguration g en eralement nomm e /etc/inetd.conf. Ce chier est en ASCII, il est lisible normalement par tous, cependant, sur certains sites et pour des raisons de s ecurit e, il peut ne pas l etre. La gure XIII.04 montre larchitecture g en erale (tr` es simpli ee) de fonctionnement.

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 e de la mani` ere suivante : Un # en d ebut de ligne indique un commentaire, comme pour un shellscript. Les lignes vides ne sont pas prises en compte. Les lignes bien form ees sont constitu ees de 7 champs. Chaque ligne bien form ee d ecrit un serveur. Description des champs : 1. Le nom du service, qui doit egalement se trouver dans le chier /etc/services. Cest gr ace ` a lui que inetd connait le num ero de port ` a employer 2. Le type de socket, connect ee (stream) ou non (dgram).

Exemple de daemon inetd 3. Le protocole qui doit etre tcp ou udp et doit en tout cas se trouver dans le chier /etc/protocols. Ce dernier chier donne une correspondance num erique aux di erents protocoles. 4. wait ou nowait suivant que le serveur est it eratif ou parall` ele. 5. Le nom du propri etaire (pour les droits ` a lex ecution). Le plus souvent cest root, mais ce nest pas une r` egle g en erale. 6. Le chemin absolu pour d esigner lex ecutable du serveur. 7. Les arguments transmis ` a cet ex ecutable lors du exec, il y en a 20 au maximum dans les impl ementations Berkeley de inetd (certaines re- ecritures, comme celle dHP, limitent ce nombre).

257

258

ements sur les serveurs El

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 compr ehension des m ecanismes internes : 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 priv ee, 32 adresse IP publique, 32 AF, 202, voir Address Family AFNIC, voir Association Fran caise pour le Nommage Internet en Coop eration AfriNIC, 32 Algorithme concourant - Mode connect e, 241 Algorithme concourant - Mode datagramme, 240 algorithme de routage, voir routage Algorithme It eratif - Mode connect e, 240 Algorithme it eratif - Mode 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 Fran caise pour le Nommage Internet en Coop eration, 3 Authentication Header, 181 base de donn ees distribu ee, 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^ ete 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` es Internet fcntl, 246 FD CLR, 247 FD ISSET, 247, 248 FD SET, 247 FD ZERO, 247 fen^ etres glissantes, 92 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` es Internet, 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 exp erimentale, 34 de broadcast, 34, 38 multicast, 39--41 sous-r eseaux, 35--36 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 R eassemblage, 48 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 it eratif 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 e, 84, 203, 206, 208 datagramme, 77, 84, 203, 206 mode connect e, 238 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 num ero de port, 75, 200, 212, 219 num ero de service, voir num ero de port open mail relay, 136 openlog, 253 orderly release, 89 OSI 7 couches de l, 5 application, 5 donn ee, 9 donn ees, 5, 12 LLC, 12 MAC, 12 physique, 5 pr esentation, 5 r eseau, 5 session, 5, 27 transport, 5 OSPF, 37 ouverture active, 88 ouverture passive, 88 paires torsad ees, voir 10BaseT 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 num ero de port 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 r ep eteur, 16--17 r eseau dinterconnexion, 177 r eseau virtuel, 41 R eseaux IP europ een, 32 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 r ep eteur 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 R eseaux IP europ een

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 d ecouverte de routeurs, 68 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 it eratif, 237 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^ etres 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-r eseau 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 e de Berkeley, 23 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