Couche application

Nous voici au sommet de la pile, celui que vous utilisez sans y penser à chaque instant. Les sept chapitres précédents ont construit un tuyau fiable et mondial ; la couche application est ce que les programmes en font. Quand vous chargez une page web, une chorégraphie invisible se déclenche en une fraction de seconde : votre machine obtient une adresse (DHCP), traduit le nom du site en adresse IP (DNS), établit une connexion (TCP, chapitre 7) et demande la page (HTTP). Ce chapitre démonte cette chorégraphie.

C'est aussi le chapitre où l'on voit converger tout le cours : chaque service applicatif s'appuie sur les couches du dessous, et fait un choix — TCP ou UDP, tel port, tel protocole — qu'on sait désormais interpréter.

Le modèle client-serveur

La plupart des applications réseau suivent le modèle client-serveur. Le serveur attend passivement, à l'écoute sur un port connu (chapitre 7) ; le client prend l'initiative, se connecte, envoie une requête, reçoit une réponse. Votre navigateur est un client, le site un serveur ; votre application de courriel est un client, le serveur de messagerie un serveur.

Ce modèle est asymétrique par nature : le serveur doit être joignable en permanence à une adresse stable (d'où l'importance du DNS, plus bas), le client peut apparaître et disparaître. Il existe d'autres organisations — le pair-à-pair, où chaque machine est à la fois client et serveur — mais le client-serveur reste le modèle dominant, et celui de tous les services de ce chapitre.

DNS : traduire les noms en adresses

Vous tapez www.exemple.fr, mais le routage (chapitre 6) ne connaît que des adresses IP. Le DNS (Domain Name System) fait le pont : il traduit les noms en adresses. C'est l'annuaire d'Internet — et l'une des idées les plus élégantes du réseau.

Sa force est qu'il n'existe aucun annuaire central. Le DNS est une base de données distribuée et hiérarchique, lue de droite à gauche :

1www . exemple.fr .2 │      │      └── géré par les serveurs racines3 │      └───────── géré par les serveurs du TLD « .fr »4 └──────────────── géré par les serveurs du domaine « exemple.fr »

Résoudre un nom, c'est descendre cette hiérarchie : demander à un serveur racine où trouver .fr, puis au serveur .fr où trouver exemple.fr, puis au serveur du domaine l'adresse de www. Chaque niveau ne connaît que le suivant — cette délégation est ce qui permet au système de gérer des milliards de noms sans effondrement.

Deux points pratiques essentiels. D'abord, le cache : les réponses sont mémorisées (pour une durée, le TTL), sinon chaque clic redemanderait toute la chaîne aux serveurs racines, qui s'effondreraient sous la charge mondiale. Ensuite, le protocole : le DNS emploie surtout UDP (chapitre 7) — question courte, réponse courte, rapidité prioritaire, et on redemande si une réponse se perd. C'est exactement le profil pour lequel UDP existe. L'exercice de ce chapitre vous fera dérouler cette résolution, cache compris.

HTTP et HTTPS : le web

