Общеизвестно, что скорость передачи данных возрастает с увеличением размера пакета. Это вполне естественно, ведь для каждого пакета в потоке принимается решение о выборе маршрута. К примеру, файл, размером в 1 мегабайт, будет передан быстрее, если он будет разбит на 700 пакетов (при максимальном размере пакета), а не на 4000.
Однако, не все сегменты Интернет могут передавать пакеты, с максимальной полезной нагрузкой в 1460 байт. Поэтому необходимо найти такой размер, который будет максимально возможным для заданного маршрута.
Процесс поиска такого размера называется ‘Path MTU Discovery’ (Поиск Максимального Размера Пакета для выбранного Пути), где MTU означает ‘Maximum Transfer Unit’ (Максимальный Размер Блока передачи данных).
Когда на маршрутизатор поступает пакет, который не может быть передан по выбранному маршруту целиком (без фрагментации) И у него установлен флаг «Don’t Fragment» (Не фрагментировать), то в ответ отправляется ICMP-сообщение о том, что пакет был сброшен из-за невозможности «протолкнуть» его по выбранному маршруту. Компьютер, выполнивший посылку, начинает последовательно уменьшать размер пакетов до тех пор, пока они не смогут быть переданы по выбранному маршруту.
Все бы ничего, если бы не появились злоумышленники, которые задались целью нарушить нормальную работу Сети. Это, в свою очередь, вынуждает администраторов ограничивать или вообще блокировать ICMP-трафик с целью повысить отказоустойчивость вверенного им фрагмента сети.
В результате таких действий процесс поиска оптимального размера пакета работает все хуже и хуже, а на некоторых маршрутизаторах вообще не работает, что в свою очередь порождает сеансы TCP/IP с весьма странным поведением, которые «умирают» спустя некоторое время.
Хотя у меня нет никаких доказательств, но я знаю по крайней мере два сайта, с которыми наблюдается подобная проблема и перед обоими стоит Alteon Acedirectors — возможно кто-то имеет более богатый опыт и сможет подсказать как и почему это происходит.
15.6.1. Решение
Если вы столкнетесь с подобной проблемой, то можно посоветовать отключить ‘Path MTU Discovery’ и установить MTU вручную. Koos van den Hout пишет:
У меня возникла следующая проблема: для арендованного мною канала, работающего через ppp, на скорости 33.6К, я установил величину MTU/MRU, равную 296. Это дает мне достаточно приемлемое время отклика.
Со моей стороны установлен роутер (с маскарадингом), работающий под управлением Linux.
Недавно я вынес маршрутизатор на отдельный компьютер, так что теперь большая часть приложений выполняется на отдельной машине.
После этого возникла масса проблем с авторизацией в irc. В процессе длительных поисков я установил, что само соединение проходит и даже показывается системой как ‘connected’, но я не получал motd от irc (motd — от англ. Message of The Day, которое демонстрируется после успешной авторизации, прим. перев.). Кроме того, помятуя о проблеме, связанной с MTU, я определил, что проблема исчезала только в том случае, когда MTU устанавливался равным 296. А так как серверы irc блокируют весь трафик, который напрямую не связан с их работой, то в числе блокируемых оказался и ICMP.
Мне удалось убедить администратора WEB-сервера в истинных причинах возникновения проблем, но администратор IRC-сервера отказался устранять их.
Таким образом, передо мной встала необходимость уменьшить MTU для внешнего трафика и оставить нормальное значение для локального.
Решение:
ip route add default via 10.0.0.1 mtu 296
(10.0.0.1 — шлюз по-умолчанию, внутренний адрес маршрутизатора с маскарадингом)
Вообще, можно запретить ‘PMTU Discovery’ путем настройки специфических маршрутов. Например, если проблемы наблюдаются только с определенной подсетью, то это должно помочь:
ip route add 195.96.96.0/24 via 10.0.0.1 mtu 1000
Как уже говорилось выше, Path MTU Discovery не работает в Интернет должным образом. Если вам известны факты существования сегментов в вашей сети, где размер MTU ограничен, то вы уже не можете полагаться на безотказную работу Path MTU Discovery.
Однако, помимо MTU, есть еще один способ ограничения размера пакета — это, так называемый MSS (Maximum Segment Size — Максимальный Размер Сегмента). MSS — это поле в заголовке TCP-пакета SYN.
С недавних пор, ядра Linux и некоторые драйверы PPPoE, стали поддерживать такую особенность, как ‘clamp the MSS’ (ограничение размера MSS).
В этом есть свои плюсы и минусы. С одной стороны, устанавливая MSS, вы недвусмысленно извещаете удаленную сторону о том, что размер пакета не должен превышать заданную величину. Причем для этого не требуется передачи ICMP-сообщений.
С другой стороны — за атакущим сохраняется возможность нарушить связь путем модификации пакетов. Однако, следует заметить, что мы довольно часто используем эту возможность и это приносит свои положительные плоды.
Чтобы иметь возможность манипулировать размером сегмента, у вас должны быть установлены iptables, не ниже 1.2.1a и ядро Linux, не ниже 2.4.3. Основная команда iptables:
# iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Она рассчитает правильный MSS для вашего соединения. Если вы достаточно уверены в себе и в своих знаниях, можете попробовать нечто подобное:
# iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 128
Это правило устанавливает MSS равным 128. Очень полезно, если вы наблюдаете разрывы при передаче голосовых данных, когда поток небольших пакетов VoIP прерывается «огромными» http-пакетами.