Ключевые метрики производительности: влияние RTT и пропускной способности на бэкенд

В предыдущей теме мы разобрали, как данные упаковываются в сегменты и пакеты. Но для бэкенд-разработчика важна не только структура пакета, но и динамика: как быстро и в каком объеме данные перемещаются между узлами.

Часто возникает вопрос: почему при «гигабитном канале» API отвечает медленно? Чтобы ответить на него, нужно научиться измерять сеть глазами Senior-инженера.

Три метрики производительности

Скорость сети — понятие растяжимое. Чтобы не путаться, разделяйте три ключевых показателя:

1. Latency (Задержка) — время в пути от отправителя до получателя. На практике мы измеряем RTT (Round Trip Time) — время «туда и обратно».
2. Throughput (Пропускная способность) — реальный объем данных, проходящий через сеть в секунду (Мбит/с или RPS).
3. Jitter (Джиттер) — «дрожание» задержки. Если один пакет идет 10 мс, а второй — 100 мс, у вас высокий джиттер. Это критично для видеосвязи и стриминга.

Запомните: Широкий канал не гарантирует низкую задержку. Представьте шоссе: количество полос — это Throughput, а ограничение скорости — Latency. Даже на 10-полосном автобане вы не доедете до цели мгновенно.

---

Анатомия RTT: куда уходит время?

RTT складывается из четырех физических факторов:

• Распространение: Ограничено скоростью света. Пакет из Москвы в Сингапур физически не долетит быстрее ~80 мс.
• Передача: Время на «выталкивание» битов в кабель. Зависит от размера пакета и ширины канала.
• Обработка: Время, которое тратят роутеры и ядро ОС на чтение заголовков.
• Очереди: Если узел перегружен, пакет ждет в буфере. Это главный источник Jitter.

В микросервисах один запрос часто порождает цепочку из 10 внутренних вызовов. Лишние 2 мс RTT на каждом шаге превращаются в 20 мс задержки для пользователя.

---

Bandwidth-Delay Product (BDP): «Емкость» канала

Чтобы эффективно использовать сеть, нужно понимать, сколько данных может находиться «в полете» одновременно. Для этого используют Bandwidth-Delay Product.

$BDP = Bandwidth \times RTT$

Зачем это бэкенд-инженеру? BDP определяет идеальный размер окна TCP. Если буфер на сервере меньше BDP, отправитель будет простаивать в ожидании подтверждения (ACK). В итоге ваш гигабитный канал будет загружен лишь на 10%.

---

Практикум: измеряем сеть в консоли

Для диагностики в современных дата-центрах обычного ping мало. Нужно видеть распределение задержек.

1. Анализ маршрута и Jitter через mtr

Утилита mtr объединяет ping и traceroute.

# Анализируем путь до сервера
mtr -rw google.com

Смотрите на колонку StDev (среднеквадратичное отклонение) — это и есть Jitter. Чем выше число, тем менее стабильна сеть.

2. Задержка прикладного уровня через curl

Выделяем сетевую составляющую из общего времени ответа API:

curl -o /dev/null -s -w 'Connect: %{time_connect} TTFB: %{time_starttransfer} Total: %{time_total}\n' https://api.example.com

• time_connect — время установления TCP-соединения (близко к RTT).
• TTFB (Time To First Byte) — время до получения первого байта (включает обработку на бэкенде).

---

Что видит Senior vs Новичок

Ситуация	Взгляд новичка	Взгляд Senior-инженера
Медленный API	«Наверное, база тормозит, пойду оптимизировать SQL».	«Проверю RTT между сервисами. Возможно, у нас Jitter из-за перегрузки коммутатора».
Выбор региона ДЦ	«Возьмем там, где дешевле».	«Рассчитаю BDP. Если RTT > 100 мс, придется тюнить TCP-окна или переходить на HTTP/3».
Мониторинг	«Средний пинг в норме, всё ок».	«Среднее значение бесполезно. Покажите P99, чтобы увидеть реальные задержки у пользователей».

Мы разобрались, как RTT ограничивает эффективность канала через BDP. Но как именно протокол TCP передает максимум данных, не «заваливая» сеть?

В следующей теме изучим механизмы надежности: узнаем, как работает Window Scaling и почему TCP всегда начинает передачу медленно, постепенно «разгоняясь».