5

libpcapを使用してパケットをキャプチャし、TCPストリームを再構築するプログラムを作成しています。私のプログラムは単にトラフィックを監視しているだけなので、パケットの受信と送信を制御することはできません。私のプログラムは、TCP/IP以外のトラフィックをすべて無視します。

ISNから次に予想されるシーケンス番号を計算し、次に連続するSEQ番号を計算します。すべてのTCP接続が、送信元IP、送信元ポート、宛先IP、および宛先ポートで構成されるタプルによって一意に識別されるように設定しています。予想とは異なるシーケンス番号のパケットを受信するまで、すべてが順調に進んでいます。ここで説明していることを説明するために、スクリーンショットをアップロードしました。

私の質問は次のとおりです。1。「失われた」パケットにあったデータはどこにありますか？2.この状況からSEQ番号の順序はどのように回復しますか？3.これらの発生を処理するために何ができますか。

思い出してください; ただし、TCPに準拠したプログラムは作成していません。TCPストリームのネットワークトラフィックを受動的に監視し、生データをディスクに保存しようとするプログラムを書いていますが、上記の状態が発生する理由と、それを処理するためのプログラム方法について混乱しています。

ありがとうございました

4

2 に答える 2

13

「失われた」パケットにあったデータはどこにありますか？

  • 誰かに落とされた
  • 途中で迷子になり（迂回が間違って）、後で到着します

この状況からSEQ番号の順序はどのように回復しますか

受信者は、セグメントの順序が狂っていることに気づき、それをアプリケーションに送信しないため、その契約を履行します。つまり、高信頼バイトストリームを順番に実行します。さて、実際に欠けている部分を取得するために起こることは非常に複雑で、スタックごとに異なります。一言で言えば、スタックは不足している部分が到着するのを待ちます。

  • 受信者は、順序が正しくないセグメントを破棄したり、再構成キューにキューに入れたりすることができます
  • 受信者は、欠落しているセグメントが到着するのを待つか、前に送信したACKをすぐに送信できます。ACKが重複していると、ピアに何か問題があることを警告します（高速再送信を探してください）
  • 確認応答を送信するとき、TCPはピアにいくつかのセグメントが正常に到着したことを通知できます-それらはシーケンスから外れています（SACK）

これらの発生を処理するために何ができますか

監視しているだけなので、何もできません。応答トラフィックもキャプチャした場合、実際に何が起こっているのかについて、より多くの洞察を得ることができるでしょう。

于 2012-07-31T19:02:59.577 に答える
1

現在のTCP接続のウィンドウサイズに応じて、新しいパケットが受信ウィンドウ（マルチパケットバッファ）内に収まる場合、受信キューに入れられます（そして、プロトコルクライアントへの順序付けされた配信のために並べ替えられます）。

シーケンス番号が現在のウィンドウの最大値よりも大きい場合、パケットは拒否されます。

RFC 675のセクション4.4.2（INPUT PACKET HANDLER）も参照してください。

于 2012-07-31T19:02:23.130 に答える