Il pattern "notifica + fetch" nei WebSocket: quanto costa e quando ha senso

Nella revisione di applicazioni real-time incontro quasi sempre la stessa architettura. Il canale WebSocket è aperto, funzionante, bidirezionale — e viene usato per mandare un messaggio che dice, in sostanza, «è cambiato qualcosa, vieni a vedere».

1// Il server ha aperto un canale bidirezionale... e lo usa per dire "guarda che2// è successo qualcosa". Il dato vero arriva da un'altra parte.3socket.addEventListener('message', async (ev) => {4  const avviso = JSON.parse(ev.data);   // { nuoviEventi: 3, modificati: 1 }5  if (!avviso.nuoviEventi && !avviso.modificati) return;6​7  const r = await fetch('/api/eventi', { credentials: 'include' });8  const eventi = await r.json();9  render(eventi);10});

1// lato server: la notifica non porta niente con sé2function onEventiCambiati(canale, delta) {3  const avviso = JSON.stringify({4    nuoviEventi: delta.nuovi.length,5    modificati: delta.modificati.length6  });7  for (const ws of iscritti(canale)) ws.send(avviso);8}

Il canale c'è, è già autenticato, è già aperto, e trasporta quaranta byte di metadati per poi delegare il lavoro vero a una richiesta HTTP separata. Vale la pena capire con precisione che cosa costa — perché la risposta non è quella che si legge di solito, e in un caso su tre il pattern è la scelta corretta.

Quanto costa davvero#

Sul filo#

Un frame WebSocket ha un'intestazione di 2 byte per payload fino a 125 byte; diventano 4 fino a 64 KiB e 10 oltre. I frame che vanno dal client al server portano in più una masking key di 4 byte, obbligatoria per specifica. Sono i numeri della sezione 5.2 dell'RFC 6455, non stime.

Una richiesta HTTP/1.1 di un browser reale non ha niente di paragonabile: riga di richiesta, Host, User-Agent, Accept, Accept-Language, Accept-Encoding, Referer, Sec-Fetch-* e soprattutto Cookie. Con un cookie di sessione si sta comodamente fra i 500 e i 900 byte, per ogni richiesta, in salita — cioè sul lato lento della connessione.

Nel tempo#

Qui non c'è compressione che tenga. Con la sincronizzazione diretta il dato è sullo schermo quando arriva il frame. Con notifica + fetch bisogna aggiungere, dopo la notifica, un round-trip completo più il tempo di risposta del server:

sync diretta      │████│                                   ~8 msnotifica + fetch  │████│─── RTT 45 ms ───│██ query 12 ms ██│  ~65 ms                   frame   andata/ritorno    lavoro server

Su fibra con 10 ms di RTT la differenza è un fastidio teorico. Su 4G, dove 40-70 ms di RTT sono la norma, ogni aggiornamento arriva con un ritardo percepibile — e in un'interfaccia che si aggiorna di continuo il ritardo non si somma, si nota: è la differenza fra un valore che cambia e un valore che scatta.

Sul server#

È il costo che scala peggio, e l'unico che può far cadere il servizio. Con la sincronizzazione diretta una modifica produce una serializzazione JSON, riusata per tutti gli iscritti al canale: per client resta solo una send() su un buffer già pronto.

Con notifica + fetch, la stessa modifica notificata a 1 000 client produce 1 000 richieste HTTP nell'arco di pochi millisecondi: 1 000 parsing, 1 000 verifiche di sessione, 1 000 query, 1 000 serializzazioni. È un thundering herd che vi siete costruiti in casa, e il primo a cedere non è la CPU: è il pool di connessioni al database.

Il bug che nessuno si aspetta: l'ordine#

Questa parte del pattern è raramente discussa e produce dati corrotti in modo silenzioso. Due modifiche ravvicinate generano due notifiche, quindi due fetch in volo contemporaneamente. Le risposte HTTP non hanno alcun obbligo di tornare nell'ordine in cui sono partite: bilanciatori diversi, repliche di lettura diverse, code diverse.

