TCP vs UDP w strumieniu wideo

Właśnie wróciłem do domu z egzaminu z programowania sieciowego i jedno z pytań, które nam zadali, brzmiało: „Jeśli zamierzasz przesyłać strumieniowo wideo, czy użyjesz protokołu TCP lub UDP? Podaj wyjaśnienie dotyczące zarówno zapisanego wideo, jak i strumieni wideo na żywo” . Na to pytanie spodziewali się po prostu krótkiej odpowiedzi TCP dla przechowywanego wideo i UDP dla wideo na żywo, ale myślałem o tym w drodze do domu i czy koniecznie lepiej jest używać UDP do przesyłania strumieniowego wideo na żywo? Chodzi mi o to, że jeśli masz wystarczającą przepustowość i mówisz, że transmitujesz mecz piłki nożnej lub koncert, czy naprawdę musisz używać UDP?

Powiedzmy, że podczas przesyłania strumieniowego tego koncertu lub czegokolwiek za pomocą TCP zaczynasz tracić pakiety (coś złego wydarzyło się w jakiejś sieci między tobą a nadawcą) i przez całą minutę nie dostajesz żadnych pakietów. Strumień wideo zostanie wstrzymany, a po minucie pakiety zaczną ponownie przechodzić (IP znalazł nową trasę). Co by się wtedy stało, to że TCP ponownie transmituje minutę, którą straciłeś, i kontynuuje wysyłanie transmisji na żywo. Zakładając, że przepustowość jest wyższa niż przepływność w strumieniu, a ping nie jest zbyt wysoki, więc w krótkim czasie stracona minuta będzie działać jako bufor dla strumienia, w ten sposób , jeśli utrata pakietów nastąpi ponownie, nie zauważysz.

Teraz przychodzi mi do głowy kilka urządzeń, w przypadku których nie byłby to dobry pomysł, na przykład wideokonferencje, w których zawsze musisz być na końcu transmisji, ponieważ opóźnienia podczas czatu wideo są po prostu okropne, ale podczas meczu piłkarskiego lub koncertu, jakie to ma znaczenie, jeśli jesteś minutę za strumieniem? Ponadto masz gwarancję, że otrzymasz wszystkie dane i lepiej byłoby zapisać je do późniejszego przeglądania, gdy pojawią się bez żadnych błędów.

To prowadzi mnie do mojego pytania. Czy są jakieś wady, o których nie wiem, jeśli chodzi o używanie protokołu TCP do transmisji na żywo? A może naprawdę powinno być, że jeśli masz odpowiednią przepustowość, powinieneś wybrać TCP, ponieważ jest „ładniejszy” dla sieci (kontrola przepływu)?

Wady używania TCP do wideo na żywo:

1. Zazwyczaj urządzenia do strumieniowego przesyłania wideo na żywo nie są zaprojektowane z myślą o przesyłaniu strumieniowym TCP. Jeśli używasz TCP, system operacyjny musi buforować niepotwierdzone segmenty dla każdego klienta. Jest to niepożądane, szczególnie w przypadku wydarzeń na żywo; prawdopodobnie Twoja lista jednoczesnych klientów jest długa ze względu na wyjątkowość wydarzenia. Wcześniej nagrane nagrania wideo zazwyczaj nie mają z tym większego problemu, ponieważ widzowie rozłożą się w czasie podczas odtwarzania; dlatego TCP jest bardziej odpowiedni do odtwarzania wideo na żądanie.
2. Multiemisja IP znacząco zmniejsza wymagania dotyczące przepustowości wideo dla dużych odbiorców; Protokół TCP zapobiega używaniu multiemisji IP, ale protokół UDP dobrze nadaje się do multiemisji IP.
3. Wideo na żywo to zwykle strumień o stałej szerokości pasma nagrywany z kamery; Nagrane strumienie wideo schodzą z dysku. Dynamika strat i odczekiwania TCP utrudnia obsługę wideo na żywo, gdy strumienie źródłowe mają stałą przepustowość (jak w przypadku wydarzenia na żywo). Jeśli buforujesz na dysku poza kamerą, upewnij się, że masz wystarczający bufor na nieprzewidziane zdarzenia sieciowe i zmienne szybkości wysyłania / wycofywania TCP. UDP zapewnia znacznie większą kontrolę nad tą aplikacją, ponieważ UDP nie dba o spadki warstwy transportowej sieci.

FYI, proszę nie używać słowa „pakiety” przy opisywaniu sieci. Sieci wysyłają „pakiety”.

ale podczas meczu piłki nożnej czy koncertu, jakie to ma znaczenie, jeśli jesteś minutę za strumieniem?

Dla niektórych fanów piłki nożnej całkiem sporo. Zauważono, że nawet kilkusekundowe opóźnienia występujące w cyfrowych strumieniach wideo spowodowane kodowaniem (lub czymkolwiek innym) mogą być bardzo irytujące, gdy podczas głośnych wydarzeń, takich jak mecze mistrzostw świata, słychać okrzyki i jęki chłopaków. obok (którzy oglądają niesprawny program analogowy), zanim zobaczysz ruchy w grze, które je spowodowały.

Myślę, że dla kogoś, kto bardzo interesuje się sportem (a to największa grupa klientów płacących za telewizję cyfrową, przynajmniej tutaj w Niemczech), bycie minutę za transmisją wideo na żywo byłoby całkowicie nie do przyjęcia (tak jak oni ”). d przełącz się na swojego konkurenta, jeśli tak się nie dzieje).

Zwykle strumień wideo jest w pewnym stopniu odporny na błędy. Więc jeśli niektóre pakiety się zgubią (na przykład z powodu przeciążenia routera po drodze), nadal będzie w stanie wyświetlać zawartość, ale z obniżoną jakością.

Jeśli Twoja transmisja na żywo korzystała z protokołu TCP / IP, będzie zmuszona zaczekać na te porzucone pakiety, zanim będzie mogła kontynuować przetwarzanie nowszych danych.

To podwójnie złe:

• stare dane zostaną ponownie przesłane (prawdopodobnie dla ramki, która została już wyświetlona, ​​a zatem bezwartościowa) i
• Nowe dane nie mogą przybyć aż po stare dane były retransmitowane

Jeśli Twoim celem jest wyświetlanie tak aktualnych informacji, jak to tylko możliwe (a w przypadku transmisji na żywo zazwyczaj chcesz być na bieżąco, nawet jeśli ramki wyglądają nieco gorzej), TCP zadziała przeciwko tobie.

W przypadku nagranego strumienia sytuacja jest nieco inna: prawdopodobnie będziesz buforować dużo więcej (prawdopodobnie kilka minut!) I wolisz ponownie przesłać dane niż mieć jakieś artefakty z powodu utraconych pakietów. W tym przypadku TCP jest dobrym dopasowaniem (można to oczywiście zaimplementować w UDP, ale TCP nie ma tak wielu wad, jak w przypadku transmisji na żywo).

Istnieją przypadki użycia odpowiednie dla transportu UDP i inne odpowiednie dla transportu TCP.

Przypadek użycia dyktuje również ustawienia kodowania wideo. Podczas transmitowania meczu piłkarskiego nacisk kładziony jest na jakość, a podczas wideokonferencji na opóźnienie.

Podczas korzystania z multiemisji do dostarczania wideo do klientów używany jest protokół UDP.

Wymóg multiemisji to kosztowny sprzęt sieciowy między serwerem rozgłoszeniowym a klientem. W praktyce oznacza to, że jeśli Twoja firma posiada infrastrukturę sieciową, możesz używać UDP i multiemisji do strumieniowego przesyłania obrazu na żywo. Nawet wtedy zaimplementowano również funkcję Quality of Service w celu oznaczania pakietów wideo i nadawania im priorytetów, aby nie doszło do utraty pakietów.

Multiemisja uprości oprogramowanie do nadawania, ponieważ sprzęt sieciowy będzie obsługiwał dystrybucję pakietów do klientów. Klienci subskrybują kanały multiemisji, a sieć zmieni konfigurację, aby kierować pakiety do nowego abonenta. Domyślnie wszystkie kanały są dostępne dla wszystkich klientów i można je optymalnie przekierowywać.

Ten przepływ pracy utrudnia proces autoryzacji. Sprzęt sieciowy nie odróżnia subskrybowanych użytkowników od innych użytkowników. Rozwiązaniem do autoryzacji jest szyfrowanie treści wideo i umożliwienie deszyfrowania w oprogramowaniu odtwarzacza, gdy subskrypcja jest ważna.

Przepływ pracy Unicast (TCP) umożliwia serwerowi sprawdzanie poświadczeń klienta i zezwala tylko na prawidłowe subskrypcje. Zezwalaj nawet tylko na określoną liczbę jednoczesnych połączeń.

Multiemisja nie jest włączona przez Internet.

Do przesyłania wideo przez Internet należy używać protokołu TCP. Gdy używany jest protokół UDP, programiści ponownie wdrażają retransmisję pakietów, np. Protokół na żywo Bittorrent p2p.

„Jeśli używasz protokołu TCP, system operacyjny musi buforować niepotwierdzone segmenty dla każdego klienta. Jest to niepożądane, szczególnie w przypadku wydarzeń na żywo”.

Ten bufor musi istnieć w jakiejś formie. To samo dotyczy bufora jittera po stronie gracza. Nazywa się to „buforem gniazda” i oprogramowanie serwera może wiedzieć, kiedy ten bufor jest pełny i odrzucać odpowiednie klatki wideo dla strumieni na żywo. Lepiej jest używać metody unicast / TCP, ponieważ oprogramowanie serwera może implementować odpowiednią logikę gubienia ramek. Losowe brakujące pakiety w przypadku UDP spowodują po prostu złe wrażenia użytkownika. jak na tym filmie: http://tinypic.com/r/2qn89xz/9

„Multiemisja IP znacznie zmniejsza wymagania dotyczące przepustowości wideo w przypadku dużych odbiorców”

Dotyczy to sieci prywatnych, multiemisja nie jest włączona przez Internet.

„Zwróć uwagę, że jeśli TCP traci zbyt wiele pakietów, połączenie znika; w ten sposób UDP zapewnia znacznie większą kontrolę nad tą aplikacją, ponieważ UDP nie dba o spadki warstwy transportowej sieci”.

UDP nie dba również o porzucanie całych ramek lub grup ramek, więc nie daje większej kontroli nad wrażeniami użytkownika.

„Zwykle strumień wideo jest w pewnym stopniu odporny na błędy”

Wideo zakodowane nie jest odporne na błędy. Podczas przesyłania przez zawodny transport, do kontenera wideo dodawana jest korekcja błędów. Dobrym przykładem jest kontener MPEG-TS używany w satelitarnej transmisji wideo, który przenosi kilka strumieni audio, wideo, EPG itp. Jest to konieczne, ponieważ łącze satelitarne nie jest komunikacją dupleksową, co oznacza, że ​​odbiornik nie może zażądać ponownej transmisji utraconych pakietów.

Gdy dostępna jest komunikacja dupleksowa, zawsze lepiej jest ponownie przesyłać dane tylko do klientów, którzy utracili pakiety, niż uwzględnić narzut korekcji błędów przesyłania w strumieniu wysyłanym do wszystkich klientów.

W każdym razie zgubione pakiety są nie do przyjęcia. Gubione ramki są w porządku w wyjątkowych przypadkach, gdy przepustowość jest ograniczona.

Rezultatem brakujących pakietów są artefakty takie jak ten:

Niektóre dekodery mogą przerywać strumienie brakujących pakietów w krytycznych miejscach.

Polecam zapoznać się z nowym protokołem p2p Live, Bittorent Live .

Jeśli chodzi o przesyłanie strumieniowe, lepiej jest używać UDP, po pierwsze, ponieważ zmniejsza obciążenie serwerów, ale głównie dlatego, że możesz wysyłać pakiety z multiemisją, jest to prostsze niż wysyłanie ich do każdego podłączonego klienta.

