Автор: Anael
WMLuck.ru
В последнее время, со всё большей «мультимедизацией» Интернета, стала очень актуальной проблема быстрого доступа к сети. И если лишними денежками на покупку выделенного канала связи вы пока не располагаете, придется заняться настройкой родного диал-ап соединения, а я вам в этом помогу.
Повременная оплата соединения с Интернет горячо любима всеми нерадивыми провайдерами, кривые руки которых не могут как следует отстроить свое хозяйство и обеспечить надлежащую скорость обмена. Клиент получает меньшее количество информации за то же время и в результате дольше торчит в Сети. А время - деньги. В самом что ни на есть прямом смысле этого слова. Вот если бы оплата шла за каждый скачанный мегабайт - будьте покойны - все бы летало, как реактивный бомбардировщик.
Ладно бы, все заключения ограничивались одной скоростью (в смысле - полным отсутствуем таковой). Так нет же - соединение может быть нестабильным, часто обрываться, а то и не работать совсем - некоторые сайты могут не грузиться, ругаясь на загадочную ошибку "TTL Bug", закачка по ftp может вообще не "фэтэпить": да разве ж перечислишь все злоключения, терзающие интернетчика!
Конечно, лучше всего - сменить провайдера, но это не всегда возможно. В больших городах счет провайдеров идет на десятки, а в провинциях он нередко бывает в единичном экземпляре, что вдвойне хуже - монополисту незачем заботиться о своих клиентах - все равно они никуда не убегут, каким бы скверным качество обслуживания ни было. Да и куда бежать-то?
Впрочем, в клинических случаях стоит задуматься о поиске провайдера в соседнем городе. Как ни парадоксально, но даже с учетом междугородней оплаты за телефон, иногда это выходит в несколько раз дешевле. Менее радикальная мера - настроить параметры TCP/IP-соединения на максимальную производительность, что дает прирост скорости обмена от 30% до 200% и избавляет от большей части разрывов. Остаются лишь фатальные сбои и зависания самого провайдера, побороть которые с клиентской стороны принципиально невозможно. Существует множество программ, например, MTUSpeed (http://www.mjs.u-net.com/download.htm), как раз и предназначенных для этой цели. Одна беда - ни одна из них не работает в полностью автоматическом режиме - все они всего лишь оболочки над системным реестром Windows, - так сказать, комфортный инструмент внесения в него изменений. Но легко сказать "вносить"! А как? Множество малопонятных и ничего не говорящих параметров, порой вообще без каких-либо пояснений. Попытки же разобраться во всем "методом тыка" скорее еще больше снизят скорость. Тут без хорошего руководства не обойтись! Первое, чем мы займемся, - попытаемся устранить разрывы TCP-соединений (не путать с разрывами модемных соединений!). Они довольно многочисленны и разнообразны, а причиной их возникновения может быть и провайдер, и один из маршрутизаторов в длинной цепочке передачи пакетов, и сам удаленный сервер, с которым, собственно, и установлено соединение, и: да мало ли еще кто! Начнем с провайдера. Итак, представим себе следующую картину: модем не бросает трубку, но все установленные соединения вдруг обрываются, и после этого ни к одному серверу подключиться не удается. Положение спасает лишь реконнект - отключение от Интернета и повторный заход вновь. Мало того, что это медленно, есть риск нарваться на глухую "бизю" - если освободившийся телефонный номер мгновенно займет другой клиент (особенно если у провайдера острый недостаток входных номеров). Такие разрывы могут происходить и эпизодически, и по несколько раз в час, а то и в минуту, представляя собой настоящую пытку. Причина их возникновения, скорее всего в том, что у провайдера неправильно настроен DHCP-сервер. Тот самый, что выдает пользователям IP-адреса. Как и любой собственник, он выдает их не насовсем, а на некоторое, подчас весьма непродолжительное, время. Если клиент (точнее, его операционная система) по каким-то там причинам (сеть тормознула, крыша поехала, пакет кто-то "прибил") не успеет продлить срок аренды, его IP-адрес будет безжалостно отнят. А когда же, наконец клиент "проснется" и пошлет петицию DHCP-серверу, тот смилостивится и отдаст другой IP-адрес, типа, на, пользуйся на здоровье! И вроде бы все ничего, да вот не понимает Windows 95/98 таких извращений! Она ожидает получения IP-адреса всего лишь один раз - на стадии подключения к провайдеру. Вернее, получить-то IP-адрес она получает, но вот включить его в таблицу маршрутизации "забывает", и ни один отправляемый пакет не может уйти дальше своего компьютера. Приходится, взяв инициативу в свои руки, исправлять положение самостоятельно. Прежде всего необходимо в сеансе MS-DOS запустить утилиту ipconfig (входит в штатную поставку Windows) и посмотреть, какой у нас IP-адрес. Если он выглядит как "0.0.0.0", - значит, DHCP-сервер висит глухо. Если же IP равен "127.0.0.1", - сети напрочь нет и тут что-то серьезное. А вот любое другое значение указывает на верный IP-адрес, который необходимо добавить в голову таблицы маршрутизации, передав его утилите route из штатной поставки Windows следующим образом: "route.exe ADD 0.0.0.0 MASK 0.0.0.0 Ваш IP METRIC 1". Попробуйте установить соединение с каким-нибудь сервером - теперь все должно заработать. Работает? Вот и славненько! Однако восстановить соединение без реконнекта - это только полдела. Хорошо бы устранить и причину этих разрывов - ведь не все же сервера поддерживают докачку, и частые разрывы создают большие проблемы. Но на клиентской стороне очень мало что можно сделать, да и то только программистам. Единственное доступное "простым смертным" решение - перейти на Windows 2000 - с этой проблемой она справляется на раз!
Второй по счету источник неприятностей - эта пресловутая ошибка "TTL bug", приводящая к невозможности установки соединения. Дело в том, что во избежание засорения Сети "летучими голландцами", то есть, попросту говоря, зацикленными пакетами, каждый из них имеет ограниченный срок существования, указанный в заголовке и измеряемый количеством промежуточных узлов, которые может посетить пакет. Если пакет не будет доставлен за это время, он "прибивается" очередным маршрутизатором c посылкой отправителю соответствующего "похоронного" уведомления. Чем больше транзитных узлов расположено между отправителем и получателем, тем дольше пакеты добираются из одного конца в другой. К счастью, время жизни пакета (аббревиатура TTL так и расшифровывается: Time To Live - время жизни) очень легко изменить - запустите Редактор Реестра, предварительно зарезервировав сам реестр, и откройте ветвь HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControl-Set\Services\ Tcpip\Parameters\ DefaultTTL для ОС Windows NT\2000 и HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services-\ VxD\MSTCP\DefaultTTL для Windows 9x - она-то и управляет сроком жизни пакетов. По умолчанию он равен 32 узлам, но, как показывает практика, в некоторых случаях этого явно недостаточно, и стоит увеличить его по крайней мере вдвое. (Можно и больше - но от этого лучше не станет, хотя и хуже - тоже). После внесения изменений в реестр следует перезагрузиться, заново войти в Сеть и проверить -возымело ли это какое-то действие.
Теперь поговорим об оптимизации соединения. Оптимизация - дело непростое. Это не то, что работает система или нет. Работать-то она работает, вот только как? Тривиальным измерением скорости скачиваемого файла ничего выяснить не удастся. График скорости только в исключительных случаях (и на хороших каналах) представляется прямой линией. Говорить о средней скорости можно только в переносном смысле, тем паче, что она может сильно варьироваться в зависимости от времени суток и сервера, с которым установлено соединение. До начала экспериментов потребуется собрать статистику работы Сети за некоторое время, скажем, за неделю. В этом поможет программа Net Medic (www.download.ru) или любая другая, аналогичная ей. Затем, после внесения изменений в настройки системы, собирается другая статистика, опять-таки на протяжении семи-десяти дней, и сравнивается с предыдущей - изменилось ли что, и если да, то в какую сторону? Дело это, конечно, медленное, но иного способа тонкой настройки нет. Необходимо убедиться в увеличении скорости обмена со всеми серверами и во все времена суток, то есть, найти компромиссный оптимум. Не все, что хорошо для одного случая, так же хорошо подходит для другого.
Для оптимизации связи займемся поиском оптимального размера TCP-окна. Чем "шире" окно, тем выше производительность, но в то же время больше издержки на повторные пересылки: случись какой сбой - не до конца заполненное окно очистится, и придется его "набивать" с самого начала. К тому же баловство с неумеренно широкими окнами часто приводит к образованию заторов в Сети - промежуточные узлы не успевают обрабатывать сыплющийся на них поток пакетов и все начинает жутко тормозить. Причем не только у виновника несчастья, но и у других, ни в чем не повинных пользователей. Ширина TCP-окна должна быть кратна размеру пакета за вычетом длины заголовка и превосходить его по крайней мере в четыре-шесть раз. В некоторых случаях наивысшая производительность достигается при ширине окна в 10х-12х (где х - размер пакета без заголовка, называемый так же "квиком"), а то и больше. Некоторые отчаянные головы пробуют даже большие значения и утверждают, что все работает "на ура!", но у меня такие значения не показывают чудес производительности, поэтому подтвердить сказанное я не берусь. Размер заголовка непостоянен и варьируется от 40 до 60 байт - не забывайте об этом при поиске оптимальной ширины окна! Для изменения размеров окна откройте ветвь реестра HKEY_LOCAL_MACHINE-\System\ CurrentControlSet\Services\ VxD\-MSTCP для Windows 95/98 и HKEY_LO-CAL_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, но рассказывать о каждом из них
было бы слишком утомительно, да и нецелесообразно - для этого пришлось бы
написать отдельную книгу…