Watch

Published content check / validate (push) Failing after 17s

Details

git.zapret.moe → git2.zapret.moe во всём хранилище, защита от возврата старых имён

git.zapret.moe в России заблокирован по имени, как и wiki.zapret.moe. Ссылки
на Forgejo во всех заметках, футерах, wizard.html и главной заменены на
git2.zapret.moe (включая закодированные адреса значков shields.io).

Какое имя рабочее, теперь решают реестры хоста /etc/zapret-*-domains.conf через
zapret-site-names: pre-commit хук vault отклоняет добавленные строки с
заблокированным именем, сборка Quartz сама переводит ссылки и baseUrl на
рабочие имена. Правило в AGENTS.md переписано под этот механизм.

scripts/wiki-stats.py: переходы с любых имён вики и git (wikiN, gitN) больше
не считаются внешними сайтами. content-check: проверка зеркал сторонних
проектов узнаёт любое имя git.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-24 15:51:32 -04:00

12 KiB

Raw Permalink Blame History

date

🦎 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 protocol → Disabled. В Firefox: about:config → network.http.http3.enable → false.

📚 См. также

Hysteria/config-client — где именно задаётся bandwidth.
Hysteria/config-server — серверные лимиты и ignoreClientBandwidth.
VPS/BBR — BBR на уровне ядра для TCP-соединений сервера.
🔗 Congestion control details · Performance

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

12 KiB Raw Permalink Blame History Unescape Escape