TCP и UDP на видео
Я только что вернулся домой с экзамена по сетевому программированию, и один из вопросов, которые они нам задали, был " Если вы собираетесь транслировать видео, вы бы использовали TCP или UDP? Дайте объяснение как для сохраненного видео, так и для живых видеопотоков". На этот вопрос они просто ожидали короткого ответа TCP для сохраненного видео и UDP для живого видео, но я думал об этом по дороге домой, и обязательно лучше использовать UDP для потокового видео? Я имею в виду, если у вас есть пропускная способность для это, и скажем, вы транслируете футбольный матч или концерт, если на то пошло, вам действительно нужно использовать UDP?
допустим, что во время потоковой передачи этого концерта или чего-либо еще с помощью TCP вы начинаете терять пакеты (что-то плохое произошло в какой-то Сети между вами и отправителем), и в течение целой минуты вы не получаете никаких пакетов. Видеопоток приостановится, и после того, как минута прошла, пакеты начнут проходить снова (IP нашел для вас новый маршрут). Что бы тогда произошло, это TCP будет ретранслировать минуту, которую вы потеряли, и продолжать отправлять вам прямой эфир. Как предположение, пропускная способность выше, чем скорость передачи битов в потоке, и пинг не слишком высок, поэтому за короткое время одна минута, которую вы потеряли, будет действовать как буфер для потока для вас, таким образом, если потеря пакетов произойдет снова, вы не заметите.
теперь я могу подумать о некоторых устройствах, где это не было бы хорошей идеей, например, видеоконференции, где вы нужно всегда быть в конце потока, потому что задержка во время видео-чата просто ужасна, но во время футбольного матча или концерта какая разница, если вы на одну минуту отстаете от потока? Кроме того, вы гарантированно получаете все данные, и было бы лучше сохранить для последующего просмотра, когда он приходит без каких-либо ошибок.
Итак, это подводит меня к моему вопросу. Есть ли какие-либо недостатки, о которых я не знаю об использовании TCP для потоковой передачи? Или так и должно быть? если у вас есть пропускная способность для него, вы должны пойти на TCP, учитывая, что он" лучше " для сети (flow-control)?
13 ответов
недостатки использования TCP для живого видео:
- обычно живые видео-потоковые устройства не разработаны с учетом потоковой передачи TCP. При использовании TCP ОС должна буферизировать неподтвержденные сегменты для каждого клиента. Это нежелательно, особенно в случае живых событий; предположительно, ваш список одновременных клиентов длинный из-за сингулярности события. Предварительно записанные видео-слепки обычно не имеют такой большой проблемы с этим, потому что зрители шатаются их активность воспроизведения; поэтому TCP более подходит для воспроизведения видео по требованию.
- IP multicast значительно снижает требования к пропускной способности видео для больших аудиторий; TCP предотвращает использование IP multicast, но UDP хорошо подходит для IP multicast.
- Live video обычно является потоком с постоянной пропускной способностью, записанным с камеры; предварительно записанные видеопотоки снимаются с диска. Динамика потери-отдачи TCP затрудняет обслуживание живого видео, когда исходные потоки находятся в постоянной полосе пропускания (как и в случае live-event). Если вы буфера на диск с камеры, убедитесь, что у вас есть достаточный буфер для непредсказуемых сетевых событий и переменной передачи TCP/частота переключений. UDP дает вам гораздо больше контроля для этого приложения, так как UDP не заботится о снижениях уровня сетевого транспорта.
FYI, пожалуйста, не используйте слово "пакеты" при описании сетей. Сети отправляют "пакеты".
но во время футбольного матча, или концерт, какое это имеет значение, если вы в одной минуте позади ручья?
для некоторых футбольных болельщиков, совсем немного. Было отмечено, что задержки даже на несколько секунд, присутствующие в цифровых видеопотоках из-за кодирования (или что-то еще), могут быть очень раздражающими, когда во время громких событий, таких как матчи Кубка мира, вы можете услышать приветствия и стоны от парней по соседству (которые смотрят некрашеную аналоговую программу) прежде чем вы получите, чтобы увидеть игру движется, что вызвало их.
Я думаю, что для кого-то, кто много заботится о спорте (и это самая большая группа платных клиентов для цифрового телевидения, по крайней мере, здесь, в Германии), быть на минуту позади в прямом эфире было бы совершенно неприемлемо (например, они переключились бы на вашего конкурента, где этого не происходит).
обычно видеопоток несколько отказоустойчив. Поэтому, если некоторые пакеты потеряются (например, из-за перегрузки какого-то маршрутизатора), он все равно сможет отображать контент, но с пониженным качеством.
Если ваш живой поток использует TCP / IP, то это будет заставили ждать тех упавших пакетов до он может продолжить обработку новых данных.
это вдвойне плохо:
- старый данные будут повторно переданы (это, вероятно, для кадра, который уже был отображен и поэтому бесполезен) и
- новые данные не могут прибыть до после старые данные были повторно переданы
Если ваша цель-отображать как можно более актуальную информацию (и для живого потока вы обычно хотите быть в курсе, даже если ваши кадры выглядят немного хуже), то TCP будет работать против вас.
для записанного потока ситуация немного по-другому: вы, вероятно, будете буферизировать намного больше (возможно, несколько минут!) и предпочел бы, чтобы данные передавались повторно, чем некоторые артефакты из-за потерянных пакетов. В этом случае TCP является хорошим совпадением (это все еще может быть реализовано в UDP, конечно, но TCP не имеет столько недостатков, сколько для случая live stream).
есть несколько вариантов использования, подходящих для UDP-транспорта, и другие, подходящие для TCP-транспорта.
прецедент также диктует настройки кодирования для видео. При трансляции футбольного матча акцент делается на качестве, а для видеоконференции-на задержке.
при использовании многоадресной рассылки для доставки видео вашим клиентам используется UDP.
требование для многоадресной рассылки-это дорогостоящее сетевое оборудование между широковещательным сервером и клиентом. На практике это означает, что если ваша компания владеет сетевой инфраструктурой, вы можете использовать UDP и многоадресную рассылку для потокового видео. Даже тогда качество обслуживания также реализуется для маркировки видеопакетов и приоритизации их, чтобы не произошло потери пакетов.
Multicast упростит широковещательное программное обеспечение, потому что сетевое оборудование будет обрабатывать распространение пакетов клиентам. Клиенты подписываются на многоадресные каналы, и сеть переконфигурируется для маршрутизации пакетов новому абоненту. По умолчанию все каналы доступно для всех клиентов и может быть оптимально маршрутизировать.
этот рабочий процесс создает трудности в процессе авторизации. Сетевое оборудование не отличает подписанных пользователей от других пользователей. Решение для авторизации заключается в шифровании видеоконтента и включении дешифрования в программном обеспечении проигрывателя, когда подписка действительна.
unicast (TCP) workflow позволяет серверу проверять учетные данные клиента и разрешать только действительные подписки. Даже разрешить только определенное количество одновременное подключение.
Многоадресная рассылка не включена через интернет.
для доставки видео через интернет необходимо использовать TCP. Когда UDP используется, разработчики в конечном итоге повторно реализуют повторную передачу пакетов, например. Протокол BitTorrent P2P live.
" Если вы используете TCP, ОС должна буферизировать неподтвержденные сегменты для каждого клиента. Это нежелательно, особенно в случае живых событий".
этот буфер должен существовать в некоторая форма. То же самое верно для jitter buffer на стороне игрока. Он называется "Socket buffer", и серверное программное обеспечение может знать, когда этот буфер заполнен, и отбрасывать правильные видеокадры для живых потоков. Лучше использовать метод unicast / TCP, потому что серверное программное обеспечение может реализовать правильную логику отбрасывания кадров. Случайные отсутствующие пакеты в случае UDP просто создадут плохой пользовательский интерфейс. как в этом видео: http://tinypic.com/r/2qn89xz/9
"IP multicast значительно уменьшает требования к пропускной способности видео для больших аудиторий"
Это верно для частных сетей, Многоадресная рассылка не включена через интернет.
"обратите внимание, что если TCP теряет слишком много пакетов, соединение умирает; таким образом, UDP дает вам гораздо больше контроля для этого приложения, так как UDP не заботится о снижении уровня сетевого транспорта."
UDP также не заботится о падении целых кадров или группы кадров, поэтому он больше не дает контроль над пользовательским интерфейсом.
"обычно видеопоток несколько отказоустойчив"
закодированное видео не отказоустойчивость. При передаче через ненадежный транспорт, то вперед исправление ошибок добавляется в контейнер видео. Хорошим примером является контейнер MPEG-TS, используемый в спутниковой трансляции видео, которые несут несколько аудио, видео, EPG и т. д. потоки. Это необходимо, поскольку спутниковая связь не является дуплексной связью, то есть приемником не удается запросить повторную передачу потерянных пакетов.
когда у вас есть дуплексная связь, всегда лучше повторно передавать данные только клиентам, имеющим потерю пакетов, а затем включать накладные расходы на исправление ошибок в потоке, отправленном всем клиентам.
в любом случае потерянные пакеты неприемлемы. Пропущенные кадры в порядке в исключительных случаях, когда пропускная способность препятствовать.
результатом пропущенных пакетов являются артефакты, подобные этому: 
некоторые декодеры могут разбить на потоки отсутствующие пакеты в критических местах.
Я рекомендую вам посмотреть на новый P2P live protocol Bittorent Live.
Что касается потоковой передачи, Лучше использовать UDP, во-первых, потому что он снижает нагрузку на серверы, но в основном потому, что вы можете отправлять пакеты с многоадресной передачей, это проще, чем отправлять его каждому подключенному клиенту.
Это зависит. Насколько важен контент, который вы транслируете? Если критическое использование TCP. Это может вызвать проблемы с пропускной способностью, качеством видео (Возможно, вам придется использовать более низкое качество для борьбы с задержкой) и задержкой. Но если вам нужен контент, чтобы гарантированно попасть туда, используйте его.
в противном случае UDP должен быть в порядке, если поток не критичен и был бы предпочтительным, потому что UDP имеет тенденцию иметь меньше накладных расходов.
одна из самых больших проблем с доставкой живых событий в интернете-это "масштаб", а TCP не масштабируется хорошо. Например, когда вы транслируете футбольный матч в прямом эфире-в отличие от воспроизведения фильма по требованию - количество людей, наблюдающих за ним, может быть в 1000 раз больше. В таком сценарии использование TCP является смертным приговором для CDNs (сетей доставки контента).
есть несколько основных причин, почему TCP не масштабируется хорошо:
один из самый большой компромисс TCP-это вариативность пропускной способности, достижимая между отправителем и получателем. При потоковой передаче видео через Интернет видеопакеты должны проходить через несколько маршрутизаторов через Интернет, каждый из этих маршрутизаторов связан с различными скоростными соединениями. Алгоритм TCP начинается с малого окна TCP, затем растет до тех пор, пока не будет обнаружена потеря пакета, потеря пакета считается признаком перегрузки, и TCP реагирует на нее, резко уменьшая размер окна, чтобы избежать затор. Таким образом в свою очередь уменьшающ эффективный объем немедленно. Теперь представьте себе сеть с передачей TCP с использованием 6-7 маршрутизаторов, переходящих к клиенту (очень нормальный сценарий), если какой-либо из промежуточных маршрутизаторов потеряет какой-либо пакет, TCP для этой ссылки уменьшит скорость передачи. На самом деле поток трафика между маршрутизаторами следует за формой песочных часов; всегда гонг вверх и вниз между одним из промежуточных маршрутизаторов. Оказание эффективной помощи гораздо ниже по сравнению с наилучшие усилия UDP.
Как вы уже знаете, TCP является протоколом на основе подтверждения. Например, скажем, отправитель находится на расстоянии 50 мс (т. е. задержка между двумя точками). Это означало бы, что время, необходимое для отправки пакета получателю и получателю для отправки подтверждения, будет 100 мс; таким образом, максимальная пропускная способность по сравнению с передачей на основе UDP уже уменьшена вдвое.
TCP не поддерживает многоадресную передачу или новую появляющуюся стандарт многоадресной AMT. Это означает, что у CDNs нет возможности уменьшить сетевой трафик путем репликации пакетов-когда многие клиенты смотрят один и тот же контент. Это само по себе является достаточно большой причиной для CDNs (например, Akamai или Level3), чтобы не идти с TCP для живых потоков.
для пропускной способности потокового видео, вероятно, ограничение на системе. Используя многоадресную рассылку, вы можете значительно уменьшить объем используемой восходящей полосы пропускания. С UDP вы можете легко многоадресной рассылки пакетов на все подключенные терминалы. Вы также можете использовать надежный многоадресный протокол, который называется Pragmatic General Multicast (PGM), я ничего не знаю об этом, и я думаю, что он не распространен в его использовании.
все ответы "использовать UDP" предполагают открытую сеть и "набить ее столько, сколько сможете". Хорошо для старого стиля закрытого сада выделенных аудио / видео сетей, которые являются исчезающим видом.
в реальном мире ваша передача будет проходить через брандмауэры (которые будут отбрасывать многоадресную рассылку, а иногда и udp), сеть совместно используется с другими более важными ( $ $ $ ) приложениями, поэтому вы хочу чтобы наказать нарушителей с помощью масштабирования окна.
помимо всех других причин, UDP может использовать многоадресную рассылку. Поддерживая 1000S пользователей TCP все передачи на тех же частотах отходов данных. Однако есть еще одна важная причина для использования TCP.
TCP может гораздо легче пройти через брандмауэры и NATs. В зависимости от вашего NAT и оператора вы даже не сможете получить поток UDP из-за проблем с пробивкой отверстий UDP.
во время чтения дебатов TCP UDP я заметил логический недостаток. Потеря пакета TCP, вызывающая задержку в одну минуту, которая преобразуется в одноминутный буфер, не может быть коррелирована с UDP, отбрасывающим полную минуту, испытывая ту же потерю. Более справедливое сравнение выглядит следующим образом.
TCP испытывает потерю пакета. Видео остановлено, в то время как TCP повторно отправляет пакеты в попытке передать математически совершенные пакеты. Видео задерживается на одну минуту и подхватывает, где оно остановилось после недостающий пакет делает свое назначение. Мы все ждем, но знаем, что не пропустим ни одного пикселя.
UDP испытывает потерю пакета. На секунду во время видеопотока угол экрана становится немного размытым. Никто не замечает, и шоу продолжается, не ища потерянные пакеты.
все, что потоки получают наибольшую выгоду от UDP. Потеря пакета, вызывающая одноминутную задержку TCP, не приведет к одноминутной задержке UDP. Учитывая, что большинство систем используют несколько потоков разрешения, делающих вещи блочными при голодании пакетов, имеет еще больше смысла использовать UDP.
UDP FTW при потоковой передаче.
Если пропускная способность намного выше, чем битрейт, я бы рекомендовал TCP для одноадресной потоковой передачи видео.
Случай 1: последовательные пакеты теряются в течение нескольких секунд. => live video остановится на стороне клиента независимо от транспортного уровня (TCP или UDP). Когда сеть восстановится: - если используется TCP, клиентский видеоплеер может перезапустить поток при первом потерянном пакете (timeshift) или удалить все поздние пакеты и перезапустить видеопоток без таймшифта. - если UDP используется, нет выбора на стороне клиента, перезапуск видео в прямом эфире без какого-либо сдвига времени. = > TCP равен или лучше.
случай 2: некоторые пакеты случайно и часто теряются в сети. - если используется TCP, эти пакеты будут немедленно ретранслированы и с правильным буфером дрожания, не будет никакого влияния на качество/задержку видеопотока. - если используется UDP, качество видео будет низким. => Протокол TCP намного лучше
это дело, это больше вопрос содержания, чем вопрос времени. Протокол TCP требует, чтобы пакет, который не был доставлен, должен быть проверен, проверен и повторно доставлен. UDP не использует это требование. Поэтому, если вы отправили файл, содержащий миллионы пакетов, используя UDP, как видео, если некоторые из пакетов отсутствуют при доставке, они, скорее всего, останутся незамеченными.