Задержка, пропускная способность и полоса пропускания: три числа, которые все путают

Однажды клиент попросил меня вдвое увеличить полосу пропускания (bandwidth), потому что приложение «тормозило».

Увеличили вдвое. Ничего не изменилось.

Проблема была не в ёмкости канала. Сервис был слишком «болтливым» (chatty): на каждое действие он слал в обе стороны россыпь мелких запросов, и за каждый платил полной круговой задержкой. Плюс буфер раздувался, как только подрастал трафик. Лишние мегабиты в секунду не лечили ни то, ни другое. Мы потратили деньги, расширяя дорогу, которая и так не была узким местом.

Такой разговор случается чаще, чем хотелось бы. И почти всегда он растёт из одного: три разных числа сливают в одно расплывчатое понятие «скорость сети». Скорость — это не одно число. Их три, и каждое рассказывает свою историю:

• Задержка (latency) — это время ожидания.
• Пропускная способность (throughput) — это то, что реально доходит.
• Полоса пропускания (bandwidth) — это потолок.

Дальше по тексту я держу английские термины в скобках: их многие знают именно как latency, throughput и bandwidth, и так проще сверяться с документацией и спид-тестами.

В русском путаница даже сильнее, чем в английском: и bandwidth, и throughput часто называют «пропускной способностью». Чтобы не запутаться, дальше потолок я зову полосой пропускания (bandwidth), а реальную доставку — пропускной способностью (throughput). Перепутаете эти три — и будете чинить не ту проблему. Вот все три на одном канале, в анимации. Смотрите на путь одного пакета, на поток, который доходит, и на общий для них канал:

Одна аналогия на весь пост

Забудьте на секунду про шоссе. Самая чистая модель — водопроводная труба.

• Ширина трубы — это полоса пропускания. Она задаёт максимум.
• Вода, реально вытекающая из дальнего конца за секунду, — это пропускная способность.
• Время, за которое первая капля проходит трубу насквозь, — это задержка.

Держите эту картинку в голове. Каждое определение ниже сводится к ней.

Задержка (Latency): сколько идёт один пакет

По-простому: сколько времени один пакет тратит на дорогу из точки A в точку B.

Точнее: время прохождения пакета от источника к получателю, которое чаще меряют как время кругового обхода (RTT, round-trip time). Оно складывается из четырёх задержек: распространение сигнала (расстояние, делённое на скорость сигнала), передача (выталкивание битов на провод), обработка (роутер читает заголовок) и ожидание в очереди (пакет лежит в буфере).

Единица: миллисекунды (мс), иногда микросекунды.

Реальное число: у пары Нью-Йорк — Лондон физический предел около 55 мс на круговой обход по оптике. Это теоретический минимум для прямого кабеля. Реальный измеренный RTT выше, ближе к 70–80 мс, когда добавляются маршрутизация и коммутация. Но именно физика отрезвляет: свет в оптоволокне идёт примерно 200 000 км/с (около двух третей скорости света в вакууме), так что мы уже в пределах небольшого множителя от этого предела. «Проапгрейдить» скорость света не выйдет. Единственный реальный рычаг — придвинуть данные ближе. Ровно для этого и существуют CDN.

В аналогии с трубой: задержка — это только про длину трубы и скорость капли в ней. К ширине трубы она отношения не имеет.

Пропускная способность (Throughput): сколько реально доходит

По-простому: сколько данных на самом деле проходит за секунду.

Точнее: средний объём данных, успешно доставленных за отрезок времени. Именно это число показывает ваша «скорость загрузки».

Единица: биты в секунду, по нарастающей: Кбит/с → Мбит/с → Гбит/с.

Реальное число: канал «на 100 Мбит/с» при замере может реально выдавать 62 Мбит/с. Этот разрыв — норма. Заторы, потери пакетов, повторные передачи и накладные расходы протокола снимают свою долю сверху.

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

