О нас

Услуги и цены

Настройка доступа

Справочная

Ссылки

ВЕБ-Хостинг

Проблемы MTU/MRU при работе через Dialup-IP (некоторые сайты открываются только через прокси, иногда не работает интернет-телефон, через ICQ не всегда возможна пересылка файлов)

Сложности возникают из-за особенностей реализации TCP-протокола в RAS Windows. Для знакомых с теорией сообщим, что эта OS не учитывает размер MTU, назначаемый при установке связи с провайдером (обычно при работе по Dialup-IP MTU между маршрутизатором провайдера и сервисом RAS клиента не превышает 576 байт).

В опциях протокола TCP есть команда для установки размера MSS (сигнатура 02, размер - 04 октета). При установке связи (открытие сокета) посылается пакет TCP с флагом SYN и этой опцией (в конце пакета сразу за полем "urgent pointer"). Windows пишет (02 04 05 b4) (MSS=1460), для сравнения, Linux пишет (02 04 02 18) (MSS=536). В IP-пакете, в который вложен TCP пакет, в обоих операционках стоит флаг 40 (don't fragment=1).

Удаленный хост отвечает IP с флагом 40 (don't fragment) и вложенным TCP с флагом (SYN+ASK) с опцией MSS (для gazeta.ru - 02 04 05 b4 в обоих операционках).

Некоторые сайты отвечают пакетом IP со сброшенным флагом (don't fragment=0) и/или TCP (SYN+ASK) c опцией (02 04 02 18). С ними проблем не возникает. Например,

• aport.ru - DF=0, MSS=536
• sovtest.ru - DF=1, MSS=536
• max.de - DF=1, MSS=536.

Не отвечающие сайты всегда устанавливают DF=1, MSS=1460.

Для приема пакетов нам не важен размер пакетов, принимаемых удаленным хостом, но если удаленный хост говорит MSS=536, то это значит, что он не поддерживает пакеты с MSS>536 и на передачу.

При возникновении проблем, получив пакет с DF=1 и MSS=1460, который надо фрагментировать для ppp с малым mtu, маршрутизатор провайдера не сможет его фрагментировать (разбить на несколько мелких TCP-пакетов), и уничтожит. При этом удаленному хосту посылается ICMP-сообщение "Fragmentation needed" ("требуется фрагментация") и это сообщение должны пропустить все роутеры к удаленному хосту, а сам удаленный хост должен отреагировать на эту просьбу соответствующим образом (специальный алгоритм).

Т.о. использование ICMP-пакетов в проверках MTU может вызывать проблемы. Все хорошие TCP-реализации используют проверки MTU, чтобы выяснить максимальный размер нефрагментированного пакета, который может принять адресат (фрагментация снижает эффективность, особенно при потере некоторых фрагментов). Проверка MTU осуществляется посылкой пакетов с установленным битом "Don't Fragment". В ответ на эти пакеты может прийти ICMP-ответ "Fragmentation needed but DF set" (необходима фрагментация, но установлен флаг DF). Это пакеты типа "destination unreachable", и если они не получены, локальный хост не будет уменьшать MTU, и эффективность будет крайне низкой или нулевой.

Однако, некоторые маршрутизаторы в интернете не пропускают через себя ICMP-сообщение "Fragmentation needed", а просто уничтожают его. Т.о., если между маршрутизатором провайдера и удаленным хостом не проходят эти ICMP-сообщения, то для клиента становится невозможным принять от такого хоста по протоколу TCP информацию, длиной больше 536 байт.

Windows не знает про MTU=576 (это значение ставит маршрутизатор провайдера, Windows с этим соглашается, но размер MSS остается 1460, т.е. MTU<MSS, а должно быть MTU=MSS+40) и считает, что может принимать пакеты размером до 1460, т.к. посылает эту цифру в TCP-опциях (MSS). Т.е. Windows даже не будет говорить кому-либо по ICMP "fragmentation needed".

Причем, такая проблема возникает только при работе через Dialup-IP без использования прокси-сервера. При работе на выделенной линии MTU клиента обычно 1500 байт. Если работать через прокси, то наш сервер легко сможет принять от удаленного хоста длинный пакет, а затем наш маршрутизатор договорится с нашим сервером о необходимости фрагментации.

Решение проблемы в Windows 95

По умолчанию, Win95 использует максимальные значения MTU. MTU и RWIN скрыты в реестре в двух местах. MTU может быть задано для каждого протокола/адаптера, RWIN устанавливается глобально. Для изменения MTU, откройте редактор реестра regedit.exe:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

\Class\NetTrans\

Найдите то значение 000n, которое является протоколом TCP/IP для Вашего подключения, затем откройте этот 000n. Внутри этого 000n, создайте новый _СТРОКОВЫЙ_ параметр с названием

"MaxMTU"

и введите значение. Используемое по умолчанию - 1500 (считается оптимальным для интранет), для интернет оптимальнее использовать значение 576, минимальное значение 552. RWIN для интранет лучше
установить равным 4096, а для интернет - 2048.

Решение проблемы в Windows 98

В Windows 98 Microsoft признает важность правильной настройки MTU, но делает это несколько своеобразно. Если в "Панели управления" выбрать значок "Сеть" и просмотреть "Свойства" "Контроллера удаленного доступа", то в открывшемся окне закладки "Дополнительно" можно в расположенном слева списке выбрать опцию "Размер пакета IP" и установить одно из жестко привязанных к определенным величинам MTU обозначений: "Авто", "Малый", "Средний" или "Большой". Малый пакет соответствует величине 576, средний - 1000, а большой - 1500. Если вы зададите опцию "Авто", то Windows будет пытаться сама определять тип соединения и в зависимости от результата подставлять нужный размер пакета. Установить произвольное значение MTU, а также задать свои параметры для RWIN и TTL в Windows 98 можно только через ручную корректировку реестра - процедура та же, что и для Windows 95.

Решение проблемы в Windows NT

Для Windows NT решение проблемы опубликовано в MS KB как ошибка, которую обещали устранить еще после SP4. Надо исправить вот эти ключи реестра:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\

Services\NdisWan\Parameters

Value name: IPMTU

Data type : REG_DWORD

Data range: 1 - 1500 (default is 1500)

Установите IPMTU=576.

Value name: TunnelMTU

Data type : REG_DWORD

Data range: 1 - 1500 (default is 1400)

Установите TunnelMTU=476.

Решение проблемы в Windows 2000

Добавьте в реестр следующие ключи:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Services\NdisWan\Parameters\Protocols\0]
"ProtocolType"=dword:00000800
"PPPProtocolType"=dword:00000021
"ProtocolMTU"=dword:00000240
"TunnelMTU"=dword:000001dc
"PacketQueueDepth"=dword:00000080

Документация о проблеме на нашем ftp-сервере

На нашем ftp-сервере (ftp.kursknet.ru) Вы можете найти подборку документов о проблеме MTU/MRU, "черных дыр" и т.п. Смотрите все это по адресу ftp://ftp.kursknet.ru/pub/Inet_Speed&FixMTU/DOC!/. Далее по тексту, имена файлов, выделенные жирным курсивом, соответствуют документам из этого архива. Программное обеспечение для управления MTU/MRU/MSS можно найти здесь (в Windows NT не все работает, нашу проблему в NT оно не решит!) ftp://ftp.kursknet.ru/pub/Inet_Speed&FixMTU/.

Устраняется проблема в Windows 9x просто (файл win_95_fix), в Windows NT - весьма нестандартно, ибо у нее свой алгоритм оптимизации MTU/MSS. Для Windows NT решение проблемы опубликовано в MS KB как ошибка (nt_ras_fix!.txt), которую обещали исправить еще после SP4, а пока рекомендовали править реестр. Воз и ныне там...

Советы, которые ничем не помогут для Windows NT, но встречаются в рунете на многих сайтах - win_nt_bug. Рецепты по оптимизации MTU в Windows NT - win_nt_optim (но это лишь оптимизация, которая не решает проблемы с сайтами типа gazeta.ru!). Описание программного обеспечения для оптимизации soft_opt.txt, url_opt_best.txt (тоже не решает проблемы с сайтами типа gazeta.ru в Windows NT!). В файлах mss.txt, mtu.txt - описание MTU и MSS и их особенностей в Windows. black_hole.txt - описание алгоритма борьбы с черными дырами в TCP для Windows NT (но это не наш случай!). Описание проблемы от Linux и Cisco - problem1.txt, cisco_doc1.txt.