Коротко: при высокой задержке и потере TCP‑сессия часто «забуксовывает» из‑за поведения алгоритма управления перегрузкой — потеря пакета воспринимается как сигнал перегрузки и окно уменьшают, что при большом RTT и ненулевой потере даёт очень низкую среднюю пропускную способность. Ниже — разбор алгоритмов, что измерять и какие изменения можно применить.
1) Как работают алгоритмы управления перегрузкой
- Reno (AIMD): рост окна по одному MSS за RTT в медленном старте/конгест‑авоиде (additive increase), при потере — multiplicative decrease (окно делят на $2$). Чувствителен к потере: при вероятности потери $p$ средняя пропускная способность аппроксимируется как
$$\text{Throughput}\approx \frac{1.22\cdot MSS}{RTT\sqrt{p}}.$$ - CUBIC: вместо линейного роста использует кубическую функцию времени от последнего уменьшения окна, рост менее зависит от RTT (лучше на высоких BDP). При потере также уменьшается окно, но восстановление агрессивнее, чем у Reno.
- BBR: измеряет доступную пропускную способность (bottleneck bandwidth) и RTT, формирует оконo по оценкам BDP и использует pacing. BBR не считает потерю прямым сигналом перегрузки (в v1), поэтому на каналах с потерями может держать стабильную скорость; BBRv2 учитывает потерю как дополнительный сигнал.
2) Основные метрики для диагностики
- RTT (median, min, max), jitter: $RTT$.
- Потеря пакетов: доля потерянных пакетов $p$ (в процентах).
- CWND, SSTHRESH, flight size, pacing rate.
- Количество реконсипций/повторных передач (retransmits), dupacks, RTO события.
- Throughput (полезная скорость), goodput (без заголовков).
- Bufferbloat (задержка при загрузке).
- ECN‑бит и SACK использование.
Полезные формулы/оценки:
- BDP: $$\text{BDP}=\text{bandwidth}\times RTT.$$ - TCP‑throughput (приближённо): см. формулу выше.
3) Инструменты и как их применять
- tcpdump: захват пакетов для анализа потерянных/повторно отправленных сегментов, временных промежутков между retransmit, ECN флагов. Комментарий: смотрите TCP flags, SACK блоки, последовательности и времена (timestamps).
- ss (или netstat): смотреть состояние сокета: cwnd, rto, retransmits, RTT оценки. Примеры: посмотреть детальную статистику сокета и cwnd/rtt/pacing info (используйте опции вроде «ss -tin» / «ss -i»).
- iperf/iperf3: измерение achievable throughput по TCP/UDP, экспериментирование с числом потоков, размером окна ($-w$), режимом UDP с измерением потерь/джиттера. Используйте тесты с различными размерами окна, с несколькими параллельными потоками, и c/без pacing.
Диагностический план (коротко):
- замерить пиковую пропускную способность канала вне TCP (iperf UDP).
- оценить BDP и выставить соответствующие буферы $\text{send/recv buffer}\approx \text{BDP}$.
- захват tcpdump, искать retransmits/dupacks/ECN.
- ss для cwnd и rtt, оценить, насколько cwnd << BDP.
- варьировать congestion control (tcp_congestion_control = cubic/bbr) и повторить тесты.
4) Что изменить на уровне протокола или приложения
- Тюнинг TCP:
- включить SACK, tcp_timestamps, увеличить tcp_rmem/tcp_wmem под BDP.
- смена алгоритма: CUBIC зачастую лучше на больших BDP; BBR может дать большую скорость при потере, но осторожно (bufferbloat, fairness).
- Перейти на QUIC:
- QUIC над UDP даёт быструю handshake, лучшее мультистриминг/потоковая гибкость и современные CC (можно использовать BBR, CUBIC, или адаптивные алгоритмы). QUIC часто восстанавливает быстрее при потерях и упрощает deploy FEC.
- Использовать UDP + FEC / приложение‑уровневый ARQ:
- для интерактивных/реальных‑времени приложений (видео, VoIP) FEC снижает чувствительность к отдельным потерям. Нужно подобрать кодирование (Reed‑Solomon, Raptor) и overhead $\alpha$ (например, добавить $\alpha =$ поправку в процентах) в зависимости от потерь $p$.
- Адаптивный congestion control:
- применять алгоритмы, ориентированные на пропускную способность/задержку (BBR v2, PCC, Copa), или комбинированные решения, которые учитывают и потерю, и задержку.
- Многопоточность/мультиплекс: несколько параллельных TCP‑соединений (или потоков в QUIC) могут повысить суммарную throughput в условиях случайных потерь, но портят fairness.
- Приложенческая стратегия: уменьшать чувствительность к задержке (buffering, адаптивный кодек, rate control), использовать адаптивный ARQ+FEC и быстрое восстановление.
5) Рекомендации при высокой задержке и потере
- если потеря сигнальная (в следствие перегрузки): настроить AQM/ECN (CoDel/PIE + ECN) на маршрутизаторах.
- если потеря случайная (ссылка беспроводная): рассмотреть UDP+FEC или QUIC с FEC и BBRv2/PCC.
- тюнить буферы по BDP: увеличить tcp_rmem/tcp_wmem до примерно $\text{BDP}$.
- тестировать: переключать congestion control (=cubic/bbr), собирать tcpdump+ss+iperf и сравнивать throughput/jitter/потери.
Если нужно, могу привести конкретные команды для измерений и примеры расчёта BDP/настроек в вашем окружении — укажите тип канала, RTT и целевую полосу.