Architektur und Datenflüsse

Drovio beruht auf WebRTC, um ein schnelles Erlebnis mit geringer Latenz zu bieten, mit den besten derzeit verfügbaren Audio- und Videokodierungen, AV1, VP9 und VP8, und behält dabei eine hochsichere, auf Datenschutz bedachte Peer-to-Peer-Architektur bei.

Überblick

Drovio besteht aus einer Serversoftware, Drovio Server, nur in der Enterprise Edition verfügbar, und einer Clientsoftware, der Drovio App. Die Lösung liefert zudem einen Web-Client, mit dem sich jede Sitzung mit Bildschirmfreigabe und jeder Anruf betreten lässt, ohne etwas herunterzuladen, zu installieren oder zu abonnieren.

Der interaktive Rundgang weiter unten folgt einer Sitzung von der Authentifizierung bis zu den Datenströmen und nennt die Protokolle und Ports, die bei jedem Schritt beteiligt sind.

Verbindungsablauf

1 · Authentifizierung2 · Signalisierung3 · STUN4 · Peer-to-Peer-Datenströme5 · Rückfall auf TURN

HTTPS · TLS 1.2 / 1.3 · 443

Die Authentifizierung bei Drovio läuft über HTTPS, TLS 1.2 oder 1.3. Anschließend werden WebSocket-Verbindungen zwischen Drovio Server und den Clients geöffnet, um die gesamte Signalisierung zu tragen.

In der Enterprise Edition werden die aktivierten Protokolle und Cipher Suites über http.tls_protocols und http.tls_cipher_suites eingestellt.

WebSocket (WSS) · 443

Die Signalisierung bezeichnet im Sinne von WebRTC den Austausch der Übertragungsfähigkeiten, also der Audio- und Videocodecs, und der Netzwerkfähigkeiten zwischen den Endpunkten, das heißt den Clients. Die SDP und die ICE-Kandidaten wandern zwischen dem Host und dem Gast über Drovio Server, per WebSocket.

Das SDP, Session Description Protocol, dient dazu, die unterstützten Datenströme aufzuzählen. Parallel dazu werden auf jedem Endpunkt die verfügbaren ICE-Kandidaten gesammelt, von denen jeder eine mögliche IP-Adresse, einen Port und eine Transportschicht bezeichnet. Sie werden ausgetauscht und bilden Paare von Kandidaten. Mehrere Paare werden zurückbehalten, doch nur eines wird ausgewählt, um die Peer-to-Peer-Kommunikation zu tragen, es sei denn, es kommt zu einem ICE-Reset, der eine Neuverhandlung der Verbindung und die Auswahl eines anderen Paares erzwingt. Drovio erledigt das transparent.

STUN · UDP 443

Während der Signalisierung können sich die Clients auf einen STUN-Server stützen, Session Traversal Utilities for NAT, um ein NAT zu durchqueren. Ihre einzige Daseinsberechtigung ist es, die Frage „Wie lautet meine öffentliche IP-Adresse?“ zu beantworten.

DTLS-SRTP / SCTP · UDP 1024-65535

Die Peer-to-Peer-Verbindungen werden anschließend direkt zwischen den Clients aufgebaut. Ein Live-Videostrom des Bildschirms oder der Anwendung des Hosts wird an die Gäste gesendet, gegebenenfalls begleitet von einem Audiostrom, Mikrofon oder Systemton. Auch die Gäste können ihr Mikrofon freigeben sowie Maus- und Tastatureingaben senden, die der Host jederzeit entziehen kann, siehe Zugang und Kontrolle von Sitzungen. Drovio Server ist während der Sitzung mit Bildschirmfreigabe nicht beteiligt, außer um einige Statistiken zu erheben, die der Verbesserung des Erlebnisses dienen, siehe Statistiken.

TURN · UDP/TCP 443 · UDP 49152-65535

Wenn Firewalls oder NAT-Regeln zu restriktiv sind, lassen sich zwischen den Clients keine direkten Verbindungen aufbauen. Relay-Server, TURN für Traversal Using Relays around NAT, leiten dann die Pakete von einem Client zum anderen weiter. Die Kommunikation bleibt Ende-zu-Ende-verschlüsselt: ein Relay leitet Pakete weiter, die es nicht entschlüsseln kann, da die Schlüssel allein zwischen den Endpunkten ausgehandelt werden.

In der Cloud Edition sind die STUN- und TURN-Server auf AWS gehostet und weltweit verteilt. Sie tragen rund 15 % der Sitzungen mit Bildschirmfreigabe, und zum Einsatz kommt jeweils der geografisch nächstgelegene Server. In der Enterprise Edition sind diese Server optional: wir helfen Ihnen, Ihre eigenen bereitzustellen, wenn die Bildschirmfreigabe über das Internet laufen muss, siehe Relay-Server (TURN).

Ein Relay ist kein offener Proxy. Eine Allocation zu erhalten erfordert zeitlich begrenzte Zugangsdaten, die aus einem gemeinsamen Geheimnis abgeleitet werden, die Allocations laufen nach wenigen Minuten ab, und das Relay lehnt Loopback- und Multicast-Ziele ab, sodass es sich nicht gegen interne Netze wenden lässt. TLS 1.0 und 1.1 sind dort abgeschaltet, seine Liste der Cipher Suites ist auf moderne ECDHE-Suiten beschränkt, und es gibt seine Softwareversion nicht preis.

Übersicht über Protokolle und Ports

Schritt	Protokoll(e)	Port(s)
Authentifizierung	HTTPS (TLS 1.2 / 1.3)	TCP 443
Signalisierung	HTTPS und WebSocket (WSS)	TCP 443
STUN	UDP	443
Bildschirmfreigabe (Peer-to-Peer)	DTLS-SRTP, DTLS-SCTP	UDP 1024-65535, ausgehend und im Rückverkehr
TURN (Relay)	UDP / TCP, um das Relay zu erreichen, dann UDP für die relayten Datenströme	443, dann 49152-65535

Zum Peer-to-Peer-Bereich. 1024-65535 ist keine Liste von Ports, die auf einem Server zu öffnen wären. Es sind die Medienports von WebRTC: bei jeder Sitzung wählt jeder Endpunkt einen eigenen ephemeren Port und kündigt ihn als ICE-Kandidaten an. Was eine Firewall erlauben muss, ist ausgehendes UDP und dessen Rückverkehr, kein fester Port. Wo das nicht möglich ist, fällt die Sitzung auf TURN zurück und alles läuft über Port 443.

Zu den Ports des Relays. 49152-65535 ist der Allocation-Bereich des Relay-Servers selbst, nicht der der Clients. In der Cloud Edition lauschen unsere Relays nur auf 443, in UDP wie in TCP, was die meisten Unternehmensfirewalls durchquert. In der Enterprise Edition wählen Sie die Ports: der Leitfaden Relay-Server (TURN) schlägt aus demselben Grund 80 und 443 vor.