1

Chapitre 3 :

Fonctionnement et protocoles des couches applicatives

Introduction La plupart d’entre nous utilisons Internet via le Web, les services de messagerie et les programmes de

partage de fichiers. Ces applications, ainsi que de nombreuses autres, constituent l’interface humaine

entre l’utilisateur et le réseau sous-jacent et nous permettent d’envoyer et de recevoir des informations

avec une relative facilité. Un professionnel des réseaux doit savoir dans quelle mesure une application

est capable de formater, de transmettre et d’interpréter les messages envoyés et reçus via le réseau.

Le modèle Open System Interconnection (OSI) permet de visualiser plus facilement les mécanismes

sous-jacents de la communication via le réseau (voir figure 1). Ce chapitre porte sur le rôle d’une

couche, la couche application, et de ses composants :

1. applications,

2. services,

3. protocoles.

Nous examinerons comment ces trois éléments permettent une communication robuste via le réseau

d’informations.

Figure 1 : La couche applicative du modèle OSI

Objectifs Dans ce chapitre, vous apprendrez à :

décrire comment les fonctions des trois couches supérieures du modèle OSI fournissent des

services de réseau aux applications destinées à l’utilisateur final ;

2

décrire comment les protocoles de la couche application TCP/IP fournissent les services spécifiés

par les couches supérieures du modèle OSI ;

définir comment les utilisateurs se servent de la couche application pour communiquer via le

réseau d’informations ;

décrire le fonctionnement d’applications TCP/IP très courantes, telles que le Web et le courrier

électronique et les services associés;

expliquer comment, grâce aux protocoles, les services exécutés sur un type de périphérique

peuvent envoyer des données vers de nombreux périphériques réseau différents et recevoir des

données de ces périphériques ;

3.1 Application : l’interaction entre les réseaux

3.1.1 Modèle OSI et TCP/IP Le modèle de référence OSI est une représentation abstraite en couches servant de guide à la

conception des protocoles réseau. Il divise le processus de réseau en sept couches logiques, chacune

comportant des fonctionnalités uniques et se voyant attribuer des services et des protocoles

spécifiques.

Dans ce modèle, les informations sont transmises d’une couche à l’autre, en commençant au niveau de

la couche application sur l’hôte émetteur (voir figure 2), puis en descendant dans la hiérarchie jusqu’à la

couche physique, pour ensuite transiter sur le canal de communication vers l’hôte de destination, où les

informations remontent la hiérarchie jusqu’à la couche application.

Figure 2 : Transmission de l’information d’une couche à l’autre selon le modèle OSI

La couche application (couche 7) est la couche supérieure des modèles OSI et TCP/IP. Elle est la couche

qui sert d’interface entre les applications que nous utilisons pour communiquer et le réseau sous-jacent

via lequel nos messages sont transmis. Les protocoles de couche application sont utilisés pour échanger

des données entre les programmes s’exécutant sur les hôtes source et de destination. Il existe de

nombreux protocoles de couche application et de nouveaux protocoles sont constamment en cours de

développement.

3

Bien que la suite de protocoles TCP/IP ait été développée avant la définition du modèle OSI, les

fonctionnalités des protocoles de couche application TCP/IP s’intègrent à la structure des trois couches

supérieures du modèle OSI (voir figure 3):

La couche application,

La couche présentation,

La couche session.

Figure 3 : Correspondance entre modèle OSI et TCP/IP

La couche présentation

La couche présentation remplit trois fonctions principales :

1. codage et conversion des données de la couche application afin que les données issues du

périphérique source puissent être interprétées par l’application appropriée sur le périphérique

de destination ;

2. compression des données de sorte que celles-ci puissent être décompressées par le

périphérique de destination ;

3. chiffrement des données en vue de leur transmission et déchiffrement des données reçues par

le périphérique de destination.

Couche session

Comme l’implique le nom de la couche session, les fonctions s’exécutant au niveau de cette couche

permettent un dialogue entre les applications source et de destination. La couche session traite

