Чому швидкість до серверів у ЄС нижча, ніж у Speedtest

Speedtest показує 290 Мбіт/с. Реальна швидкість у роботі з серверами в ЄС виходить ближче до 38 Мбіт/с. Розрив приблизно у вісім разів важко не помітити, і майже завжди причина в довгому міжнародному маршруті, а не у вашому обладнанні чи в нашому сервісі.

Коротко

Speedtest і справжнє зʼєднання з далеким сервером міряють різні речі. Speedtest перевіряє чисту пропускну здатність вашої лінії на дуже короткому маршруті. Робота з серверами в ЄС залежить від затримки і від стану міжнародних каналів, якими йде трафік. Тож високий результат Speedtest підтверджує здоровʼя вашої лінії. Низька швидкість до ЄС впирається у фізику далеких зʼєднань і завантаженість транзитних мереж.

Як виглядає розрив

Ось одна лінія, заміряна двічі з інтервалом у кілька хвилин. Спершу Speedtest проти сервера, який він вибрав сам.

Майже всю цифру пояснюють дві деталі на цій панелі. У полі "Connections" стоїть "Multi", тобто швидкість складено з кількох потоків. А сервер він вибрав у тій самій країні. Тепер та сама лінія, заміряна проти серверів, які насправді везуть вебінари. Це крок вимірювання швидкості в нашому тестері звʼязку.

Завантаження падає приблизно у вісім разів. Віддача сповзає лише з 26 до 16, тобто набагато мʼякше. Жодна з цифр не означає, що лінія несправна. Далі розберемо, куди дівається кожна з них.

Одну річ на другій панелі варто прочитати уважно. "TO YOU" показує прийом, а "FROM YOU" віддачу. Якщо ведете ви, головна цифра саме "FROM YOU", бо камера, мікрофон і показ екрана йдуть угору. Учаснику, який лише дивиться, важлива натомість "TO YOU". У замірі вище 15,98 Мбіт/с угору це приблизно вдесятеро більше, ніж треба ведучому.

Що насправді міряє Speedtest

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

• Він вибирає найближчий сервер. Speedtest бере той, до якого затримка найменша, зазвичай усередині мережі вашого провайдера або в тому самому місті. Трафік до нього йде коротким маршрутом і міжнародних каналів не торкається взагалі.
• Він відкриває багато паралельних зʼєднань. Speedtest запускає одразу кілька потоків TCP, зазвичай від 4 до 16, і додає їхню швидкість. Так він обходить межу, в яку впирається одне зʼєднання на довгому маршруті. Про неї наступний розділ. Справжні застосунки часто працюють в одне-два зʼєднання, тому такої надбавки не отримують.
• Затримка мінімальна. На короткому маршруті час обігу, він же RTT, це лише кілька мілісекунд, тому TCP встигає розігнатися до повної швидкості лінії.

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

Добуток пропускної здатності на затримку і вікно TCP

Більша частина розриву впирається саме в цей механізм.

TCP надсилає дані вікнами. Відправник виштовхує порцію даних, чекає підтвердження про доставку і лише тоді продовжує. Максимальну швидкість одного зʼєднання TCP описує проста формула.

Швидкість = Розмір вікна / Затримка (RTT)

Щоб заповнити лінію повністю, вікно має бути не меншим за добуток пропускної здатності на затримку, скорочено BDP.

BDP = Пропускна здатність × RTT

Порахуймо для тієї лінії на 290 Мбіт/с із затримкою до сервера в ЄС близько 50 мс.

BDP = 290 000 000 біт/с × 0,05 с = 14 500 000 біт = 1,81 МБ

Отже, щоб лінія була завантажена вщент, у дорозі щомиті має бути близько 1,8 МБ даних. А якщо один бік застряг з обмеженим вікном, тобто класичними 64 КБ без масштабування, стеля для одного зʼєднання виходить така.

Швидкість = 65 536 байтів × 8 біт / 0,05 с ≈ 10,5 Мбіт/с

Ось чому одне зʼєднання з далеким сервером упирається у 10-20 Мбіт/с навіть на лінії, розрахованій на сотні мегабітів. На короткому маршруті з RTT 2 мс те саме вікно віддало б понад 260 Мбіт/с. Саме тому в Speedtest проблема не спливає ніколи. Що більша затримка, то сильніший ефект. Тут нічого не зламано, бо так просто поводиться протокол.

Затримка і фізика далеких каналів

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

Світло йде оптоволокном зі швидкістю близько 200 000 км/с, помітно повільніше за швидкість світла у вакуумі. Винен показник заломлення скла. Кожна тисяча кілометрів маршруту додає близько 5 мс в один бік, тобто близько 10 мс на обіг. Справжні маршрути рідко йдуть по прямій, тож зазвичай вони довші за географічну відстань.

