【问题标题】：How to keep TCP connections alive on AWS network loadbalancer如何在 AWS 网络负载均衡器上保持 TCP 连接处于活动状态
【发布时间】：2020-02-07 20:57:56
【问题描述】：
架构：
我们有一堆物联网设备通过 AWS 网络负载均衡器 (NLB) 连接到我们的后端服务器。
这是一个双向通道（不是请求响应样式，而是从任何一方传递到另一方的消息）。
目标：
如何在不活动期间保持连接（NLB 的双方）处于活动状态。
说明：
客户端经常进入非活动模式并且不向（或从）服务器发送（或接收）任何东西。如果此状态持续超过 350 秒（NLB 的连接空闲超时值），LB 会静默终止连接。这很糟糕，因为我们到处都能看到很多 RST 数据包。
问题：
- 我知道
SO_KEEPALIVE 功能并且可以在我们的后端服务器上启用它。这使后端服务器和 NLB 之间的连接保持活动状态。但是客户呢？ NLB 是否将 TCP keep-alive 数据包转发给另一方？ （Here 它说它没有）。如果没有，如何保持客户端连接打开？ （此刻，我正在考虑发送一条空消息以保持连接。）
- 这种行为是 AWS NLB 特有的，还是负载均衡器通常以这种方式工作？
【问题讨论】：
标签：
tcp
amazon-elb
aws-load-balancer
【解决方案1】：
不是答案，只是为了记录我的发现/所做的：
- NELB 不转发保持活动的数据包。这意味着您必须在服务器和客户端上启用它们。
- NELB 的超时时间无法更改。现在是 350 秒
- 我找不到任何方法来伪造一个空 TCP 数据包来欺骗 LB 将其转发到 LB 的另一端。
最后，我们在应用层实现了keep alive特性（周期性地向客户端发送一条空消息。）
【解决方案2】：
AWS 文档说 NLB TCP 侦听器能够通过 TCP 保持活动数据包保持连接活动：link
对于 TCP 侦听器，客户端或目标可以使用 TCP keepalive 数据包来重置空闲超时。
根据我的测试，客户端正在接收服务器发送的 TCP 保持活动数据包并正确响应。
服务器不会中断连接，这意味着它会收到来自客户端的响应。
这意味着 NLB TCP 侦听器实际上是转发 keep-alive 数据包。
基于相同的文档，NLB TLS 侦听器不应该对 TCP 保持活动数据包做出相同的反应。
TLS 侦听器不支持 TCP keepalive 数据包。
但是当 Wireshark 显示在通过 TLS 侦听器连接的客户端上接收到 keep-alive 数据包时，实际测试结果让我感到震惊。
我之前 2 个月前进行的测试结果与我现在所经历的不符，我认为行为可能会改变。
（以前，即使客户端以意外方式变得不可用，服务器也会保持连接）