各种客户端/目标/elb 重置计数指标（TCP_Client_Reset_Count、TCP_Target_Reset_Count、TCP_ELB_Reset_Count）的文档只是说它们计算 RST 数据包。我试图了解什么是 RST 数据包，它似乎与断开的 TCP 连接有关。我的负载均衡器有一个单一的、长期的、看似成功的客户端连接。为什么我看到每小时有 100 次客户端重置？我还看到每小时大约 10 次负载均衡器重置，以及 0 次目标重置。
编辑：我刚刚观察到增加服务器实例的大小（我正在使用 Farscape——将 vCPU 增加 0.25 到 0.5）导致每小时客户端重置次数减少 10 倍。负载均衡器重置的次数没有改变。
【问题讨论】：
标签： amazon-web-services amazon-elb
负载平衡器重置计数可能较高的原因之一是网络负载平衡器具有理想的超时值，即 350 秒。因此，如果您的 TCP 连接在超时之前没有得到任何确认，负载均衡器将强制关闭连接。
【讨论】：
我的预感是，这与网络负载均衡器中的一个错误有关，该错误导致它发送 100 倍于它应该发送的健康检查。请参阅：NLB Target Group health checks are out of control 我的理论是，如果目标实例不够快，错误会导致运行状况检查连接以不干净的方式中断。这些损坏的运行状况检查连接会被报告为“客户端重置”，即使它们应该报告为“ELB 重置”或根本不报告。
【讨论】：
发送 TCP RST 的原因有很多。有些是不正常的，意味着错误，有些是 TCP/IP 堆栈或应用程序执行的正常连接清理。
正常 TCP RST 的一个示例是一个长期连接，该连接超过了一方或另一方施加的某个时间限制。一旦超过时间限制，可以“强制”关闭连接，这将生成 RST。
一个不正常的 TCP RST 示例是应用程序由于内部错误而突然断开连接。
如果应用程序在关闭连接之前未对 TCP 套接字执行正常关闭，那么编写不佳的应用程序也会导致 TCP RST。
我猜你看到的行为不是问题。但是，要真正了解，您需要对每个连接进行线路跟踪和协议分析，以确定到底发生了什么。
【讨论】：
TCP_Client_Reset_Count 是“从客户端发送到目标的重置 (RST) 数据包的总数。”这可能是垃圾邮件流量吗？但我猜想到达 ELB 死端口的垃圾邮件连接会指向 TCP_ELB_Reset_Count，“负载均衡器生成的重置 (RST) 数据包总数。”