l’échange des informations pour initier et maintenir un dialogue et pour redémarrer les sessions

interrompues ou inactives pendant une longue période.

Les protocoles de couche application TCP/IP les plus connus sont ceux permettant l’échange

d’informations entre les utilisateurs. Ces protocoles spécifient les informations de format et de contrôle

4

nécessaires à un grand nombre de fonctions courantes de communication via Internet. Voici certains de

ces protocoles TCP/IP :

Le protocole DNS (Domain Name Service) est utilisé pour traduire les adresses Internet en

adresses IP.

Le protocole HTTP (Hypertext Transfer Protocol) est utilisé pour transférer les fichiers qui

constituent les pages du Web.

Le protocole SMTP (Simple Mail Transfer Protocol) est utilisé pour transférer les courriels et les

pièces jointes.

Le protocole Telnet, protocole d’émulation de terminal, est utilisé pour permettre un accès

distant aux serveurs et aux périphériques réseau.

Le protocole FTP (File Transfer Protocol) est utilisé pour le transfert interactif de fichiers entre

les systèmes.

3.1.2 Logiciels de la couche application Les fonctions associées aux protocoles de couche application permettent au réseau des utilisateurs de

faire une interface avec le réseau de données sous-jacent. Lorsque l’utilisateur ouvre un navigateur Web

ou une fenêtre de messagerie instantanée, une application est lancée et le programme est placé dans la

mémoire du périphérique, où il est exécuté. Chaque programme en cours d’exécution chargé sur un

périphérique est nommé processus.

La couche application comprend deux formes de programmes ou processus logiciels permettant

d’accéder au réseau : les applications et les services.

Applications orientées réseau

Les applications sont les programmes logiciels qui permettent aux utilisateurs de communiquer sur le

réseau. Certaines applications destinées à l’utilisateur final sont orientées réseau, à savoir qu’elles

implémentent les protocoles de couche application et sont capables de communiquer directement avec

les couches inférieures de la pile de protocoles. Les clients de messagerie et les navigateurs Web sont

des exemples de ces types d’applications.

Services de couche application

D’autres programmes peuvent nécessiter l’assistance des services de couche application (par exemple,

le transfert de fichiers ou la mise en file d’attente de tâches d’impression réseau). Bien que transparents

pour l’utilisateur, ces services constituent les programmes qui établissent l’interface avec le réseau et

préparent les données à transférer.

Chaque application ou service réseau utilise des protocoles qui définissent les normes et les formats de

données à utiliser. Sans protocoles, le réseau de données ne disposerait d’aucune méthode commune

pour formater et transmettre les données.

5

3.1.3 Applications utilisateurs, services et protocoles de la couche application Comme mentionné précédemment, la couche application utilise des protocoles implémentés au sein

d’applications et de services. Alors que les applications permettent aux utilisateurs de créer des

messages et que les services de couche application établissent une interface avec le réseau, les

protocoles fournissent les règles et les formats qui régissent la manière dont les données sont traitées.

Ces trois composants peuvent être utilisés par le même programme exécutable et peuvent même porter

le même nom. Par exemple, « Telnet » peut faire référence à l’application, au service ou au protocole.

Dans le modèle OSI, les applications qui interagissent directement avec les utilisateurs sont considérées

comme étant au sommet de la pile. De même que toutes les couches au sein du modèle OSI, la couche

application fait appel aux fonctions des couches inférieures pour terminer le processus de

communication. Au sein de la couche application, les protocoles indiquent quels messages sont

échangés entre les hôtes source et de destination, la syntaxe des commandes de contrôle, le type et le

format des données transmises et les méthodes appropriées de notification et de correction des

erreurs.

3.1.4 Fonctions du protocole de couche application Les protocoles de couche application sont utilisés par les périphériques source et de destination

pendant une session de communication. Pour que les communications aboutissent, les protocoles de

couche application implémentés sur les hôtes source et de destination doivent correspondre (voir figure

4).

