Знайдіть, що споживає пропускну здатність у Windows (без сумнівних програм)

Хтось завжди «просто завантажує файл», і раптом ваша розмова в Teams перетворюється на пантоміму.
Найгірше не сама повільність — а невпевненість. Це оновлення Windows? OneDrive? Вкладка браузера, яка вийшла з-під контролю?
Або ваш ПК тихо виконує корпоративні задачі у фоновому режимі?

Ось як знайти «поїдача» пропускної здатності використовуючи лише вбудовані інструменти Windows. Жодних загадкових інсталяторів. Жодних «безкоштовних прискорювачів мережі».
Лише те, що вже є — і вміння правильно це інтерпретувати.

Швидкий план діагностики

Ви відповідальні за свій ноутбук. Часу на мережеву філософію немає.
Ось порядок дій, що дає швидкі відповіді з мінімальною метушнею.

1) Підтвердіть, що проблема на вашому ПК, а не в мережі

• Якщо повільно у всьому будинку/офісі — зупиніться. Ваш Windows не «їсть» трафік, канал виходу перегружений.
  Спочатку перевірте стан роутера/провайдера.
• Якщо повільно лише на вашому ПК — продовжуйте.

2) Визначте топ-процес за мережевим ввід/виводом

• Диспетчер завдань → Процеси → сортуйте за Мережа.
• Якщо це звичайний додаток (браузер, OneDrive): зазвичай цього достатньо; вирішіть, зупинити, обмежити чи запланувати його.
• Якщо це Service Host або «System»: перейдіть у Resource Monitor та netstat, щоб знайти справжню службу/підключення.

3) Вирішіть: проблема через пропускну здатність чи через затримки?

• Якщо щось тягне 50–500 Мбіт/с і ваша розмова обривається — це питання пропускної здатності.
  Вирішіть, зупинивши/обмеживши/перепланувавши процес, або встановивши ліміт для вимірюваного підключення / Delivery Optimization.
• Якщо стовпець «Мережа» низький, але все «видається» повільним — шукайте DNS, втрати пакетів, цикли автентифікації проксі або повторні відправлення.
  Resource Monitor та лічильники допоможуть тут.

4) Прив’яжіть трафік до віддаленого кінця

• Використовуйте Resource Monitor (TCP Connections) або netstat -b/netstat -ano.
• Віддалена IP/порт підкаже, чи ви спілкуєтеся з Microsoft CDN, корпоративним проксі чи чимось дивним.

5) Застосуйте найменш ризиковане виправлення

• Віддавайте перевагу обмеженню та плануванню над вбивством процесів.
  Пропускна здатність — спільний ресурс; стабільність — справжній SLO.
• Якщо трафік керується корпоративно (оновлення, агент безпеки): координуйте дії замість «вбивати» поодинці.

Одна цитата, яку я ношу з собою роками, бо вона — єдине протиотрута для «я впевнений, що це Х»:
В операціях вам не зарахують здогадки; вам зарахують вимірювання.
(парафраз ідеї, пов’язаної з якісною інженерією за Демінгом)

Спочатку визначте реальний стан (і не обманюйте себе)

Скарги на «пропускну здатність» зазвичай означають одне з трьох:

1. Справжня насиченість: процес споживає велику частку вашого аплінку/даунлінку.
2. Збільшена затримка: затримки DNS, проксі-цикли, втрата пакетів, повторні передачі, bufferbloat. Пропускна здатність може бути нормальна.
3. Контенція на рівні додатків: VPN-тунель, інспекція агентом безпеки або оркестрація оновлень викликають затримки.

Якщо ви не розрізняєте це, то «вилікуєте» не ту проблему. Також отримаєте корпоративний класик:
хтось вимикає VPN, щоб «підвищити продуктивність», а потім дивується, чому внутрішні додатки не працюють. Справжня загадка століть.

Ваша мета — відповісти з доказами:

• Який процес передає дані?
• Яка служба (якщо це хост-процес на кшталт svchost.exe)?
• Який віддалений кінцевий пункт (домен/IP/порт)?
• Чи це постійний потік чи спорадичний?
• Біль у вигляді пропускної здатності чи затримки/втрат?

Завдання 1–2: Почніть із Диспетчера завдань (він кращий, ніж ви пам’ятаєте)

Завдання 1: Відсортуйте за Мережею в Диспетчері завдань

Диспетчер завдань — це не глибинний аналіз пакетів, але найшвидший спосіб знайти очевидних порушників.
Якщо тут очевидний топ-талкер — не ускладнюйте зайвого.

cr0x@server:~$ taskmgr.exe
...Task Manager opens. Go to Processes, click the Network column to sort...

На що звертати увагу:

• Одиночний процес із постійними Мбіт/с. Браузери, OneDrive, Teams, Steam, Windows Update — часті винуватці.
• Якщо верхній рядок — Service Host: … або System, потрібен наступний інструмент для уточнення.

Рішення:

• Якщо це користувацький додаток: закрийте його, паузуйте завантаження або заплануйте. Підтвердіть покращення.
• Якщо це хост/системний процес: переходьте до Resource Monitor.

