美国运营商（或任何与此相关的运营商）的空闲 TCP 超时
据我了解，运营商会删除任何闲置几分钟的 TCP 连接。这就是为什么如果您想维持从客户端到后端的持久 TCP 连接，则必须双向发送 keep-alive。
我的问题是：保持活动间隔应该是多少？
From what I understand carriers remove any tcp connections that are idle for some number of minutes. This is why if you want to maintain a persistent tcp connection from your clients to your backend, you have to send keep-alive's both ways.
My question is: what should that keep-alive interval be?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
需要明确的是，除了端点之外，没有人可以删除 TCP 连接。这是因为 IP 网络协议是网络所看到的全部内容，并且它在设计上是无状态的。
然而，“终点”可能不是您所期望的。运营商可以在中间放置一个透明代理或带有 NAT 的路由器，此时它们确实需要保持状态以便正确转发数据。
NAT 是最大的问题，因为它更常见，如果路由器由于一段时间看不到流量而决定放弃连接状态，端点将永远不会知道，直到下次尝试发送数据时。
启用
SO_KEEPALIVE的默认值为 2 小时。因此，一个行为良好的路由器应该至少在那么长的时间内保持状态，但不要把赌注押在它上面。为了回答你的具体问题...如果是我，我会用 15 分钟或更短的时间。
请注意，只有一侧需要发送保持活动状态，因为它们通过重新发送数据流的最后 1 个字节来工作，就好像它在网络上丢失一样。接收方会丢弃它，因为它已经看到它，但会发送一个新的 ACK 进行回复，从而导致流量双向流动。
To be clear, nobody can remove a TCP connection except the end-points. That's because the IP network protocol is all that the network sees and it is stateless by design.
What makes an "end point" however may not be what you expect. A carrier can put a transparent proxy or a router with NAT in between at which point those do need to keep state in order to properly forward the data.
NAT is your biggest problem because it's more common and if the router decides to drop the state for a connection due to not seeing traffic for a while, and endpoint will never know until the next time it tries to send data.
Enabling
SO_KEEPALIVEhas a default value of 2 hours. A well behaved router should thus hold state for at least that long, but don't bet the farm on it.To answer your specific question... If it were me, I'd use 15 minutes or less.
Note that only one side need send the keep-alive as they work by re-sending the last 1 byte of the data stream as though it got lost on the network. The receiver discards it because it has already seen it but sends a new ACK in reply thus resulting in traffic going both directions.
只有损坏的 NAT 才需要执行此操作。 AIUI，一个明智的 NAT 可以在需要检查活动时向连接的两端发送 TCP keepalive，如果足够多的 TCP keepalive 无法引起响应，则断开连接。
唉，许多/大多数 NAT 都被破坏了。
FWIW，iOS 的“多任务处理”具有“voip”功能，如果您的套接字接收到数据，或者可选择以大约的时间间隔（例如保持活动），该功能将取消暂停您的应用程序；最小间隔约为 300 秒，因此 300-1200 秒之间的时间可能会起作用。
Only broken NATs will need to do this. AIUI, a sensible NAT can just send TCP keepalives to both ends of the connection when it needs to check for liveness, and drop the connection if enough of them fail to elicit a response.
Alas, many/most NATs are broken.
FWIW, iOS's "multitasking" has a "voip" feature which will un-suspend your app if your socket receives data, or optionally at approximate time intervals (for e.g. keepalives); the minimum interval is something like 300 seconds, so something between 300-1200 is probably going to work.
因为我不知道你保持连接的具体原因，即使显然没有任何通信流量，5 分钟曾经是与几个美国运营商的切断时间（其他运营商的时间更长） 。不过，您应该知道，他们可以随时更改此值，因此，如果您的应用程序希望将其作为其功能的一部分，那么如果您选择这样做，事情可能会变得有趣。
供参考 ...
As I do not know your particular reasons for why you are keeping a connection alive, even though there apparently isn't any comm traffic, 5 minutes used to be the cut off with a couple of the US based carriers (others have it longer). You should know that they can change this value at any point, though, thus if your application is counting on that as part of its functionality things could get interesting for you if the elect to do so.
FYI ...