服务器使用 HTTP Keep-Alive 与客户端通信
最近在一次采访中，有人问我如何处理在线聊天客户端应用程序。 我经历了标准的“轮询”解决方案，但被打断了，因为面试官正在寻找“HTTP 1.1 keep-alive”方法。 使用 HTTP 相当长一段时间并记住重点是“无状态”，这对我来说从来没有发生过（而且，更不用说保持活动状态并没有一致地实现）。
我的问题是，当设置“keep-alive”标头时，Web 服务器是否可以向客户端广播和/或发送信息？
Recently in an interview I was asked how I would approach an online chat client application. I went through the standard "polling" solution but was cut off because the interviewer was looking for the "HTTP 1.1 keep-alive" method. Having used HTTP for quite a while and remembering that the whole point was to be "stateless", this never occurred to me (also, not to mention that the keep-alive is not consistently implemented).
My question is, is it possible for a web server to broadcast and/or send information to a client when the "keep-alive" header has been set?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对于 HTTP 1.1，保持活动状态是默认行为。 （在 HTTP 1.0 中，默认行为是关闭连接。）服务器必须发送“Connection: close”标头来终止与第一个响应的连接。因此仍然有一个 TCP 套接字可用于推送数据，但只是从服务器推送数据会严重违反 HTTP 协议，即使使用 keepalive，客户端仍然必须轮询服务器，
区分 HTTP Keepalive 和 TCP Keepalive 会阻止连接。由服务器或客户端关闭。当连接可能长时间空闲并且可能被 NAT 代理或防火墙丢弃时，将使用 TCP keepalive。TCP keepalive 是通过调用 setsockopt() 在每个套接字上激活的。
当进行“长轮询”以消除重新轮询的需要时，可能需要 TCP keepalive。
With HTTP 1.1, keep-alive is the default behavior. (In HTTP 1.0, the default behavior was to close the connection.) The server must send the 'Connection: close" header to terminate the connection with the first response. So there is still a TCP socket available to push data through, but just pushing data from the server would violate the HTTP protocol in a major way. Even using keep-alive, the client would still have to poll the server.
It is important to distinguish between HTTP Keepalive and TCP Keepalive. HTTP keepalive prevents the connection from being closed by the server or client. TCP keepalive is used when the connection might be idle for an extended period of time and might be dropped by a NAT proxy or firewall. TCP keepalive is activated on a per-socket basis by setsockopt() calls.
When doing a 'long poll' to eliminate the need to re-poll, TCP keepalive might be needed.
Keep-alive 只是保持 TCP 套接字打开，因此每次轮询时，您都可以节省 TCP 设置/拆卸数据包的开销 - 但您仍然需要轮询。
然而，“长轮询”是Web服务器向客户端广播通知的一种策略。 本质上，客户端发出 GET 请求，但 Web 服务器不会立即响应，而是等到有通知要发送时才响应 GET 请求。 这消除了数据包通过线路进行轮询的任何需要，并保持连接无状态，正如您正确提到的那样，这是该协议的目的之一。
Keep-alive simply holds a TCP socket open, so each time you poll, you save the overhead of the TCP setup/teardown packets--but you still have to poll.
However, "long polling" is a strategy for the web server to broadcast notifications to the client. Essentially, the client issues a GET request, but instead of immediately responding, the web server waits until they have a notification to send, at which point they respond to the GET request. This eliminates any need for packets to go across the wire for polling purposes, and keeps the connection stateless, which as you correctly mention is one of the purposes of the protocol.
您可能会阅读有关 Comet 服务器的更多信息。 这听起来基本上就像面试官所询问的方法。 它们的有效性受到一些人的质疑，但它已被用于几种类似的情况。
例如，我相信 gmail 在某些方面使用了 comet 技术（但不要引用我的话）。
另一个似乎相关的例子是 BOSH，它是一种使用 HTTP 和 XMPP 传输聊天信息的协议。 但我不认为使用 keep-alive 涉及其中。
You might read more about Comet servers. That sounds basically like the approach that the interviewer was asking about. Their effectiveness is disputed by some, but it has been used in several similar situations.
For example, I believe gmail uses comet technologies for some things (but don't quote me on it).
Another example that seems relevant is BOSH, which is a protocol for transmitting chat information using HTTP and XMPP. But I don't believe that using keep-alive is involved in that.