ここで、単一(?) TCP パケットが複数の PDU ユニットに分割されるのはなぜですか?

Question 1

56～78の範囲の可視フレームについて言及していると思います。
この順番で対処しましょう。

概要: " TCP segment of a reassembled PDU"
これは、Wireshark (ethereal?) が TCP セグメントを再構成して表示したことを意味します。
したがって、この文字列は無視しても問題ありません。
^{これらのフレームが何であるかについては、以下のポイント 4 で詳しく説明しています。}
概要: 同じ「seq」番号を持つ異なるフレーム。
フレーム58、60、62、64などは同じシーケンス番号を示しています。
ただし、これらはない1 つのパケットが「個別のパケットとしてマーク」され、分割されません。
これらのパケットには ' ACK' フラグのみがセットされており、ACK 番号が増加していることがわかります。
これらは、異なる TCP セグメントが HTTP サーバーに到達したときに、マシンから HTTP サーバーに送信された ACK です。
' ACK' シーケンスは、1フレームので始まり52、9646FIN フレームので終わります78。
この間、ブラウザから HTTP サーバへのすべてのフレームは、最後に送信されたシーケンス番号 ( 609) を繰り返します。これは、TCP プロトコルの通常の動作です。
ブラウザは、最初の HTTP 要求 (フレーム ) 以降、それ以上データを送信しません52。HTTP
サーバは、フレームでこれを確認しました54。
54フレームは、「再構成された PDU の TCP セグメント」とマークされたフレームで形成された (Wireshark) 再構成されたサーバー応答であると予想しています。
したがって、そのようにマークされた後続のフレームはすべて、HTTP サーバーからクライアントへのものです
(ソース列と宛先列をスクラブしたため、その詳細は画像には表示されません)。

元のキャプチャファイルを再確認すると、TCP ソースポート 80 (HTTP の場合) を持つフレーム 54 から 67 が、HTTP サーバーからの 9646 バイトの応答データになることがわかります。

ここで表示されるのは、HTTP サーバーからの 9 KB の応答が、MTU 制限のある複数の TCP セグメントとしてブラウザーに到達し、それぞれが OS の TCP スタックによって確認されたものです。

これは通信の高レベルのシーケンスです。

ブラウザは 3 ウェイ TCP ハンドシェイクを使用して HTTP サーバーへの接続を開始しました。
この接続でサーバーに単一のHTTPリクエストを送信しました
サーバーはこれに9KBの応答を返し、それは複数のTCP/IPパケットに分散されました（TCP セグメント）
ブラウザマシンのTCP/IPスタックは、サーバーから受信した各TCPパケットを確認しました。
最後に、パケットから始まる接続が閉じられましたFIN。フレーム 78 以降に
さらにいくつかのパケット (または 1 つのパケット) があったと予想さFINれACKますRST。

WiresharkのTCP再構成処理の詳細については、Wireshark ウィキ。

Answer

56～78の範囲の可視フレームについて言及していると思います。
この順番で対処しましょう。

概要: " TCP segment of a reassembled PDU"
これは、Wireshark (ethereal?) が TCP セグメントを再構成して表示したことを意味します。
したがって、この文字列は無視しても問題ありません。
^{これらのフレームが何であるかについては、以下のポイント 4 で詳しく説明しています。}
概要: 同じ「seq」番号を持つ異なるフレーム。
フレーム58、60、62、64などは同じシーケンス番号を示しています。
ただし、これらはない1 つのパケットが「個別のパケットとしてマーク」され、分割されません。
これらのパケットには ' ACK' フラグのみがセットされており、ACK 番号が増加していることがわかります。
これらは、異なる TCP セグメントが HTTP サーバーに到達したときに、マシンから HTTP サーバーに送信された ACK です。
' ACK' シーケンスは、1フレームので始まり52、9646FIN フレームので終わります78。
この間、ブラウザから HTTP サーバへのすべてのフレームは、最後に送信されたシーケンス番号 ( 609) を繰り返します。これは、TCP プロトコルの通常の動作です。
ブラウザは、最初の HTTP 要求 (フレーム ) 以降、それ以上データを送信しません52。HTTP
サーバは、フレームでこれを確認しました54。
54フレームは、「再構成された PDU の TCP セグメント」とマークされたフレームで形成された (Wireshark) 再構成されたサーバー応答であると予想しています。
したがって、そのようにマークされた後続のフレームはすべて、HTTP サーバーからクライアントへのものです
(ソース列と宛先列をスクラブしたため、その詳細は画像には表示されません)。

