it-swarm.com.de

TCP vs UDP im Videostream

Ich bin gerade von meiner Prüfung in Netzwerkprogrammierung nach Hause gekommen, und eine der Fragen, die sie uns stellten, war "Wenn Sie Videos streamen möchten, würden Sie TCP oder UDP verwenden? Geben Sie eine Erklärung sowohl für gespeicherte als auch für Live-Video-Streams ". Auf diese Frage haben sie einfach eine kurze Antwort von TCP für gespeichertes Video und UDP für Live-Video erwartet, aber ich habe auf meinem Heimweg darüber nachgedacht, und ist es unbedingt besser, UDP für das Streaming von Live-Video zu verwenden? Ich meine, wenn Sie die Bandbreite dafür haben und sagen, dass Sie ein Fußballspiel oder ein Konzert streamen, brauchen Sie dann wirklich UDP?

Nehmen wir an, dass Sie beim Streamen dieses Konzerts oder was auch immer mit TCP anfangen, Pakete zu verlieren (in einem Netzwerk zwischen Ihnen und dem Absender ist etwas Schlimmes passiert), und für eine ganze Minute erhalten Sie keine Pakete. Der Videostream wird angehalten und nach Ablauf der Minute werden die Pakete wieder durchgeschickt (IP hat eine neue Route für Sie gefunden). Was dann passieren würde, ist, dass TCP die Minute, die Sie verloren haben, erneut überträgt und Ihnen weiterhin den Live-Stream sendet. Angenommen, die Bandbreite ist höher als die Bitrate im Stream und der Ping ist nicht zu hoch. In kurzer Zeit fungiert die Minute, die Sie verloren haben, auf diese Weise als Puffer für den Stream Wenn der Paketverlust erneut auftritt, werden Sie es nicht bemerken.

Nun kann ich mir einige Geräte vorstellen, bei denen dies keine gute Idee wäre, wie zum Beispiel Videokonferenzen, bei denen Sie müssen immer am Ende des Streams sein müssen, weil sich ein Video verzögert - Chat ist einfach schrecklich, aber während eines Fußballspiels oder eines Konzerts ist es wichtig, wenn Sie eine Minute hinter dem Stream sind. Außerdem haben Sie die Garantie, dass Sie alle Daten erhalten, und es ist besser, sie für eine spätere Anzeige zu speichern, wenn sie fehlerfrei eingehen.

Das bringt mich zu meiner Frage. Gibt es Nachteile, von denen ich nichts über die Verwendung von TCP für das Live-Streaming weiß? Oder sollte es wirklich so sein, dass wenn Sie die Bandbreite dafür haben, Sie sich für TCP entscheiden sollten, vorausgesetzt, es ist "netter" für das Netzwerk (Flusskontrolle)?

87
Alxandr

Nachteile der Verwendung von TCP für Live-Videos:

  1. In der Regel sind Live-Video-Streaming-Appliances nicht für das Streaming von TCP konzipiert. Wenn Sie TCP verwenden, muss das Betriebssystem die nicht bestätigten Segmente für jeden Client puffern. Dies ist insbesondere bei Live-Events unerwünscht; Vermutlich ist Ihre Liste der gleichzeitigen Kunden aufgrund der Einzigartigkeit des Ereignisses lang. Aufgezeichnete Video-Casts haben in der Regel kein so großes Problem, da die Zuschauer ihre Wiedergabeaktivitäten verschieben. Daher ist TCP besser für die Wiedergabe eines Video-on-Demand geeignet.
  2. IP-Multicast reduziert die Anforderungen an die Videobandbreite für große Zielgruppen erheblich. TCP verhindert die Verwendung von IP-Multicast, UDP ist jedoch für IP-Multicast gut geeignet.
  3. Live-Video ist normalerweise ein Stream mit konstanter Bandbreite, der von einer Kamera aufgezeichnet wurde. Aufgezeichnete Videostreams werden von einer Festplatte abgespielt. Die Loss-Backoff-Dynamik von TCP erschwert die Bereitstellung von Live-Videos, wenn die Quell-Streams eine konstante Bandbreite aufweisen (wie dies bei einem Live-Ereignis der Fall wäre). Stellen Sie sicher, dass Sie über genügend Puffer für unvorhersehbare Netzwerkereignisse und variable TCP Sende-/Backoff-Raten verfügen, wenn Sie die Festplatte einer Kamera puffern. UDP gibt Ihnen viel mehr Kontrolle über diese Anwendung, da UDP sich nicht um Netzwerk-Transport-Layer-Drops kümmert.

