在实际工作的过程中，服务程序每日开盘前需要依赖一下静态的文件进行初始化操作，类似版块文件、财务文件、除权文件等文件。由于下载工作比较简单，我们使用linux系统自带的wget，通过shell脚本的方式进行下载，脚本编写完成在测试过程中发现，随着下载频率的增加出现下载不成功的次数会增加，下载到的内容类似：
从上面的信息可以看到，等到的信息中有类似hs_cc_cookie，初步得出两个怀疑方向：
- 难道是异常使用cookie导致请求直接返回？
- 或者是请求被认为是CC攻击，安全设备直接返回了上面的上面的HTML内容？？
基于上面的怀疑我们开始问题的排查。
问题排查
1、对wget的请求增加参数
在请求中增加 -S参数，打印详细的响应头，正常下载：
错误下载：
然后对请求 增加–no-cookies 参数 ，不使用 cookies ，增加参数后结果一样，多次下载继续出现问题，关于cookies可能性排除，难道真的是安全设备的问题？涉及到跨部门协调，需要拿出证据，那么只能出最后的绝招–网络抓包 ，结果绝对公平公正，童叟无欺。
抓包分析
说到抓包，不得不说说TCP的建立连接的“三次握手”和断开连接的“四次挥手”。
如果觉得有必要回顾一下的同学可以先看看“附录一”，里面会有详细的接收。了然于胸的同学我们继续问题排查。
通过TCPDUMP （LINUX 网络抓包工具）抓取正常下载和异常下载的网络包进行对比分析。
正常下载：
下载异常：
下面我们对下载异常的网络包进行分析：
- 665号包说明服务器认为自己已经完成了服务请求，但客户端却没有主动关闭连接，于是在 20s 后只好主动将连接关闭。665号包显示 “TCP Previous segment not captured” 并且包中 “Seq=640” 而上一个 “Seq=1”我们确实有包没有抓到。
-
666号包客户端在收到 “Seq=640” 后认为自己收到了一个乱序包，因此试图通过 “TCP Dup ACK 663#1” 和 “Ack=1” 试图让服务器重传缺失的 639 字节。
-
667号包 出现 “TCP Out-Of-Order” ，产生该问题的原因一般：Packet 可能 Lost，所以重新传送造成。或存在Load Balance 之类的架构，晚送的封包却比早送的到达。
-
671 号包开始说明客户端由于某种原因还进行了多次针对 “FIN” 的==“TCP Spurious Retransmission”== 。
TCP Previous segment not captured的问题一般有以下几种情况，我们来一一排查。
服务器CPU或网络压力导致上述问题（服务器没有压力）
- 杀毒软件、恶意软件监测程序等导致问题（无此问题）。
-
交换机、路由器和防火墙等网络层问题。
排查到这里，基本可以判断问题是由于网络层相关问题导致，接下来我们从以下两个方向进行问题排查。
1、查看防火墙出口带宽，整个出口我有200M 现在看看只有50M的峰值，和出口带宽无关
2、查看防火墙关于CC攻击的配置发现开启了IPS防御以及防病毒配置，对于单IP的访问频次过高时，认为是攻击行为会产生丢弃操作，当出现错误请求时有如下报错信息：
3、调整防火墙配置关闭CC防护，问题解决：
通过以上的排查我们得出结论：wget在频繁被执行时触发了防火墙的CC攻击防护机制，导致请求被截断从而出现了文章开头的问题。
解决方案：
-
针对wget下载脚本:
在增加 中wget 时增加–limit-rate=2048k （限制下载速度为2M）参数，限制下载速度，并增长两次下载过程中的sleep 时间间隔。 -
针对防火墙：
适当调高防火墙CC防护的rps值，避免正常请求被防火墙作为CC攻击屏蔽。