Завдання 2: Використайте Історію додатків для «смерті від тисячі фоновых передач»

Деякі проблеми з трафіком — це не один великий потік, а десятки дрібних фонових. Історія додатків дає довший погляд.

cr0x@server:~$ cmd /c "start ms-settings:datausage"
...Settings opens at Data usage; inspect per-app usage for the last 30 days...

Що означає вихід:

• Якщо один додаток має шокуюче велике використання за часом, це постійний внесок, а не одноразовий сплеск.
• Якщо домінує «System», ймовірно це оновлення, Delivery Optimization або VPN/проксі-накладення.

Рішення:

• Високе використання OneDrive/Dropbox: перевірте налаштування синхронізації, вибіркову синхронізацію, обмеження завантаження.
• Високе використання «System»: не гадати; ідентифікуйте службу через Resource Monitor і відображення служб.

Завдання 3–4: Resource Monitor для сокетів процесів і підказок про затримки

Resource Monitor — недооцінений скарб. Він показує процеси, підключення та порти прослуховування в одному місці.
Він негарний. Але ефективний. Як хороший SRE.

Завдання 3: Відкрийте Resource Monitor і перегляньте вкладку Network

cr0x@server:~$ resmon.exe
...Resource Monitor opens. Go to the Network tab...

Що перевіряти:

• Процеси з мережею: показує швидкості відправки/отримання по процесах.
• Network Activity: деталі файлів і кінцевих точок (для деяких процесів).
• TCP Connections: основна інформація — локальна/віддалена адреса, порт і затримка.

Рішення:

• Якщо процес має кілька підключень до одного діапазону віддалених IP (CDN), швидше за все він завантажує оновлення/контент.
• Якщо багато короткоживих підключень і висока затримка — підозрюйте DNS/проксі/автентифікацію, а не сирий трафік.

Завдання 4: Відфільтруйте підозрілий процес і запишіть його віддалені кінцеві точки

У Resource Monitor поставте галочку біля підозрюваного процесу. Нижні таблиці автоматично відфільтруються.
Запишіть віддалені адреси та порти.

cr0x@server:~$ cmd /c "echo Use Resource Monitor: tick the process checkbox; then read Remote Address/Port in TCP Connections."
Use Resource Monitor: tick the process checkbox; then read Remote Address/Port in TCP Connections.

Що це означає:

• Віддалений порт 443: HTTPS (більшість сучасного трафіку). Тут ви побачите лише IP-адреси, не домени.
• Віддалений порт 80: HTTP (рідше, часто застаріле або внутрішнє).
• Віддалений порт 53: DNS (якщо щось б’є DNS масово — це симптом).
• Віддалений порт 123: NTP синхронізація часу (мало, але часто).

Рішення:

• Якщо віддалені кінцеві точки схожі на Microsoft/CDN і процес пов’язаний з оновленнями: дивіться секцію про Windows features.
• Якщо кінцеві точки внутрішні/корпоративні проксі: підозрюйте цикли проксі, VPN або агенти безпеки.

Завдання 5–6: netstat + відображення PID (класика, що все ще працює)

Коли GUI замовчує, netstat дає вам істину сокетів. Це не гламурно, але як і продакшен — практично.

Завдання 5: Перелічіть встановлені підключення з PID

cr0x@server:~$ cmd /c "netstat -ano | findstr ESTABLISHED"
TCP    192.168.1.50:51322   52.96.12.34:443      ESTABLISHED     4960
TCP    192.168.1.50:51340   13.107.6.171:443     ESTABLISHED     1348
TCP    192.168.1.50:51355   142.250.72.206:443   ESTABLISHED     17824

Що означає вихід:

• Останній стовпець — PID. Це ваш ключ, щоб ідентифікувати процес-власник.
• Якщо багато встановлених підключень до багатьох віддалених IP, процес може бути браузером, апдейтером або інструментом синхронізації.

Рішення:

• Візьміть кілька верхніх PID і зіставте їх із іменами процесів.

Завдання 6: Зіставте PID із процесом і командним рядком

cr0x@server:~$ cmd /c "tasklist /fi "PID eq 4960" /v"
Image Name                     PID Session Name        Session#    Mem Usage Status          User Name          CPU Time Window Title
msedge.exe                     4960 Console                    1    350,000 K Running         CORP\alice         0:12:41  Project - Edge

Tasklist дає ім’я і підказку. Для реальної відповіді подивіться командний рядок (особливо для
svchost.exe, браузерів з кількома профілями й корпоративних агентів).

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_Process -Filter 'ProcessId=4960' | Select-Object ProcessId,Name,CommandLine | Format-List"
ProcessId  : 4960
Name       : msedge.exe
CommandLine: "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --profile-directory=Default

Рішення:

• Якщо командний рядок вказує на апдейтер/планувальник: часто можна безпечно призупинити його.
• Якщо це корпоративний агент: не вбивайте його одразу. Знайдіть налаштування політики та розкладу.

Завдання 7–9: PowerShell для адаптерів, маршрутів і моменту «чому DNS повільний?»

