Оптимизация соединения с Интернет. Оптимизация интернет соединения


Ускорители Интернета - Простой Ключ

Throttle - утилита предназначенная для настройки параметров ваших модемов , в том числе, 3G-модемов, что сейчас особенно актуально, на максимальное быстродействие, что в результате может привести к более, чем 200 % увеличению скорости работы. 

 Вы выбираете свою операционную систему от Windows XP до Windows 7 

 тип интернет-соединения :

 14.4/28.8/33.6/56k кабельный модемDSL/ADSL модемISDN, Satellite T1/T3/OC3/OC12+Локальная сеть

Указываете слайдером - Speed - Fastest и нажимаете кнопку "Go" и перезагружаете компьютер.

Программа заносит необходимые предустановленные настройки в реестр , изменяющие и оптимизирующие параметры сетевого соединения (TCP, QoS, и другие) и после перезагрузки сетевое соединение улучшается

Как отмечают разработчики, программа изменит ряд ключевых параметров работы модема, например, улучшит определение сигнала "занято", уменьшит количество обрывов связи и т.д. 

Программа работает со всеми типами модемов подо всеми операционными системами семейства Windows.

Прирост скорости конечно же зависит от многих разных причин , например, если провайдер "режет" вам трафик, нереально большого прироста скорости не добьешься, тем не менее сетевое соединение станет не только стабильнее, но и заметно быстрее.

 

Официальный сайт 

Утилита платная

 

OnSpeed 9.0.0.383 FINAL 2010 RUS.

ONSPEED - это связующее звено между ПК и прокси-сервером разработчиков ONSPEED, на который переадресуется запрос на загрузку сайта из браузера.  

Сервер, пропуская через себя запрашиваемые данные, сжимает их в соответствии с настройками программы и передает их обратно утилите на Вашем компьютере, а та, в свою очередь, вашему браузеру. таким образом, браузер работает не с интернетом, а с сервером ONSPEED. 

По замыслу разработчиков, программа должна быть своеобразным архиватором сайтов, передавая браузеру не оригинальную страницу, а сжатую в несколько раз. 

Особенности программы: - использование уникальной технологии сжатия трафика; - оптимизация работы почтовых серверов; - интуитивно понятный интерфейс; - развернутая статистика работы программы; - экономия входящего и исходящего трафика. 

Год выпуска: 2010 Платформа: Windows 2000/XP/Vista/Win 7 Интерфейс: Русский 

Ускорение скорости интернета / Ashampoo Internet Accelerator 

Ashampoo Internet Accelerator - программа для автоматической оптимизации интернет-соединения и настроек вашего браузера. Используя Ashampoo Internet Accelerator вы сможете всего за один клик в автоматическом режиме оптимизировать производительностьвашего интернет-соединения и оптимизировать настройки браузеров Mozilla Firefox и Internet Explorer. Также в программе имеются различные инструменты для очистки истории посещения сайтов, кеша и кукисов, проверки и редактирования файла Hosts ( с возможностью замены текущего файла на оригинальный ), а также для онлайн - теста скорости текущего интернет-соединения. 

Вы сможете оптимизировать настройки для выбранного вами адаптера или для всех сразу. Кроме того имеется возможность ручной настройки значения MTU, RWIN, TTL и т.д.

Название: Ускорения скорости интернета / Ashampoo Internet Accelerator + ключГод выпуска: 2010Платформа: Windows XP, Vista,7Язык интерфейса: русский

 

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

Я использую соединение через модем Скайлинк и первые две недели после подключения качество и скорость сигнала меня вполне устраивала. Но после этого скорость и качество резко упали.

Я задался вопросом как увеличить скорость интернета.Этот вопрос я решил следующим образом.Для начала я увеличил скорость порта. Как я это сделал: заходим Пуск / Панель управления / Система, открываем вкладку Оборудование и жмем кнопку Диспетчер устройств. Находим опцию Порты (COM или LPT) далее жмем плюсик и после того как развернулось меню выбираем Последовательный порт (COM1). Щелкаем правой кнопкой мыши и выбираем Свойства. В открывшемся окне переходим на вкладку Параметры порта и в пункте скорость выбираем 115200,жмем ОК. Вот так мы увеличили скорость порта, обычно там стоит скорость 9600 бит/с.

Внимательно посмотрите, какой порт Вы используете для подключения Вашего модема.Где посмотреть? Панель управления / Телефон и модем, в окне переходим на вкладку Модемы, находите Ваш модем и напротив него должен быть написан порт, который использует модем. Если вы не знаете какой модем используется для подключения к сети? Для этого щелкнуть левой кнопкой мыши два раза на ярлыке Вашего подключения, который должен быть у вас на рабочем стол. Выбираем Свойства и переходим на вкладку Общие. В окне Подключатся через увидим, какой модем используется для подключения. Там же может быть написан порт, который используется для данного модема. Если у вас нет ярлыка подключения на рабочем столе – тогда сделайте вот так. В меню Пуск наведите стрелку мыши на опцию Подключения, у вас высветиться список ваших подключений, выбирайте свое подключение, кликаете и там нажимайте Свойства.

Далее настраиваем пропускную способность канала. Пуск / Выполнить, вводим в командную строку gpedit.msc и нажимаем ОК. Выбираем Конфигурация компьютера / Административные шаблоны / Сеть / Диспетчер пакетов QoS / Ограничить резервируемую пропускную способность. В открывшемся окне на вкладке Параметр ставим галочку Включен. В окне Ограничение пропускной способности (%) выставляем 0 (там по умолчанию должно стоять 20). После того как мы выставили 0 – нажимаем Применить, а потом жмем ОК.

                                                                       07.12.2010  Андрей Якутов

NetBalancer - Удобная программа для мониторинга сетевой активности и установки приоритетов скорости соединения той или иной программы с интернетом. Особенно будет полезна для не скоростных соединений. 

Часто бывает нужно отдать приоритет какому-то приложению, а во время его работы вдруг запускается автоматическое обновление программного обеспечения или антивирусных баз и наиболее важная в данный момент задача начинает "тормозить". NetBalancer раз и навсегда раздаст приоритеты сетевой активности, таким образом оптимизируя работу пользователя. С NetBalancer Вы можете:Выбрать для любого процесса загрузки и / или загрузить приоритет сети или предел Управление приоритетами и ограничения для каждого сетевого адаптера отдельно Определите подробные правила сетевого трафика Группа компьютеров локальной сети и сбалансировать их движение синхронизировано Установить глобальные ограничения трафика Показать сетевого трафика в системном трее и многое другоеРазмер: 2.1 Мб, Multi/RUS,

pro100key.jimdo.com

ВМ1-01: оптимизация соединения

Ресурс: "Компьютеры и оргтехника: Оптимизация модемного соединения"

Оптимизация соединения Windows XP - Освобождение канала (bandwidth), зарезервированного за сервисом QoS - Отключение заданий по расписанию (scheduled tasks)Оптимизация соединения Windows 98 и Millenium - MTU - Определение MTU вручную - Другие параметры

Оптимизация соединения Windows XP:

Освобождение канала (bandwidth), зарезервированного за сервисом QoS

Это такая хитрющая штука, о которой я бы вжись не догадался, если бы не прочитал на сайте улучшалок ХР. Как оказалось, Windows XP по умолчанию выделяет часть Интернет-канала для очень полезной штуки, которая называется Quality of Service (QoS). Назначение QoS - улучшать распределение трафика программ, написанных с учетом QoS API. Другое дело, что этих программ днем с огнем не сыскать (вернее, у меня лично они не стоят), поэтому резервирование канала под ненужный сервис - непозволительная роскошь. Вот что нужно проделать для того, чтобы освободить и без того узкий канал отечественного соединения с Интернетом:

В меню Start - Run запустите редактор групповых полисов: gpedit.msc. Имейте ввиду, что для выполнения всех этих процедур вам необходимо войти в систему как Администратор. В разделе Computer Configuration (в левом окне) выберите Administrative Templates. Далее Network и затем в правой панели выберите QoS Packet Scheduler и кликните на нем два раза. Выберите опцию limit reservable bandwidth и опять-таки кликните на ней два раза. В открывшемся окне включите Enabled, а затем укажите лимит канала в процентах равный нулю. ОК и выйдите из программы. Но это еще не все.

