In meinem letzten Geleit des Jahres 2020 bin ich darauf eingegangen, dass virtuelle Konferenzen gekommen sind, um zu bleiben. Sie wurden nicht erst mit Corona eingeführt und werden auch nicht mit SARS-Cov-2 verschwinden. Allerdings machte die Pandemie Millionen Menschen, die davor kaum oder gar keine virtuellen Konferenzen genutzt haben, zu regelmäßigen Teilnehmern von Online-Meetings. Ein Teil dieser Teilnehmer blickt voller Erwartung dem Ende von Covid-19 entgegen, um sich sobald wie möglich physisch statt virtuell mit anderen Menschen zu treffen. Jedoch bin ich mir sicher, dass die Häufigkeit physischer Meetings nach der Pandemie wesentlich geringer sein wird als davor. Ich weiß zwar nicht, worauf die Schätzung von Bill Gates basiert, wonach von den Dienstreisen vor Corona 50 % in die Post-Corona-Zeit entfallen werden, gehe aber ebenfalls von einer signifikanten Reduzierung physischer zugunsten virtueller Meetings aus.

An dieser Stelle habe ich vor einem Monat die Erlebnisqualität aus Sicht der Teilnehmer als Vorteil physischer Besprechungen erwähnt. Natürlich kann – nach dem heutigen Stand der Technik – eine virtuelle Besprechung diesbezüglich mit einer physischen nicht mithalten, weil sie bisher fast immer nur zwei menschliche Sinne (Sehen und Hören) bedienen kann. Sie kann diese beiden Sinne gut oder eher schlecht bedienen. Wie gut, bestimmt die Erlebnisqualität aus Teilnehmersicht wesentlich mit. Damit eine virtuelle Konferenz nicht zu einem traumatischen Erlebnis wird, muss die Qualität von Audio und Video stimmen. Sie ist von vielen technischen Faktoren abhängig, unter anderem von der Leistungsfähigkeit der Endgeräte und Server (letztere immer mehr in Clouds), der Qualität der Audioperipherie wie zum Beispiel Headsets, der Performance der Netzverbindung etc. Von diesen vielen technischen Aspekten möchte ich hier auf einen näher eingehen, nämlich auf die Nutzung des User Datagram Protocol (UDP) als Basis für die Echtzeitübertragung von Audio und Video.

Voice und Video sind anders als Daten

Die meisten IT-Anwendungen nutzen das Transmission Control Protocol (TCP). TCP enthält Mechanismen für die Kontrolle der Reihenfolge und Vollständigkeit aller übertragenen Bytes (Sequencing), Quittierung des Empfangs von Daten (Acknowledgement) und Wiederholung des Sendevorgangs im Falle von Paketverlusten (Retransmission). Diese Funktionen sind wichtig, denn ein einzelnes falsches oder fehlendes Bit kann Daten der meisten Applikationen unbrauchbar machen. Audio- und Videokonferenzen unterscheiden sich genau in diesem Punkt von den meisten Datenanwendungen. In der menschlichen Sprache, Gestik und Mimik ist sehr viel redundante Information enthalten. Ein Teil dieser Information kann auf dem Weg von Mensch zu Mensch verloren gehen, ohne dass der Verlust überhaupt auffällt oder den Informationsgehalt der Kommunikation reduziert. Natürlich dürfen die Verluste nicht dermaßen hoch sein, dass die Erlebnisqualität bei der Kommunikation oder gar die Verständlichkeit besonders leidet. Aber unterhalb einer bestimmten Schwelle von Verlusten bleibt die Verständlichkeit erhalten. Unter einer noch niedrigeren Schwelle bleiben Qualitätseinbußen sogar unbemerkt.

