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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Некоторые декодеры могут разбивать потоки на пропущенные пакеты в критических местах.

Answer 5

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

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

Answer 6

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

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

Answer 7

Одна из самых больших проблем с доставкой живых событий в Интернете - это «масштабирование», а 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 для потоков в реальном времени.

Answer 8

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

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

Answer 9

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

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

Answer 10

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

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

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