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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Некоторые варианты использования подходят для транспорта 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 и т. Д. Это необходимо, поскольку спутниковая связь не является дуплексной, то есть приемник не может запросить повторную передачу потерянных пакетов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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