Статья подготовлена в рамках исследовательского проекта CloudBridge Research, посвященного оптимизации сетевых протоколов (BBRv3, MASQUE, FEC, QUIC).

Проект: github.com/cloudbridge-research/quic-test

Видео-демонстрация работы quic-test

Предыстория

Ранее мы публиковали на Хабре результаты наших исследований современных сетевых протоколов. В статье «CloudBridge Research: открываем результаты исследований QUIC/MASQUE и приглашаем к сотрудничеству» мы рассказали о нашей исследовательской инициативе и о том, зачем мы делаем сетевые эксперименты доступными для университетов и небольших команд. В статье «BBRv3, FEC и QUIC: как мы удержали jitter <1 мс и стабилизировали RU↔EU» мы поделились конкретными результатами: как нам удалось стабилизировать QUIC на реальных межрегиональных трассах, получить jitter <1 мс PoP↔PoP и P50 ~20–21 мс RU↔EU.

В обеих статьях мы упоминали наш инструмент quic-test, с помощью которого проводили все измерения. Теперь настало время рассказать о нем подробнее. Это не просто очередной бенчмарк — это полноценная лабораторная среда, которую мы используем для реальных исследований и которую может развернуть любой желающий.

Зачем мы это сделали

Когда мы начинали исследовать поведение QUIC, BBRv3 и Forward Error Correction в реальных сетях — от Wi-Fi до мобильных каналов и региональных магистралей — столкнулись с простой проблемой: готовых инструментов для честного воспроизведения условий реальных сетей практически нет.

Можно использовать iperf3, но он про TCP и базовый UDP. Можно взять отдельные QUIC-библиотеки, но без визуализации и нагрузки. Можно написать кастомные симуляторы, но они не отражают реального поведения каналов. Хочешь проверить, как BBRv3 ведет себя на трассе Москва — Новосибирск? Пожалуйста, найди три сервера в разных дата-центрах, настрой netem, собери метрики вручную и надейся, что результаты будут воспроизводимы.

Полноценного QUIC-тестера с графиками, профилями каналов, FEC, BBRv3, TUI и Prometheus-метриками не было. Поэтому мы сделали quic-test — открытый инструмент, который мы сами используем в лаборатории CloudBridge для всех наших исследований. Теперь делимся им с сообществом, вузами и инженерами.

Что такое quic-test

Это открытая лабораторная среда для анализа поведения QUIC, BBRv3 и FEC в реальных сетях. Не симулятор, а инженерный инструмент — все наши исследования основаны на измерениях, полученных с его помощью.

Кому будет полезен quic-test

Сетевым инженерам — сравнить TCP/QUIC/BBRv3 в своих сетях, понять, где QUIC дает реальное преимущество.

SRE и DevOps — протестировать поведение сервисов в условиях потерь пакетов и высокого RTT, подготовиться к проблемам до их появления в продакшене.

Преподавателям и студентам — проводить современные лабораторные работы по сетевым протоколам с реальными метриками и визуализацией.

Исследователям — собирать метрики для ML-моделей маршрутизации, публиковать воспроизводимые результаты.

Основные возможности

Протоколы: QUIC (RFC 9000), HTTP/3, 0-RTT соединения.

Congestion Control: BBRv2 (стабильный), BBRv3 (экспериментальный), CUBIC, Reno.

Forward Error Correction: XOR-FEC (работает), RS-FEC (в разработке).

Профили сетей: mobile (4G/LTE), wifi, lossy (3-5% потерь), high-latency (региональные трассы). Основаны на реальных измерениях в наших Edge PoP узлах.

Метрики: Prometheus, Grafana, TUI-визуализация (quic-bottom на Rust).

Сравнение: TCP vs QUIC в одинаковых условиях.

Быстрый старт

Установка через Docker

Самый простой способ начать — использовать готовые Docker-образы:

# Запуск клиента (тест производительности)
docker run mlanies/quic-test:latest --mode=client --server=demo.quic.tech:4433

# Запуск сервера
docker run -p 4433:4433/udp mlanies/quic-test:latest --mode=server

