1. 抓包基础：什么是抓包、抓包的核心价值、常见抓包工具对比
大家好，我是老张。做网络排错这行十几年了，今天咱们聊聊抓包这件事。
很多人觉得抓包就是点一下Wireshark的开始按钮，然后看一堆花花绿绿的包。嗯，其实远不止这么简单。我见过不少运维同事，抓了一整天包，最后啥也没看出来——不是工具不行，是压根没搞懂抓包到底在干嘛。
1.1 什么是抓包
抓包，说白了就是把网线上跑的数据“截”下来看一眼。
你想想看，两台机器通信，数据在网络上是一段一段的二进制流。抓包工具就像在中间装了个“窃听器”，把经过网卡的数据包复制一份，然后解析成我们能看懂的样子——源IP、目标IP、端口号、协议类型、载荷内容……
举个例子。你在浏览器里打开百度，你的电脑和百度的服务器之间会交换几十个数据包。抓包工具能把它们全部记录下来，按时间顺序排好，每一层的协议头都拆开给你看。
核心要点：抓包不是“看数据”，而是“看数据怎么走的”。你关注的是通信过程，不是通信内容。
我记得刚入行那会儿，带我的师傅说了一句话，我一直记到现在：“网络出问题，90%的情况你不需要猜，抓个包就知道了。”
1.2 抓包的核心价值
抓包到底能解决什么问题？我总结了三类场景，几乎覆盖了日常排错的全部需求。
1.2.1 定位“连不上”的问题
客户端连不上服务器，原因太多了：DNS解析失败、TCP握手被防火墙拦截、服务端端口没开、SSL/TLS证书不匹配……
你靠猜？猜不出来的。抓个包看一眼三次握手的状态，马上就知道问题出在哪一环。
- 没收到SYN-ACK → 大概率是防火墙或路由问题
- 收到RST → 服务端端口没开或应用层拒绝
- 三次握手完成但马上断连 → 应用层协议协商失败
1.2.2 排查“慢”的问题
用户说“系统好慢”，你怎么办？查数据库慢查询？看CPU负载？这些当然要做，但别忘了——网络也可能是瓶颈。
我曾经帮一家电商公司排查过一个问题：他们的后台页面加载要30秒。开发查了三天代码没找到原因。我抓了个包，一看——TCP重传率高达15%。再往下查，发现是服务器网卡协商成了百兆半双工。换根网线，问题解决。
抓包能帮你看到：
- TCP重传率
- 窗口大小变化
- 应用层请求-响应间隔
- DNS解析耗时
1.2.3 验证“对不对”的问题
新系统上线，协议实现有没有bug？接口返回的数据格式对不对？加密通信有没有泄露明文？
这些靠日志不一定能看出来，但抓包一看就清清楚楚。我习惯在新系统上线前，先抓一轮包做“协议合规性检查”，能省掉后面很多麻烦。
我的习惯：每次上线新服务，我都会在测试环境抓一次完整的通信包，保存下来作为基线。以后出问题，拿基线包对比，差异一目了然。
1.3 常见抓包工具对比
工欲善其事，必先利其器。市面上抓包工具不少，但各有各的适用场景。我挑三个最常用的说说。
| 工具 | 平台 | 核心能力 | 适用场景 | 学习曲线 |
|---|---|---|---|---|
| Wireshark | Windows / macOS / Linux | 图形化、协议解析最全、过滤强大 | 日常排错、协议分析、教学 | 中等 |
| tcpdump | Linux / macOS | 命令行、轻量、可脚本化 | 服务器端抓包、自动化采集 | 较高 |
| Fiddler | Windows / macOS | HTTP/HTTPS代理、请求修改、断点调试 | Web开发、API调试、移动端抓包 | 较低 |
1.3.1 Wireshark——图形化抓包之王
Wireshark是我用得最多的工具，没有之一。它支持几百种协议的解码，过滤语法强大到可以写出“只显示源IP是192.168.1.1且TCP端口是443且数据包长度大于1000的包”这种条件。
它的界面分三块：
- 包列表区：显示每个包的概要信息（时间、源、目标、协议、长度、关键信息）
- 协议树区：选中一个包后，这里展示各层协议的详细字段
- 原始数据区：十六进制+ASCII的原始报文
我个人习惯用Wireshark做交互式分析。遇到复杂问题，我会一边抓包一边过滤，实时看数据变化。比如排查TCP重传，直接输入过滤表达式 tcp.analysis.retransmission，所有重传包瞬间高亮。
注意：Wireshark在流量大的环境下会消耗大量内存。我曾经在生产环境的数据库服务器上直接开Wireshark抓包，结果把服务器搞崩了……后来学乖了，生产环境只用tcpdump抓完再拿回本地分析。
1.3.2 tcpdump——服务器端的瑞士军刀
tcpdump是命令行工具，没有图形界面。但它的优势恰恰在这里——轻量、稳定、可脚本化。
你可以在任何Linux服务器上直接运行：
# 抓取eth0网卡上所有80端口的流量，保存到文件
tcpdump -i eth0 port 80 -w capture.pcap
# 读取文件，显示详细信息
tcpdump -r capture.pcap -nn -Xtcpdump的过滤语法和Wireshark基本一致，但更简洁。我经常在脚本里用它做自动化采集：
# 每5分钟抓一次包，持续30秒，用于监控
while true; do
tcpdump -i eth0 -G 30 -W 1 -w /data/capture_$(date +%Y%m%d%H%M).pcap
sleep 270
donetcpdump抓出来的pcap文件，可以直接用Wireshark打开分析。所以我的工作流通常是：服务器上用tcpdump抓，本地用Wireshark看。
1.3.3 Fiddler——HTTP/HTTPS调试利器
Fiddler和前面两个不太一样。它是个代理工具，专门针对HTTP/HTTPS协议。
它的核心能力是：
- 断点修改：请求发出去之前，你可以修改请求头、请求体，再放行
- 响应替换：把服务器的响应换成你指定的内容，方便测试前端容错
- HTTPS解密：安装Fiddler的根证书后，可以查看加密的HTTPS请求内容
我做Web开发调试时特别喜欢用Fiddler。比如前端说“接口返回数据不对”，我直接在Fiddler里把响应截下来，对比一下文档，马上知道是前端解析错了还是后端真的返回了错误数据。
一个小技巧：Fiddler可以配合手机使用。把手机的代理指向电脑的Fiddler端口，就能抓取手机App的HTTP/HTTPS流量。排查移动端接口问题的时候，这招特别好使。
1.4 本章知识体系总览
下面这张图，把本章的核心知识点串起来了。你可以把它当作一个“思维导图”，以后遇到网络问题，先想想该用哪个工具、从哪个角度入手。
这张图把本章内容分成了三块：什么是抓包、核心价值、工具对比。你以后遇到网络问题，先想想问题属于哪一类——是连不上、慢、还是不确定对不对？然后选对工具，抓包验证。
记住一句话：网络排错，抓包是第一步，也是最靠谱的一步。