การสำรวจแบบยาวและวิวัฒนาการสู่การสตรีม

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 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 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 long polling client recursively re-issues the request after each response. This keeps a near-continuous channel open.

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.

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.

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.

• 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.

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.

• 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.

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.

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.