Bitte verwenden Sie nicht die Word "Pakete", wenn Sie Netzwerke beschreiben. Netzwerke senden "Pakete".

75
Mike Pennington

aber während eines Fußballspiels oder eines Konzerts, was macht es aus, wenn Sie eine Minute hinter dem Strom sind?

Für manche Fußballfans schon einiges. Es wurde angemerkt, dass Verzögerungen von nur wenigen Sekunden in digitalen Videostreams aufgrund von Codierung (oder was auch immer) sehr ärgerlich sein können, wenn Sie während hochkarätiger Ereignisse wie Weltcup-Matches das Jubeln und Stöhnen der Jungs hören nebenan (die gerade ein unpassendes analoges Programm sehen), bevor Sie die Spielzüge sehen, die sie verursacht haben.

Ich denke, für jemanden, der sich sehr für Sport interessiert (und das ist die größte Gruppe zahlender Kunden für digitales Fernsehen, zumindest hier in Deutschland), wäre es völlig inakzeptabel, in einem Live-Videostream eine Minute zurückzubleiben (wie in d Wechseln Sie zu Ihrem Konkurrenten, wo dies nicht der Fall ist.

25

Normalerweise ist ein Videostream etwas fehlertolerant. Wenn also einige Pakete verloren gehen (z. B. weil ein Router unterwegs überlastet ist), kann er den Inhalt weiterhin anzeigen, jedoch mit verringerter Qualität.

Wenn Ihr Live-Stream TCP/IP verwenden würde, wäre er gezwungen , auf die verworfenen Pakete zu warten bevor könnte er fortgesetzt werden Verarbeitung neuerer Daten.

Das ist doppelt schlecht:

  • alte Daten erneut übertragen werden (das ist wahrscheinlich für einen Rahmen, der bereits angezeigt wurde und daher wertlos) nd
  • neue Daten können erst eintreffen, wenn alte Daten erneut übertragen wurden

Wenn es Ihr Ziel ist, so aktuelle Informationen wie möglich anzuzeigen (und für einen Live-Stream möchten Sie normalerweise auf dem neuesten Stand sein, auch wenn Ihre Frames etwas schlechter aussehen), dann TCP wird gegen dich arbeiten.

Bei einem aufgezeichneten Stream sieht die Situation etwas anders aus: Sie puffern wahrscheinlich viel mehr (möglicherweise mehrere Minuten!) Und lassen die Daten lieber erneut übertragen, als dass einige Artefakte aufgrund verlorener Pakete auftreten. In diesem Fall ist TCP eine gute Übereinstimmung (dies könnte natürlich immer noch in UDP implementiert werden, aber TCP hat nicht so viele Nachteile wie für die Live-Stream-Fall).

17
Joachim Sauer

Es gibt einige Anwendungsfälle, die für den UDP-Transport geeignet sind, und andere, die für den TCP Transport geeignet sind.

Der Anwendungsfall bestimmt auch die Codierungseinstellungen für das Video. Bei der Übertragung von Fußballspielen liegt der Schwerpunkt auf der Qualität und bei Videokonferenzen auf der Latenz.

Bei Verwendung von Multicast zur Bereitstellung von Videos für Ihre Kunden wird UDP verwendet.

Voraussetzung für Multicast ist teure Netzwerkhardware zwischen Broadcast-Server und Kunde. In der Praxis bedeutet dies, dass Sie, wenn Ihr Unternehmen über eine Netzwerkinfrastruktur verfügt, UDP und Multicast für das Live-Video-Streaming verwenden können. Selbst dann wird Quality-of-Service implementiert, um Videopakete zu markieren und zu priorisieren, damit kein Paketverlust auftritt.

Multicast vereinfacht die Broadcast-Software, da die Netzwerkhardware die Verteilung von Paketen an Kunden übernimmt. Kunden, die Multicast-Kanäle abonnieren, und das Netzwerk konfigurieren sich neu, um Pakete an neue Teilnehmer weiterzuleiten. Standardmäßig stehen alle Kanäle allen Kunden zur Verfügung und können optimal geroutet werden.

Dieser Workflow erschwert den Autorisierungsprozess. Die Netzwerkhardware unterscheidet abonnierte Benutzer nicht von anderen Benutzern. Die Lösung für die Autorisierung besteht darin, Videoinhalte zu verschlüsseln und die Entschlüsselung in der Player-Software zu aktivieren, wenn das Abonnement gültig ist.

Mit dem Unicast-Workflow (TCP) kann der Server die Anmeldeinformationen des Clients überprüfen und nur gültige Abonnements zulassen. Auch erlauben nur eine bestimmte Anzahl von gleichzeitigen Verbindungen.

Multicast ist nicht über das Internet aktiviert.

Für die Übertragung von Videos über das Internet muss TCP verwendet werden. Wenn UDP verwendet wird, implementieren Entwickler am Ende die Paketweiterleitung erneut, z. B. das Bittorrent p2p-Live-Protokoll.

"Wenn Sie TCP verwenden, muss das Betriebssystem die nicht bestätigten Segmente für jeden Client puffern. Dies ist insbesondere bei Live-Ereignissen unerwünscht.".

Dieser Puffer muss in irgendeiner Form vorhanden sein. Gleiches gilt für den Jitterpuffer auf der Spielerseite. Es wird "Socket-Puffer" genannt und die Serversoftware kann erkennen, wann dieser Puffer voll ist, und die richtigen Videoframes für Live-Streams verwerfen. Es ist besser, die Unicast/TCP-Methode zu verwenden, da die Serversoftware die richtige Frame-Drop-Logik implementieren kann. Zufällige fehlende Pakete in UDP-Fällen führen nur zu einer schlechten Benutzererfahrung. wie in diesem Video: http://tinypic.com/r/2qn89xz/9

"IP-Multicast reduziert die Anforderungen an die Videobandbreite für große Zielgruppen erheblich"

Dies gilt für private Netzwerke. Multicast wird nicht über das Internet aktiviert.

"Beachten Sie, dass, wenn TCP zu viele Pakete verliert, die Verbindung unterbrochen wird; UDP bietet Ihnen daher viel mehr Kontrolle für diese Anwendung, da UDP sich nicht um Netzwerk-Transport-Layer-Ausfälle kümmert."

UDP kümmert sich auch nicht darum, ganze Frames oder Framegruppen zu löschen, sodass es keine Kontrolle mehr über die Benutzererfahrung gibt.

"Normalerweise ist ein Videostream etwas fehlertolerant"

Codiertes Video ist nicht fehlertolerant. Bei der Übertragung über einen unzuverlässigen Transport wird dem Videocontainer eine Vorwärtsfehlerkorrektur hinzugefügt. Ein gutes Beispiel ist der MPEG-TS-Container, der in Satellitenvideosendungen verwendet wird, die mehrere Audio-, Video-, EPG- usw. Streams übertragen. Dies ist erforderlich, da es sich bei der Satellitenverbindung nicht um eine Duplex-Kommunikation handelt, dh der Empfänger kann keine erneute Übertragung verlorener Pakete anfordern.

Wenn Sie über Duplex-Kommunikation verfügen, ist es immer besser, Daten nur an Clients mit Paketverlust erneut zu übertragen, als den Aufwand für die Weiterleitungsfehlerkorrektur in den an alle Clients gesendeten Datenstrom einzubeziehen.

In jedem Fall sind verlorene Pakete inakzeptabel. Verworfene Frames sind in Ausnahmefällen in Ordnung, wenn die Bandbreite eingeschränkt ist.

Das Ergebnis fehlender Pakete sind Artefakte wie dieses: artifacts

Einige Decoder können bei Streams, bei denen Pakete an kritischen Stellen fehlen, eine Unterbrechung verursachen.

7
Alex

Ich empfehle Ihnen, sich das neue p2p-Live-Protokoll anzuschauen Bittorent Live .

Für das Streaming ist es besser, UDP zu verwenden, da es zunächst die Belastung der Server verringert. Meistens ist es jedoch einfacher, Pakete mit Multicast zu senden, als sie an jeden verbundenen Client zu senden.

4

Es hängt davon ab, ob. Wie kritisch ist der Inhalt, den Sie streamen? Wenn Sie kritisch sind, verwenden Sie TCP. Dies kann zu Problemen mit der Bandbreite, der Videoqualität (möglicherweise müssen Sie eine niedrigere Qualität verwenden, um die Latenz zu bewältigen) und der Latenz führen. Aber wenn Sie den Inhalt benötigen, um garantiert dorthin zu gelangen, verwenden Sie ihn.

Andernfalls sollte UDP in Ordnung sein, wenn der Stream nicht kritisch ist, und sollte bevorzugt werden, da UDP tendenziell weniger Overhead hat.

3
Webs

Eines der größten Probleme bei der Übertragung von Live-Events im Internet ist die Skalierung, und TCP skaliert nicht gut. Zum Beispiel, wenn Sie ein Live-Fußballspiel übertragen - im Gegensatz zu einem On-Demand-Spiel Filmwiedergabe - die Anzahl der Zuschauer kann leicht das 1000-fache betragen. In einem solchen Szenario ist die Verwendung von TCP ist ein Todesurteil für die CDNs (Content Delivery Networks).

Es gibt ein paar Hauptgründe, warum TCP nicht gut skaliert:

  1. Einer der größten Nachteile von TCP ist die zwischen Sender und Empfänger erreichbare Variabilität des Durchsatzes. Beim Streamen von Videos über das Internet müssen die Videopakete mehrere Router über das Internet durchlaufen, jeder dieser Router Der TCP Algorithmus startet mit TCP Fenster aus klein, wächst dann bis Paketverlust erkannt wird, der Paketverlust wird als Vorzeichen gewertet von Überlastung und TCP reagiert darauf, indem die Fenstergröße drastisch verringert wird, um Überlastung zu vermeiden. Dadurch wird wiederum der effektive Durchsatz sofort verringert. Stellen Sie sich nun ein Netzwerk mit TCP= vor Übertragung über 6-7 Router Springt zum Client (ein ganz normales Szenario). Wenn einer der Zwischenrouter ein Paket verliert, wird die Übertragungsrate durch TCP für diese Verbindung) verringert Der Verkehrsfluss zwischen den Routern folgt einer Sanduhrform, die immer zwischen einem der Zwischenrouter auf und ab wechselt Der effektive Durchsatz ist im Vergleich zu Best-Effort-UDP deutlich geringer.

  2. Wie Sie vielleicht bereits wissen, ist TCP ein bestätigungsbasiertes Protokoll. Nehmen wir zum Beispiel an, ein Absender ist 50 ms entfernt (dh Latenzzeit zwischen zwei Punkten). Dies würde bedeuten, dass ein Paket Zeit benötigt an einen empfänger gesendet und empfänger zum senden einer bestätigung 100ms, somit ist der maximal mögliche durchsatz im vergleich zur UDP-basierten übertragung bereits halbiert.

  3. Das TCP unterstützt kein Multicasting oder den neu aufkommenden Standard des Multicasting AMT. Dies bedeutet, dass die CDNs nicht die Möglichkeit haben, den Netzwerkverkehr durch Replikation der Pakete zu reduzieren, wenn viele Clients das Multicasting überwachen Gleicher Inhalt. Das ist selbst ein Grund genug für CDNs (wie Akamai oder Level3), nicht mit TCP für Live-Streams zu gehen.

