Кратко — по пунктам, с объяснениями.
1) Поведение TCP Tahoe
- Механизм: slow start → congestion avoidance; при потере (любая потеря: тайм-аут или три дупликата) сбрасывает окно в 1 сегмент.
- Правила (формулы): при потере
${\text{cwnd}}_{new}=1,\text{ssthresh}=\frac{\text{cwnd}}{2}$.
- Следствия в мобильной сети: при переменных задержках и случайных потерях (шум, переключение сот) Tahoe часто резко теряет пропускную способность и долго восстанавливается — плохо приспособлен к не‑конгестным потерям.
2) Поведение TCP Reno
- Добавляет fast retransmit + fast recovery: при трёх дубликатах ACK
$\text{ssthresh}=\frac{\text{cwnd}}{2},\text{cwnd}=\text{ssthresh}+3$.
- При тайм-ауте — поведение как Tahoe (cwnd→1).
- Следствия: лучше, чем Tahoe, при одиночных быстрых потерях (не сбрасывает до 1 при каждом событии), но всё ещё чувствителен к случайным (беспроводным) потерям и сильно страдает при высокой вариативности RTT (RTO/таймеры спорадически срабатывают). Резкая вариативность RTT и потери, не связанные с перегрузкой, всё равно интерпретируются как признак перегрузки → излишнее снижение cwnd.
3) Поведение QUIC
- Архитектурные отличия: реализован в user‑space поверх UDP, шифрование (TLS), мультипотоковые независимые потоки (нет head‑of‑line на уровне транспорта), гибкая потеря/периодичность ACK (ACK ranges, более детальный feedback).
- Loss detection и recovery: QUIC использует улучшенные алгоритмы детекции потерь (time threshold + packet number gap), ранние передатчики (TLP), ускорённые повторные передачи; RTO/RTT оценка аналогична TCP, но чаще с более тонким контролем reordering.
- Особенности важные для мобильности:
- Мультипутевые возможности/миграция: QUIC поддерживает изменение IP/портов (connection migration) без разрыва — критично при смене сотовой ячейки/Wi‑Fi↔cell.
- Отсутствие head‑of‑line: пакеты для разных потоков доставляются независимо → меньшая задержка при потере отдельного сегмента.
- Поставляемый фидбек (ACK ranges, timestamps) и гибкость реализации позволяют быстрее отличать потерю от переуплотнения и применять современные CC (CUBIC, BBR и т.д.).
- Следствия: в мобильных сетях QUIC обычно дает меньшую латентность и лучшее удержание пропускной способности при случайных потерях и смене сетей.
4) Роль алгоритма управления перегрузкой (CC)
- TCP Tahoe/Reno — чисто loss‑based; в беспроводных сетях это приводит к ложной интерпретации потерь как перегрузки.
- Современные алгоритмы (BBR, hybrid) ориентируются на оценку пропускной способности и RTT, менее чувствительны к случайным потерям, поэтому в мобильной среде могут показывать существенно лучшие результаты.
- В QUIC легко внедрять и переключать CC в user‑space, что даёт преимущество в адаптации к динамической среде.
5) RTO/RTT и вариативность задержки
- TCP RTO рассчитывается через SRTT и RTTVAR, традиционно
$\text{RTO}=SRTT+\max (G,K\cdot RTTVAR)$ с $K=4$.
- При высокой вариативности RTT RTTVAR растёт → RTO увеличивается или, при неверной оценке, срабатывает преждевременно. QUIC и современные TCP-реализации имеют дополнительные механизмы (TLP, ранняя повторная передача, адаптивные пороги) для снижения влияния нестабильного RTO.
6) Практическая оценка — кто лучше в мобильной сети?
- На практике QUIC (особенно с современным CC, либо BBR) обычно даёт лучшие результаты: меньше видимых пауз, устойчивее throughput при случайных потерях, возможность сохранения сессии при смене сети, отсутствие head‑of‑line для многопотоковых приложений.
- TCP Reno лучше Tahoe, но уступает QUIC по гибкости и по механизмам восстановления. Если сервер/стек TCP использует современные расширения (SACK, FACK, TLP, RACK) и современный CC, разрыв с QUIC уменьшается.
- Ограничения: QUIC зашифрован — некоторые middlebox‑оптимизации недоступны; в старых сетях с плохой UDP поддержкой QUIC может сталкиваться с блокировкой.
Короткое резюме:
- Tahoe: наиболее консервативен → плох в мобильной сети с переменной задержкой и случайными потерями.
- Reno: лучше за счёт fast retransmit/recovery, но всё ещё чувствителен к беспроводным потерям.
- QUIC: лучше приспособлен для мобильности благодаря мультипотоковости (нет head‑of‑line), гибкому loss detection, connection migration и возможности легко использовать современные CC (например, BBR), поэтому чаще даёт лучшие показатели в мобильных сетях.