Zapret Wiki

Недавно обновлено

время чтения ~5 мин.

.md

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

О чём заметка

Почему у Hysteria есть поле bandwidth, как работает фирменный алгоритм контроля перегрузки Brutal и как правильно выставить скорость, чтобы не сделать хуже. Про базовые конфиги — в заметках клиент и сервер. Обзор протокола — тут.

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-соединений — см. включение BBR на VPS.

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

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

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 контроль. Полезно, если владелец сервера не доверяет пользователям в честном указании скорости.

Простой рецепт для личного сервера

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

Серверный лимит 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 protocol → Disabled. В Firefox: about:config → network.http.http3.enable → false.

📚 См. также

🤖 Эти статьи открыты — можно обучать на них ИИ

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

Вид графа

Обратные ссылки