Windows scaling heuristics что это

Привет.

Сетевая подсистема в Windows NT прошла достаточно длительный путь – изначально являясь сетевой операционной системой, NT сразу ставила задачу предоставлять надежные, сбалансированные и эффективные сетевые решения.

Беда в том, что с точки зрения большинства админов под “настройкой сетевых параметров” понимаются видные глазом базовые минимальные пункты – как задание IP-адреса, маски и шлюза, а даже тот факт, что IP-адресов на интерфейсе может быть несколько, уже вызывает удивление.

Фактически же количество сетевых настроек в Windows NT достаточно велико, и, хорошо зная работу сетевой подсистемы, можно ощутимо улучшить работу ОС. И наоборот тоже. Поэтому данная статья обязательна к ознакомлению тем, кто хочет “покрутить параметры”.

Диспозиция

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

Речь будет идти про настройку для ядра NT 6.1 (Windows 7 и Windows Server 2008 R2). Всякие исторические ссылки будут, но сами настройки и команды будут применимы к указанным ОС, если явно не указано иное.

В тексте будут упоминаться ключи реестра. Некоторые из упоминаемых ключей будут отсутствовать в официальной документации. Это не страшно, но перед любой серьёзной модификацией рабочей системы лучше фиксировать то, что Вы с ней делаете, и всегда иметь возможность удалённого доступа, не зависящую от состояния сетевого интерфейса (например KVM).

Это – первая часть статьи. Потому что настроек достаточно много. В следующей части я расскажу про другие.

Содержание

• Работаем с RSS
• Работаем с CTCP
• Работаем с NetDMA
• Работаем с DCA
• Работаем с ECN
• Работаем с TCP Timestamps
• Работаем с WSH
• Работаем с MPP

Поехали.

Настраиваем RSS в Windows

Аббревиатура RSS обычно ассоциируется совсем с другим, нежели с настройкой TCP. Хотя, в общем, это у всех по-разному – кто-то PHP с ходу расшифровывает как Penultimate Hop Popping, а кто-то думает, что КВД – это НКВД без первой буквы. Все люди разные. Мы будем говорить про тот RSS, который Receive Side Scaling.

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

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

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

Допустим, у Вас есть быстрый сетевой адаптер (например, 10Гбит), и по нему к Вам приходит много данных. И эти данные хорошо разделяются на много потоков (например, когда мы ведём вебинары, на каждого слушателя идёт почти по десятку TCP-сессий, а слушателей бывает и 40). По сути, все эти потоки данных выглядят потоками только на транспортном уровне, а на сетевом сливаются в общий поток. Это, в общем, и есть работа протоколов транспортного уровня – мультиплексировать потоки данных от различных приложений на различных хостах. Но от этого нашей принимающей стороне не легче – ведь ей надо из входящего потока сформировать:

• Отдельные сессии TCP – т.е. для каждой поддерживать session state, буферы данных, состояние cwnd/rwnd, состояние sack’ов и ack’ов вообще
• Отдельные буферы для каждого фрагментированного IP-пакета
• Отдельные очереди (ведь трафик может обладать приоритетами)

И практически каждое событие во всей этой пачке сессий – это вызов прерывания и его обработка. Крайне затратно, особенно учитывая, допустим, негативный сценарий (10 гигабит поток, ip-пакеты по 1КБ). Можно даже сказать проще – ощутимое количество процентов мощности процессора (весьма дорогого, заметим) уйдёт на решение этих задач тех.обслуживания. Как с этим бороться? Да просто – пусть адаптер формирует отдельные очереди пакетов – тогда на каждую из них можно “привязать” свой процессор/ядро, и нагрузка в плане прерываний и прочего распределится. Но тут нас поджидает неочевидная проблема.

Дело в том, что просто так распределить не получится. Т.е. если мы придумаем очень простой критерий распределения (например, две очереди, четные пакеты – налево, нечетные – направо), то у нас может получиться следующая ситуация – у потоков данных часть пакетов попадёт в “четную” очередь, а часть – в “нечетную”. А в этом случае мы потеряем все возможные бонусы, возникающие при обработке непрерывного потока пакетов (обычно эти бонусы выглядят как “первый пакет обрабатываем по-полной, кэшируем все возможные результаты обработки, и все последующие пакеты обрабатываем по аналогии”). Т.е. нам надо всячески избегать ситуации, когда одному процессору придётся, обрабатывая, например, поток очень однотипных мультимедийных пакетов (какой-нибудь RTP например), пытаться “сбегать почитать” в соседнюю очередь. Скажем проще – никуда он вообще бегать тогда не будет, а придётся тогда нам выключать всяческие ускорения обработки TCP/UDP/IP-потоков, потому что работать они будут только в случае ситуации, когда весь поток однотипных пакетов обрабатывается одним ядром/процессором. А это приведёт к тому, что на процессоры придётся переводить вообще всю нагрузку по обработке сетевых данных, что с гарантией “убьёт” даже достаточно мощный CPU.

То есть, наша задача-максимум – это распределить входящие данные по нескольким отдельным очередям приёма, да так, чтобы потоки пакетов легли в очереди “целиком”, да и ещё желательно, чтобы заполнились эти очереди равномерно. Тогда мы и распределим нагрузку по процессорным ядрам, и не потеряем другие возможности по ускорению обработки потоков пакетов. Для решения этой задачи нам надо будет действовать сообща – и ОС, и оборудованию.

Хороший RSS начинается с сетевой карты. В сетевых картах, которые умеют RSS (а уже понятно, что это не карты минимального уровня), такой функционал есть – например в очень даже недорогой Intel 82576 (в моём случае – встроена в сервер) есть функционал и включения RSS сразу, и выбора количества очередей – 1, 2, 4 или 8.

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

Дело в том, что для того, чтобы определить “принадлежность” пакета к потоку, RSS использует следующую логику – берутся несколько ключевых полей пакета – SRC IP, DST IP, код протокола L4, SRC PORT, DST PORT – и от них вычисляется хэш, по последним битам которого (соответственно, для 2х очередей достаточно и одного бита, для 4х – двух, для 8 – трёх) и определяется принадлежность пакета к буферу. Соответственно, пакеты одного протокола, идущие с одного фиксированного порта и IP-адреса на другой адрес и порт, будут формировать поток и попадать в одну очередь. Такой подход достаточно быстр и прост с точки зрения балансировщика, но, как понятно, никак не решает ситуацию “Есть два стула две TCP-сессии – одна 1% канала занимает, другая 99%”. И даже не гарантирует, что обе эти сессии не попадут (с вероятностью 1/2) в одну и ту же очередь, что вообще превратит всю задачу в бессмыслицу.

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

Ну а вот дальше – уже задача операционной системы – что есть не один, а несколько потоков, и на каждый надо выделить свой процессор или ядро. Это как раз и будет тот самый RSS, который мы будем включать. Он уже будет создавать в драйвере NDIS отдельные очереди и выделять на каждую из них по процессору/ядру.

Нововведением в Windows Server 2008 R2 является то, что этим можно управлять – правда, только через реестр. В частности, управлению будут поддаваться 2 параметра – стартовое количество процессорных ядер, выделяемое для всех RSS-очередей на адаптере, и максимальное количество ядер для данной задачи. Параметры эти будут находиться по адресу HKLM\SYSTEM\CurrentControlSet\Control\Class\гуид сетевого адаптера\номер сетевого адаптера\ и называться, соответственно, *RssBaseProcNumber и *MaxRSSProcessors.

Пример использования данных параметров – допустим, у Вас есть сервер с 16 ядрами (2 процессора по 8 ядер или 4 по 4 – не суть). Есть три сетевых адаптера – один используется для управления системой, два других – для привязки к ним виртуальных машин. Вы можете выставить указанные параметры только у двух интерфейсов, на которых будет подразумеваться высокая нагрузка, притом следующим образом – поставить RssBaseProcNumber равным 2, а MaxRSSProcessors – например, 12. Тогда тот интерфейс, который будет активнее принимать трафик, сможет “отъесть” до 12 ядер системы на обработку очередей, при этом не надо будет жестко задавать этот параметр вручную (это удобно, если нагрузка переместится на другой интерфейс). Безусловно, в этом примере надо, чтобы сетевые адаптеры тоже поддерживали RSS, и, желательно, хотя бы очередей 8.

Подводя итоги – RSS – это достаточно практичная и нужная технология, требующая поддержку и со стороны оборудования, и со стороны операционной системы. И становящаяся всё более актуальной, так как на данный момент скорости сетевых интерфейсов растут, равно как и количество процессорных ядер, а, следовательно, старый подход, когда одно ядро “разгребает” единую входящую очередь, становится всё менее эффективным.

Как включить RSS в Windows

netsh interface tcp set global rss=enabled

Настраиваем логику алгоритма контроля перегрузки (CTCP) в Windows

Compound TCP – это Microsoft’овский протокол управления “окном перегрузки” (congestion window). Адресно предназначен для форсированного изменения окна при работе в сетевых средах с относительно большой задержкой (например, по WiMax или спутниковым каналам). Соответственно, не сильно полезен в сценарии широкополосного доступа в Интернет или работе по локальной сети.

По сути, всё, что он делает, это форсирует быстрое увеличение окна со стороны отправителя в случае, если обнаруживается, что сеть имеет малое время отклика, и быстро уменьшает окно в случае задержек на канале.

Как включить CTCP в Windows

netsh interface tcp set global congestionprovider=ctcp

Настраиваем использование NetDMA в Windows

NetDMA – достаточно интересная функция. Смысл её применения есть тогда, когда у Вас не поддерживается Chimney Offload и Вы хотите ускорить обработку сетевых подключений. NetDMA позволяет копировать без участия CPU данные (в общем, как и любой DMA-доступ) из приемных буферов сетевого стека сразу в буферы приложений, чем снимает с CPU данную задачу по тупому выполнению чего-то типа rep movsd.

Говоря проще, если Ваша сетевая плата не может “вытащить” на себя полную обработку TCP-соединений, то NetDMA хотя бы разгрузит процессор от самой унылой части задачи по обслуживанию сетевых соединений – копированию данных между сетевой подсистемой и использующими её приложениями.

Что нужно для включения NetDMA в Windows

Нужно оборудование, которое поддерживает NetDMA – в случае Windows это процессор с поддержкой технологий семейства Intel® I/O Acceleration Technology (I/OAT), которые, в свою очередь, входят в Intel Virtual Technology for Connectivity (VT-c). Включение NetDMA на оборудовании AMD эффекта, увы, не принесёт – не поверив, проверил на домашнем феноме 1055T – действительно, NetDMA не включается.

Как включить NetDMA в Windows

Локально:

netsh interface tcp set global netdma=enabled

Через Group Policy:

Откройте ключ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\, создайте в нём параметр EnableTCPA вида 32bit DWORD и поставьте его в единицу

Секретный уровень

Если Вы дочитали до этого места, то дальше не читайте – опасно. Но вообще, в том же ключе – HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ – есть параметр MinPacketSizeToDma, тоже типа 32bit DWORD, который, что и логично, исходя из его названия, указывает минимальный размер пакета, для которого имеет смысл инициировать DMA-передачу. Параметр данный выставляется автоматически и его тюнинг имеет слабый практический смысл – т.е. в принципе можно представить ситуацию, когда система поставит слишком малый параметр, и будет слишком часто переключаться на DMA, а Вы это поправите вручную, но очень слабо могу представить себе КПД этой операции – выяснять сие путём достаточно кропотливых синтетических тестов, чтобы выиграть призрачные доли процента на единственной операции в единственной подсистеме, притом доли эти будут укладываться в погрешность измерений, весьма уныло.

Настраиваем использование DCA (прямого доступа к кэшу NetDMA) в Windows

По сути, Direct Cache Access – это дополнение к NetDMA, которое появляется только в NetDMA 2.0 и является опциональным (т.е. факт наличия NetDMA не говорит о том, что DCA будет работать). Задачи, которые решает DCA, просты – он “привязывает” конкретную сетевую сессию к определённому ядру процессора, и позволяет копировать данные не по трассе “сетевой интерфейс”->”оперативная память”->”кэш процессора”, а напрямую с сетевого интерфейса в кэш процессора. В ряде сценариев (быстрая сеть и много сессий и ядер CPU) выигрыш может быть ощутимым – судя по исследованиям IEEE за 2009й год, в случае загруженной на ~80% 10Gbit сети плюс 12ти ядер нагрузка CPU падает примерно на треть.

Технология работоспособна для гигабитных и более быстрых сетевых адаптеров. И, как понятно, имеет смысл только в случае, когда сетевой адаптер не умеет Chimney Offload (что, в общем-то, уже достаточно сложно – в случае наличия нагрузки, при которой DCA эффективен, обычно используются сетевые адаптеры, которые на аппаратном уровне умеют обрабатывать TCP).

Кстати, интересный момент – DCA есть в Windows Server 2008, но не работает в Vista. В NT 6.1 работает везде, включая Windows 7.

Как включить DCA в Windows

Предварительно – обязательно включить NetDMA.

Локально:

netsh interface tcp set global dca=enabled

Через Group Policy:

Откройте ключ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\, создайте в нём параметр EnableDCA вида 32bit DWORD и поставьте его в единицу

Настраиваем уведомления о перегрузке (ECN’ы) в Windows

Технология ECN в явном виде относится и к IP, а не только к TCP, но все равно про неё стоит тут написать.

Протокол IP изначально не особо любил технологии класса Quality of Service – QOS, поэтому в заголовке IPv4 выделен байт с целью “использовать для целей управления качеством”. Притом этот байт может содержать данные в разных форматах, и то, как его интерпретировать, решает конкретный хост. Используется два возможных формата данного байта – DSCP (он же DiffServ) и IP Precedence. По умолчанию этот байт (называющийся ToS – Type of Service) обрабатывается как IP Precedence и представляет собой копию данных канального уровня (в него копируются три бита от CoS – Class of Service, которые передаются в 802.3 кадре в составе 802.1p компонента заголовка 802.1Q).

Но нас будет интересовать ситуация, когда в заголовке IP-пакета – в поле ToS, разумеется – данные интерпретируются в формате DSCP. В этом случае на номер класса трафика отдаётся 6 бит (что даёт возможность сделать в организации 2^6 = 64 класса трафика и удобно управлять приоритетами), а оставшиеся 2 бита отдаются как раз на сигнализацию о “заторах”.

Говоря проще, если у промежуточного устройства буфер пакетов близок к перегрузке, то оно сигнализирует Вам, отправляя служебный пакет на IP отправителя, что “пакеты скоро будет некуда девать и придётся их выбрасывать, притормози”. Отправляет их, выставляя как раз специфические биты в поле ToS. Соответственно, включая поддержку данной технологии, Вы будете включать и возможность генерации подобных пакетов, и возможность анализа оных.

Простейший пример ситуации, в которой это поможет – на пути Вашего трафика стоит маршрутизатор, который в Вашу сторону смотрит интерфейсом со скоростью 1 Gbit, а дальше – интерфейсом со скоростью 100 Mbit. Если Вы будете отдавать ему трафик с максимально возможной скоростью, то его очередь пакетов, пытающихся “выйти” через интерфейс со скорость 100 Mbit, очень быстро переполнится, и если он не сможет Вам об этом сказать (ну или если Вы не включите со своей стороны возможность услышать эти сообщения от него), то ему придётся просто в определённый момент перестать принимать пакеты, сбрасывая их. А это приведёт к тому, что начнётся потеря данных, которые надо будет восстанавливать – а служебный трафик при восстановлении данных достаточно значителен. Т.е. гораздо проще передать чуть медленнее, чем потерять много пакетов и выяснить это на уровне TCP-подключения, после чего запрашивать их повторно, теряя время и тратя трафик.

Кстати, проверить поддержку ECN ближайшим маршрутизатором можно бесплатной утилитой Internet Connectivity Evaluation Tool.

Как включить ECN в Windows

netsh interface tcp set global ecn=enabled

Настраиваем TCP Timestamps (по RFC 1323) в Windows

TCP Timestamps – базовая низкоуровневая технология, которая позволяет стеку TCP измерять два важных параметра для соединения: RTTM (задержку канала) и PAWS (защита от дублирующихся TCP-сегментов). В случае, если TCP Timestamps не включены хотя бы с одной стороны подключения, оба механизма вычисления этих параметров отключены и система не может высчитать данные значения. Это приводит к тому, что становится невозможным быстро и эффективно менять размер окна TCP (без знания времени задержки на канале-то). Поэтому включать TCP Timestamps в случае работы с большими объёмами данных (например, обращение к быстрому серверу в локальной сети – типовой сценарий корпоративной LAN) необходимо – ведь иначе протокол TCP не сможет быстро “раскачать” окно передачи.

Как включить TCP Timestamps в Windows

netsh interface tcp set global timestamps=enabled

Побочные эффекты включения TCP Timestamps в Windows

Практически не наблюдаются. Рост локальной загрузки CPU отсутствует, т.к. алгоритм достаточно прост, рост объёмов служебного трафика – так же (RTTM высчитывается, исходя из “времени оборота” обычных сегментов TCP, а не каких-то специальных дополнительных).

Настраиваем автоматический подбор размера окна TCP (WSH) в Windows

Данный параметр достаточно прост. Эта настройка – Window Scale Heuristic – говорит о том, будете ли Вы сами выбирать логику поведения протокола TCP для выбора размеров окна, либо отдадите это на усмотрение операционной системе.

То есть при включенном алгоритме WSH вышеупомянутый тюнинг окна TCP – выбор между disabled/highlyrestricted/restricted/normal/experiemental – будет делаться автоматически и Ваша настройка параметра autotuninglevel будет просто игнорироваться. При просмотре будет появляться служебное окно с текстом "The above autotuninglevel setting is the result of Windows Scaling heuristics overriding any local/policy configuration on at least one profile".

Как включить Window Scaling Heuristic в Windows

netsh interface tcp set heuristics wsh=enabled

Настраиваем базовую безопасность TCP (параметр Memory Pressure Protection) в Windows

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

Параметр включен по умолчанию в Windows Server 2008 R2, поэтому обычно нет смысла его настраивать, но если что – Вы можете его включить вручную. Более того, Вы можете выбрать, на каких портах эту защиту включать, а на каких – нет. Это имеет смысл, если доступны снаружи лишь некоторые порты, а не все.

Как включить Memory Pressure Protection в Windows

netsh interface tcp set security mpp=enabled

Включение MPP для отдельного порта (например, у нас наружу опубликован веб-сервер)

netsh int tcp set security startport=80 numberofports=1 mpp=enabled

Выключение MPP для всех портов, кроме указанного (например, кроме LDAP)

netsh int tcp set security startport=1 numberofports=65535 mpp=disabled
netsh int tcp set security startport=389 numberofports=1 mpp=enabled
netsh int tcp set security startport=636 numberofports=1 mpp=enabled

Дополнительно

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

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableMPP
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\EnableMPP

Параметр EnableMPP в каждом из случаев имеет тип 32bit DWORD и ставится либо в единицу, либо в нуль.

Вместо заключения

Данный краткий обзор части возможностей настроек сетевой подсистемы Windows имеет собой цель не побудить к немедленной правке всего вышеупомянутого, а показать то, что в данной ОС присутствует достаточно много инструментов тюнинга, хорошее знание которых может очень позитивно повлиять на работу системы. Только надо учитывать, что хорошее знание – это не “какая утилитка какие ключики правит”, а в первую очередь – отличное знание базовых сетевых технологий, которое, увы, сейчас в сообществе специалистов по Windows встречается крайне редко. Но я верю, что у Вас, при надлежащем системном подходе, всё будет хорошо.

UPDATE

Написал вторую часть статьи.

Windows 7, Vista, 2008, R2 2008Tweaks

Tweaking Windows 7 / Vista TCP/IP settings for broadband internet connections
2008.04.24 10:40 by Philip
Keywords: patch, Nagle, QoS, SynAttackProtect, DNS, DefaultTTL, NetDMA, TCP 1323 Options, MTU, auto-tunning, Compound TCP, Chimney Offload, CTCP, TCP Window, Registry, TCP/IP, tweak, Vista, Windows 7

Windows Vista introduces a number of new features to the TCP/IP stack, including CTCP, and TCP Window Auto-Tuning. This new implementation works much better by default than previous Windows versions with broadband internet connections, and is able to adjust the RWIN value on the fly, depending on the BDP (bandwidth-delay product). This, however, introduces some problems with older routers and restricts the user from tweaking some of the TCP/IP parameters. Still, there is always some room for improvement, and this article explains the known tweakable TCP/IP parameters.

To enter some of the commands below, you will need to run «elevated» command prompt. To do so, click the Start icon > Run > type: cmd , then click CTRL+SHIFT+ENTER. Alternatively, you can navigate to Start > All Programs > Accessories > right-click Command Prompt and choose «Run as Administrator».

Check the TCP/IP state

To check the current status of the Vista TCP/IP tweakable parameters, in elevated command prompt type the following command:

netsh int tcp show global

You will be presented with something like the following:

The settings, as well as their default and recommended state are explained below. The two most important tweakable parameters are «Auto-Tuning Level» and «Congestion Control Provider».

When checking the TCP state with the «netsh int tcp show global» command, it is also possible to see the following message below all those parameters:

** The above autotuninglevel setting is the result of Windows Scaling heuristics overriding any local/policy configuration on at least one profile.

It is displayed when the «Receive Window Auto-Tuning Level» is not explicitly set, or if the system deemed it necessary to make a change because of user prompted «repairing» of your network connection, for example.

Disable Windows Scaling heuristics

Windows Vista/7 has the ability to automatically change its own TCP Window auto-tuning behavior to a more conservative state regardless of any user settings. It is possible for Windows to override the autotuninlevel even after an user sets their custom TCP auto-tuning level. When that behavior occurs, the «netsh int tcp show global» command displays the following message:

** The above autotuninglevel setting is the result of Windows Scaling heuristics
overriding any local/policy configuration on at least one profile.

To prevent that behavior and enforce any user-set TCP Window auto-tunning level, you should execute the following command:

netsh int tcp set heuristics disabled

possible settings are: disabled,enabled,default (sets to the Windows default state)
recommended: disabled (to retain user-set auto-tuning level)

Note this should be executed in elevated command prompt (with admin priviledges) before setting the autotuninlevel in next section. If the command is accepted by the OS you will see an «Ok.» on a new line.

The corresponding Registry value (not necessary to edit if setting via netsh) is located in:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters
EnableWsd=0   (default: 1, recommended: 0)

TCP Auto-Tuning

To turn off the default RWIN auto tuning behavior, (in elevated command prompt) type:

netsh int tcp set global autotuninglevel=disabled

The default auto-tuning level is «normal», and the possible settings for the above command are:

disabled: uses a fixed value for the tcp receive window. Limits it to 64KB (limited at 65535).
highlyrestricted: allows the receive window to grow beyond its default value, very conservatively
restricted: somewhat restricted growth of the tcp receive window beyond its default value
normal: default value, allows the receive window to grow to accommodate most conditions
experimental: allows the receive window to grow to accommodate extreme scenarios (not recommended, it can degrade performance in common scenarios, only intended for research purposes. It enables RWIN values of over 16 MB)

Our recommendation: normal  (unless you’re experiencing problems).

If you’re experiencing problems with your NAT router or SPI firewall, try the «restricted», «highlyrestricted», or even «disabled» state.

Notes:
— Reportedly, some older residential NAT routers with a SPI firewall may have problems with enabled tcp auto-tuning in it’s «normal» state, resulting in slow speeds, packet loss, reduced network performance in general.
— auto-tuning also causes problems with really old routers that do not support TCP Windows scaling. See MSKB 935400 
— netsh set commands take effect immediately after executing, there is no need to reboot.
— sometimes when using «normal» mode and long lasting connections (p2p software / torrents), tcp windows can get very large and consume too much resources, if you’re experiencing problems try a more conservative (restricted) setting.

If you’re experiencing problems with Auto-Tuning, see also:
MSKB 835400 — email issues
MSKB 934430 — network connectivity behind firewall problems
MSKB 940646 — 3G WWAN throughput issues
MSKB 929868 — web browsing issues
MSKB 932170 — slow network file transfer

Compound TCP — Improve throughput
Add-On Congestion Control Provider

The traditional slow-start and congestion avoidance algorithms in TCP help avoid network congestion by gradually increasing the TCP window at the beginning of transfers until the TCP Receive Window boundary is reached, or packet loss occurs. For broadband internet connections that combine high TCP Window with higher latency (high BDP), these algorithms do not increase the TCP windows fast enough to fully utilize the bandwidth of the connection.

Compound TCP (CTCP) is a newer method, available in Vista and Server 2008 (there is also a hotfix available for XP x64 and 2003 Server — MSKB 949316). CTCP increases the TCP send window more aggressively for broadband connections (with large RWIN and BDP). CTCP attempts to maximize throughput by monitoring delay variations and packet loss. It also ensures that its behavior does not impact other TCP connections negatively.

By default, Vista and Windows 7 have CTCP turned off, it is only on by default under Server 2008. Turning this option on can significantly increase throughput and packet loss recovery.

To enable CTCP, in elevated command prompt type:

netsh int tcp set global congestionprovider=ctcp

To disable CTCP:

netsh int tcp set global congestionprovider=none

Possible options are:  ctcp, none, default (restores the system default value).
Recommended setting: ctcp

It is better to use this newer generation CTCP congestion control algorithm for most broadband connections, we highly recommend it being turned on.

ECN Capability

ECN (Explicit Congestion Notification, RFC 3168) is a mechanism that provides routers with an alternate method of communicating network congestion. It is aimed to decrease retransmissions. In essence, ECN assumes that the cause of any packet loss is router congestion. It allows routers experiencing congestion to mark packets and allow clients to automatically lower their transfer rate to prevent further packet loss. Traditionally, TCP/IP networks signal congestion by dropping packets. When ECN is successfully negotiated, an ECN-aware router may set a bit in the IP header (in the DiffServ field) instead of dropping a packet in order to signal congestion. The receiver echoes the congestion indication to the sender, which must react as though a packet drop were detected.

ECN is disabled by default in Vista and other modern TCP/IP implementations, as it is possible that it may cause problems with some outdated routers that drop packets with the ECN bit set, rather than ignoring the bit. To check whether your router supports ECN, you can use the Microsoft Internet Connectivity Evaluation Tool. The results will be displayed under «Traffic Congestion Test».

To change ECN, in elevated command prompt type:

netsh int tcp set global ecncapability=default

Possible settings are: enabled, disabled, default (restores the state to the system default).
The default state is: disabled
Recommendation: enabled (only for short-lived, interactive connections and HTTP requests with routers that support it, in the presense of congestion/packet loss), disabled otherwise (for pure bulk throughput with large TCP Window, no regular congestion/packet loss, or outdated routers without ECN support).

Notes: ECN is only effective in combination with AQM (Active Queue Management) router policy. It has more noticeable effect on performance with interactive connections and HTTP requests, in the presense of router congestion/packet loss. Its effect on bulk throughput with large TCP Window are less clear.

Currently, we do not recommend enabling this setting, as reportedly it has negative impact on throughput with some residential US ISPs. EA multiplayer games that require a profile logon do not support ECN as well (you will not be able to logon).

More information on ECN: Explicit Congestion Notification (ECN) for TCP/IP

RSS — Receive-side Scaling

The receive-side scaling setting enables parallelized processing of received packets on multiple processors, while avoiding packet reordering. It avoids packet reordering y separating packets into «flows», and using a single processor for processing all the packets for a given flow. Packets are separated into flows by computing a hash value based on specific fields in each packet, and the resulting hash values are used to select a processor for processing the flow. This approach ensures that all packets belonging to a given TCP connection will be queued to the same processor, in the same order that they were received by the network adapter.

To set RSS:

netsh int tcp set global rss=enabled

Possible rss settings are: disabled, enabled, default (restores rss state to the system default).
Default state is: enabled
Recommended: enabled (if you have 2 or more processor cores and a NIC that can handle RSS)

TCP Chimney Offload

TCP chimney offload enables Windows to offload all TCP processing for a connection to a network adapter. Offloads are initiated on a per-connection basis. Compared to task offload, TCP chimney offload further reduces networking-related CPU overhead, enabling better overall system performance by freeing up CPU time for other tasks.

To set TCP Chimney Offload:

netsh int tcp set global chimney=enabled

Default state: disabled (under Vista), automatic (under Windows 7 and 2008 Server)
Recommended: enabled

The possible states are disabled, enabled, default (Vista), automatic (only Windows 7 and 2008 Server) as follows:

automatic — This default setting is only available under Windows 7 and 2008 Server, it is not available udner Vista. It offloads if the connection is 10 GbE, has a RTT < 20ms, and the connection has exchanged at least 130KB of data. The device driver must also have TCP Chimney enabled.
default — this setting restores chimney offload to the system default. Setting this «default» state under Windows 7 and 2008 Server is possible, but it sets the system to the «automatic» mode described above.
disabled — this setting is maually configured as disabled.
enabled — this setting is manually configured as enabled.

Notes:
Under Windows 7 and Server 2008 the «default» and the additional «automatic» parameter set the system to the same «automatic» state.
For Chimney Offload to work, it needs to be enabled in both the OS and NIC. To enable the «TCP Offloading» setting in your NIC, navigate to the Device Manager, under Network Adapters, in the Advanced tab, and check «Enabled» in the box next to the TCP offload entry.

Direct Cache Access (DCA)

Windows 7 and 2008 Server (but not Vista) add NETDMA 2.0 Direct cache access support. Direct Cache Access (DCA) allows a capable I/O device, such as a network controller, to deliver data directly into a CPU cache. The objective of DCA is to reduce memory latency and the memory bandwidth requirement in high bandwidth (Gigabit) environments. DCA requires support from the I/O device, system chipset, and CPUs.

To enable DCA:

netsh int tcp set global dca=enabled

Available states are: enabled, disabled.
Default state: disabled
Recommended: enabled (provided the CPU/Chipset/NIC support it)

It is also possible to enable this setting by editing the Windows Registry instead of using netsh as follows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
EnableDCA=1 (DWORD, entry does not exist by default. Set to 1 to enable, 0 to disable)

Setting MTU

