Long polling e l’evoluzione verso lo streaming
Comprenda il long polling come tecnica ponte tra HTTP tradizionale e moderni trasporti di dati live, quando è ancora utile e come si confronta con WebSocket e SSE.
Long polling e l’evoluzione verso lo streaming è una lezione Real-Time Streaming Systems (WebRTC + Live Data) gratuita su CoddyKit. Questa è la lezione 4 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Real-Time Streaming Systems (WebRTC + Live Data), e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Real-Time Streaming Systems (WebRTC + Live Data) include 4 lezioni in totale.
Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.
Why Long Polling Exists
Before WebSockets and SSE were widely supported, developers needed a way to push data to clients over plain HTTP. Long polling filled that gap.
With long polling, the client makes a request and the server holds it open until new data is available, instead of replying immediately.
Short Polling vs Long Polling
Short polling hammers the server on a fixed interval, wasting requests when nothing changed.
- Short polling: request, immediate empty reply, wait, repeat.
- Long polling: request, server waits, replies only when data arrives.
Long polling cuts the volume of empty responses dramatically.
The Long Polling Cycle
The lifecycle is a loop:
- Client sends a request.
- Server holds it open (often with a timeout).
- When an event occurs, the server responds.
- Client processes data and immediately reconnects.
A Simple Client Loop
A long polling client recursively re-issues the request after each response. This keeps a near-continuous channel open.
async function poll() {
try {
const res = await fetch('/api/updates');
const data = await res.json();
handle(data);
} catch (e) {
console.error(e);
}
poll();
}
poll();Server Side: Holding the Request
On the server, you avoid replying until an event fires or a timeout is reached. This often uses an event emitter or a pending-promise registry.
app.get('/api/updates', (req, res) => {
const onEvent = (data) => {
res.json(data);
emitter.off('update', onEvent);
};
emitter.on('update', onEvent);
setTimeout(() => {
emitter.off('update', onEvent);
res.status(204).end();
}, 30000);
});Timeouts Matter
Never hold a request forever. Proxies, load balancers, and mobile networks will silently drop idle connections.
Use a server-side timeout (for example 30s) that returns an empty 204, prompting the client to reconnect cleanly.
Handling Reconnection Gaps
Between a response and the next request there is a tiny window where events could be missed. Use a cursor or last-seen ID so the server can replay anything that happened during the gap.
GET /api/updates?since=10427Long Polling vs WebSockets
- WebSockets: one persistent, bidirectional connection. Lowest latency.
- Long polling: repeated HTTP requests. Higher overhead but works everywhere HTTP works.
WebSockets win for chat and games; long polling wins for hostile network environments and legacy proxies.
Long Polling vs SSE
SSE keeps one connection open and streams many events down it. Long polling reopens a connection per event.
SSE is generally more efficient for unidirectional push, but long polling has broader compatibility and simpler proxy behavior.
Where Long Polling Still Wins
- Corporate networks that block WebSocket upgrades.
- Old proxies that buffer streaming responses.
- Serverless platforms with short execution limits, used as a fallback.
Many libraries (Socket.IO included) fall back to long polling automatically.
Scaling Considerations
Each held request consumes a server slot. With thousands of clients you need non-blocking I/O (Node, Go, async Python) so held requests do not exhaust threads.
Sticky sessions or a shared pub/sub layer (Redis) let multiple servers coordinate events.
Quick Check
Test your understanding of long polling.
Recap
Long polling holds an HTTP request open until data is ready, then the client reconnects. It bridges classic HTTP and true streaming.
- More efficient than short polling.
- Less efficient than WebSockets/SSE, but more compatible.
- Use timeouts and a cursor to stay reliable.
Impara Real-Time Streaming Systems (WebRTC + Live Data) con un tutor IA — gratis
Scrivi ed esegui vero codice nel tuo browser, ricevi aiuto istantaneo da un tutor IA disponibile 24/7, e riprendi da dove hai lasciato sul web o nell'app.
- Corsi
- 12
- Lezioni
- 48
Domande Frequenti
La lezione «Long polling e l’evoluzione verso lo streaming» è gratuita?
Sì — il testo completo di «Long polling e l’evoluzione verso lo streaming» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Real-Time Streaming Systems (WebRTC + Live Data), passa a CoddyKit PRO. Il corso Real-Time Streaming Systems (WebRTC + Live Data) include 4 lezioni in totale.
Cosa imparerò in «Long polling e l’evoluzione verso lo streaming»?
Comprenda il long polling come tecnica ponte tra HTTP tradizionale e moderni trasporti di dati live, quando è ancora utile e come si confronta con WebSocket e SSE. Eserciti Real-Time Streaming Systems (WebRTC + Live Data) con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare Real-Time Streaming Systems (WebRTC + Live Data)?
Non è richiesta alcuna esperienza precedente. Real-Time Streaming Systems (WebRTC + Live Data) su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 4 di 4.
Quanto tempo richiede la lezione «Long polling e l’evoluzione verso lo streaming»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione Real-Time Streaming Systems (WebRTC + Live Data)?
Sì. Ogni lezione Real-Time Streaming Systems (WebRTC + Live Data) include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- Dati in tempo reale e HTTP tradizionale
- WebSocket per flussi bidirezionali
- Server-Sent Events (SSE) per il push unidirezionale
- Long polling e l’evoluzione verso lo streaming