TCP против UDP в видеопотоке


98

Я только что вернулся домой после экзамена по сетевому программированию, и один из вопросов, который они нам задали, был: «Если вы собираетесь транслировать видео, вы бы использовали TCP или UDP? Дайте объяснение как для сохраненного видео, так и для потокового видео в реальном времени». . На этот вопрос они просто ожидали короткого ответа TCP для сохраненного видео и UDP для видео в реальном времени, но я думал об этом по дороге домой, и обязательно ли лучше использовать UDP для потоковой передачи видео в реальном времени? Я имею в виду, если у вас есть пропускная способность для этого, и вы говорите, что транслируете футбольный матч или концерт в этом отношении, вам действительно нужно использовать UDP?

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

Теперь я могу подумать о некоторых устройствах, где это было бы не очень хорошей идеей, например, видеоконференции, где вам нужно всегда быть в конце потока, потому что задержка во время видеочата просто ужасна, но во время футбольного матча или концерта какое это имеет значение, если вы отстаете ни на минуту от трансляции? Кроме того, вы гарантированно получите все данные, и было бы лучше сохранить их для последующего просмотра, когда они поступят без ошибок.

Итак, это подводит меня к моему вопросу. Есть ли какие-либо недостатки, о которых я не знаю, в использовании TCP для потоковой передачи в реальном времени? Или действительно должно быть так, что если у вас есть пропускная способность для этого, вы должны пойти на TCP, учитывая, что он «лучше» для сети (управление потоком)?


вы не можете использовать TCP без какой-либо встроенной задержки (с этим все согласны), но вы можете использовать TCP + UDP для обеспечения хорошего качества, если сеанс записан.
bestsss

Ответы:


88

Недостатки использования TCP для живого видео:

  1. Обычно устройства для потоковой передачи видео в реальном времени не предназначены для потоковой передачи TCP. Если вы используете TCP, ОС должна буферизовать неподтвержденные сегменты для каждого клиента. Это нежелательно, особенно в случае прямых трансляций; предположительно ваш список одновременных клиентов длинный из-за необычности мероприятия. Предварительно записанные видеопередачи обычно не имеют такой проблемы, потому что зрители изменяют свою активность воспроизведения; поэтому TCP больше подходит для воспроизведения видео по запросу.
  2. Многоадресная IP-передача значительно снижает требования к пропускной способности видео для большой аудитории; TCP предотвращает использование многоадресной IP-рассылки, но UDP хорошо подходит для многоадресной IP-рассылки.
  3. Живое видео обычно представляет собой поток с постоянной пропускной способностью, записанный с камеры; предварительно записанные видеопотоки снимаются с диска. Динамика потери потерь в TCP затрудняет обслуживание видео в реальном времени, когда исходные потоки имеют постоянную полосу пропускания (как это могло бы случиться для живого события). Если вы записываете буфер на диск с камеры, убедитесь, что у вас достаточно буфера для непредсказуемых сетевых событий и переменных скоростей отправки / отката TCP. UDP дает вам гораздо больше контроля для этого приложения, поскольку UDP не заботится о сбоях сетевого транспортного уровня.

К вашему сведению, пожалуйста, не используйте слово «пакеты» при описании сетей. Сети отправляют «пакеты».


Извините, я изменю. Один вопрос, однако, не поддерживает ли IPv6 (да, я знаю, возможно, он еще не очень хорошо поддерживается) многоадресную рассылку, так что тогда не следует ли TCP поверх IPv6?
Alxandr

1
Да, и кроме того, видео, записанное с живого мероприятия, вероятно, все равно сохраняется на диск, и придется повторно передавать небольшую часть этого, действительно ли это так больно?
Alxandr

1
@Alxandr, я не знаком ни с чем в IPv6, что упрощает многоадресную передачу TCP. Какую особенность IPv6 вы имеете в виду?
Майк Пеннингтон

2
@Alxandr, даже если вы используете адреса Anycast, это не решает фундаментальную проблему с обслуживанием многоадресной рассылки по TCP ... TCP идентифицирует сокеты как четверку (src ip, src port, dst ip, dst port). Если все клиенты используют один и тот же IP-адрес src, вы должны каким-то образом направить им пакеты IPv6 на основе порта src и сохранить состояние потери между всеми клиентами. Это противоречит цели многоадресной рассылки, которая заключалась в отправке одной копии пакетов каждому получателю
Майк Пеннингтон

Понимаю. Спасибо за ответ :). Мне было просто любопытно, поэтому я подумал, что посмотрю, что люди думают об этом. И кажется, что мировые футбольные фанаты и сам Интернет против меня, так что я полагаю, что это моя потеря ^ _ ^
Alxandr

26

а во время футбольного матча или концерта какое это имеет значение, если вы отстаете ни на минуту от трансляции?

