TCP, UDP и выбор, который делает каждый стриминговый протокол

Опубликовано: 2026-05-20 · Время чтения: 17 мин · Автор: Николай Сапунов, CEO Фора Софт

Последняя сверка: 2026-05-20 со стандартами: IETF RFC 793 (TCP, 1981), RFC 9293 (TCP, август 2022 – заменяет RFC 793), RFC 768 (UDP, 1980), RFC 9000 (QUIC, май 2021), RFC 8085 (UDP Usage Guidelines, март 2017), RFC 3550 (RTP, июль 2003), RFC 8216 (HLS, август 2017), Apple HLS Authoring Specification ревизия 2025-09, ISO/IEC 23009-1:2022 (DASH), draft-sharabayko-srt-01 (SRT, март 2024), SMPTE TR-06-1:2020 (RIST), RFC 8825 (обзор WebRTC, январь 2021) и RFC 9725 (WHIP, март 2025).

TL;DR

TCP – это транспортный протокол, который гарантирует доставку каждого байта в правильном порядке, автоматически переотправляет потерянные пакеты и управляет окном получателя. Он идеально подходит для загрузки веб-страниц, но становится проблемой при стремлении к задержке в 100 мс в live-трансляциях: один потерянный пакет блокирует все последующие данные. UDP – минимально возможный транспортный протокол: он отправляет пакеты и больше не отслеживает их судьбу. Он быстрый, не гарантирует порядок доставки, а потери считаются нормой. Именно такой подход нужен, если вы готовы самостоятельно реализовать восстановление потерянных данных.

Каждый стриминговый протокол строится на одном из этих двух основополагающих решений: HLS, DASH и CMAF используют TCP, потому что передают сегменты, похожие на файлы, через HTTP; WebRTC, SRT, RIST, RTP и Media over QUIC работают поверх UDP, поскольку им критически важно получать каждый кадр сразу после его кодирования.

Главная причина этого разделения – проблема head-of-line blocking. После прочтения этой статьи вы сможете по названию любого стримингового протокола сразу определить, на каком транспорте он работает и почему.

Зачем это понимать

Вопрос «TCP или UDP» – первое архитектурное решение в любом стриминговом продукте, и оно влияет на всё: задаёт минимальную задержку, которую вы вообще сможете достичь; определяет, может ли CDN кэшировать ваш трафик; меняет подход к работе с файрволами и корпоративными сетями; и напрямую влияет на стоимость TURN-трафика в WebRTC. Команда, не понимающая разницы, выберет неподходящий протокол – например, HLS для real-time аукциона или WebRTC для концерта на 200 000 зрителей – и обнаружит ошибку только через три месяца, когда архитектура перестанет справляться. То же непонимание проявляется и в RFP к вендорам, где просят «низкую задержку поверх HTTP», игнорируя, что физика TCP сама по себе задаёт нижнюю границу этой задержки. Эта статья даёт четыре ключевых факта, которые помогут принять решение при выборе любого стримингового протокола: что именно гарантирует каждый транспортный протокол, для каких задач он подходит, в чём суть ловушки head-of-line blocking и как QUIC в 2026 году начинает стирать старую границу между TCP и UDP.

Что вообще делает транспортный протокол

Перед TCP и UDP – слой ниже. Internet Protocol (IP) передаёт пакет по адресу назначения и пожимает плечами: он не гарантирует ни доставку, ни порядок, ни целостность пакета. Транспортный протокол – это слой, который работает поверх IP и решает, что с этим делать.

Каждый транспортный протокол отвечает на шесть вопросов о каждом байте, который вы ему передаёте: должен ли байт вообще дойти (надёжность), в каком порядке должны приходить байты (упорядочивание), как реагировать на перегрузку в сети (управление перегрузками), как сообщить отправителю «помедленнее», если получатель не справляется (управление потоком), как определить, какому приложению предназначен пакет (мультиплексирование по портам), и как зафиксировать, что две конечные точки действительно общаются друг с другом (состояние соединения). TCP отвечает на все шесть. UDP отвечает ровно на один – мультиплексирование по портам – и оставляет остальные пять задач приложению.

