Каков размер in-the-wire рамки Ethernet? 1518 или 1542?

В соответствии с приведенной здесь таблицей говорится, что MTU = 1500 байт и что часть полезной нагрузки составляет 1500 - 42 байта или 1458 байт (<- это на самом деле неправильно!). Кроме того, вы должны добавить заголовки IPv4 и UDP, которые составляют 28 байтов (20 IP + 8 UDP). Это оставляет мое максимально возможное сообщение приложения до 1430 байт! Но, глядя на этот номер в Интернете, я вижу вместо этого 1472. Я делаю этот расчет неправильно здесь?

Все, что я хочу узнать, это максимальное количество сообщений, которое я могу отправить по сети без риска фрагментации. Это определенно не 1500, потому что это включает заголовки кадра. Может кто-нибудь помочь?

Путаница заключается в том, что PAYLOAD может достигать 1500 байт, и это MTU. Так что теперь, какой размер в проводе для полезной нагрузки 1500? Из этой таблицы он может достигать 1542 байта.

Таким образом, максимальное количество сообщений приложения, которое я могу отправить, составляет 1472 (1500 - 20 (ip) - 8 (udp)) для максимального размера провода 1542. Меня удивляет, как все может быть настолько сложно, когда они на самом деле просты. И я не имею понятия, как кто-то придумал число 1518, если в таблице написано 1542.

Диаграмма в Википедии ужасна. Надеюсь, то, что я сейчас напишу, понятнее.

Максимальная полезная нагрузка в сети Ethernet 802.3 составляет 1500 байт.
Это данные, которые вы пытаетесь отправить по проводам (и на что ссылается MTU).
[payload]<- 1500 байт

Полезная нагрузка инкапсулирована в кадр Ethernet (который добавляет MAC-адрес источника / назначения, тег VLAN, длину и контрольную сумму CRC. Это всего 22 байта дополнительной «вещи»
[SRC+DST+VLAN+LENGTH+[payload]+CRC]<- 1522 байта

Кадр передается по проводам - ​​перед тем, как ваша сетевая карта сделает это, она в основном встает и очень громко кричит, чтобы убедиться, что никто больше не использует провод (CSMA / CD) - это разделитель преамбулы и начала кадра (SFD) - дополнительно 8 байт, поэтому теперь у нас есть:
[Preamble+SFD+[Ethernet Frame]]<- 1530 байт

Наконец, когда приемопередатчик Ethernet завершает отправку кадра, 802.3 требует, чтобы он передал 12 байтов тишины («межкадровый разрыв»), прежде чем ему будет разрешено отправить свой следующий кадр.
[Preamble+SFD+[Ethernet Frame]+Silence]<- 1542 байта передано по проводам.

Преамбула, SFD и межкадровый разрыв не учитываются как часть кадра. Они поддерживают структуру самого протокола Ethernet.

MTU применяется к полезной нагрузке - это самая большая единица данных, которую вы можете втиснуть в пакет. Таким образом, пакет Ethernet с MTU 1500 байт будет на самом деле 1522-байтным кадром и 1542 байт на проводе (при условии, что есть тег vLAN).

Итак, ответ на ваш вопрос - Какой самый большой пакет я могу отправить по сети 802.3 без фрагментации? - 1500 байт данных полезной нагрузки .

ОДНАКО слой Ethernet не может быть вашим ограничивающим фактором. Чтобы выяснить, ограничивает ли что-нибудь в процессе MTU размер менее 1500 байт данных полезной нагрузки, используйте одно из следующих:

• Windows: ping hostname -f -l sizeofdata(упомянутая техника Джона К)
• 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 hostname -f -l sizeofdata

Флаг -f вызовет сбой проверки связи, если пакет фрагментирован. Ключевым для понимания здесь является «sizeofdata» - это объем данных, который вы можете поместить в сообщение без фрагментации - поэтому, если вы отправите полезную нагрузку в 1500, вы начнете фрагментировать, когда пройдете более 1500 байт. Снизьте это до 1472 (1500 - 18-байтовые накладные расходы), и вы увидите, что эхо-запросы проходят.

Для базового кадра Ethernet_II размер кадра составляет 1518 байт (на проводе или без него). Он состоит из 6 байтов для каждого адреса назначения и источника, 2 байта для поля типа от 46 до 1500 байтов для полезной нагрузки (в вашем случае весь пакет IP с его заголовком IP и заголовком UDP) и 4 байта для ФТС. В дополнение к этому есть ограничение на размер кадра (64 байта). Вот почему диапазон составляет от 46 байтов (добавьте это к двум адресам, типу и FCS, и вы получите 64 байта - 46 + 6 + 6 + 2 + 4 = 64).

Если фрейм находится в сети, которая поддерживает несколько vlan, и вам нужно пометить фрейм тегом vlan, то перед полем типа добавляется одно дополнительное поле. Это 4 байта. Теперь это означает, что диапазон размеров для полезной нагрузки может быть уменьшен на 4 байта в нижней части и при этом иметь как минимум 64 байта. Отсюда 42. (То есть 42 + 6 + 6 + 2 + 4 + 4 для тега vlan = 64)

Таким образом, когда диапазон записан 1500-42, это не означает 1500 минус 42, это означает, что допустимо что-нибудь от 1500 до 42 байтов. В одном случае этот помеченный кадр может быть размером до 1522 байтов (если используется только один тег, или 1526, если используются два тега). Ничто из этого не объясняет число 1542.

Чтобы добраться до этого номера, вам нужно подумать, как кадр может быть отправлен по Ethernet. В локальной сети Ethernet нет часов, поэтому передатчик кадра посылает серию из 1 и 0 для установки часов. Это называется преамбулой. Не каждый слушатель «услышит» всю преамбулу, но большинство должно услышать какую-то ее часть. Чтобы сообщить об окончании преамбулы, один из последних 8 отправленных битов переворачивается так, что вместо 10101010 он становится 10101011. Этот байт называется началом ограничителя кадра (SDF). Это технически бесполезно для захвата без проводов, поэтому 7 байтов преамбулы и 1-байтовый SDF обычно не учитываются, но если бы они были нашими первоначальными 1518, то теперь было бы 1526. Тем не менее, 1542 ..

После того, как кадр отправлен, на проводе действует вынужденная тишина, которая называется межкадровым промежутком. Это эквивалентно передаче 12 байтов. Это также не учитывается и не захватывается, но если бы это было так, мы бы получили 1538 байт. Единственный способ добраться до 1542 из 1538 - это сказать, что фрейм помечен (т. Е. Он содержит 4-байтовый тег плана). Фу, 1542 наконец.

Это все в терминологии. Стандартная рамка составляет 1518 байт на проводе (что касается любого устройства захвата). Кадр с тегом (одиночный тег) составляет 1522 байта на проводе. Они занимают 1538 байтов или 1542 байта пространства передачи на проводе.

Надеюсь, что это помогает уточнить ..

нет, вы хотите, чтобы фрагментация происходила, вот почему вы получаете пакет, который должен быть фрагментирован, но если установить df, возьмите его так, как это двухстороннее шоссе с целой кучей полуфиналов против одной и той же трассы с целой кучей маленьких умных машин, которые оба собираются те же самые полуфиналы назначения несут большую полезную нагрузку, но они медленнее и могут загружать легче, меньшие автомобили перевозят меньше, но едут быстрее MSS также не то же самое, что MTU