Die Erfinder paketierter Voice- und Videoübertragung waren sich von Anfang an dieses wesentlichen Unterschieds zwischen Sprache und Bild einerseits und Datenströmen andererseits bewusst. Deshalb entschieden sie sich für UDP und nicht TCP als Basis für die Echtzeitübertragung von Audio und Video. Um diese Entscheidung nachzuvollziehen, müssen wir etwas näher darauf eingehen, wie Datenanwendungen auf Basis von TCP funktionieren.

TCP überträgt jedes Byte zuverlässig

In der Regel sind Prozesse für TCP/IP Bestandteil des Betriebssystems. Verschiedene Applikationen auf demselben System nutzen meistens den sogenannten TCP/IP-Stack, der zum System gehört und nicht zur Anwendung. Neben TCP unterstützt ein solcher „Stack“ (Anordnung von Protokollen für die Bedienung verschiedener Protokollschichten) auch UDP. Die Protokolle IP, TCP und UDP sind standardisiert. Die Systeme müssen sich an diese Standards halten, damit Kommunikation von System zu System möglich wird.

Dies bedeutet, dass die Anwendungen den TCP/IP-Stack auf einem System so nutzen müssen, wie er auf dem System in Übereinstimmung mit den Standards ausgeführt wird. Das Prozessmodul TCP muss von einer Applikation entweder in Gänze genutzt werden oder gar nicht. Wenn TCP genutzt wird, dann mit den Hauptfunktionen Sequencing, Acknowledgement und Retransmission. Die Anwendung übergibt Daten dem TCP-Modul, das sich dann der Aufgabe annimmt, diese Daten zuverlässig zum Empfänger zu übertragen.

Wenn es bei dieser Übertragung zu Paketverlusten, Vertauschen der Reihenfolge der Pakete oder Staubildung in den Zwischenspeichern (Buffers) der Komponenten auf dem manchmal sehr langen Weg vom Sender zum Empfänger kommt, greifen die oben genannten Hauptfunktionen von TCP, ob man will oder nicht. TCP versucht, alle Bytes ohne Ausnahme und in richtiger Reihenfolge der Anwendung auf Empfängerseite zu übergeben. Quittungen des Empfängers werden überprüft. Vermisst das TCP-Modul des Empfängers einige Bytes, meldet er sich beim TCP-Modul des Senders und fordert eine wiederholte Übertragung. Geht diese Meldung auch verloren, veranlasst der Sender von sich aus nach einer bestimmten Zeit die wiederholte Übertragung der vom Empfänger nicht quittierten Daten. Das ist manchmal viel Arbeit und belegt Ressourcen auf dem System. Hin und wieder hindern wenige vermisste Bytes das TCP-Modul daran, die bereits empfangenen Daten der Anwendung zu übergeben. Meistens gelingt dem TCP-Modul diese Aufgabe, aber manchmal erst nach vielen Wiederholungen und intensiver Nutzung der Funktion für Ende-zu-Ende-Quittierung.

Warum TCP für Voice und Video ungeeignet ist

Die Zuverlässigkeit von TCP geht oft zulasten der Echtzeitfähigkeit. Ein Vergleich: Wenn Sie bei einer Postsendung Einschreiben mit eigenhändiger Übergabe (und nicht nur mit einem vom Postboten bestätigten Einwurf) veranlassen, kann es sein, dass sich die Auslieferung der Sendung verzögert, weil der Postbote den Empfänger an der Zieladresse nicht angetroffen hat. Der Postbote darf nicht von sich aus entscheiden, Einwurf sei besser als Ablieferung bei der Postfiliale. Er muss Letzteres tun, manchmal zum Verdruss des Empfängers, der dann den Weg zur Filiale auf sich nehmen muss und die Sendung später in die Hand bekommt, als es mit einem einfachen Einwurf möglich wäre.

