Jumbo frames: механизм, который ускоряет сеть и почти никогда не включён

MAATRIX

Стандартный Ethernet-кадр несёт максимум 1500 байт полезной нагрузки — это значение не менялось с девяностых, хотя сети с тех пор ускорились в тысячи раз. Каждый такой кадр обрастает служебными заголовками почти одинакового размера независимо от того, сколько данных внутри, поэтому при передаче больших объёмов накладные расходы съедают заметную часть ресурсов CPU и канала. Jumbo frames решают эту задачу технически просто — увеличивают размер кадра до 9000 байт, — но включены они почти нигде, и в этой статье разберём, почему.

Из чего складывается накладная стоимость обычного кадра

Ethernet-кадр — это не просто ваши данные, обёрнутые в конверт. У него есть заголовок канального уровня (обычно 14 байт: MAC-адрес назначения, MAC-адрес источника, тип протокола) и контрольная сумма FCS в конце (4 байта). Дальше внутри кадра лежит IP-пакет со своим заголовком (минимум 20 байт для IPv4, 40 для IPv6), а внутри него — TCP или UDP-заголовок (минимум 20 и 8 байт соответственно). К этому добавляется физический overhead канала — преамбула и межкадровый интервал, которые не входят в MTU, но занимают время на проводе.

Если посчитать долю служебной информации в кадре с MTU 1500 и полезной нагрузкой TCP: заголовки Ethernet + IP + TCP занимают порядка 54–58 байт, то есть около 3,5–4% кадра — это чистый оверхед, не несущий пользовательских данных. При MTU 9000 те же 54–58 байт заголовков растворяются в кадре, занимая уже меньше процента. Разница не в разы по абсолютным цифрам заголовка — она в том, сколько кадров вообще нужно отправить, чтобы передать один и тот же объём данных.

Возьмём условный мегабайт данных. При MTU 1500 это примерно 700 кадров (округлённо, без учёта TCP-опций и реальной эффективности окна — это иллюстративный расчёт, а не результат измерения). При MTU 9000 — уже около 117 кадров. Каждый кадр — это не только заголовки на проводе, это ещё и отдельная единица обработки для сетевого стека: формирование дескриптора, копирование (если не задействован zero-copy), в базовом случае — потенциальное прерывание CPU на приём. Меньше кадров на тот же объём данных означает меньше этой работы на мегабайт трафика.

Что именно меняют jumbo frames

Jumbo frames — это кадры с полезной нагрузкой больше 1500 байт, обычно вплоть до 9000. Официального стандарта на это значение нет — 9000 байт стало отраслевым соглашением, потому что удобно помещает наиболее частые единицы данных (например, блок NFS в 8 КБ) в один кадр без разбиения, оставляя запас под заголовки. Некоторые производители сетевого оборудования поддерживают чуть другие максимумы — где-то это 9014, где-то 9216 байт с учётом дополнительных тегов (VLAN, MPLS) — поэтому при планировании стоит смотреть документацию конкретного свича, а не считать 9000 универсальной константой.

Эффект от увеличения MTU складывается из двух вещей. Первое — прямое снижение доли служебных байт в канале, о чём говорили выше: для потоков, которые упираются в пропускную способность (а не в задержку), это означает больше полезных данных на единицу переданного трафика. Второе, часто более заметное на практике — снижение числа прерываний и системных вызовов на сетевой стек хоста при том же объёме данных. Современные NIC используют coalescing прерываний, offload контрольных сумм и сегментации (TSO/GRO), которые сильно сглаживают эту проблему и на MTU 1500 — но при высокой интенсивности трафика (репликация БД, бэкапы по сети, NFS/iSCSI, миграция ВМ, overlay-сети между контейнерами) меньшее число кадров на мегабайт всё равно снимает часть нагрузки с CPU, оставляя больше ресурсов на полезную работу.

Здесь важна честность в ожиданиях: jumbo frames — это оптимизация накладных расходов, а не магический ускоритель. Для соединения, которое упирается в задержку (RTT), количество мелких запросов-ответов или в саму пропускную способность канала на физическом уровне, увеличение MTU почти ничего не даст — узкое место не там.

Почему увеличенный MTU не долетает целиком