1// Due notifiche a 5 ms di distanza, due fetch in volo insieme.2// Non c'è niente che garantisca che le risposte tornino nell'ordine giusto.3socket.onmessage = async () => {4  const eventi = await fetch('/api/eventi').then(r => r.json());5  render(eventi);   // ← l'ultima risposta ARRIVATA vince,6};                  //   non l'ultima EMESSA

Il risultato è uno stato più vecchio che sovrascrive uno più recente, e resta lì finché non arriva un altro aggiornamento. L'utente vede un dato sbagliato; nei log non c'è niente. La toppa è un contatore di generazione:

1// La toppa: un contatore che scarta le risposte superate.2let ultimaRichiesta = 0;3​4socket.onmessage = async () => {5  const mia = ++ultimaRichiesta;6  const eventi = await fetch('/api/eventi').then(r => r.json());7  if (mia !== ultimaRichiesta) return;   // nel frattempo ne è partita un'altra8  render(eventi);9};

Funziona. Ma vale la pena notare che cosa è appena successo: abbiamo scritto codice di sincronizzazione per riparare un problema che abbiamo introdotto noi uscendo da un canale che l'ordine lo garantiva già. Il WebSocket viaggia su TCP: dentro una connessione i messaggi arrivano nell'ordine in cui sono partiti, sempre.

La sincronizzazione diretta#

La forma corretta è banale da scrivere. Il messaggio porta il dato:

1// Il messaggio porta il dato. Nessuna seconda andata e ritorno.2function onEventiCambiati(canale, delta) {3  const payload = JSON.stringify({4    t: 'sync',5    seq: prossimoSeq(canale),        // ordine esplicito, vedi sotto6    put: delta.nuovi.concat(delta.modificati),7    del: delta.eliminati.map(e => e.id)8  });9​10  // Una sola serializzazione riusata per tutti gli iscritti: il costo per11  // client scende a una send() su un buffer già pronto.12  for (const ws of iscritti(canale)) ws.send(payload);13}

