TIME_WAIT 通常情况下，当TCP连接closures时，首先调用close()那一侧的套接字保留在TIME_WAIT状态。
当其中一个节点是Mac OS X（Lion）机器时，如果在Mac端首先调用close()则Mac上的netstat -an将不会列出TIME_WAIT 。 但是，看起来套接字实际上处于TIME_WAIT状态，因为试图再次调用listen() （不使用套接字选项SO_REUSEADDR ）导致listen()失败。
等待2 * MSL（由sysctl net.inet.tcp.msl报告，在Mac OS X Lion上为15秒的最大段寿命）将清除TIME_WAIT状态，并且可以再次调用listen()而不会出错。
为什么在TIME_WAIT中看不到套接字？
这里有两个简单的Pythontesting程序。
服务器
#!/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")
客户
#!/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")
在两台不同的Linux机器上同时运行服务器和客户机时，按<enter>键调用close()首先获得TIME_WAIT如下所示：
$ ./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 $
当其中一个同伴是Mac（运行OS X Lion）时，运行netstat -an | grep 50007时无法看到TIME_WAIT netstat -an | grep 50007 首先在Mac上closures后， netstat -an | grep 50007 。
这个错误报告声称，这个问题是在netstat的实施 。 附加到错误报告的代码正确显示了处于TIME_WAIT状态的套接字。 您需要删除以下行
if (lip == INADDR_LOCALHOST || lip == INADDR_ANY ) { continue; }
使其显示绑定到本地主机的套接字。
这不是一个答案，但有人可能能够从中挖掘出更多。
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