todo/Hysteria/bandwidth-brutal.md
loop-uh 08b4491545
Some checks failed
Published content check / validate (push) Failing after 3s
Завершить переезд базы знаний на Forgejo
Обновить правила репозитория и подписи исходников в 99 заметках, не затрагивая пользовательские незакоммиченные файлы. Сделать Forgejo Actions содержательным: проверять опубликованный commit, а не пустое рабочее дерево после checkout.
2026-08-07 08:27:28 +03:00

11 KiB
Raw Permalink Blame History

date tags aliases link
2026-07-11
hysteria
скорость
congestion-control
brutal
bbr
Hysteria Brutal
Hysteria bandwidth
Hysteria скорость
https://v2.hysteria.network/docs/advanced/Full-Server-Config/#congestion-control-details

🦎 Hysteria 2 — скорость и алгоритм Brutal

[!info] О чём заметка Почему у Hysteria есть поле bandwidth, как работает фирменный алгоритм контроля перегрузки Brutal и как правильно выставить скорость, чтобы не сделать хуже. Про базовые конфиги — в заметках Hysteria/config-client и Hysteria/config-server. Обзор протокола — Hysteria/00-overview.

TL;DR

  • Контроль перегрузки (congestion control) — это алгоритм, решающий, как быстро слать данные, чтобы не забить канал. Hysteria умеет три: Brutal (свой), BBR и Reno.
  • Наличие секции bandwidth в конфиге — это и есть переключатель Brutal для данного направления. Есть bandwidth → работает Brutal; нет → работает BBR (по умолчанию).
  • Brutal держит фиксированную заданную скорость и не сбрасывает её при потерях пакетов — за счёт этого «выигрывает» полосу на перегруженных и потерянных каналах. Отсюда и название.
  • Плата за это: скорость надо задать точно и чуть ниже реального максимума канала. Завысите — получите перегрузку, потери и нестабильность вместо ускорения.
  • Для личного сервера проще всего: на сервере bandwidth НЕ указывать, а задать его только на клиенте — тогда Brutal возьмёт клиентские значения.

Что такое контроль перегрузки простыми словами

Когда программа шлёт данные в сеть, она не знает заранее, сколько канал вытянет. Алгоритм контроля перегрузки — это стратегия «прощупывания»: слать быстрее, пока не начнутся потери пакетов, потом притормозить. Разные алгоритмы реагируют на потери по-разному, и именно это определяет итоговую скорость.

Классические TCP-алгоритмы (Reno, Cubic) считают потерю пакета сигналом «канал перегружен» и резко снижают скорость. Это разумно в проводной сети, где потеря почти всегда означает затор. Но в мобильной сети, на дальней международной линии или через перегруженный трансграничный стык пакеты теряются не из-за затора, а из-за качества канала. Классический алгоритм в такой ситуации постоянно «пугается» и держит скорость намного ниже возможной.

Три алгоритма Hysteria

BBR (Google) — оценивает пропускную способность по измерению задержек, а не по потерям. Работает сам по себе, bandwidth ему не нужен. Это разумный дефолт, если вы не хотите вручную задавать скорость. Тот же BBR, кстати, полезно включить и на уровне ядра сервера для TCP-соединений — см. VPS/BBR.

Reno — простой и консервативный алгоритм по умолчанию из библиотеки quic-go. Выбирается через congestion.type: reno.

Brutal — фирменный алгоритм Hysteria. Работает по модели фиксированной скорости: не снижает темп в ответ на потери или изменения задержки. Если не дотягивает до целевой скорости, он вычисляет процент потерь и компенсирует их, отправляя избыточные пакеты. Это очень эффективно «захватывает» полосу в перегруженных сетях с негарантированной доставкой — но работает, только если вы точно знаете и правильно указываете реальный максимум канала.

[!warning] Brutal работает, только если вы честно указали скорость Brutal не измеряет канал сам — он верит вашему числу в bandwidth и старается его выдать любой ценой. Задайте меньше реального максимума — Brutal просто сработает как ограничитель скорости, ничего страшного. Но задайте БОЛЬШЕ, чем канал физически тянет, — и вы получите постоянные потери, нестабильное соединение и впустую потраченный трафик. Правило: ставьте значение чуть ниже реальной пропускной способности.

Как включается Brutal

Ключевой момент: само наличие секции bandwidth для направления решает, использовать ли Brutal. Если для направления bandwidth задан — работает Brutal; если нет — работает обычный контроль из секции congestion (по умолчанию BBR со стандартным профилем).

Направления независимы. На клиенте:

bandwidth:
  up: 20 mbps
  down: 100 mbps

Если задать только up (или только down), то это направление пойдёт через Brutal, а другое — через BBR.

Поддерживаемые единицы: bps/b, kbps/kb/k, mbps/mb/m, gbps/gb/g, tbps/tb/t.

Как договариваются клиент и сервер

Значения bandwidth на сервере работают как лимит скорости (потолок на каждого клиента), причём отдача сервера — это загрузка клиента, и наоборот. Итоговая скорость выбирается так:

  • Клиент задал bandwidth → используется Brutal. Если сервер тоже задал bandwidth, берётся меньшее из двух значений; если сервер не задавал — берётся клиентское.
  • Клиент не задал bandwidth → это направление идёт через не-Brutal контроль (BBR/Reno).
  • На сервере включён ignoreClientBandwidth: true → сервер игнорирует любые клиентские значения и всегда использует свой локальный не-Brutal контроль. Полезно, если владелец сервера не доверяет пользователям в честном указании скорости.

[!tip] Простой рецепт для личного сервера Если сервер только для себя, не усложняйте: на сервере уберите bandwidth и ignoreClientBandwidth вообще, а скорость задайте только на клиенте. Тогда логика однозначна — есть клиентский bandwidth → работает Brutal с клиентскими значениями; нет → работает BBR. Настройку скорости держите в одном месте (клиент), это проще отлаживать.

[!note] Серверный лимит bandwidth влияет только на Brutal Значения bandwidth на сервере ограничивают скорость только когда используется Brutal. На BBR и Reno они не действуют — это местный ограничитель именно для Brutal-режима.

Важно: Hysteria не «ускоряет» UDP-протоколы

Ускорение Brutal касается TCP-трафика, который заворачивается в QUIC. UDP-трафик (например, сам HTTP/3) Hysteria не ускоряет — она не уменьшает потери UDP, скорость таких соединений зависит от контроля перегрузки конечного сервера и браузера. Поэтому проксировать HTTP/3 через Hysteria смысла нет: наоборот, HTTP/3 в браузере на PC лучше отключить, чтобы он падал обратно на TCP-based HTTP/2, который Hysteria действительно ускоряет. В Chrome: chrome://flags/Experimental QUIC protocolDisabled. В Firefox: about:confignetwork.http.http3.enablefalse.

📚 См. также


[!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: исходник этой заметки · весь репозиторий.