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

В подавляющем большинстве случаев взводить его не следует. Если на компьютере установлен только один адаптер – Dial-Up- драйвер («Контроллер удаленного доступа» в русской версии Windows), распространить настройки на другие адаптеры невозможно ввиду отсутствия таковых. Если же компьютер снабжен одной или несколькими сетевыми картами, – настройка локальной сети по образу и подобию Интернет снизит ее производительность (стандартный размер TCP-пакета для Ethernet равен 1.500 байтам, против 576 для PPP).

Флажок «RWIN enabled by Basic and Optimum buttons», будучи взведенный, приводит к включению в базовый и оптимальный шаблоны возможности ручного задания размера TCP-окна. Поскольку, размер окна, принятый в системе по умолчанию, не всегда оказывается оптимальным и его коррекция способна увеличить скорость обмена данными до двухсот и более процентов, этот флажок имеет смысл взвести.

Внимание! Чтобы любые изменения настроек вступили в силу необходимо перед выходом из программы нажать кнопку «Update Registry», затем перезагрузиться и войти в сеть опять. Это относится в равной мере к параметрам, размещенным на закладках MTU и Registry, а так же ко всем трем шаблонам.

Рисунок 2 Рис 0х01B Назначение опций закладки Registry

Закладка Utilities и подбор оптимального MTU

Для ручного подбора значения MTU, недурно бы иметь какой-нибудь инструмент, позволяющий количественно оценить влияние размера пактов на производительность Интернет — соединения.

Один из таких инструментов – утилита ping из штатной поставки Windows, способная отправлять по указанному адресу пакет заданного размера с пометкой «Не фрагментировать». Если какой-нибудь из промежуточных серверов не в состоянии обрабатывать пакеты такого размера, он возвращает отправителю уведомление о невозможности доставки пакета и ping выдает на экран что-то вроде: «Требуется фрагментация пакета, но установлен запрещающий флаг». Остается опытным путем найти наибольший допустимый размер пакета…

Вовсе не обязательно уменьшать размер пакета каждый раз на единицу – MTU по обыкновению принимает одно из следующих фиксированных значений: 65.535, 32.000, 17.914, 8.166, 4.464, .4352, 2.048, 2.002, 1.536, 1.500, 1.492, 1.006, 576, 544, 512, 508, 296,68, – жирным шрифтом выделены наиболее распространенные значения в Интернет.

Так, тысяча байт – проходит! Полторы тысячи – проходит?! Две тысячи – как, опять, проходит??!! Разумеется, нет! На самом деле сервер кривого провайдера (и попадаются же такие – к примеру, тот же krintel) игнорируя флаг запрета фрагментации, втихую разрезает отправляемый пакет на столько частей, на сколько сочтет нужным. Как же в этом случае определить подходящее значение MTU, разумеется, не меняя провайдера?

Методика подбора оптимального размера пактов в этом случае будет следующей – связавшись с некоторым сервером, отправляем ему пакеты все большего и большего размера, замеряя среднее время их пересылки. До тех пор, пока пакет в процессе своего путешествия не фрагментируется, время доставки увеличивается прямо пропорционально размеру. Но, стоит только превысить некоторую критическую величину, как один пакет разрезается на два и время доставки скачкообразно возрастает (см. рис. 3), поскольку на транспортировку двух пакетов уходит больше времени, чем на транспортировку одного.

Величина, отмеченная на графике стрелкой MaxMTU, и есть оптимальный размер пакетов для данной цепочки пересылки. Не факт, что оптимальный размер пакетов для одного маршрута окажется столь же оптимальным для всех остальных – это зависит от того через какие промежуточные узлы проходит пакет. Если хотя бы один из них не поддерживает пакеты такого размера и разрезает их на два (а то и больше), скорость обмена данными существенно падает. Кроме того, маршрут путешествия пакетов даже к одному и тому же серверу зачастую непостоянен и выбирается динамически – порой два одновременно отправленных пакета доходят до цели назначения различными путями. Поэтому, подбор оптимального значения MaxMTU – очень непростое дело! Обязательно убедитесь, что выбранный размер пакетов удовлетворительно работает на всех основных маршрутах – т.е. остается оптимальным при соединении со всеми, или, по крайней мере, наиболее часто используемыми серверами.

К рисунку – график должен пересекать вертикальную ось не в нулевом значении, а несколько выше

Рисунок 3 Рис. 0x01D Определение максимального размера не фрагментируемого пакета по скорости его доставки

Разработчики утилиты MTUSpeed не предусмотрели никакой автоматической обработки полученных данных и все вычисления приходится выполнять вручную.

Страниц: 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