Отправляйтесь в сетевую конфигурацию (иконка Network Connections в Контрольной панели). Выделите свое соединение и из контекстного меню запустите Properties В закладке Networking убедитесь, что протокол QoS Packet Scheduler подключен (enabled). Если его там нет, то добавьте из списка (через кнопку Install). Перегрузите компьютер.

Все эти сложные пассы с насильственным включением сервиса и последующим выделением под него нулевого канала вызваны тем, что если просто отключить Quality of Service, то, как это часто бывает у наших антипятов, система все равно будет резервировать под него 20 % канала.

Отключение заданий по расписанию (scheduled tasks)

Всякий раз, как MSIE 6.0 соединяется с сервером, он тратит время на проверку наличия заданий по расписанию, связанных с данным адресом. Поскольку я никогда не пользовался и не планирую пользоваться функцией синхронизации Проводника, то я отключил планировщик заданий:

В реестре нужно удалить следующий ключ - HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Windows \ CurrentVersion \ explorer \ RemoteComputer \ NameSpace \ {D6277990-4C6A-11CF-8D87-00AA0060F5BF}.

Оптимизация соединения Windows 98 и Millenium:

Пока цивилизованный мир вовсю осваивает Интернет, используя широкополосный доступ посредством выделенных линий, всевозможных кабельных модемов, ISDN, ADSL и прочих недоступных нашему пользователю прибамбасов, мы с вами довольствуемся дешевой и доступной (пока не ввели повременку) модемной связью, не забывая периодически ругать ее за плохое качество и низкую скорость передачи данных.

Однако грамотным пользователям достаточно хорошо известно, что иногда удается заметно ускорить свою работу с Интернетом, если удачно настроить некоторые слабо документированные параметры операционной системы Windows 9x. То, что при настройке соединения с Интернет-провайдером надо первым же делом выставить параметры протокола TCP/IP, стало уже догмой и многие даже не задумываются, насколько общепринятые настройки подходят именно для их конкретного соединения.

Тем более что при этом совершенно не нужно обладать какими-то особыми знаниями - программ, предназначенных для автоматического внесения в реестр Windows всех необходимых изменений настолько много, что создается впечатление, будто все начинающие программисты набираются опыта именно на "ускорителях Интернета". А между тем, слепо изменяя установленные в Windows по умолчанию значения на среднестатистические, следуя советам, почерпнутым из порой сомнительных источников, вы можете с равной вероятностью как улучшить скорость прокачки файлов, так и ухудшить ее.

Tочно так же, оставив в покое настройки ОС, вы в ряде случаев будете зря терять время и деньги, не используя по максимуму свой Интернет-доступ. Что же это за таинственные параметры и каким образом следует выбирать наиболее оптимальные в каждом конкретном случае значения?

MTU

Первым делом, конечно же, надо разобраться с давно навязшим в зубах параметром MTU - Maximum Transmission Unit. В реестре он задается таким образом:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\Class\NetTrans\000х "MaxMTU"="1500"

Это максимальный размер пакета данных, который может быть передан за один физический кадр по протоколу TCP/IP. Дело в том, что данные от компьютера к компьютеру в Интернете идут не сплошным потоком, а этими самыми кадрами - пакетами строго определенного размера. Если бы все компании и фирмы, имеющие хоть какое-то отношение к Интернету, договорились о едином стандарте на размер этих пакетов, то мы бы использовали каждый такой кадр по максимуму, полностью заполняя каналы передачи данных своими битами.

Однако это не так. Мало того, что при установке нового соединения два удаленных компьютера должны согласовать между собой размер кадра, так еще и по пути к месту назначения пакет преодолевает целый ряд промежуточных серверов и маршрутизаторов, настройки MTU которых могут быть совершенно различными. При этом слишком большой пакет в пути, скорее всего, будет фрагментироваться и заполняться "воздухом", "балластом", что негативно скажется на эффективности связи.

Так, если ваш провайдер имеет установки MTU=576, а у вас в Windows задано MTU=1500, то каждый ваш пакет будет им разбиваться на три по 576 байт: 576+576+576=1728 - то есть 228 байт балласта будут добавляться к каждому вашему пакету. Но даже если провайдер тоже поставил у себя MTU=1500, то при связи с удаленным сервером вполне может попасться маршрутизатор с меньшим значением MTU и пакеты опять-таки будут фрагментироваться, замедляя передачу данных.

Несколько спасает ситуацию включенная в "виндах" по умолчанию функция автоматического определения MTU - "PMTU Discovery" или, как ее иногда называют, "MTU Auto Discovery", однако процедура вычисления MTU для каждого соединения требует немало времени, что чуть тормозит работу при прокачке небольших файлов и веб-серфинге. Да и в случае несогласования ваших параметров с параметрами провайдера эта функция вряд ли вам поможет. Конечно, существуют некие более или менее общепринятые стандарты для данного параметра: так, например, для Ethernet MTU равен 1500 байт, для SLIP - 1006, для PPPoE -1492, для PPP (то есть модемной связи с Интернетом) - 576.

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

Каждый такой пакет данных в действительности состоит из нескольких сегментов - нескольких заголовков и фактических данных. Та его часть, в которой содержатся только фактические данные, называется MSS (Maximum Segment Size) - это еще один параметр протокола TCP, определяющий самый большой сегмент данных TCP, которые могут быть переданы за один раз. То есть, MTU = MSS + заголовки TCP/IP. В реестре MSS задается так:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\VxD\MSTCP "DefaultMSS"="ваше число"

Для заголовка тоже имеется общепринятый размер - это 40 байт (20 байт IP и 20 байт TCP), следовательно, обычно MSS = MTU - 40. По этой причине в определении оптимального размера MTU есть некоторые тонкости.

Давайте изучим передачу данных при разном размере MTU по широкополосной линии T1 (пропускная способность - 1 544 000 бит/с), используя следующую формулу: [(MSS + заголовок) * 8 бит/байт] / [1 544 000 бит/с] = задержка на один хоп (то есть на каждый компьютер в Сети по пути нашего пакета). Используя в этой формуле разные величины MTU, мы можем вычислить задержку одного пакета. Если MTU=1500, тогда задержка = (1460 + 40) * 8 / 1 544 000 = 7,772 мс. Если же MTU=576, то задержка = (536 + 40) * 8 / 1 544 000 = 2,984 мс.

Предположим, что по пути пакета встречается 10 серверов, тогда при MTU=1500 получим задержку 77,72 мс, а при MTU=576 - 29,84 мс - разница весьма заметна.

Таким образом, очевидно, что меньшие пакеты будут переданы быстрее просто из-за ограничения производительности линии. Однако не все так просто. Используя ту же формулу, давайте посчитаем, за какой промежуток времени будет передан файл размером 1 Мбайт по той же широкополосной линии T1. Один мегабайт равен 1024 кбайт или 1 048 576 байт. Если MTU=1500, то, как мы выяснили, задержка на один хоп составит 7,772 мс.

Сколько при этом понадобится послать пакетов? 1 МБ / MSS = 1 048 576 / 1460 = 718,2, то есть всего требуется 719 эффективных пакетов, чтобы передать 1 мегабайт данных. Далее, умножаем 719 пакетов на 7,772 мс, получаем 5588,083 мс, или 5,588 секунд задержки на один хоп. Если же мы передаем свой файл через 10 хопов, что встречается чаще, чем один, то получаем 55,88 сек. - это время, которое мы (вернее, провайдер, имеющий линию T1) потратим на передачу файла в 1 МБ при идеальной связи. Если же MTU=576, то: 1 МБ / MSS = 1 048 576 / 536 = 1956,300, то есть при таком MTU нужно 1957 пакетов, чтобы передать 1 мегабайт.

Далее, умножаем количество пакетов на задержку каждого из них: 1957 * 2,984 = 5840,580 мс, или 5,841 секунды на один хоп. Ну и соответственно на 10 хопов придется 58,41 сек. Как видим, из-за того, что при использовании больших пакетов передается меньше заголовков, реальная скорость передачи файла получается выше.