Проблеми з «пропускною здатністю» часто походять від неправильного інтерфейсу, неправильного маршруту або зламаного розв’язування імен.
PowerShell дає відтворювані докази, які можна скопіювати й надіслати в IT без звинувачень.

Завдання 7: Перевірте, який інтерфейс фактично використовується (і яка швидкість лінка)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Sort-Object -Property Status,LinkSpeed -Descending | Format-Table -Auto Name,Status,LinkSpeed,MacAddress"
Name          Status  LinkSpeed   MacAddress
Ethernet      Up      1 Gbps      00-11-22-33-44-55
Wi-Fi         Down    0 bps       AA-BB-CC-DD-EE-FF

Що це означає:

• Якщо Ethernet «Up» на 100 Мбіт, хоча ви чекали 1 Гбіт — можлива проблема з кабелем/переговорами комутатора.
• Якщо Wi‑Fi підключений на низькій швидкості — ви могли опинитися на 2.4 ГГц, далеко від точки доступу або під завадою.

Рішення:

• Виправляйте фізичний/канальний рівень перед пошуком процесів. Насичений 100 Мбіт канал зробить звичайні фонові задачі підозрілими.

Завдання 8: Визначте DNS-сервери і чи використовуєте щось дивне

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -Auto InterfaceAlias,ServerAddresses"
InterfaceAlias ServerAddresses
Ethernet        {10.10.0.10, 10.10.0.11}

Що це означає:

• Корпоративний DNS нормальний при роботі через VPN. Публічний DNS на корпоративному пристрої може бути нормальним або порушенням політики. Знайте своє середовище.
• Невідповідний DNS (неправильні сервери, недоступні сервери) викликає «усе повільно» без великого використання пропускної здатності.

Рішення:

• Якщо DNS-сервери неправильні або недоступні — виправте DNS перш ніж звинувачувати «пропускну здатність».

Завдання 9: Швидко виміряйте затримку DNS і помилки

cr0x@server:~$ powershell -NoProfile -Command "Measure-Command { 1..10 | ForEach-Object { Resolve-DnsName -Name microsoft.com -Type A | Out-Null } } | Select-Object TotalMilliseconds"
TotalMilliseconds
-----------------
842

Що це означає:

• Менше секунди для 10 запитів — нормально в багатьох середовищах (з урахуванням кешування).
• Якщо це триває кілька секунд або випадають помилки — ви знайшли проблему затримки, що імітує дефіцит пропускної здатності.

Рішення:

• Виправляйте DNS (доступність серверів, split DNS у VPN, політику резольверів) замість спроб «обмежити завантаження».

Завдання 10–12: лічильники Performance Monitor, які справді важливі

PerfMon старий і має свої уподобання щодо шрифтів, але він досі один із найкращих способів
побачити, чи ви насичуєте інтерфейс або тонете в повторних відправленнях і чергах.

Завдання 10: Визначте ім’я мережевого інтерфейсу, яке використовують лічильники

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter -ListSet 'Network Interface' | Select-Object -ExpandProperty Paths | Select-Object -First 8"
\\DESKTOP-7Q9K\Network Interface(Intel[R] Ethernet Connection)\Bytes Received/sec
\\DESKTOP-7Q9K\Network Interface(Intel[R] Ethernet Connection)\Bytes Sent/sec
\\DESKTOP-7Q9K\Network Interface(Intel[R] Ethernet Connection)\Output Queue Length
\\DESKTOP-7Q9K\Network Interface(Intel[R] Ethernet Connection)\Packets Outbound Errors
\\DESKTOP-7Q9K\Network Interface(Intel[R] Ethernet Connection)\Packets Received Errors

Що це означає:

• Інстанси лічильників містять рядок моделі адаптера. Вам потрібен правильний, якщо є VPN, Wi‑Fi, Ethernet, віртуальні комутатори.

Рішення:

• Виберіть релевантний інтерфейс і заміряйте кілька ключових лічильників під час вікна «повільно».

Завдання 11: Заміряйте bytes/sec і довжину черги 30 секунд

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Network Interface(Intel[R] Ethernet Connection)\Bytes Total/sec','\Network Interface(Intel[R] Ethernet Connection)\Output Queue Length' -SampleInterval 1 -MaxSamples 10 | Select-Object -ExpandProperty CounterSamples | Select-Object Path,CookedValue | Format-Table -Auto"
Path                                                                 CookedValue
----                                                                 -----------
\\...\Bytes Total/sec                                                8234512
\\...\Output Queue Length                                            0
\\...\Bytes Total/sec                                                9123301
\\...\Output Queue Length                                            0

Що це означає:

• Bytes Total/sec показує реальну пропускну здатність. Орієнтовно в Мбіт: bytes/sec × 8 ÷ 1,000,000.
• Output Queue Length постійно вище 0 може вказувати на перевантаження/буферні проблеми (контекст важливий на сучасних драйверах).

Рішення:

• Якщо ви довго близькі до пропускної здатності лінка — потрібне політичне рішення щодо пропускної здатності (обмеження/розклад), а не полювання на винуватця.
• Якщо черги великі, але пропускна здатність низька — підозрюйте проблеми драйвера, повторні спроби Wi‑Fi або upstream-стиснення.

