SLB 设备健康检查，三次握手后直接发送 RST 包断开连接，合理吗？

我也同样纠结过，之前的 socket 有缺陷，平常正常使用好好的，放在 slb 之下就容易健康检查搞死。
不过我修复缺陷之后就没啥问题了，再没纠结这个

Rst 按照协议没有关闭，这种只能是超时关闭了。

FIN 关闭需要考虑后续状态，RST 不需要。负载均衡依赖连接状态工作，因此必定有连接表。健康检查的连接频率很高，FIN 会留下大量僵尸连接。

health check 的方式不同，对应的也不同，总的来说还是你的程序不够健壮。
TCP half open 类型的 monitor，只要收到一次确认，证明端口正常就直接没了

如果连这都处理不好，那你的服务敢放在外网？

如果正常 close，有成本在里面。这个还是去修改链接池实现吧，忽略掉 reset

对客户端断开连接表示担忧
这听起来很像美团外卖早期的一个 sb 程序员

客户端能不能处理 RST 报文，跟 SLB 是不是应该发 RST 是两个问题，很多基础 lib 会对收到 RST 打印日志。
客户端断开连接，跟客户端发送 RST，也是两个问题。

SLB 发 RST 你可以抱怨，如果搞 ddos 的给你发 RST，你找谁抱怨去？

如果认为收到 RST 时打印日志是个问题，那就关掉 RST 的日志

对付 ddos，当然是前面挂防火墙。为啥要用血肉之躯对抗呢，关了 RST 日志，就能抗住 DDOS 了吗。

nmap 扫描端口 TCP 类型的原理也是这样，这个我觉得没毛病，