So ist es auch mit TCP. TCP ist ein pflichtbewusster, penibler Postbote. Dieser Postbote besteht darauf, die Sendung eigenhändig zu übergeben. Noch mehr: Er kontrolliert, ob die Sendung inklusive Verpackung vollständig ist. Fehlt ein Stück Verpackung oder hat die Sendung unterwegs an Gewicht verloren, gibt TCP keine Ruhe, bis das geheilt ist. Ein solcher Postbote kann uns auf die Nerven gehen.

So auch TCP bei den Audio- und Video-Codecs. Codec steht für Coder-Decoder. Der Coder-Teil ist dafür zuständig, Audio- oder Videoinformation zu digitalisieren und als Bitstrom auf die Reise zu schicken. Der Decoder gewinnt aus dem empfangenen Bitstrom die Audio- oder Videoinformation wieder. Kodierungsverfahren für Audio und Video tolerieren bis zu einem bestimmten Maß Verluste und können sie kompensieren bzw. vertuschen. Für einen Codec ist die Art, wie TCP mit dem Sendeauftrag umgeht, zu viel des Guten. Der Codec hat keine Möglichkeit, die Daten anzufordern, die aus TCP-Sicht unvollständig sind. Ebenso wenig fehlt eine Codec-Anweisung an das TCP-Modul, nach Ablauf einer bestimmten Zeit den Sendeauftrag als obsolet zu betrachten. Das macht der Codec selbst: Bits, die zu lange auf sich warten lassen (während TCP sie unbedingt rekonstruieren will), werden vom Codec als Verlust behandelt.

Die Lösung heißt UDP

Weil Audio- und Video-Codecs mit Verlusten umgehen können, brauchen sie keinen zuverlässigen Dienst wie TCP. Ein „unzuverlässiger“ Dienst wie UDP reicht aus. Mehr noch: Er ist besser als TCP. Denn UDP hält sich nicht damit auf, Verluste auszugleichen bzw. die Reihenfolge der Pakete wiederherzustellen. (Das UDP-Modul des Empfängers hat gar keine Möglichkeit, die richtige Reihenfolge der Pakete zu erfahren). Damit ist UDP schneller als TCP, was bei einer Echtzeitanwendung, die Verluste toleriert, wichtig ist. Die zuverlässige Übertragung aller Bytes ist dagegen nicht notwendig.

Das ist der Grund, warum Hersteller und Cloud-Betreiber im Bereich Unified Communications & Collaboration (UCC) für die Echtzeitübertragung von Audio und Video die Nutzung von UDP präferieren. Selbst wenn manche Produkte neben der UDP- auch die TCP-Variante unterstützen, sieht der empfohlene bzw. der Standardmodus die UDP-Nutzung vor.

An dieser Stelle vielleicht noch der Hinweis, dass die Präferenz für UDP nicht, wie manchmal geglaubt wird, auf den kleineren Paketoverhead im Vergleich zu TCP zurückzuführen ist. Der UDP-Header ist 8 Bytes lang, der TCP-Header 20 Bytes. Der zusätzliche Overhead ist aber kein Problem. 12 Bytes mehr pro Paket entsprechen zum Beispiel bei PCM-Audio-Kodierung 4,8 kbit/s mehr, das sind ca. 5%. Bei der höheren Videolast fällt der geringe Overhead erst recht nicht ins Gewicht.

UDP: gut für Signalqualität,  schlecht für die IT-Sicherheit?

Die einschlägigen Empfehlungen zugunsten von UDP anstelle von TCP für Echtzeitübertragung von Audio und Video bereiten einigen Betreibern von Unternehmensnetzen Kopfzerbrechen. Insbesondere wenn die Übertragung zwischen verschiedenen Vertrauensbereichen erfolgen soll, setzt man lieber auf TCP. Unternehmensübergreifende Kommunikation ist immer Kommunikation zwischen verschiedenen Vertrauensbereichen. Also geht sie über Sicherheitskomponenten wie Firewalls. Wird über das Internet kommuniziert (entweder direkt oder über eine Cloud), müssen die obligatorischen Sicherheitskomponenten zwischen dem Unternehmensnetz und dem Internet alle ausgetauschten Pakete zulassen und übertragen.

