Maximum transmission unit

Ограничение на максимальный размер кадра накладывается по нескольким причинам:

• Для уменьшения времени на повторную передачу в случае потери или неисправимого искажения пакета. Вероятность потерь растёт с увеличением длины пакета.
• Чтобы при полудуплексном режиме работы хост не занимал долгое время канал (также для этой цели используется межкадровый интервал (англ. Interframe gap)).
• Чем больше отправляемый пакет, тем дольше ждут отправления другие пакеты, особенно в последовательных интерфейсах. Поэтому маленький MTU был актуален во времена медленных коммутируемых соединений.
• Малый размер и быстродействие сетевых буферов входящих и исходящих пакетов. Однако слишком большие буферы тоже ухудшают производительность.

Значение MTU определяется стандартом соответствующего протокола, но может быть переопределено автоматически для определённого потока (протоколом PMTUD) или вручную для нужного интерфейса. На некоторых интерфейсах MTU по умолчанию может быть установлено ниже максимально возможного.

Значение MTU ограничено снизу как правило минимально допустимой длиной кадра. Минимальный размер кадра обычно связывают с коллизионным доменом (полудуплексный канал). Участники домена должны узнать о коллизии до окончания передачи кадра. Здесь также учитываются ограничения, накладываемые стандартом, на физические особенности тракта, например, длина, материалы.

Минимальный размер кадра по стандартам:
Fast Ethernet 100Base-T: 64 байта
Gigabit Ethernet 1000Base-T: 512 байт

Для высокопроизводительной сети причины, вызвавшие начальные ограничения MTU, устарели. В связи с этим для Ethernet был разработан стандарт Jumbo-кадров с увеличенным MTU.

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

 

Номинальная скорость — битовая скорость передачи данных, поддерживаемая на интервале передачи одного пакета без различия служебных и пользовательских заголовков. Очевидно, что чем меньше пакет, тем быстрее он передастся.
Эффективная скорость — это средняя скорость передачи пользовательских данных (нагрузки) в потоке. Этот параметр зависит от соотношения длин служебных заголовков к нагрузке. Во многих случаях некоторый объём информации эффективнее передавать большими пакетами из-за меньших накладных расходов. Корректно сравнивать скорости потоков можно только для одного и того же объёма данных, который требуется передать единовременно.

Чем больше полезная нагрузка пакета по отношению к его заголовкам, тем выше скорость передачи полезной информации и процент использования канала (channel utilization). Поскольку MTU — это верхняя граница длины полезной нагрузки, то максимальная скорость достигается, когда нагрузки всех пакетов в потоке имеют длину, равную MTU. Для шейпинга существуют разные методы подсчёта длины Ethernet-кадра (англ. Ethernet frame) (без jumbo):

• до 1514 байт (1518 c тегом 802.1Q) на компьютерах общего назначения, где шейпер реализован программно. Заключительные байты (называются trailer^[англ.] или footer) поля FCS обрабатываются сетевым адаптером и в операционную систему передаётся пакет без них.
• до 1518 байт (1522 c тегом 802.1Q) — Ethernet пакет, включая поле FCS, но не учитывая преамбулу.
• до 1538 байт (1542 c тегом 802.1Q) на специальных сетевых платформах^[2]. Вместе с обычным Ethernet заголовком учитывается преамбула, FCS и межкадровый интервал. Этот способ подсчёта также нужно использовать, когда скорость ограничивается только протоколом передачи (в данном случае Ethernet) и не ограничивается провайдером.

Существуют несколько способов увеличения пропускной способности в контексте длин пакетов:

• Уменьшение межкадрового интервала. Для Fast Ethernet он по умолчанию равен 0,96 мкс за который могло бы быть передано 12 байт. Некоторые сетевые адаптеры в полнодуплексном режиме могут передавать и получать кадры с уменьшенным межкадровым интервалом.
• Сжатие заголовков. Пример реализации — Метод сжатия заголовков TCP/IP Якобсона.
• Сжатие нагрузки низкого уровня. Пример реализации — IP Payload Compression Protocol.
• Решение проблемы передачи небольших данных (tinygram problem) за счёт придерживания в буфере малых данных, чтобы отправить один большой пакет. Пример реализации — алгоритм Нейгла. Частный случай этой проблемы — «болтливые» протоколы, посылающие множество запросов там, где можно обойтись одним. Существуют программные и аппаратные решения, осуществляющие оптимизацию таких соединений, например у компании Riverbed Technology^[англ.].

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

 

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