1socket.addEventListener('message', (ev) => {2  const m = JSON.parse(ev.data);3  if (m.t !== 'sync') return;4​5  // Il WebSocket viaggia su TCP: dentro una connessione l'ordine dei messaggi6  // è garantito. Il seq serve a riconoscere i buchi dopo una riconnessione,7  // non a riordinare.8  if (attesoSeq !== null && m.seq !== attesoSeq) return richiediSnapshot();9  attesoSeq = m.seq + 1;10​11  for (const ev of m.put) stato.set(ev.id, ev);12  for (const id of m.del) stato.delete(id);13  render(stato);14});

Un solo messaggio, zero richieste, aggiornamento immediato e ordine garantito dal trasporto. Se l'articolo finisse qui sarebbe uno dei tanti che consigliano la cosa giusta senza dire che cosa comporta. Comporta tre cose.

1. Un protocollo, non solo un formato#

Finché la connessione regge, TCP basta. Il problema comincia alla riconnessione: il client è stato via quattro secondi, e in quei quattro secondi lo stato è cambiato. Serve un numero di sequenza per canale e un modo per dichiarare dove si era rimasti.

// Alla riapertura del socket il client dichiara dove era rimasto.socket.addEventListener('open', () => {  socket.send(JSON.stringify({ t: 'resume', canale: 'eventi', da: attesoSeq }));});

1// Il server decide: rigiocare il buco, oppure ripartire da capo.2// Un backlog illimitato è una perdita di memoria travestita da funzionalità:3// oltre una certa distanza lo snapshot costa meno del recupero.4const FINESTRA = 500;   // quanti messaggi tengo per canale5​6function onResume(ws, { canale, da }) {7  const log = backlog(canale);              // ring buffer di FINESTRA elementi8  const primo = log.length ? log[0].seq : prossimoSeq(canale);9​10  if (da == null || da < primo) {11    return ws.send(JSON.stringify({12      t: 'snapshot', seq: prossimoSeq(canale) - 1, stato: statoCompleto(canale)13    }));14  }15​16  for (const m of log) if (m.seq >= da) ws.send(m.payload);17}

2. La backpressure, che il fetch vi regalava#

Questo è il punto in cui la sincronizzazione diretta si rompe davvero, e vale la pena essere espliciti: con notifica + fetch la backpressure era implicita. Un client lento semplicemente non richiedeva i dati; il server non se ne accorgeva nemmeno, perché non stava spingendo niente.

Spingendo, invece, send() non aspetta nessuno. Se il socket non smaltisce — rete mobile, scheda in background, dispositivo sotto carico — la coda cresce nella memoria del processo server. Con qualche migliaio di connessioni e un aggiornamento al secondo, la crescita non è teorica.

1// Il punto in cui il push diretto si rompe: un client lento.2// send() non aspetta nessuno. Se il socket non smaltisce, la coda cresce3// nella RAM del server finché il processo non viene ucciso dall'OOM killer.4const SOGLIA = 1 << 20;   // 1 MiB di arretrato per client5​6for (const ws of iscritti(canale)) {7  if (ws.bufferedAmount > SOGLIA) {8    // Questo client non sta al passo: smetto di spingergli delta e lo9    // degrado al modello a notifica. Si riallineerà con uno snapshot.10    ws.send(JSON.stringify({ t: 'stale' }));11    continue;12  }13  ws.send(payload);14}

La proprietà si chiama bufferedAmount ed esiste sia sul WebSocket del browser sia sui socket lato server. Leggerla prima di ogni send() costa nulla e trasforma un crash per esaurimento memoria in un client che si riallinea con uno snapshot.

3. L'autorizzazione al momento della pubblicazione#

Il fetch faceva un altro regalo che si nota solo quando sparisce: ogni GET ripassava dal middleware di autorizzazione, che filtrava i campi in base all'utente. Spingendo una serializzazione unica a tutti gli iscritti di un canale, quel filtro non c'è più.

1// Con il fetch l'autorizzazione era implicita: ogni GET ripassava dal2// middleware che filtrava per utente. Spingendo il dato, quel passaggio3// non avviene più — e va rifatto a mano, al momento della pubblicazione.4​5// ✗ Una sola serializzazione per tutti: il campo riservato arriva a chiunque.6const payload = JSON.stringify({ t: 'sync', put: eventi });7for (const ws of iscritti(canale)) ws.send(payload);8​9// ✓ Una vista per ruolo, serializzata una volta per ruolo e non per utente.10const perRuolo = new Map();11for (const ws of iscritti(canale)) {12  let p = perRuolo.get(ws.ruolo);13  if (!p) perRuolo.set(ws.ruolo, p = JSON.stringify({14    t: 'sync', put: eventi.map(e => proiettaPer(ws.ruolo, e))15  }));16  ws.send(p);17}

Quando "notifica + fetch" è la scelta giusta#

Non è un antipattern. È un pattern con un dominio di validità preciso, e ci sono casi in cui è la sola scelta difendibile:

• Payload grandi. Sopra qualche decina di KiB si vuole HTTP: compressione negoziata, richieste parziali, streaming, la possibilità di interrompere. Un frame WebSocket da 4 MiB è un frame da 4 MiB che occupa il canale.
• Risorse cacheabili e condivise. Se l'aggiornamento è uguale per tutti e la risorsa ha un'ETag, la CDN fa il fan-out al posto vostro e il server risponde 304. Con il push il server parla con ogni client, sempre.
• Client che potrebbero non volerlo. Scheda in background, componente non montato, vista non aperta: notificare costa 40 byte, spingere costa il payload intero a chi non lo guarderà.
• Autorizzazione complessa per riga. Se decidere che cosa un utente può vedere richiede una query, rifarlo per ogni iscritto a ogni pubblicazione è peggio che lasciarlo fare al percorso HTTP.
• Client lenti e senza controllo sul parco dispositivi. Vedi sopra: la backpressure implicita è una proprietà, non un caso.

La forma ibrida#

In produzione la scelta non è binaria. Il messaggio porta il dato finché è piccolo, e sopra una soglia degrada da solo a un riferimento — con il numero di sequenza che permette al client di chiedere esattamente il pezzo che gli manca:

1// La forma matura: il delta viaggia inline finché è piccolo, e sopra una2// soglia il messaggio degrada da solo a un riferimento da recuperare.3const SOGLIA_INLINE = 32 * 1024;   // 32 KiB4​5const delta = JSON.stringify({ t: 'sync', seq, put, del });6​7const messaggio = delta.length <= SOGLIA_INLINE8  ? delta9  : JSON.stringify({ t: 'sync-ref', seq, url: `/api/eventi?since=${seq - 1}` });10​11for (const ws of iscritti(canale)) ws.send(messaggio);

La soglia è un parametro da tarare, non un dogma: 32 KiB è un punto di partenza ragionevole per dati strutturati. Il vantaggio è che il caso comune — l'aggiornamento piccolo e frequente, che è il novanta per cento del traffico real-time — smette di pagare il round-trip, e il caso raro continua a usare lo strumento adatto.

Misurarlo sul proprio traffico#

Le stime di questo articolo servono a inquadrare l'ordine di grandezza. I numeri che contano sono i vostri, e si ottengono in cinque minuti. Il rapporto fra byte HTTP e byte WebSocket, direttamente in console:

1// Quanto pesa davvero un aggiornamento, sui due percorsi.2// Da incollare in console con la scheda aperta sull'app.3let ws = 0, http = 0;4​5const _send = WebSocket.prototype.send;6WebSocket.prototype.send = function (d) { ws += d.length || d.byteLength || 0; return _send.call(this, d); };7​8new PerformanceObserver((l) => {9  for (const e of l.getEntries()) http += e.transferSize || 0;10}).observe({ type: 'resource', buffered: true });11​12setInterval(() => console.log({ ws, http, rapporto: (http / ws).toFixed(1) }), 5000);

La latenza percepita end-to-end, che è l'unico numero che l'utente sente davvero:

1// Latenza percepita: dal momento in cui il dato è pronto sul server a quando2// è sullo schermo. È l'unico numero che conta, e non lo vedi nei log HTTP.3socket.addEventListener('message', (ev) => {4  const m = JSON.parse(ev.data);5  if (!m.emessoIl) return;6  // Richiede orologi allineati (NTP): fra server e client il confronto è7  // indicativo. Fra due strategie misurate sulla stessa macchina, è valido.8  performance.measure('sync', {9    start: m.emessoIl,10    end: performance.timeOrigin + performance.now()11  });12});

E il traffico grezzo del canale, senza strumentare niente: nel pannello Rete di Chrome si filtra per WS, si seleziona la connessione e si apre la scheda Messages. Ogni frame è lì, con dimensione e direzione.

$# quante richieste genera un singolo aggiornamento, lato server$tail -f /var/log/app/access.log | grep --line-buffered '/api/eventi' | ts '%H:%M:%.S'14:22:07.104 GET /api/eventi 200 61214:22:07.109 GET /api/eventi 200 61214:22:07.109 GET /api/eventi 200 61214:22:07.113 GET /api/eventi 200 612$# quattro client, una sola modifica: il pattern è visibile a occhio nudo

Riepilogo#

La conclusione non è «non usate mai il fetch». È che il canale bidirezionale, se lo avete aperto, è già pagato: la connessione, l'handshake, l'autenticazione e il keep-alive sono costi che state sostenendo comunque. Usarlo per suonare un campanello e poi aprire un secondo percorso per il dato è una scelta — legittima in alcuni casi, ma che va fatta sapendo che cosa si compra e che cosa si paga.