首页 > 代码库 > 工欲善其事,必先利其器 – 网络抓包

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

抓包(packet capture)就是将网络传输发送与接收的数据包进行截获、分析,甚至可以用来转发,重传等等,抓包可使用的场景很多,排错、验证、测试、核对等,我就举几个例子来说明吧。


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


详情:最简单的方式就是用进入存储的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消息返回。所以,nmap的扫描结果不能判断端口状态,必须采取其它手段。不过这不是这个场景的重点,我们的重点是可以通过抓包看到应用程序的行为。

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


场景二、发现应用程序与服务器之间的通信很慢。


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

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


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


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

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

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

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

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

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

本文出自 “刘洪亮的博客” 博客,请务必保留此出处http://liuhongliang.blog.51cto.com/2895201/1916052

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