2
Waqas

Bei Video-Streaming ist die Bandbreite wahrscheinlich die Einschränkung für das System. Mit Multicast können Sie die Menge der verwendeten Upstream-Bandbreite erheblich reduzieren. Mit UDP können Sie Ihre Pakete problemlos an alle angeschlossenen Terminals multicasten. Sie können auch ein zuverlässiges Multicast-Protokoll verwenden, das Pragmatic General Multicast (PGM) heißt. Ich weiß nichts darüber und denke, es ist in seiner Verwendung nicht weit verbreitet.

1
eyesathousand

Wenn die Bandbreite weit über der Bitrate liegt, würde ich TCP für Unicast-Live-Video-Streaming empfehlen.

Fall 1: Aufeinanderfolgende Pakete gehen für mehrere Sekunden verloren. => Live-Video stoppt auf der Client-Seite unabhängig von der Transportschicht (TCP oder UDP). Wenn das Netzwerk wiederhergestellt wird: - Wenn TCP) verwendet wird, kann der Client-Videoplayer den Stream beim ersten verlorenen Paket neu starten (Timeshift) OR), um alle zu löschen Verspätete Pakete und Neustarten des Videostreams ohne Timeshift. - Wenn UDP verwendet wird, gibt es auf der Clientseite keine Wahl. Videostart live ohne Timeshift. => TCP gleich oder besser.

