5 подписчиков

Экспериментальный QUIC в прод-сетапах: BBRv2, ACK-Frequency, FEC, Greasing

7 октября7 окт

2 мин

Экспериментальный QUIC в прод-сетапах: BBRv2, ACK-Frequency, FEC, Greasing Мы провели серию лабораторных тестов экспериментальной сборки QUIC (fork quic-go) с четырьмя продвинутыми функциями: BBRv2, ACK-Frequency (I-D), FEC для датаграмм и greasing по RFC 9287. Цель - понять, когда это реально дает выигрыш, как настроить параметры и что контролировать в продакшене. Что мы сделали Собрали автоматизированную матрицу: RTT 5–500 мс, нагрузка 100–2000 pps, 1–16 соединений, CUBIC vs BBRv2, ACK-freq 1–5. Сняли qlog-трейсы, Prometheus-метрики, добавили netem-скрипты и готовые Grafana-дашборды для воспроизведения. Описали риски и «страховки»: ProbeRTT-провалы, reordering + ACK-freq, полисеры операторов, CPU на малых RTT. Ключевые результаты (в кратце) - BBRv2 против CUBIC: при RTT ≥50 мс и нагрузке ≥600 pps получаем +20–60% пропускной способности при той же или лучшей задержке/джиттере. - ACK-Frequency (2–4): −15–25% обратного трафика и −10–20% end-to-end задержки за счет реже отправляемых A

Мы провели серию лабораторных тестов экспериментальной сборки QUIC (fork quic-go) с четырьмя продвинутыми функциями: BBRv2, ACK-Frequency (I-D), FEC для датаграмм и greasing по RFC 9287. Цель - понять, когда это реально дает выигрыш, как настроить параметры и что контролировать в продакшене.

Что мы сделали

Собрали автоматизированную матрицу: RTT 5–500 мс, нагрузка 100–2000 pps, 1–16 соединений, CUBIC vs BBRv2, ACK-freq 1–5.

Сняли qlog-трейсы, Prometheus-метрики, добавили netem-скрипты и готовые Grafana-дашборды для воспроизведения.

Описали риски и «страховки»: ProbeRTT-провалы, reordering + ACK-freq, полисеры операторов, CPU на малых RTT.

Ключевые результаты (в кратце)

- BBRv2 против CUBIC: при RTT ≥50 мс и нагрузке ≥600 pps получаем +20–60% пропускной способности при той же или лучшей задержке/джиттере.

- ACK-Frequency (2–4): −15–25% обратного трафика и −10–20% end-to-end задержки за счет реже отправляемых ACK’ов.

- FEC (10–20% реданданс): восстанавливает 80–90% одиночных потерь с минимальным влиянием на задержку - полезно для мобильных/шумных каналов.

- Greasing (RFC 9287): «future-proofing» без деградаций; включаем по умолчанию для контролируемых пиров.

Методология (коротко)

Linux + quic-go (ветка cloudbridge-exp), 30–60-сек тесты, моделирование сети через tc/netem (RTT/потери), измерения через qlog/Prometheus, визуализация в qvis/Grafana. Отдельно прогоняли «реальные» loopback-тесты - они нужны для валидации стека, но сетевые эффекты там обнулены (RTT/потери - только через netem).

Практические рекомендации

Когда выбирать BBRv2: RTT ≥50 мс, нагрузка ≥600 pps, переменные или мобильные сети.

Когда оставить CUBIC: низкие RTT (<25 мс), невысокая нагрузка, стабильные каналы.

ACK-Frequency по умолчанию: 3 (баланс). Для real-time → 4–5, для экономии обратного канала → 2–3.

FEC: 10–15% для типовых условий; 20–25% - для высоких потерь.

Мониторинг: держите в дашборде p50/p95/p99 RTT, delivery_rate, cwnd, pacing_bps, ack cadence, fec_recovered/overhead.

Ограничения и планы

Это лабораторное исследование с контролируемыми пирами. Для широкой интероп-совместимости оставляем fallback на стандартные настройки и аккуратно включаем эксперименты фич-флагами. Дальше - длительные «soak»-прогоны, мультипат, расширение сценариев потерь/джиттера и межстековые interop-замеры.

Присоединяйтесь

Будем рады отзывам, сравнительным прогонам и interop-тестам с другими реализациями QUIC. Пишите в личку.

Материалы для детального изучения:

QUIC Performance Comparison Report

Experimental QUIC Laboratory Research Report