Завдання 12: Спостерігайте TCP повторні відправлення (втрата, що маскується під «повільний інтернет»)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\TCPv4\Segments Retransmitted/sec','\TCPv4\Segments/sec' -SampleInterval 1 -MaxSamples 10 | Select-Object -ExpandProperty CounterSamples | Group-Object Path | ForEach-Object { $_.Group | Select-Object -First 1 } | Format-Table -Auto"
Path                                   CookedValue
----                                   -----------
\\DESKTOP-7Q9K\TCPv4\Segments/sec       18500
\\DESKTOP-7Q9K\TCPv4\Segments Retransmitted/sec 240

Що це означає:

• Повторні відправлення трапляються. Багато повторних відправлень, постійно, означає втрату або сильну затримку. Це вбиває інтерактивні додатки.
• Якщо повтори стрибають на Wi‑Fi, але не на Ethernet — проблема очевидна без звинувачення Windows Update.

Рішення:

• Проблема втрат: змініть середовище (Ethernet), покращіть сигнал, зменшіть завади, оновіть драйвер/прошивку, перевірте MTU VPN.

Звичні підозрювані: Windows Update, Delivery Optimization, OneDrive, Store, Defender

Якщо ви в корпоративному середовищі, Windows — не «просто ОС». Це платформа з системою розповсюдження контенту,
захистом кінцевих точок, звітністю й синхронізацією. У багатьох організаціях це не опція.
Ваше завдання — зробити їх передбачуваними.

Delivery Optimization (DoSvc): peer-to-peer і «чому зайнятий аплінк?»

Delivery Optimization — вбудована функція розповсюдження контенту в Windows. Вона може завантажувати оновлення від Microsoft
і, за політикою, від пірів у локальній мережі або навіть з інтернету. Сторона завантаження (upload) часто дивує.

cr0x@server:~$ powershell -NoProfile -Command "Get-Service DoSvc | Format-List Name,Status,StartType,DisplayName"
Name       : DoSvc
Status     : Running
StartType  : Manual
DisplayName: Delivery Optimization

Що це означає:

• Якщо служба запущена під час уповільнення — вона може активно передавати контент.
• Запуск вручну не означає «неактивна». Windows запускає її за потреби.

Рішення:

• У корпоративному середовищі не вимикайте її бездумно — політика може на неї покладатися. Краще обмежити її.

Щоб переглянути поведінку Delivery Optimization (підтримується вбудовано):

cr0x@server:~$ powershell -NoProfile -Command "Get-DeliveryOptimizationStatus | Select-Object -First 5 | Format-Table -Auto"
FileId                               SourceURL                          BytesDownloaded BytesUploaded PeerCaching
------                               ---------                          -------------- ------------- -----------
{A1B2C3D4-...}                        https://...                        104857600       5242880       True

Що це означає:

• Показує завантаження/завантаження, що належать Delivery Optimization.
• Якщо BytesUploaded немалий і у вас обмежений аплінк — ось відповідь на питання «чому аплінк зайнятий?»

Рішення:

• Встановіть обмеження пропускної здатності через Налаштування або політику. Якщо ви власник пристрою — використовуйте Налаштування. Якщо IT керує — попросіть змінити політику.

Windows Update (wuauserv): великі завантаження, невдалий час

cr0x@server:~$ powershell -NoProfile -Command "Get-Service wuauserv,BITS | Format-Table -Auto Name,Status,StartType,DisplayName"
Name     Status  StartType DisplayName
----     ------  --------- -----------
wuauserv Running Manual    Windows Update
BITS     Running Manual    Background Intelligent Transfer Service

Що це означає:

• BITS — «ввічлива» служба фонових передач, але «ввічлива» контекстуальна. Вона може нашкодити дзвінку на малому аплінку.
• Windows Update також може використовувати Delivery Optimization залежно від налаштувань/політики.

Рішення:

• Правильно налаштуйте Active Hours і розгляньте вимірюване підключення, якщо ви на хотспоті.
• У підприємстві: переконайтеся в наявності update rings і вікон обслуговування, інакше ви отримаєте випадкові денні сплески.

OneDrive: хвилі синхронізації справжні

OneDrive зазвичай чемний, поки раптом не перестає бути: великі переміщення папок, CAD-ресурси, PST-файли
або користувач, який «перегруповує» спільну папку перетягуванням.

cr0x@server:~$ powershell -NoProfile -Command "Get-Process OneDrive -ErrorAction SilentlyContinue | Select-Object Name,Id,CPU,Path | Format-Table -Auto"
Name    Id    CPU Path
----    --    --- ----
OneDrive 7324  88 C:\Users\alice\AppData\Local\Microsoft\OneDrive\OneDrive.exe

Що це означає:

• Якщо OneDrive активний і Диспетчер завдань показує мережеву активність — ймовірно йде синхронізація.

Рішення:

• Призупиніть синхронізацію під час дзвінків. Налаштуйте ліміти завантаження/завантаження, якщо часто обмежені.

Microsoft Store / оновлення додатків

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

