01 运维口水战

某天，突如其来的问题发生了，面向互联网用户的一套业务系统中的某台Web服务器出现的异常，CPU跑满了。大量的用户页面非常慢，有时甚至访问不了。对于运维人员来说，犹如晴天霹雳。

网络运维人员迅速检查到该服务器经过的各个网络设备的运行情况，网络设备都运行正常，到服务器的流量也不大。并且，同一区域的其它服务器运行也是正常的。网络运维人员初步结论：应该不是网络原因造成的，让应用运维人员检查一下软件运行情况吧。

与此同时，应用运维人员检查了程序的运行日志，程序也没有运行异常，只是发现程序在处理大量的tcp连接。应用运维人员让网络运维人员查一下，这些大量访问服务器的tcp连接是哪里过来的。

网络运维人员在负载均衡设备上查看了该服务器的并发tcp连接是挺大的，但是无法深入找出是哪些客户端发起的tcp连接。因为这个服务器是面向互联网的应用，网络运维人员初步判断，有可能是互联网的DDOS攻击导致的。现有的网络安全防护水平，还无法清洗这些DDOS流量。

最终，运维组之间陷入了僵局，业务系统处于异常状态已经快一天了。

02 神州灵云NetSensor登场

根据问题的症状，神州灵云技术顾问建议部署以下流量采集点。分别在互联网入口、负载均衡前后、防火墙前后以及服务器上联的位置同时进行流量采集。

图1：部署拓扑

部署说明：

抓包接口1：硬件探针的接口1是接入互联网流量到F5负载均衡设备入口的镜像流量，F5与互联网接入交换机直接是Trunk端口，可以通过Vlan ID区分出电信、联通、移动的流量。

抓包接口2：硬件探针的接口2是接入防火墙与互联网接入交换机的互联链路镜像流量。

抓包接口3：硬件探针的接口2是接入防火墙与核心接入交换机的互联链路镜像流量。

抓包接口4：硬件探针的接口4是接入关键数据库服务器的进行流量。

公网用户访问web应用交互逻辑：

公网用户访问58.xxx.224.12的80端口，F5做了源IP地址的转换。公网IP访问这个58.xxx.224.12时，F5将所有的会话转换为172.xxx.0.97去访问内网web服务器172.xxx.199.9

03 专家分析

流量与并发连接数对比分析：

对这个web应用，在F5前端和防火墙前端的抓包接口进行流量速率和并发连接数对比发现，互联网访问到这个web服务器经过F5前和防火墙前的流量分别是0.76Mbps和0.38Mbps。从流量上看，访问这台服务器的流量非常小，导致服务器CPU利用率100%应该不是流量因素造成的。

从F5前端和防火墙前端的并发连接数上看，互联网进来的并发连接数在10:31分时为54个，而在防火墙前端的并发连接数为22832个。同一应用的前后端抓包口的并发量相差巨大。进入“流量精分”进行深度分析。

深度分析：

查询10:06-11:06这一个小时，172.xxx.0.97访问172.xxx.199.9的tcp会话清单发现，172.xxx.0.97与172.xxx.199.9产生了64155条tcp会话，而这些TCP会话的总流量都是几KB。从tcp会话总流量上看，肯定不是一个正常的业务交互的流量范围。

选择一个tcp会话，进行解码分析发现，172.xxx.0.97与172.xxx.199.9的tcp会话只是建立了三次握手后中断了，没有数据交互。因此判断这些tcp会话应该是F5的健康检查数据包，但是这样高并发的健康检查肯定是一个异常的行为。

解决方法：

在F5上修改了对这台web服务器的健康检查策略后，问题解决。从发现问题到找出问题只花了5分钟。

04 优化建议

通过这次F5健康检查异常所发现的问题不单单是F5的健康检查机制的bug，最终导致的一个F5作为攻击源发起的TCP全连接攻击。这也是对web服务器的一个压力测试。通过数据包解码分析发现，F5向web服务器建立了tcp连接后，F5不传输任何应用数据包时，服务器是在将近10分钟内把这个会话Reset掉的。

Web服务器10分钟内的无应用数据交互的TCP会话断开时间太长了，需要做一下调优，尽量把这个超时时间缩短。

举报/反馈