Кратко — вывод: для видеоконференций в мобильных сетях с высокой потерей и переменной задержкой QUIC обычно лучше TCP, особенно если использовать QUIC DATAGRAM + прикладные FEC/приоритеты; TCP страдает из‑за HOL‑блокировки и жесткой надежности.
Сравнение по пунктам:
- Управление подключением
- TCP: привязка к 4‑tuple (IP:port). Реконнект при смене IP/моб.точки доступа — долгий. TLS handshake — дополнительный RTT.
- QUIC: сокрытие TLS внутри транспорта, поддержка 0‑RTT и встроенная миграция соединения (connection migration). Быстрее восстановление при смене IP/сети.
- Следствие: в мобильных условиях QUIC уменьшает простои при хэндовере и ускоряет установку.
- Мультиплексирование потоков
- TCP (HTTP/2/HTTP/3 на TCP через TLS): при потере пакета — HOL‑блокировка для всех потоков поверх того же TCP‑сессии (особенно критично при HTTP/2).
- QUIC: независимые потоки без транспортного HOL‑блокирования; дополнительно — DATAGRAM (неподтверждаемые, неупорядоченные) для нужд реального времени.
- Следствие: для аудио/видео/сигналинга QUIC позволяет избегать задержек одного потока из‑за потерь в другом.
- Восстановление после потерь
- TCP: надежные ретрансляции, RTO зависят от RTT/дрейфа; в условиях высокой случайной потери TCP снижает скорость (интерпретирует потери как перегрузку).
- QUIC: современный механизм обнаружения потерь (ACK ranges, более гибкие таймеры), быстрая локальная корректировка; но также подвержен снижению при loss‑based CC. QUIC DATAGRAM позволяет не репендить на ретрансмиссии (безнадежная доставка).
- Следствие: при случайных потерях выгодно комбинировать QUIC с приложенческой FEC / датаграмами и продуманной CC.
- Задержки в мобильных сетях (высокая потеря + переменная RTT)
- TCP: увеличение RTO и повторные попытки сильно увеличивают хвост задержки; HOL‑блокировка усугубляет интерактивность.
- QUIC: меньше HOL, 0‑RTT/connection migration помогают; однако при loss‑based CC (Cubic) пропускная способность и задержка падают при непереносимых потерях. BBR‑подходы могут держать низкую задержку, но чувствительны к неправильной телеметрии в мобильной среде.
- Следствие: протокол — QUIC; но нужно адаптировать конгестион‑контроль и применять прикладные меры.
Рекомендации разработчику реального‑временного приложения (в порядке важности)
1. Протокол
- Основной выбор: QUIC (UDP‑основанный) с использованием DATAGRAM для аудио/видео пакетной доставки и независимыми потоками для сигналинга/контроля. Причина: отсутствие транспортного HOL и поддержка миграции/0‑RTT.
- Если QUIC недоступен — обычный UDP (WebRTC/SRTP) с TURN/ICE; избегать TCP для медиа.
2. Надежность и потеря
- Использовать прикладной FEC (например, синхронный паритет или Reed‑Solomon) с начальной ставкой избыточности $\approx 10\%-20\%$ и адаптацией по текущей потере.
- Ограничивать ретрансмиссии: ретрансмиссировать только ключевые кадры/сигнальные сообщения, не все фреймы.
- Для ненадежной/свободной доставки — применять QUIC DATAGRAM; для маленького контролируемого порядка — использовать легкие приоритетные потоки.
3. Конгестион‑контроль и таймеры
- Включить пакетную пауза/pacing (пейсинг) — снижает кластеризацию пакетов и джиттер.
- Рассмотреть BBRv2 или другой delay‑sensitive CC как кандидат; тестировать в реальных сетях. Как запас — настроить loss‑based CC с мягкой реакцией на одиночные потери (не слишком агрессивное падение скорости).
- Начальное окно: стандартное $\mathrm{IW}=10$ MSS приемлемо; но не увеличивать без тестов.
- Уменьшить max_ack_delay/ACK‑decimation для более быстрой детекции потерь — целевой максимум $\le 25\mathrm{ms}$.
4. Пакетизация и MTU
- Избегать фрагментации; целевой размер пакета около Path MTU, минимум $\approx 1200$ байт для QUIC.
- Разбивать видео на независимые небольшие RTP/QUIC‑датаграммы, чтобы потеря одного пакета не уничтожала большой фрейм.
5. Приоритеты и потоковая архитектура
- Отдельные потоки/датаграммы: аудио — высший приоритет и предпочтительно без ретрансмиссий; видео — низший приоритет, с FEC/периодическим ключевым кадром.
- Применять SVC/слоистое кодирование, чтобы адаптировать качество без полной реконфигурации потока.
6. Jitter buffer и плейаут
- Адаптивный джиттер‑буфер с целью общей целевой задержки (односторонняя) $\approx 100-250\mathrm{ms}$ в зависимости от UX; при плохой сети увеличивать буфер, при хорошей — сокращать.
- Отбрасывать поздние пакеты вместо попыток «подтянуть» их по таймауту.
7. Мониторинг и адаптивность
- Реализовать измерения loss/RTT/jitter и менять FEC, битрейт, количество потоков, CC в реальном времени.
- Профилировать реальные сети (ручная A/B проверка: BBR vs Cubic и параметры ACK).
Коротко почему: QUIC уменьшает задержки за счёт отсутствия транспортного HOL и поддерживает миграцию/0‑RTT; DATAGRAM+FEC компенсируют случайные потери; адаптивный CC+pacing и правильные ACK/таймеры уменьшают хвосты задержки; приоритизация аудио и отбрасывание устаревших пакетов сохраняют интерактивность.
Если нужно — дам конкретные стартовые значения конфигурации (ACK таймер, FEC параметры, pacing, CC выбор) для вашей цели (аудио/видео/целевой латентности).