08b4491545
Some checks failed
Published content check / validate (push) Failing after 3s
Обновить правила репозитория и подписи исходников в 99 заметках, не затрагивая пользовательские незакоммиченные файлы. Сделать Forgejo Actions содержательным: проверять опубликованный commit, а не пустое рабочее дерево после checkout.
90 lines
11 KiB
Markdown
90 lines
11 KiB
Markdown
---
|
||
date: 2026-07-11
|
||
tags:
|
||
- hysteria
|
||
- скорость
|
||
- congestion-control
|
||
- brutal
|
||
- bbr
|
||
aliases:
|
||
- Hysteria Brutal
|
||
- Hysteria bandwidth
|
||
- Hysteria скорость
|
||
link: 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|включение BBR на VPS]].
|
||
|
||
**Reno** — простой и консервативный алгоритм по умолчанию из библиотеки quic-go. Выбирается через `congestion.type: reno`.
|
||
|
||
**Brutal** — фирменный алгоритм Hysteria. Работает по модели **фиксированной скорости**: не снижает темп в ответ на потери или изменения задержки. Если не дотягивает до целевой скорости, он вычисляет процент потерь и компенсирует их, отправляя избыточные пакеты. Это очень эффективно «захватывает» полосу в перегруженных сетях с негарантированной доставкой — но работает, только если вы точно знаете и правильно указываете реальный максимум канала.
|
||
|
||
> [!warning] Brutal работает, только если вы честно указали скорость
|
||
> Brutal не измеряет канал сам — он верит вашему числу в `bandwidth` и старается его выдать любой ценой. Задайте меньше реального максимума — Brutal просто сработает как ограничитель скорости, ничего страшного. Но задайте БОЛЬШЕ, чем канал физически тянет, — и вы получите постоянные потери, нестабильное соединение и впустую потраченный трафик. Правило: ставьте значение чуть ниже реальной пропускной способности.
|
||
|
||
## Как включается Brutal
|
||
|
||
Ключевой момент: **само наличие секции `bandwidth` для направления решает, использовать ли Brutal.** Если для направления `bandwidth` задан — работает Brutal; если нет — работает обычный контроль из секции `congestion` (по умолчанию BBR со стандартным профилем).
|
||
|
||
Направления независимы. На клиенте:
|
||
|
||
```yaml
|
||
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 protocol` → `Disabled`. В Firefox: `about:config` → `network.http.http3.enable` → `false`.
|
||
|
||
## 📚 См. также
|
||
|
||
- [[Hysteria/config-client|Конфиг клиента]] — где именно задаётся `bandwidth`.
|
||
- [[Hysteria/config-server|Конфиг сервера]] — серверные лимиты и `ignoreClientBandwidth`.
|
||
- [[VPS/BBR|Включение BBR на VPS]] — BBR на уровне ядра для TCP-соединений сервера.
|
||
- 🔗 [Congestion control details](https://v2.hysteria.network/docs/advanced/Full-Server-Config/#congestion-control-details) · [Performance](https://v2.hysteria.network/docs/advanced/Performance/)
|
||
|
||
---
|
||
|
||
> [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ
|
||
> При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Hysteria/bandwidth-brutal.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main).
|