HTTP (HyperText Transfer Protocol) est le protocole du web, sur le port 80. Il est client-serveur et requête-réponse : le navigateur envoie une requête (GET /index.html, « donne-moi cette page »), le serveur renvoie une réponse (la page, précédée d'un code de statut : 200 succès, 404 introuvable, 500 erreur serveur, 301 déplacé). HTTP repose sur TCP (chapitre 7) : le web exige que la page arrive complète et dans l'ordre, c'est le profil « fiabilité avant tout ».

HTTPS est HTTP chiffré, sur le port 443. Il ajoute une couche de sécurité (TLS) entre TCP et HTTP, qui chiffre les échanges et authentifie le serveur — vous parlez bien au site annoncé, et personne sur le chemin ne peut lire ni modifier le contenu. C'est aujourd'hui le standard : le web non chiffré disparaît. Retenez la distinction : HTTP transporte en clair, HTTPS chiffre en transit — la première des notions de sécurité de ce chapitre.

Messagerie et DHCP

Deux autres services complètent le tableau du quotidien.

La messagerie électronique combine plusieurs protocoles : SMTP pour envoyer un message (de client à serveur, puis de serveur à serveur), IMAP (ou l'ancien POP) pour consulter sa boîte depuis un client. La séparation envoi/réception explique une réalité familière : un problème de « je ne reçois plus » et un problème de « je ne peux plus envoyer » relèvent de protocoles différents.

DHCP (Dynamic Host Configuration Protocol) est le service qui vous configure automatiquement en arrivant sur un réseau. Sans lui, il faudrait saisir à la main, sur chaque machine, son adresse IP, son masque (chapitre 5), sa passerelle par défaut (chapitre 6) et son serveur DNS. DHCP les attribue automatiquement : à la connexion, votre machine diffuse « qui peut me configurer ? », un serveur DHCP lui répond avec un jeu de paramètres pour une durée donnée. C'est le service invisible qui fait qu'un téléphone rejoint un Wi-Fi « tout seul » — et, là encore, il emploie surtout UDP.

Notez la belle mise en abyme : DHCP vous donne l'adresse (chapitre 5) et la passerelle (chapitre 6), et vous indique le serveur DNS, qui vous permettra ensuite de résoudre les noms. Tout le cours se retrouve dans les premières secondes d'une connexion.

Notions de base de sécurité

La sécurité mérite un chapitre entier (et un cours entier, en L3) ; on en pose ici les trois idées minimales, ancrées dans ce qu'on a vu.

Le chiffrement en transit protège les données pendant leur voyage sur le réseau. C'est ce que fait HTTPS : sans lui, tout ce qui transite sur un réseau (surtout un Wi-Fi public, chapitre 4) peut être lu par un tiers. Le cadenas de votre navigateur signale ce chiffrement.

Le mot de passe authentifie l'utilisateur, mais il ne vaut que s'il voyage chiffré (donc en HTTPS) et s'il est fort. Un mot de passe envoyé en HTTP clair est lisible par quiconque sur le chemin — d'où la disparition du web non chiffré.

Le pare-feu (firewall) filtre le trafic entrant et sortant selon des règles : il autorise ce qui est légitime, bloque le reste. C'est la première barrière d'un réseau contre les connexions non désirées.

Ces trois notions ne sont qu'un aperçu — elles répondent chacune à une menace précise (écoute, usurpation d'identité, intrusion), et le cours de cybersécurité de L3 les reprendra en profondeur, attaques à l'appui.

À vous

L'exercice fait dérouler la résolution DNS, la première étape invisible de toute navigation. Vous implémentez la descente dans la hiérarchie — racine, puis .fr, puis le domaine — avec un cache, et vous comptez les requêtes réseau : trois pour la première résolution, zéro pour la seconde grâce au cache.

Vous verrez concrètement pourquoi le DNS doit être hiérarchique (personne ne connaît tout l'Internet) et pourquoi le cache est vital (sans lui, les serveurs racines crouleraient). Et vous retrouverez, en filigrane, le choix d'UDP du chapitre 7 : question courte, réponse courte, rapidité d'abord.

// Le DNS traduit un NOM (www.exemple.fr) en ADRESSE IP. Il n'existe pas UN
// annuaire géant : le nom est résolu par une HIÉRARCHIE de serveurs, lus de
// DROITE à GAUCHE — racine, puis .fr, puis exemple.fr.

// La hiérarchie (simulée). Chaque niveau connaît le serveur du niveau suivant.
const RACINE   = { "fr": "serveur .fr", "com": "serveur .com" };
const TLD_FR   = { "exemple.fr": "serveur exemple.fr" };
const AUTO_EX  = { "www.exemple.fr": "93.184.5.10", "mail.exemple.fr": "93.184.5.20" };

const cache = {};   // nom -> IP (mémorise les réponses passées)
let requetes = 0;

function demander(serveur, question) {
  requetes++;
  console.log("   requête #" + requetes + " -> " + serveur + " : « " + question + " ? »");
  if (serveur === "racine")            return RACINE[question];
  if (serveur === "serveur .fr")       return TLD_FR[question];
  if (serveur === "serveur exemple.fr")return AUTO_EX[question];
}

// ── À VOUS : la résolution récursive ────────────────────────────────────────
// Pour résoudre "www.exemple.fr" :
//   1. si le nom est dans le cache, le renvoyer SANS aucune requête réseau
//   2. sinon : demander à la racine le serveur de "fr",
//              puis à ce serveur le serveur de "exemple.fr",
//              puis à ce serveur l'IP de "www.exemple.fr"
//   3. mettre le résultat en cache
function resoudre(nom) {
  if (cache[nom]) { console.log("   (cache) " + nom + " = " + cache[nom]); return cache[nom]; }
  // à compléter :
  // const srvFr = demander("racine", "fr");
  // const srvDom = demander(srvFr, "exemple.fr");
  // const ip = demander(srvDom, nom);
  // cache[nom] = ip; return ip;
  return null;
}

// ── Vérification ────────────────────────────────────────────────────────────
console.log("1re résolution de www.exemple.fr :");
console.log(" => " + resoudre("www.exemple.fr"));
console.log("");
console.log("2e résolution de www.exemple.fr :");
console.log(" => " + resoudre("www.exemple.fr"));
console.log("");
console.log("Total de requêtes réseau émises :", requetes);

Ce que la suite en fait

La pile est complète, de bout en bout : du signal sur le fil jusqu'à la page web affichée. Vous comprenez maintenant chaque étage et chaque protocole majeur, et surtout comment ils coopèrent — une simple navigation mobilise DHCP, DNS, TCP et HTTP, sur IP, sur Ethernet ou Wi-Fi, sur un support physique.

Le chapitre 9, dernier du cours, est entièrement pratique. Il apprend à configurer une machine et surtout à diagnostiquer une panne — non pas au hasard, mais méthodiquement, couche par couche, en partant du bas. Toute la structure en couches du cours y devient un outil de travail : savoir à quelle couche se situe un problème, c'est déjà l'avoir à moitié résolu.

À retenir