HTTP-Long Polling 保持活动和握手答案

【问题标题】：HTTP-Long Polling keep-alive and handshakesHTTP-Long Polling 保持活动和握手
【发布时间】：2018-10-23 08:12:27
【问题描述】：

我正在做一项测试，检查与 Websocket 相比，HTTP 长轮询对 iPhone 电池性能的影响。基本上我所拥有的是一个带有快速服务器的 Node.js，它每 0.5 秒或 10 秒向 iPhone 发送一个随机字符串。我检查了 Chrome 中的消息，可以看到 keep-alive 标头存在。我知道 keep-alive 是自 HTTP/1.1 以来的默认功能。据我了解，TCP 连接将保持打开状态并可用于流水线，当我每 0.5 秒从服务器发送一次 ping 时肯定是这种情况。但是当我每 10 秒发送一次时，连接会在这段时间内关闭吗？

我如何知道连接打开了多长时间？这似乎是进行测试时要牢记的关键部分。
在 TCP 连接打开时是否仍会进行 HTTP 握手？

【问题讨论】：

标签： http long-polling keep-alive

【解决方案1】：

AFAIK，在 HTTP 1 中，如果客户端没有先发送请求，则服务器无法将响应发送回客户端。这听起来可能与您的问题无关，但请耐心等待。

Connection: keep-alive 标头告诉客户端它 can 如果他愿意重用连接，而不是 must。客户端可以随时决定关闭它，这完全取决于客户端库的实现，您没有任何保证。

强制客户端不关闭连接的唯一方法是不完成响应。做到这一点的唯一方法是发送带有Transfer-Encoding: chunked 的响应，并且永远不要发送最终块（这有一些严重的警告，例如客户端上的缓冲区溢出......）。

所以回答你的两点：

你不能，这个低级细节对客户完全隐藏（有充分的理由）。
没有 HTTP 握手，当客户端套接字连接到服务器套接字时会进行 TCP 握手。在 TCP 连接之后和发出任何请求之前进行 TLS 握手。连接打开后，客户端会发送 http 请求，服务器会以资源响应。

【讨论】：

感谢您的回复，但我如何才能确定长轮询机制是否利用了开放的 TCP 连接？我需要知道这一点，因为我相信这会对性能产生很大影响。是否仅取决于我如何在服务器和客户端上实现长轮询？
我发现node中创建的HTTP-server的标准超时时间是2分钟。我想这意味着我的长轮询请求将使用在第一个请求期间打开的 TCP 连接。
是的，这取决于您如何实现长轮询请求。从理论上讲，打开的 idle 连接对服务器的影响应该很小。 Node 使用 libUV，而 libUV 在内部使用 epoll/k-queue 轻松处理 10K+ 并发连接。