2026-09-07 — Le protocole HTTP

Contexte

Matière : _Reseaux · Type : cours · Source : Cours 07_09_2026 (notes brutes) + support Chapitre 2 — La couche Application (Partie 2) Précédent : 2026-09-07 — Rôle de la couche Application Suite : 2026-09-07 — Le protocole DNS

🎯 Objectifs de la séance

• Décrire le fonctionnement du Web de bout en bout, de l’URL tapée à la page affichée.
• Connaître la structure exacte d’une requête et d’une réponse HTTP.
• Comprendre pourquoi HTTP est sans état et comment les cookies contournent cette limite.
• Savoir ce qu’apporte un proxy / cache Web et à quoi sert le GET conditionnel.

---

Partie 1 — Fonctionnement du Web

URI vs URL

	URI — Uniform Resource Identifier	URL — Uniform Resource Locator
Rôle	Identifie une ressource	Spécifie l’adresse et le protocole d’accès
Exemple	urn:isbn:0451450523	https://example.com/livres/0451450523

Une page Web se compose d’un fichier HTML de base qui référence plusieurs objets (images JPEG, fichiers audio…), chacun adressable par sa propre URL.

• Navigateur (client Web) — agent utilisateur, affiche la page demandée.
• Serveur Web — héberge les objets, chacun accessible par une URL.
• HTTP — définit comment les clients demandent les pages et comment les serveurs les transfèrent.

Les 4 étapes, de l’URL à l’affichage

Étape 1 — Le navigateur découpe l'URL en trois parties
          http :// www.cisco.com / index.html
          └protocole┘ └nom du serveur┘ └fichier demandé┘

Étape 2 — Résolution DNS : www.cisco.com ──▶ @IP
          Ouverture de la connexion TCP (port 80)
          Envoi de la requête HTTP GET /index.html

Étape 3 — Le serveur renvoie le code HTML de la page

Étape 4 — Le navigateur interprète le HTML et met en forme la page

HTTP s'appuie sur TCP

1. Le client initie la connexion TCP (crée un socket) vers le port 80 du serveur.
2. Le serveur accepte la connexion.
3. Les messages HTTP sont échangés.
4. La connexion TCP est fermée.

HTTP est « sans état » ( stateless)

Le serveur ne conserve aucune information sur les requêtes passées du client. Chaque requête est traitée isolément, sans historique.

HTTP vs HTTPS

	HTTP	HTTPS
Requêtes	Texte clair — interceptables et lisibles	Chiffrées
Réponses (HTML)	Non chiffrées	Chiffrées
Mécanisme	—	TLS (Transport Layer Security)
Apports	—	Authentification + chiffrement
Port	80	443

HTTPS utilise exactement le même processus requête/réponse que HTTP ; seule différence : le flux est chiffré par TLS avant d’être transporté.

---

Partie 2 — Les messages HTTP

Deux types : requête et réponse. Tous deux ont la même charpente :

<ligne de départ>          ← request line ou status line
<en-tête 1>
<en-tête 2>
…
<LIGNE VIDE>               ← OBLIGATOIRE, même sans corps
<corps du message>         ← optionnel

La ligne vide est obligatoire

Elle sépare les en-têtes du corps, même si aucun corps n’est présent. C’est une erreur classique en examen.

La requête

Request line — 3 éléments

Méthode HTTP · URL demandée · Version HTTP Exemple : GET /index.html HTTP/1.1

Exemple complet

GET /index.html HTTP/1.1
Host: www-net.cs.umass.edu
User-Agent: Firefox/3.6.10
Accept: text/html,application/xhtml+xml
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7
Keep-Alive: 115
Connection: keep-alive
<ligne vide>

Les en-têtes de requête

En-tête	Signification
Host	Nom de domaine du serveur hébergeant la ressource
User-Agent	Logiciel client (navigateur) et sa version
Accept	Types de contenu acceptés en réponse
Accept-Language	Langue préférée (avec pondération q=)
Accept-Encoding	Compressions acceptées (gzip, deflate)
Accept-Charset	Jeux de caractères interprétables
Referer	URL depuis laquelle la requête a été initiée
Cookie	Paramètres attribués au client par le serveur
Keep-Alive	Durée / nombre de requêtes de la connexion persistante
Connection	La connexion TCP reste-t-elle ouverte après la réponse

Le facteur de qualité q=

Accept-Language: en-us,en;q=0.5 → priorité à l’anglais US, puis anglais général pondéré à 0.5. Plus q est élevé, plus la préférence est forte (1.0 par défaut).

