アプリケーション層で TCP パケットが断片化されるのはいつですか? アプリケーションから TCP パケットが送信された場合、アプリケーション層の受信者はパケットを 2 つ以上のパケットで受信しますか? その場合、パケットが分割される条件は何ですか。イーサネット (ネットワーク層) の制限である 1500 バイトに達するまで、パケットはフラグメント化されないようです。しかし、ネットワーク層はパケットを次の層に送信する前にフラグメントを再構成するため、アプリケーション層の受信者にはその断片化は透過的ですよね?
63801 次
10 に答える
39
パケットのサイズよりも低い MTU を持つネットワーク デバイスにヒットすると、分割されます。ほとんどのイーサネット デバイスは 1500 ですが、追加のルーティング情報のためにイーサネットが PPPoE (DSL) 経由で接続されている場合は 1492 のように小さいことが多く、Windows インターネット接続共有のように 2 番目のレイヤーが追加されている場合はさらに低くなります。ダイヤルアップは通常 576 です。
一般に、TCP はパケット プロトコルではないことに注意してください。最下位レベルのパケットを使用して IP 経由で送信しますが、TCP スタックのインターフェイスに関する限り、これはストリーム プロトコルであり、送受信される物理パケットと 1:1 の関係を提供する必要はありません。 (たとえば、ほとんどのスタックは、特定の期間が経過するまで、または指定された MTU の IP パケットのサイズを最大化するのに十分なメッセージが存在するまで、メッセージを保持します)
例として、2 つの「パケット」を送信した場合 (send 関数を 2 回呼び出した場合)、受信プログラムは 1 つの「パケット」しか受信しない可能性があります (受信 TCP スタックはそれらを結合する可能性があります)。TCP 経由でメッセージ タイプ プロトコルを実装している場合は、メッセージが2 つの部分で受信された場合、または複数のメッセージがチャンクとして受信された場合。
于 2009-04-16T16:05:29.790 に答える
17
フラグメンテーションは、TCP アプリケーションに対して透過的である必要があります。TCP はストリーム プロトコルであることに注意してください。取得するのはパケットではなく、データのストリームです! 完全なデータ パケットのアイデアに基づいてアプリケーションを構築している場合は、抽象化レイヤーを追加してストリームからパケット全体を組み立て、パケットをアプリケーションに渡さない限り、問題が発生します。
于 2009-04-16T16:06:52.533 に答える
12
この質問は、正しくないという仮定を立てています。TCP はパケットをエンドポイントに配信せず、バイト (オクテット) のストリームを送信します。アプリケーションが 2 つの文字列を TCP に書き込む場合、もう一方の端では 1 つの文字列として配信されることがあります。同様に、一方のストリングがもう一方の端に 2 つ (またはそれ以上) のストリングとして配信される場合があります。
RFC 793、セクション 1.5:
「TCP は、インターネット システムを介して送信するために、いくつかのオクテットをセグメントにパッケージ化することにより、ユーザー間で各方向にオクテットの連続ストリームを転送できます。」
キーワードは、オクテット(バイト) の連続ストリームです。
RFC 793、セクション 2.8:
「プッシュ関数とセグメント境界の間に必要な関係はありません。特定のセグメントのデータは、全体または一部の単一の SEND 呼び出しの結果、または複数の SEND 呼び出しの結果である可能性があります。」
セクション 2.8 全体が該当します。
于 2010-04-20T20:50:59.117 に答える
5
At the application layer there are any number of reasons why the whole 1500 bytes may not show up one read. Various factors in the internal operating system and TCP stack may cause the application to get some bytes in one read call, and some in the next. Yes, the TCP stack has to re-assemble the packet before sending it up, but that doesn't mean your app is going to get it all in one shot (it is LIKELY will get it in one read, but it's not GUARANTEED to get it in one read).
TCP tries to guarantee in-order delivery of bytes, with error checking, automatic re-sends, etc happening behind your back. Think of it as a pipe at the app layer and don't get too bogged down in how the stack actually sends it over the network.
于 2009-04-16T15:59:22.567 に答える
2
異なるネットワーク セグメントは、異なる MTU 値を持つことができます。その場合、断片化が発生する可能性があります。詳細については、TCP 最大セグメント サイズを参照してください。
この (デ) フラグメンテーションは TCP レイヤーで発生します。アプリケーション層には、これ以上パケットはありません。TCP は、連続したデータ ストリームをアプリケーションに提供します。
于 2009-04-16T15:54:54.933 に答える
2
パケットがネットワーク デバイスの最大MTUを超えると、複数のパケットに分割されます。(ほとんどの機器は 1500 バイトに設定されていますが、これは必須ではありません。)
パケットの再構築は、アプリケーションに対して完全に透過的である必要があります。
于 2009-04-16T15:53:09.290 に答える
2
「アプリケーション層」のTCPパケット（まあ、実際にはセグメントです。独自の層のTCPはパケットからはわかりません）が存在しないため、断片化されることはありません。アプリケーション層では、データがバイト ストリームとして表示され、確実に順序どおりに配信されます。
それ以外のことを考えている場合は、おそらく間違った方法で何かに取り組んでいます。ただし、これは、この上に層がない可能性があると言っているわけではありません。たとえば、この信頼性の高い順序どおりのバイトストリームを介して配信される一連のメッセージです。
于 2009-06-06T06:44:19.513 に答える
2
このページは、他の人が提起した問題のいくつか、つまり、アプリケーション プロトコルごとのアプリケーション プロトコルでのデータ カプセル化の必要性に関する優れた情報源です。あなたが説明した意味ではあまり信頼できませんが、例があり、いくつかの情報源があります。ネットワークプログラミングのかなりの有名人。
于 2010-04-28T23:36:03.937 に答える
1
Correct - the most informative way to see this is using Wireshark, an invaluable tool. Take the time to figure it out - has saved me several times, and gives a good reality check
于 2009-04-16T15:53:30.660 に答える
0
3000 バイトのパケットが、デフォルトの MTU サイズが 1500 (イーサネットの場合) のイーサネット ネットワークに入ると、長さがそれぞれ 1500 バイトの 2 つのパケットにフラグメント化されます。そんな時しか思い浮かびません。
これを確認するには、Wireshark が最適です。私はしばらくそれを使用しており、完全に感銘を受けています
于 2009-04-16T15:52:47.357 に答える