It is sometimes useful to view and set the MTU value for a specific network interface manually. To view a list of active network interfaces and their MTU values in Vista using netsh, open command prompt as administrator and execute the following command:

netsh interface ipv4 show subinterface

You will be presented with a list of interfaces, and their respective MTU values as follows:

To change the MTU value of a specific network card, type the following in command prompt:

netsh interface ipv4 set subinterface «network interface name» mtu=#### store=persistent

Where «network interface name» is your specific network adapter name as obtained above (or viewable under Network adapters), and mtu=#### is the desired MTU value.

For example, if the name of your network card is «Wireless Network Connection» and you’d like to set its MTU to 1500, you’d have to type:

netsh interface ipv4 set subinterface «Wireless Network Connection» mtu=1500 store=persistent

Note: The maximum MTU value is usually 1500, and up to 1492 for PPPoE connections.

Manually tuning Registry Parameters

Many of the registry keys tuning TCP/IP parameters from previous Windows versions no longer work in Vista and Server 2008. Below is a list of the few we’ve confirmed to still work. Note that for changes to these settings to take effect the computer needs to be rebooted. As always, a registry backup is recommended if making any changes, and some proficiency in using regedit is required.

In regedit (Start icon > Run > type: regedit  while logged in as administrator), you can navigate and edit the following keys.

MTU (Maximum Transmission Unit) — the maximum packet size.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{…}\
MTU=1500 (DWORD, entry does not exist by default)

The {….} part of the above path is the unique identifier of your network adapter. You can recognize the correct adapter by looking at it’s IP address, if obtaining IP automatically labeled by: DhcpIPAddress=192.168.x.x text value, for example.

We recommend leaving this at default, unless you want to lower it. Vista uses the largest possible packet size for the underlying network by default.

Note: In some test environments, the correct MTU entry may be offset by 8. The 8 offset seems to coincide with the size of the PPPoE overhead. Check the result with the TCP Analyzer.

TCP 1323 Options

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
Tcp1323Opts=1 (DWORD, entry created automatically by Windows when you run the «netsh int tcp set global autotuninglvl=…» command, set to 0 by default).

Setting this seems to have no effect, since auto-tuning uses the TCP 1323 scale factor and changes it on the fly, disregarding this setting. Additional testing may be required to determine it’s effect if auto-tuning is turned off. Setting it to 1 is best for broadband connections. 

NetDMA (TCPA)

NetDMA enables support for advanced direct memory access. In essence, it provides the ability to more efficiently move network data by minimizing CPU usage. NetDMA frees the CPU from handling memory data transfers between network card data buffers and application buffers by using a DMA engine.

Under Windows 7, NetDMA can be set directly using the netsh interface (not available under Vista):

netsh int tcp set global netdma=enabled

Under Vista/2008/7, you can set NetDMA/TCPA using the following Registry parameter:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
EnableTCPA=1  (DWORD, not in registry by default. Set to 1 to enable, 0 to disable NetDMA)

Recommended setting is 1 (if not using Chimney Offload), zero otherwise. A new DWORD value may need to be created if not already present in the registry.

For NetDMA to work, it must be enabled in BIOS, your CPU must support Intel I/O Acceleration Technology (I/OAT), and it does not work together with Chimney Offload. More info available -here-

Checksum Offloading (DisableTaskOffload)

This NDIS 5 setting allows for reducing CPU load by offloading some tasks required to maintain the TCP/IP stack to the network card. Theoretically, Widnows should automatically detect capable network hardware.

The tasks offloaded are as follows:
— TCP/IP checksum calculation — each packet sent includes a verification checksum.
— TCP/IP segmentation — also known as «TCP Large Send» where Windows sends a large amount of data to the network card, and the NIC is then responsible for dividing it according to the network MTU. Experimental feature, not enabled by default
— IPSec Encryption cyphers and message digests — provides encryption of packets at the hardware level.

To change the checksum offloading setting in the Windows Registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
DisableTaskOffload=0 (DWORD value, default: not set, recommended: 0=enable offload, 1=disable offload)

Also see: MS KB 888750, MS KB 904946, MS KB 936702

DefaultTTL

TTL can be safely left alone in many cases. It is a limit to the time and number of hops/routers a packet will travel before being discarded. A number that’s too small risks packets being discarded before reaching their destination. A number that’s too large (over 128) will cause delay in when lost IP packets are discarded. 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
DefaultTTL=64  (DWORD, set to a decimal value between 32 and 128. Recommended: 64) 

TcpMaxDataRetransmissions

Determines how many times unacknowledged data (non-connect segment) is retransmitted before TCP aborts the connection. The retransmission timeout is doubled with each successive retransmission on a connection. It is reset when responses resume.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
TCPMaxDataRetransmissions=7  (DWORD, recommended: between 3 and 10, not present in registry by default)

Note: When not present in the registry, the default behavior is 255 retransmissions (5 in documentation).

SynAttackProtect

This undocumented setting provides protection against SYN denial of service (DoS) attacks. When enabled, connections timeout sooner if SYN attack is detected. When set at 1, TCPMaxDataRetransmissions can be lowered further.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
SynAttackProtect=1  (DWORD, recommended: 1, not present in registry by default)

Network Throttling Index

By default, Windows Vista/7 implements a network throttling mechanism to restrict the processing of non-multimedia network traffic to 10 packets per millisecond (a bit over 100 Mbits/second). The idea behind such throttling is that processing of network packets can be a resource-intensive task, and it may need to be throttled to give prioritized CPU access to multimedia programs. In some cases, such as Gigabit networks and some online games, for example, it may be benefitial to turn off such throttling all together.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile
NetworkThrottlingIndex=ffffffff  (DWORD, default: 10 hex, recommended: 10 hex for media sharing, ffffffff for gaming and max throughput, valid range: 1 through 70 decimal or ffffffff to completely disable throttling)

It is only recommended to change this setting in saturated Gigabit LAN environments, where you do not want to give priority to multimedia playback. Reportedly, disabling throttling by using ffffffff can also help reduce ping spikes in some online games.

Notes: Setting is available in Windows 7, Vista (SP1), 2008 Server. Default value is 10 under Windows 7, similar behavior if the setting is not present in the Registry.
Games that may be affected by this throttling: Source Engine games (TF2, Left 4 Dead, CS:S), HoN, CoD, Overlord series.

