Настройте ваш Dial-Up TCP/IP-стек на максимум производительности

Я люблю следить за красным светящимся глазком RD моего "Курьера". Сладкий яд Интернета быстро наполняет меня и мой компьютер, когда этот глазок светится ровно и довольно ярко при загрузке Web-страницы или файла по FTP. Однако настроение часто портится, когда яркость глазка заметно падает или он "моргает". Еще хуже дело, если он гаснет надолго: на секунду, две, пять. Или даже 10, 20, 30 секунд проходит, а он все мертв. Секунда, две, пять - это еще куда ни шло, специфика HTTP 1.0 такова: ждите реконнекта с вашим сайтом. Но вот замирание на 10, 20 и более секунд - это весьма похоже на "несварение" (channel indigestion) у вашего 40-долларового или близкого к тому провайдера, и пробовать бороться с этим можно, заведя себе 32 Мбайт RAM и персональный DNS-сервер. Чуть-чуть помогает сманить хоть пару дюжин других пользователей к какому-нибудь новому "условно-бесплатному" провайдеру: любитель халявы подвижен, как ртуть. Конечно, радикальнее было бы поубивать их всех, этих любителей онлайнового "Квака" и качальщиков очередных 44 Мбайт "Эксплорера" одной доброй фирмы. Но, как говорится, богородица не велит даже для благого дела облегчить непосильные тяготы вашего провайдера с этого клиентского конца. 10-20-процентного прироста пропускной способности за счет действительно работающего соединения типа х2 или K56Flex еще придется подождать (можно и вовсе не дождаться), а вот отстроить свое собственное TCP/IP-соединение, добавляющее от 20 до 50% производительности, это при некотором терпении и желании поэкспериментировать вполне реально уже сейчас.

В том вавилонском столпотворении, которое являет собой Интернет сегодня, максимальная производительность TCP/IP-соединения даже в одном единственном сиюминутном сеансе может зависеть от немереной кучи факторов. Но с полдюжины из них поддаются настройке на вашем клиентском конце. Более того, подобная настройка просто необходима для платформ Windows 3.1x/95, OSR2, Memphis и отчасти Windows NT, поскольку параметры по умолчанию в их реестрах мало чему путному соответствуют.

Начать надо с того, чтобы запастись программой типа Net.Medic для набора статистики и набрать эту самую статистику вдумчиво и аккуратно. После придется сличать ее с новой статистикой по коннектам с теми же хостами, набранной с параметрами, перестраиваемыми по приведенной ниже методике. Оптимального набора этих параметров, устраивающих всех и вся, включая "Кваков", не существует, и перестройку, возможно, придется повторить, да не один раз. Есть, правда, программки, позволяющие поудобнее задать все эти вариации, однако тонкая настройка - предмет слишком деликатный, чтобы надеяться получить идеальный TCP/IP-стек, совсем уж ничего не понимая. Вдобавок с их помощью можно до ступора запортить реестр Windows 95. Так что предварительно сохраните в особом месте или под другим именем ваши исходные USER.DAT и SYSTEM.DAT, чтоб не было мучительно больно.

Итак, настройке подлежат следующие параметры.