Сборка из исходников

Для тех, кто хочет модифицировать код или собрать под свою платформу:

git clone https://github.com/twogc/quic-test
cd quic-test

# Сборка FEC библиотеки (требует clang)
cd internal/fec && make && cd ../..

# Сборка основного инструмента (требует Go 1.21+)
go build -o quic-test cmd/quic-test/main.go

# Запуск
./quic-test --mode=client --server=demo.quic.tech:4433

Первый тест: QUIC против TCP

Именно такие тесты мы проводили для наших исследований. Запускаем сервер:

./quic-test --mode=server --listen=:4433

Клиент с базовым тестом:

./quic-test --mode=client --server=127.0.0.1:4433 --duration=30s

Сравнение QUIC и TCP — то, что мы делали сотни раз:

./quic-test --mode=client --server=127.0.0.1:4433 --compare-tcp --duration=30s

TUI визуализация в реальном времени:

quic-bottom --server=127.0.0.1:4433

Результаты включают RTT (минимальное, максимальное, среднее), jitter, throughput, retransmissions, packet loss, FEC recovery и fairness при параллельных тестах. Именно эти метрики мы анализировали, когда получали jitter <1 мс на PoP↔PoP.

Профили реальных сетей

В инструмент встроены профили типичных условий, основанные на реальных измерениях в наших Edge PoP узлах CloudBridge (Moscow, Frankfurt, Amsterdam).

Mobile профиль (4G/LTE)

Профиль --profile=mobile эмулирует мобильный канал 4G/5G с RTT 50-150 мс (среднее 80 мс), пропускной способностью 5-50 Мбит/с (среднее 20 Мбит/с), потерями пакетов 0.1-2% (среднее 0.5%) и jitter 10-30 мс (среднее 15 мс). Именно на этом профиле мы тестировали FEC и получили прирост goodput ~+10% при 5% потерь.

WiFi профиль

Профиль --profile=wifi имитирует Wi-Fi с микропросадками и burst-потерями, характерными для беспроводных сетей в офисах и домах. Мы использовали этот профиль для тестирования стабильности соединений при переключении между точками доступа.

Lossy профиль

Профиль --profile=lossy создает стабильные 3-5% потерь, что полезно для симуляции нестабильных каналов. На этом профиле мы проверяли эффективность FEC recovery.

High-latency профиль

Профиль --profile=highlat эмулирует региональные трассы с RTT 50-150 мс, характерные для межрегиональных соединений. Именно такие условия были на наших RU↔EU трассах.

Пример использования:

./quic-test --mode=client --profile=mobile --compare-tcp --duration=60s

Кастомные профили

Для точной настройки условий можно создать свой профиль:

./quic-test --mode=client --profile=custom \
  --rtt=100ms \
  --bandwidth=10mbps \
  --loss=1% \
  --jitter=20ms

Метрики и интеграция с Grafana

Именно так мы собирали данные для всех наших исследований. Запуск с Prometheus-экспортом:

./quic-test --mode=server --prometheus-port=9090

Доступные метрики

Метрики доступны по адресу http://localhost:9090/metrics и включают:

quic_rtt_ms — Round-Trip Time в миллисекундах
quic_jitter_ms — вариация задержки (именно ее мы удерживали <1 мс)
quic_loss_total — общее количество потерянных пакетов
fec_recovered — пакеты, восстановленные через FEC
tcp_goodput_mbps и quic_goodput_mbps — полезная пропускная способность
bbrv3_bandwidth_est — оценка пропускной способности от BBRv3
quic_datagram_rate — частота отправки датаграмм
connection_drops — количество разорванных соединений
queue_delay_ms — задержка в очереди (bufferbloat)

Метрики подключаются к Grafana за 15 секунд. Мы используем эти данные для визуализации результатов тестов и для интеграции с AI Routing Lab — нашим проектом по обучению моделей предсказания оптимальных маршрутов.

Примеры из наших исследований

Покажем два характерных кейса, которые демонстрируют возможности quic-test. Полные отчеты с методологией и командами для воспроизведения доступны в docs/reports/ и в наших предыдущих статьях.

Кейс 1: Mobile профиль (5% потерь)

Условия: 4G/LTE сеть, 5% потерь пакетов, RTT ~80 мс.

Результаты:

Метрика	Baseline QUIC	QUIC + FEC 10%	Прирост
Goodput	3.628 Mbps	3.991 Mbps	+10%
Jitter	0.72 мс	0.72 мс	стабильно
RTT P50	51.25 мс	51.25 мс	стабильно

TCP с CUBIC при тех же условиях показывает деградацию в 4-6 раз.

Вывод: FEC с 10% избыточностью дает реальный прирост производительности на мобильных сетях с потерями, при этом не увеличивая задержку.

Кейс 2: VPN-туннели с высокими потерями (10%)

Условия: Эмуляция нестабильного канала, 10% потерь пакетов, RTT 100 мс.

Результаты:

Метрика	TCP	QUIC	QUIC + FEC 15%	Прирост
Throughput	25 Mbps	45 Mbps	68 Mbps	+172%
Retransmissions	18,500	12,200	3,800	-79%
P99 RTT	450 мс	320 мс	210 мс	-53%

Вывод: QUIC с FEC критически важен для VPN-туннелей в условиях высоких потерь. Избыточность 15% оптимальна для 10% loss rate.

Другие кейсы

Мы также тестировали:

PoP↔PoP (Moscow—Frankfurt—Amsterdam): jitter <1 мс, connection time 9.20 мс
BBRv2 vs BBRv3 на спутниковых профилях: BBRv3 дает +16% throughput при RTT 600 мс
Production профиль (0.1% loss): 9.258 Mbps goodput при 30 параллельных соединениях

Подробности в docs/reports/ репозитория.

Использование в университетах

quic-test изначально задумывался как лабораторный стенд для образовательных целей. Мы хотели, чтобы студенты могли не просто читать про QUIC и BBRv3, а реально экспериментировать с этими технологиями.

Готовые лабораторные работы

Сейчас подготовлены лабораторные работы по сле��ующим темам:

ЛР #1: Основы QUIC — исследование RTT и jitter, handshake, 0-RTT resumption, миграция соединений. Студенты видят, как QUIC устанавливает соединение быстрее TCP и как работает 0-RTT.

ЛР #2: Сравнение TCP и QUIC — производительность в различных условиях, влияние потерь, head-of-line blocking. Именно здесь становится понятно, почему QUIC лучше справляется с потерями.

ЛР #3: Влияние потерь и FEC — как Forward Error Correction помогает на нестабильных каналах, оптимальные параметры избыточности, trade-off между overhead и recovery.

ЛР #4: BBRv3 vs CUBIC — сравнение алгоритмов управления перегрузкой, bandwidth probing, pacing control, влияние на bufferbloat.

ЛР #5: NAT traversal и P2P — ICE, STUN, TURN, установление прямых соединений через NAT.

ЛР #6: HTTP/3 performance — производительность HTTP/3 vs HTTP/2, multiplexing без head-of-line blocking.

Учебные материалы включают готовые сценарии, методологию проведения экспериментов и шаблоны отчетов. Все материалы доступны в директории docs/labs/ репозитория. Мы открыты для интеграции с курсами в вузах и готовы помочь с адаптацией материалов.

Архитектура

Подробная схема доступна в docs/ARCHITECTURE.md. Вкратце:

Go-ядро — транспорт, QUIC-логика, измерения. Используется quic-go v0.40 с поддержкой BBRv2 и экспериментальной поддержкой BBRv3.

TUI на Rust — quic-bottom обеспечивает визуализацию метрик в реальном времени с графиками и таблицами.

FEC-модуль на C++ — использует AVX2 SIMD-оптимизации, чтобы не становиться узким местом даже на каналах десятки Гбит/с. Сейчас стабилен XOR-FEC, RS-FEC — экспериментальный.

