RTT (round-trip time) це час від відправлення пакета даних до отримання підтвердження, що він дійшов і на нього відповіли. Вимірюється в мілісекундах. Показує повний цикл туди і назад, а не шлях в один бік. Коли адміністратор мережі каже “пінг до сервера 40 мс”, він майже завжди має на увазі саме RTT, хоча пінг і RTT технічно не одне й те саме.
Браузер не може почати завантажувати сторінку, поки не завершиться встановлення з’єднання. Встановлення з’єднання коштує щонайменше один RTT. Для відеодзвінка чи онлайн-гри висока RTT відчувається як затримка реакції співрозмовника або персонажа. Нижче розібрано, з яких частин складається це число, як порахувати його самостійно і де метрика RTT дає хибну картину.
З чого складається RTT
RTT це сума чотирьох затримок. Кожна має власну природу. Затримка поширення сигналу залежить від фізичної відстані та швидкості світла у середовищі передачі. Зазвичай саме вона домінує на далеких маршрутах. Затримка передавання це час, потрібний на те, щоб протиснути весь пакет через канал певної пропускної здатності. Затримка обробки виникає на кожному маршрутизаторі, який читає заголовок пакета і вирішує, куди його направити. Затримка черги з’являється, коли пакет чекає своєї черги на завантаженому вузлі. Саме вона найсильніше стрибає під час перевантаження мережі.
| Складова | Що це | Від чого залежить |
|---|---|---|
| Поширення | час проходження сигналу фізичним середовищем | відстань, швидкість світла у волокні |
| Передавання | час виштовхування пакета в канал | розмір пакета, пропускна здатність каналу |
| Обробка | аналіз заголовка на кожному вузлі | кількість хопів, навантаження маршрутизатора |
| Черга | очікування на завантаженому вузлі | перевантаження мережі в момент вимірювання |
Власний розрахунок: скільки фізика дозволяє на маршруті Київ-Франкфурт
Пряма відстань між Києвом і Франкфуртом становить приблизно 1300 кілометрів. Світло у волоконно-оптичному кабелі рухається повільніше, ніж у вакуумі: приблизно 200000 кілометрів за секунду замість 300000. Один прохід сигналу займе 1300 поділити на 200000, це 6,5 мілісекунди. Повний цикл туди і назад це подвоєне значення, 13 мілісекунд. Це фізичний мінімум, обумовлений лише швидкістю світла. Жодна оптимізація коду цю цифру не зменшить.
Реальний маршрут ніколи не йде прямою лінією. Оптичний кабель прокладено вздовж доріг, кордонів і точок обміну трафіком. Фактична довжина шляху зазвичай перевищує пряму відстань в півтора-два рази. При коефіцієнті 1,6 ефективна відстань зростає приблизно до 2080 кілометрів в один бік, а чиста затримка поширення на повний цикл піднімається до 21 мілісекунди. До цього додаються обробка на кожному маршрутизаторі і час на встановлення TCP-з’єднання. Виміряний RTT на маршруті Київ-Франкфурт зазвичай лежить в діапазоні від 25 до 40 мілісекунд залежно від оператора і завантаженості мережі в момент вимірювання. Різниця між фізичним мінімумом 13 мс і практичним результатом 25-40 мс це ціна маршрутизації, обробки та черг, яку теоретична формула не враховує.
RTT, пінг, затримка і джитер: чотири різні речі
Плутанина між цими термінами зустрічається постійно, хоча кожен описує окрему властивість з’єднання. Затримка (latency) це час проходження сигналу в один бік, від відправника до отримувача. RTT це подвоєна затримка плюс обробка на приймальному кінці, тобто повний цикл. Пінг не показник, а інструмент: команда ping надсилає ICMP-пакет і вимірює саме RTT найпростішим можливим способом.
Джитер це окрема величина, розкид значень RTT між послідовними вимірюваннями. З’єднання зі стабільними 60 мс RTT приємніше для голосового дзвінка, ніж з’єднання, яке хаотично стрибає від 20 до 150 мс. Це вірно навіть тоді, коли середнє значення в другому випадку нижче. Для відеодзвінків і онлайн-ігор джитер часто шкідливіший за саму величину затримки. Тому системи моніторингу мережі відстежують обидва параметри окремо.
Чому RTT не можна ділити навпіл
Поширена спрощена формула стверджує, що затримка в один бік дорівнює RTT, поділеному на два. Це працює лише за симетричного маршруту, коли шлях туди і шлях назад однакові за довжиною і навантаженням. В реальному інтернеті маршрутизація найчастіше асиметрична: провайдер відправляє трафік через один транзитний вузол, а відповідь отримує через інший, з іншою довжиною і чергою. Half-RTT залишається зручною оцінкою за відсутності кращих даних. Видавати її за точний вимір затримки в один бік некоректно.
RTT у TCP: одне рукостискання дорожче, ніж здається
Перед тим як браузер отримає перший байт даних, TCP-з’єднання проходить трьохетапне рукостискання: клієнт надсилає SYN, сервер відповідає SYN-ACK, клієнт підтверджує ACK. Ці три пакети коштують рівно один повний RTT. Жодні дані на цьому етапі ще не передано. Для невеликого запиту час до першого байта відповіді, TTFB, зазвичай дорівнює двом RTT. Один цикл йде на встановлення з’єднання, другий на сам запит і відповідь.
Розмір вікна перевантаження TCP зростає поступово, подвоюючись з кожним підтвердженим циклом на етапі повільного старту. Передавання великого файлу на з’єднанні з RTT 200 мс досягне повної швидкості каналу помітно повільніше, ніж те саме передавання при RTT 20 мс. Різниця збережеться, навіть якщо пропускна здатність обох каналів однакова. Високий RTT б’є не лише по відчуттю затримки, а й по реальній швидкості завантаження важких сторінок.
TLS, HTTPS і 0-RTT: як з’єднання втратило зайвий рейс
Захищене HTTPS-з’єднання додає до TCP-рукостискання ще й криптографічне узгодження TLS. У TLS 1.2 це коштувало два додаткові цикли RTT, перш ніж клієнт міг надіслати перший запит. TLS 1.3 скоротив цю ціну до одного RTT в більшості випадків. Для повторного підключення до вже відомого сервера з’явився режим 0-RTT: клієнт надсилає зашифровані дані одразу в першому пакеті, спираючись на ключ, збережений з попередньої сесії.
Протокол QUIC, що лежить в основі HTTP/3, вбудовує ту саму логіку 0-RTT глибше в транспортний рівень і додатково прибирає окреме рукостискання TCP. Для користувача з мобільним інтернетом і RTT 150 мс економія навіть одного циклу дає помітно швидше відкриття сторінки. Плата за швидкість це трохи послаблені гарантії захисту від повторного відтворення пакетів на етапі 0-RTT. Тому протокол дозволяє серверам обмежувати, які саме запити можна приймати в цьому режимі.
Як виміряти RTT самостійно
Найпростіший інструмент це команда ping з терміналу: ping -c 10 example.com надішле десять ICMP-пакетів і покаже мінімальне, середнє, максимальне значення RTT і розкид, що приблизно відповідає джитеру. Traceroute показує RTT до кожного проміжного вузла окремо. Це дозволяє побачити, на якому саме хопі виникає стрибок затримки. Утиліта mtr поєднує обидва підходи і оновлює статистику в реальному часі, що зручно для діагностики нестабільного з’єднання протягом кількох хвилин.
ICMP-пакети деякі маршрутизатори і файрволи обробляють з нижчим пріоритетом ніж звичайний TCP-трафік або й взагалі ігнорують заради захисту від сканування мережі. Показник ping у таких випадках буде вищим за реальну затримку прикладного протоколу. Іноді ping взагалі не отримає відповіді, хоча сайт відкривається нормально. Для точнішої картини варто заміряти час до першого байта відповіді безпосередньо в браузері, через вкладку мережі в інструментах розробника.
Як зменшити RTT
Затримка поширення на далеких маршрутах домінує над іншими складовими. Тому головний важіль це фізична відстань до сервера. CDN і edge-сервери, розміщені географічно ближче до користувача, скорочують саме цю компоненту і залишаються найефективнішим методом. Другий важіль це кількість повних циклів, потрібних до першого байта даних. Перехід на TLS 1.3 з підтримкою 0-RTT, увімкнення HTTP/3 на базі QUIC і повторне використання вже встановлених з’єднань скорочують саме цю частину.
Оптимізація маршрутизації через якісний пірінг у провайдера і уникнення зайвих транзитних хопів дає менший, але реальний виграш, особливо коли трафік іде через кілька країн замість прямого стику мереж. Супутниковий інтернет лишається окремим випадком. Геостаціонарний супутник розташований на висоті приблизно 35786 кілометрів, тому навіть теоретичний мінімум RTT через нього перевищує 470 мілісекунд, а на практиці часто піднімається до 600 мілісекунд і вище. Жодна оптимізація протоколу цю фізичну відстань не скоротить.
Де метод не працює: обмеження RTT як метрики
RTT це усереднена величина одного моменту. Вона не показує втрату пакетів і не показує джитер, тому два з’єднання з однаковим середнім RTT можуть відчуватися геть по-різному. RTT також нічого не каже про пропускну здатність каналу: маршрут з низьким RTT і вузьким каналом однаково повільно завантажуватиме великий файл, бо тут вирішує добуток пропускної здатності на затримку. Значення, виміряне через ICMP, не завжди збігається зі значенням, яке відчуває конкретний застосунок на прикладному рівні, особливо коли мережа пріоритизує різні типи трафіку по-різному.
Не для кожного застосунку висока RTT критична. Завантаження пошти чи фонове резервне копіювання толерують затримку в сотні мілісекунд без помітних наслідків для користувача. Голосовий зв’язок, конкурентні онлайн-ігри і біржові системи з мілісекундною чутливістю це протилежний полюс, де кожні додаткові 10 мс мають ціну. Норматив хорошого RTT завжди залежить від типу навантаження і не існує як єдина цифра для всіх випадків.