La couche Application

La résolution de noms

Généralités - Fichiers HOSTS - DNS

Généralités

Sur un réseau TCP/IP les différents noeuds du réseaux (ordinateurs, routeurs, etc..) sont identifiés par une adresse Ip dont le format dans la version IPv4 est une suite binaire de 32 bits que l'on note généralement sous la forme de 4 entiers inférieurs à 256 séparés par des points, exemple : 192.14.25.251 (cf chapitre sur l'adressage).

Dès les débuts des réseaux TCP/IP, les utilisateurs ont rapidement pris conscience que ce type d'adressage était pratiquement impossible à mémoriser pour des individus normalement constitués. C'est la raison pour laquelle est apparue le sytème de noms de machine appelé FQDN : Full Qualified Domain Name. Par exemple : mamachine.service.masociete.fr

Remarque : Il ne faut pas confondre FQDN et URL (Uniform Ressource Locator). L'URL est la méthode d'accès à un document distant, un lien hypertexte par exemple, avec une syntaxe de la forme: <Type de connexion>://<FQDN>/[<sous-répertoire>]/.../<nom du document>. Exemple : http://mamachine.service.masociete.fr/cours/chapitre1.htm

Puisque le protocole TCP/IP ne connaît que des adresses IP, il faut donc disposer d'u mécanisme qui permette de traduire une adresse de type PQDN en adresse IP. Cette traduction est appelée résolution de noms. Elle peut se faire de 2 façons :

• Manuellement, par le biais des fichiers hosts
• En utilisant les services d'un DNS : Domain Name Server

Les Fichier HOSTS

A l'origine, les réseaux IP étaient peu étendus et le nombre de machines relativement faible, c'est pourquoi la première solution pour faire correspondre un FQDN avec une adresse IP fut d'utiliser sur chacune des machines du réseau, un fichier qui porte généralement le nom HOSTS et qui répertorie les paires (FQDN,adresse IP) connues et utiles.

Il va sans dire que ce système trouve tout de suite ses limites :

• Nécessité d'une mise à jour permanente impossible à réaliser dans le cadre d'un réseau comme internet
• Non prise en compte de la structure hiérarchique de l'adressage IP

Extrait d'un fichier hosts

Cette solution n'est donc plus utilisée que pour des cas très particulier de résolution de noms mais la méthode universellement utilisée est celle du serveur de noms ou DNS. Il faut tout de même remarquer que lorsqu'un nom doit être traduit en adresse FQDN, c'est tout d'abord le fichier hosts qui est consulté, si le nom n'est pas trouvé il est fait appel au serveur de noms, ce qui signifie que la méthode du fichier hosts peut permettre :

• D'accélérer la résolution de noms pour des noms utilisés fréquemment
• Bloquer l'accès à certains sites internet indésirables en redirigeant le nom sur l'adresse de loopback 127.0.0.1

Les DNS

A compléter...

L'allocation dynamique d'adresses

Généralités

Dans un réseau utilisant le protocole TCP/IP, chaque machine doit disposer d'une adresse IP. Cette adresse IP est généralement stockée (avec d'autres paramètres relatifs au protocole comme le masque, l'adresse de la passerelle par défaut) sur le disque dur de la machine. On parle dans ce cas d'adressage statique.

L'adressage IP statique présente un certain nombre d'inconvénients :

• La configuration doit se faire manuellement. Cette opération, même si elle est simple a réaliser, a donc non seulement un coût en terme de temps passé à réaliser cette opération mais comporte également un certain risque d'erreurs : mauvaise adresse, adresse dupliquée, erreur dans le masque, etc...
• Le gaspillage d'adresses. Sur un parc de n machines, il n'est pas toujours certain que ces n machines vont avoir besoin simultanément d'utiliser le protocole IP. C'est typiquement le problème des fournisseurs d'accès à internet qui possède un grand nombre de clients mais, à un instant donné, seul une proportion assez faible utilise internet.
• Une configuration rigide. La structure d'un réseau peut évoluer : ajout de nouvelles machines, interconnexion de réseaux, etc... Ceci est d'autant plus vrai si on utilise du matériel très mobile comme les ordinateurs portables. La configuration effectuée manuellement va dans ce cas pénaliser fortement la flexibilité du réseau et son adaptation rapide aux nouvelles contraintes.

L'adressage statique sera donc bien adapté à des réseaux de petite taille et qui évoluent peu, par contre pour les autres il sera plus intéressant de se tourner vers un mode d'allocation d'adresse dynamique.

Il existe 2 protocoles qui gèrent l'allocation dynamique d'adresses :

• BOOTP : C'est le plus ancien, il a été développé à l'origine pour le démarrage des stations sans disque.
• DHCP : C'est une extension du protocole BOOTP, plus souple dans sa gestion des adresses IP, c'est lui qui est utilisé à l'heure actuelle sur la plupart des configurations où une allocation dynamique d'adresses est mise en oeuvre.

