web-dev-qa-db-ja.com

イーサネットフレームの「有線」サイズとは何ですか? 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をどのように思いついたかはわかりません。

22
chrisapotek

ウィキペディアの図は恐ろしいです。うまくいけば、私が書こうとしていることがより明確になります。


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です(データが取る特定のパス上)。

27
voretaq7

フレームに入れるデータの量によって異なります。フレームに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が通過することがわかります。

2
Univ426

基本的な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バイトの伝送スペースを占有します。

わかりやすくなることを願っています。

0
Joevpt