IP-пакет, который больше MTU исходящего интерфейса, either фрагментируется, либо отбрасывается — в зависимости от того, установлен ли на нём бит DF (Don't Fragment). Для IPv4 без DF маршрутизатор на пути может разбить пакет на части — это работает, но дорого: фрагментация нагружает процессор промежуточных узлов и получателя, а потеря одного фрагмента убивает весь пакет целиком, так как пересобрать его без всех частей нельзя. Для IPv6 фрагментация в транзите вообще запрещена — фрагментировать может только отправитель, поэтому неверный MTU на промежуточном звене означает не фрагментацию, а потерю пакета и (в теории) ICMPv6 Packet Too Big в ответ, чтобы отправитель уменьшил размер.

На практике Path MTU Discovery (PMTUD) — механизм, при котором отправитель шлёт пакеты с DF и ждёт ICMP "fragmentation needed" от узла, который не смог их пропустить, — часто ломается, потому что кто-то на пути фильтрует ICMP целиком, приняв его за угрозу. Тогда пакеты просто пропадают без объяснения: соединение устанавливается (TCP handshake использует маленькие пакеты), но обмен данными зависает на первом же крупном пакете. Это классический сценарий несогласованного MTU, который мы подробно разбирали в статье про MTU и фрагментацию — там же описан и случай, когда искали проблему в приложении, а причина была в MTU.

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

Почему нужно согласие абсолютно всех звеньев на пути

Здесь и кроется главная причина, почему jumbo frames почти никогда не включены по умолчанию: MTU — это свойство не соединения и не приложения, а каждого отдельного сетевого интерфейса и канала между двумя соседними устройствами. Чтобы кадр в 9000 байт прошёл от одного сервера до другого без потерь, нужно, чтобы:

• на обеих сетевых картах (отправителя и получателя) был выставлен одинаковый увеличенный MTU;
• на каждом промежуточном коммутаторе порт, через который идёт трафик, поддерживал и был настроен на этот же увеличенный MTU — включая аплинки между свичами и агрегирующие/магистральные порты;
• если трафик идёт через VLAN-транк, увеличенный MTU должен быть настроен именно на транковом порту, а не только на access-порту конечного хоста — иначе кадр с VLAN-тегом может не влезть даже туда, где обычный MTU уже увеличен;
• виртуальные коммутаторы гипервизора (vSwitch, OVS, Linux-бридж) и виртуальные NIC внутри ВМ или контейнера тоже должны быть настроены согласованно — легко забыть про этот слой, потому что он не выглядит "физическим оборудованием";
• если в пути участвует туннель (VXLAN, GRE, WireGuard, IPsec), у него есть собственный оверхед заголовков, который съедает часть MTU — например, у VXLAN это обычно 50 байт, у WireGuard — около 60–80 в зависимости от режима, и это нужно учитывать при расчёте MTU внутри туннеля, иначе фрагментация или потери начнутся именно там.

Если хотя бы одно звено в этой цепочке не поддерживает или не настроено на больший MTU, результат не "частичное ускорение" — это либо фрагментация с её накладными расходами, либо потеря пакетов и зависшие соединения. Слабое звено определяет предел для всей цепочки целиком, а не усредняет эффект. Именно поэтому включить jumbo frames "частично" — например, только на серверах, забыв про свич между ними, — типичная причина инцидентов: соединение вроде бы работает (мелкие пакеты проходят), но всё, что превышает старый MTU, начинает рваться. Похожий сценарий с включением jumbo frames "на полпути" и последствиями для базы данных разобран в статье «Jumbo frames включили на полпути — и база отваливалась».

Где в реальной инфраструктуре это чаще всего ломается

На практике несогласованный MTU при попытке включить jumbo frames возникает в нескольких повторяющихся местах.

Виртуализация и облака. Гипервизор с несколькими vSwitch, где MTU выставлен на одном, но не на другом; ВМ с MTU 9000 внутри, но виртуальный NIC или порт-группа настроены на 1500 снаружи. Публичные облачные сети у разных провайдеров поддерживают jumbo frames по-разному — это стоит проверять в документации конкретного провайдера, а не считать поддержку универсальной.

Смешанное оборудование. Старый свич в стойке, который остался с прошлой закупки и не поддерживает MTU выше 1500 (или поддерживает, но настройка не была перенесена при замене части оборудования). В смешанном стеке коммутаторов достаточно одного устройства со старым лимитом на пути трафика, чтобы всё сломалось именно на этом участке.

Агрегированные линки (LACP/bonding). Если в бонд объединены интерфейсы с разным MTU (что само по себе редко валидная конфигурация, но встречается после частичного апдейта), поведение становится непредсказуемым в зависимости от того, через какой физический линк ушёл конкретный кадр.

Туннели поверх jumbo-сети. Настроили jumbo frames на физической сети, но забыли пересчитать MTU для VPN или overlay-туннеля поверх неё — туннель как был на 1500, так и остаётся, и трафик внутри него не получает выгоды, а иногда и теряет часть пакетов из-за несогласованности внешнего и внутреннего MTU.

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

Как проверять и включать jumbo frames без сюрпризов

Правило номер один: включать не на всей сети сразу, а на изолированном сегменте, где вы полностью контролируете оба конца и всё оборудование между ними — например, отдельная storage-сеть или сеть для репликации между двумя серверами в одной стойке.

Проверить текущий MTU интерфейса в Linux:

ip link show eth0
# или
cat /sys/class/net/eth0/mtu

Установить MTU на интерфейсе (временно, до перезагрузки):

sudo ip link set dev eth0 mtu 9000

Постоянно — через конфигурацию сетевого менеджера (netplan, systemd-networkd, NetworkManager или классический /etc/network/interfaces, в зависимости от дистрибутива).

Проверить, что путь между двумя хостами действительно пропускает кадры увеличенного размера, — послать ICMP-пакет с запретом фрагментации и точным размером:

# Linux, для MTU 9000: 9000 - 20 (IP) - 8 (ICMP) = 8972
ping -M do -s 8972 10.0.0.2

Если пакет с флагом -M do (DF) проходит без ошибки "Message too long" или таймаута — путь целиком пропускает нужный размер. Если нет — уменьшайте размер, пока не найдёте фактический предел, и ищите звено, которое его ограничивает (последовательно проверяя каждый хоп через traceroute или логи промежуточных коммутаторов).

На управляемых коммутаторах jumbo frames обычно включаются на уровне порта или всего устройства — синтаксис отличается у каждого производителя, поэтому сверяйтесь с документацией конкретной модели, а не переносите команды с одного вендора на другого.

После включения стоит проверить сегмент реальным трафиком (например, iperf3 между двумя хостами) и убедиться, что ретрансмитов не прибавилось по сравнению с MTU 1500 — их рост почти всегда означает, что где-то на пути размер кадра всё же не согласован.

Когда игра стоит свеч, а когда лучше не трогать

Jumbo frames дают измеримую пользу там, где по сети непрерывно идёт большой объём данных между узлами, которые вы полностью контролируете: сети хранения (NFS, iSCSI, Ceph), репликация баз данных между нодами кластера, бэкап-трафик, миграция ВМ, внутренний трафик между подами в высоконагруженном кластере. Здесь снижение накладных расходов на кадр складывается в заметную экономию ресурсов CPU и канала именно потому, что таких кадров проходят миллионы.

Для типичного веб-трафика (клиент — сервер через интернет) эффект почти всегда незаметен: интернет-провайдеры и магистральные сети в подавляющем большинстве работают со стандартным MTU 1500, PMTUD по пути через публичный интернет — вещь ненадёжная, а сам трафик обычно состоит из небольших запросов и ответов, где overhead заголовков — не то, что ограничивает скорость. Пытаться поднять MTU для внешнего интерфейса, смотрящего в интернет, почти никогда не оправдано и добавляет риск сломать соединения там, где путь пакета вам не подконтролен.

Отсюда и практический принцип: jumbo frames — это точечная настройка для конкретного контролируемого сегмента сети с большим объёмом внутреннего трафика, а не общий тумблер "ускорить сеть", который стоит щёлкать по умолчанию. Цена ошибки (фрагментация, потери, зависшие соединения на всём сегменте) высока, а выгода ощутима только там, где действительно есть постоянный поток крупных пакетов.

Частые вопросы