DHCP

Le principe

DHCP signifie Dynamic Host Configuration Protocol. C'est un protocole de la couche Application qui utilise UDP et IP. Le principe de configuration dynamique repose sur un principe de Client / Serveur. Le client DHCP, pour obtenir une adresse IP va effectuer auprès d'un serveur DHCP un certain nombre de requêtes. Les adresses obtenues ne le sont généralement pas de façon définitive mais le sont pour une durée (durée de bail) prévues au niveau du serveur. Cette procédure s'effectue de la façon suivante :

• Le client en quête de configuration émet un datagramme spécifique (destiné au port 67 du serveur) via le protocole UDP destiné à tout serveur DHCP présent sur le réseau. Ce datagramme (DHCP DISCOVER) est de type diffusion c'est à dire qu'il est envoyé à l'adresse 255.255.255.255 (voir chapitre relatif à l'adressage IP). Dans ce datagramme figure l'adresse physique (adresse MAC) du client.
  
• Le client passe dans un état d'attente pendant lequel il attend qu'un serveur DHCP lui propose une adresse IP sur son port 68. Si un serveur DHCP est actif est dispose d'une adresse IP libre il va la proposer au client qui a fait la demande et lui faire une proposition sous la forme d'une trame DHCP OFFER. Cette trame peut être envoyée soit directement à l'adresse physique du client soit en mode broadcast.
  
• Lorsqu'il reçoit une adresse IP, le client peut éventuellement vérifier que cette adresse IP n'est pas déjà attribuée sur le réseau. Cette vérification peut se faire en envoyant une requête ARP à l'adresse indiquée (cf chapitre Résolution d'adresse). Ensuite le client peut accepter cette adresse (c'est généralement ce qui se passe...) ou la refuser. Si le client accepte cette adresse, il va diffuser un datagramme d'acceptation de cette adresse (DHCP REQUEST), ce qui a pour effet de réserver cette adresse et de prévenir les éventuels autres serveurs DHCP qui auraient répondu à la demande de ne pas donner suite. S'il existe plusieurs serveurs DHCP sur le réseau, c'est la première proposition valide d'adresse qui sera retenue.
  
• Le serveur DHCP constate que son offre a été retenue, il envoie donc un datagramme de confirmation (DHCP ACK) au client. Dans ce datagramme on trouve l'adresse IP bien sûr mais également le masque indispensable à la configuration, de manière optionnelle on peut également trouver l'adresse de la passerelle par défaut et la ou les adresses des DNS. A la réception de ces paramètres, le client va configurer sa pile IP avec les paramètres reçus et dans le même temps va armer 3 temporisateurs qui vont servir à la gestion du bail.

La gestion du bail

La plupart du temps la gestion des adresses IP par un serveur DHCP est faite en incluant la notion de bail, c'est à dire qu'une adresse IP sera allouée à un client pour une durée finie. Un client qui voit son bail arriver à terme peut demander au serveur un renouvellement du bail. De même, lorsque le serveur verra un bail arrivé à terme, il émettra un paquet pour demander au client s'il veut prolonger son bail. Si le serveur ne reçoit pas de réponse valide, il rend disponible l'adresse IP précédemment allouée.

Le bail est caractérisé par 3 temporisateurs :

• T3 : Durée totale du bail. Cette durée est fixée par le serveur et est transmise au client par l'intermédiaire du datagramme DHCP ACK.
• T1 : Temporisateur de renouvellement du bail. Cette durée est généralement égale à la moitié de T3, c'est la durée limite au terme de laquelle il faudra que le client ait effectué une demande de renouvellement de bail auprès du serveur.
• T2 : Temporisateur de rebinding. Il se peut que le client ait procédé à une demande de renouvellement de bail mais que le serveur n'ai pas répondu à cette demande de renouvellement pour des problèmes de dysfonctionnement de ce serveur ou des connexions avec celui-ci. A l'expiration de T2, le client va donc diffuser sur le réseau une demande de renouvellement de son adresse à l'intention de tous les serveurs DHCP éventuellement présent sur le réseau. Généralement T2 équivaut à peu près à 80 % de T3.

Toute la problématique dans la gestion d'un serveur DHCP vient justement du choix de la durée du bail. Un bail trop court va imposer un renouvellement fréquent avec toutes les mobilisations de ressources côté serveur et client que cela engendre ainsi que les messages véhiculés sur le réseau, d'autant plus que ces messages sont de type diffusion. A l'opposé, un bail trop long ne va pas permettre une gestion économe des adresses IP surtout dans un contexte où le réseau évolue beaucoup (ordinateurs portables par exemple).

Configuration d'un serveur DHCP

A compléter...

Le protocole HTTP

A faire...

Transfert de fichiers

FTP

A faire...

TFTP

A faire...

Les applications utilisant TCP/IP

TELNET

SMTP

SNMP

RPC

NFS