Fall 2: Einige Pakete gehen zufällig und häufig im Netzwerk verloren. - Wenn TCP verwendet wird, werden diese Pakete sofort erneut übertragen, und bei korrektem Jitterpuffer hat dies keine Auswirkungen auf die Qualität/Latenz des Videostreams. - Wenn UDP verwendet wird, wird die Videoqualität übernommen arm sein. => TCP viel besser

1
Stan33

Alle "Use UDP" -Antworten setzen ein offenes Netzwerk voraus und "stopfen es so weit wie möglich". Gut für geschlossene Audio-/Videonetzwerke im alten Stil, die verschwinden.

In der tatsächlichen Welt wird Ihre Übertragung durch Firewalls gehen (die Multicast und manchmal udp fallen lassen), das Netzwerk wird mit anderen wichtigeren ($$$) Apps geteilt, so dass Sie wollen, um Missbraucher mit zu bestrafen Fensterskalierung.

1
nim

Beim Lesen der TCP UDP-Debatte ist mir ein logischer Fehler aufgefallen. Ein TCP Paketverlust, der eine Verzögerung von einer Minute verursacht, die in einen 1-Minuten-Puffer umgewandelt wird, kann nicht korreliert werden UDP fällt eine volle Minute ab, während derselbe Verlust auftritt. Ein fairerer Vergleich ist wie folgt.

