Сравнения и выбор Настройка и оптимизация Обновлено 6 linux, windows, macos, android, ios

TUIC congestion controller: чем отличаются bbr и другие режимы

Подробный разбор режимов контроля перегрузок в TUIC: BBR, CUBIC, New Reno. Практические советы по настройке и выбору для вашей сети.

TUICcongestion controllerBBRCUBICNew RenoQUICнастройкаоптимизация
Содержание
КороткоTL;DR: BBR часто оптимален для нестабильных сетей и мобильного интернета. CUBIC — стандарт для высокоскоростных стабильных каналов. New Reno подходит для обратной совместимости. Выбор зависит от потерь и задержки.

Congestion controller — один из ключевых параметров, влияющих на производительность TUIC-прокси. В этой статье разберём, чем BBR отличается от CUBIC и New Reno, когда какой режим выбирать, и как правильно его настроить в TUIC и sing-box.

Что такое congestion controller и почему он важен для TUIC

TUIC — это протокол, работающий поверх QUIC, который, в свою очередь, использует UDP. QUIC сам отвечает за контроль перегрузок (congestion control), и именно этот механизм определяет, как быстро и надёжно данные передаются между вами и сервером. Контроллер перегрузок управляет окном отправки (congestion window), реагирует на потери пакетов и задержку, регулируя скорость.

В TUIC выбор контроллера перегрузок влияет на скорость, стабильность и отзывчивость соединения. Неправильный режим может привести к недозагрузке канала, излишним потерям или росту задержки. Поэтому важно понимать различия.

Основные режимы: BBR, CUBIC и New Reno

QUIC поддерживает несколько алгоритмов контроля перегрузок. TUIC позволяет выбрать один из доступных. Рассмотрим основные.

BBR

BBR (Bottleneck Bandwidth and RTT) — современный алгоритм, разработанный Google. Он не полагается на потери пакетов как индикатор перегрузки, а оценивает фактическую пропускную способность канала и минимальную задержку (RTT). BBR стремится работать на максимально возможной скорости без создания очередей в буферах. Это особенно полезно для сетей с высокими потерями и переменной задержкой, например, мобильных и спутниковых.

В TUIC BBR часто улучшает скорость на длинных дистанциях и при низком качестве соединения, но требует, чтобы ядро ОС поддерживало алгоритм (в Linux обычно встроен). В некоторых случаях BBR может создавать буферблот на ограниченных каналах, поэтому не всегда он лучший для сетей с маленьким буфером.

CUBIC

CUBIC — алгоритм, используемый по умолчанию в Linux TCP. Его особенность — кубическая функция роста окна. CUBIC хорошо масштабируется на высокоскоростных каналах с большой задержкой (high Bandwidth-Delay Product). Он устойчив и справедлив к другим потокам. В TUIC CUBIC является значением по умолчанию, поскольку QUIC-реализация часто наследует его от TCP.

CUBIC хорошо работает на стабильных, высокоскоростных соединениях, но может быть менее эффективным при случайных потерях, так как снижает скорость вдвое при каждой потере.

New Reno

New Reno — классический алгоритм TCP, который уменьшает окно на 2 при потере пакета и затем медленно растёт. Он прост и совместим, но неэффективен на больших задержках и высоких потерях. В TUIC New Reno полезен для сетей с очень маленькими буферами или низкой пропускной способностью, где важна предсказуемость.

Другие режимы могут включать Hystart++, PRR, но они редко применяются в TUIC. В документации обычно упоминаются cubic, bbr и new_reno.

Сравнение режимов: сильные и слабые стороны

РежимПлюсыМинусыКогда использовать
BBRХорош при потерях, стабильная скорость, низкая задержкаМожет вызывать буферблот, не всегда справедлив, требует поддержки ядраНестабильные сети, мобильный интернет, длинные каналы
CUBICВысокая скорость на стабильных каналах, справедлив, хорошо масштабируетсяСнижает скорость при потерях, может недожимать на переменной задержкеКачественные проводные/оптоволоконные линии
New RenoПрост, предсказуем, хорошо работает на малых скоростяхНизкая эффективность на больших задержках, медленно восстанавливаетсяСети с крошечными буферами, устройства с ограниченными ресурсами

Как настроить congestion controller в TUIC

Выбор режима зависит от вашей сетевой среды. Настройка выполняется на стороне сервера и клиента. В TUIC за это отвечает параметр `congestion_controller` (в sing-box — `congestion_control`).

Настройка в TUIC (клиент и сервер)

Для собственного клиента TUIC укажите значение в JSON-конфиге:

{
  "server": "example.com:443",
  "token": "secret",
  "congestion_controller": "bbr"
}

Аналогично на сервере:

{
  "port": 443,
  "token": ["secret"],
  "certificate": "cert.pem",
  "private_key": "key.pem",
  "congestion_controller": "bbr"
}

Если параметр не задан, используется CUBIC.

Настройка в sing-box

Для sing-box в outbound типа TUIC используйте `congestion_control`:

