Dépannage des Performances Lentes : Utiliser 'netstat' et 'ss' Efficacement

Lorsqu'un service Linux semble lent, la table des sockets est l'un des endroits les plus rapides pour distinguer "l'application est surchargée" de "le chemin réseau est chaotique". Un serveur web qui ne peut pas accepter de nouvelles connexions, un worker bloqué lors de l'ouverture de sessions de base de données, et un hôte avec un tas de poignées de main TCP à moitié ouvertes ressemblent tous à une lenteur vague pour la personne qui attend de l'autre côté.

netstat et ss vous aident à répondre à une question plus précise : quels sockets réseau existent sur cette machine en ce moment, dans quel état sont-ils, et quel processus les possède ? netstat est toujours utile sur les systèmes plus anciens et dans les anciens runbooks. ss est l'outil que j'utilise en premier sur Linux moderne car il est plus rapide sur les hôtes chargés et dispose d'un meilleur filtrage intégré.

Pourquoi Surveiller les Sockets Réseau ?

La latence et la lenteur du réseau sont souvent liées à des problèmes de connexion plutôt qu'à une épuisement du CPU ou de la mémoire. La surveillance des sockets aide les administrateurs à répondre à des questions critiques telles que :

• Quels ports écoutent activement les connexions ?
• Y a-t-il trop de connexions bloquées dans les états SYN_RECV ou TIME_WAIT ?
• Quel processus (PID) utilise un port spécifique ?
• Y a-t-il des connexions sortantes inattendues ?

En examinant les statistiques des sockets, vous pouvez rapidement exclure les problèmes de configuration réseau ou identifier une contention de ressources liée à la gestion des connexions.

L'Outil Hérité : netstat

netstat est l'utilitaire standard pour afficher les connexions réseau, les tables de routage, les statistiques d'interface et les connexions de masquage depuis des décennies. Bien que déprécié au profit de ss sur de nombreux systèmes modernes, il reste largement disponible et souvent familier aux administrateurs de longue date.

Exemples Courants de netstat

Les indicateurs les plus courants utilisés avec netstat fournissent un aperçu complet :

Indicateur	Description
-a	Affiche tous les sockets (écoute et non-écoute)
-n	Affiche les adresses numériques au lieu d'essayer de résoudre les noms d'hôtes et les noms de services (accélère la sortie)
-t	Affiche les connexions TCP
-u	Affiche les connexions UDP
-l	Affiche uniquement les sockets en écoute
-p	Affiche le PID/nom du programme associé au socket (nécessite des privilèges root)

Exemple : Affichage de toutes les connexions TCP actives numériquement

sudo netstat -ant

Exemple : Trouver ce qui écoute sur le port 80 (HTTP)

sudo netstat -tulpen | grep ':80'

Comprendre les États de Connexion (netstat)

La sortie de netstat inclut souvent une colonne State. Les états clés à surveiller incluent :

• LISTEN : En attente de connexions entrantes.
• ESTABLISHED : Une connexion active et ouverte.
• TIME_WAIT : Un socket attendant une courte période après la fermeture pour s'assurer que les paquets retardés sont traités.
• SYN_RECV : En attente de l'accusé de réception final d'une poignée de main à trois voies (peut indiquer une attaque SYN flood si excessif).

Avertissement sur netstat : netstat repose souvent sur l'analyse des fichiers /proc/net/*, ce qui peut être lent, en particulier sur les systèmes avec un volume très élevé de connexions actives (des milliers). C'est la principale raison pour laquelle ss a été développé.

Le Remplacement Moderne : ss (Statistiques de Socket)

L'utilitaire ss est significativement plus rapide que netstat car il récupère les informations de socket directement depuis l'espace noyau en utilisant les sockets Netlink, contournant les recherches plus lentes dans le système de fichiers.

Exemples Courants de ss

La structure des indicateurs pour ss est très similaire à celle de netstat, ce qui facilite la transition :

Indicateur	Description
-a	Affiche tous les sockets
-n	Affiche les adresses numériques
-t	Affiche les sockets TCP
-u	Affiche les sockets UDP
-l	Affiche les sockets en écoute
-p	Affiche les informations de processus (PID/Programme)

Exemple : Affichage de toutes les connexions TCP actives numériquement (Équivalent à netstat -ant)

ss -ant

Exemple : Trouver ce qui écoute sur le port 443 (HTTPS)

sudo ss -tulpen | grep ':443'

Filtrage Avancé avec ss

L'un des plus grands avantages de ss est sa capacité à effectuer un filtrage direct sur les états de connexion, ce qui est beaucoup plus efficace que de rediriger la sortie de netstat vers grep.

Filtrage par État de Connexion

Vous pouvez utiliser l'option state directement dans la commande ss. C'est extrêmement utile pour diagnostiquer l'accumulation de connexions.

