2

我有客户端和服务器组件。服务器可能安装在防火墙或负载平衡器后面。许多站点/论坛建议使用 TCP 保持活动功能以避免由于不活动而导致连接终止。问题是来自客户端的保持活动消息是否真的会到达服务器？我尝试使用 tcptrace 实用程序模拟部署，发现保持活动消息没有到达服务器，但客户端仍然收到保持活动消息的 ACK。我不确定 LB/FW 是否以相同的方式工作。

在防火墙和负载均衡器的情况下，保持连接是否是避免连接终止的好选择？

4

1 回答 1

1

答案当然是：“视情况而定”。

许多防火墙和负载平衡器维护单独的前端和后端 TCP 连接，例如：

client <-- TCP --> firewall/balancer <-- TCP --> server

对于这种情况，使用 TCP keepalive不会像您期望的那样工作。为什么不？TCP keepalive 仅适用于该TCP 会话，并且 keepalive 探测数据包更像是承载数据的数据包的“管理开销”数据包。这意味着a)在客户端使用 TCP keepalive 仅意味着保持与防火墙/平衡器的 TCP 连接处于活动状态，并且b)防火墙/平衡器不会将这些 keepalive 探测数据包“转发”到后端连接。

那么使用 TCP keepalive 有用吗？是的。还有其他类型的代理在 OSI 堆栈的较低层工作，并且确实转发这些数据包。使用 TCP keepalive 有助于通过这些类型的网络中介保持空闲连接处于活动状态。

如果您的客户端/服务器应用程序通过防火墙/平衡器使用长期存在的、可能空闲的 TCP 连接，那么确保该连接不会被断开的最佳方法（有时是礼貌的，例如使用RST防火墙/平衡器发送的数据包，有时是静默) 是在应用层使用“ping”或“heartbeat”消息。（将其视为“应用程序保持活动”。）这只是从客户端发送到服务器的某种消息。一种简单而有效的技术是让客户端定期向服务器发送一些字节，服务器将这些字节回显给客户端。客户端知道它发送了哪些字节，并且当它从服务器接收到相同的字节时，

希望这可以帮助！

于 2016-02-20T06:52:59.287 回答