• Целевой хост должен получить все фрагменты для того, чтобы собрать пакет. Если хотя бы один фрагмент утерян — весь пакет должен быть отправлен заново.
• Как правило, фрагментацию выполняют более медленные процессоры, нежели те, что обрабатывают транзитный трафик. В некоторых случаях задержки, которые вызовет фрагментация всех пакетов, могут быть сочтены неприемлемыми.
• Увеличивается нагрузка на процессоры промежуточных маршрутизаторов и машины адресата.
• Увеличивается требование к памяти маршрутизатора, т.к. необходимо хранить в буфере все фрагменты IP-пакета.
• Некоторые межсетевые экраны могут блокировать фрагменты.
• Из-за копии IP-заголовка для каждого фрагмента неэффективно используется полоса пропускания.
• Протоколам маршрутизации, например OSPF, требуется согласованный MTU для корректной работы.

Для обозначения кадров, которые имеют ненормативный размер, в сетях Ethernet применяются следующие термины:

• RUNT — (коротышка) — кадр, размер которого менее 64 байтов (512 бит).
• LONG — (длинный) — кадр, размер которого лежит в пределах от 1518 до 6000 байтов.
• GIANT — (гигант) — кадр, размер которого превышает 6000 байтов.

Термин Path MTU означает наименьший MTU на пути следования пакета в сети.

Хотя фрагментация решает проблему несоответствия размеров пакетов и значения MTU, она ощутимо снижает производительность сетевых устройств. В связи с этим, в 1988 году была предложена альтернативная технология, названная Path MTU discovery (RFC 1191). Суть технологии заключается в том, что при соединении двух хостов устанавливается параметр DF (don’t fragment — не фрагментировать), который запрещает фрагментацию пакетов. Это приводит к тому, что узел, значение MTU которого меньше размера пакета, отклоняет передачу пакета и отправляет сообщение ICMP «необходима фрагментация, но установлен флаг её запрета (DF)». Хост-отправитель уменьшает размер пакета и отсылает его заново. Такая операция происходит до тех пор, пока пакет не будет достаточно мал, чтобы дойти до хоста-получателя без фрагментации.

Однако, и у этой технологии существуют потенциальные проблемы. Некоторые маршрутизаторы настраиваются администраторами на полное блокирование ICMP пакетов (это не очень грамотно, но может быть самым простым решением нескольких проблем безопасности). В результате, если размер пакета не соответствует значению MTU на определённом участке, пакет отбрасывается, а хост-отправитель не может получить информацию о значении MTU и не отправляет пакет заново. Поэтому соединение между хостами не устанавливается. Проблема получила название MTU Discovery Black Hole (RFC 2923), и протокол был модифицирован для детектирования таких маршрутизаторов. Одной из распространённых проблем при работе в сети, блокирующей ICMP пакеты, является работа в IRC, когда пользователь успешно проходит авторизацию, но не может получить так называемое MOTD (message of the day), в результате чего использование сети не представляется возможным.

Проблема представляет потенциальную опасность для любого PPPoE соединения, использующего MTU меньше типового (1500 байт).

Существует несколько вариантов решения этой проблемы. Самым простым, безусловно, является отмена фильтрации пакетов ICMP. Однако зачастую подобная операция находится вне компетенции пользователя. Поэтому проблему решают путём ручной настройки размера передаваемого пакета на шлюзе пользователя. Для этого меняют значение MSS (максимальный размер сегмента, то есть величина, меньшая MTU на 40 байт в случае протокола IPv4). При установке соединения хосты обмениваются информацией о максимальном размере сегмента, который каждый из них сможет принять. Поэтому, меняя значение MSS, заставляют оба хоста обмениваться пакетами, которые шлюз пользователя сможет заведомо принять без фрагментации.

Кроме того, существуют методы отмены бита DF с целью разрешения фрагментации. Однако метод корректировки MSS является предпочтительным.

В маршрутизаторах Cisco реализация PMTUD для туннеля поддерживает только TCP пакеты^[3].

• Maximum Receive Unit (MRU) — максимальный размер полезного блока данных протокола PPP.
• Maximum segment size (MSS) — максимальный размер полезного блока данных TCP сегмента.
• Protocol data unit^[англ.] (PDU) — общий блок данных протокола (полезные данные + заголовки). Альтернативное не всегда корректное определение — весь блок данных определённого уровня сетевой модели.
• Service data unit^[англ.] (SDU) — в терминологии OSI блок данных, который прошёл со своего уровня на нижний уровень модели и ещё не был инкапсулирован в PDU этого уровня.

• Marc Slemko. Path MTU Discovery и фильтрация ICMP  (неопр.) (18 января 1998). Дата обращения: 31 марта 2010. Архивировано из оригинала 26 августа 2011 года.
• DrTCP — утилита для оптимизации MTU в Microsoft Windows
• mturoute — консольная утилита для устранения проблем с MTU
• ручная установка значения MTU в реестре Windows Mobile, Windows XP, Windows Vista  (неопр.) (21 января 2009). Архивировано из оригинала 26 августа 2011 года.
• разъяснение MTU различных уровней на примере mikrotik os
• Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC