Выполняем следующее:
Пуск - Выполнить - вводите regedit
Жмёте enter
1 . Ищите:
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Servises \ Tcpip \ Parameters \ Interfaces \
Там будет несколько подпапок с именем по типу {7DBA6DCA-FFE8-4002-A28F-4D2B57AE8383}.
мотрите каждое, и ищите в каком стоит ваш интернетовский IP шник.
Правой кнопкой мыши и добавляете DWORD параметр с именем TcpAckFrequency, присваиваете значение 1 (хоть в 10ичной хоть в 16ичной системе)
Если что-то потом не понравится, то выставление значеня 2 вернёт настройку по умолчанию.
2 . Ищите HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSMQ \ Parameters
Правой кнопкой добавляем параметр DWORD c именем TCPNoDelay и ставим значение параметра 1
3. Перегружаем компьютер
Если начинаются страшные потери пакетов, то возвращайте настройки обратно.
Подобное шаманство будет интегрировано в новый патч.
Как это работает?
Значение TcpAckFrequency определяет частоту отправки TCP/IP подтверждающего сообщения.
Если значение равно 2, TCP/IP будет отправлять подтверждение после 2 принятых сегментов
Если после принятия 1 сегмента и отсутствия второго сегмента на протяжении 200 миллисекунд.
Если значение равно 3, TCP/IP отправляет подтверждение после приема 3 сегментов,
Ели после приема 1 или 2 сегментов и отсутствии последующих сегментов на протяжении 200 миллисекунд.
И так далее.
Если вам требуется сократить время ответа за счет удаления задержек отправки подтверждений TCP/IP, задайте это значение равным 1.
В таком случае TCP/IP будет немедленно отправлять подтверждение для каждого сегмента.
Если ваши соединения используются в основном для передачи крупных объемов данных и задержка в 200 миллисекунд несущественна,
Имеет смысл увеличить это значение для снижения дополнительной нагрузки отправки подтверждений.
Ну а если мелкие, такие как наши пакетики WoW то лучше поставить немедленное.
Параметр TCPNoDelay отключает алгоритм Nagl'e.
Из алгоритма следует, что в TCP соединении может присутствовать
Только один исходящий маленький сегмент, который еще не был подтвержден.
Следующие маленькие сегменты могут быть посланы только после того, как было получено подтверждение.
Вместо того чтобы отправляться последовательно, маленькие порции данных накапливаются
и отправляются одним TCP сегментом, когда прибывает подтверждение на первый пакет.
Красота этого алгоритма заключается в том, что он сам настраивает временные характеристики:
Чем быстрее придет подтверждение, тем быстрее будут отправлены данные.
На медленных глобальных сетях, где необходимо уменьшить количество маленьких пакетов, отправляется меньше сегментов.
Собственно отрубая данный алгоритм мы выигрываем в том что не тратим лишнее время на подтверждение целостности данных...
но и целостность наших данных, степень ошибок сразу встает вопросом.... глюки могут случаться чаще...
Так что используя данные настройки, мы уменьшаем реально нагрузку... увеличивая проходимость канала и следовательно "уменьшаем" задержку....
Однако при этом страдают такие вещи как скачивание файлов, службы торента, ДонЛоадер вова тоже будет дольше качать патчи....
Потом мы можем терять данные (протокло TCP теряет свое основное преимущество над UDP)
| 