Для того чтобы передать 1 мегабайт при использовании MTU = 1500 нужно переслать "довесок" заголовков из 28 760 байт, тогда как при использовании MTU=576 получаем аж 1957 * 40 = 78 280 байт, то есть дополнительные 49 520 байт заголовков на каждый мегабайт полезной информации. Для нашей 10-хоповой передачи это выливается в лишних 2,52 секунды при передаче каждого мегабайта даже при сверхбыстрой связи.

Эта разница, возможно, будет еще немного выше на практике, так как современные реализации TCP/IP стремятся использовать еще большие заголовки (например, дополнительные 12 байтов заголовка для отметок времени). Если же провести аналогичные расчеты для связи по модему на скорости 33 600 кбит/с, то получим, что на передачу мегабайта информации на расстояние одного хопа, то есть непосредственно вашему провайдеру, будет потрачено в идеале 256 секунд при MTU=1500 и 268 секунд при MTU=576.

Разница на одном переходе 12 секунд или около 4,5%! Но не следует забывать, что эти цифры получатся при условии отсутствия фрагментации пакетов, то есть если у вашего провайдера MTU=1500. Если же это не так, то, разумеется, больший, чем нужно, пакет будет фрагментироваться - разбиваться на несколько пакетов и даже разбавляться "воздухом", и связь ухудшится на 10-50%.

Таким образом, логично считать, что большие пакеты в итоге все-таки предпочтительнее, и если ваш провайдер настроил свои серверы и маршрутизаторы на большие пакеты, то надо стремиться использовать это на всю катушку, но не забывать и о том, что в Интернете встречаются серверы с MTU=576 (об этом чуть ниже мы еще поговорим). Тем не менее, если чистая производительность не является окончательной целью, то меньшие пакеты будут более "быстрыми", поскольку они требуют меньше времени для своих путешествий по Сети.

Этот эффект может перевешивать все другие достоинства больших пакетов в некоторых Интернет-приложениях и онлайновых играх за счет уменьшения времени отклика удаленного сервера при передаче небольших объемов информации.

В Интернете по пути следования ваших пакетов, вероятно, встретятся самые разные серверы с самыми разными настройками, но для начала все-таки желательно определить наилучшее значение MTU при связи только с вашим провайдером, поскольку именно оно может оказать решающее значение при оптимизации вашего доступа в Сеть.

В Windows 95 разработчиками по умолчанию было выбрано MTU=1500, что якобы не соответствует оптимальному для модемного соединения значению, которое всеми считается равным 576. В Windows 98 корпорация Microsoft уже исправила этот недостаток, и теперь по умолчанию при соединениях ниже 128 килобит в секунду мы имеем MTU=576, что вроде бы должно чаще оказываться наилучшим вариантом. Попробуем разобраться, так ли оно на самом деле.

Итак, есть несколько способов определить значение MTU, оптимальное для связи с вашим Интернет-провайдером. Послать письмо с вопросом в службу технической поддержки провайдера. Тут в принципе все понятно - если работники провайдера сами в курсе своих собственных настроек, то они дадут вам квалифицированный ответ, который, впрочем, не помешает все-таки и проверить самолично на практике. Подключиться к Интернету в терминальном режиме - иногда при осуществлении регистрации пользователя в одной из строк появляется рекомендуемое значение MTU. Для этого войдите в папку "Удаленный доступ", найдите там значок своего соединения и, щелкнув по нему правой кнопкой мыши, выберите пункт "Свойства". На странице "Общие" открывшегося меню жмите кнопку "Настроить" возле строки с названием вашего модема и в диалоге свойств модема переходите на вкладку "Дополнительно", где установите флажок "Выводить окно терминала после соединения". Теперь соединяйтесь с провайдером и при появлении окна терминала вводите вручную имя пользователя и пароль по соответствующим запросам. Если после этого вы увидите что-то типа "Entering PPP mode. Your IP address is ххх.ххх.ххх.ххх. MaxMTU is 1524", то вам повезло - вы получили MTU провайдера. Но и тут нелишним будет проверить это значение лично. И, наконец, ручное определение MTU.

Определение MTU вручную

Для адекватных результатов экспериментов обязательно необходимо выставить в операционной системе максимальный размер MTU=1500. Поэтому, если вы уже пытались изменять этот параметр с помощью какой-то программы или вручную в реестре, то обязательно отмените все внесенные изменения, вернув default-настройки.

В этом вам помогут утилиты Internet Tweak 2001 (http://www.magellass.com/), NetBoost 99 (http://www.download.ru/), iSpeed (http://www.hms.com/), MTUSpeed (http://www.mjs.u-net.com/), BlazeNET (http://www.indeavour.com/html_about_blazenet.htm) - выбирайте по вкусу. В реестре же вам придется проконтролировать это в разделе:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\Class\NetTrans\000х

Если найдете там параметр MaxMTU, то смело удаляйте его. Далее, открываем "Панель управления" (Control Panel) - "Сеть" (Network), выбираем "Контроллер удаленного доступа" (Dial-Up Adapter) и жмем кнопку "Свойства" (Properties). На вкладке "Дополнительно" (Advanced) появившегося меню устанавливаем большой размера IP-пакета ("IP Packet Size" - "Large"). Тем самым мы установили для нашего соединения MTU=1500. Перегружаем компьютер, чтобы изменения вступили в силу.

Теперь надо установить соединение с Интернетом и посмотреть, будут ли фрагментироваться пакеты различного размера. Для этого можно использовать и стандартную программу Ping из комплекта Windows, задавая ей такие параметры: ping -f -l 1500 ххх.ххх.ххх.ххх, где "ххх.ххх.ххх.ххх" - IP-адрес тестируемого сервера, а "-I" - это буква L, а не единица.

Но гораздо удобнее применять что-нибудь типа утилит CyberKit (http://www.cyberkit.net/ или IPTools (http://www.ks-soft.net/ip-tools.eng/index.htm) - в них есть приятный графический интерфейс вместо анахронизма командной строки Ping. Определяем сначала этой же многофункциональной программой IP-адрес одного из серверов вашего провайдера, тем самым мы избежим запросов к DNS-серверу во время тестирования.

Примените для этого вкладку "TraceRoute", введя в поле адреса URL провайдера. Теперь полученный IP вводим на странице "Ping", задаем для начала размер пакета 1500 и ставим флажок "Don't fragment" - "Не фрагментировать". В поле, где задается количество тестовых пакетов ставьте штук 5-6 - для того чтобы исключить случайные ошибки. Кстати, тест лучше проводить глубокой ночью, когда на линиях сидит мало народа и помех в телефонных сетях минимум.

Если никакого ответа не получено и наш пакет потерян, так как фрагментировать мы его запретили, а его размер слишком велик для настроек оборудования провайдера, то начинаем постепенно уменьшать величину пакета до тех пор, пока не станем получать отклики от сервера со значением этого самого "пинга". Так, например, для провайдера CEA мы получим размер неделимого пакета в 1472 байта. Означает ли это, что он использует MTU=1472?

Нет, у него MTU=1500, просто Ping прибавляет к нашим данным заголовок, который по-разному учитывается удаленными серверами, например, CEA не принимает во внимание заголовок IP (20 байтов) и ICMP (8 байтов) при отчете о своем MTU. Если же вам не повезло, и ваш провайдер выбрал меньшее значение, то ищите его среди таких чаще всего попадающихся цифр (также не забывая и о заголовке пакета): 1524, 1152, 1024, 1006, 576, 568, 560, 552, 548, 536, 528, 520, 512.

Таким образом, мы выяснили, что можно выбирать любой MTU, вплоть до 1500. Попробуйте теперь осуществить загрузку одного и того же ZIP-файла размером 1 мегабайт с одного и того же быстрого сервера при разных значениях MTU - максимальном, полученном от провайдера, и рекомендуемом 576. Для чистоты эксперимента отключите автоопределение MTU - параметр PMTU Discovery (о том, как его найти в реестре, читайте в конце статьи).

Скорее всего, вы обнаружите, что наши расчеты, говорящие о предпочтительности больших пакетов, справедливы. Проведите и такой эксперимент: "пингуйте" наибольшим нефрагментируемым пакетом (в нашем случае это 1472, то бишь MTU=1500) сайты, занесенные в список закладок. Вас ждет удивительное открытие - оказывается, большинство сайтов прекрасно воспринимают MTU=1500 и все пакеты до них доходят нефрагментированными.

Где же тот самый MTU=576, который якобы преобладает в Интернете? Проверьте также и свою любимую сетевую игру при разных MTU. Исходя из полученных данных, а не из того, что вам советуют всевозможные "эксперты", сами никогда не проделывавшие подобных опытов, а повторяющие только то, что принято за истину на загнивающем Западе, вы уже гораздо более объективно определите, какое же значение наилучшим образом согласуется с вашим Интернет-доступом - наибольшее или меньшее.

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

Можно, конечно, перестраховаться и выбрать самый минимальный размер MTU, при котором пакеты наверняка не будут фрагментироваться, но это может сказаться на быстродействии вашей системы еще более пагубно, чем использование больших пакетов. На самом же деле, главное - чтобы ваш MTU не превосходил MTU провайдера, при включенной же функции PMTU система сама найдет для ваших пакетов такой путь в Сети, при котором они не будут фрагментироваться.

Кстати, если вы обнаружите, что у провайдера установлено MTU=512 и менее, то есть смысл подумать о его смене - слишком много шлака будет передаваться вместе с вашими данными.

Другие параметры

Не только от одного MTU зависит качество вашей работы в Интернете, существует немало и других параметров протокола TCP, с которыми стоит поэкспериментировать. Конечно, есть уже некоторые готовые рекомендации и в этом случае, но, бездумно им доверяя, вы имеете шанс получить совсем не тот результат, к которому стремитесь.

Поэтому и тут крайне желательно для каждого параметра провести свой эксперимент, определяя, какой эффект вызывает его изменение в вашей конкретной системе. Многие из этих параметров легко выставляются с помощью все тех же незамысловатых утилит, что и MTU.

RWIN (receive window, окно приема) - размер буфера, в котором накапливается содержимое области данных (MSS) нескольких полученных пакетов, прежде чем передается дальше, например, в браузер. При недостаточном размере этого буфера иногда происходит его переполнение и поступающие пакеты отвергаются и теряются.

Размер RWIN обязательно должен быть кратен MSS и обычно для лучшей эффективности модемного соединения кратность рекомендуется устанавливать равной 4-8. Однако чрезмерно большой размер буфера также нежелателен, особенно на плохих линиях - при потере всего одного пакета в случае сбоя на линии будет повторно затребован не один потерянный пакет, а все пакеты из этого буфера, что займет некоторое время.

В реестре этот параметр находится здесь:

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\VxD\MSTCP "DefaultRcvWindow"="ваше значение"

TTL (time to live, время жизни) - количество хопов, то есть промежуточных серверов, через которые может пройти ваш пакет в поисках своего места назначения. Каждый такой сервер добавляет единицу к специальному счетчику в заголовке вашего пакета, и, когда счетчик достигает максимально разрешенного значения, пакет считается заблудившимся и прекращает свое существование. По умолчанию TTL равен 32, что сегодня явно недостаточно для разросшегося Интернета: нередки случаи, когда удаленный сервер находится более чем в 32 переходах, поэтому TTL следует увеличить как минимум до 64:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP "DefaultTTL"="64"

IPMTU - Internet Protocol MTU - в Windows 98, по сути, это то же самое, что и MTU, но применительно только к контроллеру удаленного доступа. В реестре он упоминается несколько раз:

HKEY_LOCAL_MACHINE\System\CurrentControlSet \Services\Class\Net\000х "IPMTU"="1500"

HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\Class\Net\000х\Ndi\params\IPMTU "default"="1500" @="1500"

PMTU (Path MTU, путевое значение MTU) - этот параметр разрешает Windows самой определять оптимальное значение MTU при организации соединения с каждым сервером. При этом серверу посылается ряд нефрагментируемых пакетов разного, постепенно уменьшающегося размера и как только очередной пакет достигнет сервера, его размер и считается оптимальным. На эту процедуру, разумеется, требуется некоторое время и по умолчанию она включена, в связи с чем часто советуют ее дезактивировать, что, пожалуй, все-таки довольно спорно - потерять на этом времени можно больше из-за того, что наилучший размер блока данных определен не будет и пакеты пойдут фрагментированными.

Выключается же этот режим так:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP "PMTUDiscovery"="0"

PMTUBlackHole Detect (обнаружение "черных дыр") - установка этого параметра разрешает протоколу TCP пытаться обнаружить никуда не ведущие роутеры и те, что не возвращают ICMP-сообщений о необходимости фрагментации при определении наилучшего MTU. Это также, как и любая дополнительная процедура, может замедлять работу в Интернете - попробуйте поэкспериментировать с ее отключением:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP "PMTUBlackHoleDetect"="0"

SessionKeepAlive (поддержание соединения) - определяет, как часто будут посылаться специальные пакеты информации, предотвращающие отключение вас сервером в случае отсутствия активности в Сети с вашей стороны. Минимум - одна минута, по умолчанию - один час в Windows Me / 9x и два часа в Windows 2000. Рекомендуемый интервал - 10 минут, параметр задается в секундах:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP "SessionKeepAlive"="600"

SlowNet - отключение этой функции может сократить задержки в передаче данных, но сей эффект уловить не так-то просто.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ Class\Net\000х "SLOWNET"=hex:00

NDI Cache (Network Device Interface Cache) - кэш, в котором хранятся данные о маршрутах движения пакетов, по умолчанию его размер равен нулю. Чтобы его задействовать наиболее оптимально, необходимо установить его размер равным 16 при модемном соединении или 32 при более скоростных подключениях:

HKEY_LOCAL_MACHINE\System\CurrentControlSet \Services\VxD\NWLink\Ndi\params\cachesize @="16"

В реестре обычно рекомендуется выставить еще некоторые параметры, влияние которых на качество связи проследить вообще чрезвычайно сложно, но попробовать поэкспериментировать с их значениями можно:

HKEY_LOCAL_MACHINE\System\CurrentControl Set\Services\VxD\NWLink\Ndi\params\maxconnect @="64" "max"="128" "min"="2"

HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\VxD\NWLink\Ndi\params\maxsockets @="255" "max"="1020" "min"="32"

HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\VxD\NETBEUI\Ndi\params\ncbs "default"="32" "max"="255" "min"="8"

HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\VxD\NETBEUI\Ndi\params\sessions "default"="32" "max"="117" "min"="4"

А нижеследующие параметры устраняют, по заверениям Microsoft, какие-то "глюки" Windows и увеличивают скорость работы вашего браузера:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\VxD\MSTCP "BSDUrgent"="1" "Tcp1323Opts"=dword:00000003 "SackOpts"="1"

А вот так вы увеличите количество одновременных подключений к серверу, что часто бывает весьма полезно:

[HKEY_USERS\.DEFAULT\Software\Microsoft\ Windows\CurrentVersion\Internet Settings] "MaxConnectionsPer1_0Server"=dword:0000000a =10 "MaxConnectionsPerServer"=dword:00000008 =8

Процедура оптимизации Интернет-соединения - дело весьма хлопотное и неоднозначное. Несмотря на то, что программ, предназначенных якобы для двукратного улучшения связи одним кликом мыши, - пруд пруди. И тут, как мы выяснили, совсем не факт, что MTU=576, которое везде рекомендуется западными программистами и экспертами, будет оптимальным и для нас в России. Наши провайдеры сплошь и рядом выбирают для себя MTU=1500, а при "пинговании" удаленных серверов мы обнаруживаем, что пакет такого размера, вопреки всем утверждениям, проходит чаще всего нефрагментированным. При этом, как видно из наших вычислений, чем больше MTU, тем эффективнее используется ваш Интернет-доступ.

Возможно, наши рассуждения несколько спорны и противоречат общепринятым догмам на этот счет, поэтому, для того чтобы настроить вашу систему на максимальную производительность, вам придется лично: во-первых, выяснить действительное значение MTU своего провайдера; во-вторых - выбрав это значение, убедиться, что пакеты такого размера при связи с чаще всего вами посещаемыми серверами не будут фрагментироваться; в-третьих - провести эксперименты с закачкой одного и того же файла при разных значениях MTU; и в-четвертых - проверить, как сказывается изменение MTU на сетевых играх, если вас они, конечно, интересуют. Исходя их итогов этих опытов и стоит решать, какой размер максимального неделимого пакета вам следует в результате выбрать.

То, что везде рекомендуется, для вас может оказаться наихудшим вариантом. Аналогично наберитесь терпения и проверьте влияние и других параметров на быстродействие системы - я упомянул далеко не все, над чем можно поизвращаться. При этом можно даже проверять MTU провайдера регулярно - раз в месяц, в два - не изменилось ли оно, но это уже для маньяков, хоть и не представляет никакой сложности, как мы с вами убедились выше.

"Компьютеры и оргтехника: Оптимизация модемного соединения"

vm1-01.narod.ru

Оптимизация соединения с Интернет

Оптимизация соединения с Интернет

Крис Касперски

Повременная оплата соединения с Интернет горячо любима всеми нерадивыми провайдерами, кривые руки которых не могут как следует отстроить свое хозяйство и обеспечить надлежащую скорость обмена. Клиент получает меньшее количество информации за то же время и, в результате, дольше торчит в Сети. А время – деньги. В самом, что ни на есть, прямом смысле этого слова. Вот если бы оплата шла за каждый скаченный мегабайт… будьте cпокойны – все бы летало как реактивный бомбардировщик с ракетой класса "Буш – Саддам Хусейн", но многие ли провайдеры поддерживают такой тарифный план?

Ладно бы, все злоключения ограничивались одной скоростью (в смысле полным отсутствуем таковой). Так нет же – соединение может быть нестабильным, часто обрываться, а то и не работать совсем – некоторые сайты могут не грузиться, ругаясь на загадочную ошибку "TTL Bug", закачка по ftp может вообще не "фэтэпить"… да разве ж перечислишь все злоключения, терзающие интернетчика!

Конечно, радикальнее всего – сменить провайдера, но это не всегда возможно. В больших городах счет провайдеров идет на десятки, а в провинциях он, монополист окаянный, нередко бывает в единичном экземпляре, что вдвойне хуже: монополисту незачем заботиться о своих клиентах – все равно они никуда не убегут, каким бы скверным качество обслуживания ни было. Да и куда бежать-то?

Впрочем, в клинических случаях стоит задуматься о поиске провайдера в соседнем городе. Как ни парадоксально, но даже с учетом междугородней оплаты за телефон, иногда это выходит в несколько раз дешевле. Правда-правда! Именно так и приходится поступать автору этой статьи.

Менее радикальная мера – настроить параметры TCP/IP-соединения на максимальную производительность, что дает прирост скорости обмена от 30% до 200% и избавляет от большей части разрывов. Остаются лишь фатальные сбои и зависания самого провайдера, побороть которые с клиентской стороны принципиально невозможно.

Существует множество программ, например, MTUSpeed, как раз и предназначенных для этой цели. Одна беда – ни одна из них не работает в полностью автоматическом режиме – все они всего лишь оболочки над системным реестром 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". Попробуйте установить соединение с каким-нибудь сервером, – теперь все должно заработать.

Работает? Вот и славненько! Однако восстановить соединение без реконнекта – это только полдела. Хорошо бы устранить и причину этих разрывов – ведь не все же сервера поддерживают докачку, а частые разрывы создают большие проблемы.

В идеальном случае следовало бы взять провайдера за ухо и с помощь дяди прокурора ткнуть носом в DCHP-сервер, объясняя ему, что клиент не должен оплачивать некомпетентность инженерного персонала поставщика сетевых услуг за свой счет. Да только в нашей стране такой прием вряд ли возымеет действие… Приходится выкручиваться самостоятельно, но на клиентской стороне очень мало, что можно сделать, да и то, только программистам. Единственное доступное "простым смертным" решение – перейти на Windows 2000 – с этой проблемой она справляется на раз!

Второй по счету источник неприятностей – эта пресловутая ошибка "TTL bug", приводящая к невозможности установки соединения. Дело в том, что во избежание засорения сети "Летучими Голландцами", то есть, попросту говоря, зацикленными пакетами, каждый из них имеет ограниченный срок существования, указанный в заголовке и измеряемый количеством промежуточных узлов, которые может посетить пакет. Если пакет не будет доставлен за это время, он "прибивается" очередным маршрутизатором c посылкой отправителю соответствующего "похоронного" уведомления.

Чем больше транзитных узлов расположено между отправителем и получателем, тем дольше пакеты добираются из одного конца в другой. К счастью, время жизни пакета (аббревиатура TTL так и расшифровывается Time To Live – время жизни) очень легко изменить: запустите Редактор Реестра, предварительно зарезервировав сам реестр, и откройте ветвь HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ DefaultTTL для ОС Windows NT\2000 и HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ VxD \ MSTCP \ DefaultTTL для Windows 9x, – она-то и управляет сроком жизни пакетов. По умолчанию он равен 32 узлам, но, как показывает практика, в некоторых случаях этого явно недостаточно и стоит увеличить его, по крайней мере, вдвое. (Можно и больше – но от этого лучше не станет, хотя и хуже – тоже). После внесения изменений в реестр следует перезагрузиться, заново войти в сеть и проверить, возымело ли это какое-то действие.

Возымело? Так... Cоединение с ftp-сервером установить удается, но вот закачка не работает, хоть убей: сколько ни жди, а индикатор прогресса издевательски остается на нуле процентов. Абыдно, понимашь! Что ж, будем лечить! Попробуйте для начала включить опцию с интригующим названием Распознавание Черной Дыры – "Black Hole Detect".

Зачем она нужна? А вот зачем – хитрая Windows, стремясь увеличить скорость передачи данных, пытается вычислить максимальный размер пакета, который бы обрабатывался пересылающими его маршрутизаторами без разрезания. Разрезание (или, говоря профессиональным языком, фрагментация) ощутимо снижает скорость соединения, особенно если пакет дробится на две неравные половины. Например, пусть компьютер клиента пытается передать пакет размером в 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 (http://download.ru/) или любая другая, аналогичная ей. Затем, после внесения изменений в настройки системы, собирается другая статистика, опять-таки на протяжении семи-десяти дней, и сравнивается с предыдущей: изменилось ли что и если да, то в какую сторону?

Дело это, конечно, медленное, но иного способа тонкой настройки нет. Необходимо убедиться в увеличении скорости обмена со всеми серверами и во все времена суток, то есть, найти компромиссный оптимум. Не все, что хорошо для одного случая, так же хорошо подходит для другого. Взять ту же фрагментацию уже рассмотренную выше. Автоматическое определение подходящего размера пакета не всегда увеличивает скорость соединения, нередко оно ее уменьшает, подчас весьма значительно, – автоматическое определение занимает какое-то время, увеличивая накладные расходы и снижая КПД. Имеет смысл попробовать найти оптимальное значение вручную.

Первым делом необходимо указать Windows, что требуется использовать не максимально возможный, а заранее оговоренный размер пакета. Для этого установите значение ключа PMTUDiscovery (EnablePMTUDiscovery) в ноль. Затем задайте желаемый размер пакета. По умолчанию он равен 576 байтам – это значение по стандарту должны поддерживать все маршрутизаторы, – да только кто эти стандарты соблюдает? Вот и встречаются узлы, обрабатывающие пакеты размером не более 512, 522, 556,… байт. В принципе, можно поставить 500 и не мучаться проблемой выбора, но так неинтересно. Разве не заманчиво методичным подбором байтов оптимизировать соединение до конца?

Размер пакетов для 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 \ Parameters \ Tcpip \ 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) и перезагрузитесь.

Оцените, как изменилась скорость соединения. Если она возросла, увеличьте ширину окна еще на один квик (не байт!), если уменьшилась, – сузьте окно, а если осталась без изменений, – расширьте окно на пару квиков. Так, в конце концов, будет найдено оптимальное значение. Интернет-гуру утверждают, что оптимум ширины окна зависит от загруженности провайдера и сильно колеблется в течение суток. При максимальной загруженности в "час пик" окно лучше прикрывать, оставляя лишь узкую щель (3х-4х), а ночью, когда все нормальные юзеры давно баиньки, и канал полностью свободен – широко распахивать обе створки (10x и выше). Никаких суточных вариаций у своих провайдеров автор не замечал, но готов поверить, что в некоторых случаях они могут иметь место, и гуру не врут.

Помимо вышеупомянутых опций реестр Windows содержит множество других значений, относящихся к TCP/IP, но рассказывать о каждом из них было бы слишком утомительно, да и нецелесообразно, – для этого пришлось бы написать отдельную книгу, страниц эдак на пятьсот.

doc4web.ru

Оптимизация соединения с Интернет

Крис Касперски

Повременная оплата соединения с Интернет горячо любима всеми нерадивыми провайдерами, кривые руки которых не могут как следует отстроить свое хозяйство и обеспечить надлежащую скорость обмена. Клиент получает меньшее количество информации за то же время и, в результате, дольше торчит в Сети. А время – деньги. В самом, что ни на есть, прямом смысле этого слова. Вот если бы оплата шла за каждый скаченный мегабайт… будьте cпокойны – все бы летало как реактивный бомбардировщик с ракетой класса "Буш – Саддам Хусейн", но многие ли провайдеры поддерживают такой тарифный план?

Ладно бы, все злоключения ограничивались одной скоростью (в смысле полным отсутствуем таковой). Так нет же – соединение может быть нестабильным, часто обрываться, а то и не работать совсем – некоторые сайты могут не грузиться, ругаясь на загадочную ошибку "TTL Bug", закачка по ftp может вообще не "фэтэпить"… да разве ж перечислишь все злоключения, терзающие интернетчика!

Конечно, радикальнее всего – сменить провайдера, но это не всегда возможно. В больших городах счет провайдеров идет на десятки, а в провинциях он, монополист окаянный, нередко бывает в единичном экземпляре, что вдвойне хуже: монополисту незачем заботиться о своих клиентах – все равно они никуда не убегут, каким бы скверным качество обслуживания ни было. Да и куда бежать-то?

Впрочем, в клинических случаях стоит задуматься о поиске провайдера в соседнем городе. Как ни парадоксально, но даже с учетом междугородней оплаты за телефон, иногда это выходит в несколько раз дешевле. Правда-правда! Именно так и приходится поступать автору этой статьи.

Менее радикальная мера – настроить параметры TCP/IP-соединения на максимальную производительность, что дает прирост скорости обмена от 30% до 200% и избавляет от большей части разрывов. Остаются лишь фатальные сбои и зависания самого провайдера, побороть которые с клиентской стороны принципиально невозможно.

Существует множество программ, например, MTUSpeed, как раз и предназначенных для этой цели. Одна беда – ни одна из них не работает в полностью автоматическом режиме – все они всего лишь оболочки над системным реестром Windows – так сказать, комфортный инструмент внесения в него изменений. Но легко сказать "вносить"! А как? Множество малопонятных и ничего не говорящих параметров, порой, вообще без каких либо пояснений. Попытки же разобраться во всем "методом тыка" скорее еще больше снизят скорость, чем ее увеличат. Тут без хорошего руководства не обойтись!

Первое, чем мы займемся – попытаемся устранить разрывы TCP-соединений (не путать с разрывами модемных соединений!). Они довольно многочисленны и разнообразны, а причиной их возникновения может быть и провайдер, и один из маршрутизаторов в длинной цепочке передачи пакетов, и сам удаленный сервер, с которым, собственно, и установлено соединение, и… да мало ли еще что!

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

Причина их возникновения, скорее всего, в том, что у провайдера неправильно настроен DHCP-сервер. Тот самый, что выдает пользователям IP-адреса. Как и любой собственник, он выдает их не насовсем, а на некоторое, подчас весьма непродолжительное время. Если клиент (точнее его операционная система) по каким-то там причинам (сеть тормознула, крыша поехала, пакет кто-то прибил) не успеет продлить срок аренды, его IP-адрес будет безжалостно отнят. А когда же, наконец, клиент "проснется" и пошлет петицию DHCP-серверу, тот смилостивится и отпустит с барского плеча еще один IP-адрес, типа: на, пользуйся на здоровье! И вроде бы все ничего, да вот не понимает "народная" Windows 9598 таких извращений! Она ожидает получения 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". Попробуйте установить соединение с каким-нибудь сервером, – теперь все должно заработать.

Работает? Вот и славненько! Однако восстановить соединение без реконнекта – это только полдела. Хорошо бы устранить и причину этих разрывов – ведь не все же сервера поддерживают докачку, а частые разрывы создают большие проблемы.

В идеальном случае следовало бы взять провайдера за ухо и с помощь дяди прокурора ткнуть носом в DCHP-сервер, объясняя ему, что клиент не должен оплачивать некомпетентность инженерного персонала поставщика сетевых услуг за свой счет. Да только в нашей стране такой прием вряд ли возымеет действие… Приходится выкручиваться самостоятельно, но на клиентской стороне очень мало, что можно сделать, да и то, только программистам. Единственное доступное "простым смертным" решение – перейти на Windows 2000 – с этой проблемой она справляется на раз!

Второй по счету источник неприятностей – эта пресловутая ошибка "TTL bug", приводящая к невозможности установки соединения. Дело в том, что во избежание засорения сети "Летучими Голландцами", то есть, попросту говоря, зацикленными пакетами, каждый из них имеет ограниченный срок существования, указанный в заголовке и измеряемый количеством промежуточных узлов, которые может посетить пакет. Если пакет не будет доставлен за это время, он "прибивается" очередным маршрутизатором c посылкой отправителю соответствующего "похоронного" уведомления.

Чем больше транзитных узлов расположено между отправителем и получателем, тем дольше пакеты добираются из одного конца в другой. К счастью, время жизни пакета (аббревиатура TTL так и расшифровывается Time To Live – время жизни) очень легко изменить: запустите Редактор Реестра, предварительно зарезервировав сам реестр, и откройте ветвь HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services Tcpip Parameters DefaultTTL для ОС Windows NT2000 и HKEY_LOCAL_MACHINE System CurrentControlSet Services VxD MSTCP DefaultTTL для Windows 9x, – она-то и управляет сроком жизни пакетов. По умолчанию он равен 32 узлам, но, как показывает практика, в некоторых случаях этого явно недостаточно и стоит увеличить его, по крайней мере, вдвое. (Можно и больше – но от этого лучше не станет, хотя и хуже – тоже). После внесения изменений в реестр следует перезагрузиться, заново войти в сеть и проверить, возымело ли это какое-то действие.

Возымело? Так... Cоединение с ftp-сервером установить удается, но вот закачка не работает, хоть убей: сколько ни жди, а индикатор прогресса издевательски остается на нуле процентов. Абыдно, понимашь! Что ж, будем лечить! Попробуйте для начала включить опцию с интригующим названием Распознавание Черной Дыры – "Black Hole Detect".

Зачем она нужна? А вот зачем – хитрая Windows, стремясь увеличить скорость передачи данных, пытается вычислить максимальный размер пакета, который бы обрабатывался пересылающими его маршрутизаторами без разрезания. Разрезание (или, говоря профессиональным языком, фрагментация) ощутимо снижает скорость соединения, особенно если пакет дробится на две неравные половины. Например, пусть компьютер клиента пытается передать пакет размером в 576 байт, но один из маршрутизаторов в цепочке "умеет считать" только до 512, и разрезает пакет на два, причем во второй попадает "хвостик" из 64 байт, плюс… заголовок, занимающий от 40 и более байт. В итоге – КПД второго пакета составит всего лишь 50%, что очень нехорошо!

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

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

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

Запустите "Редактор Реестра" и откройте ветвь HKEY_LOCAL_MACHINE System CurrentControlSet Services VxD MSTCP для Windows 9598 и HKEY_LOCAL_MACHINE System CurrentControlSet Services Tcpip Parameters для Windows NT2000. Найдите или при необходимости создайте двоичный параметр PMTUBlackHoleDetect для Windows 9598 и EnablePMTUBHDetect для Windows NT2000. Теперь присвойте ему значение "1" и перезагрузитесь.

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

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

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

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

Дело это, конечно, медленное, но иного способа тонкой настройки нет. Необходимо убедиться в увеличении скорости обмена со всеми серверами и во все времена суток, то есть, найти компромиссный оптимум. Не все, что хорошо для одного случая, так же хорошо подходит для другого. Взять ту же фрагментацию уже рассмотренную выше. Автоматическое определение подходящего размера пакета не всегда увеличивает скорость соединения, нередко оно ее уменьшает, подчас весьма значительно, – автоматическое определение занимает какое-то время, увеличивая накладные расходы и снижая КПД. Имеет смысл попробовать найти оптимальное значение вручную.

Первым делом необходимо указать Windows, что требуется использовать не максимально возможный, а заранее оговоренный размер пакета. Для этого установите значение ключа PMTUDiscovery (EnablePMTUDiscovery) в ноль. Затем задайте желаемый размер пакета. По умолчанию он равен 576 байтам – это значение по стандарту должны поддерживать все маршрутизаторы, – да только кто эти стандарты соблюдает? Вот и встречаются узлы, обрабатывающие пакеты размером не более 512, 522, 556,… байт. В принципе, можно поставить 500 и не мучаться проблемой выбора, но так неинтересно. Разве не заманчиво методичным подбором байтов оптимизировать соединение до конца?

Размер пакетов для Windows 9598 задается ключом MaxMTU, находящимся в той же самой ветке реестра, что и предыдущие ключи. С Windows NT2000 посложнее: чтобы выяснить местоположение ключа 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 Parameters Tcpip Interfaces ИдентификаторАдаптера)

Среди прочего хлама здесь должен находиться только что запомненный идентификатор адаптера, а в нем – ключ MTU, содержащий в себе максимальный размер пакета в байтах. Если такого ключа нет, его необходимо создать. Тип ключа MTU в обоих случаях соответствует двойному слову (DWORD).

Второй бастион оптимизации – размер TCP-окна. Чем "шире" окно, тем выше производительность, но, в то же время, больше издержки на повторные пересылки: случись какой сбой, – не до конца заполненное окно очистится и придется его "набивать" с самого начала. К тому же, баловство с неумеренно широкими окнами часто приводит к образованию заторов в сети: промежуточные узлы не успевают обрабатывать сыплющийся на них поток пакетов и начинают жутко тормозить. Причем, не только у виновника несчастья, но и у других ни в чем не повинных пользователей.

Ширина TCP-окна должна быть кратна размеру пакета за вычетом длины заголовка и превосходить его по крайне мере в четыре-шесть раз. В некоторых случаях наивысшая производительность достигается при ширине окна в 10х-12х (где х – размер пакета без заголовка, называемый так же "квиком"), а то и больше. Некоторые отчаянные головы пробуют даже бóльшие значения и утверждают, что все работает "на ура!", но у автора такие значения не показывают чудес производительности, поэтому подтвердить сказанное он не берется. Размер заголовка непостоянен и варьируется от 40 до 60 байт, – не забывайте об этом при поиске оптимальной ширины окна!

Для изменения размеров окна откройте ветвь реестра HKEY_LOCAL_MACHINE System CurrentControlSet Services VxD MSTCP для Windows 9598 и HKEY_LOCAL_MACHINE System CurrentControlSet Services Tcpip Parameters для Windows NT2000. Найдите или при необходимости создайте двоичный параметр (двойное слово, DWORD) DefaultRcvWindow для Windows 9598 и TcpWindowSize для Windows NT2000. Присвойте ему желаемое значение (например "3680", если размер пакета, заданный ключом MTU, равен 500 байт: (500 – 40) * 8 = 3/600) и перезагрузитесь.

Оцените, как изменилась скорость соединения. Если она возросла, увеличьте ширину окна еще на один квик (не байт!), если уменьшилась, – сузьте окно, а если осталась без изменений, – расширьте окно на пару квиков. Так, в конце концов, будет найдено оптимальное значение. Интернет-гуру утверждают, что оптимум ширины окна зависит от загруженности провайдера и сильно колеблется в течение суток. При максимальной загруженности в "час пик" окно лучше прикрывать, оставляя лишь узкую щель (3х-4х), а ночью, когда все нормальные юзеры давно баиньки, и канал полностью свободен – широко распахивать обе створки (10x и выше). Никаких суточных вариаций у своих провайдеров автор не замечал, но готов поверить, что в некоторых случаях они могут иметь место, и гуру не врут.

Помимо вышеупомянутых опций реестр Windows содержит множество других значений, относящихся к TCP/IP, но рассказывать о каждом из них было бы слишком утомительно, да и нецелесообразно, – для этого пришлось бы написать отдельную книгу, страниц эдак на пятьсот.

www.coolreferat.com

Оптимизаторы интернет соединения. Лучшие прогрммы

К превеликому сожалению не все провайдеры могут качественно настроить достойную скорость обмена данными поэтому пользователи вынуждены пользоваться оптимизаторами интернет соединений. Мы часами торчим в интернете стараясь вытянуть из него всю необходимую информацию. Наверное, если бы нам пришлось платить за каждый скачанный Мб, то скорость передачи была бы как у реактивного двигателя. Можно, конечно, сменить провайдера, однако не все пользователи интернет сети имеют такую возможность. Если в больших городах провайдеров десятки, то в провинциях, это обычно какой-нибудь наглый монополист, который не сильно заботится о качестве обслуживания. Как уже говорилось выше, скорость интернета чаще всего ограничивается пропускной способностью провайдера. Оптимизировать настройку соединения можно вручную, для этого нужно установить необходимые параметры в системном реестре. Наиболее оптимальным выходом является настройка TCP/IP-соединения на максимально возможную производительность, что может увеличить скорость на 30-200% и избавит от большинства разрывов соединения. Однако, для рядового пользователя это порой не под силу, да и времени требует немало. Выглядеть это бует примерно так: вы открываете системный реестр, меняете какой-то параметр, закрываете, соединяетесь с провайдером и проверяете качество связи, и так до тех пор, пока результат вас не удовлетворит. Поэтому лучше прибегнуть к помощи специальной утилиты. Такой оптимизатор интернет соединения самостоятельно выберет и установит необходимые значения параметров в протоколах TCP/IP. Самыми распространенными и оптимальными являются программы SpeedConnect Internet Accelerator и TweakMASTER. Их преимущество заключается в том, что они в автоматическом режиме настраивают параметры соединения. Это удобно для новичков и дает возможность профессиональным пользователям вручную ввести более тонкие настройки. Каждая из этих утилит имеет функцию тестирования скорости соединения с интернет, затем программа анализирует изменения и в случае необходимости вернется к предыдущим параметрам по умолчанию.

Рассмотрим эти утилиты оптимизаторы скорости интернет соединения более подробно

TweakMASTER Pro и SpeedConnect Internet Accelerator наверное, лучшее решение для оптимизации соединения с интернет. Утилиты поддерживает любое подключение к сети - dial-up, по xDSL-технологии, по сети кабельного телевидения и беспроводной радиодоступ. В программах имеется функция поддержки Traceroute и Ping, которые могут выявить причины проблем в работе интернета, существует связь с базой данных WhoIs, благодаря которой можно получить сведения об IP-адресе или домене и многие другие возможности. В утилиты включены модули DU Meter и LinkFox, первый учитывает интернет трафик и контролирует сетевую активность, а второй ускоряет веб-серфинг. Неплохо зарекомендовала себя программа TCP Optimizer. Эта утилита настраивает ваше интернет подключение (любым путем) на максимальную скорость. Прелесть этой программы в том, что она не требует установки.

www.stef33.ru

Оптимизация интернет-соединения - Оптимизация интернет - Каталог статей

Оптимизация интернет-соединения

Эти оптимизации предназначены для поднятия скорости медленного соединения, и если ваша скорость выхода в интернет от 1 Мбита, вам это вряд ли поможет (куда ещё :) ).

