✖


Jump to content

Главный блок передачи

В компьютерных сетях максимальная единица передачи ( MTU ) — это размер наибольшего блока данных протокола (PDU), который может быть передан в одной транзакции сетевого уровня . [1] MTU относится к максимальному размеру кадра , который может передаваться на канальном уровне , но не идентичен ему, например, кадру Ethernet .

Больший MTU связан с меньшими накладными расходами . Меньшие значения MTU могут уменьшить задержку в сети . Во многих случаях MTU зависит от возможностей базовой сети и должен регулироваться вручную или автоматически, чтобы не превышать эти возможности. Параметры MTU могут появляться в связи с интерфейсом или стандартом связи. Некоторые системы могут определять MTU во время соединения, например, используя Path MTU Discovery .

Применимость

[ редактировать ]

MTU применяются к протоколам связи и сетевым уровням . MTU указывается в байтах или октетах наибольшего PDU, который уровень может передать дальше. Параметры MTU обычно появляются в связи с интерфейсом связи ( сетевой адаптер , последовательный порт и т. д.). Стандарты ( например, Ethernet ) могут фиксировать размер MTU; или системы (например, последовательные каналы связи «точка-точка») могут определить MTU во время соединения.

Базовый канал передачи данных и физический уровень обычно добавляют служебные данные к транспортируемым данным сетевого уровня, поэтому для заданного максимального размера кадра среды необходимо вычесть сумму служебных данных, чтобы вычислить MTU этой среды. Например, в Ethernet максимальный размер кадра составляет 1518 байт, 18 байт из которых являются служебными ( заголовок и последовательность проверки кадра ), в результате чего MTU составляет 1500 байт.

Компромиссы

[ редактировать ]

Больший MTU обеспечивает большую эффективность, поскольку каждый сетевой пакет несет больше пользовательских данных, в то время как издержки протокола, такие как заголовки или основные задержки для каждого пакета, остаются фиксированными; результирующая более высокая эффективность означает улучшение пропускной способности массового протокола. Больший MTU также требует обработки меньшего количества пакетов для того же объема данных. В некоторых системах попакетная обработка может быть критическим ограничением производительности.

Однако это преимущество не лишено и обратной стороны. Большие пакеты занимают канал больше времени, чем меньшие пакеты, вызывая большие задержки для последующих пакетов и увеличивая сетевую задержку и ее вариацию . Например, пакет размером 1500 байт, самый большой из разрешенных Ethernet на сетевом уровне, связывает модем 14,4 КБ примерно на одну секунду.

Большие пакеты также создают проблемы из-за ошибок связи. Если прямое исправление ошибок не используется, повреждение одного бита в пакете потребует повторной передачи всего пакета, что может оказаться дорогостоящим. При заданной частоте ошибок по битам более крупные пакеты более подвержены повреждению. Из-за большей полезной нагрузки повторная передача пакетов большего размера занимает больше времени. Несмотря на негативное влияние на продолжительность повторной передачи, большие пакеты все же могут оказывать положительное влияние на сквозную производительность TCP. [2]

Интернет-протокол

[ редактировать ]

Набор интернет-протоколов был разработан для работы с множеством различных сетевых технологий, каждая из которых может использовать пакеты разных размеров. Хотя хост будет знать MTU своего собственного интерфейса и, возможно, интерфейса своих одноранговых узлов (из начальных рукопожатий), он изначально не будет знать наименьший MTU в цепочке ссылок на другие одноранговые узлы. Другая потенциальная проблема заключается в том, что протоколы более высокого уровня могут создавать пакеты большего размера, чем поддерживает даже локальный канал.

IPv4 допускает фрагментацию , которая делит дейтаграмму на части, каждая из которых достаточно мала, чтобы соответствовать указанному ограничению MTU. Этот процесс фрагментации происходит на интернет-уровне . Фрагментированные пакеты помечаются таким образом, чтобы уровень IP узла назначения знал, что он должен повторно собрать пакеты в исходную дейтаграмму.

Чтобы пакет считался полученным, должны поступить все фрагменты пакета. Если сеть отбрасывает какой-либо фрагмент, весь пакет теряется.

Когда количество пакетов, которые необходимо фрагментировать, или количество фрагментов велико, фрагментация может привести к необоснованным или ненужным издержкам. Например, различные ситуации туннелирования могут незначительно превышать MTU, поскольку при этом добавляется объем данных, равный только заголовку. Дополнение небольшое, но каждый пакет теперь приходится отправлять двумя фрагментами, второй из которых несет очень мало полезной нагрузки. Перемещается тот же объем полезной нагрузки, но каждый промежуточный маршрутизатор должен пересылать вдвое больше пакетов.

