Тест Пінгу та Втрати Пакетів

Як це працює

1. Закрийте інші завантаження та трансляції. Інший пристрій чи застосунок, що споживає смугу пропускання під час тесту, роздує показник затримки під навантаженням з причин, які не мають нічого спільного з реальною поведінкою вашого з'єднання.
2. Віддавайте перевагу Ethernet або сідайте ближче до роутера. Wi-Fi додає власну затримку та джитер поверх того, що робить ваша інтернет-лінія — кабель ізолює вимірювання до самої лінії.
3. Натисніть «Почати» і залиште вкладку на передньому плані. Браузери сповільнюють фонові вкладки, що тихо зіпсує вимірювання, на яке спирається цей тест.
4. Спочатку дивіться затримку в спокої, потім під навантаженням. Перша фаза вимірює з'єднання в спокої; друга запускає завантаження одночасно з тими самими зондами затримки, щоб побачити, наскільки воно сповільнюється, поки зайняте.
5. Читайте лічильники стабільності, а не відсоток втрат. Його немає — див. нижче чому — але кількість зондів без відповіді і скільки з них повернулися незвично повільно кажуть майже те саме.
6. Запустіть ще раз у годину пік. Затримка та bufferbloat чутливіші до часу доби, ніж чиста швидкість — вечірній результат може суттєво відрізнятися від денного.

Що насправді вимірює цей тест (і чому «пінг» тут трохи неточна назва)

Команда `ping` надсилає сирий пакет ICMP і засікає час відповіді. Вебсторінка так не може — браузери не мають доступу до ICMP чи до сирих сокетів жодного виду, з тих самих причин пісочниці (sandboxing), через які вебсторінка не може читати ваші файли без дозволу. Тому цей тест робить найближче чесне рішення: засікає час звичайного HTTPS-запиту до мережі Cloudflare і віднімає час обробки, який повідомляє сам сервер, залишаючи лише мережевий шлях туди-й-назад.

• Це реальний, виміряний шлях туди-й-назад — не симуляція й не оцінка, просто через HTTPS замість ICMP.
• Зазвичай показує на кілька мілісекунд більше, ніж пінг з термінала до того самого місця призначення, тому що захищений TLS обмін HTTP усе одно коштує трохи більше за простий ICMP-луна-сигнал, навіть після віднімання часу обробки сервера.
• Вимірює шлях до точки Cloudflare, а не до конкретного ігрового сервера, провайдера дзвінків чи сайту — сприймайте це як індикатор «наскільки добре моє з'єднання загалом», а не як точне число до конкретного місця призначення.

Чому на цій сторінці немає відсотка втрати пакетів

Це варто пояснити прямо, а не просто пропустити число, бо його відсутність — свідомий вибір, а не відсутня функція.

• TCP — протокол під будь-яким звичайним вебзапитом — автоматично й непомітно повторно надсилає втрачені дані. Втрачений пакет не провалюється; він просто приходить пізніше, після однієї повторної спроби.
• Це означає, що вебсторінка, яка засікає час HTTP-запитів, буквально не може побачити втрачений пакет як втрату — вона бачить повільну відповідь, яку на перший погляд не відрізнити від звичайного перевантаження.
• Інструмент, який обчислив би «0% втрати пакетів» з цих даних, не повідомляв би низький рівень втрат — він повідомляв би, що взагалі не зміг виявити втрати, а це зовсім інша річ для того, хто діагностує нестабільне з'єднання.
• Справжнє вимірювання втрати пакетів потребує протоколу, що не приховує втрату — сирого ICMP або UDP — а це саме те, що браузеру не дозволено надсилати.

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

Затримка, джитер і найгірший випадок: що означає кожне число

Тест повідомляє три пов'язані, але різні числа зі своєї фази затримки в спокої.

• Затримка (мс): типовий час туди-й-назад — технічно медіана всіх зондів, яка стійка до спотворення одним повільним викидом, на відміну від середнього.
• Джитер (мс): наскільки цей час туди-й-назад коливається від одного зонда до іншого, а не наскільки він високий у середньому. З'єднання може мати пристойну середню затримку і все одно відчуватися уривчастим у дзвінку, якщо джитер високий.
• Найгірший випадок (мс): шлях туди-й-назад на 95-му перцентилі — близько до числа, яке ви справді помітите в дзвінку чи грі, оскільки один дуже повільний момент виділяється набагато більше, ніж типовий.

