Chapitre 1.5 — Le cycle de vie d’une requête

⏱️ TL;DR — Un visiteur tape formacampus.fr et ta page s’affiche. Entre les deux, une chaîne précise : le DNS traduit le nom en IP, le navigateur ouvre une connexion TCP puis TLS (le cadenas HTTPS) vers ton serveur, le pare-feu laisse passer le port 443, Nginx (reverse proxy) reçoit la requête et la relaie à ton app locale, qui interroge peut-être la base de données, construit la réponse, et le tout remonte la chaîne jusqu’à l’écran. Connaître ce trajet, c’est posséder la carte de dépannage : quand « le site est down », tu sais à quel maillon regarder.

🎯 Objectifs

Décrire les étapes d’une requête HTTP en production, dans l’ordre.
Situer le rôle de chaque maillon : DNS, TCP/TLS, pare-feu, Nginx, app, base.
Utiliser cette chaîne comme méthode de diagnostic (« ça casse où ? »).
Faire le lien avec les parties du cours qui construisent chaque maillon.

Le trajet complet, étape par étape

Suivons une requête, du clavier du visiteur jusqu’à sa page — puis le retour.

1–2. La résolution DNS : du nom à l’adresse

Le navigateur ne connaît que des noms ; le réseau ne route que des IP. Première étape : demander au DNS « quelle est l’IP de formacampus.fr ? ». Le DNS répond avec l’adresse IP du VPS (celle d’un enregistrement A/AAAA que tu as configuré). Sans DNS correct, rien ne démarre : le visiteur ne sait même pas où frapper. (Partie 6.)

3. La connexion : TCP puis TLS

Le navigateur ouvre une connexion TCP vers l’IP, sur le port 443 (HTTPS). Puis il négocie TLS : c’est la poignée de main qui établit le chiffrement et vérifie le certificat du serveur (celui délivré par Let’s Encrypt). À l’issue, le canal est chiffré — personne au milieu ne peut lire le trafic. (Partie 8.)

4. Le pare-feu : le videur à l’entrée

La connexion arrive sur le VPS, mais d’abord sur le pare-feu (UFW). Son rôle : n’ouvrir que les ports autorisés. Le port 443 (HTTPS) est ouvert → ça passe. Un scan sur le port 5432 (Postgres) ? Bloqué. Le pare-feu est la première ligne de défense : tout ce qui n’est pas explicitement permis est refusé. (Partie 5.)

5. Nginx : le reverse proxy en façade

La requête atteint Nginx, qui écoute sur 80/443. C’est lui, la porte d’entrée web — pas ton app. Selon le nom de domaine demandé et le chemin, Nginx décide quoi faire : servir un fichier statique lui-même, ou relayer (proxy_pass) vers l’app qui tourne en local sur un port privé (ex. 127.0.0.1:3000). Nginx gère aussi le TLS, la compression, le cache, les logs. On n’expose jamais l’app directement : Nginx la protège et l’habille. (Partie 7.)

6–7. L’application et la base de données

Ton app (Next.js, Symfony…) reçoit enfin la requête relayée par Nginx. Elle exécute ta logique : router, vérifier l’auth, et souvent interroger la base de données (Postgres) pour lire ou écrire des données. La base répond, l’app assemble le résultat. L’app tourne en service (systemd) pour être toujours là ; la base écoute en local uniquement, jamais exposée à Internet. (Parties 9 à 11.)

8–9. La réponse remonte

L’app renvoie sa réponse (HTML, JSON…) à Nginx, qui la rechiffre en TLS et la renvoie au navigateur par la connexion établie. Le navigateur reçoit la page, l’affiche, et le cadenas HTTPS est vert. Fin du voyage — le tout en quelques dizaines de millisecondes.

La chaîne = ta carte de dépannage

L’intérêt de connaître ce trajet est pratique : quand quelque chose casse, tu remontes la chaîne au lieu de paniquer. Chaque maillon a ses symptômes et son outil de test.

Maillon	Symptôme si ça casse	Test rapide
DNS	Le nom ne résout pas, « serveur introuvable »	`dig formacampus.fr`
Connexion / réseau	Timeout, connexion refusée	`ping`, `curl -I`, `nc`
Pare-feu	Le port semble « fermé » de l’extérieur	`ss -tulpn`, test depuis dehors
TLS / certificat	Avertissement de sécurité, cert expiré	`curl -vI https://…`, SSL Labs
Nginx	Erreur 502/504, page d’erreur Nginx	logs Nginx, `nginx -t`
App	502 (app tombée), 500 (bug applicatif)	`systemctl status`, `journalctl`
Base	Erreurs de connexion DB, 500	logs de la base, `psql`

💡 Réflexe — Face à un « le site marche pas », ne devine pas : remonte la chaîne de l’extérieur vers l’intérieur. Le DNS résout-il ? La connexion s’établit-elle ? Le certificat est-il valide ? Nginx répond-il (et que disent ses logs) ? L’app tourne-t-elle ? La base répond-elle ? Chaque question isole un maillon. Nommer le maillon fautif, c’est déjà à moitié résoudre. (Runbooks complets en Partie 16.)

