Привет уважаемые читатели блога. Оплата соединения с Интернет любима всеми провайдерами,
которые не могут обеспечить надлежащую скорость обмена. Если бы все злоключения ограничивались одной скоростью (или полным отсутствуем таковой). Так нет же – соединение может быть нестабильным, часто обрываться, а то и не работать совсем - некоторые сайты могут не грузиться, ругаясь на загадочную ошибку
"TTL Bug". Конечно, лучше всего – сменить провайдера, но это не всегда возможно.
Поэтому лучше уж самим настроить параметры TCP/IP - соединения на максимальную
производительность, что
дает прирост скорости обмена и избавляет от
большей части разрывов. Остаются лишь
фатальные сбои и зависания самого провайдера, побороть которые с клиентской стороны принципиально невозможно.
О параметрах конфигурации TCP/IP для Windows XP читайте далее
Первое с чего нужно начать это - попытаемся устранить
разрывы TCP - соединений
(
не путать с разрывами модемных соединений!). Они довольно многочисленны и разнообразны, а причиной их возникновения может быть и провайдер, и один из маршрутизаторов в длинной цепочке передачи пакетов, и сам удаленный сервер, с которым, собственно, и установлено соединение.
И начнем с провайдера -
модем не бросает трубку, но все установленные соединения
вдруг обрываются и после этого
ни к одному серверу подключиться не удается.
Положение спасает лишь реконнект – отключение от Интернет и повторный вход вновь.
Мало того, что это медленно, к тому же есть риск нарваться на глухую "стену", если
освободившийся телефонный номер мгновенно
займет другой клиент (
особенно если у провайдера острый недостаток входных номеров).
Такие разрывы могут происходить и
эпизодически, и по несколько
раз в час, а то и в минуту.
Причина их возникновения, скорее всего, в том, что у провайдера
неправильно настроен DHCP - сервер.
Тот самый, что выдает пользователям
IP - адреса, потому что он выдает их не насовсем, а
на некоторое время. Если
клиент (точнее операционная система)
по каким-то там причинам
не успеет продлить срок аренды,
его IP-адрес будет
отнят.
А когда же, наконец, клиент "проснется" и пошлет повторно запрос
DHCP - серверу, тот выдаст
еще один IP - адрес, и вроде бы все ничего, только вот не хочет понимать
Windows этого. Она ожидает получения
IP - адреса всего лишь один раз –
на стадии подключения к
провайдеру. Получить-то
IP - адрес Windows получает,
но вот включить его в таблицу маршрутизации "
забывает", и ни один отправляемый пакет не может уйти дальше своего компьютера. И тут уже надо самому исправлять положение.
Вначале необходимо в сеансе
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".
Попробуйте установить соединение с каким-нибудь сервером, – теперь все должно заработать.
Однако восстановить соединение без реконнекта - это только полдела.
Хорошо бы устранить и причину этих разрывов - ведь не все же сервера поддерживают
докачку, а частые разрывы создают большие проблемы.
Приходится выкручиваться самостоятельно, но на клиентской стороне очень мало, что можно
сделать, да и то, только если Вы не разработчик или программист..
Еще один неприятный момент это - ошибка "TTL bug", приводящая к
невозможности установки соединения. Дело в том, что во избежание засорения сети
"Летучими Голландцами", то есть, попросту говоря,
зацикленными пакетами, каждый из них имеет ограниченный срок существования, указанный в заголовке и измеряемый количеством промежуточных узлов, которые может посетить пакет. Если пакет не будет доставлен за это время, он "
прибивается" очередным маршрутизатором c посылкой отправителю соответствующего уведомления.
Чем больше транзитных узлов расположено
между отправителем и получателем, тем
дольше пакеты добираются из одного конца в другой. К счастью, время жизни пакета (аббревиатура TTL так и расшифровывается
Time To Live – время жизни) очень легко изменить: запустите
Редактор Реестра, (Пуск - Выполнить - regedit)
предварительно скопировав (сохранив) сам реестр, и откройте ветвь:
HKEY_LOCAL_MACHINE \ SYSTEM \CurrentControlSet \ Services \ Tcpip \ Parameters \ DefaultTTL -
для
ОС Windows NT\2000
и
HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ VxD \ MSTCP \ DefaultTTL для Windows 9x, – она-то и управляет сроком жизни пакетов. По умолчанию он равен
32 узлам(я поставил 64, как видите), но, как показывает практика, в некоторых случаях этого явно недостаточно и стоит увеличить его, по крайней мере
, вдвое. (Можно и больше – но от этого лучше не станет, хотя и хуже – тоже). После внесения изменений в реестр
следует перегрузиться, заново войти в сеть и проверить, возымело ли это какое-то действие.
Еще один момент это надо включить опцию с интригующим названием:
Распознавание Черной Дыры – "Black Hole Detect".
Для чего она нужна? А вот для чего – Windows, стремясь увеличить скорость передачи данных, пытается вычислить максимальный размер пакета, который бы обрабатывался пересылающими его маршрутизаторами без разрезания.
Разрезание (или, говоря профессиональным языком,
фрагментация) ощутимо снижает скорость соединения, особенно если пакет дробится
на две неравные половины.
Например, пусть компьютер клиента пытается передать пакет размером в
576 байт,
но один из маршрутизаторов в цепочке
"умеет считать" только до 512, и разрезает пакет на два, причем во второй попадает
"хвостик" из 64 байт, плюс заголовок,
занимающий от
40 и более байт. В итоге – КПД второго пакета составит всего лишь 50%, что очень нам не нужно
Какая у Вас скорость передачи данных читайте далее
Если Windows видит, что избежать фрагментации не удастся,
она уменьшает размер пакета так, чтобы он без проблем прошел сквозь все маршрутизаторы одним куском. Но не проще
было бы сразу задать минимальный размер? Нет, и вот почему: чем меньше пакет, тем выше накладные расходы на его пересылку (заголовок тоже ведь занимает место) и тем больше пакетов требуется переслать для передачи того же объема информации.
Умение
Windows подбирать максимальный размер
нефрагментируемого пакета всем хорошо известно, да только вот – не всегда это работает. Некоторые, не слишком демократичные маршрутизаторы,
получив слишком длинный (по их мнению) пакет с пометкой "не фрагментировать",
прибивают его на месте безо всяких уведомлений! Windows же, не подозревая, что посланный ею пакет погиб,
ждет отклика от сервера.
Долго ждет… А затем, так и не дождавшись, вновь посылает тот же самый пакет. И все повторяется!
Вот этот-то маршрутизатор и называется "Черной дырой".
Запустите "Редактор Реестра" и откройте ветвь
HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \Services \ VxD \ MSTCP для
Windows 95\98 и
HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \
Services \ Tcpip \ Parameters для Windows NT\2000.
Найдите или при необходимости создайте двоичный параметр:
PMTUBlackHoleDetect для
Windows 95\98 и
EnablePMTUBHDetect для
Windows NT\2000.
Теперь присвойте ему значение
"1" и перегрузитесь.
Теперь об оптимизации соединения.
Автоматическое определение подходящего размера пакета не всегда увеличивает скорость соединения
, нередко оно ее уменьшает, подчас весьма значительно, –автоматическое определение занимает какое-то время, увеличивая накладные расходы и
снижая КПД.
Имеет смысл попробовать найти оптимальное значение вручную.
Первым делом необходимо указать
Windows, что требуется использовать
не максимально возможный, а заранее оговоренный размер пакета.
Для этого установите значение ключа
PMTUDiscovery (EnablePMTUDiscovery)
в ноль.
Затем задайте желаемый размер пакета.
По умолчанию он равен
576 байтам – это значение по стандарту должны поддерживать все маршрутизаторы, – да только кто эти стандарты соблюдает? Вот и встречаются узлы, обрабатывающие пакеты размером
не более 512, 522, 556,… байт.
В принципе, можно поставить
500 и не мучатся с проблемой выбора, но разве не интересно самому подбором байтов оптимизировать соединение до конца?
От чего зависит скорость TCP/IP-соединений читайте далее
Размер пакетов для
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 \ Tcpip \ Parameters \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) и
перегрузитесь.
Посмотрите, как изменилась скорость соединения.
Если она возросла, увеличьте ширину окна еще на один
квик (
не байт!),
если уменьшилась, – сузьте окно, а если осталась без изменений, – расширьте окно на
пару квиков. Так, в конце концов, будет найдено оптимальное значение. Многие знатоки утверждают, что оптимальное значение ширины окна
зависит от загруженности провайдера и сильно колеблется в течение суток.
Как снять ограничение TCP/IP соединений читайте здесь
Помимо вышеупомянутых опций реестр Windows содержит множество других значений, относящихся к TCP/IP, но обо всем рассказать в одной статье нереально.
Дальше будем эту тему тему расширять и обновлять.
