2012年12月9日日曜日

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を返答しています。

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

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

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

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

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

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

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



ここからまだ続きがあります。TCP Zerowindowによる通信断 その②へ続く


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秒後にリセット








このエントリーをはてなブックマークに追加