ss vs netstat : quelle commande de ports sous Linux ?

Utilise ss — c'est le standard actuel sur toute distribution Linux moderne, et netstat y est un héritage. Sur Ubuntu, Fedora et Debian, le binaire netstat n'arrive plus que via le paquet optionnel net-tools, tandis que ss fait partie d'iproute2 et est installé partout. ss est aussi plus rapide sur les serveurs chargés parce qu'il lit les statistiques de sockets directement dans le kernel au lieu de parcourir _/proc_ fichier par fichier. La difficulté, c'est la syntaxe : -tulpn ne signifie pas la même chose dans les deux outils, donc ce guide te donne la table d'équivalence exacte, les commandes qui méritent d'être mémorisées et les réponses aux questions qui tombent en plein incident à 2 h du matin.

netstat est-il déprécié ?

Sous Linux, en pratique oui. Le paquet net-tools — qui contient netstat, ifconfig et route — ne suit plus les fonctions modernes du kernel depuis des années et n'est plus installé par défaut sur aucune grande distribution. Il existe toujours, fonctionne toujours, et il n'y a rien à désinstaller, mais les nouveautés n'arrivent que dans iproute2 (le paquet derrière ss et ip).

Trois conséquences concrètes :

Absent des installations fraîches. Un Ubuntu 24.04 ou un serveur Fedora d'origine n'a pas de netstat tant que tu n'installes pas net-tools à la main. Voilà pourquoi tant de gens cherchent l'équivalent de netstat — le binaire n'est simplement plus là.
Pas d'infos de sockets modernes. netstat est antérieur à des fonctions comme TCP fast open, les stats de sockets au niveau sous-flux et l'attribution des sockets par cgroup. ss les remonte nativement.
L'exception Windows. Sous Windows, netstat vit bien — netstat -ano y reste la façon standard de relier un PID à un port en écoute. L'histoire de dépréciation ne concerne que Linux.

C'est quoi la commande ss sous Linux ?

ss veut dire « socket statistics ». Elle déverse la vision du kernel de chaque socket TCP, UDP et Unix : état, adresses, ports, processus, timers et profondeurs de files. La forme couteau suisse :

# Tout ce qui est en écoute, avec le processus propriétaire
sudo ss -tulpn

Option par option, ça se lit : TCP (-t), UDP (-u), sockets en écoute seulement (-l), afficher les processus (-p), sortie numérique — sans requêtes DNS (-n). Le sudo compte pour -p : sans root tu vois les ports mais pas les noms de processus des sockets qui ne t'appartiennent pas.

Deux autres one-liners qui couvrent l'essentiel du travail :

# Toutes les connexions établies vers/depuis le port 443, avec les processus
sudo ss -tnp 'sport = :443 or dport = :443'

# Tableau récapitulatif : combien de sockets dans chaque état
ss -s

Cette syntaxe de filtrage est une vraie avance face au « grep et prie » de netstat — elle tourne dans le kernel, donc elle est exacte au lieu d'être un appariement de texte.

Comment savoir quel processus utilise un port ?

C'est la raison numéro un pour recourir à l'un ou l'autre outil. Avec ss :

sudo ss -ltnp 'sport = :8080'

Sortie d'exemple sur une machine qui fait tourner un serveur de dev :

State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
LISTEN  0       511     *:8080              *:*               users:(("node",pid=214113,fd=18))

Le champ users:(...) te donne le nom du processus et le PID directement — pas besoin d'une seconde commande. Si le port est occupé mais qu'aucun processus n'apparaît, tu regardes en général un socket détenu par un autre namespace réseau (un conteneur). Depuis l'hôte, lance sudo ss -ltnp et cherche le port avec la colonne processus vide, puis recoupe avec docker ps ou entre dans le namespace du conteneur avec nsenter.

Tu préfères un outil dédié ? sudo lsof -i :8080 -sTCP:LISTEN fait le même travail et se comporte pareil sur macOS et la plupart des BSD, d'où sa survie dans les runbooks. Sous Linux, pourtant, ss est déjà là.

Quelles différences entre ss et netstat ?

Même travail, plomberie différente : netstat scrute _proc/net/tcp_ en espace utilisateur, pendant que ss passe par netlink pour interroger le kernel directement — voilà pourquoi ss répond en millisecondes sur un serveur qui porte 50 000 sockets ouverts et netstat pas. Au quotidien, la différence tient aux options. Voici l'équivalence qui vaut un scotch sur l'écran :

Tu veux	netstat	ss
Ports TCP en écoute + processus	`netstat -tlpn`	`ss -tlpn`
Toutes les connexions TCP + UDP	`netstat -tulpna`	`ss -tulpna`
Table de routage	`netstat -r`	`ip route`
Statistiques d'interfaces	`netstat -i`	`ip -s link`
Résumé des sockets du kernel	—	`ss -s`
Filtrer par port dans le kernel	—	`ss -tnp 'sport = :22'`

Note que les deux premières lignes sont identiques : par chance, les options courtes de ss coïncident avec celles de netstat dans les cas courants, donc la mémoire musculaire survit en grande partie au changement. Les lignes du bas sont celles où netstat n'a pas de réponse — le routage et les interfaces ont migré vers la commande ip, et les lignes résumé/filtre n'existent que dans ss.

Quand faut-il encore utiliser netstat ?

Deux cas honnêtes. D'abord, la portabilité : sur un parc mixte de Linux, AIX ou BSD anciens, netstat est la seule syntaxe présente partout. Ensuite, la continuité de la mémoire musculaire dans les vieux runbooks — si le runbook dit netstat -tlpn et que la machine a net-tools, ça fonctionne encore très bien.

Pour tout le reste, ss par défaut, et mets à jour le runbook. Un compagnon utile quand tu réécris ces runbooks sur un serveur : le mémo journalctl, qui se marie naturellement avec les vérifications de ports quand tu diagnostiques un service qui ne démarre pas : /en/blog/2026-09-02/journalctl-cheat-sheet.

Pourquoi la commande ss est introuvable ?

Parce que tu es soit sur une distribution très vieille (ère pré-2007, avant qu'iproute2 ne soit standard), soit — bien plus probable — pas sur Linux du tout. ss n'est pas une commande macOS ; macOS embarque lsof et netstat mais aucun ss. À peu près pareil pour les BSD. Sous Windows, utilise netstat -ano ou le Get-NetTCPConnection de PowerShell.

Si tu es bel et bien sous Linux et que ss manque, installe iproute2 :

sudo apt install iproute2    # Debian/Ubuntu
sudo dnf install iproute2    # Fedora/RHEL

La réponse en 30 secondes

ss plutôt que netstat sous Linux, à chaque fois : préinstallé, plus rapide, et il peut filtrer dans le kernel. netstat -tlpn devient ss -tlpn, la chasse au processus devient sudo ss -ltnp 'sport = :PORT', et les tables de routage appartiennent désormais à ip route. Garde netstat pour les scripts multiplateformes et la vieille mémoire musculaire ; garde cette page pour l'équivalence des options.