To zależy. Jak ważna jest zawartość, którą przesyłasz? Jeśli krytyczny, użyj TCP. Może to powodować problemy z przepustowością, jakością wideo (może być konieczne użycie niższej jakości, aby poradzić sobie z opóźnieniem) i opóźnieniem. Ale jeśli potrzebujesz treści, aby się tam dostać, użyj jej.

W przeciwnym razie UDP powinien być dobry, jeśli strumień nie jest krytyczny i byłby preferowany, ponieważ UDP ma zwykle mniejszy narzut.

Jednym z największych problemów związanych z dostarczaniem wydarzeń na żywo w Internecie jest „skala”, a protokół TCP nie skaluje się dobrze. Na przykład, gdy transmitujesz mecz piłki nożnej na żywo - w przeciwieństwie do odtwarzania filmów na żądanie - liczba osób oglądających może z łatwością być 1000 razy większa. W takim scenariuszu używanie TCP jest wyrokiem śmierci dla CDN (sieci dostarczania treści).

Istnieje kilka głównych powodów, dla których TCP nie skaluje się dobrze:

1. Jednym z największych kompromisów protokołu TCP jest zmienność przepustowości, jaką można osiągnąć między nadawcą a odbiorcą. Podczas przesyłania strumieniowego wideo przez Internet pakiety wideo muszą przechodzić przez wiele routerów w Internecie, a każdy z tych routerów jest połączony połączeniami o innej szybkości. Algorytm TCP zaczyna się od małego okna TCP, a następnie rośnie, aż do wykrycia utraty pakietów, utrata pakietów jest uważana za oznakę przeciążenia, a TCP odpowiada na to, drastycznie zmniejszając rozmiar okna, aby uniknąć zatoru. W ten sposób natychmiast zmniejsza efektywną przepustowość. Teraz wyobraź sobie sieć z transmisją TCP wykorzystującą 6-7 przeskoków routera do klienta (bardzo normalny scenariusz), jeśli którykolwiek z routerów pośrednich utraci pakiet, TCP dla tego łącza zmniejszy szybkość transmisji. W rzeczywistości przepływ ruchu między routerami ma kształt przypominający klepsydrę; zawsze gong w górę iw dół pomiędzy jednym z pośrednich routerów. Renderowanie efektywne przez było znacznie niższe w porównaniu z najlepszym wysiłkiem UDP.

2. Jak być może już wiesz, TCP jest protokołem opartym na potwierdzeniach. Załóżmy na przykład, że nadawca jest oddalony o 50 ms (tj. Opóźnienie między dwoma punktami). Oznaczałoby to, że czas potrzebny na wysłanie pakietu do odbiorcy i wysłanie przez odbiorcę potwierdzenia wyniósłby 100 ms; tak więc maksymalna możliwa przepustowość w porównaniu z transmisją opartą na UDP jest już o połowę mniejsza.

3. Protokół TCP nie obsługuje multiemisji ani nowego powstającego standardu multiemisji AMT. Oznacza to, że sieci CDN nie mają możliwości zmniejszenia ruchu w sieci poprzez replikację pakietów - gdy wielu klientów ogląda tę samą zawartość. Już to jest wystarczającym powodem, dla którego sieci CDN (takie jak Akamai czy Level3) nie korzystają z protokołu TCP do transmisji na żywo.

Czytając debatę o TCP UDP zauważyłem logiczną lukę. Utrata pakietów TCP powodująca jednominutowe opóźnienie, która jest konwertowana na jednominutową przechyłkę kolejną bufora, jest skorelowana z porzuceniem protokołu UDP o pełną minutę przy tej samej utracie. Bardziej uczciwe porównanie jest następujące.

W protokole TCP następuje utrata pakietów. Wideo jest zatrzymywane, podczas gdy TCP ponownie wysyła pakiety, próbując strumieniowo przesyłać idealne matematycznie pakiety. Wideo jest opóźnione o jedną minutę i rozpoczyna się w miejscu, w którym zostało przerwane, gdy brakujący pakiet dotrze do celu. Wszyscy czekamy, ale wiemy, że nie przegapimy ani jednego piksela.

