0

最近、私はネットワーク プロトコルと OSI モデルの問題をもう少し深く掘り下げました。気付いたとき、着信 TCP データグラム (これが間違った用語である場合は訂正してください) は、特定のサイズを超えると、いくつかの部分に分割されます。おそらくルーターのMTUです。この情報をどこから入手したか疑問に思っている場合は、探している情報を抽出するために、SharpPcap を使用してこれらのデータグラムをキャプチャしました。

とにかく、断片化されたパケットの再構成が IP 層のタスクであってはならないのではないかと考えていました。IP 層は、これを達成するための情報 (ID、断片化フラグ、断片オフセット) を確実に提供するからです。さらに、TCPレイヤーはストリームベースのプロトコルとして解釈されることを読みました。しかし、これは実際には、アプリケーションのバッファを正しい方法で埋めるのは TCP 層次第であることを意味します。これにより、情報の最初の部分が再構築され、それ以降のすべての層で「フラッシュ」される可能性があります。

この観察を行う前に、実際には、TCP レイヤーはこれらのデータグラムの再構築を気にする必要があると考えていましたが、言及されたレイヤーはどれも気にしません...

これは、次の質問につながります: 受信した TCP データグラムが再構築されないのはなぜですか? また、実際にこれを処理する必要があるのはどのレイヤーですか?

4

1 に答える 1

1

IP レイヤーは、断片化と再構成を処理します ( http://en.wikipedia.org/wiki/IP_fragmentation ) 。

winpcap/airpcap/libpcap を使用する SharpPcap などのツールを使用すると、キャプチャしているデバイスから生データグラムを受信して​​います。多くのアダプタでは、これは IP フレームなどを含むイーサネット データグラムです。

これは、再構成が実行されるネットワーク スタックによる処理後に受信されるデータとは対照的です。

そのため、再構築を実行しているネットワーク スタックの出力として内部ではなく、アダプター レベルでデータがキャプチャされているため、SharpPcap (または他の多くのキャプチャ ライブラリ) から再構築されたデータグラムを取得しないことが予想されます。

再構成は、キャプチャ後に自分で実行するか、この機能を提供するライブラリを使用して実行できます。このようなコンポーネントを Packet.Net (SharpPcap が使用しているパケット処理ライブラリ) に追加して、この再構成を提供することもできます。

于 2014-09-02T21:48:49.820 に答える