HTTP 推送机制

Source: Dev.to

传统的 HTTP 拉取模型

• 客户端发送请求
• 服务器处理请求
• 服务器返回响应
• 连接被关闭

每个请求都有一个生存时间（TTL），通常在 30 到 60 秒之间，具体取决于浏览器和运行环境。

如果服务器在此时间窗口内未作出响应，浏览器会认为请求已卡住并关闭连接。客户端随后必须发送新请求重新尝试。

这种行为是有意为之。打开的连接会消耗服务器资源，例如内存和文件描述符，且服务器只能同时处理有限数量的连接。如果没有超时机制，服务器最终可能耗尽资源。

当 HTTP Pull 不足时

HTTP Pull 模型在大多数使用场景下表现良好，但在以下情况下会出现问题：

• 服务器响应时间超过 TTL
• 服务器需要在数据可用后立即发送
• 需要低延迟、实时更新

在这些情况下，反复轮询服务器效率低下，并会引入不必要的延迟。

持久连接和 HTTP 推送

为了解决这个问题，我们使用持久连接。

持久连接在客户端和服务器之间保持打开状态，而不是在一次请求‑响应循环后关闭。一旦建立，服务器可以在准备好时随时向客户端推送数据，而无需等待新的请求。

这种通信模式通常称为 HTTP Push，并构成了许多实时 Web 系统的基础。

保持连接活跃：心跳拦截器

浏览器会在连接空闲时自动关闭它们。为防止这种情况，持久连接依赖于心跳机制。

心跳是客户端与服务器之间定期交换的体积小、开销低的消息。它们通常不包含任何有意义的数据。唯一的目的就是表明连接仍然处于活动状态，不应因闲置而被终止。

如果没有心跳，浏览器或代理会关闭长期保持的连接，从而导致 HTTP Push 不可靠。

持久连接的成本

虽然强大，但持久连接也有权衡。

与传统的 HTTP Pull 相比：

• 每个客户端消耗更多内存
• 需要更仔细的连接管理
• 增加服务器复杂性

由于每个客户端都保持打开的连接，可扩展性成为关键问题。这就是为什么只有在真正需要实时通信时才应使用 HTTP Push。

实际案例：多人浏览器游戏

一个明确需要 HTTP Push 的例子是基于浏览器的多人游戏。

玩家需要持续、实时地获取游戏状态、操作和事件的更新。如果每隔几秒就轮询一次服务器，响应速度会很差，用户体验也会下降。

在这种情况下，保持持久连接可以显著提升性能和响应速度。

常用的 HTTP 推送技术

• Ajax Long Polling – 通过保持请求打开直至有数据可用来模拟推送
• WebSockets – 在单个持久连接上提供全双工、实时通信
• Server‑Sent Events (SSE) – 允许服务器通过 HTTP 向客户端单向推送更新

每种方法都有其自身的优势和权衡，正确的选择取决于应用的需求。

结论

HTTP Push 通过保持连接打开并允许服务器在数据可用时立即发送数据，实现实时通信。虽然这种方法比传统的 HTTP Pull 更加占用资源，但对于需要低延迟和实时更新的现代应用来说是不可或缺的。

了解 TTL、持久连接和心跳机制如何协同工作，有助于工程师设计出既响应迅速又具可扩展性的系统。若谨慎使用，HTTP Push 能显著提升现代 Web 应用的用户体验。