Сеть и производительность на Windows VPS: почему «тормозит» не CPU, а TCP-стек и драйверы – и как это проверить

Автор:

Сценарий знакомый: арендуете Windows VPS, запускаете загрузку, копирование, прокачку трафика через API или прокси – и видите странную картину. Процессор по диспетчеру задач занят на 10-20%, диски не упираются, память с запасом, а сеть «как будто вязкая»: низкая скорость, рывки, высокий отклик, иногда таймауты.

Обычно в этот момент начинают «добавлять ядра» или менять тариф, хотя причина нередко вообще не в CPU как таковом. Часто узкое место – сетевой путь внутри ОС: обработка пакетов в ядре, настройки TCP, offload-функции, очереди, фильтрующие драйверы и особенности виртуализации. Разбираем это на примере типового Windows VPS (VDS Windows) – такой сервер можно быстро поднять у любого провайдера, например на VPS.house, чтобы воспроизвести проблему на чистой системе и сравнить результаты.

Эта статья – методика: как отличить ограничение канала от проблем стека TCP, как заметить упор в DPC/ISR и драйверы, где в виртуалке появляются дополнительные уровни, и какие инструменты в Windows реально дают ответ «кто виноват».

Почему «сеть тормозит», когда CPU вроде свободен

Сеть – это не только мегабиты в секунду. Это ещё и стоимость обработки каждого пакета: прерывания, DPC, работа NDIS, копирование буферов, расчёт контрольных сумм, сборка сегментов TCP, фильтрация (фаервол, VPN, антивирусные фильтры), плюс виртуальный коммутатор и виртуальная NIC в случае Hyper-V.

Из-за этого возможна парадоксальная картина:

• общая загрузка CPU низкая, но один логический процессор «горит» в ядре
• скорость «упирается» на маленьких пакетах (PPS), но на больших более-менее
• один поток скачивает медленно, а несколько потоков внезапно дают почти «паспортную» скорость
• внутри дата-центра всё хорошо, а в интернет – провалы из-за MTU/потерь/окна TCP

Поэтому правильный старт – не гадать, а измерять. И измерять отдельно: канал, задержку, потери, поведение TCP, нагрузку на обработку пакетов.

Шаг 1. Отделяем «канал» от «приложения» за 10 минут

Сначала ответьте на вопрос: медленно всё или только конкретный сценарий (SMB, RDP, HTTP, API, прокси, VPN)?

Минимальный набор тестов:

• iPerf3 (или аналог) до точки, которой вы доверяете. Желательно: один тест наружу (интернет) и один тест «рядом» (внутри той же площадки)
• RTT и потери: ping и pathping/трассировка до ключевого узла
• Один поток и несколько потоков: TCP может «не разогнаться» одним соединением по разным причинам (окно, потери, задержка, ограничения на стороне приложения)

Если у провайдера заявлен, например, порт 250 Мбит/с, а вы стабильно видите 30-60 Мбит/с даже на iPerf по нескольким потокам – почти наверняка вы упёрлись не в «скорость тарифа», а в обработку/настройки/потери.

Шаг 2. Проверяем здоровье TCP: окно, автонастройка и профили

В Windows ключевой момент для пропускной способности на соединениях с заметной задержкой – размер эффективного окна приёма (receive window) и его автонастройка. Если автонастройку кто-то отключил (часто это делают «оптимизаторы» или старые гайды), один поток может выглядеть как «вечный 2005-й» даже на хорошем канале.

Быстрая проверка глобальных параметров TCP:

netsh interface tcp show global

Что интересно смотреть в выводе:

• Receive Window Auto-Tuning Level – если disabled/restricted без причины, это кандидат номер один
• ECN Capability – сам по себе не зло и не добро, но в некоторых сетях/туннелях может вести к неожиданностям
• Chimney Offload и подобные исторические параметры – чаще важны для совместимости, чем для «ускорения»

TCP-шаблоны (templates) и supplemental-настройки (актуально на современных Windows Server):

netsh interface tcp show supplemental

Шаблоны влияют на набор параметров для разных сценариев (internet, datacenter и т.п.). В 2020-х это нормальный путь управления TCP, а не «магия реестра». Если у вас сервер под типичную интернет-нагрузку (web, API, прокси), убедитесь, что вы не уехали в странный кастом без понимания, зачем.

Проверка TCP-настроек через PowerShell (удобнее, чем netsh):

Get-NetTCPSetting | Select-Object SettingName, CongestionProvider, InitialCongestionWindowMss, MinRtoMs

Тут важна логика: вы не «выбираете самый быстрый алгоритм», вы проверяете, не включили ли вам что-то экзотическое, что конфликтует с вашим профилем трафика.

Шаг 3. Симптомы проблем в обработке пакетов: DPC/ISR и «один забитый core»

