Tutoriel Linux : Interroger le nombre de connexions simultanées et l'état de la connexion de Nginx

Vérifiez le nombre de connexions simultanées et l'état de connexion de Nginx, etc. sous Linux.

1. Vérifiez le nombre de requêtes simultanées du serveur web (Nginx Apache) et son état de connexion TCP :

netstat -n | awk '/^tcp/ {++S[$ NF]} END {for(a in S) print a, S[a]}'

ou :

netstat -n | awk '/^tcp/ {++state[$ NF]} END {for(key in state) print key,"t",state[key]}'Le résultat renvoyé est généralement le suivant :

LAST_ACK 5 (nombre de requêtes en attente de traitement)

SYN_RECV 30 <🎜> 🎜>

Autres descriptions de paramètres :

FERMÉ : Aucune connexion n'est active ou en cours

ÉCOUTER : Le serveur est en attente d'arrivée appels

SYN_RECV : Une demande de connexion a été effectuée. Arrivé, en attente de confirmation

SYN_SENT : L'application a démarré, ouverture d'une connexion

ESTABLISHED : Statut de transfert de données normal

FIN_WAIT1 : L'application indique qu'elle est terminée

FIN_WAIT2 : L'autre partie a accepté de publier

ITMED_WAIT : En attente de la mort de tous les paquets

CLOSING : Les deux les deux côtés essaient de fermer en même temps

TIME_WAIT : L'autre côté a initialisé une version

LAST_ACK : Attendez que tous les paquets meurent

Les trois états couramment utilisés sont : ESTABLISHED signifie communiquer, TIME_WAIT signifie fermeture active et CLOSE_WAIT signifie fermeture passive.

Le protocole TCP stipule que pour une connexion établie, les deux parties sur le réseau doivent effectuer une négociation à quatre pour réussir la déconnexion. Si l'une de ces étapes est manquante, la connexion sera dans un état d'animation suspendue, et les ressources occupées par la connexion elle-même ne seront pas libérées. Le programme serveur réseau doit gérer un grand nombre de connexions en même temps, il est donc nécessaire de s'assurer que les connexions inutiles sont complètement déconnectées, sinon un grand nombre de connexions mortes gaspilleront beaucoup de ressources du serveur. Parmi les nombreux états TCP, il existe deux états les plus remarquables : CLOSE_WAIT et TIME_WAIT.

TIME_WAIT

TIME_WAIT est formé lorsque le lien est activement fermé, en attendant un temps de 2MSL, environ 4 minutes. Principalement pour éviter la perte du dernier ACK. Étant donné que TIME_WAIT prendra très longtemps, le serveur devrait essayer de réduire le nombre de connexions actives fermées

CLOSE_WAIT

CLOSE_WAIT est formé en fermant passivement les connexions. Selon la machine à états TCP, lorsque le serveur reçoit le FIN envoyé par le client, il envoie un ACK selon l'implémentation TCP, il entre donc dans l'état CLOSE_WAIT. Cependant, si le serveur n'exécute pas close(), il ne pourra pas migrer de CLOSE_WAIT vers LAST_ACK et il y aura de nombreuses connexions à l'état CLOSE_WAIT dans le système. À ce moment-là, il se peut que le système soit occupé à traiter les opérations de lecture et d'écriture et n'ait pas fermé la connexion qui a reçu FIN. À ce stade, recv/read a reçu le socket de connexion FIN et renverra 0.

Pourquoi avons-nous besoin de l'état TIME_WAIT ?

En supposant que l'ACK final est perdu, le serveur renverra le FIN. Le client doit conserver les informations d'état TCP afin que l'ACK final puisse être renvoyé, ce qui entraînera la réflexion du serveur. qu'une erreur s'est produite. Les implémentations TCP doivent terminer de manière fiable les deux sens de la connexion (duplex intégral fermé) et le client doit entrer dans l'état TIME_WAIT car le client peut être confronté à la retransmission de l'ACK final.

Pourquoi l'état TIME_WAIT doit-il rester 2MSL pendant si longtemps ?

Si l'état TIME_WAIT n'est pas maintenu assez longtemps (par exemple, moins de 2MSL), la première connexion se terminera normalement. Une deuxième connexion apparaît avec le même quintuple associé, et des paquets en double de la première connexion arrivent, interférant avec la deuxième connexion. L'implémentation TCP doit empêcher les messages en double d'une certaine connexion d'apparaître après la fin de la connexion, donc gardez l'état TIME_WAIT suffisamment longtemps (2MSL), et les messages TCP dans la direction correspondante de la connexion recevront une réponse complète ou seront rejetés. Il n'y a aucune confusion lors de l'établissement d'une deuxième connexion.

Trop de sockets dans les statuts TIME_WAIT et CLOSE_WAIT

S'il y a une exception dans le serveur, 89% du temps ce sera les deux situations suivantes :

1. Le serveur conserve un grand nombre de statuts TIME_WAIT

2. Le serveur conserve un grand nombre de statuts CLOSE_WAIT En termes simples, le nombre excessif de CLOSE_WAIT est dû à une mauvaise gestion des connexions fermées passivement.

Parce que le handle de fichier alloué à un utilisateur par Linux est limité, et si les deux états de TIME_WAIT et CLOSE_WAIT sont toujours maintenus, cela signifie que le nombre de canaux correspondant sera toujours occupé, et ce sera " occupé." Aucun effort", une fois la limite supérieure du nombre de handles atteinte, les nouvelles requêtes ne peuvent pas être traitées, suivies d'un grand nombre d'exceptions Too Many Open Files et Tomcat plante.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!