Разница между «отвечает на шесть» и «отвечает на один» – вот в чём суть.

Нажмите, чтобы увеличить

TCP в одном абзаце

TCP – это протокол транспортного уровня, обеспечивающий надёжную, ориентированную на соединение передачу данных между устройствами в сети. Он гарантирует доставку пакетов в правильном порядке, без потерь и с контролем ошибок, используя механизмы подтверждения получения, повторной передачи и управления потоком. Перед началом обмена данными стороны устанавливают соединение через трёхэтапное рукопожатие (SYN, SYN-ACK, ACK), а после завершения передачи – корректно его закрывают. TCP адаптируется к условиям сети, регулируя скорость передачи в зависимости от загруженности канала, что делает его идеальным для приложений, где важна целостность данных, таких как веб-страницы, электронная почта и файлы.

Transmission Control Protocol, определённый в IETF RFC 793 (сентябрь 1981) и обновлённый в RFC 9293 (август 2022, формально заменяющем RFC 793), – это соединение-ориентированный, надёжный, упорядоченный транспортный протокол для передачи потока байтов. Перед началом передачи данных конечные точки обмениваются тремя сообщениями (SYN, SYN-ACK, ACK), чтобы установить соединение и синхронизировать начальные номера последовательности – это three-way handshake. После установления соединения отправитель передаёт поток байтов; TCP разбивает его на сегменты, нумерует каждый байт, упаковывает в IP-пакеты и ожидает подтверждения (ACK) от получателя за каждый непрерывный диапазон. Если подтверждение не приходит в течение рассчитанного времени повторной передачи (retransmission timeout), TCP отправляет сегмент заново. Получатель передаёт байты приложению строго по порядку – даже если байт 1000 пришёл раньше байта 500, приложение не увидит ничего до получения байта 500. TCP также использует алгоритм управления перегрузками (в 2026 году будут внедрены CUBIC, BBR и Reno), который оценивает доступную пропускную способность и уменьшает окно передачи при обнаружении потерь. С точки зрения приложения результат выглядит как идеальная упорядоченная труба: каждый отправленный байт приходит ровно один раз, в правильном порядке и в конечном итоге.

«В конце концов» – это место, где стримингу становится невыносимо.

UDP в одном абзаце

UDP – это протокол транспортного уровня, который обеспечивает быструю передачу данных без установления соединения, гарантируя минимальную задержку, но не обеспечивая надёжность доставки, порядок пакетов или контроль ошибок, что делает его подходящим для приложений, где важна скорость, например, потоковое видео или онлайн-игры.

User Datagram Protocol, определённый в IETF RFC 768 (август 1980), – это безсостоятельный, ненадёжный, ориентированный на сообщения транспортный протокол. Никакого рукопожатия не предусмотрено: вы отправляете UDP-датаграмму (одно сообщение объёмом до 65 507 байт после IP- и UDP-заголовков), он добавляет 8-байтовый UDP-заголовок, передаёт пакет на уровень IP и завершает работу. Нет подтверждений, повторной передачи, упорядочивания, контроля перегрузок и управления потоком. Если датаграмма потеряна, об этом не сообщит сам UDP – приложение должно самостоятельно обнаружить потерю и принять решение. Если две датаграммы пришли в обратном порядке, они так и придут. Если сеть перегружена и получатель не справляется, UDP продолжит передавать данные с той же скоростью. UDP предоставляет приложению только четыре параметра: порт назначения, порт источника, длину и контрольную сумму. Всё остальное – ответственность приложения. RFC 8085 (UDP Usage Guidelines, март 2017) – это обширный документ, единственная цель которого – объяснить разработчикам приложений, что TCP обеспечивает «бесплатно», и как реализовать аналогичные механизмы поверх UDP, не перегружая сеть.

Звучит как катастрофа для видео. На самом деле – идеально, если понять, что такое head-of-line blocking.

Head-of-line blocking – проблема, решающая всё