Далі йде затримка на кожному проміжному вузлі. Маршрутизатор обробляє пакет, ставить його в чергу і передає далі. Дорогою до сервера в ЄС таких вузлів зазвичай від 10 до 20, їх називають хопами. Кожен додає свою частку. Що вищий підсумковий RTT, то нижча стеля для одного зʼєднання за формулою вище.

Втрати пакетів і їхній вплив на TCP

Навіть невеликі втрати пакетів на міжнародному каналі різко зрізають підсумкову швидкість. Втрачений пакет TCP сприймає як ознаку затору, тому сповільнюється, а потім знову набирає швидкість. Цей звʼязок описує рівняння Матіса.

Швидкість ≈ MSS / (RTT × √p)

MSS це максимальний розмір сегмента, зазвичай близько 1460 байтів. RTT це затримка, а p це частка втрачених пакетів. Швидкість падає обернено до кореня квадратного з рівня втрат і прямо залежить від затримки.

На практиці цифри виглядають драматично. При RTT 50 мс і звичайному MSS навіть 0,1 відсотка втрат тримають одне зʼєднання близько 7 Мбіт/с. Один відсоток втрат опускає його приблизно до 2,3 Мбіт/с, а два відсотки нижче за 1,7 Мбіт/с. На довгих транзитних маршрутах втрати в один-два відсотки в години пік цілком звичайні. А там, де втрати сягають таких значень, вони кусають сильніше за обмеження вікна вище. Тому маршрут, який зранку просто повільний, увечері стає непридатним.

Маршрутизація і пірінг

Шлях, яким ваш трафік іде до сервера в ЄС, не прямий. Його ведуть ланцюжок операторів і протокол маршрутизації BGP. А той вибирає маршрут з комерційних і технічних міркувань, а не за найкоротшою відстанню.

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

Затори на міжнародних каналах провайдера

Локальний трафік, у межах міста та країни, у більшості провайдерів має добрий запас ємності. Тому Speedtest до близького сервера завжди показує високу цифру. Міжнародні канали дорожчі, їх купують обмеженим обсягом, і у вечірній пік саме вони стають вузьким місцем. Це й пояснює, чому швидкість до ЄС помітно гуляє протягом доби, а локальний Speedtest стабільно високий.

Інші технічні чинники

Крім головних причин, на швидкість до далекого сервера впливає ще кілька речей.

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

Bufferbloat. Завеликі буфери на проміжних вузлах піднімають затримку під навантаженням і збивають з пантелику алгоритми керування потоком у TCP. Реальна швидкість від цього падає ще нижче.

Шейпінг і пріоритизація, вони ж QoS. Деякі провайдери свідомо ріжуть швидкість або занижують пріоритет міжнародного трафіку чи одного його різновиду. І це прямо видно у ваших цифрах.

Накладні витрати протоколів. Заголовки TCP, IP і шифрування зʼїдають частину смуги. На короткому маршруті цього не видно. У парі з втратами й затримкою на довгому маршруті вони вже відчутні.

Ваше власне оточення. Wi-Fi замість кабелю, перевантажений домашній роутер, антивірус чи VPN на пристрої теж знижують реальну швидкість, тож починайте перевірку саме з них.

Чому це не проблема обладнання чи сервісу

Високий результат Speedtest доводить, що ваше обладнання і локальна лінія здорові й видають належну швидкість. Просідання в роботі з серверами в ЄС береться з іншого місця. Це затримка на довгому маршруті, межа вікна для одного зʼєднання TCP, втрати пакетів і стан міжнародних каналів провайдера. Усе це лежить поза нашим сервісом і поза вашим обладнанням, бо належить ділянці мережі між провайдером і магістральними операторами.

Перш ніж ганятися за цифрами, варто тримати масштаб у голові. Вебінару треба значно менше, ніж передаванню файлів, тож 20 Мбіт/с до ЄС для нас узагалі не проблема. Ведучому потрібно близько 1,6 Мбіт/с угору, або 3,2 під час показу екрана, а учаснику стільки, щоб прийняти кожного спікера в ефірі. Усі цифри повністю розписують технічні вимоги. Стабільність тут важить більше за голу швидкість, тож коли ваші заходи йдуть гладко, розрив зі Speedtest це радше цікавинка, ніж несправність.

Як перевірити самому

Кілька перевірок пришпилять причину.

