# Speed limits and congestion policy

## Цель документа

Зафиксировать корректную speed policy без неточных упрощений.

## Что нельзя считать правильной схемой

Нельзя описывать baseline так:
- на сервере включили host BBR
- выдали какой-то URI
- автоматически получили строгий лимит 50 Mbps на клиента

Это неверная модель.

## Три разные вещи, которые нельзя смешивать

Это главный источник путаницы в теме скоростей Hysteria.

| Механизм | Что это | Где задаётся |
| --- | --- | --- |
| **Политика HY2XS 50/50** | продуктовое решение проекта, сколько давать клиенту | `HY2XS_HYSTERIA_BANDWIDTH_UP` / `_DOWN` |
| **Brutal bandwidth** | режим Hysteria, работающий по согласованным сторонами значениям полосы | `bandwidth.up` / `bandwidth.down` на сервере + hints на клиенте |
| **Fallback congestion controller** | что делает Hysteria, когда Brutal не применяется | `congestion.type` / `congestion.bbrProfile` |

`50 mbps` здесь — **не** «оптимальная скорость Hysteria» и не свойство протокола. Это политика HY2XS.

## Что зафиксировано в baseline

### На сервере
- `bandwidth.up = 50 mbps`
- `bandwidth.down = 50 mbps`
- `bandwidth.disableLossCompensation = false`
- `ignoreClientBandwidth = false`
- `congestion.type = bbr`
- `congestion.bbrProfile = standard`

### На клиенте
Совместимый клиентский конфиг должен задавать соответствующие bandwidth hints:
- `up_mbps = 50`
- `down_mbps = 50`

## Практический смысл

Ожидаемый 50/50 Mbps contract считается корректным только тогда, когда сервер и клиентская конфигурация согласованы.

Логика выбора внутри Hysteria:

- когда стороны согласовали Brutal bandwidth — используется Brutal;
- когда это не применяется — используется выбранный fallback congestion controller.

Поэтому BBR тоже является частью явного baseline HY2XS, а не «настройкой по умолчанию, о которой можно не думать».

## Loss compensation

```yaml
bandwidth:
  disableLossCompensation: false
```

Компенсация потерь (появилась в Hysteria 2.10.0) позволяет отправлять быстрее заданной полосы, чтобы компенсировать потерю пакетов. В baseline HY2XS она **включена**, а значение фиксируется в конфиге явно — проект про воспроизводимое поведение, а не про молчаливое следование upstream-дефолтам.

## Что делать с host-level BBR

`net.ipv4.tcp_congestion_control=bbr` можно оставить как общий системный тюнинг, но:

- это не главный механизм speed policy Hysteria2;
- это не замена клиентским bandwidth hints;
- это **не то же самое**, что `congestion.type: bbr` в конфиге Hysteria — у Hysteria собственный congestion-control контур поверх QUIC;
- это не центр документации по лимитам.

## Что фиксировать в `post-install.env`

Минимум:
- `HY2_BANDWIDTH_UP`
- `HY2_BANDWIDTH_DOWN`
- `HY2_IGNORE_CLIENT_BANDWIDTH`
- `HY2_DISABLE_LOSS_COMPENSATION`
- `HY2_CONGESTION_TYPE`
- `HY2_BBR_PROFILE`

Дополнительно фиксируется `HY2_VERSION` как фактически установленная версия Hysteria2 и `HY2_RESOLUTION` как способ её выбора при сборке пакета.

## Что нельзя писать в проектных доках

Не писать:
- «лимит задаётся только на сервере, клиент не важен»
- «любой URI достаточно для полной speed policy»
- «host BBR и есть логика Hysteria»
- «50 mbps — оптимальная скорость Hysteria» (это политика HY2XS, а не свойство протокола)
- «Brutal и congestion controller — одно и то же»

## Правильная baseline-формулировка

Пер-клиентный лимит 50/50 Mbps обеспечивается согласованной серверной и клиентской конфигурацией. Install baseline отвечает за серверную часть этого контракта; конкретный delivery/access слой в этот документ не входит.