Калькулятор задержек передачи данных в сети

Битрейт, Мбит/с

Размер пакета, байт

MTU, байт

Сетевая задержка RTT, мс

Протокол передачи TCP UDP ICMP

Доли времени: передача, фрагментация, RTT

Фрагменты пакета	–
Задержка передачи, мс	–
Задержка от фрагментации, мс	–
Общая задержка, мс	–
Эффективный битрейт, Мбит/с	–

Онлайн-программа моделирует задержки при передаче сетевых пакетов и помогает оценить, какие компоненты вносят основной вклад в итоговую задержку (латентность): время сериализации на канале, задержки, связанные с фрагментацией пакета при MTU меньше размера пакета, сетевой RTT/пропагация и дополнительные расходы протоколов (например, установка TCP-соединения). Калькулятор удобен для инженеров, сисадминов, разработчиков сетевых приложений и всех, кто проектирует сети или оценивает поведение при разных конфигурациях канала.

Для расчётов задаются основные входные параметры: номинальный битрейт канала (в Мбит/с), размер передаваемого пакета (в байтах), значение MTU (в байтах), базовая сетевой задержка / RTT (в миллисекундах) и тип протокола (TCP/UDP/ICMP). Регуляторы позволяют быстро и наглядно менять параметры и сразу получать пересчёт результата: круговую диаграмму вкладов задержки, числовые значения и оценку эффективной пропускной способности.

Как пользоваться калькулятором

1. Введите ожидаемый канал в Мбит/с — это физическая или заявленная пропускная способность канала.
2. Укажите размер пакета в байтах (payload + заголовки приложения, если знаете) — это тот «пакет», который вы анализируете.
3. Задайте MTU — максимальный размер кадра/пакета на пути. Если пакет > MTU, он будет фрагментирован и отправлен как несколько фрагментов.
4. Укажите сетевую задержку/RTT — это суммарная «пропагация + обработка» между узлами (можно измерить ping).
5. Выберите протокол: TCP (учитываем установку соединения / подтверждения), UDP (без подтверждений), ICMP (ping-пакеты). Вклад протокола влияет на дополнительные накладные задержки и на модель эффективного битрейта.
6. Сразу после изменения любого параметра график и числовые поля обновляются интерактивно.

Используем простую, прозрачную физическую модель, разделяющую задержку на понятные части:

1. Задержка сериализации

Это время, требуемое на отправку всех бит пакета по каналу:
$$
t_{tx} = \frac{L_{bits}}{R}\cdot 1000\ \mathrm{(мс)}
$$

где \(L_{bits}\) — размер пакета в битах (байты × 8), \(R\) — битрейт канала в бит/с. Результат в миллисекундах.

2. Фрагментация и дополнительная задержка

Если пакет превышает MTU, он разбивается на \(N_{\mathrm{frag}} = \left\lceil\frac{L_{bytes}}{MTU}\right\rceil\) фрагментов. Каждый фрагмент несёт собственные заголовки и требует отдельной сериализации. В упрощённой модели мы считаем дополнительную задержку двумя способами (в зависимости от настроек калькулятора):

а) как «penalty per fragment» — фиксированная накладная задержка на каждый дополнительный фрагмент:
$$
t_{\mathrm{frag}} = (N_{\mathrm{frag}} — 1)\cdot t_{\mathrm{perFrag}}
$$
б) более корректно — через увеличение числа передаваемых битов из-за заголовков каждого фрагмента:
$$
\mathrm{Доп.\ биты} \;=\; N_{\mathrm{frag}}\cdot H_{\mathrm{frag}}
$$

$$
t_{\mathrm{frag}} \;=\; \frac{\mathrm{Доп.\ биты}}{R}\cdot 1000\ \mathrm{мс}
$$

3. Сетевой RTT / Propagation & processing

Это внешняя задержка (маршрутизация, физическая пропагация), задаётся пользователем и добавляется к общему времени. Для TCP могут добавляться дополнительные RTT на установку соединения или подтверждения, поэтому модель прибавляет условный вклад протокола.

4. Общая задержка по упрощённой модели

