gpt4 book ai didi

tcp - 如何在 AWS 网络负载均衡器上保持 TCP 连接

转载 作者:行者123 更新时间:2023-12-05 02:59:03 24 4
gpt4 key购买 nike

架构:
我们有一堆物联网设备通过 AWS 网络负载均衡器 (NLB) 连接到我们的后端服务器。这是一个双向 channel (不是请求响应方式,而是从任何一方传递给另一方的消息)。

目标:
如何在不活动期间保持连接(NLB 的两侧)处于事件状态。

描述:客户端经常进入非事件模式并且不向(或从)服务器发送(或接收)任何东西。如果此状态持续时间超过 350 秒(NLB 的连接空闲超时值),LB 将静默终止连接。这很糟糕,因为我们到处都能看到很多 RST 数据包。

问题:

  1. 我知道 SO_KEEPALIVE 功能并且可以在我们的后端服务器上启用它。这使后端服务器和 NLB 之间的连接保持事件状态。但是客户呢? NLB 是否将 TCP 保活数据包转发给另一方? (Here 它说它没有)。如果没有,如何保持客户端连接打开? (此时此刻,我正在考虑发送一条空消息以保持连接。)
  2. 这种行为是 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/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com