ＴＣＰコネクションが切断される理由？！
戸根様
いつもお世話になっております、小山です。
台風がまた、関東に近づいています(--;)
ひとつ教えていただきたいのですが、あるネットワークで
ＩＰ層以下に異常がないのに、ＴＣＰコネクションが切れることがあります。
ネットワーク構成機器は、ルータとモデムとスイッチ、パソコン（端末）です。
ＲＳ－２３２Ｃとイーサネット変換アダプタもあります。
主に端末間どうしのＴＣＰコネクションが切れている場合が多いです。
ＩＰ層まで異常が見当たらないのに、ＴＣＰ層の動作が不安定なのが
よくわかりません。ＴＣＰコネクションが切れる主な理由を教えていただければ
幸いです。よろしくお願い致します。
日時:
02/08/19 13:34
コメント
パケットを調べた方が早いかも
小山さん，こんにちわ。
今年は台風が多いですね。
さて，TCPコネクションの件ですが，
普通に考えると，IPパケットが正しく届いていれば，
TCPコネクションでの通信は正しくできるはずですから，
どこかがおかしいんでしょうねぇ．．．
ありがちな原因を考えてみると，
IPアドレスを重複して割り当てているとか，
何らかのエラーでIPパケットが途中で落ちるとか，
TCPプロトコルソフトに何らかの異常があるとか，
といったことでしょうけれど，この中に思い当たるものはありますか？
この手のトラブルはパケットを採取して調べてみるのが，
一番手っ取り早いように思いますが，
パケット採取はできますか？
パケットを調べましたが．．．。
>小山さん，こんにちわ。
>今年は台風が多いですね。
早いお返事ありがとうございます、小山です。
今回の台風の影響は、強烈なものではなかったみたいですね...。
>さて，TCPコネクションの件ですが，
>どこかがおかしいんでしょうねぇ．．．
スニファーを使って調べてみましたが、
ＴＣＰ層において
ウィンドウ凍結、トランスポート再送、Ａｃｋ時間超過、誤転送フレーム
応答なし等が発生していました。
この中でも特に、ウィンドウ凍結、トランスポート再送、応答なしが
目立っています。
これらが発生する原因として、受信バッファ不足やネットワーク輻輳などが
考えられますが、何が引き金になって、このような状況に陥ったか
読み取ることができません...今のところは...。
確かに、伝送速度が１００Ｍや１０Ｍで行っているところから
１２８Ｋの回線にデータを送っているから、レスポンスが悪くなって
いるのかと考えましたが、流れるデータの最大量は６４Ｋ前後なので
途中で回線が細くなったからと言って、回線容量以下のデータが欠けるとは
考えにくいと思います。いかがでしょうか？
>ありがちな原因を考えてみると，
>IPアドレスを重複して割り当てているとか，
>何らかのエラーでIPパケットが途中で落ちるとか，
>TCPプロトコルソフトに何らかの異常があるとか，
>といったことでしょうけれど，この中に思い当たるものはありますか？
先ほどと重複しますが、何らかの原因（原因不明）でＴＣＰの再送が多くなり、
ネットワーク負荷が増大し、ＵＤＰが破棄されている可能性があるようですが
パケット破棄されているかどうか、スニファーでは読み取れません...。
アプリケーションでみると、ＵＤＰ受信したデータが表示されるので
パケットが来なければ表示されないので、目視で判断しています。
>この手のトラブルはパケットを採取して調べてみるのが，
>一番手っ取り早いように思いますが，
>パケット採取はできますか？
ＴＣＰパケットの中で、ＰＳＨフラグがあり、規則的に１がある時が
見受けられましたが、このタイミングはＴＣＰの規則か何かで決められて
いるのでしょうか？
あと、ウィンドウサイズを受信側から送信側へ通知していますが、
そのままのウィンドウサイズが反映されず、なぜか通知されたウィンドウサイズ
から、１７５バイトを引いた値が送信のウィンドウサイズになっていました。
例えば、受信側から通知されたウィンドウサイズが８７２５バイトだった場合は
送信側のウィンドウサイズは、８５５０バイトでした。
このウィンドウサイズの動作はこれで合っているのでしょうか？
分かる範囲で教えていただければ幸いです。
よろしくお願い致します。
途中でパケットが消えているような．．．？
>ウィンドウ凍結、トランスポート再送、Ａｃｋ時間超過、誤転送フレーム
>応答なし等が発生していました。
これは，要するに，受信確認応答パケットが受信側から返って来ていない，
ということでしょうか？
tracerouteとかPingPlotterっていうユーティリティは知っていますか？
（PingPlotterはhttp://www.pingplotter.com/で入手可能）
これを使うと，どこかでパケットが落ちいないかどうか検査できます。
（精度はそんなに高くないですけど）
試してみるといいかもしれません。
>確かに、伝送速度が１００Ｍや１０Ｍで行っているところから
>１２８Ｋの回線にデータを送っているから、レスポンスが悪くなって
>いるのかと考えましたが、流れるデータの最大量は６４Ｋ前後なので
通信回線に流れ込んでいくデータが64Kbps程度であれば，
それほど問題は起こらないはずなんですが，
通信回線側にパケットを送っている機器が他にあれば話は別です。
その辺，見落としはないでしょうか？
>ＴＣＰパケットの中で、ＰＳＨフラグがあり、規則的に１がある時が
>見受けられましたが、このタイミングはＴＣＰの規則か何かで決められて
>いるのでしょうか？
Pushフラグはアプリケーション側でコントロールするものなので，
アプリケーションがそうしている，というだけです。
アプリケーションはどういったものですか？
>あと、ウィンドウサイズを受信側から送信側へ通知していますが、
ウインドウサイズっていうのは，要するに，
自分の受信バッファの空き領域のサイズを相手に知らせるもので，
相手側から通知してきた値とは関係ないですから，気にする必要はありません。
再度、調査してみます。
>>ウィンドウ凍結、トランスポート再送、Ａｃｋ時間超過、誤転送フレーム
>>応答なし等が発生していました。
>これは，要するに，受信確認応答パケットが受信側から返って来ていない，
>ということでしょうか？
大半は、戸根さんの言われるとおりで間違いないと思います。
>tracerouteとかPingPlotterっていうユーティリティは知っていますか？
>（PingPlotterはhttp://www.pingplotter.com/で入手可能）
>これを使うと，どこかでパケットが落ちいないかどうか検査できます。
>（精度はそんなに高くないですけど）
>試してみるといいかもしれません。
tracerouteは、ＭＳ－ＤＯＳで使うtracertと同一の機能を
持っているものだと思いますが、
tracerouteというプログラム（ツール）が、インターネット上に落ちている
という意味ですか？
PingPlotterの方は早速、試してみます。
>通信回線に流れ込んでいくデータが64Kbps程度であれば，
>それほど問題は起こらないはずなんですが，
>通信回線側にパケットを送っている機器が他にあれば話は別です。
>その辺，見落としはないでしょうか？
もう一度、見直してみます。
>Pushフラグはアプリケーション側でコントロールするものなので，
>アプリケーションがそうしている，というだけです。
>アプリケーションはどういったものですか？
受信したＵＤＰパケットの情報を元に音声の再生、ディスプレイへの表示を
行っています。
監視、制御などは、ＴＣＰで行っています。
具体的な名前などは、セキュリティ上の問題などから
個人的に電子メールでやりとりを希望したいです。
いかがでしょうか？
>ウインドウサイズっていうのは，要するに，
>自分の受信バッファの空き領域のサイズを相手に知らせるもので，
>相手側から通知してきた値とは関係ないですから，気にする必要はありません。
ＴＣＰでフロー制御する際に、受信側のウィンドウサイズを送信側に通知し
そのサイズに合わせて、送信側が一度に送れるサイズを調整すると
ある書籍に書いてあったので、その説明と相違する現象が今回のパケット解析で
現れていたので．．．。解析の仕方がまずかったのかな？
それでは、また．．．。
UDPの音声パケットは要注意
>tracerouteは、ＭＳ－ＤＯＳで使うtracertと同一の機能を
>持っているものだと思いますが、
そうですが，両方試す必要はありません。
PingPlotterの方がわかりやすいですから，それだけで十分です。
>受信したＵＤＰパケットの情報を元に音声の再生、ディスプレイへの表示を
>行っています。
音声や映像データをUDPで流すアプリケーションは要注意です。
UDPで音声を流すものは，受信確認を行わないことが多いのですが，
受信確認を行わないと，相手の状態や途中の混雑状態を判断できないので，
途中で混雑していてもお構いなしにパケットを垂れ流すことになります。
そのため，トラフィックが増えたときに，
ルータやスイッチの待ち行列を溢れさせる原因になりやすいからです。
音声パケットの遅延を抑制するためにルータで待ち行列を分けて
音声パケットを優先的に流すことがありますが，それはもっと要注意です。
音声パケットを優先するため，他のアプリケーションにしわ寄せがいき，
そちらのパケットが消えることになるからです。
UDPパケットが消えているのなら，
TCPのパケットも消えている可能性が高いですね。
>監視、制御などは、ＴＣＰで行っています。
>具体的な名前などは、セキュリティ上の問題などから
>個人的に電子メールでやりとりを希望したいです。
いえ，pushフラグは，現時点では重要ではないので，
そこまでは必要ありません。
>ＴＣＰでフロー制御する際に、受信側のウィンドウサイズを送信側に通知し
>そのサイズに合わせて、送信側が一度に送れるサイズを調整すると
えーと，どう説明したらいいのでしょうか。
データを送信する方は相手から通知されたウインドウサイズを超える量の
データを送らないようにします。
つまり，通知されたウインドウサイズ分だけデータを送信したら，
受信確認が返ってくるまで送信動作を一時休止する，ということです。
これが，書籍に書いてあったことの意味です。
しかし，その動きと，データ送信時にヘッダにセットするウインドウサイズの値は，
まったく関係がありません。
TCPは全二重で送受信しますから，
送信と受信が同時に実行されることを想定しています。
データ送信時にヘッダにセットするウインドウサイズの値は，
送信側のマシンが受信動作を行うときのことを考えて，
受信バッファの空き領域を相手に知らせているわけです。
各層の動きの再調査を行っています
おはようございます、小山です。
お返事が遅れて申し訳ありません。
ＵＤＰパケットが紛失しているのは、今のところないのですが、
ＴＣＰコネクション切断は、たまに発生しています。
ただ、アプリケーション層の動きで、ＵＤＰパケットが到着しても
音声が出ないことがあるなど、一筋縄では行かない部分が多々ありますので
各層の動きを再調査しています。また、進展がありましたらご連絡致します。
しばらく時間がかかりそうです。
よろしくお願い致します。