1. MTU, Maximum Transmission Unit, максимальный передаваемый блок. Одна добрая фирма, недавно придумавшая роскошное транснациональное ругательство "коннектоид" (connectoid), попутно иногда обзывает этот блок MaxMTU, что несомненно, гораздо круче (видимо, из латыни: maximum maximorum, то есть "глобальнее не бывает"). Здесь под MTU будет пониматься максимальное количество информации, или размер пакета, который может быть передан в одном физическом кадре данной сети либо данного сегмента сети. Такой пакет содержит заголовок и сопроводительную информацию, используемые маршрутизаторами для его адресации. Если некоторый пакет пересылается через сеть (сегмент сети) с паспортным MTU, меньшим, чем длина кадра для данного пакета, то пакет фрагментируется. Это неизбежно приводит к снижению производительности TCP/IP-соединения, поскольку полученные фрагменты требуют обратной сборки, особо неприятной, если они, не дай Бог, загуляют по разным маршрутам. Величина MTU, принимаемая по умолчанию в Windows 95, а также в Trumpet Winsock и зачастую у вашего затюканного провайдера, составляет 1500 и происходит из стандартного значения для сетей Ethernet, однако это значение далеко не довлеет на просторах Интернета. Все больше указаний на то, что наиболее распространенным значением, чуть ли не стандартом для маршрутизаторов и шлюзов Интернета является MTU=576. Однако экспериментировать придется со всем диапазоном, от 512 до 1500, поскольку у каждого свой Интернет, где он или она гуляет.
2. Величине MTU ставится в соответствие некоторое значение MSS (Maximum Segment Size, максимальный размер сегмента [данных, уложенных в MTU]). Установленное значение MSS представляет собой наибольший сегмент данных, который ваш стек может принять в одном пакете данного соединения. Величина MSS должна быть меньше MTU по меньшей мере на 40 байт заголовка и сопроводительных данных. Встречавшиеся совсем недавно рекомендации, определять MSS как MTU-60, вызваны были, похоже, стремлением перебдеть, однако потеря двадцати драгоценных "полезных" байтов на каждом пакете оказалась ничем не оправданной. Вообще, счет в этой борьбе будет вестись до последнего байта. Так что MSS=MTU-40.
3. Хорошо бы работать на максимуме RWIN (TCP Receive Window, окно приема на TCP-соединении), покуда у провайдера буферов хватит, однако чрезмерная ширина этого окна увеличивает риск разом утерять весьма длинную посылку. Дело здесь в том, что ваш показатель RWIN пересылается удаленному хосту, который, в свою очередь, чаще всего готов разразиться длинной пулеметной очередью IP-пакетов. А на маршрутах случается всякое, включая вашего провайдера. Придется потом долго переспрашивать. Обратно, при предельно малом окошке RWIN, например при RWIN=MSS, передача опять замедлится, по меньшей мере из-за того, что шансов у n пакетов вылететь, не разбросавшись по разным коннектам с хостом, существенно меньше, чем на одном коннекте с RWIN=n*MSS. Надо так понимать, здесь могут существовать оптимумы, и действительно, заядлые настройщики TCP/IP рекомендуют в основном значения n, равные 4, или 6, или 8. Те, кто смог отыскать особо "чистые" соединения с хостами типа "streaming-что-то", телефонных и т. п., вольны попробовать n=10 или даже n=12, правда, похоже, лучше в темную, глухую ночь, когда и так все "летает". С повсеместным внедрением HTTP 1.1, возможно, получится удачней поиграть с большими n.
4. Есть еще параметры TTL (Time To Live, время жизни), а также (для Windows 95/NT) Session Keep Alive (максимальная длительность поддержания соединения открытым). Далее: опция PMTU (Path MTU, путевое значение MTU в автоматическом поиске маршрута с наибольшим MTU из всех минимальных по маршрутам), опция PMTU Black Hole Detect (обнаружение "черной дыры" в PMTU). Наконец, NDI Cache (Network Driver Interface Cache), то бишь размер кэша, используемого для хранения путей маршрутизации по типу Token Ring. С вариацией всех этих параметров особо резких улучшений ожидать не приходится, но попробовать стоит. Величину TTL можно оставить той, что по умолчанию (32 с), но можно испытать и рекомендованную (www.sns-access.com): 64 с. Особой разницы я не ощутил и пока не вижу каких-то шансов этому рекомендованному TTL вообще проявиться с лучшей стороны.

Невнятные рассуждения приводятся и для 10 минут вместо 1 часа по умолчанию в значении Session Keep Alive, а значимого эффекта я опять не наблюдал. Довольно странная история связана с PMTU и PMTU Black Hole Detect. В Windows 95 опция автоматического определения путевого MTU включена по умолчанию, похоже, в рассуждении отыскать гладкий, нефрагментирующий маршрут с MTU=1500, принятым также по умолчанию. Но фокус в том, что Интернет, так сказать, "в мировом масштабе" содержит слишком много маршрутизаторов с MTU=576, 512, 552, 556, 1024, 1152. Есть даже машинки с MTU=1524 где-то в Соединенном Королевстве. Так что маловато будет шансов отыскать хайвей с MTU=1500 повсюду до места назначения и проскакать по нему без толкотни с такими же умельцами, если вы дозваниваетесь из Урюпинска или Марьиной Рощи, а не, скажем, из Сан-Хосе (Калифорния). Да и времени на такие поиски можно потратить прилично, дотягиваясь до предмета из Урюпинска, поскольку это у них там топология с адаптивно настраивающимся трафиком, а к нам только какие-то куцые ниточки дотягиваются из этого клубка.