⚠️ Piège — Attribuer au mauvais maillon. Une erreur 502 Bad Gateway est une erreur de Nginx qui te dit « je n’ai pas réussi à joindre l’app derrière » — presque toujours l’app est tombée ou n’écoute pas sur le bon port, pas un bug de Nginx. Confondre les deux fait perdre des heures à trafiquer la config du proxy alors qu’il faut relancer l’app. Comprendre qui parle à qui évite ces impasses.

🔒 Sécurité — Regarde la chaîne côté défense : le pare-feu ferme tout sauf 80/443/22, TLS chiffre le transport, Nginx en façade cache l’app et filtre, l’app tourne en utilisateur non-root, la base n’est pas exposée à Internet. Chaque maillon est aussi une couche de défense (defense in depth) : si une tombe, les autres tiennent. C’est pour ça qu’on ne « saute » aucune étape.

🧭 Sur FormaCampus — Sur formacampus.fr, une requête vers une page de cours suit exactement cette chaîne : DNS → TLS → UFW (443 ouvert) → Nginx qui sert les images de cours en statique et relaie /api/* vers l’API Symfony et le reste vers le front Next.js (deux services locaux distincts) → l’API interroge Postgres → la réponse remonte, chiffrée. Le jour où une page renvoie 502, l’équipe sait d’emblée regarder le service applicatif (systemctl status, journalctl), pas Nginx. La carte mentale leur fait gagner un temps fou en incident.

Ce que la suite du cours va construire

Ce chapitre clôt la Partie 1 : tu as maintenant la carte. Chaque maillon de la chaîne correspond à une (ou plusieurs) partie(s) à venir :

Se déplacer sur la machine pour tout configurer → Parties 2-3.
Y accéder en sécurité (SSH) → Partie 4.
Durcir (pare-feu, MàJ) → Partie 5.
DNS & réseau → Partie 6.
Nginx & HTTPS → Parties 7-8.
App en service & base → Parties 9-11.
Industrialiser & opérer → Parties 12 à 16.

✏️ Exercices

Exercice 1 — Reconstitue la chaîne. Remets dans l’ordre ces étapes en désordre et nomme le maillon de chacune : (A) Nginx relaie vers l’app locale ; (B) le DNS renvoie l’IP ; (C) l’app interroge la base ; (D) TLS établit le canal chiffré sur 443 ; (E) le pare-feu laisse passer le port 443.

✅ Solution

Ordre : B → D → E → A → C. (B) DNS (nom → IP). (D) TCP/TLS (connexion chiffrée sur 443). (E) Pare-feu (autorise 443). (A) Nginx (reverse proxy → app locale). (C) App → base de données. Puis la réponse remonte la chaîne jusqu’au navigateur, rechiffrée par Nginx.

Exercice 2 — Diagnostique. Un visiteur voit une page « 502 Bad Gateway » avec le style d’erreur de Nginx. Le certificat HTTPS est valide, le nom résout bien. Où est le problème le plus probable, et quelle est la première chose à vérifier ?

✅ Solution

DNS et TLS fonctionnent (le nom résout, le cert est valide, et on obtient une réponse de Nginx). Le 502 signifie que Nginx n’arrive pas à joindre l’app derrière lui : l’application est probablement tombée ou n’écoute pas sur le port attendu. Première vérification : l’état du service applicatif — systemctl status <app> et ses logs journalctl -u <app> — puis le relancer si besoin. Ce n’est presque jamais un problème de Nginx lui-même.

🧠 Quiz de révision

1. Quelle est la toute première étape quand un visiteur tape un nom de domaine ?

La résolution DNS : traduire le nom (formacampus.fr) en adresse IP (celle du VPS, via un enregistrement A/AAAA). Sans elle, le navigateur ne sait pas où se connecter.

2. Pourquoi Nginx est-il devant l’application et non l’inverse ?

Nginx est le reverse proxy en façade : il gère le TLS/HTTPS, sert le statique, compresse, met en cache, logue, et relaie vers l’app locale sur un port privé. Il protège et habille l’app, qu’on n’expose jamais directement à Internet.

3. Que signifie une erreur 502 Bad Gateway, et où regarder ?

Que Nginx n’a pas pu joindre l’app derrière lui (app tombée, mauvais port). On regarde donc l’application : systemctl status et journalctl du service — pas la config de Nginx en premier.

4. Pourquoi la base de données n’est-elle pas dans le trajet exposé à Internet ?

Parce qu’elle écoute en local uniquement et n’est jamais ouverte au public (pare-feu + config d’écoute). Seule l’app, sur la même machine, lui parle. Exposer la base serait une faille majeure.

5. En quoi connaître cette chaîne aide-t-il au dépannage ?

Elle sert de carte : face à une panne, on remonte les maillons (DNS → connexion → TLS → pare-feu → Nginx → app → base), chacun avec son symptôme et son outil de test, pour isoler précisément où ça casse au lieu de deviner.

Fin de la Partie 1. Tu as la carte du territoire. On passe aux mains dans le cambouis : Partie 2 — Linux : les fondamentaux.