Long Polling：它是什么、如何工作及在哪里使用

什么是 Long Polling

Long Polling 是客户端-服务器架构中的一种交互模式，客户端发起 HTTP 请求，服务器延迟发送响应直到新数据出现或指定超时到期。收到响应后，客户端立即发送下一个请求，产生持续连接的效果。

Long Polling 技术是 Short Polling 的演进发展，用于减少空 HTTP 请求的数量。在传统轮询中，客户端每隔 N 秒发送请求，即使没有新数据服务器也会响应。在 Long Polling 中，服务器使用连接保持机制，大幅减少无用流量。

Long Polling 的历史

在 2011 年 WebSocket 出现之前，Long Polling 是网络上组织实时通信的主要方式。Facebook 和 Gmail 等公司在 2010 年代初使用这种技术进行聊天和通知。根据 High Performance Browser Networking (Grigorik, 2013) 的研究，Long Polling 处理了当时大型 Web 应用中高达 95% 的实时连接。

Long Polling 的基本原理

客户端向服务器发送标准 HTTP 请求。服务器收到请求后不立即返回响应 — 将请求放入等待队列。当服务器上发生事件（新消息、数据更改）时，服务器形成响应并发送给客户端。客户端收到响应后，立即创建新的Long Polling 请求，循环重复。

Long Polling 如何工作

Long Polling 按以下步骤序列工作。客户端向服务器端点发送 HTTP GET 请求。服务器收到请求后检查事件队列中是否有新数据。如果没有数据，服务器保持请求处于等待状态，不立即发送响应。保持机制取决于服务器的实现 — 最常使用带回调的异步处理或事件驱动架构。

当服务器端发生事件（例如用户在聊天中发送消息）时，服务器形成包含这些数据的 HTTP 响应并结束连接。客户端收到响应，处理数据并立即发起新请求。如果在等待期间没有数据出现，服务器在超时后发送空响应，客户端也重新创建连接。超时通常为 30-60 秒，以平衡负载和延迟。

超时与连接管理

Long Polling 配置的关键参数是等待超时。超时过短（少于 10 秒）会导致请求数量增加，使技术接近 Short Polling。过长（超过 120 秒）可能导致中间代理和负载均衡器断开连接。大多数场景的推荐值为 30-45 秒。

处理多个事件

如果在一次 Long Polling 请求期间服务器上发生了多个事件，服务器必须在一次响应中全部传递，或在客户端组织事件队列。为此使用事件缓冲：服务器收集请求保持期间发生的事件，作为数据数组在响应体中传递。

JavaScript 中 Long Polling 实现示例

让我们看看使用现代 Fetch API 在客户端实现 Long Polling 的简单例子。客户端函数发送请求并在收到响应后递归调用自身。

async function longPoll(url) {
    try {
        const response = await fetch(url);
        const data = await response.json();

        handleData(data);
        longPoll(url);
    } catch (error) {
        console.error("Long Polling 错误", error);
        setTimeout(() => longPoll(url), 3000);
    }
}

function handleData(data) {
    if (data.events && data.events.length > 0) {
        data.events.forEach(event => {
            console.log("新事件：", event);
        });
    }
}

longPoll("/api/events");

此代码创建无限 Long Polling 循环：收到响应后，函数立即发送新请求。连接错误时，在重试前设置三秒延迟以避免服务器雪崩负载。

Node.js 中的服务器实现

在服务器端，需要保持请求直到事件出现或超时到期。在 Node.js 中使用 EventEmitter 的实现示例演示了此机制。

const express = require("express");
const EventEmitter = require("events");
const app = express();

const eventBus = new EventEmitter();

app.get("/api/events", (req, res) => {
    const timeout = setTimeout(() => {
        res.json({ events: [] });
    }, 30000);

    eventBus.once("new-event", (data) => {
        clearTimeout(timeout);
        res.json({ events: [data] });
    });
});

app.post("/api/events", (req, res) => {
    eventBus.emit("new-event", req.body);
    res.send({ status: "ok" });
});

app.listen(3000);

服务器部分使用 EventEmitter 在新数据出现时通知等待的 Long Polling 连接。达到 30 秒超时后，服务器返回空事件数组，客户端创建新请求。

何时使用 Long Polling

Long Polling 在需要实时数据传递但因技术或基础设施原因无法使用 WebSocket 的场景中使用。最常见的情况 — 阻止 WebSocket 连接的企业代理和防火墙，以及服务器端协议支持受限的环境。

• 聊天和即时通讯 — Long Polling 确保通过 HTTP 无 WebSocket 工作的 Web 版即时通讯工具的信息传递。
• 监控面板 — 用于 DevOps 指标、日志和告警的实时系统，其中数据的时效性（1-5 秒延迟）很重要。
• 通知 — 在浏览器中无需使用 Service Workers 和 Push API 即可传递通知。
• 活动流 — 社交网络和新条目出现时自动更新内容的新闻提要。
• 协同工作 — 类似 Google Docs 的编辑器，用户之间进行基本的变更同步。

选择 Long Polling 的关键因素是向后兼容性。所有 HTTP 客户端和服务器都支持此方法，使其成为无需额外依赖的实时通用解决方案。根据 HTTP Archive（2024），约 8% 的网站继续使用 Long Polling 实现基本的实时功能。

Long Polling vs Short Polling

Long Polling 和 Short Polling 解决相同的任务 — 将数据从服务器传递到客户端 — 但在机制和效率方面有根本区别。Short Polling 使用固定轮询间隔，客户端以相等时间间隔发送 HTTP 请求，无论服务器上是否有新数据。

Short Polling 实现更简单，但在相同的数据更新频率下对服务器和网络产生更大的负载。如果需要低于 5 秒的延迟，Short Polling 每分钟生成几十个请求，而 Long Polling 每次事件或超时使用一个请求。对于事件稀疏的应用程序，Long Polling 在流量方面效率更高。

Long Polling vs WebSocket

WebSocket 是一种完整的双向实时协议，在初始 HTTP 握手后通过 TCP 工作。与 Long Polling 不同，WebSocket 建立一个永久连接，允许服务器随时向客户端发送数据而无需创建新的 HTTP 请求。

Long Polling 和 WebSocket 之间的选择取决于几个因素。兼容性：Long Polling 可通过所有代理和防火墙工作，WebSocket 可能被企业网络阻止。性能：WebSocket 具有更小的开销（每帧 2 字节，而完整 HTTP 头为数百字节），在高消息频率下至关重要。可扩展性：Long Polling 因保持多个连接而需要更多服务器端资源，WebSocket 每会话使用固定连接。

• Long Polling — 低事件频率（每分钟 1-10 个事件）、基础设施有限或需要支持旧浏览器的应用程序的最佳选择。
• WebSocket — 高负载实时应用（股票数据、在线游戏、协作编辑器）每秒数百条消息的最佳解决方案。
• 混合方法 — 某些应用程序将 Long Polling 作为不支持 WebSocket 的客户端的后备方案，自动切换协议。

根据 Mozilla Developer Network（2024），WebSocket 从 2011-2015 版本开始被所有现代浏览器支持，但企业代理（如 Symantec Blue Coat）仍在 15-20% 的企业网络中阻止它，保持 Long Polling 作为后备解决方案的相关性。