Некоторым футбольным фанатам совсем немного. Было замечено, что задержки даже на несколько секунд, присутствующие в цифровых видеопотоках из-за кодирования (или чего-то еще), могут быть очень раздражающими, когда во время громких событий, таких как матчи чемпионата мира, вы можете слышать аплодисменты и стоны от парней. по соседству (кто смотрит неотмеченную аналоговую программу) до того, как вы увидите игровые ходы, которые их вызвали.

Я думаю, что для человека, который очень заботится о спорте (а это самая большая группа платящих клиентов за цифровое телевидение, по крайней мере, здесь, в Германии), отставание на минуту в прямом видеопотоке было бы совершенно неприемлемым (например, они '' d переключитесь на вашего конкурента, где этого не происходит).


Я помню, как люди жаловались на это и в Швейцарии.
Тара

21

Обычно видеопоток несколько отказоустойчив. Таким образом, если некоторые пакеты будут потеряны (например, из-за перегрузки какого-либо маршрутизатора), он все равно сможет отображать контент, но с ухудшенным качеством.

Если бы ваш прямой поток использовал TCP / IP, он был бы вынужден дождаться этих отброшенных пакетов, прежде чем он сможет продолжить обработку новых данных.

Это вдвойне плохо:

  • старые данные должны быть повторно переданы (это, вероятно, для кадра, который уже был отображен и, следовательно, бесполезен) и
  • новые данные не могут прибыть до тех пор , после того, как старые данные повторно передаются

Если ваша цель - отображать как можно более актуальную информацию (а для прямой трансляции вы обычно хотите быть актуальной, даже если ваши кадры выглядят немного хуже), то TCP будет работать против вас.

Для записанного потока ситуация немного иная: вы, вероятно, будете буферизовать намного больше (возможно, несколько минут!) И предпочтете повторно передать данные, чем иметь некоторые артефакты из-за потери пакетов. В этом случае TCP - хорошее совпадение (конечно, это все еще может быть реализовано в UDP, но TCP не имеет таких недостатков, как в случае прямого потока).


1
Но, как я объяснил, у многих «живых» потоков, которые мы используем сегодня, вероятно, не возникнет проблем с задержкой на полминуты, и, таким образом, вы автоматически получите буфер, чтобы вы не увидели потерянные пакеты в все. Разве это не было бы предпочтительнее, если бы вы сохранили данные?
Alxandr

2
@Alexandr: в таком случае вы смягчаете определение «живого» стрима, не так ли ;-)
Йоахим Зауэр

Да, я знаю, но я тоже пытался объяснить это в вопросе. Хотя похоже, что основная проблема будет с буферизацией старых данных (для повторной передачи) и многоадресной
рассылкой

В любом случае вы не хотите отбрасывать пакеты, это вызовет визуальные артефакты, которые распространяются в нескольких кадрах. Правильное решение - отбрасывать целые кадры, и UDP определенно не является решением проблемы перегрузки сети при воспроизведении видео.
Alex

По умолчанию видеопоток не является отказоустойчивым
Alex

10

Некоторые варианты использования подходят для транспорта UDP, а другие подходят для транспорта TCP.

Вариант использования также диктует настройки кодирования для видео. При трансляции футбольного матча основное внимание уделяется качеству, а при видеоконференции - задержке.

При использовании многоадресной рассылки для доставки видео вашим клиентам используется UDP.

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

Многоадресная рассылка упростит программное обеспечение для вещания, поскольку сетевое оборудование будет обрабатывать рассылку пакетов клиентам. Клиенты подписываются на многоадресные каналы, и сеть будет переконфигурирована для маршрутизации пакетов новому подписчику. По умолчанию все каналы доступны всем клиентам и могут быть оптимально маршрутизированы.

Этот рабочий процесс затрудняет процесс авторизации. Сетевое оборудование не отличает подписанных пользователей от других пользователей. Решение для авторизации заключается в шифровании видеоконтента и включении дешифрования в программном обеспечении плеера, когда подписка действительна.

Рабочий процесс Unicast (TCP) позволяет серверу проверять учетные данные клиента и разрешать только действительные подписки. Даже разрешить только определенное количество одновременных подключений.

Многоадресная передача через Интернет не включена.

Для доставки видео через Интернет необходимо использовать TCP. Когда используется UDP, разработчики в конечном итоге повторно реализуют повторную передачу пакетов, например. Живой протокол Bittorrent p2p.

«Если вы используете TCP, ОС должна буферизовать неподтвержденные сегменты для каждого клиента. Это нежелательно, особенно в случае живых событий».

Этот буфер должен существовать в какой-то форме. То же самое верно и для буфера джиттера на стороне игрока. Это называется «буфер сокета», и серверное программное обеспечение может знать, когда этот буфер заполнен, и отбрасывать правильные видеокадры для живых потоков. Лучше использовать метод одноадресной передачи / TCP, потому что серверное программное обеспечение может реализовать правильную логику отбрасывания кадров. Случайные пропущенные пакеты в случае UDP только ухудшат пользовательский интерфейс. как в этом видео: http://tinypic.com/r/2qn89xz/9