cr0x@server:~$ powershell -NoProfile -Command "Get-Service InstallService | Format-List Name,Status,StartType,DisplayName"
Name       : InstallService
Status     : Running
StartType  : Manual
DisplayName: Microsoft Store Install Service

Рішення:

• Якщо оновлення Store повторюються вдень — вимкніть автооновлення через політику (в підприємстві) або налаштуйте Store (особисто).

Microsoft Defender і засоби безпеки: сканування може викликати мережеву активність

Defender зазвичай не «жере» трафік, але стеки безпеки можуть виконувати хмарні запити, перевірки репутації і телеметрію.
«Свиня» може виявитися корпоративним агентом, а не Windows.

cr0x@server:~$ powershell -NoProfile -Command "Get-Process | Where-Object { $_.ProcessName -match 'MsMpEng|Sense|Crowd|Carbon|Sentinel' } | Select-Object ProcessName,Id,CPU | Sort-Object CPU -Descending | Format-Table -Auto"
ProcessName Id    CPU
----------- --    ---
MsMpEng     4100  120

Рішення:

• Якщо агент виконує важку роботу у робочий час — вирішення через розклад та політику; не поспішайте вбивати процеси.

Жарт #1: Якщо встановити «оптимізатор пропускної здатності», ваш ПК стане швидшим — прямо в новий інцидент.

Коли «свиня» — svchost.exe: безпечно знімаємо маску

svchost.exe — це хост служб, а не «програма» у звичному розумінні. Багато служб Windows запускаються в ньому.
Якщо svchost споживає трафік, ваша задача — ідентифікувати яку саме службу всередині нього.

Завдання: Зіставте PID svchost до розміщених служб

cr0x@server:~$ cmd /c "tasklist /svc /fi "imagename eq svchost.exe""
Image Name                     PID Services
svchost.exe                   1348 BITS, wuauserv
svchost.exe                   1720 DoSvc
svchost.exe                   1020 Dhcp, NlaSvc

Що це означає:

• Тепер можна з’єднати факти: якщо PID 1720 говорить з багатьма віддаленими 443-ендпойнтами і в ньому є DoSvc — це історія Delivery Optimization.
• Якщо це DHCP/NLA — зазвичай не великоваговий трафік, але може вказувати на мережеві збої (що породжує інший трафік).

Рішення:

• Для BITS/wuauserv/DoSvc: застосуйте обмеження та розклад для оновлень/DO.
• Для незвичних служб: розберіться, що вони роблять перед відключенням. «Вимикання випадкових служб» — не стратегія, а хобі.

Три корпоративні міні-історії з практики

Міні-історія 1: Інцидент через хибне припущення

Середня компанія розгорнула новий образ Windows 11 на кількох сотнях ноутбуків. Через тиждень черга звернень заповнилася
заявками «Wi‑Fi непридатний», здебільшого близько 9–11 ранку. Перше припущення було класичне: «Провайдер має проблеми».
Це припущення тривало, поки хтось не помітив, що в сусідньому офісі (інший орендар, той самий провайдер) все гаразд.

Друге припущення було більш впевненим: «Це Teams». Користувачі були на дзвінках, дзвінки були погані — додаток звинуватили.
Радили вимкнути HD-відео і використовувати лише аудіо. Це трохи допомогло, і всім стало здаватись, що вони розумні,
але це не вирішило основну проблему й зробило зустрічі некомфортними. Часткова міра — все ще поразка, якщо розслідування зупинено.

Реальна причина виявилася відразу, як тільки хтось відкрив Resource Monitor на проблемному комп’ютері:
svchost.exe передавав багато даних, а netstat показував довготривалі сесії 443 до IP-діапазонів Microsoft.
Відображення PID на служби вказало на DoSvc і BITS. Delivery Optimization була налаштована (за «дружніми» значеннями)
для дозволу завантажень від пірів у LAN. В офісі з тонкими аплінками та новими образами це означало постійний трафік.

Виправлення не полягало у відключенні оновлень. Налаштували Delivery Optimization на LAN-only (або вимкнули peer upload),
обмежили фонову пропускну здатність у робочий час і розтягнули завантаження через вікна обслуговування.
Дзвінки повернулися до нормального стану. Helpdesk припинив діагностувати «погоду».

Урок: «Проблема з ISP» — зручне припущення, бо не вимагає дій. Часто воно хибне.

Міні-історія 2: Оптимізація, яка повернулась бумерангом

Команда прагнула зменшити WAN-трафік для віддалених сайтів. Їхня яскрава ідея:
агресивне кешування і peer-to-peer дистрибуція оновлень скрізь. Намір був правельний — економія на CDN egress,
і Windows підтримує розподілений контент. Проблема — ігнорування обмеження: асиметрія аплінків.

У маленьких філіях швидкість завантаження була пристойна, але аплінк крихітний. Peer upload означав, що щойно один ПК отримав оновлення,
він став міні-сервером контенту на з’єднанні ледь придатному для відправки листів. Коли колега працював — «інтернет вмирав».
Той колега ні в чому не винен; він став жертвою політики.

