Echtzeit-Kommunikation in der mobilen Entwicklung: was es ist, welche Protokolle und wie es funktioniert

Echtzeit-Kommunikation: WebSocket-, SSE- und Long-Polling-Protokolle

Echtzeit-Kommunikation sind Technologien, die den Datenaustausch zwischen Client und Server mit minimaler Latenz ermöglichen. Die wichtigsten Protokolle: WebSocket, SSE (Server-Sent Events), Long Polling und Short Polling. Jedes hat seine Nische: WebSocket für bidirektionale Kommunikation, SSE für Benachrichtigungen, Long Polling als Fallback für ältere Browser. Echtzeit in der mobilen Entwicklung ist besonders wichtig: Benutzer erwarten sofortige Zustellung von Nachrichten und Benachrichtigungen. Kommunikation in der mobilen Entwicklung wird genau auf diesen Protokollen aufgebaut.

WebSocket vs SSE

WebSocket ist ein Vollduplex-Protokoll (Client ↔ Server). Nach dem Handshake (HTTP Upgrade) bleibt die Verbindung offen. Header sind minimal (2 Bytes vs. HTTP-Header). Wird in Chats (WhatsApp, Telegram), Spielen, Echtzeit-Handel verwendet. SSE ist ein unidirektionales Protokoll (Server → Client). Der Client abonniert Ereignisse und empfängt sie über eine einzige HTTP-Verbindung. SSE ist einfacher, leichter skalierbar (einfaches HTTP), ideal für Twitter-Feeds, Wechselkurse, Push-Benachrichtigungen.

Long Polling ist eine Technik, bei der der Client eine HTTP-Anfrage stellt und sie offen hält, bis der Server Daten sendet oder ein Timeout eintritt (30–60 Sek.). Nach dem Empfangen von Daten öffnet der Client sofort eine neue Anfrage. Long Polling ist ein Fallback für WebSocket. Short Polling — der Client fragt den Server alle N Sekunden ab. Am einfachsten, aber ineffizient (die meisten Anfragen geben leere Antworten zurück).

Signalisierungsserver

Vor dem Aufbau einer P2P-Verbindung benötigen die Geräte einen Signalisierungsserver — einen Vermittlungsserver zum Austausch von SDP-Angeboten und ICE-Kandidaten zwischen Peers. Die Signalisierung kann über WebSocket, SSE oder ein anderes Protokoll implementiert werden. Nach dem Verbindungsaufbau ist die Signalisierung nicht mehr an der Übertragung von Medienverkehr beteiligt.

WebRTC: Echtzeit-Kommunikation mit Audio- und Videoanrufen

WebRTC (Web Real-Time Communication) ist eine offene Technologie für P2P-Audio/Video/Daten. Funktioniert in Browsern und nativen Anwendungen (iOS, Android). WebRTC umfasst: getUserMedia (Kamera-/Mikrofonzugriff), RTCPeerConnection (P2P-Verbindung), RTCDataChannel (Datenübertragung). WebRTC ermöglicht Echtzeit-Kommunikation in mobilen Anwendungen — Kommunikation in mobilen Apps funktioniert ohne zusätzliche Plugins.

WebRTC-Ablauf

Peer A erstellt eine RTCPeerConnection und ein Offer SDP. Schritt 2: Das Offer wird über den Signalisierungsserver an Peer B gesendet. Schritt 3: Peer B empfängt das Offer, erstellt ein Answer SDP und sendet es zurück. Schritt 4: Beide Peers sammeln ICE-Kandidaten (Adressen für die Verbindung) und tauschen sie über die Signalisierung aus. Schritt 5: Das ICE-Framework wählt den besten Pfad (P2P oder über TURN). Nach der Verbindung fließt der Medienverkehr direkt.

SDP (Session Description Protocol) ist ein Textprotokoll, das die Verbindungsparameter beschreibt: Codecs, IP-Adressen, Ports. ICE Candidate ist ein Vorschlag von STUN/TURN: „Ich bin unter dieser Adresse zu finden“. Je mehr Kandidaten, desto höher die P2P-Wahrscheinlichkeit.

Socket.IO ist der Marktführer für Startups: Sie kontrollieren den Server, keine Limits. Pusher und Ably sind für Produkte, bei denen Sie keine Infrastruktur verwalten möchten. PubNub ist für IoT und globale Zielgruppen. IT Sectr empfiehlt Socket.IO für Projekte mit eigenem Backend, Pusher für schnelle Prototypen, Ably für Unternehmen mit Zuverlässigkeitsanforderungen.