Если из этой статьи вы прочитаете только один абзац – прочитайте этот. TCP передаёт байты приложению строго по порядку. Эта гарантия обеспечивается за счёт буферизации. Когда TCP получил байты с 1 по 499 и с 501 по 1000, но не получил байт 500, он не отдаст приложению ни одного байта, пока не придёт байт 500 – он удерживает байты с 501 по 1000 в буфере ядра и ждёт их повторной передачи. Приложение при этом ничего не видит. Такая задержка называется head-of-line blocking (блокировка головы очереди). Это фундаментальное свойство TCP, и отключить его невозможно.

Для веб-страницы head-of-line blocking – не проблема. Приложение всё равно ожидает каждый байт, а задержка в 200 мс на переотправку незаметна на фоне 2-секундного time-to-first-paint типичной страницы. Для видео с 5-секундным запасом задержки head-of-line blocking тоже терпим – у плеера буфер на несколько секунд, и переотправка укладывается внутрь буфера.

Для видео с задержкой «менее секунды» head-of-line blocking – главная проблема. Возьмём видеоконференцию с частотой 30 кадров в секунду: каждый кадр длится 33 мс. Если в сети потерян один пакет с частью кадра 100, TCP не передаст получателю кадры 101, 102, 103 и последующие, пока не будет переотправлен кадр 100. Типичная задержка переотправки по трансконтинентальному каналу – 80–200 мс – это три–шесть замороженных кадров ради одного. Получатель на долю секунды «зависает», а затем «оживает» с идеально упорядоченной последовательностью кадров, которой уже нельзя воспользоваться, потому что разговор давно ушёл вперёд.

UDP просто передаёт кадр 101 сразу при его поступлении, даже если кадр 100 был потерян. Видео-конвейер сообщает: «Я потерял пакет кадра 100, закрою его интерполяцией от кадра 99, ближайший I-кадр полностью пересинхронизирует изображение не более чем за 2 секунды» – и продолжает воспроизведение. Скрытие потерь декодером заметно гораздо меньше, чем заморозка кадра.

Именно поэтому каждый протокол стриминга в реальном времени работает поверх UDP. Его задача – сделать UDP менее плохим, добавив эффективный механизм восстановления потерянных пакетов, который не блокирует передачу новых данных.

Нажмите, чтобы увеличить

TCP против UDP – сравнительная таблица для команды

Шесть измерений, две колонки. Запомните эту таблицу – почти любой спор о выборе стримингового протокола укладывается в неё.

Измерение, определяющее архитектуру стриминга, – пол задержки при потерях. В сетях с потерями даже на уровне 1% эффективная пропускная способность TCP падает на порядок из-за остановок при переотправках. Формула Mathis и соавт. 1997 года, до сих пор используемая как грубая оценка «на обороте конверта», даёт throughput ≤ MSS / (RTT × √loss). Подставим значения: MSS = 1460 байт, RTT = 80 мс, потери = 1% – получаем предел около 1,8 Мбит/с. Этого недостаточно для передачи в разрешении 1080p. UDP с собственным восстановлением потерь на стороне приложения такую формулу игнорирует.

Почему HLS и DASH отлично работают по TCP

Если TCP так плох для низкой задержки, почему два самых популярных стриминговых протокола на планете – HTTP Live Streaming и Dynamic Adaptive Streaming over HTTP – оба используют TCP?

Ответ: HLS и DASH – не протоколы реального времени. Они файло-подобные. Энкодер разбивает прямой эфир на сегменты длительностью 2–10 секунд, сохраняет их как файлы (.ts, .mp4 или .m4s) на origin-сервере и позволяет плееру загружать их по обычному HTTP. HTTP работает поверх TCP. Плеер обычно поддерживает буфер из 3–4 сегментов – при длительности сегмента 6 секунд это составляет 18–24 секунды буфера. Задержка переотправки в 200 мс в таком буфере практически незаметна.

Этот буфер – ровно та задержка, которую вы платите за надёжность TCP и кэшируемость HTTP. Буфер – это то, что позволяет CDN кэшировать каждый сегмент, отдавать его с edge и обслуживать миллион одновременных зрителей, не перегружая origin. Без буфера CDN не может кэшировать; без кэширования вы не масштабируетесь; без масштаба нет OTT.