Мережна команда додала правила QoS для пріоритезації голосу. Це допомогло, але додало складності та непослідовної поведінки по моделях обладнання.
Деякі точки доступу застосовували маркування, деякі — ні. Тим часом кінцеві пристрої продовжували віддавати контент.
«Оптимізація» перетворилася на постійні операційні витрати.

Згодом замінили загальну політику на рівневі налаштування: великі сайти — peer distribution дозволено; малі — заборонено.
Також встановили агресивні ліміти на завантаження і жорсткі вікна оновлень. Споживання трафіку не зникло, але стало передбачуваним.
Передбачуване завжди краще за «здивування».

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Фінансовий відділ мав процес закриття місяця. Щомісяця одне і те ж: паніка і скарги на повільну мережу.
IT команда не панікувала; у них була нудна звичка: щотижня знімати легкий базовий зріз за вбудованими лічильниками
і зберігати короткий PowerShell-скрипт у спільному runbook.

Коли з’явилася скарга, вони вже знали, як виглядає «норма»: типові bytes/sec на головному інтерфейсі,
типовий рівень повторних відправлень на Wi‑Fi і топ фоновых служб. У них також був чекліст, що починався з:
«Ми насичені чи у нас велика затримка?» Відповідь була миттєвою — пропускна здатність не була надто високою, але повтори стрибнули.

Вони обійшли офіс і знайшли новий немережевий комутатор, підключений у порт аплінку, що створив петлю.
Мережа тонула у широкомовному трафіку і повторах, а не в «програмах, що їдять трафік». Видалили комутатор,
повтори впали, і все відновилося. Жодного героїчного дебагу. Просто база + метод.

Ось сенс нудної практики: вона скорочує час розв’язання захоплюючих проблем.

Цікавинки та історичний контекст

• PerfMon старіше більшості «сучасних» інструментів спостереження. Лічильники продуктивності Windows існують ще з ери NT і досі першокласні.
• BITS створено для «ввічливих» передач. Він намагається використовувати вільну пропускну здатність, але «вільна» — не універсальна істина, особливо на асиметричних каналах.
• Консолідація svcchost була ресурсною стратегією. Хостинг кількох служб зменшував накладні витрати, але ускладнив атрибуцію до появи кращих інструментів.
• Delivery Optimization — це, по суті, система розподілу контенту. Ідея не нова — CDN та peer distribution існують десятиліттями, але тепер це вбудовано в ОС.
• Windows давно відокремлює користувацькі додатки від інфраструктурних служб. Саме тому «System» і «Service Host» з’являються в списках: багато роботи відбувається нижче рівня додатків.
• TCP повторні відправлення — прихований вбивця «швидких» лінків. Ви можете мати хороший рівень сигналу і все одно страждати від завад або bufferbloat.
• Metered connections додали через несподівані рахунки. Windows поступово навчився, що не всі мережі безлімітні.
• Netstat старіший за більшість проблем, які він діагностує. Він залишається корисним, бо сокети — джерело істини для підключень.

Типові помилки: симптом → причина → виправлення

Цей розділ відвертий. Більшість розслідувань пропускної здатності йдуть неправильно, бо люди сприймають симптоми як діагноз.

1) «Якість дзвінка жахлива» → «Вина пропускна здатність» → Насправді втрата пакетів/повтори Wi‑Fi

• Симптом: Дзвінки заїкаються, але Диспетчер завдань показує низьке мережеве навантаження.
• Причина: Втрата/повторні відправлення, завади, поганий драйвер або перевантажений AP.
• Виправлення: Перевірте лічильники повторних відправлень TCP; спробуйте Ethernet; оновіть драйвер Wi‑Fi; підберіться ближче до AP; перейдіть на 5 GHz/6 GHz; перевірте MTU VPN.

2) «Аплінк завантажений, але я нічого не завантажую» → Peer upload Delivery Optimization

• Симптом: Апаратний аплінк зайнятий, особливо після Patch Tuesday або образування пристроїв.
• Причина: DoSvc завантажує оновлення на піри (політично зумовлено).
• Виправлення: Використайте Get-DeliveryOptimizationStatus; обмежте upload; вимкніть peer upload там, де недоречно; встановіть вікна оновлень.

3) «Все повільно» → «Провайдер поганий» → Насправді DNS/проксі-цикли

• Симптом: Сторінки підвисають на початку, завантаження не стартує, додатки «липкі».
• Причина: Повільні відповіді DNS, зламаний split DNS у VPN, проксі-цикли автентифікації які генерують багато дрібних запитів.
• Виправлення: Виміряйте час DNS через PowerShell; перевірте DNS-сервери; перевірте налаштування проксі та облікові дані; перегляньте Event Viewer при потребі.

4) «svchost використовує трафік» → «Вбити його» → Потім Windows працює дивно

• Симптом: Service Host на вершині стовпця Мережа.
• Причина: Одна з багатьох служб (BITS/wuauserv/DoSvc) виконує легітимну роботу.
• Виправлення: Зіставте PID зі службами за допомогою tasklist /svc; відрегулюйте налаштування/політику; уникайте вбивства важливих хостів.

