Sockets, ports et lecture de ss

Prérequis : cours 6.1-6.2 ; observer les ports.

Pourquoi

« Le service ne répond pas » : ss dit en 5 secondes si c'est « rien n'écoute », « écoute au mauvais endroit » ou « écoute mais filtré ». À condition de lire ses colonnes.

Concepts

• Socket : l'extrémité d'une connexion (IP + port + protocole). Une socket en écoute (LISTEN) attend ; une établie (ESTAB) parle.
• Ports : 0-1023 (privilégiés : 22, 80, 443 — root pour écouter), 1024-49151 (enregistrés), 49152-65535 (éphémères : ports sources temporaires des clients).
• États TCP utiles : LISTEN (attend), ESTAB (vit), SYN-SENT (bloqué sortant), TIME-WAIT (fermée, en quarantaine anti-doublons ~60 s).

Exemple : les 4 lectures

ss -tlnp                          # qui écoute, où, quel processus
ss -tn state established '( dport = :443 )'  # mes connexions HTTPS sortantes
ss -s                             # résumé : TIME-WAIT qui explosent ?
ss -tlnp | grep 3000              # mon app écoute-t-elle ? où (127.0.0.1 vs 0.0.0.0) ?

Cas d'école : app qui écoute sur 127.0.0.1:3000 derrière un proxy qui vise app:3000 → le proxy ne la joint pas si ce n'est pas le bon nom/réseau. Lire l'adresse, pas juste le port.

Cas réel

« L'API ne répond plus » : ss -tlnp montre le port en LISTEN, curl localhost répond, mais pas depuis le LAN → écoute sur 127.0.0.1 au lieu de 0.0.0.0. Une option de conf (HOST=0.0.0.0), 10 secondes de fix après 30 minutes de doute.

Pièges

• Port « ouvert » au firewall mais rien n'écoute : le scan dit closed, pas filtered — lire la nuance.
• Écoute sur :: (IPv6 any) : accepte aussi le v4 mappé… sauf config ipv6only. Vérifier les deux piles.
• Trop de TIME-WAIT côté client lourd : épuisement des éphémères — ss -s pour voir, réutilisation (SO_REUSEADDR, keepalive) pour soigner.

À retenir

Lire adresse + état + processus ; 127.0.0.1 ≠ 0.0.0.0 ; TIME-WAIT en masse = client qui s'épuise.