Укрощение Интренет@

Например, путь компьютер клиента пытается передать пакет размером в 576 байт, но один из маршрутизаторов в цепочке «умеет считать» только до 512, и разрезает пакет на два, причем во второй попадает «хвостик» из 64 байт, плюс… заголовок, занимающий от 40 и более байт. В итоге – КПД второго пакета составит всего лишь 50%, что очень нехорошо!

Если Windows видит, что избежать фрагментации не удастся, она уменьшает размер пакета так, чтобы он без проблем прошел сквозь все маршрутизаторы одним куском. Но не проще было бы сразу задать минимальный размер? Нет, и вот почему – чем меньше пакет, тем выше накладные расходы на его пересылку (заголовок тоже ведь занимает место) и тем больше пакетов требуется переслать для передачи того же объема информации.

Умение Windows подбирать максимальный размер не фрагментируемого пакета всем хорошо, да вот беда – не всегда это работает. Некоторые, не слишком демократичные маршрутизаторы, получив слишком длинный (по их мнению) пакет с пометкой «не фрагментировать», прибивают его на месте безо всяких уведомлений! Windows же, не подозревая, что посланный ею пакет погиб, ждет отклика от сервера. Долго ждет… А затем, там и не дождавшись, вновь посылает тот же самый пакет. И все повторяется! Вот этот-то недемократичный маршрутизатор и называется «Черной дырой»!

Включение опции «Black Hole Detect» активирует хитроумный алгоритм распознания «Черных Дыр» для обхода их стороной. Но за все приходится платить, и такое детектирование несколько снижает общую производительность. Несильно – но все ж таки! Поэтому прибегать к нему следует только в крайних случаях – когда действительно что-то не работает – соединение есть, а трансфер (передача данных) на нуле.

Запустите «Редактор Реестра» и откройте ветвь 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″ и перезагрузитесь.

Что? Все равно не работает? Хм… Боги, боги, зачем вы так несправедливы?! Ничего не остается, как расстаться с надеждой пересылки пакетов максимального размера и перейти на размер, обязательный (ну, формально обязательный) для всех маршрутизаторов – 576 байт. Для этого в той же самой ветке реестра найдите (создайте) двоичный параметр PMTUDiscovery для Windows 95\98, а для Windows NT\2000 – EnablePMTUDiscovery и присвойте ему значение «0″. Перезагрузитесь. Должно же это, наконец, заработать!

Кстати, с типом двух этих ключей творится что-то непонятное. Документация от Microsoft утверждает, что он (тип в смысле) должен представлять собой двойное слово, то бишь, по-английски DWORD. Однако у автора под Windows 2000 закачка по ftp начинает работать только после создания указанных ключей типа одиночного слова (WORD), а DWORD-ключи операционная система упорно игнорирует. Мистика какая-то…

Теперь поговорим об оптимизации соединения. Оптимизация – дело непростое. Это не то, что работает система или нет. Работать-то она работает, вот только как? Тривиальным измерением скорости скачиваемого файла ничего выяснить не удастся. График скорости только в исключительных случаях (и на хороших каналах) представляется прямой линией. Гораздо чаще он напоминает трассу Урюпинск – Ханты-Мансийск: сплошные бугры, колдобины, ямы, словом, крайне испещренная местность. Говорить о средней скорости можно только в переносном смысле, тем паче, что она может сильно варьироваться в зависимости от времени суток, сервера, с которым установлено соединение, количества осадков, выпавших в Африке, да мало ли еще от чего!

До начала экспериментов потребуется собрать статистику работы сети за некоторое время, скажем за неделю. В этом поможет программа Net Medic (www.download.ru) или любая другая, аналогичная ей. Затем, после внесения изменений в настройки системы, собирается другая статистика, опять-таки на протяжении семи — десяти дней, и сравнивается с предыдущей – изменилось ли что и если да, то в какую сторону?

Дело это, конечно, медленное, но иного способа тонкой настройки нет. Необходимо убедиться в увеличении скорости обмена со всеми серверами и во все времена суток, то есть, найти компромиссный оптимум.

Страниц: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142