Figure 4 : Correspondance des protocoles de la couche application

Les protocoles établissent des règles cohérentes pour échanger des données entre les applications et les

services chargés sur les périphériques concernés.

Ils indiquent la manière dont les données figurant dans les messages sont structurées et le type des

messages envoyés entre les hôtes source et de destination. Ces messages peuvent être des requêtes de

services, des reçus, des messages de données, des messages d’état ou des messages d’erreur. Les

protocoles définissent également les dialogues au niveau des messages et assurent qu’un message

envoyé reçoit la réponse prévue et que les services appropriés sont invoqués lorsque se produit un

transfert de données.

6

3.2 Utilisation des applications et des services

3.2.1 Modèle client serveur Lorsque l’utilisateur tente d’accéder aux informations situées sur son périphérique, qu’il s’agisse d’un

PC, d’un ordinateur portable, d’un assistant numérique personnel, d’un téléphone portable ou autre

périphérique connecté au réseau, les données peuvent ne pas être stockées sur ce périphérique. Dans

ce cas, une requête d’accès aux informations doit être adressée au niveau du périphérique sur lequel

résident les données.

Dans le modèle client/serveur, le périphérique demandant les informations est nommé client et celui

répondant à la demande est nommé serveur. Les processus client et serveur sont considérés comme

faisant partie de la couche application. Le client commence l’échange en demandant des données au

serveur, qui répond en envoyant un ou plusieurs flux de données au client. Les protocoles de couche

application décrivent le format des requêtes et des réponses entre clients et serveurs. Outre le transfert

de données effectif, cet échange peut également nécessiter des informations de contrôle, telles que

l’authentification de l’utilisateur et l’identification d’un fichier de données à transférer.

3.2.2 Serveurs Dans un contexte général de réseau, un périphérique qui répond à des requêtes émanant d’applications

clientes opère en tant que serveur. Un serveur est généralement un ordinateur qui contient des

informations à partager avec de nombreux systèmes clients. Par exemple, les pages Web, les

documents, les bases de données, les images, les fichiers vidéo et les fichiers audio peuvent tous être

stockés sur un serveur et transmis à des clients demandeurs.

Dans un réseau client/serveur, le serveur exécute un service, ou processus, parfois nommé démon de

serveur (voir figure 5).

3.2.3 Services et protocoles de la couche application Les serveurs comportent généralement plusieurs clients demandant des informations en même temps.

Par exemple, un serveur peut comporter de nombreux clients demandant à se connecter à ce serveur

(voir figure 5). Ces requêtes de client individuelles doivent être traitées simultanément et séparément

pour que le réseau fonctionne correctement. Les processus et les services de la couche application sont

assistés par les fonctions des couches inférieures pour gérer correctement les conversations multiples.

7

Figure 5: Plusieurs clients se connectent au même serveur

3.2.4 Réseau et applications pear to pear (P2P)

Modèle Peer to Peer

Outre le modèle de réseau client/serveur, il existe également un modèle Peer to Peer. Le réseau Peer to

Peer implique deux formes différentes : la conception de réseau Peer to Peer et les applications Peer to

Peer (P2P). Les deux formes comportent des caractéristiques similaires mais, dans les faits, fonctionnent

très différemment.

Réseaux Peer to Peer

Dans un réseau Peer to Peer, au minimum deux ordinateurs sont connectés via un réseau et peuvent

partager des ressources (par exemple, des imprimantes et des fichiers) sans disposer de serveur dédié

(voir figure 6). Chaque périphérique final connecté (nommé homologue) peut opérer en tant que

serveur ou en tant que client. Un ordinateur peut remplir le rôle d’un serveur pour une transaction et

d’un client pour une autre transaction. Les rôles de client et de serveur sont définis en fonction de

chaque requête.

8

Figure 6 : Réseaux Peer to Peer

Par exemple, un réseau domestique simple connectant deux ordinateurs qui partagent une imprimante

