RTT: время полного цикла запроса и влияние на скорость страниц

RTT, Round-Trip Time, это время, которое проходит от отправки пакета до получения ответа на него. Оно включает путь в обе стороны и время обработки на удалённом узле. В выводе ping значение «время=23 мс» и есть RTT. В отличие от односторонней задержки его можно измерить на одном устройстве, без синхронизации часов с получателем.

Поскольку прямой и обратный маршруты нередко проходят разными путями, половина RTT лишь приблизительно равна задержке в одну сторону.

Многие протоколы устроены как диалог: отправить, дождаться подтверждения, отправить дальше. Каждый такой обмен стоит целого RTT. Установка TCP-соединения занимает один RTT на рукопожатие, затем шифрование в TLS добавляет ещё один или два в зависимости от версии, и лишь потом уходит первый запрос. Для страницы, которая грузит десятки ресурсов, накопленные задержки становятся ощутимыми.

TCP тоже разгоняется поэтапно: окно отправки растёт каждый RTT. Чем RTT больше, тем медленнее набирается скорость, и короткие передачи так и не достигают пропускной способности канала.

При RTT в 20 миллисекунд страница с двадцатью последовательными зависимостями теряет порядка полусекунды на ожиданиях, при 200 миллисекундах уже около четырёх секунд. Браузеры смягчают ситуацию, открывая несколько соединений и загружая ресурсы параллельно, а протоколы нового поколения, как QUIC, сокращают число обменов при установке соединения.

Именно поэтому сайты размещают ближе к пользователям через сети доставки контента. Смысл в том, чтобы уменьшить расстояние и, следовательно, RTT для каждого обмена.

Ping даёт простейшую оценку. Запустите его на несколько десятков пакетов и смотрите минимум, среднее и максимум. Минимум показывает физический предел пути, средний отражает типичную картину, а максимум помогает заметить пики. Разница между ними и есть джиттер.

В инструментах разработчика браузера на вкладке сети видно, сколько времени занимают отдельные этапы: поиск DNS, соединение, шифрование, ожидание ответа. Если ожидание велико при малом RTT, проблема в самом сервере, а не в канале.

Внутри локальной сети RTT обычно доли миллисекунды или пара миллисекунд, до сервера в том же городе десять–двадцать, между европейскими странами несколько десятков, через океан порядка ста и больше. Спутниковые каналы с геостационарной орбиты добавляют около полусекунды из-за расстояния.

Не путайте RTT с пропускной способностью: их не заменишь одно другим. Рост скорости подключения не сделает RTT меньше, а сокращение маршрута не увеличит скорость канала. Оба показателя нужно оценивать вместе.

TCP использует измеренный RTT для расчёта тайм-аута повторной передачи: если подтверждение не пришло за время, немного большее типичного RTT, пакет считается потерянным. При скачках задержки протокол вынужден увеличивать запас, а значит, реакция на реальные потери замедляется. Поэтому нестабильный RTT вредит не меньше высокого, но стабильного.

В современных протоколах усилия направлены на сокращение обменов до первых данных. QUIC объединяет транспортное и криптографическое рукопожатие, а TLS 1.3 сократил число обменов при шифровании. Для пользователя с большим RTT, например при подключении к серверу за океаном, эта экономия заметна сильнее всего: страница начинает отображаться на сотни миллисекунд быстрее.

Для практики выполните такой опыт: пингуйте по очереди роутер, узел провайдера, сервер в своей стране и сервер на другом континенте, записывая минимальное значение. Получившаяся лесенка хорошо показывает, как расстояние и число сетей на пути складываются в RTT, и заодно даёт ориентир, каких цифр ждать от ваших подключений. Затем повторите замеры вечером, в час наибольшей нагрузки, и сравните.

Обратите внимание: для мобильных сетей значения обычно колеблются сильнее, чем для проводных, и виноват в этом радиоканал, а не сервер.

Тем, кто настраивает сервисы, стоит учитывать RTT при выборе места размещения серверов и числа запросов на страницу.