TCP ist anders als UDP verbindungsorientiert. Ohne den expliziten Aufbau einer Verbindung zwischen zwei Parteien fängt TCP erst gar nicht mit der Übertragung an. Das macht TCP für Firewalls besser kontrollierbar. Diese können zulassen, dass bestimmte TCP-Verbindungen zwischen zwei Vertrauensbereichen aufgebaut werden. Pakete werden bei dem von Firewalls in der Regel angewandten Modus Stateful Inspection nur dann übertragen, wenn sie einer zugelassenen Verbindung zugeordnet werden können. UDP hat dagegen keine Phase des Verbindungsaufbaus. Sicherheitskomponenten müssen entweder an dem für den Session-Aufbau genutzten Signalisierungsprotokoll aktiv teilnehmen oder ganze Bereiche von UDP-Ports durchlassen.

Letzteres wird immer häufiger notwendig, weil die meisten UCC-Cloud-Anbieter ihre Signalisierungsverfahren für Drittfirmen wie Firewall-Hersteller nicht öffnen und eher proprietäre Mechanismen für den Session-Aufbau nutzen.

Natürlich würde die IT-Sicherheit davon profitieren, wenn alle UCC-Lösungen standardisierte Verfahren für den Session-Aufbau nutzen würden, die von Sicherheitskomponenten wirksam zu kontrollieren wären. Aber dieser ideale Zustand liegt leider nicht vor. Stattdessen geben die Hersteller und Cloud-Betreiber UDP-Portbereiche an, die auf Firewalls freizuschalten sind. Man bohrt also ein Loch durch die Sicherheitsmauer. Firewalls können den UDP-Verkehr nicht wirklich kontrollieren und müssen dafür auf Durchzug schalten. Unter Umständen können neben UDP-Portbereichen auch IP-Adressbereiche für UDP-Übertragung eingeschränkt werden (selbst das ist schwierig, wenn ein Cloud-Betreiber viele nicht zusammenhängende IP-Adressbereiche nutzt, die sich zudem noch häufig ändern).

Im Vergleich zu TCP ist das aber kein großer Verlust an Sicherheit. Denn auch bei TCP machen die Firewalls nichts anderes als Ports und IP-Adressen freizugeben. Der einzige Vorteil von TCP im Vergleich zu UDP wäre, dass eine Firewall TCP-Pakete, die nicht einer vorher aufgebauten Verbindung zuzuordnen sind, verwirft. Der Verbindungsaufbau selbst ist bei Nutzung der freigeschalteten Adressen und Ports möglich. Die Information über diese Adressen und Ports ist allgemein verfügbar. Deshalb können Firewalls, die nur auf TCP-Ebene agieren, nicht erkennen, ob ein TCP-Paket von einem Trittbrettfahrer stammt, der Kenntnisse über die genutzten Port- und Adressbereiche hat.

Konferenzanwendungen wenden daher kryptografische Methoden an, um sich und das System, auf dem sie laufen, vor Angriffen zu schützen. Kryptografie kann für Authentisierung, Integritätsschutz und Verschlüsselung aller Pakete genauso genutzt werden wie für die Erkennung von Replay-Angriffen (Senden von Kopien legitimer Paketen mit dem Ziel der Überlastung oder Manipulation des Empfängers).

Fazit

Zur Verbesserung der Akzeptanz von virtuellen Konferenzen sind technische Maßnahmen notwendig, zu denen die Nutzung von UDP statt TCP gehört. UDP wird dem Echtzeitcharakter von Audio- und Videokonferenzen besser gerecht als TCP. Für diese Konferenzen ist es unerheblich, dass UDP keinen Mechanismus für die zuverlässige Übertragung jedes Bytes bietet, denn Kodierungsverfahren für Audio und Video gleichen Verluste aus.