Reference: MSKB 948066

Set DNS and Hosts Priority

As with previous versions of Windows, one can improve DNS and hostname resolution by increasing the priority of of related services, while keeping their order. This is explained in more defail in our Host Resolution article. Lower numbers mean higher process priority. The corresponding registry settings in Vista are as follows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ServiceProvider
LocalPriority=4  (DWORD, recommended: 4, default: 499) — local names cache
HostsPriority=5  (DWORD, recommended: 5, default: 500) — the HOSTS file
DnsPriority=6  (DWORD, recommended: 6, default: 2000) — DNS
NetbtPriority=7  (DWORD, recommended: 7, default: 2001) — NetBT name resolution, including WINS

TcpTimedWaitDelay (port allocation)

Short lived (ephemeral) TCP/IP ports above 1024 are allocated as needed by the OS. The default Vista values have improved from previous Windows versions, and are usually sufficient under normal load. However, in some instances under heavy load it it may be necessary to adjust the settings below to tweak the availability of user ports requested by an application.

If the default limits are exceeded under heavy loads, the following error may be observed: «address in use: connect exception».  By default under Vista (when the values are not presend in the registry), the OS can allocate up to 16384 ephemeral ports above port 1024, and the OS waits for 120 seconds before reclaiming ports after an application closes the TCP connection. This is a considerable improvement over older Windows versions. However, if necessary, the following registry values can be added/edited:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
MaxUserPort=65534 (DWORD, not in the registry by default. Recommended: leave at default, or use a number above 16384 up to 65534 decimal as necessary) —  maximum number of ports to use. 1024 is automatically subtracted from entered value to allow for reserved ports under 1024. 
TcpTimedWaitDelay=30 (DWORD, not present or 0xffffffff in registry by default. Recommended: 30 decimal, denoting 30 seconds) — time to wait before reclaiming ports, in seconds. Default time before reclaiming ports, if value is at 0xffffffff or not present in the registry is 120 seconds. Just reducing the delay is often sufficient without changing MaxUserPort, as it allows for reusing ports more efficiently.

Ephemeral ports can be checked and changed using netsh as well.

To query the current values, in command prompt, type:
netsh int ipv4 show dynamicportrange tcp (for UDP, use the same command, replacing only «tcp» with «udp» at the end)

To set both the starting, and max user port using netsh, in elevated command prompt run:
netsh int ipv4 set dynamicportrange protocol=tcp start=1025 num=64511 (start=NNN denoting the starting port, and num=NNN denoting the number of ports)

Notes:
By default, dynamic ports are allocated between ports 49152 and 65535 (for a total of 16384 ephemeral ports).
Using netsh allows to set both the starting port and port range. Editing the Registry allows for setting the port range, and the starting port is fixed at 1025. Deleting the MaxUserPort registry entry (or setting it to a value outside the allowed range) causes the OS to revert to using the default values.
Some system processes can install port filters to block certain port ranges. If ephemeral ports run into these filtered port ranges, TCP/IP applications will be unable to bind to any ports.

See also: TechNet article, MSKB 328476, MSKB 319502

QoS Reserved Bandwidth

As with Windows XP, nework adapters have a «QoS Packet Scheduler» enabled by default, which reserves 20% of bandwidth by default for QoS applications that request priority traffic. Note this only has effect in the presence of running QoS applications that request priority traffic. Registry value is undocumented for the Vista version of Windows. To customize this setting, in the Windows Registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched
NonBestEffortLimit=0 (DWORD, not present in the registry by default. Recommended: 0 , possible values between 0 and 100) — indicates the percentage value of reserved bandwidth for QoS applications. Set to 0 to disable.

Notes: This tweak applies only to Windows versions that have Qos Packet Scheduler enabled. It will ONLY have effect in the presense of running QoS applications.

Network Memory Allocation (Event ID 2017 error)

When using Windows Vista/7 to serve many/large files over the local network, it is possible to sometimes run into memory allocation errors related to the Windows share. This can happen with Linux, Mac, or Windows XP clients. When this happens, you can usually see the following error in the Event Viewer System log:

Source: srv
Event ID: 2017
Level: Error
The server was unable to allocate from the system nonpaged pool because the server reached the configured limit for nonpaged pool allocations.

It is also possible to get an error indicating that: «Not enough server storage is available to process this command». To avoid those errors, you need to change the way Windows allocates memory for network services and file sharing. The below settings optimze the machine as a file server so it would allocate resources accordingly. There are two related registry settings:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
LargeSystemCache=1 (DWORD, default value: 0, recommended value: 1)

A value of zero above establishes a cache of ~8 MB, a value of 1 allows the cache to expand to physical memory minus 4 MB, if needed.

HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Size=3  (DWORD, default value: 1, recommended value: 3)

Size=1 minimizes used memory
Size=2 balance used memory
Size=3 optimal setting for file sharing and network applications

Note: Even though this tweak is from older Windows server OSes, it works on workstation versions, as well as Windows Vista and 7 (32 and 64 bit).

Gaming Tweak — Disable Nagle’s algorithm

The tweak below allows for tweaking or disabling Nagle’s alogrithm. Disabling «nagling» allows for very small packets to be transferred immediately without delay. Note that disabling Nagle’s algorithm is only recommended for some games, and it may have negative impact on file transfers/throughput. The dafault state (Nagling enabled) improves performance by allowing several small packets to be combined together into a single, larger packet for more efficient transmission. While this improves overall performance and reduces TCP/IP overhead, it may briefly delay transmission of smaller packets. Keep in mind that disabling Nagle’s algorithm may have some negative effect on file transfers, and can only help reduce delay in some games. To implement this tweak, in the registry editor (Start>Run>regedit) find:

This setting configures the maximum number of outstanding ACKs in Windows XP/2003/Vista/2008:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{NIC-id}
There will be multiple NIC interfaces listed there, for example: {1660430C-B14A-4AC2-8F83-B653E83E8297}. Find the correct one with your IP address listed. Under this {NIC-id} key, create a new DWORD value:
TcpAckFrequency=1 (DWORD value, 1=disable, 2=default, 2-n=send ACKs if outstanding ACKs before timed interval. Setting not present by default).

