1) Как TCP обеспечивает надёжность и управление перегрузкой — основные механизмы и краткие пояснения:
- Надёжность:
- Нумерация байт (sequence numbers) и подтверждения (ACK). Пакет считается доставленным только после получения соответствующего ACK (кумулятивные ACK; SACK — Selective ACK — для селективной ретрансляции фрагментов).
- Контроль целостности: 16‑битная контрольная сумма в заголовке.
- Таймеры и повторные передачи: RTO вычисляется на основе оценок RTT: $RTO=SRTT+4\cdot RTTVAR$. При таймауте — повторная передача.
- Быстрая повторная передача (fast retransmit) при получении трёх дублирующих ACK и опциональная быстрая коррекция (fast recovery).
- Устранение ошибок порядка: буферизация и сборка в правильном порядке, отбрасывание дубликатов, обработка out‑of‑order сегментов (с поддержкой SACK эффективнее).
- Управление потоком (flow control):
- Окно приёмника (rwnd) ограничивает количество не подтверждённых данных у отправителя, предотвращая переполнение буфера приёмника.
- Управление перегрузкой (congestion control) — классический набор:
- Slow start: экспоненциальный рост окна каждое RTT пока $cwnd<ssthresh$ (приблизительно удвоение по RTT).
- Congestion avoidance (AIMD): при достижении порога рост становится аддитивным; на каждое подтверждение: $cwnd\leftarrow cwnd+\frac{MS{S}^2}{cwnd}$ (что эквивалентно ≈ $1$ MSS на RTT), при потере — мультипликативное уменьшение: $cwnd\leftarrow \frac{cwnd}{2}$.
- Fast retransmit / fast recovery для быстрого отклика на отдельные потери.
- Модернизации: SACK, TCP timestamps (для лучшей оценки RTT), TLP (tail loss probe), RACK и т.д.
- Пример модельной оценки пропускной способности TCP (приближённо для Reno‑стиля): $\text{Throughput}\approx \frac{MSS}{RTT\sqrt{p}}$, где $p$ — вероятность потери пакета.
2) Когда UDP предпочтительнее:
- Приложения чувствительны к задержке/латентности и допускают потерю пакетов (или реализуют свою логику восстановления): голос/VoIP, видеоконференции (WebRTC), онлайн‑игры, некоторые realtime‑телеметрии.
- Когда нужна multicast/broadcast доставка (UDP поддерживает мультикаст лучше, чем TCP).
- Когда желательна простая модель без установки соединения и с низкой накладной задержкой на установку (например, короткие однонаправленные запросы).
- Когда приложение реализует собственный контроль над надёжностью/повторными передачами, FEC или ARQ, и может оптимизировать поведение под конкретные требования (например, SRT, RIST для вещания).
- Ограничения: UDP даёт меньше гарантий (нет упорядочивания, повторных передач по умолчанию), может блокироваться политиками сети/файрволами.
3) Современные альтернативы и практики для низкой задержки:
- QUIC (RFC и реализация в HTTP/3): транспорт над UDP, предоставляет надёжность, мультиплексирование без head‑of‑line blocking, криптографию TLS 1.3, 0‑RTT установку сессии, pluggable congestion control. Для многих задач низкой задержки и браузерного трафика — предпочтение перед TCP+TLS.
- BBR (Bottleneck Bandwidth and RTT): алгоритм управления перегрузкой, ориентирован на измерение доступной пропускной способности и RTT, часто даёт меньшую латентность по сравнению с AIMD‑схемами (CUBIC).
- CUBIC: дефолтный CC в Linux, улучшен для высокоскоростных сетей (фокус на пропускной способности).
- SCTP, DCCP: специализированные протоколы (SCTP — ассоцированная мультистриминговая надёжность; DCCP — для потоков с групповым контролем перегрузки), но менее распространены в интернете.
- UDP + приложение‑уровневые решения: RTP/RTCP (медиа) с адаптивными кодеками и Congestion Control (например, Google Congestion Control), SRT/ RIST для профессиональной видеопередачи, FEC/forward error correction для уменьшения воздействия потерь без задержек на повторную передачу.
- Практики: использовать QUIC для минимизации HoL и ускоренной установки соединения; применять BBR или адаптивные CC для чувствительных к задержке потоков; комбинировать UDP с FEC и адаптивным кодированием в real‑time мультимедиа.
Короткое практическое правило:
- Нужна полная надёжность и упорядочение — TCP (с современным CC, можно настроить CUBIC/BBR, включить SACK, TLS поверх TCP/QUIC в зависимости от требований).
- Нужна минимальная задержка и мультиплексирование/быстрый запуск — использовать QUIC.
- Нужна маленькая задержка и потеря отдельных пакетов допустима (реaltime) — UDP с приложенческой логикой (RTP/RTCP, FEC, адаптивное кодирование).