Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

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

WAN_BDP_BOTTLENECK Сетевое оборудование и VPN

Поиск узких мест WAN-каналов: расчет Bandwidth-Delay Product (BDP)

Обновлено: 25.08.2026 · Официальная документация ↗
  • Купленный высокоскоростной WAN / L2VPN канал 1 Gbps на большие расстояния выдает реальную скорость скачивания одного потока не более 20–50 Mbps.
  • Утилизация физического канала не поднимается выше 10–15% при отсутствии потерь пакетов и низком CPU маршрутизаторов.
  • Синтетический тест iperf3 в один поток показывает низкую скорость, но в 20 параллельных потоков (-P 20) утилизирует всю емкость канала.

1. Математика Bandwidth-Delay Product (BDP)

BDP (Произведение емкости канала на задержку) определяет объем данных, который должен находиться «в полете» (in flight) внутри сетевого кабеля/канала для 100% заполнения доступной полосы пропускания.

2. Формула расчета BDP и требуемого буфера TCP Window

BDP (в байтах) = (Пропускная способность в бит/сек * Round Trip Time в сек) / 8

Пример: Канал 1 Gbps (1 000 000 000 bps) с трансконтинентальной задержкой RTT = 80 мс (0.080 сек):
BDP = (1 000 000 000 * 0.080) / 8 = 10 000 000 байт ≈ 9.53 Мегабайт!

Если системный буфер TCP Receive Window на сервере равен стандартным 64 КБ (0.064 МБ), вы сможете утилизировать только (65535 * 8) / 0.080 = 6.5 Mbps из доступного 1 Gbps!

3. Практическое тестирование пропускной способности через iperf3

# Тест со стандартным окном системы
iperf3 -c wan-server.domain.com -p 5201

# Тест с принудительным заданием окна под рассчитанный BDP (10 МБ)
iperf3 -c wan-server.domain.com -p 5201 -w 10M

# Тест в несколько параллельных потоков для подтверждения BDP ограничений
iperf3 -c wan-server.domain.com -p 5201 -P 8

4. Переключение алгоритма контроля перегрузки на Google BBR

Классические алгоритмы Reno/CUBIC интерпретируют минимальную потерю пакета как сигнал перегрузки и сбрасывают размер окна в 2 раза. Алгоритм BBR (Bottleneck Bandwidth and RTT) максимизирует скорость на основе измерения реальной емкости канала:

# Проверка текущего алгоритма в Linux
sysctl net.ipv4.tcp_congestion_control

# Включение BBR
echo "net.core.default_qdisc=fq" >> /etc/sysctl.d/99-bbr.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.d/99-bbr.conf
sysctl --system
💡 Практика специалистов: При настройке серверов баз данных и репликации хранилищ (DRBD, Ceph, Veeam), работающих через удаленные датацентры (DCI / WAN), всегда вручную выставляйте размер TCP Socket Buffer в конфигурации приложения равным расчетному значению BDP.

Частые вопросы (FAQ)

Почему параллельные потоки iperf3 (-P 10) разгоняют канал, а один поток — нет?

Каждый отдельный TCP-поток имеет свой собственный лимит размера буфера (Window Size). 10 параллельных потоков по 64 КБ суммарно держат 'в полете' 640 КБ данных, что позволяет заполнить в 10 раз большую полосу пропускания.

Что такое Bufferbloat и как он связан с BDP?

Bufferbloat — это чрезмерная буферизация пакетов на промежуточных сетевых устройствах (маршрутизаторах/модемах). Слишком большие неуправляемые очереди раздувают RTT до нескольких секунд, ломая работу интерактивных сервисов (DNS, SSH, VoIP).

Как влияет потеря 0.1% пакетов на производительность канала с высоким BDP?

Для классического алгоритма CUBIC потеря даже 0.1% пакетов на канале с RTT 100 мс приводит к падению скорости на 80–90% из-за постоянного уменьшения Congestion Window. Переход на алгоритм BBR решает эту проблему.

Какой максимальный размер TCP Window поддерживается стандартом RFC 7323?

Благодаря опции TCP Window Scale (максимальный коэффициент масштабирования 14) максимальный теоретический размер окна составляет 1 Гигабайт (2^30 - 1 байт).

Полезные материалы
Рекомендуем