Полоса пропускания (Bandwidth): потолок

По-простому: самое большое, что канал в принципе способен унести.

Точнее: теоретическая максимальная ёмкость канала по передаче данных. Потолок, а не обещание.

Единица: та же, что у пропускной способности. Биты в секунду: Мбит/с, Гбит/с.

Реальное число: те самые «100 Мбит/с» в вашем тарифе. Вы платите за это число. На реальной передаче видите его редко.

В аналогии с трубой: полоса пропускания — это ширина трубы. Она ограничивает всё, но никогда не гарантирует, что труба полна.

Как три числа связаны

Вот соотношение, которое снимает большую часть путаницы:

Пропускная способность всегда меньше либо равна полосе пропускания. Никогда не больше.

Полоса — это потолок; пропускная способность — то, что реально остаётся после того, как реальный мир возьмёт своё. Если канал заявлен на 100 Мбит/с, а вы намеряли 62 Мбит/с — числа не противоречат друг другу. Одно потолок, другое доставка.

И дальше то, что упускают чаще всего:

Задержка живёт на совершенно отдельной оси. Это время, а не объём.

Труба может быть огромной по ширине (большая полоса) и всё равно долго доставлять первую каплю (большая задержка). У трансконтинентального канала с гигантской ёмкостью всё равно зашит RTT расстояния. Вот почему «просто добавь полосы» так часто ничего не меняет: если узкое место на оси времени, расширение трубы его не трогает.

Маленькая ловушка единиц: биты против байтов

Скорости сети считают в битах (Мбит/с). Размеры файлов — в байтах (МБ). В одном байте 8 бит, поэтому:

Канал на 100 Мбит/с упирается примерно в 12,5 МБ/с (100 ÷ 8).

Вот почему «быстрый» канал кажется медленным, когда смотришь на счётчик загрузки файла. Файл в 1 ГБ по идеальному каналу 100 Мбит/с всё равно потребует около 80 секунд, а не 8. Мбит/с — это скорость; МБ — это размер. Не сравнивайте их напрямую без деления на 8.

Формула за «большая полоса, маленькая пропускная способность»

Если нужен один кусок математики, который объясняет, почему канал на 1 Гбит/с может еле ползти, — это произведение полосы на задержку (BDP, bandwidth-delay product):

BDP (бит) = полоса (бит/с) × время кругового обхода (с)

BDP — это объём данных, который может находиться «в полёте» по каналу одновременно. Объём трубы, а не её ширина.

Вот почему это важно. В TCP отправитель может выпихнуть только одно окно данных, а потом обязан остановиться и ждать подтверждения — оно возвращается за один полный круговой обход. Поэтому:

макс. пропускная способность одного соединения ≈ размер окна ÷ RTT

Теперь подставим реальные числа. Заполним канал 1 Гбит/с с RTT 100 мс:

BDP = 1 000 000 000 бит/с × 0,1 с = 100 000 000 бит = 12,5 МБ

Чтобы держать эту трубу полной, нужно 12,5 МБ в полёте. Но исходное окно TCP без масштабирования упирается в 64 КБ. Значит:

65 535 байт × 8 ÷ 0,1 с ≈ 5,2 Мбит/с

Одно соединение использует около 0,5% канала в 1 Гбит/с — и только из-за задержки и маленького окна. Лечится масштабированием окна TCP (RFC 7323): на современных системах оно включено по умолчанию, но на затюненных или старых стеках всё ещё подводит. Вывод: на «длинном толстом канале» задержка душит пропускную способность напрямую, сколько бы полосы вы ни купили.

Не верьте на слово. Потяните время кругового обхода вверх и смотрите, как гигабитный канал проседает, а потом включите масштабирование окна и смотрите, как он восстанавливается:

Почему приложение тормозит, хотя с полосой всё в порядке

Когда что-то тормозит, не спешите докупать мегабиты. Сначала пройдитесь по реальным подозреваемым:

1. Узкое место — задержка. Болтливый протокол платит за круговой обход на каждом запросе. Для большинства сайтов стена — это задержка, а не полоса. Правят бал расстояние и число обходов.

2. Bufferbloat — раздувание буферов. Слишком большие буферы в роутерах и модемах забиваются под нагрузкой. В покое пинг 20 мс, но стоит запустить загрузку — он подскакивает до 200 мс и хуже. Страдает всё интерактивное: видеозвонки, игры, SSH. Лечение — в умном управлении очередями: CoDel, FQ-CoDel или алгоритм управления заторами BBR, а не более толстая труба.

3. Пакеты в секунду, а не биты. В высоконагруженных системах реальный потолок — это часто частота пакетов, которую способно обработать железо, а не сырая полоса. Я видел разбор производительности сети на больших системах, где предел упирался в PPS, и лечилось это джамбо-кадрами (пакеты крупнее, числом меньше), а не добавкой полосы.

4. Одно соединение, маленькое окно. Один поток TCP на длинном маршруте упирается в потолок далеко ниже линейной скорости, пока не масштабируется окно (см. математику BDP выше). Параллельные соединения или мультиплексирование HTTP/2 часто помогают сильнее, чем ёмкость.

5. Потери пакетов. TCP читает потерю как затор и резко сбавляет. Даже 1–2% потерь способны обрушить пропускную способность на канале с большим RTT. Добавка полосы тут не даёт ничего; нужно найти и устранить потерю.

Заметьте, сколько из этого — проблемы задержки или качества, переодетые в «нам нужно больше полосы».

Как на самом деле измерить каждое

Нельзя починить то, чего не видишь. У каждой метрики свой инструмент, и ни один из них — не «посмотреть на Мбит/с в тарифе»:

# Задержка — время кругового обхода и ГДЕ оно вносится
ping vedmich.dev                 # RTT по каждому пакету, в мс
mtr -rwc 100 vedmich.dev         # задержка и потери по каждому хопу за 100 пакетов

# Пропускная способность — что маршрут реально доставляет
iperf3 -c iperf.example.net      # достижимые Мбит/с на маршруте, которым вы управляете
#  ... или спид-тест в браузере (Ookla / Cloudflare) против ближайшего сервера

# Полоса пропускания — её не меряют. Это заявленная ёмкость канала.
#  Спид-тесты меряют пропускную способность; потолок вы выводите уже из неё.

# Bufferbloat — тест, который ловит тихого убийцу:
ping vedmich.dev &               # держим пинг запущенным...
curl -o /dev/null https://speed.example.net/1GB.bin   # ...и забиваем канал
#  смотрите на RTT, пока идёт загрузка: ровно — здорово, раздувается — bufferbloat

Последний — самая полезная диагностическая привычка, какую только можно завести: пингуйте во время загрузки. Если задержка держится ровно — тормозит что-то другое. Если скачет — у вас bufferbloat или забитый канал, и никакая добавка полосы вас не спасёт. Вот это вживую. Запустите загрузку, смотрите на линию, потом примените умную очередь:

Первый вопрос, который стоит задать

Когда приложение тормозит, первый вопрос — никогда не «сколько у нас полосы».

Он такой: что из трёх на самом деле узкое место?

• Если задержка — придвиньте данные ближе или сократите число обходов.
• Если пропускная способность на длинном маршруте — смотрите на масштабирование окна, параллелизм и потери пакетов.
• Если это правда полоса (труба действительно полна) — тогда, и только тогда, докупайте.

Ошибётесь с диагнозом — и сделаете то же, что мой клиент: потратите реальные деньги, расширяя дорогу, которая никогда не была проблемой.

Если было полезно — я раз в неделю разбираю основы сетей, AWS и Kubernetes. Сопроводительная визуальная карусель к этому посту — у меня в LinkedIn.