• Запустіть Speedtest вручну і виберіть сервер у Німеччині або у Фінляндії. Усі наші сервери стоять у ЄС, у Німеччині, Франції, Нідерландах і Фінляндії, але саме німецькі та фінські машини везуть трафік вебінарів. Нідерландські та французькі розсилають запрошення на майбутні заходи, тож замір проти них розкаже про маршрут, яким ваші вебінари не ходять. Перевірка проти Німеччини чи Фінляндії показує справжню швидкість на робочому маршруті, а не на маршруті до найближчого локального сервера.
• Простежте маршрут. Запустіть tracert у Windows або traceroute на macOS і Linux проти нашого сервера, і отримаєте ланцюжок вузлів із затримкою на кожному. Щоб ясніше побачити втрати й затримку, візьміть утиліту mtr або WinMTR у Windows і залиште її працювати на кілька хвилин у години пік.
• Порівняйте одне зʼєднання з кількома. Завантаження в багато потоків швидке, а в один потік повільне? Це підтверджує межу вікна TCP на довгому маршруті.
• Якщо маєте технічну змогу, зміряйте пропускну здатність до далекого вузла напряму через iperf3, спершу в один потік, потім у кілька.

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

Що робити

Перевірки показали високу затримку або втрати пакетів на міжнародній ділянці? Зверніться до провайдера з конкретними даними. Це трасування маршруту і показання mtr із зазначеним часом доби. Правити маршрут або розширювати міжнародну звʼязність це робота провайдера. З нашого боку ми дамо адреси наших серверів для точкової діагностики і допоможемо прочитати результати. Напишіть в онлайн-чат, і ми їх надішлемо.

Підсумок

Результат Speedtest близько 290 Мбіт/с підтверджує, що лінія здорова. Просідання нижче за 40 Мбіт/с у роботі з серверами в ЄС очікуване. Його дають затримка на довгому маршруті, межа вікна для одного зʼєднання TCP, втрати пакетів і завантаженість міжнародних каналів провайдера. Ці причини лежать у мережі між вами і нами, а не у вашому обладнанні чи в нашому сервісі. Проста діагностика маршруту покаже, яка з чотирьох шкодить.

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

Чи варто платити за швидшу лінію, щоб це виправити?

Ні, бо вебінару треба значно менше, ніж передаванню файлів, і 20 Мбіт/с до ЄС для нас узагалі не проблема. Ведучому потрібно близько 1,6 Мбіт/с угору, або 3,2 під час показу екрана, а всі цифри повністю розкладають технічні вимоги. Стабільність тут важить більше за голу швидкість, тож коли ваші заходи йдуть гладко, розрив зі Speedtest це радше цікавинка, ніж несправність.

Завантаження впало у вісім разів, а віддача майже не змінилася. Що з них важливіше?

Віддача, якщо ведете саме ви, бо камера, мікрофон і показ екрана йдуть угору. Це цифра "FROM YOU". Учаснику, який лише дивиться, важлива натомість "TO YOU", тож той самий замір читається по-різному залежно від вашої ролі на заході. У показаннях вище віддача сповзла лише з 26 до 16 Мбіт/с, а це приблизно вдесятеро більше, ніж треба ведучому.

Який сервер Speedtest вибрати для чесного порівняння?

У Німеччині або у Фінляндії. Усі наші сервери стоять у ЄС, у Німеччині, Франції, Нідерландах і Фінляндії, але саме німецькі та фінські машини везуть трафік вебінарів. Нідерландські та французькі розсилають запрошення на майбутні заходи, тож замір проти них розкаже про маршрут, яким ваші вебінари не ходять.

Чи можу я щось виправити самотужки?

Почніть зі свого боку, бо Wi-Fi замість кабелю, перевантажений домашній роутер, антивірус чи VPN на пристрої знижують реальну швидкість. Тут чисто, а перевірки й далі показують високу затримку або втрати пакетів на міжнародній ділянці? Тоді виправляти має провайдер. Зверніться до нього з конкретними даними, тобто з трасуванням маршруту і показаннями mtr із зазначеним часом доби. Адреси наших серверів для точкової діагностики ми дамо, тож напишіть в онлайн-чат.

Чому вранці маршрут нормальний, а ввечері непридатний?

Міжнародні канали купують обмеженим обсягом, і у вечірній пік вони стають вузьким місцем. Локальний трафік має добрий запас, тому Speedtest до близького сервера тримає високу цифру цілий день. Втрати пакетів ідуть тією самою кривою, і на довгих транзитних маршрутах один-два відсотки в години пік цілком звичайні. При RTT 50 мс один відсоток втрат тримає одне зʼєднання приблизно на 2,3 Мбіт/с, а це й перетворює просто повільний маршрут на непридатний.