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

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

Коротко про головне

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

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

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

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

2. Він відкриває багато паралельних зʼєднань. Speedtest запускає кілька одночасних потоків TCP (зазвичай від 4 до 16) і підсумовує їхню швидкість. Саме так він обходить обмеження, на яке одиночне зʼєднання натрапляє на далеких маршрутах (докладніше про це нижче). Реальні застосунки часто працюють через одне зʼєднання або кілька, тож такого розгону не отримують.

3. Затримка мінімальна. На короткому маршруті час обігу (RTT) становить лише кілька мілісекунд, тому TCP встигає розігнатися до повної швидкості каналу.

У підсумку Speedtest показує "лабораторну" пропускну здатність вашого каналу, а не ту швидкість, яку ви насправді отримаєте під час обміну даними із сервером в іншій країні.

Головна причина: добуток смуги на затримку та вікно TCP

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

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

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

Щоб повністю заповнити канал, вікно має бути щонайменше таким, як так званий добуток смуги на затримку (BDP):

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

Порахуймо це для каналу 600 Мбіт/с за затримки до сервера в ЄС близько 50 мс:

BDP = 600 000 000 біт/с × 0,05 с = 30 000 000 бітів = 3,75 МБ

Це означає, що для насичення каналу в "польоті" одночасно має перебувати близько 3,75 МБ даних. Якщо ж на одному боці активний старий або обмежений розмір вікна (класичні 64 КБ без масштабування вікна), стеля швидкості для одиночного зʼєднання становить:

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

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

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

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

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

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

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

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

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

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

На практиці це має драматичний вигляд. За RTT 50 мс і стандартного MSS навіть 0,1% втрат обмежує одиночне зʼєднання приблизно 73 Мбіт/с, 1% втрат опускає його до близько 23 Мбіт/с, а 2% втрат нижче 17 Мбіт/с. На далеких транзитних маршрутах втрати в 1 до 2% у години пік це цілком звичне явище і часто головний обмежувач.

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

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

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

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

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

Додаткові технічні чинники

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

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

Bufferbloat (роздування буферів). Надмірні буфери на проміжних вузлах збільшують затримку під навантаженням і збивають алгоритми керування потоком TCP, додатково знижуючи реальну швидкість.

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

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

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

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

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

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

Щоб переконатися в причині, виконайте кілька простих перевірок.

1. Запустіть Speedtest вручну й оберіть сервер у потрібній країні ЄС (наприклад, у Німеччині чи Нідерландах, де розташовані наші сервери). Це покаже реальну швидкість саме на тому маршруті, який використовується в роботі, а не до найближчого локального сервера.

2. Побудуйте трасування маршруту. Команда tracert (Windows) або traceroute (macOS, Linux) до нашого сервера показує ланцюг вузлів і затримку на кожному з них. Для наочної діагностики втрат і затримки чудово підходить утиліта mtr (або WinMTR у Windows), яку найкраще залишити запущеною на кілька хвилин у години пік.

3. Порівняйте одне зʼєднання з кількома. Якщо багатопотокове завантаження йде швидко, а одиночний потік повільно, це прямо підтверджує обмеження вікна TCP на далекому маршруті.

4. За наявності технічної змоги скористайтеся iperf3, щоб виміряти пропускну здатність до віддаленого вузла напряму, як одним, так і кількома потоками.

Що робити

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

Підсумок

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

Оновлено: 21/06/2026