HTTP (HyperText Transfer Protocol) est le protocole de la couche 7 (Application) qui structure les échanges entre clients et serveurs web. HTTPS y ajoute une couche de chiffrement TLS (couche 6 — Présentation).

HTTP repose sur TCP (Paquets IP et TCP) — une connexion TCP est établie avant tout échange HTTP.
Pour les méthodes, codes de statut, headers et CORS → HTTP — Méthodes, Codes et Headers


Structure d’une requête HTTP

Une requête HTTP est un message texte composé de 4 parties :

POST /api/users HTTP/1.1                ← (1) Ligne de requête : Méthode + Chemin + Version
Host: api.exemple.com                   ← ──────────────────────────────────────────────
User-Agent: Mozilla/5.0                 │
Accept: application/json                │  (2) Headers (paires clé: valeur)
Authorization: Bearer eyJhbGci...       │
Content-Type: application/json          │
Content-Length: 42                      ← ──────────────────────────────────────────────
                                        ← (3) Ligne vide obligatoire (séparateur)
{"name": "Alice", "role": "admin"}      ← (4) Body (optionnel — POST/PUT/PATCH)

Structure d’une réponse HTTP

HTTP/1.1 201 Created                    ← (1) Ligne de statut : Version + Code + Message
Content-Type: application/json          ← ──────────────────────────────────────────────
Content-Length: 87                      │
Cache-Control: no-store                 │  (2) Headers de réponse
Set-Cookie: session=abc123; HttpOnly    │
Location: /api/users/42                 ← ──────────────────────────────────────────────
                                        ← (3) Ligne vide
{"id": 42, "name": "Alice"}             ← (4) Body

Versions HTTP

VersionConnexionMultiplexageCompression headersTransportUsage
HTTP/1.0Une connexion par requêteNonNonTCPObsolète
HTTP/1.1Persistante (keep-alive)Non (file d’attente)NonTCPEncore très répandu
HTTP/2PersistanteOui (streams)Oui (HPACK)TCPAPI modernes
HTTP/3PersistanteOuiOui (QPACK)QUIC (UDP)Émergent

HTTP/2 — multiplexage

En HTTP/1.1, les requêtes s’enchaînent sur une connexion (head-of-line blocking). HTTP/2 introduit les streams : plusieurs requêtes en parallèle sur une seule connexion TCP.

HTTP/1.1 — séquentiel :
  conn ──► req1 ──► rep1 ──► req2 ──► rep2 ──► req3 ──► rep3

HTTP/2 — multiplexé :
  conn ──► req1 ──────────────────────────────► rep1
           req2 ──────────────────────────────► rep2
           req3 ──────────────────────────────► rep3

HTTP/3 et QUIC

HTTP/3 abandonne TCP au profit de QUIC (basé sur UDP). QUIC intègre nativement TLS 1.3 et résout le head-of-line blocking au niveau transport.

HTTP/1.1 et HTTP/2 :   [HTTP] ──► [TLS] ──► [TCP] ──► [IP]
HTTP/3 :               [HTTP] ──► [QUIC (= UDP + TLS intégré)] ──► [IP]

Pour QUIC/UDP en détail → UDP


HTTPS — HTTP dans un tunnel TLS

HTTPS = HTTP transporté à l’intérieur d’une session TLS. TLS chiffre la totalité du message HTTP : headers, body, URL, cookies — tout est opaque pour les intermédiaires réseau.

Ce que les routeurs / FAI voient en HTTPS :
┌──────────────────────────────────────────────────────────┐
│  IP src=192.168.1.5  dst=93.184.1.10                     │
│  TCP port dst=443                                         │
│  TLS [ données chiffrées — illisibles ]                   │
└──────────────────────────────────────────────────────────┘

Ce que le serveur voit après déchiffrement TLS :
┌──────────────────────────────────────────────────────────┐
│  GET /api/users?role=admin HTTP/1.1                       │
│  Host: api.exemple.com                                    │
│  Authorization: Bearer eyJhbGci...                       │
└──────────────────────────────────────────────────────────┘

TLS Handshake (TLS 1.3 — 1 aller-retour)

Client                                       Serveur
  │── ClientHello ──────────────────────────►  │
  │   versions TLS, suites crypto,              │
  │   clé publique DH éphémère                  │
  │                                             │
  │◄── ServerHello + Certificate + Finished ──  │
  │    suite choisie, clé DH, cert X.509        │
  │                                             │
  │  [client vérifie la chaîne de certificats]  │
  │  [les deux calculent le secret DH partagé]  │
  │                                             │
  │── Finished (chiffré) ───────────────────►   │
  │                                             │
  │════════════ HTTP chiffré ════════════════   │

Pour le handshake complet, mTLS et les suites cryptographiques → TLS et SSL
Pour comprendre les certificats X.509 → Certificats — Vue d’ensemble

Ce que TLS garantit

PropriétéMécanismeCe que ça évite
ConfidentialitéChiffrement AES-256-GCMUn intermédiaire lit les données
IntégritéAEAD / HMACModification du contenu en transit
AuthentificationCertificat X.509 signé par CAConnexion à un serveur usurpateur (MITM)
Forward SecrecyClés DH éphémèresDéchiffrer des sessions passées si clé privée fuite

Flux d’une requête HTTPS — de bout en bout

L'utilisateur tape : https://api.exemple.com/users

Étape 1 — DNS (L7)
  Résolution : api.exemple.com → 93.184.1.10
  Requête UDP port 53 vers le résolveur DNS     → [[DNS]]

Étape 2 — TCP Three-Way Handshake (L4)
  SYN ──► SYN-ACK ──► ACK  vers 93.184.1.10:443  → [[Paquets IP et TCP]]

Étape 3 — TLS Handshake (L6)
  ClientHello ──► ServerHello + Certificate ──► Finished
  Clé de session dérivée, tunnel chiffré ouvert

Étape 4 — Requête HTTP (L7, chiffrée dans TLS)
  GET /users HTTP/1.1
  Host: api.exemple.com
  Authorization: Bearer eyJ...

Étape 5 — Réponse HTTP (chiffrée dans TLS)
  HTTP/1.1 200 OK
  Content-Type: application/json
  [body JSON]

Étape 6 — TCP Four-Way Handshake (fermeture)
  FIN ──► ACK ──► FIN ──► ACK

Ce que les routeurs intermédiaires voient :
  IP 192.168.1.5 → 93.184.1.10  port 443  [payload chiffré]
  Ils ne voient ni l'URL, ni les headers, ni le body.

En relation avec