基于 JVM 的 longpoll/comet 客户端：路由器杀死空闲连接答案

【问题标题】：JVM-based longpoll/comet client: routers killing idle connections基于 JVM 的 longpoll/comet 客户端：路由器杀死空闲连接
【发布时间】：2011-11-06 08:39:07
【问题描述】：

我目前有一个基于 JVM 的网络客户端，它使用标准 java.net.HttpURLConnection 执行 HTTP 长轮询（又名彗星）请求。我为连接设置了非常高的超时时间（1 小时）。对于大多数用户来说，它工作正常。但是有些用户没有收到服务器发来的数据，最终在1小时后超时。

我的理论是（NAT）路由器超时并丢弃它们的连接，因为它们在服务器发送任何数据之前空闲时间过长。

那么我的问题是：

我可以为 java.net.HttpURLConnection 使用的连接启用 TCP keep-alive 吗？我找不到这样做的方法。

我应该使用不同的 API（不同于 HttpURLConnection）吗？

其他解决方案？

【问题讨论】：

标签： java comet httpurlconnection long-polling keep-alive

【解决方案1】：

java.net.HttpURLConnection 处理Keep-Alive header transparently，可以控制，默认为on。但是你的问题不在Keep-Alive，这是一个更高级别的标志，表示服务器应该在处理完第一个请求后关闭连接，而是等待下一个。

在您的情况下，OSI 堆栈的较低级别可能会中断连接。因为长时间保持一个打开但空闲的 TCP 连接从来都不是一个好的选择（具有两个打开连接的 FTP 协议：一个用于命令，一个用于数据有相同的问题），我宁愿实现某种断开连接/在客户端重试故障安全程序。

事实上，安全限制可能只是几分钟，而不是几小时。只需每 60 秒或 5 分钟主动断开与 HTTP 服务器的连接。应该做的伎俩。

【讨论】：

我的意思是 TCP keep-alive，而不是 HTTP keep-alive。服务器通常会在 5 到 15 分钟内做出响应。只有少数用户有问题——我的理论是他们的路由器更积极地杀死空闲连接。你是对的，这将有助于降低超时。但如果可能的话，我更愿意在 20-30 分钟的超时时间内完成这项工作。
java.net.HttpURLConnection 仅支持 HTTP1.1，这意味着默认情况下连接是持久的（不需要 Keep Alive）
TCP keep-alive 不适用于持久的 HTTP 连接。它使您的计算机定期发送没有任何 TCP 流数据的数据包，因此空闲连接会获得一些流量。我认为这可以防止路由器终止连接。

【解决方案2】：

似乎没有办法为 HttpURLConnection 开启 TCP keep-alive。

当 4.2 版支持 TCP 保持活动时，Apache HttpComponents 将成为一个选项。

【讨论】：