États de connexion TCP et la sortie de la commande Netstat

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 137984
Cet article a été archivé. Il est proposé « en l'état » et ne sera plus mis à jour.
Résumé
Cet article explique comment lire les Netstat(NETSTAT. et les États de connexion TCP Sortie (EXE).

Avant le transfert de données a lieu dans TCP, une connexion doit être établie. TCP utilise une négociation à trois voies (les détails de cette vous trouverez inRFC793, chapitre 3: « Spécifications fonctionnelles »).
Plus d'informations

États de connexion TCP

Voici une brève explication de cette négociation. Dans ce contexte, le « client » est l'homologue de demande de connexion et le « serveur » est le peeraccepting une connexion. Notez que cette notation ne pas les relations reflectClient-serveur sous la forme d'une entité de sécurité architecturale.

  1. Établissement de la connexion

    • Le client envoie un message SYN qui contient le port du serveur et Initial séquence numéro (ISN du client) sur le serveur (ouvrir active).
    • Le serveur renvoie son propre SYN et ACK (qui se compose du client n + 1).
    • Le Client envoie un accusé de réception (qui se compose du serveur n + 1).
  2. Connexion destructions (modifié en trois temps).

    • Le client envoie une ailette (clôture active). C'est maintenant une connexion fermées. Le client n'est plus envoie des données, mais est toujours capable de recevoir des données à partir du serveur. Lors de la réception à cette FIN, le serveur entre dans un état de fermeture passif.
    • Le serveur envoie un accusé de réception (qui est la séquence FIN clients + 1)
    • Le serveur envoie son propre FIN.
    • Le client envoie un accusé de réception (qui est la séquence FIN du serveur + 1). Lorsqu'il reçoit cet accusé de réception, le serveur ferme la connexion.
Une connexion demi-fermées à peut être utilisée pour arrêter l'envoi de données lors de la sillreceiving données. Les applications de socket peuvent appeler arrêt avec le secondargument défini sur 1 pour cet état.

Sortie de la commande netstat

Les États de connexion TCP ci-dessus peuvent être surveillés dans les indicateurs de TCP envertu une trace réseau. Il est également possible de déterminer l'état de connexion en exécutant l'utilitaire Netstat et en examinant l'état column.Netstat est livré avec Windows NT, Windows 95 et TCP/IP-32 pour Windowsfor Workgroups.

État des explications, comme indiqué dans la commande Netstat :
Explication de l'état
------------ --------------------------------------------------------

SYN_SEND indique actif ouvert.

Sync reçue juste reçue par le serveur SYN à partir du client.

ÉTABLIS Client a reçu SYN du serveur et la session est établie.

Serveur écoute est prêt à accepter la connexion.

Remarque : Consultez la documentation relative à l'appel de socket listen(). Les sockets TCP dans l'état d'écoute ne sont pas affichés - il s'agit d'une limitation de la commande NETSTAT. Pour plus d'informations, consultez l'article suivant dans la Base de connaissances Microsoft :
134404 NETSTAT. EXE n'affiche pas les Sockets d'écoute TCP
Clôture active indique FIN_WAIT_1.

TIMED_WAIT Client passe à cet état après clôture active.

CLOSE_WAIT indique une fermeture passive. Le serveur vient de recevoir le premier FIN d'un client.

FIN_WAIT_2 Le client vient de recevoir l'accusé de réception de son premier FIN à partir du serveur.

Serveur de LAST_ACK est dans cet état lorsqu'il envoie sa propre FIN.

CLOSED le serveur a reçu ACK du client et la connexion est fermée.
Par exemple, considérez le scénario suivant :

Une application de socket a été arrêtée, mais Netstat signale le socket ina état CLOSE_WAIT. Cela peut indiquer que le client a connexion (FIN a été envoyé) fermé correctement, mais le serveur a toujours son socket ouvert. Cela peut être le résultat d'une seule instance (parmi tous les threads ou les processus) du socket ne pas fermé.

Remarque : Il est normal d'avoir un socket dans l'état TIME_WAIT pour un longperiod de temps. L'heure est spécifiée dans la RFC793 comme deux fois la MaximumSegment durée de vie (MSL). MSL est défini comme étant de 2 minutes. Ainsi, un socketcould est dans un état TIME_WAIT aussi longtemps que 4 minutes. Certains systemsimplement des valeurs différentes (moins de 2 minutes) pour le langage MSL.

Références supplémentaires :
  • "Interconnexion de réseaux TCP/IP, Volume 1" par Douglas Comer
  • « TCP/IP illustrées, Volume 1" par Richard Stevens.
  • « Réseaux informatiques » par Andrew Tanenbaum
prodtcp prodnt 3.11 NtwkWinsock

Propriétés

ID d'article : 137984 - Dernière mise à jour : 12/04/2015 12:08:18 - Révision : 9.0

Microsoft Windows NT Workstation 3.5, Microsoft Windows NT Workstation 3.51, Microsoft Windows NT Server 3.51, Microsoft TCP/IP for Windows for Workgroups 3.11, Microsoft Windows 95

  • kbnosurvey kbarchive kbmt KB137984 KbMtfr
Commentaires