微信号:dellemc_tech

介绍:为戴尔易安信客户提供技术支持服务,为广大IT行业用户分享技术文章与行业信息。

工欲善其事,必先利其器 – 网络抓包

2017-02-18 11:43 EMC中文技术社区

     其实抓包不是难事,很多人都会,下个Protocol Analyzer,比如Network Monitor、Wireshark,打开点记下就可以抓了。我主要有三个问题:

  1. 你为什么想都要抓包?你的问题是否能通过抓包获取答案?

  2. 在什么情况下抓包可以帮助你发现答案?

  3. 如潮水般涌入的网络包瞬间就能淹没Protocol Analyzer的Packet List,你要从何下手?


今天就简单来谈一下这几个问题

 

     抓包可使用的场景很多,排错、验证、测试、核对等等,我就举几个例子来说明吧。


Case I:客户在一台存储上启用了SNMP服务,随后想通过验证UDP161/162的侦听状态来确认服务是否确实启动了。


详情I:最简单的方式就是用进入存储的OS运行类似netstat –anop查看UDP端口状态,还有些同学会条件反射的说telnet一下呗。客户玩得比较高级,用一个叫做nmap的工具做端口扫描,发现扫描结果是Open | Filtered,这又算哪门子意思?除非找到这些工具的使用说明,否则无法明白其输出的意思。但有的时候就是没有太多参考文档,比如netstat显示的UDP端口状态列都是空的,没有任何状态,这代表什么呢?其实网络抓包可以帮助我们。你可以在telnet的同时抓包,结果会发现telnet发起了TCP SYN包,立刻就被对端给Reset掉了,所以用telnet的提议是错误的,用TCP去验证一个UDP端口是否在侦听,显然是南辕北辙了。同样,做nmap扫描的同时抓包,你会发现原来UDP使用ICMP返回消息来判断端口状态。如果端口关闭,那么对端会返回port unreachable,如果没有任何ICMP返回呢?那就说明中间存在包过滤逻辑,这也是为什么客户的nmap扫描显示open | filtered,nmap也无法确认端口状态,因为没有任何ICMP消息返回。所以,客户的扫描结果不能判断端口状态,必须采取其它手段。不过这不是这个case的重点,我们的重点是可以通过抓包看到应用程序的行为。


总结:判断端口状态的方式很多,但你是否采用了正确的方式,完全可以通过抓包来判断,它会告诉你一个应用程序的行为,帮助你发现原因。

 


Case II:客户发现应用程序与服务器之间的通信很慢。


详情II:为什么拿这个case来说,因为抓包和对TCP的分析在这个case里几乎就直接问题原因所在了。通过分析TCP分段,我们发现了traffic pattern的变化,延迟由正常的几个ms逐渐转变为了十几个ms,并在之后的流量中看到了Window Full以及最终的ZeroWindow消息。对TCP熟悉的同学立马能够判断出接收端存在处理能力的问题,导致无法及时清理TCP接收缓存,使得队列长度越来越长,根据Little Law和Utilization Law,响应时间会呈指数上升,这也为什么我们会观察到响应时间的变化。还有同学提问中间的交换机/路由器是否有可能发生这样的过载?当然是肯定的,但我们这个case里不是这个问题,为什么?因为我们抓包没有看到任何重传。


总结:抓包在这个case帮你排除了看起来最有可能是网络问题的问题,TCP的行为非常清晰的指出了问题所在。

 


Case III:Http下载失败


详情III:抓包下载过程,发现下载失败是因为TCP reset,但又是什么导致TCP reset呢?客户是一家web hosting网站,提供文件下载,他说这不是个案,有很多他们的客户抱怨说下载失败。因此我们初步会怀疑是服务器端的问题。在抓包后,我们发现数据传输开始是正常的,数据包长度都为1460bytes,而且客户端也在不时的Ack数据。直到某个数据没有被Ack,随后变发现了tcp reset。仔细观察后发现,没有被Ack的那个包的长度并非1460bytes,而其它所有数据包都是1460bytes。至此,虽然不能100%确认问题所在,但是你有理由让服务器端的应用开发人员做Application debugging,为什么服务器端应用程序会改变发包大小,当然对TCP来讲,这不是问题,比如TCP sender buffer就是只有这么点数据。但突然之间的大小变化,以及Ack的奇怪行为让我们有理由怀疑,服务器端程序的逻辑或许存在问题。


