Mac OS XのTIME_WAITはどこにありますか?


9

TIME_WAITMac OS Xではなし

通常、TCP接続が閉じられると、close()最初に呼び出された側のソケットはそのTIME_WAIT状態のままになります。

ピアの1つがMac OS X(Lion)マシンである場合、最初にMac側で呼び出されると、MacにTIME_WAITは何も表示さnetstat -anれませんclose()。ただし、実際にソケットTIME_WAIT状態にあるようです。これは、listen()(ソケットオプションを使用せずに)再度呼び出しSO_REUSEADDRを行うlisten()と失敗するためです。

2 * MSL(によって報告されるMac OS X Lionでの最大セグメント寿命は15秒)を待つと状態がsysctl net.inet.tcp.mslクリアされTIME_WAITlisten()エラーなしで再度呼び出すことができます。

なぜソケットが見えないのTIME_WAITですか?

テスト中

Pythonの2つの簡単なテストプログラムを次に示します。

サーバ

#!/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")

2つの異なる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  
$ 

ピアの1つがMac(OS X Lionを実行している)であるTIME_WAIT場合netstat -an | grep 50007、Macで最初に閉じた後に実行されているときに、私は一度も表示されません。


良い質問。同じことを私自身で見て、それらを含めるnetstatのオプションを何も見ていません…
natevw

2
FWIW、sudo lsof -i -Pすでに終了したプロセスのTIME_WAITステータスも表示されません。
natevw 2014

@natevw私が一人ではないことを知って幸せ。:-)
mgd 2014

回答:


2

このバグレポートは、問題がnetstat 実装にあると主張しています。バグレポートに添付されたコードは、ソケットがTIME_WAIT状態で正しく表示されます。次の行を削除する必要があります

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

localhostにバインドされたソケットを表示するようにします。


0

これは答えではありませんが、誰かがこれからさらに掘り下げることができるかもしれません。

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 !?誰がこのパケットを送り返していますか?サーバープロセスが閉じています!」最初のFINを送信する部分であるため、TIME_WAIT状態のサーバーから送信されたようです。サーバープロセスが終了した場合でも、TCPスタックは接続の状態を保持して、最後のACKを送信します。
neverov
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.