使用 HTTP Keep-Alive 让服务器与客户端通信答案

【问题标题】：Use HTTP Keep-Alive for server to communicate to client使用 HTTP Keep-Alive 让服务器与客户端通信
【发布时间】：2010-09-29 12:20:54
【问题描述】：

最近在一次采访中，有人问我如何处理在线聊天客户端应用程序。我经历了标准的“轮询”解决方案，但由于面试官正在寻找“HTTP 1.1 keep-alive”方法而被中断。使用 HTTP 已经有一段时间了，并记得整点是“无状态的”，但我从来没有想到过（更不用说 keep-alive 并没有始终如一地实现）。

我的问题是，当设置了“keep-alive”标头时，网络服务器是否可以向客户端广播和/或发送信息？

【问题讨论】：

标签： http chat keep-alive

【解决方案1】：

对于 HTTP 1.1，keep-alive 是默认行为。（在 HTTP 1.0 中，默认行为是关闭连接。）服务器必须发送 'Connection: close" 标头以终止与第一个响应的连接。所以仍然有一个 TCP 套接字可用于推送数据，但只是从服务器推送数据在很大程度上违反了 HTTP 协议。即使使用 keep-alive，客户端仍然需要轮询服务器。

区分 HTTP Keepalive 和 TCP Keepalive 很重要。 HTTP keepalive 防止连接被服务器或客户端关闭。当连接可能长时间处于空闲状态并且可能被 NAT 代理或防火墙丢弃时，使用 TCP keepalive。通过 setsockopt() 调用在每个套接字的基础上激活 TCP keepalive。

在进行“长轮询”以消除重新轮询的需要时，可能需要 TCP 保持连接。

【讨论】：

【解决方案2】：

您可能会阅读有关Comet 服务器的更多信息。这听起来基本上像面试官所询问的方法。它们的有效性受到一些人的质疑，但它已被用于几个类似的情况。

例如，我相信 gmail 在某些事情上使用了彗星技术（但不要引用我的话）。

另一个似乎相关的例子是BOSH，它是一种使用 HTTP 和 XMPP 传输聊天信息的协议。但我不认为使用 keep-alive 参与其中。

【讨论】：

【解决方案3】：

Keep-alive 只是保持 TCP 套接字打开，因此每次轮询时，您都可以节省 TCP 设置/拆除数据包的开销——但您仍然需要轮询。

但是，“长轮询”是 Web 服务器向客户端广播通知的一种策略。本质上，客户端发出 GET 请求，但 Web 服务器不会立即响应，而是等待它们发送通知，此时它们会响应 GET 请求。这消除了数据包通过网络进行轮询的任何需要，并保持连接无状态，正如您正确提到的，这是协议的目的之一。

【讨论】：