Самая частая причина «CPU низкий, а сеть не едет» в Windows – обработка сетевых прерываний и DPC на одном ядре. Диспетчер задач усредняет картину, а сеть может быть «пришита» к одному логическому процессору из-за отключённого RSS, ограничений очередей, особенностей виртуального адаптера или фильтров.

Что смотреть быстро:

• Диспетчер задач – вкладка CPU, включите отображение по логическим процессорам: есть ли ядро, которое заметно выше остальных именно во время сетевого теста
• Resource Monitor (resmon) – вкладка Network: нет ли тысячи мелких соединений/ретрансляций
• PerfMon – счётчики DPC/Interrupt (если вы любите точнее)

Полезные счётчики PerfMon (примерно):

• Processor / % DPC Time
• Processor / % Interrupt Time
• Network Interface / Packets Received Discarded
• Network Interface / Output Queue Length
• TCPv4 / Segments Retransmitted/sec

Если во время iPerf у вас растут ретрансляции и одновременно видно повышенное DPC/Interrupt – это уже не «просто провайдер режет скорость». Это либо потери/MTU/сеть, либо драйверно-стековая история.

RSS на Windows: почему без него трафик «липнет» к одному процессору

Receive Side Scaling (RSS) – механизм, который распределяет обработку входящего трафика по нескольким процессорам. Без RSS (или при его фактической недоступности) приём может концентрироваться на одном CPU, и он становится потолком по PPS и throughput. В виртуализации ситуация сложнее: есть RSS на хосте, есть vRSS/производные механизмы для VM, есть VMMQ.

Проверка RSS на адаптере в гостевой Windows:

Get-NetAdapterRss

Если RSS выключен или выглядит ограниченным, смотрите контекст:

• Внутри VM вы видите виртуальный адаптер – часть функций контролирует гипервизор
• В некоторых конфигурациях «включить» в госте недостаточно – ограничения на стороне хоста важнее

Попытка включить RSS (если это уместно и поддерживается):

Enable-NetAdapterRss -Name "Ethernet"

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

RSC, LSO и другие offload-функции: ускорители, которые иногда тормозят

У сетевого стека Windows есть целый набор аппаратных и программных «ускорителей». В идеале они снижают стоимость обработки пакетов и повышают throughput. В реальности любая offload-функция – это ещё и слой сложности: иногда в конкретной связке драйвера, vSwitch, туннеля или фильтра она ведёт к проблемам.

Коротко о главных:

• LSO (Large Send Offload) – TCP отдаёт драйверу большой буфер, а сегментацию до MTU делает NIC/драйвер
• RSC (Receive Segment Coalescing) – на приёме несколько TCP-сегментов могут склеиваться в крупные, чтобы стек обрабатывал меньше «единиц работы»
• Checksum Offload – расчёт контрольных сумм уходит в NIC/драйвер

В Hyper-V и современных Windows Server отдельного внимания заслуживает RSC в виртуальном коммутаторе (vSwitch) – механизм, который помогает снижать загрузку CPU хоста и повышать throughput виртуальных нагрузок. На стороне гостя вы можете не «видеть» всех деталей, но эффект (или проблема) проявляется в цифрах.

Проверка/управление RSC в гостевой системе (если доступно):

Get-NetAdapterRscGet-NetAdapterRss

Если вы столкнулись с нестабильностью или странными провалами скорости, временное точечное отключение конкретной offload-функции иногда помогает локализовать проблему. Но это не универсальный «ускоритель», а диагностический приём: отключили – померили – вернули как было, зафиксировали выводы.

Фильтры и «невидимые пассажиры» NDIS: VPN, антивирусы, traffic shaper

Ещё один частый источник «тормозов» на Windows VPS – фильтрующие драйверы. Это может быть антивирус с сетевой инспекцией, агент DLP, VPN-клиент, перехватчик трафика, WFP-фильтры. Они добавляют обработку на каждый пакет, а иногда ломают offload-цепочку или меняют MTU.

Что можно проверить без экзотики:

Get-NetAdapterBinding -Name "Ethernet"netcfg -s n

Смысл не в том, чтобы «снести всё», а в том, чтобы увидеть лишние компоненты на сетевом пути. На чистом сервере их обычно минимум. Если у вас их много, а проблема появилась «после установки агента», это сильная зацепка.

MTU и PMTU: когда «всё работает», но медленно и с ретрансляциями

Проблемы MTU редко выглядят как полный обрыв. Чаще это «подвисания», медленные загрузки, странные таймауты на отдельных сайтах, провалы скорости в одном направлении. Особенно если есть VPN, GRE/IPsec, туннели, прокси или нестандартный путь до клиента.

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

На практике диагностируют это сочетанием: ретрансляции в статистике TCP, трассировка, тесты ping с DF, захват пакетов.

