Comunicazioni in tempo reale nello sviluppo mobile: cosa sono, quali protocolli e come funzionano

Comunicazioni in tempo reale: protocolli WebSocket, SSE e Long Polling

Le comunicazioni in tempo reale sono tecnologie che consentono lo scambio di dati tra client e server con latenza minima. I protocolli principali: WebSocket, SSE (Server-Sent Events), Long Polling e Short Polling. Ciascuno ha la sua nicchia: WebSocket per comunicazione bidirezionale, SSE per notifiche, Long Polling come fallback per browser vecchi. Il tempo reale nello sviluppo mobile è particolarmente importante: gli utenti si aspettano consegna immediata di messaggi e notifiche. Le comunicazioni nello sviluppo mobile sono costruite proprio su questi protocolli.

WebSocket vs SSE

WebSocket è un protocollo full-duplex (client ↔ server). Dopo l'handshake (HTTP Upgrade) la connessione rimane aperta. Gli header sono minimi (2 byte contro header HTTP). Utilizzato in chat (WhatsApp, Telegram), giochi, trading in tempo reale. SSE è un protocollo unidirezionale (server → client). Il client si abbona agli eventi e li riceve tramite una singola connessione HTTP. SSE è più semplice, più facile da scalare (HTTP semplice), ideale per feed Twitter, tassi di cambio, notifiche push.

Long Polling è una tecnica in cui il client effettua una richiesta HTTP e la mantiene aperta finché il server non invia dati o scade un timeout (30–60 sec). Dopo aver ricevuto i dati, il client apre immediatamente una nuova richiesta. Long Polling è un fallback per WebSocket. Short Polling — il client interroga il server ogni N secondi. Il più semplice ma inefficiente (la maggior parte delle richieste restituisce risposte vuote).

Server di segnalazione

Prima di stabilire una connessione P2P, i dispositivi necessitano di un Server di segnalazione — un server intermedio per scambiare offerte SDP e candidati ICE tra i peer. La segnalazione può essere implementata tramite WebSocket, SSE o qualsiasi altro protocollo. Dopo l'instaurazione della connessione, la segnalazione non partecipa più alla trasmissione del traffico multimediale.

WebRTC: comunicazioni in tempo reale con chiamate audio e video

WebRTC (Web Real-Time Communication) è una tecnologia aperta per audio/video/dati P2P. Funziona nei browser e nelle applicazioni native (iOS, Android). WebRTC include: getUserMedia (accesso a fotocamera/microfono), RTCPeerConnection (connessione P2P), RTCDataChannel (trasferimento dati). WebRTC abilita comunicazioni in tempo reale nelle applicazioni mobili — le comunicazioni nelle app mobili funzionano senza plugin aggiuntivi.

Flusso WebRTC

Il Peer A crea una RTCPeerConnection e un'offerta SDP. Passo 2: L'offerta viene inviata tramite il Server di segnalazione al Peer B. Passo 3: Il Peer B riceve l'offerta, crea una risposta SDP e la rinvia. Passo 4: Entrambi i peer raccolgono candidati ICE (indirizzi per la connessione) e li scambiano tramite la segnalazione. Passo 5: Il framework ICE seleziona il percorso migliore (P2P o tramite TURN). Dopo la connessione — il traffico multimediale fluisce direttamente.

SDP (Session Description Protocol) è un protocollo testuale che descrive i parametri di connessione: codec, indirizzi IP, porte. ICE Candidate è una proposta da STUN/TURN: "Sono reperibile a questo indirizzo". Più candidati ci sono, maggiore è la probabilità di P2P.

Socket.IO è il leader per le startup: controlli il server, nessun limite. Pusher e Ably sono per prodotti dove non vuoi gestire l'infrastruttura. PubNub è per IoT e audience globali. IT Sectr raccomanda Socket.IO per progetti con backend proprio, Pusher per prototipi rapidi, Ably per enterprise con requisiti di affidabilità.

