Вы не указали, о каких сетевых технологиях вы говорили, поэтому я собираюсь принять Ethernet и IP [v4].
Ethernet всегда определял диапазон допустимой длины полезной нагрузки от 46 до 1500 байт и требует, чтобы все устройства (хосты и коммутаторы) в локальной сети могли принимать кадры с полезной нагрузкой 1500 байт. Из - за этого, Ethernet не обеспечивает механизм фрагментации, а также не обеспечивают механизм для общения или переговоров значение MTU (или, что более важно, M R Us - Maximum Receive Units) между устройствами. Фактически термин "MTU" или "максимальная единица передачи" нигде не встречается в спецификации IEEE 802.3.
Итак, давайте добавим IP в картинке. IP имеет концепцию MTU, и большинство современных IP-стеков позволяют вам устанавливать MTU для каждого интерфейса (и более). Но ваш вопрос, как указано, не совсем работает и в контексте IP, потому что IP имеет минимальный MTU 576. Итак, позвольте мне повторить ваш вопрос так: «M1 имеет MTU 600, а M2 имеет MTU 1200». Но какой MTU мы скажем, что есть у "Switch"? Что ж, если коммутатор является просто коммутатором Ethernet уровня 2, у него нет концепции настраиваемого MTU. Таким образом, чтобы ваш вопрос работал в контексте IP, мы должны превратить этот коммутатор в маршрутизатор. Итак, давайте назовем его "Маршрутизатор" и скажем, что он имеет два интерфейса Ethernet, один из которых подключен к M1, а другой - к M2. Скажем также, что на обоих его интерфейсах установлено значение MTU 1200.
- Когда M1 отправляет кадр с 600-байтовой полезной нагрузкой на M2, проблем не будет.
- Когда M2 отправляет кадр с полезной нагрузкой 1200 байт на M1, проблем не будет. Почему бы и нет? Потому что установка MTU в M1 не обязательно изменяет MRU, и, по моему опыту, MTU и MRU являются отдельными, и реализации не дают вам способа изменить ваше MRU. Таким образом, MRU для этого интерфейса будет 1500, так как это Ethernet.
- Маршрутизатор не будет знать, что ему нужно фрагментировать кадры из M2, потому что он считает, что все хосты в локальной сети Ethernet, в которой находится M1, способны принимать кадры с полезной нагрузкой 1200 байт, потому что он был настроен для 1200-байтового MTU на этом интерфейс. К счастью, это все равно, вероятно, сработает, как я уже говорил в (2).
Хорошо, все еще пытаясь найти и ответить на истинный дух вашего вопроса, скажем, связь между M1 и Router на самом деле PPP вместо Ethernet. Протокол PPP позволяет хостам связываться / согласовывать свои MRU. Скажем, M1 сказал Router, что M1 имеет ограничение MRU 600 байт, поэтому Router установил свой MTU для этой ссылки в 600 байтов.
Теперь, в этом случае, если M2 отправит 1200-байтовую IP-дейтаграмму в M1 (без установки бита «Не фрагментировать» в заголовке IP), маршрутизатор получит его очень хорошо и поймет, что ему нужно фрагментировать его для отправки это к М1. Итак, маршрутизатор разбивает его на два 600-байтовых фрагмента? Ну, нет, это не так просто по нескольким причинам.
Одна из причин заключается в том, что каждый фрагмент должен иметь свой собственный IP-заголовок, который добавляет 20 байтов к размеру каждого фрагмента после первого. Другая причина заключается в том, что поле смещения фрагментации IP считается в 8-байтовых блоках вместо отдельных байтов.
Допустим, 1200-байтовая датаграмма была, в частности, 1172 байта данных приложения в дейтаграмме UDP (8 байтов заголовков UDP, 20 байтов заголовков IP). После фрагментации первый фрагмент будет содержать 20-байтовый заголовок IP, 8-байтовый заголовок UDP и первые 568 байтов данных приложения, что в общей сложности составит 586 байтов. Второй кадр будет содержать еще один 20-байтовый заголовок IP, без заголовка UDP, и следующие 576 байтов данных приложения, что в общей сложности составит 586 байтов. Это оставляет 28 байтов данных приложения, оставленных для окончательного фрагмента, который с добавленным IP-заголовком будет 48 байтов.
Обновление на основе обновления Кавина о том, что он говорил о Jumbo-кадрах:
Jumbo-кадры - это то, что некоторые производители продуктов Gigabit Ethernet создавали независимо во время создания GigE, и оно (как я полагаю) было впоследствии отвергнуто или проигнорировано IEEE и, похоже, вряд ли когда-нибудь станет частью стандарта 802.3 Ethernet. Даже IEEE 802.3-2008, который включает в себя не только 1000BASE-T, но и 10 G BASE-T, не содержит ничего о полезной нагрузке кадра 9000 байт.
Поставщики, которые придумали jumbo-кадры, не предоставили какой-либо механизм автосогласования или механизма связи для поддержки jumbo-фреймов, а также не создали метод фрагментации уровня Ethernet для обработки (очень распространенного) случая, который вы иллюстрировали. Если вы хотите запустить свою локальную сеть Ethernet в этом нестандартном режиме, вы должны убедиться, что все хосты и коммутаторы в вашей локальной сети поддерживают Jumbo-кадры.
Если сетевой адаптер M1 не способен принимать гигантские кадры, он будет рассматривать гигантский кадр как "Ethernet jabber" - сломанное устройство, которое "продолжает включать и выключать"; продолжает посылать биты далеко за пределы максимально допустимого 1500 (на самом деле 1518) -байтового кадра. Обратите внимание, что это значение jabber является термином, обозначающим неисправность Ethernet, и его не следует путать с одноименной системой интернет-чата Jabber. Вам нужно будет решить, хотите ли вы прекратить использование гигантских кадров в этой сети, или вы хотите обновить M1, чтобы иметь сетевую карту, поддерживающую гигантские кадры.
Если NIC М1 способен принимать большие кадры, я подозреваю , что установка его IPv4 MTU для интерфейса , вплоть до 1500 будет убедиться , что он не передает джамбо размер IP - дейтаграммы в одном м-либо кадре Ethernet, но, скорее всего, сможем получить большие IP-дейтаграммы в одиночных кадрах большого размера без проблем, потому что опять-таки MTU не является MRU, и установка MTU IP-уровня не влияет на размер буфера кадров, который позволяет NIC. Теперь, если вы настраиваете настройки NIC/ драйвера, чтобы указать NIC использовать только 1500-байтовые буферы вместо 9000-байтовых буферов, это изменение уровня Ethernet, и, вероятно, ваш NIC будет работать так, как если бы он этого не делал. поддержка 9000-байтовых буферов.
