2026-09-07 — Rôle de la couche Application
Contexte
Matière : _Reseaux · Type : cours · Source : Cours 07_09_2026 (notes brutes) + support Chapitre 2 — La couche Application (Partie 1) Précédent : 2026-09-04 — ARP et couche transport Suite : 2026-09-07 — Le protocole HTTP
🎯 Objectifs de la séance
- Comprendre les rôles distincts des couches 5, 6 et 7 du modèle OSI.
- Savoir pourquoi l’identification de session est indépendante des couches basses.
- Distinguer les deux architectures applicatives : client-serveur et pair-à-pair.
- Situer les grands protocoles applicatifs et leurs usages.
Partie 1 — Les couches hautes du modèle OSI
Le chapitre précédent s’arrêtait à la couche 4. Les couches 5, 6 et 7 sont celles qui donnent enfin un sens aux données transportées : la raison d’être du réseau, c’est de faire tourner des applications.
La couche 5 — Session : identifier l’utilisateur
Rôle de la couche session
Créer, maintenir et restaurer le dialogue entre l’application source et l’application destination. Elle gère la reprise des sessions interrompues ou inactives.
Le point clé du cours : la couche session permet d’identifier un utilisateur indépendamment des couches inférieures (MAC, IP, port).
Pourquoi c'est important
Si l’identité de l’utilisateur reposait sur son IP, tout changement d’adresse (Wi-Fi → 4G, bail DHCP renouvelé) casserait sa session. La couche 5 découple l’identité de l’adressage.
FTP vs HTTP — deux traitements opposés
| FTP | HTTP | |
|---|---|---|
| Couche session | Implémentée « comme il le juge approprié », voire omise | Gestion de session via cookies |
| Identification | S’appuie sur les infos des couches 3 et 4 (IP, port) | Identifiant applicatif (cookie) |
| Changement d’IP en cours de session | ⚠️ Reconnexion obligatoire | Session conservée |
À retenir
FTP n’a pas de mécanisme intrinsèque d’identification de session. HTTP, lui, est sans état au niveau protocole — mais reconstitue une session par-dessus, grâce aux cookies.
La couche 6 — Présentation : interpréter les 1 et les 0
Trois rôles, tous symétriques (une opération à l’émission, l’opération inverse à la réception) :
- Formatage — comment interpréter la série binaire : ASCII, Base64, hexadécimal, types MIME.
- Compression / décompression — réduire le volume transmis (
gzip,deflate). - Chiffrement / déchiffrement — protéger les données en transit (TLS).
Le formatage en une phrase
Convertir les données de la source dans un format compatible avec ce que sait interpréter la destination.
La couche 7 — Application : définir les commandes
Rôle de la couche 7
Elle détermine comment les caractères interprétés sont utilisés et définit les commandes au niveau applicatif.
Exemple canonique : en HTTP, la commande GET sert à demander et récupérer une page Web. C’est l’interface entre les applications et le réseau sous-jacent.
┌──────────────────────────────────────────────────┐
│ 7 — Application │ commandes (GET, POST…) │
├──────────────────────────────────────────────────┤
│ 6 — Présentation │ format · compression · chiffr.│
├──────────────────────────────────────────────────┤
│ 5 — Session │ identité utilisateur, dialogue│
├══════════════════════════════════════════════════┤
│ 4 — Transport │ ports, segments (TCP/UDP) │
└──────────────────────────────────────────────────┘
Partie 2 — Architectures applicatives
La communication au niveau applicatif repose sur deux architectures principales.
Client-serveur
Un serveur toujours disponible, avec une adresse fixe et connue, répond aux requêtes des clients. Les clients ne communiquent pas entre eux.
Pair-à-pair (P2P)
Pas de serveur central permanent : les hôtes communiquent directement entre eux, chacun étant à la fois client et serveur.
| Client-serveur | Pair-à-pair | |
|---|---|---|
| Serveur central | Oui, permanent | Aucun |
| Adressage | Serveur à adresse fixe | Pairs intermittents, adresses changeantes |
| Passage à l’échelle | Limité par le serveur | Croît avec le nombre de pairs |
| Point de défaillance | Le serveur | Réparti |
Les deux problèmes du P2P (vus en cours)
- Sécurité — pas d’autorité centrale pour valider les pairs ni le contenu échangé.
- Churn — quand un nœud entre ou sort du réseau, il doit prévenir tous les autres, ce qui génère un trafic de maintenance permanent.
Partie 3 — Les protocoles de la couche application
| Protocole | Rôle | Transport |
|---|---|---|
| DNS | Résout un nom de domaine → adresse IP | UDP (53) |
| DHCP | Attribue automatiquement IP, masque, passerelle et serveur DNS | UDP (67/68) |
| HTTP | Transfert de pages et d’objets Web | TCP (80) |
| HTTPS | HTTP chiffré par TLS | TCP (443) |
| FTP | Transfert de fichiers | TCP (20/21) |
| SMTP | Envoi de mail | TCP (25) |
| POP3 | Récupération de mail (téléchargement) | TCP (110) |
| IMAP | Consultation de mail (synchronisation serveur) | TCP (143) |
DHCP fournit quatre paramètres
IP · masque · passerelle par défaut · serveur DNS. C’est le quadruplet à citer en examen.
Le cas du mail : trois protocoles, deux rôles
PC 1 ──SMTP──▶ Serveur mail A ──SMTP──▶ Serveur mail B ──IMAP/POP3──▶ PC 2
(envoi) (relais) (récupération)
La règle simple
SMTP pousse le message (émetteur → serveurs → serveur destinataire). POP3 / IMAP tirent le message (serveur destinataire → client final). Le transfert entre serveurs se fait toujours en SMTP.
| POP3 | IMAP | |
|---|---|---|
| Principe | Télécharge puis supprime du serveur | Synchronise avec le serveur |
| Messages | Stockés localement | Restent sur le serveur |
| Multi-appareils | Mal adapté | Adapté |
⚠️ À retenir absolument (examen)
- Couche 5 = identification de l’utilisateur indépendamment de MAC/IP/port.
- FTP n’a pas de gestion de session · HTTP en a une (via cookies).
- Couche 6 = 3 rôles : formatage, compression, chiffrement (et leurs inverses).
- Couche 7 = définit les commandes applicatives (ex.
GET). - P2P : deux problèmes = sécurité et annonce à tout le réseau à chaque entrée/sortie de nœud.
- DHCP fournit IP + masque + passerelle + DNS.
- Mail = SMTP pour l’envoi et entre serveurs · POP3 / IMAP pour la réception.
❓ Points flous / à revoir
- Différence exacte entre URI et URN (le support ne montre que l’exemple
urn:isbn:) - Ports par défaut : les vérifier tous avant l’examen
- Cas concrets de protocoles P2P au programme (BitTorrent ? DHT ?)