4.4.3 TCP versus UDP

TCP

TCP garantiert den fehlerfreien und sicheren Transport der Daten durch Ankuftsbestätigungsmeldungen. In UDP gibt es keine solche Versicherung.¹

Da http-Streams über TCP (und nicht über UDP) funktionieren (http verwendet immer TCP²), wird überprüft, ob denn alle Datenpakete angekommen sind. Das erfolgt über eine Acknowledge-Message. (Das ist das typische 'Transfer Control Protokoll'-Auslieferungsverhalten.)

Eine Grafik dazu ist im Unterkaptitel 'Streaming via TCP und http' zu sehen. Darunter gibt es eine kurze Erklärung. Deshalb gibt es an dieser Stelle nur einen Thumbnail der Grafik 'Abbildung 8: TCP-Streaming erklärt in der Server-Client-Struktur' mit Link zu sehen.

Thumbnail TCP-Streaming

Es hat sich aber heraus gestellt, dass TCP nicht immer das beste Prinzip ist. Für Stream-Übertragungen ist es gar nicht so entscheidend, dass alle Daten beim Empfänger eintreffen. Viel wichtiger erscheint, dass sie zeitnah ankommen; ein paar Prozent Datenverlust sind mitunter vom Empfänger gar nicht wahrnehmbar bzw. werden nicht zwangsmäßig als störend empfunden. Ein kurzer Unterbruch stört die Wahrnehmung aber fast immer.

Puffer leergelaufen ('buffer underrun') unter TCP

Mit TCP kann ein 'buffer-underrun' passieren, weil Übertragungsfehler sich angestaut haben. Bei Netzwerk-Problemen steigen die Übertragungsfehler und mit TCP auch die zusätzlichen Nachfragen, um fehlerhafte Pakete nochmals zugestellt zu bekommen. Damit erhöht sich die Anzahl der Anfragen, denn es wird solange nachgefragt und wiederholt, bis die Pakete richtig angekommen sind. Die gehäuften Anfragen verlangsamt das Herausgeben der aktuellen Daten. Der Server kommt mit dem Daten-Nachschub nicht mehr nach. Der Client hat zu wenig Daten zum Abspielen – der Puffer läuft leer. Ein komplett leerer Puffer bedeutet kein Audio zum Abspielen. Es kommt zu Hackern und zu längeren Aussetzern, weil die Nachfragen des TCP sich erst abbauen müssen. Eventuell reißt die Übertragung ab und muss komplett neu aufgebaut werden.

UDP kennt auch 'buffer underruns'. Das Hochschaukeln von Anfragen ist aber TCP-spezifisch. Es macht die Situation bei Übertragungsfehlern schwierig. Für Video-Streaming ist das nochmals problematischer, weil viel größere Datenmengen transportiert werden müssen (meist besteht Video aus Ton und Bild).
 

Die Latenz ist bei TCP nicht so genau absehbar, denn die Pakete können erst abgespielt werden, wenn die Ankunft auch bestätigt wurde. Das benötigt mehr Zeit als bei UDP ohne Sicherheitsabfragen. Streaming-Experte Stefan Giessler von Barix weißt darauf hin, das TCP nicht für Sattelitenübertragung geeignet ist. Die 300 bis 800 ms vor dem Verbindungsabbruch (Timeout) reicht für eine stabile Übertragung nicht aus.³
 

Netzwerkaufzeichnung eines http-Streams

Abbildung 11: Netzwerk-Verkehr eines Testgerätes, dass ein http-Stream bezieht (Pull)

In der Abbildung oben bezieht das Testgerät (192.168.11.133) einen Stream aus dem Internet (vom Server 212.53.158.91) über TCP. Jedes Paket wird bestätigt. (Destination und Source wechseln.) Der verwendete Port des Streaming-Servers ist 8000 (wie in der Paketinfo unten gelistet ist. 'irdmi' steht in diesem Fall für 8000.) Ebenfalls in diesem Screenshot zu sehen - das Eintreffen vom Server zweier aufeinander folgenden Paketen dauerte bis zu 270 Millisekunden.

Internet-Radio ist über http

Die Kehrseite von http-Streaming ist für Audio nicht so gravierend. Die Nachteile stören selten. Im gesamten Angebot von Internet-Radios, sowie im Audio-Consumer-Bereich, ist http-Streaming und das Anfordern des Streams über 'Progressive Download' der Standard!

Der Vorteil bei http-Streaming ist die durch die Verbreitung vom WWW bekannten und etablierten Bedingungen von TCP. Es müssen keine Ports an der Firewall frei geschalten werden. http-Streaming und Internet-Radio ist somit der breite Masse und ohne langwierige Konfigurationsarbeiten zugänglich.

