В тот момент, когда хост должен передавать данные через интерфейс, он ссылается на максимальный размер полезного блока данных для одного пакета Maximum Transmission Unit, чтобы определить, сколько данных он может поместить в каждый пакет. Например, интерфейсы Ethernet имеют MTU по умолчанию 1500 байт, не включая заголовок или трейлер Ethernet. Это означает, что хост, которому необходимо отправить данные по TCP-протоколу, обычно будет использовать первые 20 из этих 1500 байтов для заголовка IP, следующие 20 для заголовка TCP, а оставшиеся 1460 байт для полезной нагрузки. Инкапсуляция данных в пакеты максимального размера, подобные этому, позволяет потреблять полосу пропускания наиболее эффективно, минимизируя использование служебного трафика протокола передачи данных. Оптимальный размер MTU — ключ к эффективному использованию сетевых каналов передачи данных и снижению нагрузки на сетевое оборудование.

Фрагментация пакетов MTU

К сожалению, не все устройства в сети Интернет имеют одинаковый максимальный размер полезного блока данных MTU. MTU может различаться в зависимости от типа физического носителя или сконфигурированной инкапсуляции (например, туннелирование GRE или шифрование IPsec). Когда маршрутизатор решает переслать IPv4 пакет через интерфейс и определяет, что размер пакета превышает MTU интерфейса, маршрутизатор должен разбить пакет так, чтобы передать его как две (или более) отдельные части, каждая из которых не превышает предельный размер MTU канала между абонентами. Фрагментация довольно дорого стоит, как в ресурсах маршрутизатора, так и в использовании полосы пропускания. Должны быть созданы новые заголовки и прикреплены к каждому фрагменту. В спецификации протокола IPv6 из маршрутизатора полностью удалена фрагментация пакетов, но эта тема для отдельного разговора.

Определение оптимального размера MTU пакета данных

Чтобы использовать канал наиболее эффективным образом, хосты должны определить оптимальный размер MTU — это минимальный MTU среди всех узлов на пути между хостами. Например, для двух хостов, путь между которыми состоит из 3-х маршрутизаторов с различными максимально возможными размерами пакетов: 1500, 800 и 1200 байтов, каждый из конечных хостов должен принять наименьший размер пакета 800 байт, чтобы избежать фрагментации.

Do not Fragment и Destination Unreachable, Fragmentation Needed

Пакеты могут перемещаться по сетям произвольным образом и невозможно заранее просчитать все маршруты и максимальный размер пакетов для каждого подключения. В RFC 1191 прописана методология определения размера MTU. Процесс, посредством которого хост для конкретного подключения может обнаруживать меньший размер MTU, чем поддерживает его собственный сетевой интерфейс. Ключевыми являются два компонента: бит “Не фрагментировать” (Do not Fragment (DF)) заголовка IP и субкод сообщения ICMP-протокола  Destination Unreachable, Fragmentation Needed.

Установка бита DF в IP-пакете не позволяет маршрутизатору выполнять фрагментацию, когда он обнаруживает MTU меньше, чем размер пакета. Вместо этого пакет отбрасывается и по ICMP отправителю приходит сообщение о необходимости фрагментации пакетов. По сути, маршрутизатор указывает, что для отправки далее ему необходимо разбить пакет на части, но флаг Don’t Fragment (DF) не позволяет это сделать. RFC 1191 расширяет ICMP-сообщение, запрашивающее фрагментацию, с включением размера MTU для текущего подключения.

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

Расчет максимального размера MTU пакета с помощью трассировки

Вы можете вычислить максимальный размер пакета MTU для каждого маршрута через живую сеть с помощью инструмента, такого как трассировка пути. Является частью пакета Linux — IPutils. Или утилита, написанная для Windows — mturoute:
https://14bytes.ru/files/mturoute.exe

Привожу пример определения MTU для маршрута между двумя хостами через шифрованный GRE-туннель. Видим как утилита последовательно подбирает максимальный размер пакета:

c:\bin>mturoute.exe 192.168.3.1
* ICMP Fragmentation is not permitted. *
* Speed optimization is enabled. *
* Maximum payload is 10000 bytes. *
- ICMP payload of 1472 bytes is too big.
+ ICMP payload of 92 bytes succeeded.
+ ICMP payload of 782 bytes succeeded.
+ ICMP payload of 1127 bytes succeeded.
+ ICMP payload of 1299 bytes succeeded.
- ICMP payload of 1385 bytes is too big.
+ ICMP payload of 1342 bytes succeeded.
+ ICMP payload of 1363 bytes succeeded.
+ ICMP payload of 1374 bytes succeeded.
- ICMP payload of 1379 bytes is too big.
+ ICMP payload of 1376 bytes succeeded.
+ ICMP payload of 1377 bytes succeeded.
+ ICMP payload of 1378 bytes succeeded.
Path MTU: 1406 bytes.

Читать далее

Оптимальный размер MTU — снижаем нагрузку на сеть
Adblock detector