总结:在海量数据下,如何做到火眼晶晶找出数据包的不同是需要练习的。

 


Case IV:这并非是一个问题,还是要教会我们如何怀疑任何存在疑点的延迟。


详情 IV:理论上,你应该很清楚自己网络内所有的delay component,因为它们都是可以通过计算获得的。但有的时候,无法解释的延迟,就需要你理解协议和看包的能力。在这个case中,我们遇到的是TCP NagleDelayed-Ack算法之间的临时通信死锁问题。Nagle只允许一次发送一个小包(<MSS),除非收到Ack;而Delayed Ack要求至少收到两个包,否则不Ack;如此一来,两种就会较劲,直至Delayed-Ack timer超时,通常会有200ms的延迟。因此,在这种情况下,对延迟非常敏感的应用很容易超时报错,甚至crash。你完全可以抓包,而理解TCP行为和解释不正当的200ms延迟就是你的任务了。通常来说,在如今的一个健康的LAN内,不可能会有200ms网络延迟,一定是协议或应用本身的行为,而抓包给你机会去证明这一切。

 


Case V:NFS mount失败


详情V:这是我自己的一个case,我并不熟悉NFS,只是在测试VNX时,NFS mount失败。抓包后发现整个MOUNT过程涉及了RPC、port-mapper、NFS、MOUNT四种上层协议。于是我就下载了所有RFC扫了一遍,发现协议消息本身的数据结构和消息编号在RFC文档内都能找到。对于我见到的错误消息,找到对应的报错协议RFC并搜索该错误,立马就能找到对应的解释,原来是权限问题。到VNX上调了一下,问题就解决了。

总结:抓包可以帮住你揭示一些隐藏在上层协议下面的东西,你以为自己只是在做nfs mount,但其实涉及了不同的协议,任何一个出现问题,都会发生失败。抓包显示的错误消息,帮助你知道应该搜索哪个文档,哪个关键字,直指问题所在。这也有助于你学习新的协议。

 


最后,给到大家一些建议:

  • 网络包在大部分时候能够告诉你真相,所以用好它很有价值。

  • 网络包告诉你发生了什么,但不会告诉你为什么发生,理解协议行为和分析是你的任务。

  • 不要只看文档,尝试抓一下包,因为真相可能和文档是不同的。

  • 面对海量数据包,需要训练你的眼睛和大脑来过滤消息

  • TCP其实是老好人,不要总是责怪它。理解它,分析它,你会发现错误大部分时候是在别的地方。

  • 新一代数据中心网络十分复杂,用好工具,会帮你解决很多难题。



其它参考文章:

【存储入门必读】存储基础知识



更多精彩内容,请点击阅读原文”进行查看!

如何每天都能收到如此精彩的文章?

①点击右上角点击查看官方账号”→点击关注

②长按并识别下图中的二维码,直接访问EMC中文支持论坛


 
戴尔易安信技术支持 更多文章 公共、私有或混合:哪种云最适合 您的应用程序? 详解VxRail超融合产品的软硬件功能 EMC Unity启用压缩时的建议和最佳实践 VMAX全闪存集成CloudArray 【声音】叶成辉谈新常态下外资科技公司在中国的角色
猜您喜欢 西安Android第10期,毕业10天就业率52.54%,平均薪资6693 我所关注的Java问题 从 Java 应用部署方式看 IT 思潮——从开发和运维到开发自运维 可视化图表让机器学习“biu”的一样简单:特征分析 配置试用NativeScript开发Android、iOS原生应用