Real-Time Streaming Systems (WebRTC + Live Data) · 课时

长轮询及其向流式传输的发展

了解长轮询如何在传统 HTTP 与现代实时数据传输之间发挥桥梁作用、它何时仍然重要，以及它与 WebSockets 和 SSE 的区别。

第 4 / 4 课13 个步骤

长轮询及其向流式传输的发展 是 CoddyKit 上的免费 Real-Time Streaming Systems (WebRTC + Live Data) 课时。这是第 4 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。这是 Real-Time Streaming Systems (WebRTC + Live Data) 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Real-Time Streaming Systems (WebRTC + Live Data) 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

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=10427

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

免费开始

用 AI 导师学习 Real-Time Streaming Systems (WebRTC + Live Data) — 免费

在浏览器中编写并运行真实代码，获得全天候 AI 导师的即时帮助，并在网页或应用中继续学习。

课程: 12
课程: 48

免费开始学习查看完整课程

常见问题解答

「长轮询及其向流式传输的发展」课时是免费的吗？

是的 — 「长轮询及其向流式传输的发展」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Real-Time Streaming Systems (WebRTC + Live Data) 课程的其余内容，请升级到 CoddyKit PRO。 Real-Time Streaming Systems (WebRTC + Live Data) 课程共包含 4 节课。

「长轮询及其向流式传输的发展」这节课中我会学到什么？

了解长轮询如何在传统 HTTP 与现代实时数据传输之间发挥桥梁作用、它何时仍然重要，以及它与 WebSockets 和 SSE 的区别。你通过在浏览器中直接运行的动手代码来练习 Real-Time Streaming Systems (WebRTC + Live Data)，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Real-Time Streaming Systems (WebRTC + Live Data) 需要有经验吗？

无需任何先前经验。CoddyKit 上的 Real-Time Streaming Systems (WebRTC + Live Data) 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 4 节课，共 4 节。

「长轮询及其向流式传输的发展」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 Real-Time Streaming Systems (WebRTC + Live Data) 课中编写并运行代码吗？

能。每节 Real-Time Streaming Systems (WebRTC + Live Data) 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 Real-Time Streaming Systems (WebRTC + Live Data)