Объединяя всё:
$$
t_{\mathrm{total}} = t_{tx} + t_{\mathrm{frag}} + t_{\mathrm{net}} + t_{\mathrm{proto}}
$$
где \(t_{\mathrm{net}}\) — сетевой RTT/задержка (мс), \(t_{\mathrm{proto}}\) — дополнительный вклад протокола (например, 1 RTT для TCP в модели установки соединения).

5. Эффективная пропускная способность

Для оценки того, сколько «полезных» бит/байт реально доставляется за единицу времени, используется формула
$$
\mathrm{Eff} = \frac{L_{\mathrm{payload\ (бит)}}}{t_{\mathrm{total}}/1000}\ \mathrm{(бит/с)}
$$

Результат можно перевести в Мбит/с. Обратите внимание: здесь мы считаем через одну транзакцию/пакет: если общая задержка велика, эффективный битрейт по одиночной транзакции будет низким (важно для интерактивных мелких запросов). Для устойчивого пропускного потока используется другая модель, где доминирует сам битрейт канала.

Пример расчёта пошагово

Пусть у нас: битрейт \(R = 100\) Мбит/с, пакет \(L = 1500\) байт, MTU = 1500 байт, сетевой RTT = 10 мс, протокол = TCP (учтём 1 мс условной накладки для установки в упрощённой модели).

1) \(L_{bits} = 1500\cdot 8 = 12000\) бит.
2) \(t_{tx} = 12000 / (100\times10^6) \cdot 1000 = 0.12\) мс.
3) фрагментации нет, \(t_{\text{frag}} = 0\).
4) \(t_{\text{total}} \approx 0.12 + 10 + t_{\text{proto}} = 11.12\) мс.
5) Эффективный битрейт (для этого одиночного пакета): \( \text{Eff} = 12000 / (11.12/1000) \approx 1.08 \times 10^6\) бит/с ≈ 1.08 Мбит/с.

Обратите внимание: номинальный канал 100 Мбит/с — это пиковая физическая скорость, но из-за частых маленьких обменов и ожиданий (RTT, подтверждения) «эффективный битрейт» для одиночных транзакций может быть значительно ниже.

Что означает эффективный битрейт

Высокий показатель означает, что при заданных задержках и размере пакета канал используется эффективно (много полезных бит/мс). Низкий означает, что из-за частых ожиданий, фрагментации или малого размера передаваемых сообщений реальное количество доставляемых полезных данных за единицу времени мало — это критично для интерактивных приложений (RPC, веб-запросы) и менее критично для потоковой передачи, где данные передаются крупными блоками.

Если вы видите, что фрагментация даёт заметную дополнительную задержку, постарайтесь уменьшить размер пакета или поднять MTU (например, Jumbo Frames в LAN). Для TCP-ориентированных приложений имеет смысл объединять мелкие сообщения в крупные пакеты, чтобы уменьшить влияние RTT. Используйте Path MTU Discovery, если возможно, либо настраивайте MSS/TCP оконный размер, чтобы улучшить использование канала. На медленных каналах полезно минимизировать частоту коротких запросов: агрегируйте данные, применяйте компрессию и кэширование.

Таблица типовых значений

В реальных сетях модель усложняется: TCP использует окно и конгестион-контроль, при устойчивом потоке канал может быть полностью использован, и эффективный битрейт приближается к R. Для кратковременных одиночных обменов — DOMINATE RTT. Если ваш сценарий — частые маленькие запросы, улучшать нужно именно RTT и уменьшать накладные протокола (HTTP/2, поддержание соединения, мультиплексирование). Для потоковой передачи и загрузок важнее MTU и контроль фрагментации.

Многие ожидают, что «битрейт 100 Мбит/с» сразу означает, что одиночный запрос передаст данные с 100 Мбит/с. Это не так — номинальная физическая скорость не снимает потребность в учёте сетевых задержек и накладок. Эффективный битрейт, рассчитанный по модели одного пакета, показывает именно сколько полезных бит реально проходит при одной транзакции с учётом ожидаемого времени ответа.

Минимизируйте число коротких транзакций, поднимайте MTU там, где можно, агрегируйте сообщения, используйте UDP/QUIC для сценариев с малыми накладными подтверждениями если приложение это позволяет, и следите за корректной настройкой MSS/PMTUD в TCP-стеке.

Справочная таблица с примерами

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