Вопрос #1615377

Кратко и по делу — сравнение и критерии выбора.
Сравнение TCP vs UDP по четырём свойствам
- Доставка:
- TCP — гарантированная доставка (повторные передачи, контроль целостности).
- UDP — без гарантий; доставка пакетов ненадёжна, приложение само реализует повторную отправку/коррекцию.
- Упорядочение:
- TCP — строгое in‑order (приемник получает поток в правильном порядке; out‑of‑order буферизуется, возможна head‑of‑line blocking).
- UDP — пакеты независимы, порядок не гарантируется; приложение при необходимости самосортирует.
- Контроль перегрузки:
- TCP — встроенный контроль перегрузки (AIMD/ Reno/CUBIC/BBR и т.п.), адаптирует скорость, в целом «дружелюбен» в сети.
- UDP — нет встроенного контроля; если приложение не реализует, может вызывать перегрузку/нечестное использование полосы.
- Задержка:
- TCP — может создавать дополнительные задержки: ретрансляции и head‑of‑line blocking увеличивают латентность и джиттер.
- UDP — обычно минимальная задержка и меньший jitter при отсутствии ретрансляций; критические сообщения можно посылать без ожидания подтверждения.
Дополнения: современные протоколы (QUIC) строят поверх UDP и совмещают надежность/порядок с низкой задержкой и лучшей работой через NAT/firewall.
Критерии выбора протокола для приложений реального времени
- Чувствительность к задержке (latency):
- «Критически» чувствительные: целевой one‑way latency < \(50\) ms (соревновательные игры). Предпочтение UDP/QUIC.
- Приемлемые/интерактивные: one‑way latency < \(150\) ms (видеоконференции — ITU‑T ориентир). Часто UDP/RTP.
- Нечувствительные: задержка вторична → TCP/QUIC (файлообмен).
- Требование к потере пакетов:
- Нулевая/почти нулевая (файлы) → TCP/QUIC (гарантии доставки).
- Небольшие потери допустимы (аудио/видео с PLC/FEC) → UDP+RTP+FEC/NACK.
- Игры: выборочное восстановление важных событий по UDP + локальная интерполяция.
- Требование к порядку:
- Нужен жёсткий порядок → TCP/QUIC или реализовать на приложении.
- Можно допускать out‑of‑order (игровые позиционные пакеты) → UDP + приложение.
- Управление полосой и честность в сети:
- Важна «корректность» и адаптация к перегрузкам → TCP/QUIC или UDP с реализацией congestion control (например, Google Congestion Control в WebRTC).
- Сетевые ограничения (NAT/firewall):
- UDP может блокироваться; если важна проходимость, выбирать QUIC (UDP + TLS) или TCP fallback.
- Реализация функций на уровне приложения:
- Если используете UDP, будьте готовы реализовать: FEC, selective retransmit (NACK), jitter buffer, congestion control, порядок для критичных сообщений.
- Простота разработки и инфраструктура:
- Файловый обмен: готовые решения на TCP/HTTP/FTP/SFTP проще.
- Реалтайм: существующие стеки (RTP/RTCP, WebRTC) над UDP дают готовые механизмы.
Рекомендации по приложениям
- Гейминг (онлайн, быстрый ввод): UDP с приложенным набором: клиентская предсказание, серв‑сайд авторитет, выборочная надежность (reliable only for critical state), локальное сглаживание; использовать congestion control; fallback на TCP/QUIC при блокировках. Целевые метрики: latency < \(50\)–\(100\) ms, потеря допустима до ≈ \(1\%\)–\(3\%\) в зависимости от жанра.
- Видеоконференции: RTP/UDP + RTCP + адаптивный bitrate, FEC/NACK, jitter buffer; UDP предпочтителен, но QUIC/TCP fallback для прохода через сети. Целевое one‑way latency < \(150\) ms, jitter < \(30\) ms, потери допустимы ≈ \(1\%\)–\(3\%\) с коррекцией.
- Файловый обмен: TCP (или QUIC) — гарантии доставки и порядок; поддержка возобновления, checksum. При слабых сетях QUIC даёт меньшую задержку установления соединения и лучшее мультиплексирование без head‑of‑line blocking.
Короткое резюме
- Если важна 100% доставка и порядок → TCP/QUIC.
- Если критична низкая задержка и можно терпеть/лечить потерю → UDP (с реализацией обработки потерь/контроля перегрузки) или QUIC (если нужна надёжность + низкая латентность + проходимость через NAT).