Метрики — Prometheus client, HDR histograms для точного расчета перцентилей (P50, P95, P99), экспорт в JSON/CSV/Markdown.

Network emulation — token bucket для bandwidth limiting, delay queue для RTT, random drop для packet loss. Так создаются профили mobile, wifi, lossy.

Статус проекта

Стабильные функции — QUIC client/server, сравнение TCP/QUIC, профили сетей, Prometheus-экспорт, TUI-визуализация. Используем ежедневно в наших исследовательских стендах.

Экспериментальные — BBRv3, RS-FEC, MASQUE CONNECT-IP, TCP-over-QUIC. Показывают хорошие результаты, но требуют дополнительного тестирования.

В планах — автоматическая пост-обработка графиков, eBPF-инспектор задержек, мини-PoP контейнер. Полный roadmap в docs/roadmap.md.

Зачем мы открыли проект

Проект развивается в рамках CloudBridge Research. В 2025 году мы зарегистрировали АНО «Центр исследований и разработок сетевых технологий» — независимый ��сследовательский центр, который занимается сетевыми протоколами и образовательными программами.

Наша цель — создать открытый стек инструментов для сетевых инженеров и университетов. Мы верим, что открытые исследования ускоряют развитие технологий и делают их доступными для всех.

Связанные проекты

quic-test — часть экосистемы CloudBridge Research.

AI Routing Lab — использует метрики quic-test (RTT, jitter, throughput) для обучения моделей, которые предсказывают, какой маршрут будет лучше в ближайшие минуты. Цель — точность >92% при прогнозировании задержки.

masque-vpn — исследовательский VPN на MASQUE/QUIC, который мы нагрузочно тестируем с помощью quic-test, в том числе для кейсов с высокими потерями.

Все проекты открыты, с готовыми лабораторными для студентов. Подробнее расскажем в отдельной статье.

Как воспроизвести наши результаты

Все команды и конфигурации доступны в репозитории.

Версии:

Go: 1.25+
quic-go: v0.40.0
OS: macOS или Linux
MTU: 1200 байт (стандарт для QUIC)

Production профиль (0.1% loss, 20 мс RTT):

# Сервер
./quic-test --mode=server --listen=:4433 --prometheus-port=9090

# Клиент (30 соединений, BBRv3)
./quic-test --mode=client \
  --server=<server-ip>:4433 \
  --connections=30 \
  --duration=60s \
  --congestion=bbrv3 \
  --profile=custom \
  --rtt=20ms \
  --loss=0.1%

Mobile профиль (5% loss) с FEC:

# Сервер с FEC
./quic-test --mode=server \
  --listen=:4433 \
  --fec=true \
  --fec-redundancy=0.10

# Клиент
./quic-test --mode=client \
  --server=<server-ip>:4433 \
  --profile=mobile \
  --fec=true \
  --fec-redundancy=0.10 \
  --duration=60s

Остальные сценарии (BBRv2 vs BBRv3, спутниковые профили, VPN-туннели) описаны в scripts/ и docs/reports/ репозитория.

Контрибуции и обратная связь

Мы открыты для issues, pull requests, реальных отчетов о тестах, предложений по расширению функциональности и интеграции с курсами в вузах. Если вы используете quic-test в своих исследованиях или в учебном процессе — будем рады узнать об этом.

GitHub: ggithub.com/cloudbridge-research/quic-test
Email: info@cloudbridge-research.ru
Блог: cloudbridge-research.ru
Наши статьи на Habr:

Итог

Если вам нужно честно посмотреть, как ведет себя QUIC, BBRv3 и FEC в реальной сети — от Wi-Fi до мобильного или региональных трасс — попробуйте quic-test.

Все результаты воспроизводимы — мы предоставляем точные команды и конфигурации. Все инструменты открыты. Это живой инженерный проект, который мы развиваем вместе с сообществом.

Попробуйте, воспроизведите наши результаты, поделитесь своими. Вместе мы делаем сети лучше.

quic-test: открытый инструмент для тестирования QUIC, BBRv3 и FEC в реальных условиях