est un réseau Peer to Peer. Chaque utilisateur peut configurer son ordinateur pour partager des fichiers,

exécuter des jeux en réseau...

Applications Peer to Peer

Figure 7 : Messagerie instantanée est une application P2P

Une application Peer to Peer (P2P), contrairement à un réseau Peer to Peer, permet à un périphérique

d’opérer à la fois comme client et comme serveur au sein d’une même communication (voir figure 7).

Dans ce modèle, chaque client est un serveur et chaque serveur un client. Les deux peuvent lancer une

communication et sont considérés comme égaux dans le processus de communication. Cependant, les

applications P2P nécessitent que chaque périphérique final fournisse une interface utilisateur et exécute

un service en tâche de fond. Lorsque vous lancez une application P2P spécifique, elle invoque l’interface

9

utilisateur et les services en tâche de fond requis. Les périphériques peuvent ensuite communiquer

directement.

Les applications P2P peuvent être utilisées sur des réseaux Peer to Peer, des réseaux client/serveur et

via Internet.

3.3 Exemples de services et protocoles de la couche application

3.3.1 Services et protocoles DNS (Domain Name System) À présent que nous savons mieux comment les applications fournissent une interface à l’utilisateur et

permettent d’accéder au réseau, nous allons examiner certains protocoles spécifiques courants.

Comme nous allons le voir par la suite dans ce cours, la couche transport utilise un modèle d’adressage

nommé numéro de port. Les numéros de port identifient les applications et les services de la couche

application qui constituent la source et la destination des données. Les programmes serveur utilisent

généralement des numéros de port prédéfinis connus des clients. En examinant les différents protocoles

et services de couche application TCP/IP, nous nous référerons aux numéros de port TCP et UDP

normalement associés à ces services. Certains de ces services sont les suivants :

DNS (Système de noms de domaine) - Port TCP/UDP 53

HTTP (Hypertext Transfer Protocol) - Port TCP 80

SMTP (Simple Mail Transfer Protocol) - Port TCP 25

POP (Post Office Protocol) - Port UDP 110

Telnet - Port TCP 23

DHCP (Dynamic Host Configuration Protocol) - Port UDP 67

FTP (File Transfer Protocol) - Ports TCP 20 et 21

DNS

Sur les réseaux de données, les périphériques sont étiquetés par des adresses IP numériques, ce qui leur

permet de participer à l’envoi et à la réception de messages via le réseau. Cependant, la plupart des

utilisateurs mémorisent très difficilement ces adresses numériques. Pour cette raison, des noms de

domaine ont été créés pour convertir les adresses numériques en noms simples et explicites.

Sur Internet, ces noms de domaine (par exemple, www.cisco.com) sont beaucoup plus faciles à

mémoriser que leurs équivalents numériques (par exemple, 198.133.219.25, l’adresse numérique du

serveur de Cisco). De plus, si Cisco décide de changer d’adresse numérique, ce changement est

transparent pour l’utilisateur car le nom de domaine demeure www.cisco.com.

10

Figure 8 : Fonctionnement du protocole DNS

Le protocole DNS a été créé afin de permettre la résolution de nom pour ces réseaux. Le protocole DNS

utilise un ensemble distribué de serveurs pour convertir les noms associés à ces adresses en numéros.

Le protocole DNS est un service client/serveur. Cependant, il diffère des autres services client/serveur

examinés dans ce cours. Les autres services utilisent un client qui constitue une application (par

exemple, un navigateur Web ou un client de messagerie) tandis que le client DNS s’exécute en tant que

service lui-même. Le client DNS, parfois nommé résolveur DNS, prend en charge la résolution de noms

pour nos autres applications réseau et pour les autres services qui en ont besoin.

Un serveur DNS effectue la résolution des noms à l’aide du démon de nom, souvent appelé named

(name daemon).

Lorsqu’un client effectue une demande, le processus de démon de nom du serveur examine d’abord ses

propres enregistrements pour voir s’il peut résoudre le nom (voir figure 8). S’il ne peut pas résoudre le

