Adresse IP, routeur, DNS : les réseaux expliqués simplement

Quand tu tapes une URL, ton navigateur mobilise en moins d'une seconde, la plupart du temps, sept notions réseau : adresse IP, port, DNS, adresse MAC et ARP, routeur et NAT, TCP, puis HTTPS. Le cours E25 les suit dans l'ordre, du clavier jusqu'au serveur, à partir d'une question très concrète : pourquoi le localhost:3000 de Salma fonctionne chez elle, mais affiche une erreur chez son ami Karim ?

C'est quoi une adresse IP, publique ou privée ?#

Chez Salma, un laptop et un téléphone sont reliés à la box Wi-Fi. Chaque appareil du réseau a une adresse IP, comme l'adresse d'une maison : chaque paquet indique d'où il vient et où il va.

Une adresse IPv4, ce sont quatre nombres de 0 à 255 séparés par des points. Le laptop de Salma a 192.168.1.23, le téléphone a la même base qui se termine par .42, et la box est en .1.

Ce sont des IP privées : les mêmes plages se répètent dans des millions de maisons et ne circulent pas sur Internet. Côté Internet, la box a en général une IP publique, partagée par tous les appareils du foyer. C'est elle que t'affichent les sites « quelle est mon IP », pas celle de ton laptop. Et une IP ne dit pas qui tu es : elle désigne un point de connexion à un moment donné, et elle peut changer.

Ports et localhost : pourquoi « localhost:3000 » ne marche pas chez ton ami ?#

L'application Express de Salma écoute sur le port 3000. Si l'IP est l'adresse de l'immeuble, le port est le numéro de l'appartement : il désigne un programme sur la machine. Un port va de 0 à 65535. HTTP utilise le 80, HTTPS le 443, et le navigateur les ajoute tout seul. Le 3000 n'a rien d'officiel pour Node : c'est une habitude des tutos.

localhost est le nom de 127.0.0.1, l'adresse de bouclage. Elle veut dire « moi-même » : un paquet envoyé à localhost ne quitte pas la machine. Quand Karim ouvre localhost:3000 sur son téléphone, son téléphone s'interroge lui-même. Aucun programme n'y écoute sur le 3000 : connection refused.

Et 0.0.0.0 ?#

Ce n'est pas une adresse où l'on se rend. Elle signifie « j'écoute sur toutes les interfaces ». Un app.listen(3000) sans host fait écouter Node sur toutes les interfaces. C'est pour cela que le téléphone de Salma, sur le même Wi-Fi, peut ouvrir l'application avec l'IP du laptop, si le pare-feu le permet.

Que faire face à « address already in use » ?#

Cette erreur célèbre (EADDRINUSE) ne veut pas dire que ton code est faux. Le port est simplement occupé, souvent par un ancien serveur resté ouvert dans un autre terminal. Sur Mac et Linux, lsof te donne le PID du programme qui écoute sur le port, puis tu l'arrêtes avec kill ; sur Windows, netstat et taskkill font le même travail :

# Mac / Linux
lsof -nP -iTCP:3000 -sTCP:LISTEN
kill <PID>

# Windows
netstat -ano | findstr :3000
taskkill /PID <PID> /F

Sans -P, macOS affiche parfois un nom de service à la place du numéro 3000. Autre option qui marche sur tous les systèmes :

npx kill-port 3000

Attention : cette commande arrête le programme qui occupe le port, quel qu'il soit.

DNS : comment un nom devient une adresse IP ?#

Salma tape https://example.com. Le navigateur a besoin de l'IP du serveur, mais il n'a que le nom. Le DNS joue le rôle d'annuaire : on lui demande l'IP de example.com, il répond par une adresse. Il n'héberge pas le site, il donne seulement l'adresse.

Avant de le consulter, le système regarde en général le fichier hosts. Il se trouve dans /etc/hosts sur Mac et Linux (à modifier avec sudo nano /etc/hosts), et dans C:\Windows\System32\drivers\etc\hosts sur Windows. Salma y a ajouté une ligne :

127.0.0.1   salma.test

En ouvrant http://salma.test:3000, son application s'affiche. Le suffixe .test est réservé aux tests. Quant à localhost, il ne passe pas par Internet : le système le résout lui-même vers l'adresse de bouclage.

Si le nom n'est pas dans le fichier hosts, une requête DNS part, généralement en UDP sur le port 53. Avec dig example.com +short (ou nslookup), tu vois l'IP réellement renvoyée aujourd'hui. Chaque réponse a un TTL, une durée en secondes pendant laquelle elle reste en cache : la visite suivante ne repose pas la question.

MAC et ARP : la livraison dans le réseau local#

On connaît l'IP du serveur. Mais à l'intérieur de la maison, le paquet est remis à une carte réseau grâce à son adresse MAC : six paires en hexadécimal, une par carte Wi-Fi ou câble. L'IP dit à qui le paquet est destiné au final ; la MAC dit à qui on le remet maintenant, dans le réseau local.

Pour remettre un paquet à un appareil de son réseau local, le laptop doit connaître sa MAC. Or il ne connaît souvent que son IP. Pour trouver la MAC, il utilise ARP (en IPv4) : il demande à tout le réseau, par exemple, « qui a 192.168.1.1 ? ». Seul l'appareil qui a cette IP répond, directement au laptop. La réponse est gardée dans la table ARP, visible avec :

