Introduction détaillée sur la façon de vérifier le nombre de connexions simultanées et l'état de la connexion de Nginx sous Linux

Linux Vérifiez le nombre de connexions simultanées et le statut de connexion de Nginx, etc.

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 suit :

LAST_ACK 5 （正在等待处理的请求数）
SYN_RECV 30 
ESTABLISHED 1597 （正常数据传输状态） 
FIN_WAIT1 51 
FIN_WAIT2 504 
TIME_WAIT 1057 （处理完毕，等待超时结束的请求数）

Autres descriptions de paramètres :

FERME : Aucune connexion n'est active ou en cours

LISTFR : Le serveur est en attente appels entrants

SYN_RECV : Une demande de connexion est arrivée, en attente de confirmation

SYN_SENT : L'application a démarré, ouvrant 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 libérer

ITMED_WAIT : Attendez que tous les groupes meurent

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

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

LAST_ACK : En attente que tous les paquets meurent

Les trois les é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 de la 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 maintient un grand nombre de statuts TIME_WAIT

2. Le serveur maintient un grand nombre de statuts CLOSE_WAIT . .

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!