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 не дбає про зниження рівня мережевого транспортного рівня.

FYI, будь ласка, не використовуйте слово "пакети" при описі мереж. Мережі відправляють "пакети".

але під час футбольного матчу чи концерту, що має значення, якщо ви на хвилину за потоком?

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

Я думаю, що для когось, хто багато турбується про спорт (а це найбільша група платників за цифрове телебачення, принаймні тут, у Німеччині), відставання в потоці відео в прямому ефірі буде абсолютно неприйнятним (як, наприклад, 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 може використовувати багатоадресну передачу. Підтримуючи 1000 секунд TCP-користувачів, які передають однакові дані, витрачаючи смугу пропускання. Однак є ще одна важлива причина використання TCP.

TCP може набагато легше проходити через брандмауери та NAT. Залежно від NAT та оператора, ви навіть не зможете отримати потік UDP через проблеми з пробиванням отворів UDP.

Усі відповіді "використовувати UDP" передбачають відкриту мережу та підхід "набийте, скільки зможете". Добре підходить для старих аудіо / відео мереж із закритим садом, які зникають.

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

У цьому річ, це більше питання змісту, ніж питання часу. Протокол TCP вимагає перевірки, перевірки та повторної доставки пакета, який не був доставлений. UDP не використовує цю вимогу. Отже, якщо ви надіслали файл, який містить мільйони пакетів, використовуючи UDP, наприклад відео, якщо деякі пакети відсутні при доставці, вони, швидше за все, будуть пропущені.