arp -a

ARP ne traverse pas les routeurs : il ne fonctionne qu'à l'intérieur du réseau local.

C'est quoi un routeur, et pourquoi ton localhost n'est pas en ligne ?#

Le paquet part vers Internet, mais l'IP de Salma est privée. La box est un routeur : elle relie les réseaux et transmet chaque paquet à l'étape suivante. À la sortie, elle fait du NAT : elle remplace l'adresse source de Salma par l'IP publique, avec un autre port, et note cet échange dans une table. Quand la réponse revient, elle consulte la table et la renvoie au laptop.

Si Karim, depuis un café, essaie l'IP publique de Salma sur le port 3000, aucune ligne de la table ne correspond. Une connexion qui arrive de l'extérieur sans avoir été demandée n'a pas de destinataire : la box la refuse.

TCP ou UDP : quelle différence ?#

Avant d'envoyer la requête, le navigateur ouvre une connexion TCP avec le serveur, sur le 443, en trois messages : SYN, SYN-ACK, ACK. C'est la poignée de main. TCP numérote les données, renvoie ce qui s'est perdu et livre dans l'ordre.

UDP, lui, n'a ni poignée de main ni renvoi : chaque message part seul. Ce n'est pas un défaut, c'est un choix. Dans un appel vidéo, une image perdue arriverait trop tard si on la renvoyait. D'où UDP pour le DNS, la vidéo ou les jeux en ligne. Et la poignée de main TCP ne chiffre rien : c'est l'étape suivante.

HTTP et HTTPS : que protège vraiment le cadenas ?#

HTTP est le langage de l'échange : le navigateur envoie par exemple GET /, le serveur répond par un code et le contenu. 200 OK signifie que tout va bien, 404 que la page n'existe pas.

HTTPS, c'est HTTP dans un tunnel chiffré par TLS, sur le port 443. Après la poignée TCP, le serveur présente un certificat pour example.com, signé par une autorité reconnue. Les deux côtés s'accordent ensuite sur des clés, et tout devient chiffré. La commande suivante montre ces étapes : connexion, TLS, puis GET et 200 :

curl -v https://example.com

Sur le Wi-Fi d'un café, en HTTP, un mot de passe passe en clair ; en HTTPS, il est illisible. Sont cachés : le chemin, les en-têtes, les cookies et le contenu. Restent visibles : l'IP du serveur et, le plus souvent, le nom de domaine. Enfin, le cadenas garantit le chiffrement et le domaine, pas les intentions du site : un site d'arnaque peut très bien avoir HTTPS.

Le trajet complet, dans le bon ordre#

1. Salma tape https://example.com ; le navigateur en déduit le port 443 et le nom.
2. Il cherche l'IP : cache, fichier hosts, sinon requête DNS.
3. Pour que la requête DNS sorte, le laptop doit déjà connaître une adresse MAC dans son réseau local : c'est le travail d'ARP (souvent déjà en cache). ARP intervient donc avant le DNS, même si le cours l'explique après.
4. Le paquet part avec l'IP du serveur comme destination.
5. La box fait du NAT, puis de routeur en routeur jusqu'au serveur.
6. Poignée TCP, puis poignée TLS et certificat.
7. GET /, 200 OK et le HTML : le navigateur affiche la page.

Questions fréquentes#

À retenir#

• IP privée dans la maison, IP publique partagée par la box sur Internet.
• localhost = 127.0.0.1 = « moi-même » ; un port désigne un programme sur la machine.
• « address already in use » : le port est occupé, pas forcément ton code qui est faux.
• Le DNS traduit un nom en IP ; le fichier hosts passe avant, et le TTL règle le cache.
• La MAC sert à livrer dans le réseau local, ARP la trouve ; le NAT n'est pas un pare-feu.
• HTTPS chiffre le contenu, pas le nom du site, et le cadenas ne prouve pas l'honnêteté.

Regarder le cours#

Le cours complet (9 min 47, en darija) est sur sa page : Les réseaux, expliqués en darija (E25).

• 0:00 Tu tapes une URL : 7 notions réseau
• 0:25 Adresse IP : publique vs privée
• 1:20 Ports et localhost (port 3000 already in use)
• 3:02 DNS : du nom à l'adresse IP
• 4:04 MAC et ARP : la livraison dans le réseau local
• 4:57 Routeur et NAT : pourquoi ton localhost n'est pas en ligne
• 5:58 TCP vs UDP : la poignée de main
• 6:41 HTTP vs HTTPS : le cadenas et TLS
• 8:00 Récap : tout le trajet d'une URL
• 9:02 Défi : quelle adresse MAC ?

Le défi de la fin : Salma ouvre un site hébergé sur un autre réseau. À quelle adresse MAC son laptop envoie-t-il la trame : celle du serveur, celle de la box, ou l'adresse de diffusion ff:ff:ff:ff:ff:ff ? Donne ta réponse en commentaire sous la vidéo : la correction y sera publiée.

Pour aller plus loin#

• L'application sur localhost:3000 vient d'ici : Node.js et Express pour un développeur PHP.
• Le parcours : Introduction à l'informatique.
• Les bases du réseau, de OSI à TCP/IP : réseau informatique, cours de révision.

Sources#

• MDN, How the web works
• IETF, RFC 1918 : adresses IP privées
• MDN, HTTPS (glossaire)