未加星标

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

字体大小 | |
[大数据技术 所属分类 大数据技术 | 发布者 店小二04 | 时间 | 作者 红领巾 ] 0人收藏点击收藏

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

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

Case V:NFS mount失败

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

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

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

网络包在大部分时候能够告诉你真相,所以用好它很有价值。 网络包告诉你发生了什么,但不会告诉你为什么发生,理解协议行为和分析是你的任务。 不要只看文档,尝试抓一下包,因为真相可能和文档是不同的。 面对海量数据包,需要训练你的眼睛和大脑来过滤消息 TCP其实是老好人,不要总是责怪它。理解它,分析它,你会发现错误大部分时候是在别的地方。 新一代数据中心网络十分复杂,用好工具,会帮你解决很多难题。

End.



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

转载请注明来自36大数据(36dsj.com):36大数据 工欲善其事,必先利其器 – 网络抓包

tags: 抓包,TCP,case,端口,Case,Ack,延迟,发现,telnet,ack,UDP,nmap,NFS
分页:12
转载请注明
本文标题:工欲善其事,必先利其器 – 网络抓包
本站链接:http://www.codesec.net/view/427673.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 大数据技术 | 评论(0) | 阅读(228)