Les méthodes

Méthode	Usage
GET	Demander et obtenir des données depuis le serveur
POST	Transmettre des données au serveur (envoi d’un formulaire)

La réponse

Status line — 3 éléments

Version HTTP · Code de statut · Phrase descriptive (reason phrase) Exemple : HTTP/1.1 200 OK

Exemple complet

HTTP/1.1 200 OK
Date: Sun, 26 Sep 2010 20:09:20 GMT
Server: Apache/2.0.52 (CentOS)
Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT
ETag: "17dc6-a5c-bf716880"
Accept-Ranges: bytes
Content-Length: 2652
Keep-Alive: timeout=10, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=ISO-8859-1
<ligne vide>
<code HTML>

Les en-têtes de réponse

En-tête	Signification
Date	Date et heure de génération de la réponse
Server	Logiciel serveur HTTP et sa version
Last-Modified	Date de dernière modification de la ressource
ETag	Identifiant unique de version de la ressource (cache)
Accept-Ranges	Le serveur accepte les requêtes partielles (reprise de téléchargement)
Content-Length	Taille du corps en octets
Content-Type	Type MIME et encodage des données renvoyées
Set-Cookie	Envoie un cookie au navigateur
Expires	Durée de validité du contenu pour le cache navigateur
Cache-Control	Directives de mise en cache (ex. no-cache)

Les codes de statut

Classe	Catégorie	Sens
1xx	Informationnel	Information sur le traitement en cours
2xx	Succès	La requête a été traitée avec succès
3xx	Redirection	Le client doit accéder à une autre ressource
4xx	Erreur côté client	La requête contient une erreur
5xx	Erreur côté serveur	Le serveur a rencontré un problème

Code	Nom	Explication
200	OK	Reçue, comprise, traitée — la ressource est dans le corps
301	Moved Permanently	Nouvelle URI permanente ; l’adresse est dans l’en-tête Location
304	Not Modified	La copie en cache est toujours valide (GET conditionnel)
404	Not Found	Ressource introuvable (supprimée ou mauvaise URL)
505	HTTP Version Not Supported	Version du protocole non prise en charge

---

Partie 3 — Les cookies

Cookie

Petit fichier qu’un site utilise pour suivre et mémoriser les actions ou préférences d’un utilisateur au fil de sa navigation. C’est ce qui redonne un état à un protocole sans état.

Où vivent les cookies ? (4 emplacements)

1. En-tête Set-Cookie de la réponse HTTP (le serveur l’envoie)
2. En-tête Cookie de la requête HTTP (le client le renvoie)
3. Fichier de cookies du navigateur (côté client)
4. Base de données back-end du serveur (côté serveur)

Les quatre composants du cookie

C’est la réponse type en examen : ligne Set-Cookie en réponse, ligne Cookie en requête, fichier chez le client, base de données chez le serveur.

Le cycle de vie

Client                                         Serveur (Amazon)
  │                                                  │
  │ ─── requête HTTP habituelle ──────────────────▶  │  crée l'ID 1678
  │ ◀── réponse + Set-Cookie: 1678 ───────────────   │  crée l'entrée en BDD
  │  (fichier de cookies : amazon 1678)              │
  │                                                  │
  │ ─── requête HTTP + Cookie: 1678 ──────────────▶  │  action spécifique
  │ ◀── réponse HTTP ─────────────────────────────   │  au cookie, accès BDD
  │                                                  │
  ┆   une semaine plus tard                          ┆
  │ ─── requête HTTP + Cookie: 1678 ──────────────▶  │  retrouve l'utilisateur

First party vs third party

Une page Web assemble des éléments provenant de plusieurs serveurs : le navigateur récupère la page principale sur nytimes.com, y trouve une référence de publicité, contacte AdX.com pour la télécharger, puis assemble le tout.

	Cookie first party (interne)	Cookie third party (tiers)
Origine	Le site que vous avez choisi de visiter (celui qui fournit le HTML principal)	Un site que vous n’avez pas choisi de visiter (régie pub, tracker)
Exemple	nytimes.com → cookie 1634	AdX.com → cookie 7493
Portée	Un seul site	Tous les sites affichant ce tiers

Le mécanisme du pistage inter-sites

C’est l’en-tête Referer qui trahit l’utilisateur. À chaque page contenant une pub AdX, le navigateur envoie à AdX.com son cookie 7493 plus le Referer du site visité. AdX accumule :

