Что? Все равно не работает? Хм… Боги, боги, зачем вы так несправедливы?! Ничего не остается, как расстаться с надеждой пересылки пакетов максимального размера и перейти на размер, обязательный (ну, формально обязательный) для всех маршрутизаторов – 576 байт. Для этого в той же самой ветке реестра найдите (создайте) двоичный параметр PMTUDiscovery для Windows 95\98, а для Windows NT\2000 – EnablePMTUDiscovery , и присвойте ему значение "0". Перезагрузитесь. Ну, должно же это, наконец, заработать!
Кстати, с типом двух этих ключей творится что-то непонятное. Документация от Microsoft утверждает, что он (тип, в смысле) должен представлять собой двойное слово, то бишь, по-английски DWORD. Однако у автора под Windows 2000 закачка по ftp начинает работать только после создания указанных ключей типа одиночного слова (WORD), а DWORD-ключи операционная система упорно игнорирует. Мистика какая-то…
Теперь поговорим об оптимизации соединения. Оптимизация – дело непростое. Это не то что: работает система или нет. Работать-то она работает, вот только как? Тривиальным измерением скорости скачиваемого файла ничего выяснить не удастся. График скорости только в исключительных случаях (и на хороших каналах) представляется прямой линией. Гораздо чаще он напоминает трассу Урюпинск – Ханты-Мансийск: сплошные бугры, колдобины, ямы… словом, крайне испещренная местность. Говорить о средней скорости можно только в переносном смысле, тем паче, что она может сильно варьироваться в зависимости от времени суток, сервера, с которым установлено соединение, количества осадков, выпавших в Африке, да мало ли еще от чего!
До начала экспериментов потребуется собрать статистику работы сети за некоторое время, скажем, за неделю. В этом поможет программа Net Medic (http://download.ru/) или любая другая, аналогичная ей. Затем, после внесения изменений в настройки системы, собирается другая статистика, опять-таки на протяжении семи-десяти дней, и сравнивается с предыдущей: изменилось ли что и если да, то в какую сторону?
Дело это, конечно, медленное, но иного способа тонкой настройки нет. Необходимо убедиться в увеличении скорости обмена со всеми серверами и во все времена суток, то есть, найти компромиссный оптимум. Не все, что хорошо для одного случая, так же хорошо подходит для другого. Взять ту же фрагментацию уже рассмотренную выше. Автоматическое определение подходящего размера пакета не всегда увеличивает скорость соединения, нередко оно ее уменьшает, подчас весьма значительно, – автоматическое определение занимает какое-то время, увеличивая накладные расходы и снижая КПД. Имеет смысл попробовать найти оптимальное значение вручную.
Первым делом необходимо указать Windows, что требуется использовать не максимально возможный, а заранее оговоренный размер пакета. Для этого установите значение ключа PMTUDiscovery (EnablePMTUDiscovery) в ноль. Затем задайте желаемый размер пакета. По умолчанию он равен 576 байтам – это значение по стандарту должны поддерживать все маршрутизаторы, – да только кто эти стандарты соблюдает? Вот и встречаются узлы, обрабатывающие пакеты размером не более 512, 522, 556,… байт. В принципе, можно поставить 500 и не мучаться проблемой выбора, но так неинтересно. Разве не заманчиво методичным подбором байтов оптимизировать соединение до конца?
Размер пакетов для Windows 95\98 задается ключом MaxMTU, находящимся в той же самой ветке реестра, что и предыдущие ключи. С Windows NT\2000 посложнее: чтобы выяснить местоположение ключа MTU необходимо определить идентификатор используемого адаптера. Перечень всех адаптеров компьютера содержится в ключе Adapters ветки HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ Tcpip \ Parameters. Как правило, большинство персональных компьютеров обходятся лишь одним адаптером – контроллером удаленного доступа (нет, это не плата расширения, это драйвер такой) и буридановой проблемы выбора нужного идентификатора не стоит. Идентификатор же, – это такое длинное малопонятное число, например: 20692835-7194-467A-A2DC-0FAE23F0A70D.
Запоминаем (записываем) его и открываем ветку HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ ИдентификаторАдаптера \ Parameters \ Tcpip (В Windows 2000 – HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Parameters \ Tcpip \ Interfaces \ ИдентификаторАдаптера)
Среди прочего хлама здесь должен находиться только что запомненный идентификатор адаптера, а в нем – ключ MTU, содержащий в себе максимальный размер пакета в байтах. Если такого ключа нет, его необходимо создать. Тип ключа MTU в обоих случаях соответствует двойному слову (DWORD).
Второй бастион оптимизации – размер TCP-окна. Чем "шире" окно, тем выше производительность, но, в то же время, больше издержки на повторные пересылки: случись какой сбой, – не до конца заполненное окно очистится и придется его "набивать" с самого начала. К тому же, баловство с неумеренно широкими окнами часто приводит к образованию заторов в сети: промежуточные узлы не успевают обрабатывать сыплющийся на них поток пакетов и начинают жутко тормозить. Причем, не только у виновника несчастья, но и у других ни в чем не повинных пользователей.
Ширина TCP-окна должна быть кратна размеру пакета за вычетом длины заголовка и превосходить его по крайне мере в четыре-шесть раз. В некоторых случаях наивысшая производительность достигается при ширине окна в 10х-12х (где х – размер пакета без заголовка, называемый так же "квиком"), а то и больше. Некоторые отчаянные головы пробуют даже бóльшие значения и утверждают, что все работает "на ура!", но у автора такие значения не показывают чудес производительности, поэтому подтвердить сказанное он не берется. Размер заголовка непостоянен и варьируется от 40 до 60 байт, – не забывайте об этом при поиске оптимальной ширины окна!
Для изменения размеров окна откройте ветвь реестра HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ VxD \ MSTCP для Windows 95\98 и HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ Tcpip \ Parameters для Windows NT\2000. Найдите или при необходимости создайте двоичный параметр (двойное слово, DWORD) DefaultRcvWindow для Windows 95\98 и TcpWindowSize для Windows NT\2000. Присвойте ему желаемое значение (например "3680", если размер пакета, заданный ключом MTU, равен 500 байт: (500 – 40) * 8 = 3/600) и перезагрузитесь.
Оцените, как изменилась скорость соединения. Если она возросла, увеличьте ширину окна еще на один квик (не байт!), если уменьшилась, – сузьте окно, а если осталась без изменений, – расширьте окно на пару квиков. Так, в конце концов, будет найдено оптимальное значение. Интернет-гуру утверждают, что оптимум ширины окна зависит от загруженности провайдера и сильно колеблется в течение суток. При максимальной загруженности в "час пик" окно лучше прикрывать, оставляя лишь узкую щель (3х-4х), а ночью, когда все нормальные юзеры давно баиньки, и канал полностью свободен – широко распахивать обе створки (10x и выше). Никаких суточных вариаций у своих провайдеров автор не замечал, но готов поверить, что в некоторых случаях они могут иметь место, и гуру не врут.
Помимо вышеупомянутых опций реестр Windows содержит множество других значений, относящихся к TCP/IP, но рассказывать о каждом из них было бы слишком утомительно, да и нецелесообразно, – для этого пришлось бы написать отдельную книгу, страниц эдак на пятьсот.