Cours – Protocoles applicatifs : HTTP, messagerie, DNS
BTS SIO SISR 1re année – Bloc 2 – S15
PARTIE I — HTTP / HTTPS : Le Web Expliqué
I.A. HTTP — HyperText Transfer Protocol
HTTP est le protocole de la couche Application qui permet l'échange de documents hypertexte (pages web, API, médias) entre un client (navigateur) et un serveur web (Apache, Nginx...). C'est le protocole le plus utilisé sur Internet.
- Port : TCP 80
- Version courante : HTTP/1.1 (texte), HTTP/2 (binaire, multiplexé), HTTP/3 (sur QUIC/UDP)
- Sans état (stateless) : chaque requête est indépendante — le serveur ne "se souvient" pas du client
Fonctionnement — Requête/Réponse :
Légende : Échange HTTP complet en 4 étapes. La connexion TCP est établie en premier (SYN/SYN-ACK/ACK — le 3-way handshake). La requête HTTP indique la méthode (GET), la ressource (/index.php) et la version du protocole. Le serveur répond avec un code de statut (200 OK) et les en-têtes décrivant la réponse, suivis du corps (le contenu HTML). La connexion TCP est ensuite fermée.
I.B. Les Méthodes HTTP
| Méthode | Action | Analogie |
|---|---|---|
GET |
Demander une ressource (lecture) | Consulter un document |
POST |
Envoyer des données au serveur | Remplir et soumettre un formulaire |
PUT |
Remplacer une ressource existante | Écraser un fichier |
PATCH |
Modifier partiellement une ressource | Corriger une ligne dans un document |
DELETE |
Supprimer une ressource | Supprimer un fichier |
HEAD |
Obtenir les en-têtes sans le corps | Vérifier si un fichier existe sans le télécharger |
OPTIONS |
Connaître les méthodes supportées | Demander ce qu'on peut faire |
Dans le quotidien SISR : GET et POST couvrent 95% des échanges web. GET pour afficher une page, POST pour soumettre un formulaire (connexion, recherche). Les méthodes PUT/DELETE/PATCH sont typiques des API REST que vous rencontrerez en développement web.
I.C. Les Codes de Statut HTTP
Les codes de statut HTTP sont regroupés en 5 familles selon leur premier chiffre :
| Famille | Signification | Exemples clés |
|---|---|---|
| 1xx | Information — traitement en cours | 100 Continue |
| 2xx | Succès | 200 OK, 201 Created, 204 No Content |
| 3xx | Redirection | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 4xx | Erreur client | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found |
| 5xx | Erreur serveur | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable |
Les 6 codes les plus rencontrés en administration :
200 OK → Tout va bien, ressource retournée
301 Moved Permanently → L'URL a changé définitivement (ex : HTTP → HTTPS)
400 Bad Request → La requête du client est mal formée
401 Unauthorized → Authentification requise (pas encore connecté)
403 Forbidden → Authentifié mais pas les droits (ex : droits NTFS insuffisants)
404 Not Found → La ressource n'existe pas sur ce serveur
500 Internal Server → Le serveur a planté (bug PHP, erreur Apache)
Astuce de diagnostic : Quand Apache retourne un
403sur votre site LAMP, regardez en premier les droits Linux (ls -la /var/www/html) — Apache exécute les requêtes en tant qu'utilisateurwww-dataqui doit pouvoir lire les fichiers.
I.D. HTTPS — HTTP Sécurisé
HTTPS = HTTP + TLS (Transport Layer Security). TLS chiffre intégralement la communication HTTP, protégeant la confidentialité et l'intégrité des données.
- Port : TCP 443
- Certificat : Le serveur présente un certificat X.509 signé par une CA (Certificate Authority) — il prouve son identité au client
- Indicateur visuel : Le cadenas dans la barre d'adresse du navigateur
Le TLS Handshake simplifié :
Légende : Le TLS handshake en 5 étapes. Le client annonce ses capacités. Le serveur répond avec son certificat contenant sa clé publique. Le client vérifie que le certificat est signé par une CA de confiance. Le client génère une clé de session et la chiffre avec la clé publique du serveur. À partir de ce moment, toute la communication HTTP est chiffrée de bout en bout — un intercepteur ne voit que des données chiffrées.
Différence entre HTTP et HTTPS pour l'administrateur :
| Aspect | HTTP | HTTPS |
|---|---|---|
| Contenu visible sur le réseau | Oui (texte clair) | Non (chiffré) |
| Mots de passe des formulaires | Visibles en clair ! | Chiffrés |
| Certificat requis | Non | Oui (Let's Encrypt = gratuit) |
| Configuration Apache | VirtualHost *:80 |
VirtualHost *:443 + SSLCertificateFile |
| SEO (référencement) | Pénalisé | Favorisé |
PARTIE II — La Messagerie : SMTP, IMAP, POP3
II.A. Architecture de la Messagerie Email
Pour comprendre SMTP, IMAP et POP3, il faut visualiser le parcours complet d'un email de l'expéditeur au destinataire :
Légende : Le parcours d'un email de A à Z. SMTP est utilisé pour deux choses distinctes : le client envoie son email à son serveur de messagerie (MTA) via SMTP port 587 (soumission). Les serveurs MTA se transmettent l'email entre eux via SMTP port 25. Le destinataire récupère ses emails depuis son serveur avec IMAP (synchronisation, mail reste sur le serveur) ou POP3 (téléchargement, mail supprimé du serveur).
II.B. SMTP — Simple Mail Transfer Protocol
SMTP (RFC 5321) est le protocole d'envoi de courrier électronique. Il est utilisé dans deux contextes distincts :
| Usage | Port | Chiffrement | Qui l'utilise |
|---|---|---|---|
| Client → Serveur (soumission) | 587 (STARTTLS) ou 465 (SSL) | Oui (recommandé) | Outlook, Thunderbird, apps |
| Serveur → Serveur (relais) | 25 | Optionnel (STARTTLS) | Serveurs MTA entre eux |
Dialogue SMTP (simplifié) :
Sécurité SMTP : SMTP sans authentification est exploitable pour le spam relay (utiliser votre serveur pour envoyer du spam). En production, toujours configurer
smtpd_recipient_restrictions(Postfix) ou l'équivalent pour exiger une authentification.
II.C. IMAP vs POP3 — Récupération des Emails
| Critère | IMAP (RFC 3501) | POP3 (RFC 1939) |
|---|---|---|
| Port | 143 (STARTTLS) / 993 (SSL) | 110 (STARTTLS) / 995 (SSL) |
| Stockage des emails | Sur le serveur (synchronisation) | Téléchargés et supprimés du serveur |
| Accès multi-appareils | Oui — même boîte sur téléphone + PC + webmail | Non — les mails disparaissent du serveur après téléchargement |
| Organisation dossiers | Synchronisée entre client et serveur | Locale uniquement |
| Fonctionnement hors-ligne | Partiel (cache local) | Total (mails stockés localement) |
| Usage recommandé | Usage professionnel moderne | Archivage local, connexion intermittente |
Pourquoi IMAP est-il devenu le standard ?
Légende : Comparaison POP3 (à gauche) et IMAP (à droite). Avec POP3, le premier appareil qui télécharge vide la boîte du serveur — les autres appareils ne voient plus les messages. Avec IMAP, le serveur est la source de vérité et tous les appareils synchronisent leur état avec lui.
II.D. Récapitulatif Messagerie
| Protocole | Port | Usage | Chiffrement |
|---|---|---|---|
| SMTP | 25 | Serveur vers serveur | STARTTLS (optionnel) |
| SMTP | 587 | Client vers serveur | STARTTLS (obligatoire en production) |
| SMTP | 465 | Client vers serveur | SSL/TLS (SMTPS, ancien) |
| IMAP | 143 | Le client récupère (synchronisation) | STARTTLS |
| IMAPS | 993 | Le client récupère (synchronisation) | SSL/TLS direct |
| POP3 | 110 | Le client télécharge | STARTTLS |
| POP3S | 995 | Le client télécharge | SSL/TLS direct |
PARTIE III — DNS en Profondeur
III.A. Rappel : La Résolution DNS
Le DNS (Domain Name System) transforme un nom de domaine lisible (www.siosarl.local) en une adresse IP utilisable (192.168.0.145). Aucune communication IP ne peut avoir lieu sans cette résolution préalable.
- Port : UDP 53 (requêtes standard) / TCP 53 (réponses volumineuses, transferts de zone)
- Cache TTL : Chaque enregistrement DNS a une durée de vie (Time To Live) après laquelle il doit être rafraîchi
III.B. Types d'Enregistrements DNS
| Type | Signification | Exemple | Usage |
|---|---|---|---|
| A | Address — IPv4 | srv-ad01.siosarl.local → 192.168.0.145 |
Résolution nom → IP |
| AAAA | Address IPv6 | srv-ad01.siosarl.local → FE80::1 |
Résolution nom → IPv6 |
| CNAME | Canonical Name — alias | www → srv-ad01 |
Alias d'un enregistrement A |
| MX | Mail Exchanger | siosarl.local → mail.siosarl.local (10) |
Serveur de messagerie du domaine |
| PTR | Pointer — résolution inverse | 192.168.0.145 → srv-ad01.siosarl.local |
IP → nom (zone inverse) |
| NS | Name Server | siosarl.local → ns1.siosarl.local |
Serveur DNS faisant autorité |
| SOA | Start Of Authority | — | Informations sur la zone (admin, TTL...) |
| TXT | Texte libre | v=spf1 mx ~all |
SPF, DKIM, validation de domaine |
| SRV | Service | _ldap._tcp.siosarl.local |
Localisation des services AD (Kerberos, LDAP) |
L'enregistrement SRV est particulièrement important en SISR : c'est grâce aux enregistrements
_ldap._tcp.siosarl.localet_kerberos._tcp.siosarl.localqu'un poste Windows trouve automatiquement son contrôleur de domaine lors de la jonction au domaine. Sans DNS correct, AD ne fonctionne pas.
III.C. Résolution Récursive vs Itérative
Il existe deux modes de résolution DNS, selon l'acteur qui porte la charge de la recherche :
Légende : Les deux modes de résolution DNS. Dans la résolution récursive (en haut), le client délègue entièrement la recherche au résolveur — c'est ce que fait votre navigateur quand vous tapez une URL. Dans la résolution itérative (en bas), le résolveur interroge successivement les serveurs de la hiérarchie DNS (racine → TLD → autorité) en récupérant à chaque fois une référence vers le niveau suivant, jusqu'à obtenir la réponse finale. Dans la pratique, le client utilise la récursion avec son résolveur, et ce résolveur utilise l'itération avec les serveurs d'autorité.
III.D. Hiérarchie DNS
Légende : Hiérarchie du système DNS. La racine (.) est au sommet, gérée par 13 clusters de serveurs racine répartis mondialement (en réalité plusieurs centaines de serveurs via anycast). Les TLD (Top Level Domains) comme .com, .fr ou .local sont en dessous. Chaque domaine délègue ensuite ses sous-domaines à ses propres serveurs DNS.
III.E. Les Attaques DNS (Culture Sécurité)
| Attaque | Mécanisme | Protection |
|---|---|---|
| DNS Poisoning (empoisonnement) | Injecter de faux enregistrements dans le cache d'un résolveur | DNSSEC, requêtes randomisées |
| DNS Hijacking (détournement) | Modifier les serveurs DNS d'une victime (malware, routeur compromis) | HTTPS, DNSSEC, surveillance |
| DNS Amplification (DDoS) | Utiliser des serveurs DNS ouverts pour amplifier une attaque DDoS | Fermer les résolveurs ouverts |
| DNS Tunneling | Exfiltrer des données dans des requêtes DNS (contournement de pare-feu) | Analyse comportementale DNS |
PARTIE IV — Récapitulatif : Les Protocoles Applicatifs dans le Modèle OSI
Couche 7 - Application
| Protocole | Port(s) | Transport | Rôle |
|---|---|---|---|
| HTTP | 80 | TCP | Pages web (texte clair) |
| HTTPS | 443 | TCP | Pages web (chiffré TLS) |
| FTP | 21/20 | TCP | Transfert de fichiers (clair) |
| SFTP | 22 | TCP | Transfert de fichiers (SSH) |
| FTPS | 990 | TCP | Transfert de fichiers (TLS) |
| SMTP | 25/587 | TCP | Envoi de mail |
| IMAP | 143/993 | TCP | Lecture de mail (synchronisée avec le serveur) |
| POP3 | 110/995 | TCP | Lecture de mail (téléchargement) |
| DNS | 53 | UDP + TCP | Résolution de noms |
| DHCP | 67/68 | UDP | Attribution IP automatique |
| SSH | 22 | TCP | Shell distant sécurisé |
| Telnet | 23 | TCP | Shell distant en clair (obsolète) |
| LDAP | 389 | TCP | Annuaire (Active Directory) |
| LDAPS | 636 | TCP | Annuaire chiffré (AD) |
| RDP | 3389 | TCP | Bureau distant Windows |
| SMB/CIFS | 445 | TCP | Partages de fichiers Windows |
| NTP | 123 | UDP | Synchronisation horaire |
| SNMP | 161/162 | UDP | Supervision réseau |
Couche 4 - Transport : TCP (connexion fiable, acquittements, retransmissions) ; UDP (sans connexion, rapide, sans garantie).
Couche 3 - Réseau : IP (IPv4 / IPv6), ICMP, ARP.