Où sont mes TIME_WAIT sur Mac OS X?


9

Non TIME_WAITsur Mac OS X

Normalement, lorsqu'une connexion TCP est fermée, le socket du côté où close()est appelé en premier est laissé en l' TIME_WAITétat.

Lorsque l'un des pairs est une machine Mac OS X (Lion), aucun TIME_WAITn'est répertorié par netstat -ansur le Mac s'il close()est appelé en premier du côté Mac. Cependant, il semble que le socket soit réellement en TIME_WAITétat, car une nouvelle tentative d'appel listen()(sans utiliser l'option socket SO_REUSEADDR) listen()échoue.

L'attente de 2 * MSL (durée de vie maximale du segment, qui est de 15 secondes sur Mac OS X Lion comme indiqué par sysctl net.inet.tcp.msl) efface l' TIME_WAITétat et listen()peut être rappelée sans erreur.

Pourquoi ne puis-je pas voir la prise TIME_WAIT?

Essai

Voici deux programmes de test simples en Python.

Serveur

#!/usr/bin/env python

import socket

HOST = ''
PORT = 50007
l = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
l.bind((HOST, PORT))
l.listen(1)
print("Listening on %d" % PORT)
(s, _) = l.accept()
print("Connected")
raw_input("Press <enter> to close...")
l.close()
s.close()
print("Closed")

Client

#!/usr/bin/env python

import socket
import sys

HOST = sys.argv[1]
PORT = 50007

print("Opening connection to server")
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))
raw_input("Press <enter> to close...")
s.close()
print("Closed")

Lors de l'exécution du serveur et du client sur deux machines Linux différentes, l'homologue qui appuie <enter>pour appeler en close()premier obtient un TIME_WAITcomme prévu:

$ ./server-timewait.py 
Listening on 50007
Connected
Press <enter> to close...
Closed
$ netstat -an | grep 50007
tcp        0      0 172.16.185.219:50007    172.16.185.42:49818     TIME_WAIT  
$ 

Lorsque l'un des pairs est un Mac (exécutant OS X Lion), je ne vois jamais un TIME_WAITlors de l'exécution netstat -an | grep 50007après avoir d'abord fermé sur le Mac.


Bonne question. Voir la même chose moi-même et ne voir aucune option pour netstat de les inclure…
natevw

2
FWIW, n'affiche sudo lsof -i -Ppas non plus le statut TIME_WAIT pour les processus qui ont déjà quitté.
natevw

@natevw Heureux de savoir que je ne suis pas seul. :-)
mgd

Réponses:


2

Ce rapport de bogue prétend que le problème est dans l' implémentation de netstat . Le code attaché au rapport de bogue affiche correctement les sockets dans l'état TIME_WAIT. Vous devez supprimer les lignes suivantes

if (lip == INADDR_LOCALHOST ||
  lip == INADDR_ANY
  ) { continue; }

pour lui montrer les sockets liées à localhost.


0

Ce n'est pas une réponse, mais quelqu'un peut peut-être en savoir plus.

tcpdump -i lo0 -vv port 50007

## Press Enter at the server window

# Server send a FIN (note the flag)
23:33:04.283768 IP (tos 0x0, ttl 64, id 4134, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->2c9c)!)
    localhost.50007 > localhost.56030: Flags [F.], cksum 0xfe28 (incorrect -> 0xeff9), seq 1, ack 1, win 9186, options [nop,nop,TS val 432165676 ecr 432157913], length 0

# Client send back ACK
23:33:04.283803 IP (tos 0x0, ttl 64, id 44906, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->8d57)!)
    localhost.56030 > localhost.50007: Flags [.], cksum 0xfe28 (incorrect -> 0xd1a6), seq 1, ack 2, win 9186, options [nop,nop,TS val 432165676 ecr 432165676], length 0

# Server confirm the ACK is received
23:33:04.283812 IP (tos 0x0, ttl 64, id 18284, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->f555)!)
    localhost.50007 > localhost.56030: Flags [.], cksum 0xfe28 (incorrect -> 0xd1a6), seq 2, ack 1, win 9186, options [nop,nop,TS val 432165676 ecr 432165676], length 0

## After this point, the server process is actually exit but client still running.
## It's strange that re-run server script gives "OSError: [Errno 48] Address already in use"
## and netstat shows this connection is in CLOSE_WAIT status

## Press Enter at the client window

# Client send a FIN to server
23:33:09.731728 IP (tos 0x0, ttl 64, id 51478, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->73ab)!)
    localhost.56030 > localhost.50007: Flags [F.], cksum 0xfe28 (incorrect -> 0xbcb6), seq 1, ack 2, win 9186, options [nop,nop,TS val 432171035 ecr 432165676], length 0

# WTH!? Who send back this packet? The server process is closed!
23:33:09.731764 IP (tos 0x0, ttl 64, id 18754, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->f37f)!)
    localhost.50007 > localhost.56030: Flags [.], cksum 0xfe28 (incorrect -> 0xa7c7), seq 2, ack 2, win 9186, options [nop,nop,TS val 432171035 ecr 432171035], length 0

"WTH !? Qui renvoie ce paquet? Le processus du serveur est fermé!" Il semble être envoyé par le serveur qui est dans l'état TIME_WAIT, car c'est la partie qui envoie le premier FIN. Même si le processus serveur a été interrompu, la pile TCP conserve l'état de la connexion pour envoyer le dernier ACK.
neverov
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.