«Многоадресная IP-рассылка значительно снижает требования к пропускной способности видео для большой аудитории»

Это верно для частных сетей, многоадресная рассылка не включена через Интернет.

«Обратите внимание, что если TCP теряет слишком много пакетов, соединение разрывается; таким образом, UDP дает вам гораздо больше контроля для этого приложения, поскольку UDP не заботится о сбоях сетевого транспортного уровня».

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

«Обычно видеопоток в некоторой степени отказоустойчив»

Кодированное видео не является отказоустойчивым. При передаче по ненадежному транспорту в видеоконтейнер добавляется прямое исправление ошибок. Хорошим примером является контейнер MPEG-TS, используемый в спутниковой видеотрансляции, которая передает несколько потоков аудио, видео, EPG и т. Д. Это необходимо, поскольку спутниковая связь не является дуплексной, то есть приемник не может запросить повторную передачу потерянных пакетов.

Когда у вас есть дуплексная связь, всегда лучше повторно передавать данные только клиентам с потерей пакетов, чем включать накладные расходы на прямое исправление ошибок в поток, отправляемый всем клиентам.

В любом случае потерянные пакеты недопустимы. Пропущенные кадры допустимы в исключительных случаях, когда пропускная способность ограничена.

Результатом пропуска пакетов являются такие артефакты, как этот: артефакты

Некоторые декодеры могут прерывать потоки, пропуская пакеты в критических местах.


-1 для многоадресной рассылки через Интернет не разрешен. Это не везде, но некоторые узлы предлагают услуги многоадресной рассылки. Одним из примеров является SeattleIX, который активировал многоадресную рассылку в 2009 году
Майк Пеннингтон

2
@Mike Pennington: некоторые провайдеры не работают в Интернете, поэтому мое утверждение остается верным. Вы просто указываете на очень небольшую часть инфраструктуры и надеетесь, что другие присоединятся к этой практике. Пожалуйста, придерживайтесь фактов.
Alex

1
Когда вы найдете точку для обсуждения, сколько многоадресной рассылки проходит через Интернет, пожалуйста, дайте мне знать
Майк Пеннингтон

4

Рекомендую вам взглянуть на новый протокол p2p live Bittorent Live .

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


3

Это зависит. Насколько важен контент, который вы транслируете? Если критично, используйте TCP. Это может вызвать проблемы с пропускной способностью, качеством видео (возможно, вам придется использовать более низкое качество, чтобы справиться с задержкой) и задержкой. Но если вам нужен контент, чтобы гарантированно попасть туда, используйте его.

В противном случае UDP будет в порядке, если поток не критичен, и предпочтительнее, потому что UDP имеет меньше накладных расходов.


3

Одна из самых больших проблем с доставкой прямых трансляций в Интернет - это «масштаб», а TCP плохо масштабируется. Например, когда вы транслируете футбольный матч в прямом эфире, в отличие от просмотра фильма по запросу, количество людей, которые смотрят, может быть в 1000 раз больше. В таком сценарии использование TCP - это смертный приговор для CDN (сетей доставки контента).

Есть несколько основных причин, по которым TCP плохо масштабируется:

  1. Один из самых больших компромиссов TCP - это различная пропускная способность, достижимая между отправителем и получателем. При потоковой передаче видео через Интернет видеопакеты должны проходить через несколько маршрутизаторов через Интернет, каждый из этих маршрутизаторов подключен с разной скоростью. Алгоритм TCP начинается с маленького окна TCP, затем увеличивается до тех пор, пока не будет обнаружена потеря пакета, потеря пакета считается признаком перегрузки, и TCP реагирует на нее, резко уменьшая размер окна, чтобы избежать перегрузки. Таким образом, в свою очередь, немедленно снижается эффективная пропускная способность. Теперь представьте сеть с передачей TCP с использованием 6-7 переходов маршрутизатора к клиенту (очень нормальный сценарий). Если какой-либо из промежуточных маршрутизаторов теряет какой-либо пакет, TCP для этого канала снижает скорость передачи. Фактически, поток трафика между маршрутизаторами имеет форму песочных часов; всегда гоняйте вверх и вниз между одним из промежуточных маршрутизаторов. Рендеринг эффективной пропускной способности намного ниже по сравнению с оптимальным протоколом UDP.

  2. Как вы, возможно, уже знаете, TCP - это протокол, основанный на подтверждении. Предположим, например, что отправитель находится на расстоянии 50 мс (то есть задержка между двумя точками). Это будет означать, что время, необходимое для отправки пакета получателю и получателя для отправки подтверждения, составит 100 мс; таким образом, максимальная возможная пропускная способность по сравнению с передачей на основе UDP уже уменьшена вдвое.

  3. TCP не поддерживает многоадресную рассылку или новый развивающийся стандарт многоадресной рассылки AMT. Это означает, что у CDN нет возможности уменьшить сетевой трафик путем репликации пакетов, когда многие клиенты просматривают один и тот же контент. Это само по себе является достаточно серьезной причиной для того, чтобы CDN (например, Akamai или Level3) не использовали TCP для потоковой передачи в реальном времени.


