plp mtu discovery
1.0.0
Выполняйте обнаружение Path MTU, не полагаясь на ошибки ICMP, которые часто не доставляются.
Эта программа выполняет обнаружение MTU пути на уровне пакетизации, как описано в RFC 4821, что является более надежным способом определения размера MTU при наличии черных дыр ICMP.
Хотя TCP-соединения автоматически корректируют размер MTU с течением времени в зависимости от различных показателей (производительность сети, потеря пакетов, сообщения об ошибках ICMP и т. д.), это не относится к протоколам без установления соединения.
Когда производительность имеет решающее значение, пропускная способность , фрагментация пакетов и надежность маршрута являются тремя ключевыми показателями, которые необходимо проанализировать для оптимизации производительности потока. Поскольку надежность маршрута не всегда зависит от нас, мы должны стремиться максимизировать пропускную способность, НЕ выполняя при этом фрагментацию пакетов , что может сильно ухудшить производительность [1] .
Первоначальное предложение Path MTU Discovery основывалось на необходимости доставки пакетов ICMP Fragmentation Needed , когда пакет IPv4 с установленным полем «Не фрагментировать» был слишком большим для распространения. К сожалению, некоторые маршрутизаторы не генерируют такого рода ошибок, а вместо этого предпочитают молча игнорировать большие пакеты. У клиента нет возможности определить причину потери пакета.
Поскольку все хосты обязаны поддерживать запросы ICMP_ECHO, мы можем использовать тот факт, что сообщения ICMP принимают произвольный объем данных и отправляют на наш сервер пакеты разного размера. Если мы включим поле «Не фрагментировать» в пакете IPv4 и прослушиваем ответ, мы де-факто ожидаем ACK (в форме пакета ICMP_ECHOREPLY), подтверждающего, что этот размер MTU действителен.
Теперь нам просто нужно выполнить двоичный поиск по размеру пакетов, чтобы найти максимальный размер MTU, поддерживаемый этим маршрутом.
В режиме ICMP генерируются некоторые запросы ICMP_ECHO разных размеров.
ICMP Fragmentation Needed ), этот размер MTU объявляется недействительным и порог снижается.Единственное требование режима ICMP — хост должен иметь возможность отвечать на сообщения ping.
Тот же алгоритм применяется к пакетам UDP, но вам необходимо запустить сервер ( udp_server.py ) на принимающем хосте, чтобы отправлять обратно подтверждающие сообщения.
Эта программа должна нормально работать в большинстве дистрибутивов Linux и OSX.
gcc -Wall -Wextra mtu_discovery.c mtu.c -o plpmtu
Он не должен сообщать о предупреждениях/ошибках. Если это так, пожалуйста, откройте проблему.
Если вы хотите работать в режиме ICMP, введите:
sudo ./plpmtu -p icmp -s <server-ipaddr>
Если вы хотите вместо этого запустить режим UDP :
sudo ./plpmtu -p udp -s <server-ipaddr:port>
Для использования необработанных сокетов необходимы права администратора.
| Спецификатор | Описание |
|---|---|
| -p {icmp/udp} | Выберите, в каком режиме работать. |
| -s <адрес[:порт]> | Укажите адрес сервера. При работе в режиме UDP необходимо также указать порт назначения, добавив «:port» (например -s 8.8.8.8:12345 ). |
| -l <адрес:порт> | Необязательный. Выберите, по какому адресу выполнять привязку(); используется в режиме UDP; может быть удалено. |
| -t <тайм-аут> | Необязательный. Выберите максимальное время ожидания ответа от сервера, по умолчанию — 1 секунда; время выражается в миллисекундах. |
| -r <максимальные требования> | Необязательный. Выберите максимальное количество неудачных попыток, необходимое для объявления размера MTU недействительным. По умолчанию — 3 попытки. |
sudo ./plpmtu -p icmp -s 184.12.26.131
Выполните обнаружение MTU (режим ICMP) с помощью 184.12.26.131.
sudo ./plpmtu -p udp -s 184.12.26.131:24000 -t 1500 -r 5
Выполните обнаружение MTU (режим UDP) с адресом 184.12.26.131 на порту 24000. Если ответ не получен в течение 1,5 секунд 5 раз подряд, уменьшите порог MTU.