Интернет-протокол требует, чтобы хосты могли обрабатывать IP-дейтаграммы размером не менее 576 байт (для IPv4) или 1280 байт (для IPv6). Однако это не мешает канальным уровням с MTU меньшим, чем этот минимальный MTU, передавать IP-данные. Например, согласно спецификации IPv6, если конкретный канальный уровень не может доставить IP-дейтаграмму размером 1280 байт в одном кадре, то канальный уровень должен предоставить свой собственный механизм фрагментации и повторной сборки, отдельный от механизма фрагментации IP, чтобы гарантировать, что 1280-байтовая IP-дейтаграмма может быть доставлена ​​на уровень IP в целости и сохранности.

MTU для обычных медиа

[ редактировать ]

В контексте Интернет-протокола MTU относится к максимальному размеру IP-пакета , который может быть передан без фрагментации по данной среде. Размер IP-пакета включает заголовки IP, но исключает заголовки канального уровня. В случае кадра Ethernet это добавляет служебные данные протокола в размере 18 байт или 22 байта с тегом IEEE 802.1Q для маркировки VLAN или класса обслуживания .

Не следует путать MTU с минимальным размером дейтаграммы, который все хосты должны быть готовы принять. Это 576 байт для IPv4. [3] и 1280 байт для IPv6 . [4]

Носители для IP-транспорта Максимальная единица передачи (байты) Примечания
к Интернету MTU пути IPv4 Минимум 68, [5] максимум 64 КиБ [6] Системы могут использовать обнаружение Path MTU. [7] чтобы найти фактический путь MTU. Маршрутизация от большего MTU к меньшему MTU приводит к фрагментации IP .
в Интернете MTU пути IPv6 Минимум 1280, [8] максимум 64 КиБ, но до 4 ГиБ с дополнительной джамбограммой [9] Системы должны использовать Path MTU Discovery. [10] чтобы найти фактический MTU пути, если только минимальный MTU (1280 байт) не превышен.
Х.25 Минимум 576 (отправка) или 1600 (получение). [11]
Ethernet v2 1500 [12] Почти все реализации IP over Ethernet используют формат кадров Ethernet II .
Ethernet с LLC и SNAP 1492 [13]
Ethernet Большие кадры 1501–9202 [14] или больше [15] Ограничение зависит от поставщика. Для корректного взаимодействия размер кадров не должен превышать максимальный размер кадра, поддерживаемый любым устройством в сегменте сети . [16]
PPPoE v2 1492 [17] Ethernet II MTU (1500) без заголовка PPPoE (8)
DS-Lite через PPPoE 1452 Ethernet II MTU (1500) без заголовка PPPoE (8) и заголовка IPv6 (40)
Большие кадры PPPoE 1493–9190 или больше [18] MTU Ethernet Jumbo Frame (1501–9198) без заголовка PPPoE (8)
IEEE 802.11 Wi-Fi (WLAN) 2304 [19] Максимальный размер MSDU — 2304 до шифрования. WEP добавит 8 байт, WPA-TKIP — 20 байт и WPA2-CCMP — 16 байт. См. также Механизмы агрегации кадров в 802.11n.
Маркерное кольцо (802.5) 4464
ФДДИ 4352 [7]

Максимальный размер кадра Ethernet

[ редактировать ]

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

Поскольку IP-пакет передается в кадре Ethernet, этот кадр Ethernet должен быть больше, чем IP-пакет. При обычных немаркированных служебных данных кадра Ethernet в 18 байт и полезной нагрузке в 1500 байт максимальный размер кадра Ethernet составляет 1518 байт. Если 1500-байтовый IP-пакет должен передаваться по тегированному соединению Ethernet, максимальный размер кадра Ethernet должен составлять 1522 байта из-за большего размера тегированного кадра 802.1Q. В соответствии с этим стандарт 802.3ac увеличивает стандартный максимальный размер кадра Ethernet.

Обнаружение пути MTU

[ редактировать ]
Основная статья: Обнаружение Path MTU

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

Обнаружение MTU пути — это метод определения MTU пути между двумя IP-хостами, определенный для обоих IPv4. [20] и IPv6 [21] . Он работает путем отправки пакетов с опцией DF (не фрагментировать) в наборе заголовков IP. Любое устройство на пути, чей MTU меньше пакета, отбросит такие пакеты и отправит обратно ICMP-сообщение «Пункт назначения недоступен (слишком большая дейтаграмма)» , в котором указывается его MTU. Эта информация позволяет исходному хосту соответствующим образом уменьшить предполагаемый MTU пути. Процесс повторяется до тех пор, пока MTU не станет достаточно маленьким, чтобы пройти весь путь без фрагментации.

Стандартный Ethernet поддерживает MTU до 1500 байт, а реализация Ethernet, поддерживающая большие кадры, допускает MTU до 9000 байт. Однако пограничные протоколы, такие как PPPoE, уменьшат это. Обнаружение MTU пути выявляет разницу между MTU, видимым конечными узлами Ethernet, и MTU пути.

