facebook twitter hatena line google mixi email
★お気に入り追加


  • 545
  •  
  • 2014/12/30(火) 02:29:54.53
>>544
これ以上の解析は結構泥臭い作業になるよ・・・?

上下がなにを指すのかいまいちわかりづらいけど、
kbnyuxz.png が受信側PC1でのキャプチャってことでOK?

一度確認しておきたいのは「どんなふうにパケットがロスしているか」なので、
送信側と受信側のパケットを一つ一つ見ていく必要がある。

TCPの基礎的な動作はググってもらえばわかるので
kbnyuxz.pngの黒くなっているところが何故黒いのか説明する。

何バイト目のデータを送信しているのかを示すseqと、
パケットのサイズlenの関係は、seq+len=[次のseq] となる。
送信側では必ず順番に送信しているので、
番号飛びはパケットロスか順序逆転を示す。

 No.87811 seq=102475189 len=1460
 No.87812 seq=102484841 len=1460 (この間8192バイト分)

直後にこの間の部分(No.87813〜)を受けっているので最終的に問題ないんだけど、
パケットロスにしては復旧が早いのが気になる。
順序逆転が起きてるのなら、ハブの動作が想定以上におかしい可能性が高い。

seq=102475189 〜 102484841 のパケットが
送信側でどう扱われているのかちょっと追いかけてみて。
再送しているのか、一度しか送っていないのか。
一度しか送ってないなら、送信タイミングに不審な点はないかなど。

・・・一応確認するけど、ネットワークの構成、PC1--GS105-- PC2 だけだよね。

ここまで見た

★お気に入り追加

このページを共有する
facebook twitter hatena line google mixi email
おすすめワード