Piattaforme: Socket.IO, Pusher, Ably, PubNub

Le piattaforme in tempo reale forniscono infrastruttura server pronta per WebSocket e SSE. Eliminano la necessità di scrivere il proprio server in tempo reale, bilanciare connessioni WebSocket e scalarle. La scelta della piattaforma dipende dal budget, dai requisiti di affidabilità e dalla volontà di gestire un server. Per il tempo reale nello sviluppo mobile, le piattaforme offrono SDK client e infrastruttura già pronti.

Socket.IO

Socket.IO è una libreria per Node.js e client (iOS, Android, web). Basata su WebSocket, ma utilizza HTTP polling come fallback. Supporta stanze, namespace, conferme ACK. Per lo sviluppo — socket.io-client-java (Android) e socket.io-client-swift (iOS). Le comunicazioni nelle app mobili su Socket.IO sono gestite in modo affidabile grazie alla riconnessione automatica.

Pusher e Ably

Pusher è una piattaforma SaaS in tempo reale. Integrazione semplice: crea un canale e iscriviti agli eventi. Pusher Channels per notifiche, Pusher Beams per notifiche push. Ably è di livello enterprise con replicazione globale in 7 data center. Garantisce consegna exactly-once. Supporta SSE, WebSocket, MQTT per IoT. Entrambe le piattaforme risolvono compiti di comunicazione nello sviluppo mobile senza scrivere codice server.

Infrastruttura in tempo reale: STUN, TURN, Signaling in WebRTC

STUN (Session Traversal Utilities for NAT) è un server che aiuta un dispositivo a scoprire il proprio IP e porta esterni dietro NAT. Il dispositivo invia una richiesta STUN, il server risponde: "Sei visibile come 203.0.113.5:45678". STUN viene utilizzato gratuitamente (Google STUN: stun.l.google.com:19302). Nel contesto dell'infrastruttura in tempo reale, STUN è il primo passo per stabilire un canale P2P.

STUN vs TURN

TURN (Traversal Using Relays around NAT) è un server relay che ritrasmette il traffico multimediale se la connessione P2P è impossibile (ad esempio, entrambi i dispositivi dietro NAT simmetrico). TURN consuma banda del server, quindi è costoso. In WebRTC, il framework ICE prova prima P2P, poi TURN come ultima risorsa. Il tempo reale nello sviluppo richiede TURN per le comunicazioni nelle app mobili quando ci si connette tramite reti aziendali.

ICE (Interactive Connectivity Establishment) è un framework che raccoglie tutti i percorsi di connessione possibili (IP locale, IP esterno tramite STUN, relay TURN) e seleziona il migliore. ICE Candidate è ogni percorso possibile. Più candidati ci sono, maggiore è la probabilità di P2P riuscito.

Peer-to-Peer

P2P è una connessione diretta tra due dispositivi senza server intermediario per il traffico multimediale. Il P2P riduce la latenza (< 100 ms) e i costi del server. Svantaggi: debole protezione contro NAT, necessità di STUN/TURN. WebRTC utilizza P2P per impostazione predefinita.

P2P e ICE

Peer-to-Peer (P2P) è un'architettura in cui i dati vengono trasferiti direttamente tra dispositivi. Nel contesto delle comunicazioni in tempo reale, il P2P viene utilizzato in WebRTC per ridurre al minimo la latenza. ICE (Interactive Connectivity Establishment) è il meccanismo che trova il percorso migliore per una connessione P2P. Per lo sviluppo, il P2P è il modo ottimale per organizzare comunicazioni nelle app mobili in tempo reale.

Come funziona ICE

ICE raccoglie ICE Candidate di tre tipi: 1) host (IP locale), 2) srflx (tramite STUN), 3) relay (tramite TURN). Tutti i candidati vengono ordinati e ICE prova a connettersi con ciascuno in ordine di priorità. La prima connessione riuscita viene utilizzata. Se il P2P non è possibile, viene utilizzato TURN (ma è costoso).