Komunikace v reálném čase v mobilním vývoji: co to je, jaké protokoly a jak funguje

Komunikace v reálném čase: protokoly WebSocket, SSE a Long Polling

Komunikace v reálném čase jsou technologie umožňující výměnu dat mezi klientem a serverem s minimální latencí. Hlavní protokoly: WebSocket, SSE (Server-Sent Events), Long Polling a Short Polling. Každý má své místo: WebSocket pro obousměrnou komunikaci, SSE pro oznámení, Long Polling jako fallback pro starší prohlížeče. Reálný čas v mobilním vývoji je obzvláště důležitý: uživatelé očekávají okamžité doručení zpráv a oznámení. Komunikace v mobilním vývoji je postavena právě na těchto protokolech.

WebSocket vs SSE

WebSocket je plně duplexní protokol (klient ↔ server). Po handshake (HTTP Upgrade) zůstává spojení otevřené. Hlavičky jsou minimální (2 bajty oproti HTTP hlavičkám). Používá se v chatech (WhatsApp, Telegram), hrách, obchodování v reálném čase. SSE je jednosměrný protokol (server → klient). Klient se přihlásí k odběru událostí a přijímá je přes jediné HTTP spojení. SSE je jednodušší, snadněji škálovatelný (čisté HTTP), ideální pro Twitter kanály, směnné kurzy, push oznámení.

Long Polling je technika, při které klient odešle HTTP požadavek a drží jej otevřený, dokud server nepošle data nebo nenastane timeout (30–60 sec). Po přijetí dat klient okamžitě otevře nový požadavek. Long Polling je fallback pro WebSocket. Short Polling — klient dotazuje server každých N sekund. Nejjednodušší, ale neefektivní (většina požadavků vrací prázdné odpovědi).

Signalizační server

Před navázáním P2P spojení potřebují zařízení Signalizační server — zprostředkující server pro výměnu SDP nabídek a ICE kandidátů mezi peer. Signalizace může být implementována přes WebSocket, SSE nebo jakýkoli jiný protokol. Po navázání spojení se signalizace již neúčastní přenosu mediálního provozu.

WebRTC: komunikace v reálném čase s audio a video hovory

WebRTC (Web Real-Time Communication) je otevřená technologie pro P2P audio/video/data. Funguje v prohlížečích a nativních aplikacích (iOS, Android). WebRTC zahrnuje: getUserMedia (přístup k kameře/mikrofonu), RTCPeerConnection (P2P spojení), RTCDataChannel (přenos dat). WebRTC umožňuje komunikaci v reálném čase v mobilních aplikacích — komunikace v mobilních aplikacích funguje bez dalších pluginů.

Tok WebRTC

Peer A vytvoří RTCPeerConnection a nabídku SDP. Krok 2: Nabídka je odeslána přes Signalizační server peeru B. Krok 3: Peer B obdrží nabídku, vytvoří odpověď SDP a odešle ji zpět. Krok 4: Oba peer shromáždí ICE kandidáty (adresy pro spojení) a vymění si je přes Signalizaci. Krok 5: Rámec ICE vybere nejlepší cestu (P2P nebo přes TURN). Po spojení — mediální provoz teče přímo.

SDP (Session Description Protocol) je textový protokol popisující parametry spojení: kodeky, IP adresy, porty. ICE Candidate je návrh od STUN/TURN: "Lze mě najít na této adrese". Čím více kandidátů, tím větší šance na P2P.

Socket.IO je lídr pro startupy: ovládáte server, bez omezení. Pusher a Ably jsou pro produkty, kde nechcete spravovat infrastrukturu. PubNub je pro IoT a globální publikum. IT Sectr doporučuje Socket.IO pro projekty s vlastním backendem, Pusher pro rychlé prototypy, Ably pro podniky s požadavky na spolehlivost.

Platformy: Socket.IO, Pusher, Ably, PubNub

Platformy v reálném čase poskytují hotovou serverovou infrastrukturu pro WebSocket a SSE. Eliminují potřebu psát vlastní server v reálném čase, vyvažovat WebSocket spojení a škálovat je. Výběr platformy závisí na rozpočtu, požadavcích na spolehlivost a ochotě spravovat server. Pro reálný čas v mobilním vývoji nabízejí platformy hotové klientské SDK a infrastrukturu.

Socket.IO

Socket.IO je knihovna pro Node.js a klienty (iOS, Android, web). Založena na WebSocket, ale používá HTTP polling jako fallback. Podporuje místnosti, jmenné prostory, ACK potvrzení. Pro vývoj — socket.io-client-java (Android) a socket.io-client-swift (iOS). Komunikace v mobilních aplikacích na Socket.IO je spolehlivě zpracována díky automatickému opětovnému připojení.

Pusher a Ably

Pusher je SaaS platforma v reálném čase. Jednoduchá integrace: vytvořte kanál a přihlaste se k odběru událostí. Pusher Channels pro oznámení, Pusher Beams pro push oznámení. Ably je podnikové úrovně s globální replikací v 7 datových centrech. Zaručuje doručení exactly-once. Podporuje SSE, WebSocket, MQTT pro IoT. Obě platformy řeší úkoly komunikace v mobilním vývoji bez psaní serverového kódu.

Infrastruktura v reálném čase: STUN, TURN, Signaling v WebRTC

STUN (Session Traversal Utilities for NAT) je server, který pomáhá zařízení objevit jeho externí IP a port za NAT. Zařízení odešle STUN požadavek, server odpoví: "Jste viditelný jako 203.0.113.5:45678". STUN se používá zdarma (Google STUN: stun.l.google.com:19302). V kontextu infrastruktury v reálném čase je STUN prvním krokem k vytvoření P2P kanálu.

STUN vs TURN

TURN (Traversal Using Relays around NAT) je relay server, který přenáší mediální provoz, pokud P2P spojení není možné (např. obě zařízení za symetrickým NAT). TURN spotřebovává šířku pásma serveru, takže je drahý. V WebRTC se rámec ICE nejprve pokusí o P2P, poté TURN jako poslední možnost. Reálný čas ve vývoji vyžaduje TURN pro komunikaci v mobilních aplikacích při připojení přes podnikové sítě.

ICE (Interactive Connectivity Establishment) je rámec, který shromažďuje všechny možné cesty spojení (lokální IP, externí IP přes STUN, TURN relay) a vybírá tu nejlepší. ICE Candidate je každá možná cesta. Čím více kandidátů, tím vyšší pravděpodobnost úspěšného P2P.

Peer-to-Peer

P2P je přímé spojení mezi dvěma zařízeními bez zprostředkujícího serveru pro mediální provoz. P2P snižuje latenci (< 100 ms) a náklady na server. Nevýhody: slabá ochrana proti NAT, potřeba STUN/TURN. WebRTC standardně používá P2P.

P2P a ICE

Peer-to-Peer (P2P) je architektura, kde jsou data přenášena přímo mezi zařízeními. V kontextu komunikace v reálném čase se P2P používá v WebRTC k minimalizaci latence. ICE (Interactive Connectivity Establishment) je mechanismus, který najde nejlepší cestu pro P2P spojení. Pro vývoj je P2P optimální způsob organizace komunikace v mobilních aplikacích v reálném čase.

Jak ICE funguje

ICE shromažďuje ICE Candidate tří typů: 1) host (lokální IP), 2) srflx (přes STUN), 3) relay (přes TURN). Všichni kandidáti jsou seřazeni a ICE se pokusí připojit ke každému v pořadí podle priority. První úspěšné spojení se použije. Pokud P2P není možné, použije se TURN (ale je drahý).