nom à l’aide de ses enregistrements stockés, il contacte d’autres serveurs pour résoudre le nom (voir

figure 9).

La requête peut être transmise à plusieurs serveurs, ce qui peut nécessiter un délai supplémentaire et

consommer de la bande passante. Lorsqu’une correspondance est trouvée et retournée au serveur

demandeur d’origine, le serveur stocke temporairement dans le cache l’adresse numérique

correspondant au nom.

11

Si ce même nom est de nouveau demandé, le premier serveur peut retourner l’adresse en utilisant la

valeur stockée dans son cache de noms. La mise en cache réduit le trafic réseau de données de

demandes DNS et les charges de travail des serveurs situés aux niveaux supérieurs dans la hiérarchie. Le

service client DNS sur les PC Windows optimise les performances de la résolution de noms DNS en

stockant également en mémoire les noms déjà résolus.

Le protocole DNS utilise un système hiérarchique pour créer une base de données afin d’assurer la

résolution de noms. La hiérarchie ressemble à une arborescence inversée dont la racine se situe au

sommet et les branches en dessous (Figure 9).

Figure 9 : Hiérarchie des serveurs DNS

Les différents domaines de premier niveau représentent le type d’organisation ou le pays d’origine.

Voici des exemples de domaines de premier niveau :

.au : Australie

.co : Colombie

.com : entreprise ou industrie

.jp : Japon

.org : organisme à but non lucratif

12

3.3.2 Services WWW et HTTP Lorsqu’une adresse Web (ou URL Uniform Resource Locator) est tapée dans un navigateur Web, ce

dernier établit une connexion au service Web s’exécutant sur le serveur à l’aide du protocole HTTP. Les

URL sont les noms que la plupart des utilisateurs associent aux adresses Web.

Figure 10 : Fonctionnement du protocole HTTP

Par exemple, http://www.cisco.com/index.html est une adresse URL qui se réfère à une ressource

spécifique : une page Web nommée index.html située sur le serveur cisco.com (voir figure 10).

Les navigateurs Web sont les applications clientes que les ordinateurs utilisent pour se connecter au

Web et accéder aux ressources stockées sur un serveur Web. Comme avec la plupart des processus

serveur, le serveur Web s’exécute en tant que service en tâche de fond et met différents types de

fichiers à la disposition de l’utilisateur.

Pour accéder au contenu Web, les clients Web établissent des connexions au serveur et demandent les

ressources voulues. Le serveur retourne les ressources et, à la réception de ces ressources, le navigateur

interprète les données et les présente à l’utilisateur.

Les navigateurs peuvent interpréter et présenter de nombreux types de données, tels que des données

en texte clair ou HTML (Hypertext Markup Language), langage dans lequel sont conçues les pages Web.

Pour mieux comprendre l’interaction entre le navigateur Web et le client Web, voyons comment une

page Web s’ouvre dans un navigateur. Cet exemple utilise l’adresse URL suivante :

http://www.cisco.com/index.html.

13

Le navigateur commence par interpréter les trois parties de l’adresse URL :

1. http (protocole ou modèle)

2. www.cisco.com (nom du serveur)

3. index.html (nom du fichier demandé).

Le navigateur fait ensuite appel à un serveur DNS pour convertir l’adresse www.cisco.com en une

adresse numérique, qu’il utilise pour se connecter au serveur. À l’aide des caractéristiques du protocole

HTTP, le navigateur envoie une requête GET au serveur et demande le fichier index.html. En réponse, le

serveur envoie le code HTML de cette page Web au navigateur. Enfin, le navigateur déchiffre le code

HTML et formate la page en fonction de sa fenêtre.

Le protocole HTTP constitue un protocole de requête/réponse. Lorsqu’un client (généralement un

navigateur Web) envoie une requête à un serveur, le protocole HTTP définit les types de messages que

le client utilise pour demander la page Web, ainsi que les types de messages que le serveur utilise pour