так же вы можете скачать программу и настроить все автоматически http://ferstaid.do.am/load/raznoe/systemmechanicpro/8-1-0-7 

Настройки

Первым делом жмём Win + Break, далее идём в Оборудование\ Диспетчер устройств. Теперь ищем в списке устройств свой модем, и заходим в его настройки. Скорость порта модема должна быть установлена на 115200 (или больше). 

В том же Диспетчере устройств идём в настройки COM-порта, на котором висит ваш модем, переходим на закладку Параметры порта и выставляем максимальную скорость. После чего нажимаете кнопку Дополнительно и в следующем окне увеличиваете по максимуму буфера.

Теперь настроим кэш вашего модема. В папке Windows есть файл system.ini, откройте его и впишите в раздел [386Enh] строку Com1Irq4Buffer=1024 если ваш модем стоит на COM1, и впишите Com2Irq3Buffer=1024, если на COM2. 

В Пуск\ Выполнить вводим gpedit.msc. В разделе Конфигурация компьютера выберите пункт Административные шаблоны, далее Сеть и затем в правой панели выберите «Диспетчер пакетов QoS» и кликните на нем два раза. Выберите опцию «Ограничить резервируемую пропускную способность» и опять-таки кликните на ней два раза. В открывшемся окне включите Enabled, а затем укажите лимит канала в процентах равный нулю, нажмите «ОК» и выйдите из программы. Или можно просто вырубить службу QoS

