Основная идея заключается в том, что бы определить, какой максимальный размер tcp-пакета маршрутизатор провайдера может пропустить не фрагментируя его для дальнейшей передачи и установить своё значение MTU меньшим (в идеале равным) значению MTU маршрутизатора. В чем тут фишка. Дело в том, что возможно в силу каких-либо причин на маршрутизаторе установлен размер MTU меньше, чем типичный для ethernet, а у вас используется значение по умолчанию (1492). Если MTU маршрутизатора провайдера к примеру 576 (стандартное для ppp-соединений значение), а у вас 1492, и вы отправляеет в сеть пакет размером 1400 байт (к примеру), то до маршрутизатора он дайдет 1 пакетом, а дальше будет разбит на 3 (1400\576) и отправлен далее по маршруту, а там в свою очередь MTU может быть еще ниже и пакет опять будет разбит. А теперь представьте, что во время передачи между какими-либо маршрутизаторами один из этих фрагментов потерялся (потеря пакета) и соответствеено передача остальных двух смысла уже иметь не будет, вам сообщается, что при передаче произошла ошибка и нужно повторить. Т.е. терятся время и трафик. А если мы сделаем размер уходящего от нас пакета равным минимальному MTU на пути его следования, то и разбивать его маршрутизатору не придется, а значит и шанс на ошибку ниже и времени на достоверную передачу тоже нужно меньше -> мы выигрываем в скорости.
Приступаем:
1. "Пуск"\Выполнить: cmd
2. Пишем: ping -f -l 1492
www.tattelecom.ru
3. Смотрим результат, если видим:
"Требуется фрагментация пакета, но установлен запрещающий флаг"
то уменьшаем размер пакета с 1492 в меньшую сторону до тех пор пока не пойдут привычные ответы. Это и есть подходящее для вас значение MTU. Магическое число 1492 взято не с потолка, это величина получается если из максимального размера фрейма ethernet`a (1500) вычесть 8 байт отводимых под заголовок и получится 1492 байта для полезной нагрузки, а меньше оно может оказаться если по пути следования пакета встречаются не только ethernet каналы, но и каналы использущие другие протоколы канального уровня, где размер фрейма другой (меньше) или фрейм инкапсулируется.
4. Открываем ветку реестра:
Код:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}
Обнаруживаем там много включений вида 0000, 0001, 0002 и так далее. Просматриваем их все, пока не найдем ключ с описанием вашего сетевого адаптера (например у меня "Marvell Yukon 88E8056 PCI-E Gigabit Ethernet Controller") и смотрим значение параметра
NetCfgInstanceId
5. Перемещаемся в ветку:
Код:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
и находим там раздел с именем соответствующим
NetCfgInstanceId найденному ранее. Т.е. изменения
MTU каснутся только этого сетевого подключения.
6. Если есть параметр
MTU, меняем его на полученное вам в результате экспериментов в пункте 3. число (в десятичном виде), если же этого параметра нет - создайте его сами (тип DWORD).
7. Можно так же поправить значение
TcpWindowSize, этот параметр определяет максимальный размер окна приема протокола TCP, предлагаемый системой. Находится он должен в ветке:
Код:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
. (Если - создаем, тип DWORD). Его значение определяется исходя из следующих соображений. Величине MTU ставится в соответствие некоторое значение MSS (Maximum Segment Size, максимальный размер сегмента (размер данных, уложенных в MTU)). Величина MSS должна быть меньше MTU на 40 байт заголовка. MSS = MTU - 40. TcpWindowSize рекомендуется ставить мимимум в четыре раза больше величины MSS. TcpWindowSize = MSS * 4. (в моём случае MTU был равен 1464, значит TcpWindowSize должен быть (1462-40)*4 = 5688. Но имейте в виду, что это изменение каснется абсолютно всех подключений (сетевых, dial-up) по умолчанию величина TcpWindowSize 8760 (т.е. расчитан на 6 стандартных фреймов ethernet`а) и уменьшать его следует только в том случае, если канал очень не надежен и значение потерь пакетов до хотя бы до ближайшего маршрутизатора около 16%, что в условиях adsl крайне редко (а вот для dial-up`a очень даже часто). И уменьшенее даст более уверенную передачу. Уменьшать соответственно кратно величине TcpWindowSize. Если канал очень надежный, то казалось бы можно увеличить размер буфера, это можно сделать, но не стоит слишком увлекаться иначе можно только навредить. Величина вплоть до TcpWindowSize * 12 для хорошего канала вполне приемлема.
8. Можно перезагружаться.
ЗЫ Кстатит говоря, пытаться проверять действие этих манипуляций простыми пингами некорректно, так как размер пакета icmp-echo намного меньше MTU. Ощутить разницу можно если до и после изменения MTU замерить скорость скачивания с какого-нибудь ближайшего хоста. Особенно эффект виден на медленных линках (dial-up) но и на adsl тоже вполне ощутим