Plattformen: Socket.IO, Pusher, Ably, PubNub

Echtzeit-Plattformen bieten fertige Server-Infrastruktur für WebSocket und SSE. Sie machen die Notwendigkeit überflüssig, einen eigenen Echtzeit-Server zu schreiben, WebSocket-Verbindungen zu balancieren und zu skalieren. Die Wahl der Plattform hängt vom Budget, den Zuverlässigkeitsanforderungen und der Bereitschaft ab, einen Server zu verwalten. Für Echtzeit in der mobilen Entwicklung bieten Plattformen fertige Client-SDKs und Infrastruktur.

Socket.IO

Socket.IO ist eine Bibliothek für Node.js und Clients (iOS, Android, Web). Basiert auf WebSocket, verwendet aber HTTP-Polling als Fallback. Unterstützt Räume, Namespaces, ACK-Bestätigungen. Für die Entwicklung — socket.io-client-java (Android) und socket.io-client-swift (iOS). Kommunikation in mobilen Apps mit Socket.IO wird dank automatischer Wiederverbindung zuverlässig behandelt.

Pusher und Ably

Pusher ist eine Echtzeit-SaaS-Plattform. Einfache Integration: Erstellen Sie einen Kanal und abonnieren Sie Ereignisse. Pusher Channels für Benachrichtigungen, Pusher Beams für Push-Benachrichtigungen. Ably ist auf Enterprise-Niveau mit globaler Replikation in 7 Rechenzentren. Garantiert Exactly-once-Zustellung. Unterstützt SSE, WebSocket, MQTT für IoT. Beide Plattformen lösen Kommunikationsaufgaben in der mobilen Entwicklung ohne Servercode schreiben zu müssen.

Echtzeit-Infrastruktur: STUN, TURN, Signaling in WebRTC

STUN (Session Traversal Utilities for NAT) ist ein Server, der einem Gerät hilft, seine externe IP und seinen Port hinter NAT zu ermitteln. Das Gerät sendet eine STUN-Anfrage, der Server antwortet: „Sie sind als 203.0.113.5:45678 sichtbar“. STUN wird kostenlos genutzt (Google STUN: stun.l.google.com:19302). Im Kontext der Echtzeit-Infrastruktur ist STUN der erste Schritt zur Einrichtung eines P2P-Kanals.

STUN vs TURN

TURN (Traversal Using Relays around NAT) ist ein Relay-Server, der Medienverkehr weiterleitet, wenn eine P2P-Verbindung nicht möglich ist (z. B. beide Geräte hinter symmetrischem NAT). TURN verbraucht Serverbandbreite und ist daher teuer. In WebRTC versucht das ICE-Framework zuerst P2P, dann TURN als letzten Ausweg. Echtzeit in der Entwicklung erfordert TURN für Kommunikation in mobilen Apps bei der Verbindung über Unternehmensnetzwerke.

ICE (Interactive Connectivity Establishment) ist ein Framework, das alle möglichen Verbindungspfade sammelt (lokale IP, externe IP über STUN, TURN-Relays) und den besten auswählt. ICE Candidate ist jeder mögliche Pfad. Je mehr Kandidaten, desto höher die Wahrscheinlichkeit einer erfolgreichen P2P-Verbindung.

Peer-to-Peer

P2P ist eine direkte Verbindung zwischen zwei Geräten ohne Vermittlungsserver für Medienverkehr. P2P reduziert Latenz (< 100 ms) und Serverkosten. Nachteile: schwacher NAT-Schutz, Notwendigkeit von STUN/TURN. WebRTC verwendet standardmäßig P2P.

P2P und ICE

Peer-to-Peer (P2P) ist eine Architektur, bei der Daten direkt zwischen Geräten übertragen werden. Im Kontext der Echtzeit-Kommunikation wird P2P in WebRTC verwendet, um Latenz zu minimieren. ICE (Interactive Connectivity Establishment) ist der Mechanismus, der den besten Pfad für eine P2P-Verbindung findet. Für die Entwicklung ist P2P der optimale Weg, um Kommunikation in mobilen Apps in Echtzeit zu organisieren.

Wie ICE funktioniert

ICE sammelt ICE Candidate von drei Typen: 1) host (lokale IP), 2) srflx (über STUN), 3) relay (über TURN). Alle Kandidaten werden sortiert, und ICE versucht, sich in der Reihenfolge der Priorität mit jedem zu verbinden. Die erste erfolgreiche Verbindung wird verwendet. Wenn P2P nicht möglich ist, wird TURN verwendet (aber es ist teuer).