Vous êtes sur la page 1sur 19

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 ;

1
 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.

2
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

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

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

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

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

7
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

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

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

10
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

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

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

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

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

15
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

16
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

17
(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.

18
Figure 16 : Interrogation et réponse des homologues

19