Le voyage d'un paquet : ce qui se passe vraiment quand tu tapes une adresse

Le point de départ

Tu es assis devant ton PC. Tu ouvres ton navigateur, tu tapes une adresse, tu appuies sur Entrée.

Une seconde plus tard, la page s'affiche.

Entre ces deux instants, il s'est passé une dizaine d'opérations, réparties sur quatre couches réseau, impliquant ton PC, ta box, une dizaine de routeurs et les serveurs de destination.

Cet article suit ce voyage, étape par étape. Pas pour réciter, mais pour comprendre.

Premier arrêt : le navigateur ne sait pas où aller

Ton navigateur a un problème : tu lui as donné un nom (www.google.com), mais il ne sait parler qu'en adresses IP.

C'est comme si tu lui donnais "Tour Eiffel" et qu'il avait besoin de "Champ de Mars, 5 Avenue Anatole France, 75007 Paris".

Il lui faut un traducteur.

Ce traducteur, c'est le DNS.

Ton navigateur commence par vérifier s'il connaît déjà la réponse :

Son cache (il garde les résolutions récentes)
Le fichier hosts de ta machine (une liste locale de correspondances)
Sinon, il demande à un serveur DNS

La requête part en UDP sur le port 53. Pourquoi UDP et pas TCP ? Parce que c'est rapide. Une requête DNS tient dans un paquet, pas besoin d'une connexion fiable.

Quelques millisecondes plus tard, la réponse arrive : une adresse IP.

Le navigateur sait maintenant où aller.

Deuxième arrêt : "Mais c'est qui, cette adresse ?"

Ton navigateur connaît l'IP de destination. Mais il y a un problème : cette IP n'est pas dans ton réseau local.

Ton PC est en 192.168.1.x. L'IP de Google est quelque chose comme 142.250.x.x. Ce n'est pas la même plage.

Conséquence : ton PC ne peut pas envoyer le paquet directement. Il doit passer par la passerelle — ta box ou ton routeur.

Mais pour envoyer un paquet à la passerelle sur le réseau local, il faut son adresse MAC (l'adresse physique de la carte réseau).

Ton PC connaît l'IP de la passerelle, mais pas sa MAC.

C'est là qu'intervient ARP : ton PC envoie un message en broadcast à tout le réseau :

"Qui a l'IP 192.168.1.1 ? Dites-moi votre adresse MAC !"

Le routeur répond :

"C'est moi, ma MAC est AA:BB:CC:DD:EE:FF."

Maintenant, ton PC sait à qui envoyer physiquement.

Troisième arrêt : l'encapsulation

Ton PC a tout ce qu'il lui faut :

L'IP destination : celle de Google
La MAC destination : celle du routeur

Il construit alors le paquet, en empilant les couches :

┌─────────────────────────────────────────┐
│  Trame Ethernet                         │  ← Couche 2 (MAC)
│  ┌───────────────────────────────────┐  │
│  │  Paquet IP                        │  │  ← Couche 3 (IP)
│  │  ┌─────────────────────────────┐  │  │
│  │  │  Segment TCP                │  │  │  ← Couche 4 (Ports)
│  │  │  ┌───────────────────────┐  │  │  │
│  │  │  │  Données HTTP/HTTPS   │  │  │  │  ← Couche 7 (Application)
│  │  │  └───────────────────────┘  │  │  │
│  │  └─────────────────────────────┘  │  │
│  └───────────────────────────────────┘  │
└─────────────────────────────────────────┘

C'est ça, l'encapsulation. Chaque couche ajoute son en-tête, comme des poupées russes.

Avant d'envoyer, il y a un dernier détail : le three-way handshake TCP.

Parce que TCP est fiable — il veut s'assurer que la connexion est établie avant d'envoyer des données.

#	Sens	Flag
1	Toi → Google	SYN (demande de connexion)
2	Google → Toi	SYN, ACK (accepté)
3	Toi → Google	ACK (confirmé)

La connexion est établie.

Quatrième arrêt : le routeur prend le relais

Ton PC envoie la trame sur le câble (ou en WiFi). Le switch la reçoit, lit la MAC destination, et l'envoie au routeur.

Le routeur fait alors quelque chose de crucial : il change d'identité.

Problème : ton IP source est 192.168.1.42. C'est une adresse privée. Elle n'est pas routable sur Internet. Si le paquet partait tel quel, Google ne saurait pas où répondre.

Solution : le NAT (Network Address Translation).

Le routeur :

Remplace ton IP privée par son IP publique (celle fournie par ton FAI)
Remplace ton port source par un port unique
Note la correspondance dans une table NAT

Port 55000 → 192.168.1.42:54321

Maintenant, le paquet peut sortir sur Internet.

Et c'est grâce à ce mécanisme que 200 machines dans une entreprise (ou une famille) peuvent sortir avec une seule IP publique.

Cinquième arrêt : le voyage sur Internet

Le paquet traverse ensuite une dizaine de routeurs :

Ceux de ton FAI
Ceux du backbone Internet
Ceux du datacenter de Google

Chaque routeur :

Décrémente le TTL (Time To Live) du paquet
Consulte sa table de routage
Réexpédie vers le prochain routeur

Le TTL, c'est un compteur de sauts. Chaque routeur retire 1. Quand il atteint 0, le paquet est détruit.

C'est ce mécanisme qui évite les boucles infinies — et c'est aussi lui qui permet à traceroute de cartographier le chemin.

Sixième arrêt : Google répond

Les serveurs de Google reçoivent le paquet. Ils voient :

IP source : l'IP publique de ton routeur
Port source : le port unique attribué par le NAT

Ils préparent leur réponse et l'envoient à cette adresse.

Septième arrêt : le chemin inverse

Le paquet réponse arrive à ton routeur. Celui-ci :

Consulte sa table NAT
Voit que le port 55000 correspond à 192.168.1.42:54321
Remplace l'IP destination par la tienne
Réexpédie vers ton PC

Ton PC reçoit la réponse.

Et le navigateur affiche la page.

Huitième arrêt : la fermeture

Une fois l'échange terminé, TCP ferme proprement la connexion :

#	Sens	Flag
1	Toi → Google	FIN, ACK
2	Google → Toi	FIN, ACK
3	Toi → Google	ACK

La connexion est terminée.

Le récapitulatif du voyage

Étape	Ce qui se passe	Couche	Protocole
1	Résolution du nom en IP	7	DNS (UDP/53)
2	Recherche de la MAC du routeur	2	ARP
3	Encapsulation + handshake TCP	3-4	IP + TCP
4	NAT + routage	3	NAT
5	Traversée d'Internet	3	IP + ICMP
6	Réponse de Google	3	IP
7	Chemin inverse + NAT	3	NAT
8	Fermeture de la connexion	4	TCP

Ce que ce voyage m'a appris

Chaque couche a un rôle précis :

La couche 7 traduit les noms en IP (DNS)
La couche 2 trouve l'adresse physique locale (ARP)
La couche 3 route le paquet à travers le monde (IP + NAT)
La couche 4 garantit la fiabilité (TCP)

Et surtout : quand quelque chose ne marche pas, on peut suivre le fil pour trouver où ça casse.

Pas d'IP ? → problème DNS ou DHCP
Pas de ping vers la passerelle ? → problème local (couche 1-2)
Ping OK mais pas de navigateur ? → problème DNS

C'est là que le modèle OSI devient un outil de diagnostic, pas juste une théorie.