7493: NY Times sports, 2/15/22
7493: socks.com,       2/16/22
7493: NY Times arts,   2/17/22

Résultat : après un passage sur socks.com, une publicité pour des chaussettes s’affiche sur nytimes.com.

Avantages et inconvénients

✅ Avantages	⚠️ Inconvénients
Simplifie navigation et achat en ligne (panier conservé)	Permettent de suivre le comportement de navigation
Personnalisation du contenu par utilisateur	Atteinte à la vie privée : collecte souvent à l’insu de l’utilisateur

Cookies et RGPD

RGPD, considérant 30 (mai 2018)

Les identifiants en ligne — adresses IP, identifiants de cookies — peuvent, combinés à d’autres informations, servir à créer des profils de personnes physiques et permettre leur identification.

Deux conséquences juridiques directes :

1. Lorsqu’un cookie permet d’identifier une personne, il est une donnée personnelle soumise au RGPD.
2. Les cookies non strictement nécessaires au fonctionnement du site ne peuvent être activés qu’après consentement explicite de l’utilisateur.

L’utilisateur doit donc disposer d’un contrôle explicite sur l’autorisation des cookies — c’est l’origine des bandeaux de consentement.

---

Partie 4 — Cache Web, proxy et GET conditionnel

Le serveur proxy

Cache Web / serveur proxy

Entité réseau qui répond aux requêtes HTTP au nom du serveur Web d’origine. Il dispose de son propre stockage disque et y conserve des copies des objets récemment demandés.

Bénéfice principal, tel que noté en cours : c’est un intermédiaire qui améliore les performances du réseau en réduisant la latence perçue par l’utilisateur (et le trafic sortant).

Le serveur d’origine pilote le cache via l’en-tête Cache-Control :

• la durée maximale de conservation d’un objet dans le cache ;
• l’interdiction de mise en cache d’un objet.

Le GET conditionnel

Le problème du cache

La copie stockée dans le cache peut être obsolète : l’objet d’origine a pu être modifié sur le serveur depuis sa mise en cache.

Solution HTTP : le GET conditionnel, fondé sur l’en-tête If-Modified-Since.

Cas 1 — objet NON modifié               Cas 2 — objet modifié
client            serveur                client            serveur
  │                  │                     │                  │
  │─ GET ───────────▶│                     │─ GET ───────────▶│
  │  If-modified-    │  objet non          │  If-modified-    │  objet modifié
  │  since: <date>   │  modifié            │  since: <date>   │  après <date>
  │                  │  avant <date>       │                  │
  │◀── HTTP/1.0 ─────│                     │◀── HTTP/1.0 ─────│
  │    304 Not       │                     │    200 OK        │
  │    Modified      │                     │    <data>        │
  │  (pas de corps)  │                     │  (objet complet) │

Le gain du 304

La réponse 304 Not Modified ne contient aucun corps : le cache est autorisé à servir sa copie, et l’objet n’a pas été retransmis. C’est là que se fait l’économie de bande passante.

⚠️ À retenir absolument (examen)

• HTTP = HyperText Transfer Protocol, sans état, sur TCP port 80 · HTTPS = TLS, port 443.
• Requête → request line = méthode + URL + version.
• Réponse → status line = version + code de statut + phrase.
• Ligne vide obligatoire entre en-têtes et corps, même sans corps.
• Codes : 1xx info · 2xx succès · 3xx redirection · 4xx erreur client · 5xx erreur serveur.
• Cookies présents à 4 endroits : Set-Cookie (réponse), Cookie (requête), fichier navigateur, BDD serveur.
• First party = site visité · Third party = site tiers, base du pistage via Referer.
• RGPD : cookie identifiant = donnée personnelle → consentement explicite requis.
• Proxy = intermédiaire qui réduit la latence en servant des copies locales.
• GET conditionnel : If-Modified-Since → 304 Not Modified (sans corps) ou 200 OK (avec l’objet).

❓ Points flous / à revoir

• Différence pratique entre ETag/If-None-Match et Last-Modified/If-Modified-Since
• Autres méthodes HTTP hors programme (PUT, DELETE, HEAD) — vérifier si attendues
• Où se situe exactement TLS dans le modèle OSI (couche 6 ? entre 4 et 7 ?)
• Détail du handshake TLS (non traité dans ce chapitre)

🔗 Liens

• Précédent : 2026-09-07 — Rôle de la couche Application
• Suite : 2026-09-07 — Le protocole DNS
• Révisions : Révisions — Couche Application et HTTP
• Quiz : Quiz — Couche Application et HTTP