Round-Trip Time

Round-Trip Time (RTT, время кругового пути) — это метрика в компьютерных сетях и телекоммуникациях, обозначающая время, необходимое для передачи сигнала от источника к получателю и обратно (подтверждения получения). RTT является одной из ключевых характеристик задержки (latency) в сетях с коммутацией пакетов, таких как Интернет, и напрямую влияет на производительность протоколов, скорость передачи данных и качество работы приложений реального времени.

Физическая природа и измерение

RTT складывается из нескольких компонентов:

• Время распространения сигнала (propagation delay) — время, которое затрачивает электромагнитный сигнал (свет в оптоволокне, электрический ток в медном кабеле, радиоволна) на преодоление физического расстояния между узлами. Ограничено скоростью света в среде (около 200 000 км/с в оптоволокне).
• Время обработки (processing delay) — время, необходимое маршрутизаторам, коммутаторам и конечным устройствам для анализа заголовков пакетов, принятия решений о маршрутизации и буферизации.
• Время ожидания в очереди (queuing delay) — время, которое пакет проводит в очередях на промежуточных узлах перед отправкой, зависящее от загрузки сети.
• Время передачи (transmission delay) — время, необходимое для «выталкивания» всех бит пакета в канал связи (зависит от размера пакета и пропускной способности канала).

Измеряется RTT обычно в миллисекундах (мс). Для этого используется отправка специального тестового пакета (например, ICMP Echo Request в утилите ping) и фиксация времени получения ответа (ICMP Echo Reply). RTT включает время на передачу запроса, обработку на удалённом узле и передачу ответа.

Значение в протоколах и приложениях

Протокол TCP

RTT является критически важным параметром для протокола управления передачей (TCP), который обеспечивает надёжную доставку данных в Интернете. TCP использует RTT для:

