WebSocket è un protocollo di comunicazione bidirezionale e persistente su una singola connessione TCP. A differenza di HTTP dove il client fa richieste e il server risponde, WebSocket mantiene un canale aperto dove entrambe le parti possono inviare messaggi in qualsiasi momento. È la tecnologia che abilita lo streaming delle risposte AI token per token e gli aggiornamenti in tempo reale.
Cos'è WebSocket?
Il protocollo WebSocket (standardizzato in RFC 6455 nel 2011) nasce per risolvere un limite fondamentale di HTTP: la comunicazione unidirezionale. Con HTTP il server può rispondere solo quando il client fa una richiesta e non può inviare dati spontaneamente. Questo era un problema per applicazioni che richiedevano aggiornamenti in tempo reale: chat, giochi online, feed live, trading platform.
Le soluzioni precedenti (long polling, server-sent events, iframe tricks) erano hack sul modello HTTP, inefficienti e difficili da mantenere. WebSocket introduce un protocollo nativo per comunicazioni bidirezionali e persistenti: dopo un handshake iniziale tramite HTTP che "fa upgrade" a WebSocket, la connessione TCP rimane aperta e sia client che server possono inviare messaggi (frame) in qualsiasi momento, senza overhead di header HTTP ripetuti.
Nel contesto dei chatbot AI moderni, WebSocket è utilizzato per due funzioni chiave: lo streaming delle risposte (i token dell'LLM vengono inviati non appena generati, token per token) e le notifiche real-time (nuovi messaggi in arrivo, aggiornamenti stato conversazione, handoff a operatore). Supabase Realtime usa WebSocket per notifiche live di INSERT/UPDATE/DELETE sul database.
Come Funziona WebSocket
Step 1: Handshake HTTP → WebSocket Upgrade
La connessione WebSocket inizia sempre come una normale richiesta HTTP con header speciali che chiedono al server di "fare upgrade" al protocollo WebSocket. Se il server supporta WebSocket e accetta, risponde con HTTP 101 Switching Protocols:
Dopo l'101, la connessione TCP rimane aperta e viene usata per messaggi WebSocket, non più per HTTP.
Step 2: Comunicazione Full-Duplex
Con la connessione stabilita, client e server possono inviare messaggi in qualsiasi momento senza attendere il turn dell'altro (full-duplex). I messaggi WebSocket sono molto più leggeri degli HTTP: solo 2-10 byte di overhead vs 200-800 byte di header HTTP. Questo li rende efficienti per messaggi frequenti e piccoli.
Step 3: Heartbeat e Reconnect
Le connessioni WebSocket possono cadere (timeout di rete, server restart, cambio WiFi). Per rilevare connessioni "zombie" si usa il meccanismo ping/pong: il server invia periodicamente un frame ping, il client risponde con pong. Se nessun pong arriva entro un timeout, la connessione viene chiusa. I client ben implementati gestiscono la riconnessione automatica con backoff esponenziale.
Step 4: Chiusura Pulita
La chiusura di una connessione WebSocket avviene tramite un handshake specifico: il mittente invia un frame di tipo "close" con un codice di chiusura (es. 1000 = normale, 1001 = going away, 1006 = closed abnormally). Il destinatario risponde con un close frame e la connessione TCP viene terminata in modo ordinato. Questo previene la perdita di messaggi in transito.
WebSocket vs HTTP: Confronto
| Aspetto | WebSocket | HTTP |
|---|---|---|
| Connessione | Persistente (aperta) | Effimera (request/response) |
| Direzione | Full-duplex (entrambi inviano) | Request-response (client chiede) |
| Overhead | 2-10 byte per frame | 200-800 byte di header |
| Server Push | Nativo: il server invia quando vuole | Solo con SSE o long polling |
| Caching | Non applicabile | Nativo con GET |
| Scalabilità Server | Più complessa (connessioni persistenti) | Semplice (stateless) |
| Ideale per | Real-time, streaming, notifiche | API, operazioni discrete |
WebSocket nel Chatbot AI
Streaming Risposte Token per Token
L'utilizzo principale di WebSocket nei chatbot AI moderni è lo streaming: il Large Language Model genera la risposta un token (parola/frammento) alla volta. Senza streaming, l'utente vede uno schermo bianco per 1-3 secondi e poi la risposta completa appare tutta insieme. Con lo streaming WebSocket, ogni token viene inviato non appena generato: l'utente vede il bot che "scrive" in tempo reale, migliorando drasticamente la percezione di reattività.
Questo è esattamente il comportamento che vedi su ChatGPT, Claude.ai e altri chatbot AI moderni.
Notifiche Real-Time supabase Realtime
Supabase Realtime usa WebSocket per inviare notifiche ai client quando i dati nel database cambiano. In V Support, questo abilita: notifica immediata quando un nuovo messaggio arriva in una conversazione, aggiornamento live del contatore conversazioni attive nella dashboard, e notifica agli operatori quando una conversazione richiede handoff, senza alcun polling.
Dashboard Live e Monitoring
La dashboard di amministrazione mostra metriche in tempo reale (conversazioni attive, messaggi per minuto, tasso di risoluzione) che si aggiornano senza refresh della pagina. WebSocket permette al server di inviare aggiornamenti ai widget della dashboard non appena i dati cambiano nel database, offrendo una visione operativa sempre aggiornata.
Alternative a WebSocket
Server-Sent Events (SSE)
SSE è un'API browser standard che permette al server di inviare un flusso di eventi al client su una connessione HTTP persistente. A differenza di WebSocket, SSE è unidirezionale (solo server → client). Più semplice da implementare e con reconnect automatico nativo. Ideale per streaming testo AI quando non serve comunicazione bidirezionale.
OpenAI API usa SSE per streaming risposte GPT. Più semplice di WebSocket quando basta monodirezionale.
Long Polling
Il client fa una richiesta HTTP e il server la mantiene aperta finché non ci sono dati da inviare (o scade il timeout). Quando il server risponde, il client fa immediatamente una nuova richiesta. Simula il real-time su HTTP puro, ma con overhead elevato e latenza maggiore. Usato come fallback quando WebSocket non è disponibile.
Fallback per ambienti con proxy che non supportano connessioni WebSocket persistenti.
HTTP/2 Push
HTTP/2 permette al server di inviare risorse al client prima che le richieda (server push). Usato principalmente per ottimizzare il caricamento delle pagine web (invia CSS e JS prima che il browser li richieda). Meno adatto per comunicazioni bidirezionali real-time rispetto a WebSocket.
WebTransport (Futuro)
API emergente basata su HTTP/3 e QUIC (UDP) per comunicazioni bidirezionali a bassa latenza. Supera alcune limitazioni di WebSocket (multiplexing stream, indipendenza head-of-line blocking). Ancora in fase di adozione, ma candidato a diventare il successore di WebSocket per casi d'uso ad alta performance.
Quando Usare WebSocket vs HTTP
Usa WebSocket per...
- Streaming risposte AI token per token
- Chat in tempo reale multi-utente
- Notifiche push live (nuovi messaggi, alert)
- Dashboard con aggiornamenti real-time
- Giochi online o applicazioni collaborative
- Monitoraggio di sistemi con aggiornamenti frequenti
Usa HTTP REST per...
- Operazioni CRUD discrete (crea, leggi, aggiorna, elimina)
- Richieste che beneficiano del caching HTTP
- API pubbliche con accesso da qualsiasi client
- Operazioni idempotenti e stateless
- Integrazioni con sistemi che non supportano WebSocket
- Quando la semplicità è prioritaria
Domande Frequenti
Cos'è il WebSocket?
WebSocket è un protocollo di comunicazione bidirezionale e persistente che opera su TCP. Dopo un handshake iniziale HTTP, la connessione rimane aperta e sia client che server possono inviare messaggi in qualsiasi momento. Questo lo rende ideale per comunicazioni real-time come streaming AI, chat live, notifiche push e dashboard che si aggiornano continuamente senza dover fare polling periodico.
Perché il chatbot usa WebSocket?
Il chatbot usa WebSocket principalmente per lo streaming delle risposte AI: ogni token generato dall'LLM viene inviato immediatamente al client, dando l'impressione che il bot stia scrivendo in tempo reale. Senza WebSocket, l'utente aspetterebbe in silenzio 1-3 secondi e poi vedrebbe la risposta completa apparire tutta insieme. Lo streaming migliora significativamente la percezione di velocità e naturalezza dell'interazione.
WebSocket vs HTTP: differenze principali?
HTTP è request-response: il client chiede, il server risponde, la connessione si chiude. WebSocket è full-duplex e persistente: entrambi possono inviare messaggi quando vogliono su una connessione aperta. HTTP ha overhead alto (header ripetuti), WebSocket ha overhead minimo (2-10 byte). Molte applicazioni usano entrambi: HTTP per operazioni discrete (CRUD), WebSocket per comunicazioni continue (streaming, notifiche live).
Termini Correlati
Implementa WebSocket nella Tua Azienda
Scopri come V Support può aiutarti a sfruttare l'AI per il tuo customer service. Demo gratuita di 30 minuti.