Понятно, если начинать с MaxMTU в районе 500 с копейками, то вроде бы особой разницы нет, пусть себе ищет нефрагментирующую тропку, когда это и так почти что первая попавшаяся. Все же предлагается поэкспериментировать с отключенной опцией PMTU. Соответственно, в Windows 95поиски "черной дыры" отключены по умолчанию. Включение этой опции означает, что TCP-запрос будет пытаться обнаруживать такие маршрутизаторы с максимальным MTU, которые в ответ на поиски PMTU не отсылают ICMP-сообщений о необходимости фрагментации. Теперь в подобном TCP-запросе будут посылаться сегменты со сброшенным байтом DF (Don't Fragment, не фрагментировать!) в тех случаях, если повторные передачи сегмента прошли незамеченными. Если же такие пробные сегменты замечены, величина MTU будет уменьшена, а бит DF установлен для последующих пакетов данного соединения.

Понятно, что специальная зондирующая процедура предварительного обнаружения "черных дыр" снижает общий к.п.д. соединения, однако подобные "молчаливые" маршрутизаторы способны просто отменить обнаружение PMTU, что в ряде случаев еще хуже, если это обнаружение в результате проведенных настроек MTU могло стать вполне тривиальным процессом. Подробнее обо всей этой затее с PMTU можно ознакомиться в RFC 1191 (например, здесь: hotline.pvtnet.cz/dokumentace/rfc/rfc1191.html). В Windows NT PMTU с "черной дырой" конфигурируются автоматически, и вроде бы нужно только убедиться, что вы еще в Мневниках, а не в Редмонде (Орегон), то есть послетало с импортных умолчаний само. Для NDI Cache некоторые хвалят значение 16 вместо 0 по умолчанию. Нехай будут шаманские 16. Ничего дурного не наблюдал ни от 0, ни от 16.

Теперь можно начинать курочить, последний раз заглянув в свою статистику прошлой жизни. Вручную реестр (после обязательного сохранения где-нибудь исходных USER.DAT и SYSTEM.DAT) правится следующим образом:

MaxMTU = xxxx (512, 552, 576, 1006, 1024, 1152, 1500 или даже 1524.) в разделе

HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\Class\NetTrans\00yy (Здесь yy будет в диапазоне от 00 до 30, отвечая различным вариантам установок.)

DefaultRcvWindow = yyyy (4*, 6*, 8* или 10*MSS; MSS=MTU-40.) в разделе

HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\VxD\MSTCP

PMTUDiscovery = 0 или 1 в разделе

HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\VxD\MSTCP

PMTUBlackHoleDetect = 0 или 1 в разделе

HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\VxD\MSTCP

DefaultTTL = 32 или 64 в разделе

HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\VxD\MSTCP

default = xx в разделе

HKEY_LOCAL_MACHINE\System\CurrentControlSet \Services\VxD\NWLink\Ndi\params\cachesize

(Это умолчание хх для Windows 95 составляет 0. Отмечаются более качественные результаты при хх=16)

Тем, кому лень это проделывать всякий раз вручную, можно порекомендовать скачать и применять специальные программки TweakDUN версии 1.2 (http://sns-access.com/%7Enetpro/maxmtu.htm) или MTU-Speed версии 3.08 (http://mjs.u-net.com/mtuspeed/mtuspeed.htm). Только неплохо всякий раз убеждаться в правильности работы программок, рассматривая эти разделы реестра после проведенных настроек.

Ну вот и все. Дерзайте! Те, у кого еще не изжиты нефатальные ошибки типа CRC OVERRUN Error, боритесь. Их, может быть, и мало на потоках до 28,8 кбит/с, но полезет больше при 33,6К и через край на коннектах с 56К. Смотрите сами: три недели работы с моим более-менее отстроенным стеком дали приросты производительности на 30, а то и под 50%. В строке состояния все чаще стали появляться и долго держаться цифры 3.0, 3.1, 3.2 Kbps по FTP, от 1.5 до 2.5, даже с выхлестами до 4.5 Kbps в загрузках Web-страниц. Этак я, чего доброго, могу теперь и поменьше в онлайне торчать. Понятное дело, Arena под Linux, или моя новая игрушка - крохотулечка Voyager под QNX, как "летали" так и "летают", у них стеки отродясь не такие "кривые", как у одной доброй фирмы. Но, по крайней мере, ясно, к чему следует стремиться.