Low-Latency HLS и Low-Latency DASH снижают задержку, публикуя частичные сегменты продолжительностью 200–400 мс – Apple HLS Authoring Specification (ревизия 2025-09, §2.10 и далее) подробно описывает расширения LL-HLS. В результате достигается задержка glass-to-glass менее 3 секунд при хорошо настроенной трансляции, при этом используется всё ещё TCP. Ниже 3 секунд TCP начинает терять эффективность; при задержках менее 1 секунды TCP и UDP резко расходятся по характеристикам.

Вывод не в том, что «TCP плох для стриминга». Вывод – что «TCP плох для стриминга с задержкой меньше 3 секунд». Для VOD с задержкой в 5 секунд и для live OTT TCP – правильный выбор: его надёжность и кэшируемость HTTP перевешивают плату за задержку. Для интерактивного видео с задержкой в 100 мс TCP не справляется с требованиями по времени.

Почему WebRTC, SRT и RIST работают поверх UDP

Три больших семейства протоколов реального времени работают поверх UDP и каждое реализует свою версию «сделаем UDP менее плохим».

WebRTC (рекомендация W3C плюс RFC 8825–8866 и семейство RTP, начиная с RFC 3550) передаёт медиа в виде RTP-пакетов по протоколу UDP. У каждого RTP-пакета есть порядковый номер и временная метка. Получатель использует порядковый номер для обнаружения потерь пакетов, а временную метку – для планирования воспроизведения. При обнаружении потери WebRTC применяет несколько механизмов восстановления: NACK (отрицательное подтверждение о потерянных пакетах), RTX (переотправка через отдельный RTP-поток с другим типом полезной нагрузки), FEC (обнаружение и исправление ошибок за счёт заранее добавленной избыточности) и собственное скрытие ошибок кодеком. Ни один из этих механизмов не блокирует обработку последующих пакетов: если кадр 100 не удаётся восстановить вовремя, декодер заменяет его и воспроизводит кадр 101. Задержка «от стекла до стекла» в WebRTC обычно составляет 100–500 мс.

SRT (Secure Reliable Transport, определённый в Internet-черновике draft-sharabayko-srt-01, март 2024 – обратите внимание на статус draft; SRT может измениться до выхода в RFC) оборачивает UDP настраиваемым ARQ-переотправлением, опциональным FEC, AES-шифрованием и доставкой по временным меткам. Главная особенность – настраиваемый буфер задержки: вы говорите SRT: «дай мне 200 мс jitter-буфера» – и он использует этот запас, чтобы восстанавливать потерянные пакеты переотправкой, если round-trip время укладывается в лимит, и отказывается от попыток, если нет. SRT – де-факто стандарт для профессиональных контрибуционных линий по публичному интернету (камера → энкодер → облако). Поведение при head-of-line блокировке настраивается: внутри бюджета SRT ждёт и переотправляет, за его пределами – отбрасывает пакет и продолжает работу.

RIST (Reliable Internet Stream Transport, SMPTE TR-06-1, TR-06-2, TR-06-3) – ответ индустрии вещания на ту же задачу. RIST работает поверх UDP, передаёт RTP и использует собственную схему переотправки по NACK на основе номеров последовательности RTP. SRT разрабатывали компании Haivision и Wowza, RIST – Video Services Forum и коалиция поставщиков оборудования для вещания. Оба протокола решают одну и ту же задачу, но с разными управленческими моделями.

RTMP и его потомки – единственное крупное исключение в контрибуционном семействе: RTMP использует TCP, потому что был разработан в 1996 году для совместного использования TCP-сокета с другим трафиком Flash. RTMP уходит в прошлое как контрибуционный протокол; SRT и WHIP отбирают его долю именно потому, что TCP – неподходящий выбор для контрибуционной линии при любых заметных потерях.

Числовой пример: один и тот же потерянный пакет по TCP и по UDP

Подставим числа. Камера кодирует видео в разрешении 1080p с частотой 30 кадров в секунду, средний размер кадра – 8 КБ, пиковый I-кадр – 80 КБ. Задержка до облака – 80 мс в одну сторону, RTT – 160 мс, средняя потеря пакетов – 0,5 %. Один кадр передаётся десятью UDP-датаграммами по 1500 байт (реальные значения – MTU 1500 минус заголовки IP и UDP).

