Programmazione · Web · Reti

Cos’è un WebSocket?

La maggior parte del web funziona per richiesta e risposta: il browser chiede, il server risponde, la connessione si chiude. Va benissimo per caricare una pagina, ma crolla quando vuoi aggiornamenti dal vivo — un messaggio di chat, una quotazione di borsa, una mossa multiplayer — che il server deve inviare nell’istante in cui accadono. Un WebSocket è la risposta standard. Questa guida spiega cos’è un WebSocket, in cosa differisce dal normale HTTP e quando ti serve davvero.

L’idea centrale: una connessione, entrambe le direzioni

Un WebSocket è una connessione persistente e bidirezionale (full-duplex) tra un client — di solito un browser — e un server. Una volta aperta, ciascun lato può inviare un messaggio in qualsiasi momento, senza che l’altro debba prima chiederlo. È questa la differenza fondamentale rispetto a una normale API HTTP: HTTP è una richiesta, una risposta, e finisce lì; un WebSocket resta aperto e trasporta messaggi in entrambe le direzioni per tutto il tempo che ti serve.

Poiché la connessione è già aperta, i messaggi arrivano con pochissimo overhead e quasi nessun ritardo. Niente header ripetuti, nessun nuovo handshake per messaggio — solo una piccola frame di dati in ciascuna direzione. È questo che rende i WebSocket adatti a tutto ciò che deve sembrare istantaneo.

Come parte un WebSocket: l’handshake HTTP

Un WebSocket non spunta dal nulla — inizia come una normale richiesta HTTP. Il browser invia una richiesta normale con un header Upgrade: websocket, chiedendo in sostanza al server di cambiare protocollo. Se il server accetta, risponde con lo stato 101 Switching Protocols, e da quel momento la stessa connessione TCP smette di parlare HTTP e inizia a parlare il protocollo WebSocket. È per questo che i WebSocket viaggiano sulle stesse porte del web (80 e 443) e attraversano la maggior parte dei firewall che già consentono il traffico web.

Dopo l’handshake, i dati si muovono come frame leggere. Ogni messaggio può essere testo — molto spesso JSON — o binario, e non c’è una forma fissa richiesta/risposta: i messaggi semplicemente scorrono quando c’è qualcosa da inviare.

ws vs wss

Gli URL WebSocket usano un proprio schema. ws:// è una connessione non cifrata, e wss:// è la versione cifrata, protetta con TLS esattamente come lo è https://. In pratica dovresti usare sempre wss:// in produzione — è cifrato ed è molto meno probabile che venga bloccato da proxy e reti aziendali che diffidano del traffico ws:// in chiaro.

Quando usare un WebSocket (e quando no)

I WebSocket danno il meglio ogni volta che il server deve inviare dati al client nel momento in cui accadono:

• Chat e messaggistica — i messaggi compaiono nell’istante in cui vengono inviati.
• Dashboard e quotazioni dal vivo — ticker di borsa, metriche, risultati sportivi.
• Collaborazione — documenti e lavagne condivise in cui le modifiche si sincronizzano dal vivo.
• Giochi multiplayer — aggiornamenti di stato a bassa latenza in entrambe le direzioni.
• Notifiche — tutto ciò che l’utente deve vedere senza ricaricare.

Non sono lo strumento giusto per tutto. Se il client si limita sempre a chiedere e il server sempre a rispondere — caricare una pagina, inviare un modulo, recuperare un record — una semplice API HTTP è più semplice, cacheabile e più facile da scalare. Ricorri a un WebSocket quando è il server a dover avviare la conversazione.

WebSocket vs polling vs SSE

Prima dei WebSocket, il trucco abituale per i dati «dal vivo» era il polling: il client chiede al server «c’è qualcosa di nuovo?» ogni pochi secondi. Funziona, ma è uno spreco — la maggior parte delle richieste torna vuota, e gli aggiornamenti restano comunque in ritardo dell’intervallo di polling. Un WebSocket sostituisce tutto questo con una connessione aperta e zero richieste sprecate.

Ci sono anche i Server-Sent Events (SSE), che ti danno un flusso a senso unico dal server al client su HTTP semplice. SSE è più semplice quando ti serve solo che il server invii (un feed di notizie, una barra di avanzamento). Scegli un WebSocket quando hai bisogno che i messaggi scorrano in entrambe le direzioni, e SSE quando una sola direzione basta.

Una nota sull’infrastruttura

Poiché un WebSocket tiene aperta una connessione, cambia il modo in cui distribuisci. Le connessioni di lunga durata hanno bisogno di un server e di un reverse proxy configurati per tenerle in vita anziché chiuderle per timeout, e scalare molte connessioni simultanee è un problema di progettazione a sé. È questo il compromesso: un WebSocket ti offre una comunicazione istantanea e bidirezionale in cambio del mantenere uno stato aperto sul server.

In sintesi

Un WebSocket è una connessione unica, persistente e bidirezionale che permette a server e browser di scambiarsi messaggi nel momento in cui accadono — senza il ritmo chiedi-e-attendi dell’HTTP. Nasce come una richiesta HTTP che viene aggiornata (upgrade), poi trasporta frame leggere in entrambe le direzioni. Usa wss://, ricorri a esso quando il server deve inviare dati dal vivo, e resta su una normale API HTTP quando bastano una semplice richiesta e risposta.