通过Tcpdump抓包 Wireshark分析 找出Wget文件下载失败的原因

有运维或运维开发方面的需求,可以联系博主QQ 452336092或Email:admin#centos.bz(收费)

文章目录
[隐藏]

在实际工作的过程中,服务程序每日开盘前需要依赖一下静态的文件进行初始化操作,类似版块文件、财务文件、除权文件等文件。由于下载工作比较简单,我们使用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攻击屏蔽。

原文出处:hundsun -> http://rdc.hundsun.com/portal/article/766.html

打赏

如果此文对你有所帮助,请随意打赏鼓励作者^_^