На TCP (контрибуция через RTMP, легаси-случай): энкодер отправляет десять пакетов в TCP-сокет. Один теряется. Ядро получателя буферизует девять. Энкодер обнаруживает потерю, не дождавшись ACK в течение времени повторной передачи (базовое значение – 160 мс плюс джиттер), и переотправляет пропавший пакет. Получатель ждёт 160 мс, прежде чем любой из десяти пакетов станет доступен приложению. При 30 fps это 4,8 кадра стопора. Далее приходит следующий кадр, и по пути снова теряется один пакет – ещё 160 мс задержки. При 0,5% потерь на десять пакетов на кадр ожидаемое число таких событий – один раз в двадцать кадров, или раз в 0,67 секунды. Пользователь видит явные заморозки и скачки каждые две трети секунды.

На UDP (контрибуция через WebRTC или SRT): тот же энкодер пакетизирует те же десять датаграмм и отправляет их. Одна теряется. Получатель получает девять, по номеру последовательности RTP замечает пропуск, отправляет NACK на пропавший пакет. NACK и переотправка занимают те же 160 мс, что и в TCP, но за это время декодер обрабатывает девять имеющихся пакетов, заполняет пропущенную область данными с предыдущего кадра и выводит кадр в нужное время. Если переотправка приходит вовремя – её используют; если нет – пропуск уже закрыт, следующий кадр воспроизводится нормально. Видимой заморозки нет. Ближайший I-кадр полностью пересинхронизирует изображение за 2 секунды.

Это и есть весь инженерный аргумент за UDP в интерактивном стриминге. Та же сеть, тот же процент потерь, тот же RTT – совершенно разный пользовательский опыт.

QUIC и Media over QUIC – новая карта

Дихотомия TCP против UDP начинает стираться в 2026 году благодаря QUIC.

QUIC, определённый в IETF RFC 9000 (май 2021), – это транспортный протокол, который работает поверх UDP, но переосмысливает почти всё, что делает TCP: надёжность, упорядочивание, управление перегрузками, управление потоком и шифрование (TLS 1.3 интегрирован в handshake, а не добавлен сверху). Ядро видит UDP-датаграммы; приложение – упорядоченный, надёжный, зашифрованный байтовый поток. С точки зрения приложения QUIC очень похож на TCP + TLS.

Ключевое отличие – QUIC поддерживает множество независимых стримов в одном соединении, и потеря пакета в одном стриме не блокирует другие. В TCP каждый байт передаётся в одном огромном упорядоченном потоке, и из-за head-of-line blocking задержка затрагивает всё соединение. В QUIC можно одновременно передавать стрим 0 (видеочанк 1), стрим 1 (видеочанк 2), стрим 2 (аудиочанк 1) и стрим 3 (субтитры), и потеря пакета в стриме 0 не задержит стримы 1, 2 и 3. Блокировка головы становится per-stream, а не per-connection. Для chunked-encoding при доставке CMAF-сегментов по HTTP/3 это – именно то, что позволяет избавиться от значительной доли задержек, характерных для LL-HLS-on-TCP.

HTTP/3 (RFC 9114) – это HTTP поверх QUIC. HLS и DASH, передаваемые по HTTP/3, автоматически получают изоляцию потоков на уровне QUIC без каких-либо изменений в протоколах более высокого уровня. Media over QUIC, draft-ietf-moq-transport-17 (январь 2026; это Internet-Draft и может измениться до публикации в RFC), предлагает более продвинутый подход: он рассматривает поток как дерево именованных объектов, а не как последовательность сегментов, обеспечивая встроенную поддержку ретрансляции, работы с несколькими CDN и прямой трансляции с задержкой менее одной секунды. MoQ – наиболее реалистичный кандидат на роль «следующего стандартного» способа доставки после LL-HLS. Подробности – в Media over QUIC в деталях.