répondre. Les trois types de messages courants sont GET, POST et PUT.

GET est une requête cliente pour obtenir des données. Un navigateur Web envoie le message GET pour

demander des pages à un serveur Web.

Les requêtes POST et PUT sont utilisées pour envoyer des messages qui téléchargent des données vers

le serveur Web. Par exemple, lorsque l’utilisateur entre des données dans un formulaire incorporé à une

page Web, la requête POST comprend les données dans le message envoyé au serveur.

Bien qu’il soit remarquablement flexible, le protocole HTTP n’est pas un protocole sécurisé. Les

messages POST téléchargent des informations vers le serveur dans un format de texte clair pouvant être

intercepté et lu. De même, les réponses du serveur (généralement, des pages HTML) ne sont pas

chiffrées.

Pour une communication sécurisée via Internet, le protocole HTTPS (HTTP Secure) est utilisé lors de

l’accès aux informations du serveur Web ou de leur publication. Le protocole HTTPS peut procéder à

l’authentification et au chiffrement pour sécuriser les données pendant qu’elles circulent entre le client

et le serveur.

3.3.3 Services de messagerie et protocoles SMTP et POP La messagerie électronique, le service de réseau le plus répandu, par sa simplicité et sa vitesse

d’exécution, a révolutionné la manière dont nous communiquons. Mais pour s’exécuter sur un

ordinateur ou autre périphérique final, une messagerie nécessite plusieurs applications et services. Les

protocoles POP (Post Office Protocol) et SMTP (Simple Mail Transfer Protocol), illustrés dans la figure 11,

sont deux exemples de protocoles de couche application. Tout comme le protocole HTTP, ces protocoles

définissent des processus client/serveur.

14

Figure 11 : Protocoles SMTP et POP

Lorsque l’utilisateur rédige un courriel, il fait généralement appel à une application connue sous le nom

d'agent de messagerie (MUA), ou client de messagerie. L’agent de messagerie permet l’envoi des

messages et place les messages reçus dans la boîte aux lettres du client, ces deux processus étant des

processus distincts.

Pour recevoir le courriel d’un serveur de messagerie, le client de messagerie peut utiliser le protocole

POP. L’envoi de courriel à partir d’un client ou d’un serveur implique l’utilisation de commandes et de

formats de messages définis par le protocole SMTP. Un client de messagerie fournit généralement les

fonctionnalités des deux protocoles au sein d’une application.

Processus de serveur de messagerie : MTA et MDA

Le serveur de messagerie opère deux processus distincts :

1. Agent de transfert des messages (MTA).

2. Agent de remise des messages (MDA).

Le processus MTA est utilisé pour transférer le courriel. Comme l’illustre la figure 12, l’agent de transfert

des messages reçoit des messages de l’agent de messagerie ou d’un autre agent de transfert des

messages sur un autre serveur de messagerie. En fonction de l’en-tête du message, il détermine la

manière dont un message doit être transmis pour arriver à destination. Si le message est adressé à un

utilisateur dont la boîte aux lettres réside sur le serveur local, le message est transmis à l’agent de

remise des messages (MDA). Si le message est adressé à un utilisateur ne se situant pas sur le serveur

local, l’agent de transfert des messages l’achemine vers l’agent de transfert des messages du serveur

approprié.

Dans la figure 12, l’agent de remise des messages (MDA) accepte un courriel d’un agent de transfert des

messages (MTA) et procède à la remise effective du courriel. L’agent de remise des messages reçoit tous

les messages entrants de l’agent de transfert des messages et les place dans la boîte aux lettres des

utilisateurs appropriés. Il peut également traiter les derniers aspects liés à la remise, tels que l’analyse

antivirus, le filtrage du courrier indésirable et la gestion des reçus. La plupart des communications par

courriel utilisent les applications MUA, MTA et MDA.

15

Figure 12 : Applications MUA, MTA et MDA

Un client peut être connecté à un système de messagerie d’entreprise, tel que Lotus Notes d’IBM,

