Comment fonctionne Internet ? DNS, HTTP, HTTPS, routeurs et CDN
De votre clavier au serveur, en passant par une dizaine de routeurs, un résolveur DNS et un CDN — le chemin complet d'une requête web expliqué simplement.
Vous tapez https://iducation.fr dans votre navigateur et appuyez sur Entrée. Moins de 200 millisecondes plus tard, la page s'affiche. Pendant ces 200ms, votre requête a traversé une dizaine de routeurs, interrogé plusieurs serveurs DNS, établi une connexion chiffrée TLS, et récupéré des fichiers depuis un serveur probablement à des milliers de kilomètres — ou depuis un CDN à quelques millisecondes de vous.
Voici le trajet complet, étape par étape.
Les adresses IP : l'identité des machines
Internet est un réseau de machines. Chaque machine connectée a une adresse IP — un identifiant numérique unique.
IPv4 : 93.184.216.34 — quatre nombres de 0 à 255 séparés par des points. 4,3 milliards d'adresses possibles. Épuisées depuis 2011.
IPv6 : 2606:2800:220:1:248:1893:25c8:1946 — 128 bits. 340 undécillions d'adresses. La migration est en cours depuis des années, mais IPv4 domine encore.
Votre box internet a une IP publique attribuée par votre FAI. Tous les appareils de votre réseau local (ordinateur, téléphone, TV) ont des IPs privées (192.168.x.x, 10.x.x.x) — non routables sur Internet, masquées derrière votre box via NAT.
Le problème des adresses IP : personne ne retient 93.184.216.34. C'est pour ça qu'existe le DNS.
DNS : le carnet d'adresses d'Internet
DNS — Domain Name System — traduit les noms de domaine lisibles par les humains (iducation.fr) en adresses IP lisibles par les machines (76.76.21.21).
La hiérarchie DNS
. (root)
│
┌────────────┼───────────────┐
.fr .com .io
│ │ │
iducation.fr google.com github.io
│
www.iducation.frLe DNS est une hiérarchie distribuée de serveurs. Personne ne détient l'annuaire complet — chaque niveau délègue au niveau inférieur.
La résolution DNS pas à pas
Quand votre navigateur a besoin de l'IP de iducation.fr :
Votre machine Résolveur DNS Serveurs DNS
│ (votre FAI ou 8.8.8.8) autoritatifs
│ │ │
│── iducation.fr ? ───────►│ │
│ │── Root servers ? ────────►│ . (root)
│ │◄─ Demandez à .fr ─────── │
│ │── iducation.fr ? ────────►│ .fr (TLD)
│ │◄─ Demandez à ns.iducation │
│ │── iducation.fr ? ────────►│ ns.iducation.fr
│ │◄─ 76.76.21.21 ─────────── │
│◄── 76.76.21.21 ──────── │ │1. Cache local — votre navigateur vérifie d'abord son cache. Si vous avez visité le site récemment et que le TTL (Time To Live) n'est pas expiré, la réponse est immédiate.
2. Résolveur récursif — votre FAI (ou Cloudflare 1.1.1.1, Google 8.8.8.8) est votre résolveur. Il fait le travail à votre place.
3. Root servers — 13 clusters de serveurs racine (a.root-servers.net à m.root-servers.net) répartis mondialement. Ils savent qui gère chaque TLD (.fr, .com, .io...).
4. Serveurs TLD — le registre .fr (Afnic) sait à quel nameserver appartient iducation.fr.
5. Nameserver autoritatif — le serveur DNS de votre hébergeur retourne enfin l'IP réelle.
Tout ça tient généralement en 20 à 120 ms. Le cache fait que vous ne payez ce coût qu'une fois par TTL (souvent 300 à 3600 secondes).
# Voir la résolution DNS en détail
dig iducation.fr +trace
# Résolution simple
nslookup iducation.fr
# Quel serveur DNS votre machine utilise ?
cat /etc/resolv.conf # Linux/MacDNS utilise UDP port 53 pour les requêtes standard. Si vous voulez comprendre pourquoi UDP plutôt que TCP pour DNS, TCP vs UDP — les deux protocoles de transport explique la logique.
Cette section couvre le flux de résolution. Pour aller plus loin — types d'enregistrements (A, CNAME, MX, TXT, CAA...), TTL, DNSSEC, DoH, dig avancé et attaques DNS — le guide complet du protocole DNS couvre tout ça.
Routeurs : les aiguilleurs d'Internet
Vous avez maintenant l'IP de destination. Comment votre paquet arrive-t-il là-bas ?
Le chemin d'un paquet
Internet n'est pas un câble direct de votre machine au serveur. C'est un réseau de réseaux interconnectés — des milliers d'opérateurs (FAI, backbone providers, hébergeurs) qui s'accordent pour s'échanger le trafic.
# Tracer le chemin d'un paquet (chaque ligne = un routeur)
traceroute iducation.fr # Linux/Mac
tracert iducation.fr # Windows 1 192.168.1.1 1 ms # Votre box (passerelle locale)
2 10.x.x.x 8 ms # Routeur de votre FAI
3 62.x.x.x 11 ms # Backbone FAI
4 80.x.x.x 18 ms # Peering point (échange entre FAIs)
5 104.x.x.x 22 ms # Réseau Cloudflare/hébergeur
6 76.76.21.21 25 ms # DestinationComment un routeur décide
Chaque routeur maintient une table de routage — une liste de préfixes IP et vers quel prochain routeur les envoyer. Le protocole BGP (Border Gateway Protocol) permet aux routeurs de s'échanger ces tables et de converger vers les meilleurs chemins.
Destination Passerelle Interface
0.0.0.0/0 192.168.1.1 eth0 # Route par défaut
10.0.0.0/8 192.168.1.1 eth0
76.76.21.0/24 10.0.0.1 eth1 # Route spécifiqueLe chemin n'est pas fixe. Si un câble est coupé, BGP re-converge et les paquets prennent un autre chemin — souvent en quelques secondes. C'est la résilience fondamentale d'Internet.
HTTP : le protocole des échanges web
Votre navigateur a l'IP. Il ouvre une connexion TCP vers le port 80 (HTTP) ou 443 (HTTPS) et envoie une requête HTTP.
Anatomie d'une requête HTTP
GET /articles/docker-introduction HTTP/1.1
Host: iducation.fr
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, br
Accept-Language: fr-FR,fr;q=0.9
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Connection: keep-alive- Méthode :
GET(lire),POST(envoyer),PUT(remplacer),PATCH(modifier),DELETE(supprimer) - Chemin : la ressource demandée
- Headers : métadonnées sur la requête
- Corps : pour POST/PUT, les données envoyées (JSON, formulaire...)
La réponse HTTP
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Cache-Control: public, max-age=3600
ETag: "abc123"
X-Content-Type-Options: nosniff
<!DOCTYPE html>
<html>...Codes de statut — le serveur communique via ces codes :
| Code | Signification |
|---|---|
200 OK | Succès |
201 Created | Ressource créée (POST) |
301 Moved Permanently | Redirection permanente |
304 Not Modified | Cache valide — pas de re-téléchargement |
400 Bad Request | Requête malformée |
401 Unauthorized | Non authentifié |
403 Forbidden | Authentifié mais pas autorisé |
404 Not Found | Ressource inexistante |
429 Too Many Requests | Rate limiting |
500 Internal Server Error | Erreur serveur |
503 Service Unavailable | Serveur indisponible |
HTTP/1.1, HTTP/2, HTTP/3
HTTP/1.1 (1997) — une requête par connexion TCP. Les navigateurs contournent ça en ouvrant 6 connexions parallèles par domaine.
HTTP/2 (2015) — multiplexage : plusieurs requêtes sur une seule connexion TCP, en parallèle. Headers compressés (HPACK). Push serveur. Gain significatif sur les pages avec beaucoup de ressources.
HTTP/3 (2022) — remplace TCP par QUIC (sur UDP). Élimine le head-of-line blocking de HTTP/2. Connexion plus rapide (0-RTT pour les visites répétées). Déjà déployé par Google, Cloudflare, Meta.
HTTPS : HTTP + chiffrement TLS
HTTP envoie tout en clair. N'importe quel routeur sur le chemin peut lire vos données, les modifier, injecter du contenu. HTTPS ajoute une couche TLS (Transport Layer Security) entre HTTP et TCP.
La poignée de main TLS (TLS Handshake)
Client Serveur
│ │
│── ClientHello ───────────────────►│
│ (versions TLS, cipher suites, │
│ nombre aléatoire) │
│ │
│◄── ServerHello ─────────────────── │
│ (cipher choisi, certificat, │
│ nombre aléatoire) │
│ │
│ [Vérifier le certificat] │
│ [Calculer les clés de session] │
│ │
│── Finished ─────────────────────►│
│◄── Finished ──────────────────────│
│ │
│══════ Données chiffrées ══════════│Le certificat TLS prouve l'identité du serveur. Il est signé par une Autorité de Certification (Let's Encrypt, DigiCert...) à qui votre navigateur fait confiance. Sans certificat valide, le navigateur bloque avec "Votre connexion n'est pas privée".
Ce que TLS garantit :
- Confidentialité : les données sont chiffrées — un routeur intermédiaire ne voit que du bruit
- Intégrité : les données n'ont pas été modifiées en transit (MAC cryptographique)
- Authentification : vous parlez bien au bon serveur (pas à un imposteur)
TLS 1.3 (actuel) réduit le handshake à 1 aller-retour (1-RTT) au lieu de 2 pour TLS 1.2. Et 0-RTT pour les sessions reprises — données envoyées dès le premier paquet.
Let's Encrypt : HTTPS gratuit pour tous
Avant 2015, un certificat TLS coûtait entre 100€ et plusieurs milliers d'euros par an. Let's Encrypt a changé ça en fournissant des certificats gratuits, automatisés, renouvelés tous les 90 jours.
# Installer certbot et obtenir un certificat (Nginx sur Ubuntu)
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d iducation.fr -d www.iducation.fr
# Renouvellement automatique via cron
sudo certbot renew --dry-runAujourd'hui, il n'y a aucune raison de servir un site en HTTP. Les navigateurs marquent les sites HTTP comme "non sécurisés", Google les pénalise dans les résultats, et les FAIs peuvent injecter des publicités dans le trafic HTTP.
CDN : rapprocher le contenu des utilisateurs
Un serveur à Paris répond en 10ms pour un utilisateur français. Pour un utilisateur japonais, la latence physique seule (vitesse de la lumière dans la fibre) est de ~130ms aller. 260ms aller-retour minimum — avant même de traiter la requête.
Un CDN (Content Delivery Network) résout ça en distribuant le contenu sur des dizaines ou centaines de Points of Presence (PoP) répartis mondialement.
Comment un CDN route les requêtes
Utilisateur Tokyo CDN PoP Tokyo Serveur origine Paris
│ │ │
│── iducation.fr ? ──────►│ (DNS Anycast) │
│◄── 104.x.x.x ──────────│ │
│ │ │
│══ GET /page ═══════════►│ │
│ [Cache HIT ?] │
│ │── Non → GET /page ─────►│
│ │◄── 200 OK ──────────────│
│◄═ 200 OK ══════════════│ [Mise en cache] │
│ (depuis Tokyo, 12ms) │ │Anycast est la magie du routage CDN. La même adresse IP est annoncée depuis plusieurs PoPs simultanément. BGP route automatiquement chaque requête vers le PoP le plus proche en termes de routage réseau.
Ce qu'un CDN met en cache
# Le serveur déclare ce qui est cacheable
Cache-Control: public, max-age=31536000, immutable
# → CDN cache ce fichier un an, ne le revalide pas
Cache-Control: public, max-age=3600, stale-while-revalidate=86400
# → CDN cache 1h, puis sert l'ancienne version pendant 24h pendant qu'il rafraîchit
Cache-Control: no-store
# → Jamais en cache (données personnelles, temps réel)Contenu statique — images, CSS, JS compilé, fonts : cache très long (immutable avec hash dans le nom de fichier).
Pages HTML — cache court ou pas de cache selon si contenu personnalisé.
API dynamique — généralement pas mis en cache, ou cache très court sur des endpoints GET sans authentification.
CDN = protection DDoS intégrée
Un attaquant qui envoie 1 million de requêtes par seconde vers votre serveur le fait tomber. Le même attaque vers un CDN comme Cloudflare est absorbée par une infrastructure à 200 Tbps de capacité. Le CDN filtre, votre serveur ne voit rien.
Les principaux CDN — Cloudflare, Fastly, AWS CloudFront, Akamai — intègrent aussi du WAF (Web Application Firewall) pour bloquer les attaques applicatives. C'est un complément au pare-feu UFW au niveau serveur.
Edge Computing : CDN intelligent
Le CDN moderne ne fait plus que du cache. Il exécute du code directement dans ses PoPs — Cloudflare Workers, Vercel Edge Functions, Fastly Compute. Une fonction JavaScript qui tourne à Tokyo au lieu de Paris, sans aller-retour vers le serveur origine. C'est le principe de l'edge computing appliqué aux applications web.
Le trajet complet en 200ms
0ms Vous tapez https://iducation.fr
1ms Cache DNS local : pas trouvé
5ms Résolveur DNS (1.1.1.1) : résolution complète → 76.76.21.21
(ou depuis cache résolveur si déjà visité)
6ms TCP handshake vers 76.76.21.21:443
8ms TLS 1.3 handshake (1-RTT)
10ms GET / HTTP/2 envoyé
25ms Réponse depuis CDN PoP Paris
(pas le serveur à New York — le CDN a servi depuis le cache local)
30ms Navigateur parse le HTML, déclenche requêtes CSS/JS/images
(en parallèle via HTTP/2 multiplexing)
80ms Toutes les ressources reçues (CDN cache HIT)
120ms First Contentful Paint
200ms Page interactiveSi votre DNS était non caché, le serveur à New York (pas de CDN), et HTTP/1.1 : la même page prendrait 1 à 3 secondes. Ce sont ces optimisations en cascade qui font la différence.
Internet est une somme de standards ouverts — DNS, TCP/IP, HTTP, TLS — développés et maintenus par des organisations comme l'IETF, l'ICANN, et le W3C. Aucune entité ne contrôle l'ensemble. C'est à la fois sa force (résilience, interopérabilité) et sa faiblesse (évolution lente, gouvernance complexe).
Chaque couche que vous venez de voir est un protocole que vous pouvez inspecter, déboguer et optimiser. La commande curl -v https://iducation.fr vous montre le TLS handshake, les headers HTTP, et la réponse — le trajet complet, observable en une ligne.
Ces mécanismes ont un impact direct sur le référencement : Googlebot suit les mêmes chemins DNS → TCP → HTTP(S) pour crawler vos pages. Comprendre comment Internet fonctionne est le prérequis de toute stratégie SEO technique — le crawl, l'indexation et les Core Web Vitals s'expliquent tous par ces couches.