Программы

Существуют специальные программы для повышения скорости работы в интернете. Но не следует использовать сразу с десяток таких программ, я могу посоветовать две - AusLogics BoostSpeed и Throttle. Эти проги есть у меня на сайте. Используйте в таком порядке: сначала обработайте ваш комп Throttle-ом, затем с помощью BoostSpeed в режиме ручной оптимизации отключите RFC 1323 Settings и включите Selective Acknowlegement с Black Hole. Ну а потом доведите до окончательного вида вручную.

Реестр

Как работать с ним можно узнать здесь. Все основные настройки скорости доступа в сеть расположены по адресу HKEY_LOCAL_MASHINE\ SYSTEM\ CurrentControlSet\ Services\ Tcpip\ Parameters. Все изменения перечисленных параметров нужно призводить в десятичной системе, а не в шестнадцатеричной! Если какого параметра у вас не хватает, можно создать его самим как DWORD

DefaultTTL - время жизни пакета, ставим 256 - чисто на всякий случай )) 

GlobalMaxTcpWindowSize - максимальный размер пакета, ставим 32768 на диалапе 56k

MTU - размер принимаемого пакета MTU, на диалапе 56k оптимально - 1536 (можете попробовать значение 576) 

TcpWindowSize - размер Tcp пакета, ставим 16384 (можете попробовать значение 8192, но только не ставьте выше GlobalMaxTcpWindowSize), если у вас диалап 56k

