架构:
我们有一堆物联网设备通过 AWS 网络负载均衡器 (NLB) 连接到我们的后端服务器。
这是一个双向 channel (不是请求响应方式，而是从任何一方传递给另一方的消息)。
目标:
如何在不活动期间保持连接(NLB 的两侧)处于事件状态。
描述: 客户端经常进入非事件模式并且不向(或从)服务器发送(或接收)任何东西。如果此状态持续时间超过 350 秒(NLB 的连接空闲超时值)，LB 将静默终止连接。这很糟糕，因为我们到处都能看到很多 RST 数据包。
问题:
- 我知道
SO_KEEPALIVE功能并且可以在我们的后端服务器上启用它。这使后端服务器和 NLB 之间的连接保持事件状态。但是客户呢？ NLB 是否将 TCP 保活数据包转发给另一方？ (Here 它说它没有)。如果没有，如何保持客户端连接打开？ (此时此刻，我正在考虑发送一条空消息以保持连接。) - 这种行为是 AWS NLB 特有的，还是负载均衡器通常以这种方式工作？
最佳答案
AWS 文档说 NLB TCP 监听器能够通过 TCP 保活数据包保持连接:link
For TCP listeners, clients or targets can use TCP keepalive packets to reset the idle timeout.
根据我的测试，客户端正在接收服务器发送的 TCP 保持事件数据包并正确响应。 服务器不会中断连接，这意味着它会收到来自客户端的响应。 这意味着 NLB TCP 监听器实际上转发了保持事件的数据包。
基于相同的文档，NLB TLS 监听器不应对 TCP keep-alive 数据包做出相同的 react 。
TCP keepalive packets are not supported for TLS listeners.
但是当 Wireshark 显示在通过 TLS 监听器连接的客户端上接收到的保持事件数据包时，实际测试结果让我感到震惊。 我 2 个月前进行的先前测试结果与我现在的经历不符，我认为行为可能会改变。 (以前即使客户端意外不可用，服务器也会保持连接)
关于tcp - 如何在 AWS 网络负载均衡器上保持 TCP 连接，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/58322484/