5) «Ми обмежимо пропускну здатність QoS і все» → Оптимізація повернулась бумерангом

• Симптом: Деякі користувачі покращились, інші — гірше; поведінка залежить від пристрою/AP.
• Причина: QoS застосовано непослідовно, або ліміти встановлено для невірного класу трафіку; про асиметрію аплінків забули.
• Виправлення: Почніть з атрибуції на кінці та здорового розкладу; потім застосовуйте QoS як цілеспрямований контроль, а не заміну діагностиці.

Контрольні списки / покроковий план

Чекліст A: «Щось зараз їсть пропускну здатність» (10 хвилин)

1. Диспетчер завдань → сортуйте за Мережею. Занотуйте топ-3 процеси.
2. Відкрийте Resource Monitor → вкладка Network → відфільтруйте підозрілий процес → запишіть віддалені IP/порти.
3. Запустіть netstat -ano і зіставте топ-PID з процесами/командними рядками.
4. Якщо це svchost.exe: зіставте PID з службами за допомогою tasklist /svc.
5. Якщо це пов’язане з оновленнями: перевірте DoSvc/BITS/wuauserv і статус Delivery Optimization.
6. Застосуйте найменш ризикований контроль: пауза синхронізації, тимчасова пауза оновлень, вимірюване підключення або обмеження DO.

Чекліст B: «Відчуття повільності, але числа низькі» (15 хвилин)

1. Перевірте адаптер і швидкість лінка (Get-NetAdapter).
2. Виміряйте DNS-перформанс (Resolve-DnsName в циклі + Measure-Command).
3. Перевірте лічильники повторних відправлень TCP (Get-Counter).
4. Якщо Wi‑Fi: перевірте по Ethernet або хотспоту, щоб ізолювати RF-проблему від upstream.
5. Якщо VPN: перевірте політику split tunneling і DNS-сервери; шукати симптоми MTU (часткове завантаження сайтів, великі завантаження зависають).

Чекліст C: «Щоб цього не повторилося» (постійно)

1. Реалістично налаштуйте вікна оновлень/Active Hours.
2. Налаштуйте обмеження Delivery Optimization для вашого аплінку.
3. Відрегулюйте область синхронізації OneDrive (selective sync) та обмеження пропускної здатності.
4. Щотижня фіксуйте ключові лічильники: bytes/sec, retransmits/sec, Wi‑Fi link rate.
5. Документуйте «очікуваних топ-токерів» у вашому середовищі (агент, VPN-клієнт, патчинг).

Жарт #2: Мережа ніколи не «вимкнена». Вона просто взяла незаплановану відпустку кар’єри.

Більше практичних завдань (з командами, значенням і рішеннями)

У вас вже є 12 завдань вище. Ось додаткові, які окупаються в заплутаних середовищах — особливо корпоративних.
Використовуйте їх, коли очевидні перевірки не дають чистої відповіді.

Завдання: Показати активні TCP-підключення з іменем процесу (потребує адміністратора для -b)

cr0x@server:~$ cmd /c "netstat -abno | more"
...Shows connections plus the executable involved; may prompt for elevation...

Що це означає: -b додає ім’я бінарного файлу. Це може показати, який допоміжний виконуваний файл справді встановлює з’єднання.

Рішення: Якщо бінарник несподіваний (апдейтер, хелпер, агент) — знайдіть його батьківський додаток і перевірте розклад/налаштування.

Завдання: Перевірити, які процеси прослуховують порти (корисно для «чому порт відкритий?»)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -State Listen | Select-Object -First 10 | Format-Table -Auto LocalAddress,LocalPort,OwningProcess"
LocalAddress LocalPort OwningProcess
------------ --------- -------------
0.0.0.0      445       4
0.0.0.0      135       988
127.0.0.1    49664     1020

Що це означає: Порти в режимі прослуховування не є використанням пропускної здатності, але допомагають ідентифікувати служби (SMB, RPC, локальні проксі), що можуть корелювати з трафіком.

Рішення: Якщо бачите локальний проксі або незвичний listener — перевірте, чи браузер/VPN/пакет безпеки тунелює трафік через нього.

Завдання: Зіставити PID з Get-NetTCPConnection до процесу

cr0x@server:~$ powershell -NoProfile -Command "Get-Process -Id 988 | Select-Object Id,ProcessName,Path | Format-List"
Id          : 988
ProcessName : svchost
Path        : C:\Windows\System32\svchost.exe

Рішення: Якщо це svchost — зіставте зі службами (tasklist /svc) перед будь-якими діями.

Завдання: Швидка перевірка маршрутів (неправильний маршрут = дивна повільність)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric | Select-Object -First 12 | Format-Table -Auto DestinationPrefix,NextHop,InterfaceAlias,RouteMetric"
DestinationPrefix NextHop     InterfaceAlias RouteMetric
----------------- -------     -------------- -----------
0.0.0.0/0         192.168.1.1 Ethernet        25
10.0.0.0/8        10.8.0.1    VPN             5

Що це означає: Метрики маршрутів вирішують, куди йде трафік. Маршрути VPN з низькими метриками можуть тягнути весь трафік через обмежений тунель.

