TCP Zerowindowの調整

TCP Zerowindowによる通信切断が発生している状況をパケットキャプチャーしました。

以下では 192.168.1.55 がバックアップデータを受信する側、192.168.1.10 がバックアップデータを送信する側になっています。

Tivoli Storage Manager Server(192.168.1.55),Tivoli Storage Manager Client(192.168.1.10)間で発生していました。

以後、TSM Server,TSM Clientと表記します。

通信を開始してから、すぐにTCP ZeroWindowが192.168.1.55から出ています。

これは、受信側のバッファがいっぱいで受けられないという状況になっていることを示唆しています。

その後、192.168.1.10からTCP ZeroWindow Probeが出ています。

これは、送信側が受信側へバッファに余裕ができたかチェックをしています。

このチェックに対して、192.168.1.55からはTCP ZeroWindowAckを返答しています。

これは、受信側がまだ無理であると回答しているということです。

このやりとりが、送信側と受信側の間で繰り返されています。

１秒経過してから確認し、その後、2秒経過してから再び確認、今度は４秒経過してから、、というように２倍ずつ確認の間隔が延びていきます。

そして結果的に受信側に余裕ができることが無いままRSTパケット（リセットパケット）を発行し通信断で終了してしまっています。

この場合、バックアップデータを送信する側のTSMアプリケーション側でタイムアウト値を延ばすことで回避しています。

下図でいうところのRSTパケットを出しているのはアプリケーション側ということになるんですね。

だからタイムアウト値を延ばすことで、もうちょっとがんばって通信してくれるようになるんです。

NO	Time	Source	Dest	TCP	備考
6087	17:40:51	192.168.1.10	192.168.1.55	ACK 1460Byte
6088	17:40:50	192.168.1.55	192.168.1.10	TCP ZeroWindow
6089	17:40:51	192.168.1.10	192.168.1.55	TCP ZeroWindow Probe
6090	17:40:51	192.168.1.55	192.168.1.10	TCP ZeroWindowAck
6091	17:40:52	192.168.1.10	192.168.1.55	TCP ZeroWindow Probe	1秒後に確認
6092	17:40:52	192.168.1.55	192.168.1.10	TCP ZeroWindowAck
6093	17:40:54	192.168.1.10	192.168.1.55	TCP ZeroWindow Probe	2.5秒後に確認
6094	17:40:54	192.168.1.55	192.168.1.10	TCP ZeroWindowAck
6095	17:40:59	192.168.1.10	192.168.1.55	TCP ZeroWindow Probe	5秒後に確認
6096	17:40:59	192.168.1.55	192.168.1.10	TCP ZeroWindowAck
6097	17:41:09	192.168.1.10	192.168.1.55	TCP ZeroWindow Probe	10秒後に確認
6098	17:41:09	192.168.1.55	192.168.1.10	TCP ZeroWindowAck
6099	17:41:28	192.168.1.10	192.168.1.55	TCP ZeroWindow Probe	20秒後に確認
6100	17:41:28	192.168.1.55	192.168.1.10	TCP ZeroWindowAck
6107	17:42:06	192.168.1.10	192.168.1.55	TCP ZeroWindow Probe	40秒後に確認
6108	17:42:06	192.168.1.55	192.168.1.10	TCP ZeroWindowAck
6157	17:43:22	192.168.1.55	192.168.1.10	RST 76秒後にリセット