Tcp1323Opts - 0 (выкл.)- совершенно ненужная функция - измеряет заранее время передачи каждого пакета, фтопку... 

  EnablePMTUDiscovery - 1(вкл.), EnablePMTUBHDetect - 1 (вкл.) - эти опции определяют фрагментацию пути и ищут "чёрные дыры", немного увеличивают скрорость 

KeepAliveInterval, KeepAliveTime - эти параметры определяют время, по истечении которого будут пересылаться keep-alive пакеты, никому не нужные, но отъедающие часть траффика. Поэтому ставим нули в обоих случаях, чтобы отключить эти параметры.

DeadGWDetectDefault - 0 (выкл.) - отключает предварительный поиск неработающих маршрутизаторов, который обычно замедляет интернет. 

 При заходе на любой сайт происходит "перевод" имени сайт в его IP адрес. Все это хранится в кеше DNS, то есть информация берется из кеша, а не происходит "перевод на лету". Вы можете увеличить размер кеша DNS, тем самым повысив скорость серфинга в сети. Для этого вы должны создать и запустить reg-файл, содержащий такой текст: Windows Registry Editor Version 5.00   [HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Services\ Dnscache\ Parameters] "CacheHashTableBucketSize"=dword:00000001 "CacheHashTableSize"=dword:00000180 "MaxCacheEntryTtlLimit"=dword:0000fa00 "MaxSOACacheEntryTtlLimit"=dword:0000012d   Кстати, кэш DNS периодески нужно очищать. Делается это так: Пуск\ Выолнить\ и вводите ipconfig /flushdns

 Медленная скорость при соединении бывает при большом кол-ве файлов в одной директории. Решается эта проблема так: Создаем reg-файл следующего содержания: Windows Registry Editor Version 5.00   [HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Services\ lanmanserver\ parameters] "SizReqBuf"=dword:0000ffff   Теперь запустите созданный файл.