Практический вывод для 2026: TCP против UDP – всё ещё правильная ментальная модель для понимания любого существующего протокола, но при создании нового стоит выбирать QUIC. Cloudflare, Meta, Google и YouTube уже передают значительную часть трафика через HTTP/3, а доля QUIC в общем интернет-трафике превысила 30% в 2025 году, согласно отчёту Sandvine Global Internet Phenomena.

Типичная ошибка – считать, что TCP «надёжнее» в каком-то полезном смысле

Распространённая путаница в продуктовых командах: «нам нужен надёжный стриминг – давайте использовать TCP». Здесь путают два разных значения слова надёжность.

Надёжность TCP – байт-уровня: каждый отправленный байт дойдёт, по порядку, в конце концов. Это свойство байтового потока, а не пользовательского опыта. С точки зрения зрителя замёрзшее видео не «надёжно» – оно сломано. Per-packet ненадёжность UDP в сочетании с возможностью реального приложения сбросить, замаскировать и пойти дальше даёт гораздо более полезную надёжность на уровне UX: картинка не останавливается.

Правильный вопрос не «TCP или UDP – что надёжнее», а «что мой продукт считает “пришло вовремя”». Для 24-секундного OTT-буфера «в конце концов» TCP – это вовремя. Для 100-миллисекундного конференц-бюджета всё, что не пришло за 100 мс, уже потеряно – и переотправка TCP в бюджет не укладывается, так что её «надёжность» не работает.

Считайте надёжность не свойством, а бюджетом. UDP с собственным восстановлением потерь надёжнее в жёстком бюджете задержки, чем TCP. TCP надёжнее вне любого бюджета. Выбирайте решение под бюджет.

Где здесь Фора Софт

Мы занимаемся видеостримингом, видеоконференциями, OTT, видеонаблюдением, телемедициной, e-learning и AR/VR-продуктами с 2005 года, и выбор между TCP и UDP – это первый вопрос, который мы ставим на каждой архитектурной доске. Телемедицинским консультациям нужен WebRTC с задержкой 200 мс по UDP; для e-learning-лекций, записываемых на будущее, отлично подходит HLS по TCP; OTT-стриминг в реальном времени требует LL-HLS с частичными сегментами по TCP и HTTP/3 там, где плеер его поддерживает; приём данных с камер в системах видеонаблюдения – по SRT через UDP, потому что сотовая линия теряет пакеты. Часто один и тот же конвейер передаёт трафик по обоим транспортам на разных этапах – например, WebRTC-ингест с камеры по UDP, а затем перекодирование и упаковка в HLS по TCP для аудитории с долгим хвостом просмотров. Знать, какой транспорт используется на каждом этапе, – это первая проверка здравого смысла, которую мы проводим, когда существующая система начинает работать медленно.

Ключевые выводы

• TCP передаёт каждый байт строго по порядку с обязательной переотправкой; блокировка головы очереди (head-of-line blocking) – это неизбежная плата.
• UDP передаёт каждую датаграмму независимо; восстановление потерянных пакетов – задача приложения, и именно в этом заключается его смысл для реального времени, например, в видео.
• HLS, DASH и RTMP используют TCP, потому что они работают с данными, похожими на файлы, и допускают буферизацию.
• WebRTC, SRT, RIST, RTP и MoQ используют UDP, потому что им нужен каждый кадр как можно быстрее.
• Надёжность – это не свойство протокола, а часть бюджета задержки; UDP с восстановлением на уровне приложения может быть надёжнее в условиях ограниченного времени.
• QUIC преодолевает старую дихотомию: мультиплексирование на уровне потока устраняет блокировку головы очереди на уровне соединения.

Что почитать дальше

• Управление перегрузкой простыми словами: BBR, CUBIC, Copa – что алгоритм на транспортном уровне делает с вашей пропускной способностью на перегруженной линии.
• QUIC: новый транспортный уровень – подробный разбор протокола, который переосмысливает TCP поверх UDP, и его роль в качестве основы для HTTP/3 и MoQ.
• Задержка, glass-to-glass, end-to-end: что означают эти секунды – статья из Блока 1, формирующая бюджет задержки и влияющая на выбор между TCP и UDP.