によるとここのテーブル、MTU = 1500 バイト、ペイロード部分は 1500 - 42 バイト、つまり 1458 バイト (<- これは実際には間違っています!) と書かれています。さらに、28 バイト (20 IP + 8 UDP) の IPv4 および UDP ヘッダーを追加する必要があります。これで、アプリケーション メッセージの最大可能サイズは 1430 バイトになります。しかし、インターネットでこの数字を検索すると、1472 が表示されます。この計算は間違っていますか?
私が知りたいのは、断片化のリスクなしにネットワーク経由で送信できる最大のアプリケーション メッセージだけです。フレーム ヘッダーが含まれているため、1500 ではないことは確かです。誰か助けてくれませんか?
混乱を招くのは、PAYLOAD が実際には最大 1500 バイトになる可能性があり、それが MTU であることです。では、1500 のペイロードの伝送サイズはどのくらいでしょうか? この表から、最大 1542 バイトになる可能性があることがわかります。
したがって、送信できるアプリ メッセージの最大数は 1472 (1500 - 20 (IP) - 8 (UDP)) で、ワイヤ サイズの最大数は 1542 です。実際には単純なのに、こんなに複雑になるなんて驚きです。また、表に 1542 と記載されているのに、なぜ 1518 という数字が出てくるのか、私にはわかりません。
答え1
Wikipedia の図はひどいです。これから書くことがもっと明確になれば幸いです。
最大ペイロード802.3 イーサネットでは 1500 バイトです。
これは、回線経由で送信しようとしているデータです (MTU が参照しているもの)。
[payload]<- 1500 バイト
ペイロードはイーサネットフレーム（送信元/宛先 MAC、VLAN タグ、長さ、CRC チェックサムを追加します。合計 22 バイトの追加「要素」
[SRC+DST+VLAN+LENGTH+[payload]+CRC]<- 1522 バイト）
フレームはワイヤーを介して送信されます。イーサネットカードが送信する前に、基本的に立ち上がって大声で叫び、他の誰もワイヤーを使用していないことを確認します（CSMA/CD）。これが前文そしてフレーム開始区切り文字(SFD) -- 8バイト追加なので、合計は次のようになります:
[Preamble+SFD+[Ethernet Frame]]<- 1530バイト
最後に、イーサネット トランシーバーがフレームの送信を完了すると、次のフレームを送信する前に 12 バイトの無音 (「フレーム間ギャップ」) を送信することが 802.3 によって要求されます。
[Preamble+SFD+[Ethernet Frame]+Silence]<- 1542 バイトが回線上で送信されます。
プリアンブル、SFD、インターフレームギャップはフレームの一部としてカウントされません。これらは、イーサネット プロトコル自体のサポート構造です。
MTU はペイロードに適用されます。ペイロードはパケットに詰め込める最大のデータ単位です。したがって、MTU が 1500 バイトのイーサネット パケットは、実際には 1522 バイトのフレームとなり、回線上では 1542 バイトとなります (vLAN タグがあると仮定)。
あなたの質問に対する答えは -断片化せずに 802.3 イーサネット経由で送信できる最大のパケットはどれくらいですか?- は1500バイトのペイロードデータ。
しかしイーサネット層が制限要因ではない可能性があります。途中で何かが MTU をペイロード データの 1500 バイト未満に制限しているかどうかを確認するには、次のいずれかを使用します。
- Windows:
ping hostname -f -l sizeofdata(John K が言及したテクニック) - BS: いいえ
ping -D -s sizeofdata hostname - リナックス:
ping -M do -s sizeofdata hostname
機能する最大値はsizeofdataMTU (データが通過する特定のパス上) です。
答え2
フレームに入れるデータの量によって異なります。フレームに 1500 バイトのデータを入れると、フレームの合計サイズは 1518 バイトになります。1472 バイトのデータを入れると、フレームの合計サイズは 1500 になります。
http://en.wikipedia.org/wiki/イーサネットフレーム
そうは言っても、断片化のテストに本当に興味があるなら、いくつかのフラグを付けた古き良き ping でテストするのが良い方法です。
ping ホスト名 -f -l データサイズ
-f フラグは、パケットが断片化されている場合に ping が失敗する原因となります。ここで理解すべき重要な点は、「sizeofdata」は断片化せずにメッセージに入れることができるデータ量であるということです。つまり、1500 のペイロードを送信すると、1500 バイトを超えると断片化が始まります。ただし、これを 1472 (1500 - 18 バイトのオーバーヘッド) に下げると、ping が通過することがわかります。
答え3
基本的な Ethernet_II フレームの場合、フレーム サイズは 1518 バイトです (回線上または回線外)。これは、宛先アドレスと送信元アドレスのそれぞれに 6 バイト、ペイロード (この場合、IP ヘッダーと UDP ヘッダーを含む IP パケット全体) に 46 ～ 1500 バイトのタイプ フィールドの 2 バイト、FCS に 4 バイトで構成されます。これに加えて、フレームのサイズには制限があります (64 バイト)。これが、範囲が 46 バイトからである理由です (これに 2 つのアドレスとタイプと FCS を加えると、64 バイト - 46+6+6+2+4=64)。
フレームが複数の VLAN をサポートするネットワーク上にあり、フレームに VLAN タグを付ける必要がある場合は、タイプ フィールドの前に 1 つのフィールドが追加されます。これは 4 バイトです。つまり、ペイロードのサイズの範囲は、下端で 4 バイト削減されても、最小 64 バイトは維持されます。したがって、42 です (つまり、42+6+6+2+4 + VLAN タグの 4 = 64)
したがって、範囲が 1500-42 と書かれている場合、それは 1500 から 42 を引いた値を意味するのではなく、1500 から 42 バイトまでが有効であることを意味します。回線上では、このタグ付きフレームは最大 1522 バイト (タグが 1 つだけ使用されている場合、またはタグが 2 つ使用されている場合は 1526 バイト) になる可能性があります。このどれも 1542 という数字を説明するものではありません。
この数字を得るには、フレームがイーサネット上でどのように送信されるかを考慮する必要があります。イーサネット LAN にはクロックがないため、フレームの送信側から一連の 1 と 0 が送信され、クロックが設定されます。これはプリアンブルと呼ばれます。すべてのリスナーがプリアンブルのすべてを「聞く」わけではありませんが、ほとんどのリスナーは一部を聞くはずです。プリアンブルの終了を通知するために、送信された最後の 8 ビットの 1 つが反転され、10101010 ではなく 10101011 になります。このバイトはフレーム開始デリミタ (SDF) と呼ばれます。これは技術的にはワイヤからキャプチャするのに役立たないため、通常はプリアンブルの 7 バイトと 1 バイトの SDF はカウントされませんが、元の 1518 であれば 1526 になります。それでも 1542 ではありません。
フレームが送信された後、フレーム間ギャップと呼ばれる、ワイヤ上での強制的な無音状態が発生します。これは 12 バイトの送信に相当します。これもカウントもキャプチャもされませんが、カウントまたはキャプチャされるとすると 1538 バイトになります。1538 から 1542 に到達する唯一の方法は、フレームにタグが付いている (つまり、4 バイトのプラン タグが含まれている) と言うことです。やれやれ、ついに 1542 になりました。
すべては用語に表れています。標準フレームは、回線上で 1518 バイトです (キャプチャ デバイスに関する限り)。タグ付きフレーム (単一タグ) は、回線上で 1522 バイトです。これらは、回線上で 1538 バイトまたは 1542 バイトの送信スペースを占有します。
それが明確になる助けになれば幸いです。
答え4
いいえ、断片化が発生することを望んでいます。これがパケットを断片化する必要がある理由ですが、DFセットでは次のように考えます。多数の大型トレーラーが走る双方向の高速道路と、同じ目的地に向かう多数の小型スマートカーが走る同じ高速道路。大型トレーラーはより多くのペイロードを運びますが、速度が遅く、混雑しやすくなります。小型車は運ぶペイロードは少なくなりますが、より速く移動します。MSSはMTUと同じではありません。