Che cos'è un WebSocket?

Un WebSocket è una connessione persistente e bidirezionale tra client e server: ogni lato invia messaggi nell’istante in cui accadono. HTTP ha costruito il web chiedendo; i WebSocket lo hanno reso vivo ascoltando – un solo upgrade standardizzato (RFC 6455) trasforma una richiesta in un canale aperto, e tutto ciò che sul web è in tempo reale – chat, presenza, ticker, cursori collaborativi – ci viaggia sopra.

Punti chiave

Come funziona l’upgrade dell’handshake WebSocket (HTTP 101)

GET /chat HTTP/1.1                      ← inizia come HTTP ordinario
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

HTTP/1.1 101 Switching Protocols        ← e qui smette di essere HTTP
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

# Da qui in avanti: frame minuscoli (2–14 byte di overhead), in entrambi i sensi,
# contro i ~500+ byte di header di ogni singolo poll HTTP.

La maggior parte delle applicazioni non dovrebbe scrivere a mano ciò che viene dopo – l’idioma di produzione è un livello gestito di tempo reale, in cui socket, heartbeat e riconnessione sono codice di qualcun altro:

// JavaScript / Node.js — Back4app JS SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
const query = new Parse.Query('Message');
query.equalTo('room', 'general');

const subscription = await query.subscribe();  // wss:// under the hood
subscription.on('create', (msg) => appendToChat(msg));
subscription.on('open', () => setStatus('live'));
// Later: subscription.unsubscribe();

// Flutter / Dart — Back4app Flutter SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
final liveQuery = LiveQuery();
final query = QueryBuilder<ParseObject>(ParseObject('Message'))
  ..whereEqualTo('room', 'general');

final sub = await liveQuery.client.subscribe(query); // wss:// under the hood
sub.on(LiveQueryEvent.create, (msg) => appendToChat(msg));

// iOS / Swift — Back4app Swift SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
let query = Message.query("room" == "general")

let subscription = query.subscribeCallback   // wss:// under the hood
subscription?.handleEvent { _, event in
  if case .created(let msg) = event { appendToChat(msg) }
}

// Android / Kotlin — Back4app Android SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
val client = ParseLiveQueryClient.Factory.getClient()
val query = ParseQuery.getQuery<ParseObject>("Message")
query.whereEqualTo("room", "general")

val handling = client.subscribe(query)       // wss:// under the hood
handling.handleEvent(SubscriptionHandling.Event.CREATE) { _, msg ->
  appendToChat(msg)
}

WebSocket vs. tutto il resto che muove dati

Far girare i socket in produzione

Quattro concetti portano il carico operativo. Affinità di sessione: le connessioni hanno stato, quindi i load balancer devono tenere ogni client appuntato al proprio nodo. Fan-out: trasmettere un messaggio a diecimila sottoscrittori distribuiti su molti nodi richiede un backplane pub/sub fra i server – il messaggio viaggia da server a server prima di viaggiare da server a client. Backpressure: non si può lasciare che un telefono lento su una rete scadente accumuli messaggi senza limite nella memoria del server; occorre scartare, accorpare o disconnettere. Vitalità: i frame ping/pong più gli heartbeat applicativi rilevano le connessioni mezze morte, e i client si riconnettono con backoff esponenziale e jitter, poi ri-sottoscrivono il proprio stato – il passaggio che le implementazioni ingenue dimenticano. Niente di tutto questo è esotico; tutto questo spiega perché “apriamo un socket e via” diventa una decisione di piattaforma.

Dai messaggi alla sincronizzazione: il livello sopra

I WebSocket grezzi muovono byte; le applicazioni vogliono stato. Il gradino superiore è la sincronizzazione in tempo reale: invece di inventare a mano tipi di messaggio e contabilità lato client, si sottoscrivono dei dati – una query, un documento, un canale – e il livello consegna eventi di cambiamento precisi, gestisce riconnessione e recupero e applica i permessi lato server per singolo sottoscrittore. È il modello delle live queries: i WebSocket come trasporto, un motore di query come cervello. Se il codice WebSocket accumula switch sui tipi di messaggio, questo livello è già in corso di ricostruzione a mano.

Casi d’uso tipici

• Chat e messaggistica – il caso canonico: parlano entrambi i lati, subito.
• Presenza – chi è online, chi sta scrivendo: messaggi minuscoli, ad alta frequenza, nei due sensi.
• Editing collaborativo – documenti e lavagne condivise, dove posizioni del cursore e modifiche scorrono in continuo.
• Dashboard in diretta e ticker – push dal server di numeri che si muovono; anche SSE va bene quando il flusso è a senso unico.
• Multigiocatore e posizione – stato di gioco e marcatori di mappa in movimento, dove la latenza è il prodotto.

Serve un socket? Matrice decisionale

E la via di mezzo che la matrice nasconde: i casi solo da server a client (feed, notifiche) stanno bene su SSE, con meno macchinario – il confronto completo fra i trasporti ha una voce propria nel registro di questo glossario.

Limiti e trade-off

• Lo stato è il prezzo del push. Ogni connessione aperta è memoria del server e un vincolo di bilanciamento del carico; l’assenza di stato di HTTP reggeva più peso di quanto sembrasse.
• Le reti detestano le connessioni di lunga durata. Proxy, radio mobili e portatili che si richiudono tagliano socket di continuo – la logica di riconnessione non è un caso limite, è il ciclo principale.
• La sicurezza si sposta sulla connessione. Autenticare alla connessione, validare ogni messaggio, applicare l’autorizzazione per singola sottoscrizione – e sempre wss.
• Qui la cache non esiste. Tutto ciò che viene spinto è calcolato e consegnato per singolo client; il CDN non può fare nulla.
• La sincronizzazione scritta a mano è una trappola. La distanza fra “ho aperto un socket” e “sincronizzazione di stato corretta, con riconnessione e permessi” è dove vive l’ingegneria vera – ed è esattamente il livello che conviene affittare.

I WebSocket su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Il suo livello di tempo reale è Live Query: trasporto WebSocket, heartbeat, riconnessione e fan-out multi-nodo girano come infrastruttura gestita (con sotto il protocollo aperto LiveQuery), mentre il codice applicativo sottoscrive delle query e riceve eventi di cambiamento tipizzati – con le ACL applicate per singolo sottoscrittore, così che il tempo reale non scavalchi mai il modello dei permessi. Le schede di codice qui sopra sono tutta la storia lato client.