Рішення: Якщо ваш маршрут за замовчуванням іде через VPN несподівано — перевірте налаштування/політику VPN; не «ремонтуйте» видаленням маршрутів навмання.

Завдання: Перевірити WinHTTP проксі (часто відрізняється від проксі браузера)

cr0x@server:~$ cmd /c "netsh winhttp show proxy"
Current WinHTTP proxy settings:

    Proxy Server(s) : 10.10.0.20:8080
    Bypass List     : (none)

Що це означає: Деякі служби використовують WinHTTP проксі. Неправильний проксі може створювати повтори і повільність.

Рішення: Якщо проксі неправильний/застарілий — виправте через політику або скиньте (в керованих середовищах координуйте з IT).

Завдання: Показати деталі Wi‑Fi лінка (підказки про сигнал/швидкість)

cr0x@server:~$ cmd /c "netsh wlan show interfaces"
    Name                   : Wi-Fi
    State                  : connected
    Signal                 : 68%
    Receive rate (Mbps)    : 433.3
    Transmit rate (Mbps)   : 144.4

Що це означає: Низька швидкість передачі може впливати на дзвінки і завантаження навіть якщо завантаження здається нормальним.

Рішення: Якщо швидкості низькі або коливаються — вважайте це RF-проблемою: завантаженість каналів, відстань, завади.

Поширені питання

1) Чи можна знайти використання пропускної здатності по процесу без встановлення нічого?

Так. Використайте Диспетчер завдань (стовпець Мережа) для швидкого перегляду, Resource Monitor для підключень і netstat + відображення PID для атрибуції.

2) Чому «Service Host» використовує трафік замість нормальної назви додатку?

Тому що багато служб Windows запускаються в svchost.exe. Використайте tasklist /svc, щоб відобразити PID у конкретні служби.

3) Чи безпечно відключати BITS або Windows Update, щоб зупинити використання трафіку?

Тимчасова зупинка служби може бути кроком для діагностики, але довготривале відключення інфраструктури оновлень — ризик для безпеки.
Віддавайте перевагу розкладу, обмеженням і вікнам оновлень.

4) Який найшвидший спосіб визначити, чи проблема — насиченість каналу, чи затримка?

Перевірте пропускну здатність інтерфейсу (PerfMon Bytes Total/sec) і перевірте повторні відправлення. Висока пропускна здатність близько до ліміту лінку — насиченість.
Високі повтори при помірній пропускній здатності — втрата/затримка.

5) Чому мій аплінк зайнятий, якщо я «лише завантажую оновлення»?

Delivery Optimization може завантажувати контент іншим пірам. Підтвердіть через Get-DeliveryOptimizationStatus та відрегулюйте обмеження/політику.

6) Диспетчер завдань показує низьке використання мережі, але сайти довго починають завантажуватись. Чому?

Часто це затримка DNS, проблеми з проксі або цикли автентифікації. Виміряйте DNS повторними Resolve-DnsName і перевірте WinHTTP проксі.

7) Чи може Windows обмежувати фонову пропускну здатність без сторонніх інструментів?

Так. Використовуйте налаштування Delivery Optimization/політику та вимірювані підключення. Багато служб Microsoft поважають ці налаштування.

8) Як ідентифікувати, з якими віддаленими серверами процес спілкується?

Resource Monitor і netstat -ano показують віддалені IP і порти. Перетворення IP у «ім’я» не завжди точне через CDN, але діапазон IP і відображення служб зазвичай достатні для рішення.

9) Чи означає трафік «System» завжди Windows Update?

Ні. «System» може включати активність стеку мережі, SMB, VPN-драйвери та інші компоненти на рівні ядра.
Використовуйте таблиці підключень і відображення служб замість припущень.

10) Що надіслати в IT, якщо потрібна допомога?

Надайте: час, інтерфейс (Wi‑Fi/Ethernet/VPN), топ-процес за Мережею, релевантні PID, віддалені IP/порти і чи підвищені повтори.
Це — тикет, з яким можна працювати.

Наступні кроки, які можна зробити сьогодні

1. Коли сповільнення станеться, зробіть два скріншоти: Диспетчер завдань, відсортований за Мережею, і Resource Monitor → TCP Connections, відфільтрований за топ-процесом.
   Докази краще відчуттів.
2. Запустіть netstat -ano і зіставте топ-PID. Якщо це svchost — зіставте служби через tasklist /svc.
3. Якщо оновлення — причина, не воюйте з патчингом. Налаштуйте Active Hours, відрегулюйте Delivery Optimization і обмежте uploads на обмежених каналах.
4. Якщо використання низьке, але повільність велика — розцінюйте як проблему затримки/втрат: перевірте Wi‑Fi швидкості і повтори TCP.
5. Одного разу запишіть, як виглядає «норма» на вашій машині. Базові лінії недорогі. Аварії — дорогі.

Вся хитрість — відмовитися від здогадок. Windows дає достатньо вбудованої видимості, щоб ідентифікувати «свиню»,
службу за нею і тип виправлення, що не спричинить завтрашнього простою.