UDP doświadcza utraty pakietów. Na sekundę podczas transmisji wideo róg ekranu staje się nieco zamazany. Nikt nie zauważa, a pokaz toczy się dalej bez szukania zagubionych pakietów.

Wszystko, co jest przesyłane strumieniowo, czerpie największe korzyści z UDP. Utrata pakietów powodująca jednominutowe opóźnienie w TCP nie spowodowałaby jednominutowego opóźnienia w UDP. Biorąc pod uwagę, że większość systemów używa strumieni o wielu rozdzielczościach, co powoduje, że rzeczy stają się blokowe, gdy brakuje pakietów, jeszcze bardziej sensowne jest użycie UDP.

UDP FTW podczas przesyłania strumieniowego.

Jeśli przepustowość jest znacznie większa niż szybkość transmisji bitów, polecam TCP do przesyłania strumieniowego wideo na żywo w trybie emisji pojedynczej.

Przypadek 1: Kolejne pakiety są tracone na okres kilku sekund. => wideo na żywo zatrzyma się po stronie klienta niezależnie od warstwy transportowej (TCP lub UDP). Po przywróceniu sieci: - jeśli używany jest protokół TCP, odtwarzacz wideo klienta może wybrać ponowne uruchomienie strumienia przy pierwszym utraconym pakiecie (przesunięcie w czasie) LUB porzucić wszystkie późne pakiety i ponownie uruchomić strumień wideo bez przesunięcia w czasie. - jeśli używany jest UDP, po stronie klienta nie ma wyboru, wideo uruchamia się ponownie na żywo bez przesunięcia w czasie. => TCP równe lub lepsze.

Przypadek 2: niektóre pakiety są losowo i często gubione w sieci. - jeśli używany jest protokół TCP, pakiety te będą natychmiast retransmitowane, a przy odpowiednim buforze jittera nie będzie to miało wpływu na jakość / opóźnienie strumienia wideo. - jeśli używany jest UDP, jakość wideo będzie słaba. => TCP znacznie lepiej

W przypadku przesyłania strumieniowego wideo ograniczenie przepustowości systemu jest prawdopodobnie. Korzystając z multiemisji, można znacznie zmniejszyć ilość wykorzystywanej przepustowości wysyłania. Dzięki UDP możesz łatwo rozsyłać swoje pakiety do wszystkich podłączonych terminali. Możesz także użyć niezawodnego protokołu multiemisji, nazywanego Pragmatic General Multicast (PGM), nic o nim nie wiem i myślę, że nie jest on rozpowszechniony w użyciu.

Oprócz wszystkich innych powodów, UDP może używać multiemisji. Obsługa tysięcy użytkowników TCP transmitujących te same dane marnuje przepustowość. Istnieje jednak inny ważny powód, dla którego warto używać protokołu TCP.

TCP może znacznie łatwiej przejść przez zapory i NAT. W zależności od NAT i operatora możesz nawet nie być w stanie odebrać strumienia UDP z powodu problemów z dziurkowaniem UDP.

Wszystkie odpowiedzi „użyj UDP” zakładają otwartą sieć i podejście „zapchaj ją jak najwięcej”. Dobre dla starych sieci audio / wideo typu zamkniętego ogrodu, które są zanikającym rodzajem.

W rzeczywistości twoja transmisja przechodzi przez zapory ogniowe (które odrzucają multiemisję, a czasem udp), sieć jest współdzielona z innymi ważniejszymi aplikacjami ($$$), więc chcesz ukarać nadużywających skalowaniem okien.

Chodzi o to, że jest to bardziej kwestia treści niż czasu. Protokół TCP wymaga, aby pakiet, który nie został dostarczony, został sprawdzony, zweryfikowany i ponownie dostarczony. UDP nie korzysta z tego wymagania. Więc jeśli wysłałeś plik, który zawiera miliony pakietów za pomocą UDP, na przykład wideo, jeśli niektórych pakietów brakuje w momencie dostarczenia, najprawdopodobniej nie zostaną one pominięte.