К сожалению, все большее число сетей отбрасывают ICMP-трафик (например, для предотвращения атак типа «отказ в обслуживании» ), что препятствует работе определения MTU пути. Обнаружение MTU пути уровня пакетизации [22] [23] — это метод обнаружения MTU пути, который более устойчиво реагирует на фильтрацию ICMP. В IP-сети путь от адреса источника до адреса назначения может меняться в ответ на различные события ( балансировка нагрузки , перегрузка , сбои в работе и т. д.), и это может привести к изменению MTU пути (иногда неоднократно) во время передачи. , что может привести к дальнейшим отбрасываниям пакетов, прежде чем хост найдет новый надежный MTU.

Сбой Path MTU Discovery может привести к тому, что некоторые сайты за плохо настроенными брандмауэрами станут недоступными. Соединение с несовпадающим MTU может работать для данных небольшого объема, но не работать, как только хост отправляет большой блок данных. Например, при использовании Internet Relay Chat подключающийся клиент может видеть начальные сообщения, включая начальный пинг (отправленный сервером в качестве меры защиты от спуфинга), но после этого не получить ответа. Это связано с тем, что большой набор приветственных сообщений, отправленных в этот момент, представляет собой пакеты, размер которых превышает MTU пути. Эту проблему можно обойти, в зависимости от того, какую часть сети вы контролируете; например, можно изменить MSS ( максимальный размер сегмента ) в исходном пакете, который устанавливает TCP -соединение на брандмауэре.

В других контекстах

[ редактировать ]

MTU иногда используется для описания максимальных размеров PDU на уровнях связи, отличных от сетевого уровня.

  • Cisco Systems и MikroTik используют L2 MTU для максимального размера кадра. [24] [25]
  • Dell / Force10 использует MTU для максимального размера кадра. [26]
  • Hewlett-Packard использовала только MTU для максимального размера кадра, включая дополнительный тег IEEE 802.1Q . [27]
  • В Juniper Networks используется несколько терминов MTU: MTU физического интерфейса (MTU L3 плюс некоторые неуказанные служебные данные протокола), MTU логического интерфейса (в соответствии с MTU IETF) и Максимальный MTU (максимальный настраиваемый размер кадра для больших кадров). [28]

Передача пакета в физическом сегменте сети, размер которого превышает MTU сегмента, называется jabber . Почти всегда это вызвано неисправными устройствами. [29] Сетевые коммутаторы и некоторые концентраторы-ретрансляторы имеют встроенную возможность определять, когда устройство болтает. [30] [31]

Ссылки

