イーサネットフレームの「有線」サイズとは何ですか？ 1518または1542？
ここの表 によると、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をどのように思いついたかはわかりません。
ウィキペディアの図は恐ろしいです。うまくいけば、私が書こうとしていることがより明確になります。
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バイト
最後に、イーサネットトランシーバがフレームの送信を完了すると、802.3は次のフレームの送信を許可される前に、12バイトの無音（ "Interframe Gap"）を送信する必要があります。[Preamble+SFD+[Ethernet Frame]+Silence] <-1542バイトがネットワーク上で送信されました。
プリアンブル、SFD、インターフレームギャップはフレームの一部としてカウントされません。これらは、イーサネットプロトコル自体のサポート構造です。
MTUはペイロードに適用されます。これは、パケットに詰め込むことができるデータの最大の単位です。したがって、MTUが1500バイトのイーサネットパケットは、実際には1522バイトのフレームであり、回線上では1542バイトです（vLANタグがあると想定）。
だからあなたの質問への答え-断片化なしで802.3イーサネット経由で送信できる最大のパケットは何ですか？-は1500バイトのペイロードデータ。
[〜＃〜]ただし、[〜＃〜]イーサネット層は制限要因ではない可能性があります。途中で何かがMTUをペイロードデータの1500バイト未満に制限しているかどうかを検出するには、次のいずれかを使用します。
- ウィンドウズ：
ping hostname -f -l sizeofdata（John Kの技術について言及） - BSD：
ping -D -s sizeofdata hostname - Linux：
ping -M do -s sizeofdata hostname
機能するsizeofdataの最大値はMTUです（データが取る特定のパス上）。
フレームに入れるデータの量によって異なります。フレームに1500バイトのデータを入れると、合計フレームサイズは1518バイトになります。 1472バイトのデータで、合計フレームサイズは1500になります。
http://en.wikipedia.org/wiki/Ethernet_frame
とはいえ、断片化のテストに本当に興味がある場合、これをテストする良い方法は、いくつかのフラグを付けた古き良きpingを使用することです。
pingホスト名-f -l sizeofdata
-fフラグを指定すると、パケットがフラグメント化されている場合にpingが失敗します。ここで理解する重要なポイントは、「sizeofdata」が断片化せずにメッセージに入れることができるデータの量です。つまり、1500のペイロードを送信すると、1500バイトを超えると断片化が始まります。ただし、これを1472（1500-18バイトのオーバーヘッド）に下げると、pingが通過することがわかります。
基本的なEthernet_IIフレームの場合、フレームサイズは1518バイトです（回線上または回線外）。これは、宛先アドレスと送信元アドレスのそれぞれに6バイト、ペイロードの46〜1500バイトのタイプフィールドに2バイト（IPヘッダーとUDPヘッダーを含むIPパケット全体）および4バイトで構成されます。 FCS。これに加えて、フレームがどれだけ小さいか（64バイト）にも制限があります。これが、範囲が46バイトからである理由です（これを2つのアドレスとタイプおよびFCSに追加すると、64バイトになります-46 + 6 + 6 + 2 + 4 = 64）。
フレームが複数のVLANをサポートするネットワーク上にあり、フレームにVLANタグをタグ付けする必要がある場合は、タイプフィールドの前に1つのフィールドが追加されます。これは4バイトです。これは、ペイロードのサイズの範囲を下端で4バイト減らしても、最小で64バイトであることを意味します。したがって、42です（したがって、vlanタグの場合、42 + 6 + 6 + 2 + 4 + 4 = 64）。
したがって、範囲が1500〜42と書かれている場合、1500から42を引いたものではなく、1500〜42バイトのいずれかが有効であることを意味します。ワイヤーの1つであるこのタグ付きフレームは、最大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バイトの伝送スペースを占有します。
わかりやすくなることを願っています。