2

Читая дискуссию о TCP UDP, я заметил логическую ошибку. Потеря TCP-пакета, вызывающая задержку в одну минуту, которая преобразуется в одноминутный буфер, не может быть коррелирована с потерей UDP-пакета на целую минуту при такой же потере. Более справедливое сравнение выглядит следующим образом.

TCP теряет пакет. Видео останавливается, пока TCP повторно отправляет пакеты в попытке передать математически идеальные пакеты в потоковом режиме. Видео задерживается на одну минуту и ​​возобновляется с того места, где оно было остановлено, после того как пропущенный пакет попадает в пункт назначения. Мы все ждем, но знаем, что не пропустим ни одного пикселя.

UDP теряет пакет. На секунду во время видеопотока угол экрана становится немного размытым. Никто не замечает, и шоу продолжается без поиска потерянных пакетов.

Все, что передает потоки, получает наибольшие преимущества от UDP. Потеря пакета, вызывающая задержку в одну минуту для TCP, не вызовет задержки в одну минуту для UDP. Учитывая, что большинство систем используют потоки с несколькими разрешениями, что делает вещи блокированными при недостатке пакетов, имеет еще больше смысла использовать UDP.

UDP FTW при потоковой передаче.


1
Вы забываете, что большинство видеокодеков имеют хотя бы небольшую избыточность за счет использования кодов исправления ошибок. Отдельный отброшенный пакет может быть проигнорирован в любом случае, потому что данные уже были доступны, а декодер может даже не заметить.
Энди

2

Если пропускная способность намного выше, чем битрейт, я бы рекомендовал TCP для одноадресной потоковой передачи видео в реальном времени.

Случай 1: Последовательные пакеты теряются в течение нескольких секунд. => Живое видео будет останавливаться на стороне клиента независимо от транспортного уровня (TCP или UDP). Когда сеть восстанавливается: - если используется TCP, клиентский видеоплеер может выбрать перезапуск потока при первом потерянном пакете (сдвиг во времени) ИЛИ отбрасывание всех поздних пакетов и перезапуск видеопотока без сдвига во времени. - если используется UDP, на стороне клиента нет выбора, перезапуск видео в реальном времени без какого-либо временного сдвига. => TCP равно или лучше.

Случай 2: некоторые пакеты случайно и часто теряются в сети. - если используется TCP, эти пакеты будут немедленно повторно переданы и с правильным буфером дрожания, это не повлияет на качество / задержку видеопотока. - при использовании UDP качество видео будет плохим. => TCP намного лучше


1

Для потоковой передачи видео пропускная способность, вероятно, является ограничением системы. Используя многоадресную рассылку, вы можете значительно уменьшить используемую полосу пропускания восходящего потока. С UDP вы можете легко рассылать свои пакеты на все подключенные терминалы. Вы также можете использовать надежный протокол многоадресной рассылки, один из которых называется Pragmatic General Multicast (PGM), я ничего о нем не знаю и, полагаю, он не получил широкого распространения.


1

Помимо всех других причин, UDP может использовать многоадресную рассылку. Поддержка тысяч пользователей TCP, которые передают одни и те же данные, тратит впустую полосу пропускания. Однако есть еще одна важная причина для использования TCP.

TCP может намного легче проходить через брандмауэры и NAT. В зависимости от вашего NAT и оператора вы можете даже не получить поток UDP из-за проблем с пробивкой отверстий UDP.


0

Все ответы «использовать UDP» предполагают открытую сеть и подход «наполняйте ее как можно больше». Подходит для старых закрытых специализированных аудио / видео сетей, которые исчезают.

В реальном мире ваша передача будет проходить через брандмауэры (которые будут отбрасывать многоадресную рассылку, а иногда и UDP), сеть используется совместно с другими более важными ($$$) приложениями, поэтому вы хотите наказать злоумышленников масштабированием окна.


0

Вот в чем дело, это скорее вопрос содержания, чем вопрос времени. Протокол TCP требует, чтобы пакет, который не был доставлен, был проверен, проверен и доставлен повторно. UDP не использует это требование. Поэтому, если вы отправили файл, содержащий миллионы пакетов, используя UDP, например видео, если некоторые из пакетов отсутствуют при доставке, они, скорее всего, не будут пропущены.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.