Groupwise de Novell ou Exchange de Microsoft. Ces systèmes disposent souvent de leur propre format

de messagerie interne et leurs clients communiquent généralement avec le serveur de messagerie à

l’aide d’un protocole propriétaire.

Autre alternative : les ordinateurs ne disposant pas d’un agent de messagerie peuvent encore se

connecter à un service de messagerie sur un navigateur Web pour récupérer et envoyer des messages

de cette manière.

Comme indiqué précédemment, le courriel peut utiliser les protocoles POP et SMTP. Les protocoles POP

et POP3 (Post Office Protocol, version 3) sont des protocoles de remise du courrier entrant et

constituent des protocoles client/serveur standard. Ils transmettent le courriel du serveur de messagerie

au client de messagerie. L’agent de remise des messages (MDA) procède à une écoute pour détecter le

moment où un client se connecte à un serveur. Une fois qu’une connexion est établie, le serveur peut

remettre le courriel au client.

Par ailleurs, le protocole SMTP (Simple Mail Transfer Protocol) régit le transfert du courriel sortant du

client expéditeur au serveur de messagerie (MDA), ainsi que le transport du courriel entre les serveurs

de messagerie (MTA). Le protocole SMTP permet le transport du courriel sur des réseaux de données

entre différents types de logiciels serveur et client, ainsi que l’échange de courriel via Internet.

Le format de message du protocole SMTP utilise un ensemble rigide de commandes et de réponses. Ces

commandes prennent en charge les procédures du protocole SMTP, telles que l’ouverture de session, la

transaction du courriel, le transfert du courriel, la vérification des noms de boîte aux lettres, le

développement des listes de diffusion et les échanges de début et de fin.

16

Certaines des commandes spécifiées dans le protocole SMTP sont les suivantes :

HELO : identifie le processus client SMTP pour le processus serveur SMTP.

MAIL FROM : identifie l’expéditeur.

RCPT TO : identifie le destinataire.

DATA : identifie le corps du message.

3.3.4 Services de téléchargement de fichiers et le protocole FTP Le protocole FTP (File Transfer Protocol) est un autre protocole de couche application couramment

utilisé. Il a été développé pour permettre le transfert de fichiers entre un client et un serveur. Un client

FTP est une application s’exécutant sur un ordinateur et utilisée pour extraire des fichiers d’un serveur

exécutant le démon FTP (FTPd).

Figure 13 : Fonctionnement du protocole FTP

Pour transférer les fichiers correctement, le protocole FTP nécessite que deux connexions soient

établies entre le client et le serveur : une connexion pour les commandes et les réponses et une autre

pour le transfert même des fichiers (voir figure 13).

Le client établit la première connexion au serveur sur le port TCP 21. Cette connexion est utilisée pour le

trafic de contrôle et se compose de commandes clientes et de réponses serveur.

Le client établit la seconde connexion au serveur via le port TCP 20. Cette connexion est destinée au

transfert même des fichiers et est établie à chaque transfert de fichiers.

Le transfert de fichiers peut s’effectuer dans l’une des deux directions. Le client peut télécharger un

fichier à partir du serveur ou en direction du serveur.

3.3.5 Service DHCP Le service DHCP (Dynamic Host Configuration Protocol) permet aux périphériques d’un réseau d’obtenir

d’un serveur DHCP des adresses IP et autres informations. Il permet à un hôte d’obtenir une adresse IP

17

dynamiquement lorsqu’il se connecte au réseau. Le serveur DHCP est contacté et une adresse est

demandée. Le serveur DHCP choisit une adresse dans une plage d’adresses configurée (nommée pool)

et affecte cette adresse à l’hôte pour une durée définie.

Sur les réseaux locaux ou sur les réseaux dont les utilisateurs changent fréquemment, le protocole DHCP

est préférable. De nouveaux utilisateurs peuvent se présenter travaillant sur des ordinateurs portables

et nécessitant une connexion. D’autres peuvent disposer de nouvelles stations de travail devant être