Die Nachteile wiegen nicht so schwer. Audio-Frames kommen normalerweise nicht durcheinander – es wird jeder einzeln bestätigt (TCP). Es kommt nur selten zu Drop-Outs und das nur, wenn es zu Netzwerk-, Bandbreiten- oder Leitungsproblemen kommt. Im Gegensatz zu Video wird hier nur ein Bruchteil an Daten benötigt und über das Internet verschickt.
 

UDP und RTP

Im Gegensatz zu TCP und http beruht VoIP, die Telefonie über das Internet, auf dem SIP-Protokoll, das üblicherweise UDP als Daten-Übertragungsart verwendet.⁴ UDP ist für Live-Streaming vorzuziehen, um Aussetzer und Hacker im Audio zu vermeiden. Wenn dort ein paar Pakete des nötig-großen Datenstrom verloren gehen, ist das kaum zu hören.

Eine brauchbare Lösung dafür ist das 'Realtime Transport Protokoll'. „RTP [...] gewährleistet einen durchgängigen Transport von Daten in Echtzeit. Speziell für Audio- und Video-Daten, bei denen je nach Codec 1-20% Paketverlust tolerierbar sind.“⁵ (Codecs werden in einem nachfolgenden Kapitel näher erläutert.) RTP verwendet UDP. Im Header werden einige Zusatzinformationen für jedes Datenpakets mitgeschickt: Codec, Sequenznummer, Zeitstempel, Synchronisation und evt. Verschlüsselung.⁶ Der Stream hat damit den Vorteil, dass die Pakete in der richtigen Reihenfolge zusammen gesetzt werden können.

Eine Fehlerkorrektur bei RTP kann durch Kopieren von Paketen erfolgen. Ein Paket, das verloren gegangen ist, kann so nicht hörbar überbrückt werden. Auch beim Ausfall von zwei, drei Paketen ist das kaum hörbar. (Die Paketlänge ist ein Frame. Bei mp3 ist das je nach Sample-Rate von 32kHz, 44.1kHz, 48kHz, entsprechend 36ms, 26ms, 34ms.)⁷

RTP-Streams, die UDP verwenden, sind somit geeigneter für einen Echtzeit/„live“-Betrieb. Verluste werden besser überspielt. verwendet per Definition TCP. Die Daten werden dabei auf Vollständigkeit überprüft.

Netzwerkaufzeichnung eines RTP-Streams

Abbildung 12: Netzwerk-Verkehr eines Streaming-Servers, der ein RTP-Stream verschickt (Push)

In der Abbildung oben verschickt ein Streaming-Server (Barix Instreamer mit der IP 192.168.11.173) einen Stream an eine Multicast-Adresse (224.2.3.4) über RTP (UDP). Wenn sich ein Client für diese Adresse anmeldet, kann er den Stream beziehen. In der graphischen Analyse ist zu sehen, dass die Pakete sehr regelmäßig gesendet werden. Die Sendegeschwindigkeit stimmt mit der Frame-Länge von MP3 bei 44,1 kHz Samplerate überein, die 26 Millisekunden beträgt. (siehe Fenster 'Wireshark: RTP Stream Analysis' Es werden in diesem Fall 38 Pakete pro Sekunde versendet.) Im Hauptfenster ist die im Paket-Header mitgelieferte Sequenz-Nummmer und der Codec zu sehen.

Latenz

Mit UDP sind die Latenzen zwischen Audio-Input und -Output absehbar. Optimal sind 32ms bei einer PCM-48kHz-Übertragung im LAN. Bei einer mp3-Übertragungn sind es 180ms. (Das sind die Werte, die sich aus dem Encoding und der Frame-Größe, durch die Übertragung, v.a. aber am Decoder, durch das Pakete empfangen und analysieren, ergeben.) Um Latenzen kurz zu halten, kommt für Stefan Giessler vom Barix-Support nur UDP in Frage.⁸

Gerade für Sport-Events wie Fußball mutet es seltsam an, wenn in der Nachbarswohnung schon ein paar Sekunden früher gejubelt wird, weil der Video-Stream mit dem Tor bei dem einen Übertragungsweg schneller ankommt. Die FAZ zeigt in einer Info-Grafik: der Unterschied zwischen Satellit und DVB-T liegt bei 1-3 Sekunden (zwischen Satellit-und Kabel kommt es zu 5-10 Sekunden). Erklärt wird das damit, dass es bei DVB-T noch einen zusätzlichen „Datenpuffer“ gibt - der somit die Latenzzeit erhöht - um alle ausstrahlenden Sender synchron zu bekommen. (Beim Kabel wird mitunter das Signal eines Sender in neue Multiplexe zusammen geführt, was wiederum Rechenzeit benötigt.)⁹