For gaming performance, recommended is 1 (disable). For pure throughput and data streaming, you can experiment with values over 2. If you try larger values, just make sure TcpAckFrequency*MTU is less than RWIN, since the sender may stop sending data if RWIN fills witout acknowledgement. 

Also, find the following key (if present):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters
Add a new DWORD value:
TCPNoDelay=1 (DWORD value, 0 to enable Nagle’s algorithm, 1 to disable, not present by default)

To configure the ACK interval timeout (only has effect if nagling is enabled), find the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{NIC-id}
TcpDelAckTicks=0  (DWORD value, default=2, 0=disable nagling, 1-6=100-600 ms). Note you can also set this to 1 to reduce the nagle effect from the default of 200ms without disabling it.

Notes:
Reportedly, the above gaming tweak (disabling nagle’s algorithm) can reduce WoW (World of Warcraft) latency by almost half!
XP/2003 needs hotfix or SP2 for it to work (MS KB 815230)
Vista needs hotfix or SP1 for it to work (MS KB 935458)
See also: NetworkThrottlingIndex setting above

SG TCP Optimizer (version 3.x)

The TCP Optimizer version 3.x allows for easy application of the above settings under all current Windows versions. This free software provides an intuitive interface for tunning your internet connection, backing up/restoring to the Windows defaults, etc. There is no installation required, you can just save it to the desktop, right-click > run as administrator and choose your settings. More detailed information about all available options is provided in the online documentation, answers to frequently asked questions are available in the Optimizer FAQ, and personalized help is available through our broadband tweaking forum.

SG TCP Optimizer download

For user convenience, we also provide a quick way to apply all optimal values as recommended above using our SG Vista TCP/IP Patch. It allows for tweaking all the above netsh settings and registry values in one simple step (with the exception of the «gaming tweak» section). The patch also provides for easily reverting the settings to their Windows default values. To apply, save to your desktop and run as administrator (right-click -> run as administrator). Click Y when prompted to apply settings.

Note: If for some reason Windows renames the file and adds .txt extension to it, you may have to manually rename it back to have a .cmd (or .bat) extension before running it as administrator. 

See Also

Windows Vista tcpip.sys connection limit patch for Event ID 4226 — removing the limit on half-open TCP connections.

References

Windows Server 2008 Network Shell (Netsh) Technical Reference
Microsoft KB951037

RFC 2581
Wikipedia: Nagle’s algorithm
Technet: TCPNoDelay
Technet: LargeSystemCache
MS KB 311833
MS KB 328890
MS KB 321098
MS KB 321169
MS KB 951037 — TCP Chimney Offload, Receive Side Scaling, and Network DMA in Windows Server 2008

Dragokas, цитирую http://www.speedguide.net/_ifr… %20WINDOW:
TCP Receive Window is a buffer that determines how much data the receiving computer is prepared to get at one time.
The sending side will only send data up to the size of the RWIN, and wait for acknowledgement before sending additional packets.
A RWIN value that’s too large will result in greater loss of data if a packet is lost or damaged. A too small RWIN will be very slow, as each packet will have to be acknowledged before the next packet is sent.
RWIN is one of the most important parameters in tweaking any TCP/IP connection.

На всякий случай (вдруг Вы не знаете английского) переведу:
TCP Receive Window (принимающее окно TCP) или RWIN — буфер, определяющий, сколько данных принимающий ПК готов принять за раз.
Отправляющая сторона отправляет данные согласно размеру этого буфера (не больше) и ожидает подтверждения перед отправкой доп. пакета.
Слишком большой размер RWIN приведет к бОльшим потерям, если пакет повредится/потеряется.
А слишком маленький размер окна делает его слишком медленным, так как каждый такой пакетик будет ждать подтверждения от предыдущего
Размер принимающего окна (RWIN) — один из самых важных параметров в настройках TCP/IP соединения.

Далее. https://blogs.msdn.microsoft.c… sta-tcpip/
МСДН говорит —

At any given time, the amount that TCP can send is governed by three factors: the congestion window, the receive window and the number of bytes available to send. Without using TCP window scaling (which is disabled by default in previous versions of Windows), the maximum receive window a receiver can advertise is 64K bytes. Since the congestion window is usually greater than 64K bytes in high-bandwidth/high-latency networks, the receive window is often the limiting factor if the application is submitting enough data.

В любой взятый момент времени количество данных, которые может переправлять протокол TCP, контролируется 3 факторами: https://en.wikipedia.org/wiki/… ion_window, RWIN и количество доступных к отправке байт. Без использования TCP window scaling (масштабирование RWIN) (по умолчанию отключено в WinXP и более ранних) максимум для RWIN — 64кб. Так как congestion window обычно больше 64кб в высокоскоростных подключениях, то обычно малый размер TCP Receive Window является тормозящим фактором для приложений, способных принимать большее количество данных (примерно, не уверен, что я правильно понял последние слова).

Эвристический метод масштабирования TCP Receive Window подразумевает (насколько я понял наших забугорных товарищей) самостоятельное, в соответствии с обстоятельствами (и местными тенденциями на Вашем ПК), управление Windows этим самым окном — RWIN или TCP Receive Window. Как утверждает
http://www.speedguide.net/faq/… tuning-339
Windows изменяет даже самостоятельно настроенные пользователем настройки. Этот вывод был сделан, когда

1

netsh int tcp show global

выдал ** The above autotuninglevel setting is the result of Windows Scaling heuristics

ИТОГО:
To prevent that behavior and turn off heuristics, before setting the TCP Receive Window auto-tuning level you should execute the following command (чтобы избавиться от такого поведения и отключить эвристический режим):

1

netsh int tcp set heuristics disabled

Note this should be executed in elevated command prompt (as administrator). If the command is accepted by the OS you should see an «Ok.» on a new line. (запускать под Админом, если все ОК, то Вы и увидите ОК)

Добавлено через 6 минут
Правда я не компетентен в этом, может профы подтянутся и объяснят. Как я все это понимаю, отключение эвристического метода запретит винде менять размеры принимающего окна взамен устанавливаемому Вами в autotuninglevel