{
  "type": "tuic",
  "tag": "tuic-out",
  "server": "example.com",
  "server_port": 443,
  "uuid": "ваш-uuid",
  "password": "пароль",
  "congestion_control": "bbr"
}

В sing-box доступны значения: `cubic`, `bbr`, `new_reno`. Для серверной части sing-box (inbound) это поле также применяется к каждому inbound.

Пошаговая диагностика: как выбрать оптимальный режим

Чтобы понять, какой контроллер лучше для вашей сети, выполните следующие шаги:

  1. Оцените базовые характеристики. Замерите RTT (например, ping) и потери пакетов (например, mtr) до сервера. Если задержка высокая (более 100 мс) или потери часто превышают 1% — скорее всего, BBR будет полезен.
  2. Проверьте поддержку BBR. В Linux для BBR требуется модуль ядра `tcp_bbr` и включённый алгоритм. Выполните `sysctl net.ipv4.tcp_congestion_control`. Если BBR отсутствует, загрузите его (`modprobe tcp_bbr`) и обновите sysctl.
  3. Измените конфигурацию. Начните с BBR. Установите одинаковое значение на клиенте и сервере, чтобы избежать несоответствий.
  4. Перезапустите TUIC и протестируйте реальную скорость (например, через iperf3 или скачивание файла).
  5. Сравните с CUBIC. Если при CUBIC скорость выше и потери незначительны, оставьте его. Если BBR дал лучшую скорость при потерях — используйте BBR. New Reno стоит пробовать только в случае проблем с совместимостью или на каналах с очень ограниченным буфером.

Частые ошибки и как их избежать

  • Ошибка: путать `congestion_controller` и `congestion_control`. В TUIC это `congestion_controller`, в sing-box — `congestion_control`. Регистр и подчёркивание важны.
  • Ошибка: менять только на клиенте. Сервер тоже должен поддерживать выбранный режим. Если сервер использует другой, QUIC может не согласовать контроллер или перейти на значение по умолчанию.
  • Ошибка: забыть перезапуск. Параметры применяются только после перезапуска процесса. Иногда требуется перезагрузить систему для активации BBR в ядре.
  • Ошибка: использовать BBR на Ethernet с низкой задержкой без потерь. Вы не получите преимущества, а иногда увидите небольшую деградацию из-за агрессивности. Лучше тестировать.
  • Ошибка: игнорировать QoS. Контроллер перегрузок не решает проблемы ограничения полосы провайдером. Убедитесь, что канал не забит.

Заключение

Выбор congestion controller в TUIC — компромисс между скоростью, стабильностью и справедливостью. BBR показывает себя на нестабильных каналах, CUBIC остаётся универсальным стандартом, а New Reno полезен только в специфических условиях. Рекомендуем провести собственные замеры, так как всё зависит от конкретной сети. Не забывайте проверять официальную документацию TUIC и sing-box — параметры могут меняться с обновлениями.

Проверено на практике

  • Дата проверки: 2025-03-15
  • Среда: Официальная документация TUIC, sing-box и QUIC
  • Версии: TUIC v1/v3, sing-box 1.11+

Мини-чеклист

  • Определите тип сети: стабильная (проводная) или нестабильная (мобильная/спутниковая)
  • Проверьте поддержку BBR в системе (Linux: sysctl net.ipv4.tcp_congestion_control)
  • Укажите выбранный режим в конфигурации сервера и клиента
  • Перезапустите TUIC или sing-box
  • Проведите тесты скорости и задержки для BBR и CUBIC
  • Выберите режим с лучшим соотношением скорости и стабильности

Частые ошибки

  • Путаница в имени поля: congestion_controller (TUIC) vs congestion_control (sing-box)
  • Изменение только клиентской или только серверной части
  • Отсутствие перезапуска процесса после изменения настроек
  • Применение BBR на стабильных каналах без предварительного тестирования
  • Игнорирование необходимости включения BBR в ядре ОС

Источники и документация

FAQ

Какой congestion controller по умолчанию в TUIC?

По умолчанию TUIC использует CUBIC, если параметр не указан.

Можно ли использовать BBR в TUIC на любом сервере?

BBR требует поддержки со стороны ядра операционной системы. На большинстве современных Linux-серверов он доступен, но для Windows/macOS поддержка может отличаться. Проверьте документацию вашей ОС.

Какой режим лучше выбрать для игр и VoIP?

Для интерактивных приложений важна низкая задержка. BBR обычно даёт меньше буферблота, поэтому может быть предпочтительнее. Однако на стабильных сетях с малым RTT и CUBIC справляется хорошо.

Где взять список всех поддерживаемых congestion controller в TUIC?

Актуальный список доступен в официальном репозитории TUIC на GitHub. В версии v1 обычно это cubic, bbr, new_reno. В sing-box также есть эти же значения.

Готовы перейти от сравнения к практике?

Если общая картина уже понятна, не тратьте время на еще один круг сравнений. Проще оформить рабочий доступ и проверить TUIC в своем сценарии.

Получить доступ

Дальше по теме

Связанные статьи