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.

mgd
la source
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.

Neverov
la source
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
yegle
la source
"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