Bufferbloat: чому з'єднання гальмує саме тоді, коли починається завантаження

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

• Більшість роутерів і модемів ставлять вихідні дані в чергу в буфері перед відправкою — розумна ідея, яка йде не так, коли цей буфер завеликий для з'єднання.
• Коли велике завантаження чи вивантаження заповнює цей буфер, кожен інший пакет — включно з зондами затримки цього тесту та кожним пакетом дзвінка чи гри — має чекати в черзі за ним.
• Результат: затримка, яка нормальна, коли з'єднання вільне, може стрибнути з 20мс до 300мс і більше в ту мить, коли щось насичує лінію, а потім знову впасти, коли це закінчується.
• Цей тест вимірює саме це: запускає насичуюче завантаження у фоні, продовжуючи надсилати зонди затримки, а потім порівнює затримку до й під час.

Оцінки йдуть від A+ до F, залежно від того, наскільки зростає затримка під навантаженням — A+ це ледь помітні кілька мілісекунд, F — сотні мілісекунд, тип сплеску, через який дзвінок обривається саме тоді, коли телефон починає резервне копіювання в хмару на тому самому з'єднанні.

Як виглядають хороші числа, за видами діяльності

Немає єдиного «хорошого» числа — те, що важливо, повністю залежить від того, що ви робите на з'єднанні.

• Голосові дзвінки: комфортно нижче приблизно 200мс туди-й-назад з низьким джитером; більшість VoIP-кодеків мають достатньо буферизації, щоб згладити більше, ніж відео.
• Відеодзвінки: затримка нижче 150мс і джитер нижче 30мс відчувається надійно; оцінка bufferbloat C або гірша часто є справжньою причиною дзвінка, що обривається щоразу, коли хтось інший онлайн.
• Онлайн-ігри: нижче 50мс з жорстким джитером — відмінно для будь-чого змагального; 50-100мс годиться для більшості казуальних ігор.
• Хмарний гейминг: найсуворіший випадок — нижче 40мс з дуже низьким джитером, тому що весь відеокадр робить шлях туди-й-назад, а не лише ввід.
• Перегляд, стрімінг, завантаження: затримка тут майже не має значення — див. тест швидкості інтернету для чисел, які насправді керують цим.

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

Wi-Fi, VPN та інше, що роздуває результат

Перш ніж вважати, що поганий результат означає погану інтернет-лінію, виключіть те, що найімовірніше додає власну затримку.

• Wi-Fi: додає власну затримку і, особливо на перевантаженому діапазоні 2,4ГГц або в багатоквартирному будинку з десятками накладених мереж, власний джитер — часто більше, ніж вносить сама інтернет-лінія.
• VPN: маршрутизує кожен пакет через додатковий сервер, часто віддалений, додаючи реальну відстань туди-й-назад поверх витрат на шифрування.
• Перевантажений роутер: старіший або слабкий роутер може додавати затримку обробки під навантаженням незалежно від вашого реального інтернет-з'єднання — зовні це виглядає ідентично bufferbloat.
• Фонові застосунки: хмарна синхронізація, автооновлення та інші пристрої в тій самій мережі можуть тихо насичувати з'єднання під час того, що ви вважали тестом у спокої.

Найшвидший спосіб ізолювати причину: запустіть тест дротовим з'єднанням із призупиненим усім іншим, а потім знову через Wi-Fi зі звичайним фоновим навантаженням — розрив між ними покаже, де насправді проблема.

Коли результат справді вказує на проблему

Більшість неідеальних результатів мають одне з пояснень вище. Менший набір патернів справді варто підняти перед провайдером.

• Оцінка bufferbloat D або F на дротовому з'єднанні, підтверджена в кількох запусках — часто виправна з боку провайдера сучасним керуванням чергою (продається як SQM або fq_codel), якщо вони це підтримують.
• Затримка в спокої значно вища за 100мс до найближчої точки Cloudflare на дротовому з'єднанні, стабільно в різний час доби — це вказує на проблему маршрутизації чи перевантаження вище за течією, а не на щось у вашому домі.
• Велика кількість зондів без відповіді на дротовому з'єднанні без активного VPN — варто відтворити і повідомити зі скріншотом, оскільки це може вказувати на реальну проблему в мережі провайдера.
• Числа в нормі о 3-й ночі, але стабільно погані щовечора — локальне перевантаження мережі, конкретний патерн, який варто повідомити безпосередньо провайдеру.

Часті запитання