[ редактировать ]
  1. ^ РФК 791 . п. 25. дои : 10.17487/RFC0791 .
  2. ^ Мюррей, Дэвид; Терри Козинец; Кевин Ли; Майкл Диксон (2012). «Большие MTU и производительность в Интернете» . 2012 13-я Международная конференция IEEE по высокопроизводительной коммутации и маршрутизации . стр. 82–87. дои : 10.1109/HPSR.2012.6260832 . ISBN  978-1-4577-0833-6 . S2CID   232321 .
  3. ^ РФК 791 . п. 24. дои : 10.17487/RFC0791 . Каждый интернет-адресат должен иметь возможность получать дейтаграмму длиной 576 октетов либо целиком, либо фрагментами для повторной сборки.
  4. ^ РФК 2460 . п. 13. дои : 10.17487/RFC2460 .
  5. ^ РФК 791 . п. 24. дои : 10.17487/RFC0791 . Каждый интернет-модуль должен иметь возможность пересылать дейтаграмму длиной 68 октетов без дальнейшей фрагментации.
  6. ^ РФК 791 . п. 12. дои : 10.17487/RFC0791 . Общая длина — это длина дейтаграммы, измеряемая в октетах, включая интернет-заголовок и данные. Это поле позволяет длине датаграммы достигать 65 535 октетов.
  7. ^ Перейти обратно: а б РФК 1191 . дои : 10.17487/RFC1191 .
  8. ^ РФК   2460
  9. ^ RFC   2675 , стр. 1: «Заголовок IPv6 [IPv6] имеет 16-битное поле длины полезной нагрузки и, следовательно, поддерживает полезную нагрузку длиной до 65 535 октетов. В этом документе указана опция пошагового IPv6, называемая опцией Jumbo Payload, которая содержит Поле длины 32 бита, позволяющее передавать пакеты IPv6 с полезной нагрузкой длиной от 65 536 до 4 294 967 295 октетов. Пакеты с такой длинной полезной нагрузкой называются «джамбограммами».
  10. ^ РФК   2460
  11. ^ RFC   1356
  12. ^ Сетевая рабочая группа IETF, RFC   894 : Стандарт передачи IP-дейтаграмм по сетям Ethernet, Страница 1, «Максимальная длина поля данных пакета, отправляемого по Ethernet, составляет 1500 октетов, таким образом, максимальная длина IP-дейтаграммы, отправляемой по Ethernet, составляет 1500 октетов.», ОШИБКИ
  13. ^ IEEE 802.3 [ нужна страница ]
  14. ^ Скотт Хогг (06 марта 2013 г.), Jumbo Frames , Network World , получено 5 августа 2013 г. , Большинство сетевых устройств поддерживают размер больших кадров 9216 байт.
  15. ^ Juniper Networks (23 марта 2020 г.), Свойства физического интерфейса , получено 1 мая 2020 г.
  16. ^ Джо Сент-Совер (4 февраля 2003 г.). «Практические вопросы, связанные с MTU 9 тыс.» (PDF) . uoregon.edu. п. 67 . Проверено 15 декабря 2016 г. вам все равно необходимо убедиться, что ВСЕ коммутаторы Ethernet в восходящем направлении, включая любые коммутаторы в ядре вашего кампуса, ТАКЖЕ поддерживают работу с большими кадрами.
  17. ^ RFC   2516 со стандартным Ethernet MTU размером 1500 байт; расширения существуют
  18. ^ RFC   4638
  19. ^ 802.11-2012, стр. 413, раздел 8.3.2.1; стр. 381 «Поле «Тело кадра» имеет переменный размер. Максимальный размер тела кадра определяется максимальным размером MSDU (2304 октета) плюс длиной поля Mesh Control (6, 12 или 18 октетов), если оно присутствует, максимальный размер незашифрованного MMPDU, исключая заголовок MAC и FCS (2304 октета) или максимальный размер A-MSDU (3839 или 7935 октетов, в зависимости от возможностей STA), плюс любые накладные расходы, связанные с инкапсуляцией безопасности».
  20. ^ Дж. Могул; С. Диринг (ноябрь 1990 г.). Путь обнаружения MTU . Сетевая рабочая группа. дои : 10.17487/RFC1191 . РФК 1191 . Проект стандарта. Устаревшие РФК 1063 .
  21. ^ Дж. Макканн; С. Диринг ; Дж. Могул (июль 2017 г.). Р. Хинден (ред.). Обнаружение MTU пути для IP версии 6 . IETF . дои : 10.17487/RFC8201 . СТД 87. RFC 8201 . Интернет-стандарт 87. Устарел . РФК 1981 .
  22. ^ М. Матис; Дж. Хеффнер (март 2007 г.). Обнаружение MTU пути уровня пакетизации . Сетевая рабочая группа. дои : 10.17487/RFC4821 . РФК 4821 . Предлагаемый стандарт. Обновлено РФК 8899 .
  23. ^ Г. Фэйрхерст; Т. Джонс; М. Тюксен; И. Рюнгелер; Т. Фёлькер (сентябрь 2020 г.). Обнаружение MTU пути уровня пакетизации для транспорта дейтаграмм . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC8899 . ISSN   2070-1721 . РФК 8899 . Предлагаемый стандарт. Обновления RFC 4821 , 4960 , 6951 , 8085 и 8261 .
  24. ^ «Настройка и проверка максимальной единицы передачи на платформах Cisco Nexus» . Циско. 29 ноября 2016 г. Идентификатор документа: 118994 . Проверено 4 января 2017 г.
  25. ^ «MTU в RouterOS» . МикроТик. 08.07.2022 . Проверено 2 сентября 2022 г.
  26. ^ «Как настроить MTU (максимальную единицу передачи) для Jumbo Frames на коммутаторах Dell Networking Force10» . Делл. 2016-06-02. Идентификатор статьи: HOW10713 . Проверено 6 января 2017 г.
  27. ^ «Джамбо-кадры». Руководство по управлению и настройке коммутаторов HP Networking 2910al . Хьюлетт-Паккард. Ноябрь 2011 г. Номер по каталогу 5998-2874.
  28. ^ «Служебные шлюзы серии SRX для Справочника модулей физического интерфейса филиала: значения MTU по умолчанию и максимальные значения для модулей физического интерфейса » . Можжевельник. 03 января 2014 г. Проверено 4 января 2017 г.
  29. ^ jabber , Сетевая энциклопедия , получено 28 июля 2016 г.
  30. ^ показать интерфейсы , Juniper Networks , получено 28 июля 2016 г.
  31. ^ IEEE 802.3 27.3.1.7 Функциональные требования к приему jabber
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Maximum_transmission_unit&oldid=1236599247"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 4f36914b27042dd73b5decf44526e9b7__1721910720
URL1:https://arc.ask3.ru/arc/aa/4f/b7/4f36914b27042dd73b5decf44526e9b7.html
Заголовок, (Title) документа по адресу, URL1:
Maximum transmission unit - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)