• Управления тайм-аутом повторной передачи (Retransmission Timeout, RTO). Если подтверждение (ACK) не получено в течение времени, равного нескольким RTT (с учётом вариации), отправитель считает пакет потерянным и повторно отправляет его. Слишком маленький RTO ведёт к ложным повторным передачам, слишком большой — к снижению производительности при реальных потерях.
• Контроля перегрузки (congestion control). Алгоритмы TCP (например, Cubic, BBR) оценивают пропускную способность сети на основе RTT и скорости потери пакетов. Увеличение RTT (например, из-за заполнения буферов маршрутизаторов) может сигнализировать о начале перегрузки, и TCP снижает скорость отправки данных.
• Алгоритма Нейгла (Nagle's algorithm). Для уменьшения количества мелких пакетов TCP может задерживать отправку данных, если ожидается подтверждение на предыдущий сегмент (то есть в течение одного RTT).

Приложения реального времени

Для голосовой и видеосвязи (VoIP, видеоконференции), онлайн-игр, удалённого управления (SSH, VNC) и финансовых торговых систем RTT имеет решающее значение:

• Допустимые значения: RTT до 100–150 мс обычно считается приемлемым для голосовой связи; выше 300 мс — заметная задержка, ухудшающая диалог. Для онлайн-игр (шутеры, гонки) RTT менее 50 мс считается отличным, 50–100 мс — хорошим, выше 150 мс — заметно ухудшает игровой опыт.
• Джиттер (jitter) — вариация RTT между последовательными пакетами. Высокий джиттер (например, от 10 до 200 мс) вызывает прерывания в аудио/видео потоке, даже если средний RTT низок.

Факторы, влияющие на RTT

1. Географическое расстояние. Основной неустранимый фактор. Сигнал от Москвы до Нью-Йорка (около 7500 км по оптоволокну) имеет минимальное время распространения ~37 мс (в одну сторону). Реальный RTT обычно выше из-за маршрутизации и обработки.
2. Тип и качество канала связи. Спутниковые каналы (геостационарная орбита, высота 36 000 км) дают RTT около 500–600 мс только за счёт распространения (вверх и вниз). Оптоволоконные линии обеспечивают минимальные задержки. Медные DSL-линии и сотовые сети (3G/4G/5G) добавляют задержки на модуляцию/демодуляцию и обработку в базовых станциях.
3. Загрузка сети и перегрузки. При высокой загрузке маршрутизаторов и коммутаторов пакеты задерживаются в очередях, что увеличивает RTT. В крайних случаях (перегрузка) может происходить сброс пакетов, что приводит к повторным передачам и ещё большему росту RTT.
4. Производительность конечных устройств. Слабый процессор, медленная сетевая карта, перегруженная операционная система могут увеличивать время обработки пакетов на стороне отправителя/получателя.
5. Маршрутизация и количество промежуточных узлов (хопов). Каждый маршрутизатор добавляет задержку на обработку и буферизацию. Неоптимальная маршрутизация (например, трафик из Европы в Азию через США) может значительно увеличить RTT.

Методы снижения RTT

• Оптимизация маршрутизации — использование прямых пиринговых соединений между крупными сетями (IXP, точки обмена трафиком), выбор кратчайших маршрутов.
• Использование протоколов с меньшей задержкой — например, QUIC (HTTP/3), который работает поверх UDP и устраняет задержки TCP-рукопожатия (один RTT вместо двух) и конвейеризацию подтверждений.
• Сжатие заголовков и данных — уменьшение размера пакетов сокращает время передачи.
• Аппаратное ускорение — использование специализированных сетевых процессоров и FPGA для обработки пакетов на промежуточных узлах.
• Сети доставки контента (CDN) — размещение серверов ближе к конечным пользователям, что сокращает физическое расстояние и, следовательно, RTT.
• Оптимизация протоколов TCP — настройка параметров (например, увеличение начального окна перегрузки, использование алгоритмов BBR).

Инструменты измерения

Наиболее распространённый инструмент — утилита командной строки ping, которая отправляет ICMP-пакеты и выводит статистику RTT (минимальное, среднее, максимальное значение и среднеквадратическое отклонение). Более продвинутые инструменты:

• traceroute / tracert — показывает RTT до каждого промежуточного узла (хопа) на пути к цели.
• mtr (My TraceRoute) — объединяет функционал ping и traceroute, предоставляя непрерывную статистику RTT для каждого хопа.
• iperf3 — измеряет пропускную способность и задержки, может оценивать RTT косвенно.
• Специализированные сервисы (например, Cloudflare Speed Test, RIPE Atlas) позволяют измерять RTT между множеством точек по всему миру.

RTT и качество обслуживания (QoS)

В сетях с поддержкой QoS (Quality of Service) RTT может быть приоритизирован. Например, трафик голосовой связи (VoIP) может быть помечен как чувствительный к задержкам, и маршрутизаторы будут обрабатывать его в первую очередь, минимизируя время ожидания в очереди. Для фонового трафика (обновления ПО, резервное копирование) RTT может быть менее критичным.

Ограничения и критика

• RTT не является единственной метрикой качества сети. Высокая пропускная способность (bandwidth) может компенсировать умеренный RTT для потоковой передачи данных, но не для интерактивных приложений.
• Измерение RTT с помощью ICMP может быть неточным, так как ICMP-пакеты часто обрабатываются с более низким приоритетом, чем обычный трафик, и могут быть заблокированы межсетевыми экранами.
• RTT может сильно варьироваться в зависимости от времени суток, загрузки сети и маршрута (асимметричная маршрутизация). Однократное измерение не даёт полной картины.
• В некоторых случаях (например, в спутниковых сетях) RTT принципиально высок, и его снижение требует физических изменений (переход на низкоорбитальные спутники, такие как Starlink).

Интересные факты

• Минимальный теоретический RTT между двумя точками на поверхности Земли (по большому кругу, через оптоволокно) составляет около 66 мс (для расстояния 20 000 км, скорость света в вакууме 300 000 км/с, в оптоволокне ~200 000 км/с). Практически достижимые значения — около 70–80 мс для трансатлантических маршрутов.
• В финансовом секторе (алгоритмическая торговля) снижение RTT на 1 миллисекунду между биржами может стоить миллионы долларов в год. Для этого прокладываются специальные микроволновые линии, где скорость распространения сигнала в воздухе выше, чем в оптоволокне.
• Протокол TCP использует оценку RTT для адаптации к сети. Современные реализации (например, BBR) могут работать эффективно при высоких RTT (до нескольких секунд), характерных для спутниковых каналов.

Источники

• Компьютерные сети. Принципы, технологии, протоколы (Олифер В.Г., Олифер Н.А.)
• RFC 793 — Transmission Control Protocol (TCP)
• RFC 6298 — Computing TCP's Retransmission Timer
• RFC 896 — Congestion Control in IP/TCP Internetworks
• Документация по утилитам ping, traceroute, mtr (Linux man pages)
• Материалы IETF (Internet Engineering Task Force) по протоколам QUIC и BBR