Инструменты, которые реально отвечают на вопрос «где теряется скорость»

Pktmon: быстрый захват и поиск дропов внутри стека

Pktmon (Packet Monitor) полезен тем, что он «видит» не только интерфейс, но и события/дропы внутри компонентов сети Windows, и особенно хорош в виртуализационных сценариях.

Базовый сценарий:

pktmon start --etw -p 0REM воспроизведите проблему 30-60 секундpktmon stoppktmon format PktMon.etl -o pktmon.txt

Дальше вы смотрите, есть ли дропы, на каком компоненте, и коррелируете с моментом провала скорости.

netsh trace: «чёрный ящик» Windows для сетевой диагностики

Когда нужно собрать доказательства без установки сторонних снифферов, netsh trace умеет писать ETL с сетевыми событиями и (при необходимости) пакетным захватом.

netsh trace start scenario=InternetClient capture=yesREM воспроизведите проблемуnetsh trace stop

Результат – ETL, который удобно разбирать в Windows Performance Analyzer или отдавать в поддержку (в том числе поддержку провайдера, если вы пришли не с «у меня тормозит», а с конкретными фактами).

WPR/WPA: когда важно увидеть DPC, ISR и таймлайн событий

Если вы подозреваете, что упираетесь в обработку пакетов, лучше ETW-трассы и разбор в WPA ничего не покажет. WPR пишет ETL, WPA раскладывает это в графики: DPC/ISR, CPU, контекстные переключения, задержки, сетевые события.

Принцип такой: записали короткую трассу (1-2 минуты) ровно во время воспроизведения проблемы, затем открыли в WPA и нашли, какой драйвер или цепочка событий съедает время. Это уже уровень «экспертной диагностики», но он окупается, когда вы не хотите лечить симптомами.

Практический чек-лист: что проверять в первую очередь

1. Однопоток против многопотока: один TCP-поток медленный, несколько нормальные – смотрим окно TCP, потери, RTT
2. netsh interface tcp show global: не отключена ли автонастройка окна и нет ли странных глобальных ограничений
3. netsh interface tcp show supplemental: какой шаблон реально активен, нет ли «кастома из прошлого»
4. Get-NetTCPSetting: проверьте, не включён ли неожиданный congestion provider в custom-шаблоне
5. RSS: Get-NetAdapterRss, распределяется ли обработка, нет ли упора в один core
6. DPC/Interrupt: во время нагрузки смотрите ядра и PerfMon-счётчики
7. Ретрансляции: TCPv4 Segments Retransmitted/sec, netstat -s, Get-NetTCPStatistics
8. Дропы интерфейса: Packets Discarded, ошибки, Output Queue Length
9. Фильтры NDIS/WFP: что навешано на адаптер, что появилось «перед тем, как стало плохо»
10. MTU: особенно если есть VPN/туннели/прокси или «падает только на некоторых направлениях»
11. Трасса pktmon: есть ли дропы внутри стека
12. netsh trace или WPR: когда нужен ответ уровня «вот компонент, вот время, вот корреляция»

Зачем иногда полезно поднять второй сервер рядом и проверить по приватной сети

Большая часть споров «это провайдер» против «это Windows» решается простым приёмом: сравните два пути.

• Путь А – тест наружу (ваш офис/дом/другая площадка)
• Путь Б – тест до второго VPS в той же площадке, лучше по приватной сети, если провайдер её даёт

Если по приватной сети два сервера легко выдают ожидаемые цифры, а наружу начинается деградация – вы сузили зону поиска до внешнего пути, MTU, конкретных провайдеров, фильтрации или потерь. Если же и «внутри» всё плохо, тогда фокус на драйверах, очередях, RSS/RSC и на конфигурации виртуализации.

Именно для такой диагностики удобно иметь возможность быстро поднять пару машин на Windows Server, прогнать тесты и снести. На практике проще всего это делать через посуточную аренду VPS Windows на VPS.house – просто чтобы получить чистую лабораторию рядом с продом и сравнить поведение один в один.

Выводы

«Сеть тормозит» на Windows VPS часто означает не «мало ядер» и не «плохой процессор», а то, что сетевой путь внутри ОС работает неоптимально или нестабильно: автонастройка окна TCP, масштабирование приёма (RSS и производные), offload-механизмы, фильтрующие драйверы, MTU, потери, особенности vSwitch.

Хорошая новость в том, что это диагностируется: сперва отделяем канал от приложения, затем смотрим TCP и масштабирование, после чего собираем трассу (pktmon/netsh trace/WPR) и получаем факты, а не ощущения. В результате вы либо чините конкретную настройку/компонент, либо приходите к провайдеру с точным описанием, где именно по цепочке возникает проблема.