Пользуйтесь лучшим браузером http://ferstaid.do.am/load/brauzery/opera_10_6_0/3-1-0-4

ferstaid.do.am

Программа для настройки и оптимизации интернета. Оптимизация интернет-соединения. Программы для ведения статистики подключения

В этой статье Вы узнаете:

Как увеличить скорость интернета с помощью программы TCP Optimizer?

Несомненно вопрос о восстановлении удаленных файлов затрагивает многих пользователей, но в этот раз давайте поговорим о «наболевшем», — о скорости интернета…

Хотите увеличить скорость интернета ? Желаете ли Вы быстро скачивать большие файлы, торренты, фильмы..? Большинство ответит конечно же да, тогда на сайте представляем Вашему вниманию — бесплатная программа для увеличения скорости интернета — TCP Optimizer, которая оптимизирует настройки связанных tcp и ip параметров ОС Windows, тем самым поднимая скорость сети интернет.

Вы также можете проверить, что это указывает на некоторые из ключевых моментов, которые имеют более быстрый характер. И, если ваша потребность в ускорении, это поможет вам. И вскоре после того, как программа будет указана выше. Нажмите стрелку на боковой стороне клавиши, чтобы открыть ее.

И все соответствующие записи появятся в правой части экрана. На этом этапе мы добавим новую запись, которая заставит ее расти. Для этого нам нужно знать, какая версия системы, будь то 32 или 64 бит. Откройте «Пуск» и щелкните правой кнопкой мыши значок «Мой компьютер» и выберите «Свойства».

TCP Optimizer — это своеобразный «регулятор» скорости соединения, после выбора которой программа ищет лучшие окна параметров tcp и произведёт оптимизацию на этом режиме.

Открываем Диспетчер задач , жмем Файл — Новая задача (Выполнить) или Пуск — Выполнить

После создания нового значения мы изменим ваши данные. Перезагрузите компьютер, чтобы приложения вступили в силу. Во время просмотра вы заметите разницу в увеличении загрузки страниц и видео. Итак, первый шаг - загрузить программу. Шаг 1 - создайте папку для размещения программы.

Коды ошибок удаленного доступа Windows

Шаг 3 - На этом экране вы можете увидеть, как настроено ваше соединение. Шаг 4 - Установить в следующем порядке. Шаг 5 - На этом экране вы даете краткое изложение того, что меняется. Компьютер должен быть перезагружен. Шаг 6 - снова откройте программу.

Далее как показано на скриншоте в Редакторе локальной групповой политике ищем в папке Планировщика пакетов Qos или Диспетчере пакетов Qos значение Ограничить резервную пропускную способность , как на картинке

Шаг 7 - Проверьте, что меняется. Только значения, установленные на шаге 6, должны быть изменены. Шаг 1 - откройте программу. Шаг 2 - щелкните меню «Файл». У вас есть два варианта для изменения изменений. Выберите нужный файл резервной копии и нажмите «Открыть». Шаг 4 - Проверьте, что меняется. Значения, которые будут отменены, имеют информацию «Удалить значение».

Измерение качества вашего беспроводного соединения

Сила сигнала представлена ​​зелеными полосками.

Как проверить настройки интернет-бокса
Статус: Включено Активация беспроводной точки доступа: включен

syq.ru


Prostoy-Site | Все права защищены © 2018 | Карта сайта