infra / reseaux-tcp-ip
Ports, TCP/UDP
Explication
Ce que vous allez apprendre
- Comprendre à quoi sert un numéro de port et pourquoi une IP seule ne suffit pas
- Reconnaître les ports "bien connus" des services courants (SSH, HTTP, HTTPS, bases de données)
- Distinguer TCP (fiable, orienté connexion) d'UDP (rapide, sans garantie) et savoir quand chacun est utilisé
- Identifier quel processus écoute sur quel port avec
ss -tulpnoulsof -i - Tester si un port distant est ouvert avec
nc -zvounmap
Dans quel contexte ?
Un développeur backend n'arrive plus à connecter son application à sa base PostgreSQL sur db-interne.local:5432. Avant de suspecter le code, il vérifie sur le serveur de base de données avec sudo ss -tulpn | grep :5432 : si rien n'apparaît, PostgreSQL n'écoute tout simplement pas sur ce port, et le problème n'a rien à voir avec le réseau. C'est le tout premier réflexe à avoir face à une erreur "connection refused".
Une adresse IP ne suffit pas : identifier le bon service
Une machine peut faire tourner simultanément un serveur web, un serveur de messagerie et une base de données. L'adresse IP identifie la machine, mais pas lequel de ces services est visé par une connexion. Le port comble ce manque : c'est un numéro qui désigne précisément quel service, sur cette machine, doit recevoir les données. C'est comme un numéro d'appartement en plus de l'adresse de l'immeuble.
| Port | Service | Protocole |
|---|---|---|
| 22 | SSH | TCP |
| 80 / 443 | HTTP / HTTPS | TCP |
| 53 | DNS | TCP + UDP |
| 5432 | PostgreSQL | TCP |
| 6379 | Redis | TCP |
Piège fréquent
Un port "fermé" (rien n'écoute) et un port "bloqué par un pare-feu" produisent des symptômes différents : nc -zv échoue immédiatement sur un port fermé (connexion refusée), mais reste bloqué en attente ("timeout") sur un port filtré par un pare-feu. Cette nuance permet souvent de deviner la cause avant même de se connecter à la machine distante.
Pourquoi certains ports sont "connus"
Pour que deux machines inconnues l'une de l'autre puissent communiquer sans configuration préalable, il faut des conventions partagées : le port 80 pour HTTP, le port 443 pour HTTPS, etc. Ces "ports bien connus" (en dessous de 1024) sont des accords historiques qui permettent à n'importe quel client de deviner comment joindre un service standard, sans avoir à le demander explicitement.
TCP et UDP : deux philosophies opposées de la transmission
TCP privilégie la fiabilité : il vérifie que chaque donnée arrive, dans le bon ordre, quitte à ralentir. UDP privilégie la rapidité : il envoie sans garantie ni accusé de réception, quitte à perdre des données en route. Ce n'est pas qu'UDP soit "moins bon" que TCP : c'est un choix de conception adapté à l'usage. Pour un appel vidéo, perdre une fraction de seconde de son est moins grave qu'attendre une retransmission qui arriverait trop tard — UDP est alors le bon choix, malgré son manque de fiabilité.
Le lien avec la suite du cours
Cette distinction TCP/UDP prépare directement la leçon suivante, qui détaille précisément comment TCP établit une connexion fiable avant même d'échanger la moindre donnée.
Commandes & code
Ports, TCP et UDP
# Un port = un numéro entre 0 et 65535, identifie un SERVICE sur une machine
# Une "socket" = adresse IP + port + protocole, identifie une connexion précise
Ports bien connus (0-1023, nécessitent root pour être ouverts en écoute) :
20/21 FTP 22 SSH 23 Telnet
25 SMTP 53 DNS 80 HTTP
110 POP3 143 IMAP 443 HTTPS
3306 MySQL 5432 PostgreSQL 6379 Redis 27017 MongoDB
Ports enregistrés (1024-49151) : utilisés par des applications spécifiques
Ports dynamiques/éphémères (49152-65535) : attribués temporairement côté client# Voir les ports en écoute sur la machine
ss -tulpn
# t=tcp u=udp l=listening p=process n=numérique (pas de résolution de nom)
# Colonne "Local Address:Port" -> 0.0.0.0:80 = écoute sur toutes les interfaces
sudo ss -tulpn | grep :5432 # qui écoute sur le port 5432 ?
sudo lsof -i :8000 # alternative : quel process utilise ce port
# Tester si un port distant est ouvert
nc -zv exemple.com 443
nmap -p 1-1000 exemple.com # scan une plage de ports (à utiliser avec prudence/autorisation)
nmap -p 22,80,443 exemple.com # scan de ports précisTCP vs UDP
| Critère | TCP | UDP |
|---|---|---|
| Connexion | orientée connexion (handshake) | sans connexion |
| Fiabilité | garantit livraison + ordre | pas de garantie |
| Vitesse | plus lent (accusés de réception) | plus rapide |
| Cas d'usage | HTTP, SSH, bases de données | DNS, streaming, VoIP, jeux vidéo |
| En-tête | plus lourd (20+ octets) | léger (8 octets) |
# UDP : pas de connexion, pas de garantie -> vérifiable avec un simple envoi
echo "test" | nc -u -w1 exemple.com 53
# TCP : établit une connexion avant tout échange (voir la leçon dédiée au three-way handshake)
ss -t state established # connexions TCP actuellement établies
ss -t state time-wait # connexions en cours de fermeture (TIME_WAIT)
# Ouvrir un port dans le pare-feu (rappel, voir leçon Linux dédiée iptables/nftables)
sudo ufw allow 5432/tcpRésumé
- Un port identifie un service ; combiné à une IP il forme une socket unique par connexion.
- TCP garantit ordre et livraison (au prix de la latence), UDP privilégie la vitesse sans garantie.
ss -tulpn(oulsof -i) est le réflexe pour savoir ce qui écoute où sur une machine.
Exercices pratiques
Mission : distinguer un port fermé d'un port filtré
Objectif : Interpréter deux comportements différents de connexion refusée pour déduire, sans accès aux deux serveurs, la cause probable de chacun.
Contexte
Une application backend doit se connecter à PostgreSQL sur db-interne.local:5432. En testant depuis deux environnements différents, tu observes deux comportements très différents : sur le serveur A, nc -zv db-interne.local 5432 échoue instantanément avec "Connection refused" ; sur le serveur B, la même commande reste bloquée sans réponse pendant 10 secondes avant d'abandonner.