Trouver tous les sockets actuellement dans l'état TIME-WAIT :

ss -tan state time-wait

Trouver tous les sockets dans l'état SYN-SENT (côté client en attente de réponse du serveur) :

ss -tan state syn-sent

Filtrage par Port ou Adresse

Le filtrage par adresse ou port de destination ou source est simple :

Afficher les connexions établies destinées au port 22 (SSH) :

ss -tn state established '( dport = :22 or sport = :22 )'

Afficher les connexions liées à une adresse IP locale spécifique :

ss -ant '( daddr = 192.168.1.100 or saddr = 192.168.1.100 )'

Analyse des Performances : Comparaison netstat vs. ss

Lors du dépannage, le choix entre les outils se résume souvent à la vitesse et aux détails.

Fonctionnalité	netstat	ss
Vitesse	Plus lent (Lit les fichiers)	Beaucoup plus rapide (Utilise les sockets Netlink)
Syntaxe	Mature, bien documentée	Indicateurs similaires, options spécifiques plus récentes
Filtrage	Nécessite une redirection vers grep	Prise en charge native du filtrage par état et adresse
Profondeur d'Information	Bon pour les bases	Plus de détails sur les tailles de tampon de socket (Infos TCP)
Disponibilité	Quasiment universel	Standard sur les distributions Linux modernes

Diagnostiquer un Établissement de Connexion Lent

Si les clients signalent des connexions lentes, vérifiez les sockets bloqués en attente de poignées de main. Utiliser ss est le moyen le plus rapide de le déterminer :

1. Vérifier les comptes élevés de SYN-RECV : Cela suggère que le serveur reçoit des demandes de connexion mais ne termine pas la poignée de main, souvent en raison d'une épuisement des ressources ou d'une charge de trafic élevée.

   ss -s | grep syn-rec
   

