我对负载均衡器处理 TCP 连接有疑问。
我的负载均衡器后面有三台服务器，有时由于某些处理任务，服务器和客户端之间没有发送任何数据，空闲 5 分钟后连接将被断开，因为服务器已发送 RST 标志（对等方重置连接）。我想知道负载均衡器是否对此负责，所以我使用 WireShark 捕获带有 RST 标志的 TCP 数据包，它捕获了这样的数据包。
我的问题是，如果负载均衡器负责重置连接，我是否会在服务器端看不到 RST 数据包，因为它是由 LB 发送的，并且源 IP 已更改？或者我错了，即使 LB 正在发送 RST 数据包，是否仍然可以在服务器端捕获它？
编辑1
我想缩小（或者可能增强）我的问题。如果客户端和服务器之间发送带有 RST 的数据包，它应该在客户端和服务器上都可见，还是仅在其中一个服务器上可见（例如客户端）？
编辑2
我在客户端和服务器端捕获了带有 RST 标志的数据包，奇怪的是，在客户端，它看起来像是 LB 服务器发送的数据包，而在服务器端，它看起来像是客户端发送的数据包（通过源/目标 IP）
答案1
据我所知，这是您对网络主题（包括 OSI 层和通信方法）的误解。
简要回答您的主要问题，我应该说您的 LoadBalancer 的处理方式完全取决于您的配置以及您定义/希望它如何处理。但为了向您展示 LoadBalancing 在 OSI 模型的第 4 层和第 7 层中的实际工作方式，请阅读以下信息：
首先，关于 RST 数据包，您应该注意，您提到的情况非常常见，因为 RST 用于重置连接，并且可能在双方发生，具体取决于无法完成的操作以及在连接尚未结束时服务器和客户端之间不再发生对话的情况。摘自Quora, 当服务器拒绝连接或不可用时，在三次握手过程中发送 RST 数据包，或者当服务器或客户端变得不可用或拒绝进一步通信而没有正式的四向 TCP 连接终止过程时，在数据传输过程中发送 RST 数据包。
传输控制协议 (TCP)运作于运输层（OSI 模型中的第 4 层）。TCP 提供可靠、有序且经过错误检查的八位字节流传输，并在通过 IP 网络进行通信的主机上运行的应用程序之间建立虚拟连接。换句话说，它在应用程序和 Internet 协议之间提供中间级别的通信服务，并且由于 IP 数据包可能会丢失、损坏或无序到达，因此 TCP 具有纠正这些错误的机制，将 IP 数据包流转换为可靠的通信通道。每个应用程序都分配有一个唯一的 TCP 端口号，以便在运行许多应用程序的主机上将数据包传输到正确的应用程序。例如，已分配标准 TCP 端口 22 用于联系 SSH 服务器 - 如果需要，可以在配置文件中更改默认端口。
在第 4 层负载平衡负载均衡器的 IP 地址会向网站或服务的客户端公布。因此，正如可能已经猜到的那样，客户端请求中记录的目标地址将是 LoadBalancer 的地址。当第 4 层负载均衡器收到请求并做出负载平衡决策后，它还会对请求数据包执行网络地址转换 (NAT)，将记录的目标 IP 地址从其自身更改为其在内部网络上选择的内容服务器的地址。例如，在您的场景中，您的 LoadBalancer 会将其自身地址更改为向客户端提供请求服务所需的地址，为了更明确，让我们假设 LoadBalancer 后面的三台服务器之一用作您的存储服务器，而客户端愿意阅读 PDF 或您网站上的任何内容。客户端的目标地址设置为分配给您的 LoadBalancer 的公共 IP 地址，当您的 LoadBalancer 收到请求时，它将根据您在 LoadBalancer 中设置和配置的规则决定将请求映射到哪个服务器（在内部网络中使用它自己的）。同样，在将服务器响应转发给客户端之前，负载均衡器会将数据包头中记录的源地址从内部服务器的 IP 地址（例如您的存储）更改为其自己的地址。 （数据包中记录的目标和源 TCP 端口号有时也会以类似的方式更改。）然后，它根据从 TCP 流中的前几个数据包中提取的地址信息做出路由决策，而不检查数据包内容。
回答“如果负载均衡器负责重置连接，我是否不会在服务器端看到 RST 数据包，因为它是由 LB 发送的，并且源 IP 已更改？”，我应该说，如果需要使用 LoadBalancer 重置其他服务器的连接，而不是客户端与 LoadBalancer 的连接，您才会在其他服务器上看到 RST 数据包。
顺便说一句，我强烈建议您在内部服务器上使用 tcpdump 来查看您是否可以接收来自 LoadBalancer 的请求，这样您就可以看到哪里出了问题，并找到解决问题的方法。不要因为使用 WireShark 而感到困惑，它是一款出色的工具，但您应该足够熟悉它才能理解它向您显示的内容。