元のキャプチャファイルを再確認すると、TCP ソースポート 80 (HTTP の場合) を持つフレーム 54 から 67 が、HTTP サーバーからの 9646 バイトの応答データになることがわかります。

ここで表示されるのは、HTTP サーバーからの 9 KB の応答が、MTU 制限のある複数の TCP セグメントとしてブラウザーに到達し、それぞれが OS の TCP スタックによって確認されたものです。

これは通信の高レベルのシーケンスです。

ブラウザは 3 ウェイ TCP ハンドシェイクを使用して HTTP サーバーへの接続を開始しました。
この接続でサーバーに単一のHTTPリクエストを送信しました
サーバーはこれに9KBの応答を返し、それは複数のTCP/IPパケットに分散されました（TCP セグメント）
ブラウザマシンのTCP/IPスタックは、サーバーから受信した各TCPパケットを確認しました。
最後に、パケットから始まる接続が閉じられましたFIN。フレーム 78 以降に
さらにいくつかのパケット (または 1 つのパケット) があったと予想さFINれACKますRST。

WiresharkのTCP再構成処理の詳細については、Wireshark ウィキ。

Question 2

図は見えませんが、下位レベルのプロトコル (たとえば、イーサネット) は、上位レベルのプロトコル (たとえば、TCP パケット) を MTU (最大転送単位) のサイズに基づいてフラグメントに分割できます。

Answer

図は見えませんが、下位レベルのプロトコル (たとえば、イーサネット) は、上位レベルのプロトコル (たとえば、TCP パケット) を MTU (最大転送単位) のサイズに基づいてフラグメントに分割できます。

Question 3

Wikipediaの定義プロトコルデータユニット次のように：

電気通信において、プロトコルデータユニット (PDU) という用語には、次の意味があります。

ネットワークのピアエンティティ間で単位として配信され、制御情報、アドレス情報、またはデータが含まれる可能性がある情報。

階層化システムでは、特定の層のプロトコルで指定され、その層のプロトコル制御情報とユーザーデータで構成されるデータの単位。例: ブリッジ PDU または iSCSI PDU1

PDUは、最初の4つの層のそれぞれに関連しています。OSIモデル(レイヤー 5 以上はデータと呼ばれます)。

したがって、実際には、PDU は、独自のコンテキストで定義された単なるデータ単位です。

からWireSharkを理解する:

パケットが 1 つにまとまらず、複数のプロトコルデータユニット (PDU) として到着する場合があります。WireShark はこれらのユニットを 1 つのパケットに再構成しようとします。このようなパケットは再構成された PDU と呼ばれます。

再構成された PDU を使用する場合、表示は通常のパケットほどきれいではありません。応答のヘッダーは、図 2.11 の下部のペインに表示されます。

つまり、これらは TCP/IP メッセージのセグメントであり、通常は最後のセグメントにのみ TCP/IP メッセージに関する意味のある完全な情報が含まれています。

から再構成された PDU の Wireshark TCP セグメント:

TCP プロトコル設定で「サブディセクタによる TCP ストリームのセグメント化解除を許可する」のチェックを外すと、TCP セグメントの再構成を無効にすることができます。これにより、アプリケーション PDU のすべての部分が個別に表示されます。

これは、最後のパケットだけでなく、TCP/IP セグメントを意味のある形で表示するために必要なすべての情報がすべてのセグメントに含まれるようにするための方法です。

Answer