抓包（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其实是老好人，不要总是责怪它。理解它，分析它，你会发现错误大部分时候是在别的地方。
- 新一代数据中心网络十分复杂，用好工具，会帮你解决很多难题。