connectées. Plutôt que de faire attribuer des adresses IP par l’administrateur réseau à chaque station de

travail, il est plus efficace que les adresses IP soient attribuées automatiquement à l’aide du protocole

DHCP.

Le protocole DHCP vous permet d’accéder à Internet via des points d’accès sans fil dans des aéroports

ou des cafés. Lorsque vous pénétrez dans la zone, le client DHCP de votre ordinateur portable contacte

le serveur DHCP local via une connexion sans fil. Le serveur DHCP attribue une adresse IP à votre

ordinateur portable.

Les adresses attribuées via le protocole DHCP ne sont pas affectées aux hôtes définitivement mais

uniquement pour une durée spécifique. Si l’hôte est mis hors tension ou retiré du réseau, l’adresse est

retournée au pool pour être réutilisée.

Comme l’illustre la figure 14, dans la plupart des réseaux de taille moyenne à grande, le serveur DHCP

est généralement un serveur local dédié basé sur un PC.

Dans le cas des réseaux domestiques, il est généralement situé au niveau du fournisseur de services

Internet et un hôte sur le réseau domestique reçoit directement sa configuration IP du fournisseur de

services Internet.

Figure 14 : Position des serveurs DHCP dans le réseau

Sans le protocole DHCP, les utilisateurs doivent manuellement entrer l’adresse IP. Les adresses IP étant

des adresses dynamiques (temporairement attribuées) et non pas des adresses statiques

18

(définitivement attribuées), les adresses qui ne sont plus utilisées sont automatiquement retournées au

pool pour être réattribuées. Lorsqu’un périphérique configuré pour le protocole DHCP est mis sous

tension ou se connecte au réseau, le client diffuse un paquet DHCP DISCOVER pour identifier les

serveurs DHCP disponibles du réseau. Un serveur DHCP répond avec un paquet DHCP OFFER, à savoir un

message d’offre de bail qui indique une adresse IP attribuée, et autres informations.

Le serveur DHCP s’assure que toutes les adresses IP sont uniques (une adresse IP ne peut pas être

attribuée à deux périphériques réseaux différents en même temps). Le protocole DHCP permet aux

administrateurs réseau de reconfigurer aisément les adresses IP des clients sans devoir apporter de

modifications manuelles aux clients. La plupart des fournisseurs Internet utilisent un protocole DHCP

pour attribuer des adresses à leurs clients ne nécessitant pas d’adresse statique.

3.3.6 Services pear to pear et protocole Gnutella Vous avez appris que le protocole FTP constitue une méthode permettant d’obtenir des fichiers. Voici

maintenant un autre protocole d’application. Partager des fichiers via Internet est devenu très courant.

Avec les applications Peer to Peer basées sur le protocole Gnutella, les utilisateurs peuvent mettre les

fichiers situés sur leur disque dur à la disposition des autres utilisateurs pour que ces derniers les

téléchargent. Les logiciels clients compatibles avec le protocole Gnutella permettent aux utilisateurs de

se connecter aux services Gnutella via Internet et de localiser des ressources partagées par d’autres

homologues Gnutella pour y accéder.

De nombreuses applications clientes sont disponibles pour permettre aux utilisateurs d’accéder au

réseau Gnutella, parmi lesquelles : BearShare, Gnucleus, LimeWire, Morpheus, WinMX et XoloX

(reportez-vous à la capture d’écran de LimeWire présentée dans la figure 15).

Figure 15 : Capture d’écran de LimeWire

De nombreuses applications Peer to Peer n’utilisent pas de base de données centrale pour enregistrer

tous les fichiers disponibles sur les homologues. À la place, chaque périphérique du réseau, lorsqu’il est

interrogé, indique aux autres périphériques quels fichiers sont disponibles et utilise le protocole et les

services Gnutella pour prendre en charge la localisation des ressources. Reportez-vous à la figure 16.

19

Figure 16 : Interrogation et réponse des homologues