2. Vérifier les comptes élevés de SYN-SENT : Si le serveur lui-même initie de nombreuses connexions (par exemple, agissant comme client vers des bases de données ou d'autres API), cela montre qu'il attend des réponses.

   ss -s | grep syn-sent
   

Si vous voyez des nombres élevés soutenus dans l'une ou l'autre catégorie, traitez-les comme une piste plutôt qu'un verdict. SYN-SENT peut signifier qu'un hôte distant est hors service, qu'une route est erronée, qu'un pare-feu bloque silencieusement le trafic, ou que le service distant est surchargé. SYN-RECV peut signifier que le serveur est sous charge, que des paquets sont perdus, ou que des clients ouvrent des connexions sans les terminer.

Un Flux de Triage Pratique

Quand quelqu'un dit "l'application est lente", je commence généralement par un passage court et reproductible :

sudo ss -tulpen
ss -s
sudo ss -tan state established '( sport = :443 or dport = :443 )' | head
sudo ss -tan state syn-recv
sudo ss -tan state time-wait | head

La première commande confirme que le service attendu écoute réellement et montre le processus propriétaire. Le résumé montre si l'hôte a un nombre surprenant de sockets TCP. La commande filtrée établie prouve si le trafic client réel est attaché au port. Les vérifications syn-recv et time-wait montrent si la configuration de la connexion ou le renouvellement des connexions mérite attention.

Par exemple, imaginez un proxy inverse Nginx où les utilisateurs se plaignent que les nouvelles requêtes se bloquent pendant quelques secondes. sudo ss -tulpen | grep ':443' confirme que Nginx possède l'écouteur HTTPS. ss -s montre un grand total TCP, et sudo ss -tan state syn-recv '( sport = :443 )' continue de renvoyer des lignes des mêmes plages sources. Cela ne prouve pas automatiquement une attaque, mais cela vous indique d'examiner les vérifications de santé de l'équilibreur de charge, la perte de paquets en amont, la pression du backlog SYN, les journaux du pare-feu, et éventuellement les limites de débit.

Imaginez maintenant que le même proxy a très peu de sockets SYN_RECV mais de nombreuses connexions établies vers une base de données en amont sur le port 5432. Cela vous éloigne du HTTPS public et vous dirige vers le chemin de la base de données :

sudo ss -tanp '( dport = :5432 or sport = :5432 )'

Si le processus propriétaire est votre application et que le nombre continue d'augmenter, la prochaine question utile est de savoir si l'application fuit des connexions, attend des requêtes lentes, ou ne parvient pas à retourner les connexions à un pool. ss ne répond pas à cette question au niveau de l'application, mais il vous amène dans la bonne pièce.

Lire TIME_WAIT Sans Paniquer

TIME_WAIT est un état TCP normal, pas une erreur en soi. Un serveur qui gère beaucoup de connexions de courte durée montrera naturellement des sockets TIME_WAIT. Ils existent pour que les paquets retardés d'une ancienne connexion ne soient pas confondus avec une nouvelle.

La question utile est de savoir si TIME_WAIT correspond à la charge de travail. Un travail par lots qui ouvre une nouvelle connexion HTTP pour chaque petite requête peut créer une vague de TIME_WAIT. Un service qui devrait utiliser keep-alive mais ne le fait pas peut faire de même. Avant de modifier les paramètres du noyau, vérifiez si l'application peut réutiliser les connexions, activer HTTP keep-alive, ou utiliser un pool de clients approprié.

Soyez prudent avec les anciens conseils qui suggèrent de modifier aveuglément les sysctls TCP pour "corriger" TIME_WAIT. Certains paramètres dépendent de la version du noyau, certains ont été supprimés ou déconseillés avec le temps, et certains créent des échecs subtils derrière des NAT ou des équilibreurs de charge. Commencez par comprendre pourquoi les connexions sont de courte durée.

Vérifier la Pression Locale par Rapport à la Pression Distante

Un détail qui fait gagner du temps est de savoir si l'hôte local accepte principalement des connexions ou en établit principalement. Un proxy frontal a généralement de nombreuses connexions où le port local est 80 ou 443. Un serveur d'application qui communique avec des bases de données et des API peut avoir de nombreuses connexions où le port distant est 5432, 3306, 6379, ou 443.

Pour les écouteurs locaux et le trafic entrant :

sudo ss -tan '( sport = :443 )'

Pour le trafic sortant vers une dépendance :

sudo ss -tan '( dport = :6379 )'

Cette distinction change la conversation suivante. Si le HTTPS entrant s'accumule, vous devrez peut-être inspecter l'équilibreur de charge, la terminaison TLS, les limites de workers, ou le comportement du client. Si les connexions Redis sortantes s'accumulent, l'application locale peut créer trop de connexions client, attendre Redis, ou réessayer de manière trop agressive.

Lorsque vous avez besoin d'un décompte rapide sans lire des centaines de lignes, combinez ss avec des outils shell simples :

sudo ss -tan state established '( dport = :443 )' | wc -l
sudo ss -tan state established '( dport = :5432 )' | wc -l

Le décompte inclut la ligne d'en-tête, ce n'est donc pas une métrique parfaite. Pour le triage, c'est toujours utile. Si le nombre double chaque minute pendant un incident, vous avez un signal plus fort qu'un simple instantané.

Conteneurs et Espaces de Noms Réseau

Sur les hôtes conteneurisés, soyez prudent quant à l'endroit où vous exécutez la commande. Exécuter ss sur l'hôte montre les espaces de noms réseau de l'hôte et les ports publiés, mais il peut ne pas montrer la même vue que le processus voit à l'intérieur de son conteneur. Si un service s'exécute dans un conteneur, comparez les deux vues :

sudo ss -tulpen
docker exec <conteneur> ss -tulpen

Pour Kubernetes, utilisez la vue du nœud pour les écouteurs au niveau de l'hôte et kubectl exec pour l'espace de noms réseau du pod. Un port peut être ouvert à l'intérieur du conteneur tandis que l'hôte, le service, l'ingress, ou la politique réseau empêchent toujours le trafic de l'atteindre. ss est un outil de vérité locale, pas un test de connectivité de bout en bout.

Meilleures Pratiques pour le Dépannage Réseau

1. Utilisez Toujours -n : Lors du dépannage des performances ou de l'écriture de scripts, utilisez l'indicateur numérique (-n) pour éviter les délais de résolution DNS, qui peuvent rendre les diagnostics lents.
2. Priorisez ss : Adoptez ss comme outil par défaut. Réservez netstat uniquement pour les systèmes hérités où ss n'est pas disponible.
3. Exécutez en tant que Root pour le PID : Pour voir quel programme utilise un port, vous avez généralement besoin de sudo ou de privilèges root lors de l'utilisation de l'indicateur -p avec les deux utilitaires.
4. Vérifiez les Statistiques d'Interface : N'oubliez pas les compteurs d'interface. Utilisez ip -s link show <nom_interface> pour vérifier les paquets perdus ou les erreurs, ce qui pourrait indiquer un problème de couche physique plutôt qu'un problème de socket.
5. Comparez les instantanés. Une sortie ss est une photographie. Deux sorties prises à une minute d'intervalle vous indiquent si la situation croît, diminue ou est stable.
6. Notez le filtre exact. Pendant les incidents, une commande sauvegardée comme ss -tan '( dport = :5432 )' est plus facile à répéter et à comparer qu'un pipeline grep à moitié mémorisé.

L'habitude qui porte ses fruits est simple : commencez par les écouteurs, passez aux états de connexion, identifiez le processus propriétaire, puis décidez si la prochaine étape appartient à l'application, au chemin réseau, au pare-feu ou au noyau.