TCP erleidet einen Paketverlust. Das Video wird angehalten, während TCP die Pakete erneut gesendet werden, um mathematisch perfekte Pakete zu streamen. Das Video wird um eine Minute verzögert und dort wieder aufgenommen, wo es aufgehört hat, nachdem das fehlende Paket sein Ziel erreicht hat. Wir alle warten jedoch Wir wissen, dass wir kein einziges Pixel verpassen werden.

UDP hat einen Paketverlust. Während des Videostreams wird eine Ecke des Bildschirms für eine Sekunde etwas unscharf. Niemand merkt es und die Show geht weiter, ohne nach den verlorenen Paketen zu suchen.

Alles, was Streams liefert, profitiert am meisten von UDP. Der Paketverlust, der eine Verzögerung von einer Minute auf TCP) verursacht, würde keine Verzögerung von einer Minute auf UDP verursachen. Wenn man bedenkt, dass die meisten Systeme Streams mit mehreren Auflösungen verwenden, ist es sogar noch sinnvoller, Dinge blockieren zu lassen, wenn sie nach Paketen hungern UDP verwenden.

UDP FTW beim Streaming.

1
user3439082

Neben all den anderen Gründen kann UDP Multicast verwenden. Die Unterstützung von Tausenden von TCP Benutzern, die alle dieselben Daten übertragen, verschwendet Bandbreite. Es gibt jedoch einen weiteren wichtigen Grund für die Verwendung von TCP.

TCP kann viel einfacher durch Firewalls und NATs gelangen. Abhängig von Ihrem NAT und Ihrem Operator können Sie möglicherweise aufgrund von Problemen mit dem UDP-Hole-Punching nicht einmal einen UDP-Stream empfangen.

1
Andy

Dies ist die Sache, es ist eher eine Frage des Inhalts als der Zeit. Das TCP Protokoll verlangt, dass ein nicht zugestelltes Paket überprüft, verifiziert und erneut zugestellt wird. UDP verwendet diese Anforderung nicht. Wenn Sie also eine Datei senden, die Millionen von Paketen enthält, verwenden Sie UDP, wie z Wenn in einem Video einige der Pakete bei der Lieferung fehlen, werden sie höchstwahrscheinlich nicht angenommen.

0
Angel