未解决
此帖子已超过 5 年
2 Intern
•
1.4K 消息
0
4651
工欲善其事，必先利其器 – 网络抓包
工欲善其事，必先利其器 – 网络抓包
转载请在文首保留原文出处：EMC中文支持论坛https://community.emc.com/go/chinese
介绍
其实抓包不是难事，很多人都会，下个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只允许一次发送一个小包（ ），除非收到 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其实是老好人，不要总是责怪它。理解它，分析它，你会发现错误大部分时候是在别的地方。
- 新一代数据中心网络十分复杂，用好工具，会帮你解决很多难题。
参考
应用于
网络抓包分析