所有的站点都是从小型站点逐步发展而来的，在此过程中，最大的挑战来自于大量的用户，安全环境恶劣，高并发访问，以及大量的数据，任何简单的业务处理，一旦需要处理数以P计的数据，以及面对上亿的用户，都会变得非常棘手。

当客户反馈其内部网络SLB业务流量较大时，一些固定的ECS客户端无法连接内部网络SLB。但同时，其他ECS客户端正常访问SLB；而问题ECS客户端直接访问SLB后端RealServer的业务也没问题。

部署架构相对简单。

内部网络ECS<->内部网络SLB<->内部网络后端RealServerECS。

用户使用脚本，使用nmap或nc每1秒访问一次平衡负载，尝试在释放之前建立TCP连接。

当脚本打印filter时，连接失败。从客户端抓取包来看，客户端发送的TCPSYN包没有得到SLB返回的SYN+ACK响应。

脚本如下:

#！/bin/bash

whiletrue；do。

nmap-Pn-p192.168.1.1|awk"\$1~/9999/{print\$2}"|grep"filter"

sleep1

done

注意：9999是TCP监控端口，192.168.1.1是VIP地址。

分析思路。

由于负载平衡访问链路过长，在处理负载平衡相关网络问题时，我们可以根据整个网络链路，结合问题现象和比较测试来确定问题的可能性。

一般来说，在客户端访问量大的情况下出现问题，我们会怀疑以下可能性:

云盾防护

客户端的一些访问行为是否触发了云盾的保护机制，导致访问失败。

跟踪分析：没有发现云盾截取日志中有相关记录，可以排除。

物理机械性能问题

过多的流量达到ECS网卡流量上限。

跟踪分析:检查发现ECS中的网卡流量不高，可以排除。

后端RS问题。

TCP核心参数配置不合理，导致TCP核心资源耗尽，如TimeWait数量过多，导致新连接无法建立，或后RS防火墙丢失指定源地址。

跟踪方案:检查/var/log/messages日志，检查sysctl.conf配置文件参数，检查防火墙配置，无疑问题。可以排除。

IDC中间链接。

中间交换机链路是否丢失了特定源IP和特定目的IP。

跟踪方案:网络团队检查链接报警日志，未发现可疑点。升级相关设备驱动到最新版本后，问题依然存在。可以排除。

负载平衡或NC物理机上相关模块的处理。

考虑到这个问题只发生在流量大的情况下，客户端访问RealServer没有丢包，只是访问负载平衡失败，但考虑到负载平衡集群为多个负载平衡实例提供服务，集群上的其他负载平衡实例正常工作。因此，我们怀疑NC物理机的处理是否有问题。