1、课程导学与抓包基础：什么是抓包？为什么抓包能解决性能问题？
1.1 什么是抓包？说白了就是“偷看”网络对话
抓包，专业点叫“网络数据包捕获”。你想想看，两台机器在网络上通信，就像两个人打电话。你作为第三方，想偷听他们说了什么、怎么说的、中间有没有卡顿——这就是抓包。
我习惯用一个比喻：抓包就像在快递中转站装了个摄像头。你能看到每个包裹什么时候来、什么时候走、有没有破损、是不是绕了远路。网络里的数据包也一样，每个包都有源IP、目标IP、端口号、协议类型、时间戳……这些信息全都能被记录下来。
常用的工具有两个：Wireshark（图形界面，适合日常分析）和 Tcpdump（命令行，适合服务器环境）。它们底层都依赖 libpcap 库，原理就是让网卡进入“混杂模式”，把经过的所有数据包都复制一份给抓包程序。
核心概念：抓包不是“破解”，也不是“入侵”。它只是被动监听，不修改任何数据。你抓到的包，就是网络上真实传输的原始二进制流。
1.2 为什么抓包能解决性能问题？
我在项目中遇到过太多“玄学”问题了：用户说系统慢，开发说代码没问题，运维说服务器资源充足。谁也说不清到底卡在哪。这时候抓包就是最好的“照妖镜”。
抓包能帮你回答三个关键问题：
- 慢在哪？ 是 DNS 解析慢？TCP 握手慢？还是数据传输慢？
- 谁的问题？ 客户端发请求慢？服务器响应慢？还是中间网络丢包重传？
- 数据对不对？ 有没有请求参数错误？响应内容异常？协议版本不匹配？
举个例子。有一次线上接口响应时间从 50ms 飙升到 5s，开发查了三天没结果。我抓了 30 秒的包，一看 TCP 握手阶段就有大量重传——原来是防火墙把某些 SYN 包丢了，客户端一直在等 ACK，超时后才重试。说白了，问题根本不在应用层，在网络层。
我的经验：性能问题 70% 以上都能通过抓包找到根因。不是因为抓包万能，而是因为“网络”是连接所有组件的唯一通道。任何环节出问题，都会在网络上留下痕迹。
1.3 Wireshark 基础安装与抓包原理
安装
Wireshark 支持 Windows、macOS、Linux。安装时记得勾选“安装 WinPcap/Npcap”，这是底层驱动。Linux 下直接用包管理器：
# Ubuntu/Debian
sudo apt install wireshark
# CentOS/RHEL
sudo yum install wireshark
# macOS
brew install --cask wireshark安装后需要把当前用户加入 wireshark 组，否则没法抓包：
sudo usermod -aG wireshark $USER
# 然后重新登录抓包原理
Wireshark 的抓包流程其实就三步：
- 网卡进入混杂模式：默认网卡只接收发给自己的包。混杂模式下，所有经过的包都收。
- libpcap 捕获数据：从网卡驱动层复制原始帧，加上时间戳和长度信息。
- Wireshark 解析展示：把二进制数据按协议规范拆解成我们能看懂的字段。
嗯，这里要注意：抓包本身有性能开销。在高流量环境下（比如 10Gbps 链路），抓包工具可能会丢包。我建议用 Tcpdump 配合环形缓冲区来抓，或者用专门的硬件分流器。
避坑指南：我曾经在生产环境直接开 Wireshark 抓包，结果 CPU 飙到 90%，业务受影响。后来学乖了：生产环境用 Tcpdump 抓原始包，存成 pcap 文件，再拿到本地用 Wireshark 分析。记住，Wireshark 是分析工具，不是生产环境的抓包工具。
1.4 Tcpdump 基础安装与使用
安装
# 几乎所有的 Linux 都自带，没有的话：
sudo apt install tcpdump # Debian/Ubuntu
sudo yum install tcpdump # CentOS/RHEL常用命令
我平时最常用的几个 Tcpdump 命令：
| 场景 | 命令 |
|---|---|
| 抓所有包（默认 eth0） | sudo tcpdump -i eth0 |
| 抓指定端口的包 | sudo tcpdump -i eth0 port 80 |
| 抓指定主机的包 | sudo tcpdump -i eth0 host 192.168.1.1 |
| 抓并保存到文件 | sudo tcpdump -i eth0 -w capture.pcap |
| 读取 pcap 文件 | sudo tcpdump -r capture.pcap |
| 抓 HTTP 请求（80 端口） | sudo tcpdump -i eth0 port 80 -A |
你想想看，Tcpdump 的优势在哪？它轻量、稳定、不依赖图形界面。我经常在客户的服务器上远程 SSH 进去，用 Tcpdump 抓 30 秒，然后 scp 回本地分析。整个过程对业务几乎无影响。
小技巧：抓包时加上 -s 0 参数，表示抓取完整的数据包（默认只抓前 68 字节）。分析应用层协议（如 HTTP、MySQL）时，必须抓完整包，否则看不到请求内容。
1.5 抓包能解决哪些典型性能问题？
我整理了一个清单，都是我在项目中真实遇到过的：
- TCP 重传率高：网络丢包导致，表现为响应时间波动大。
- TCP 窗口太小：接收端处理慢，导致发送端被“限速”。
- DNS 解析慢：每次请求都要查 DNS，耗时几百毫秒。
- HTTP 队头阻塞：HTTP/1.1 的缺陷，一个请求慢拖慢所有请求。
- TLS 握手慢：证书链太长、密码套件协商慢、OCSP 验证超时。
- 应用层协议设计问题：比如频繁创建短连接、请求体过大、响应体未压缩。
这些问题的共同点是什么？光看日志和监控是看不出来的。 日志只记录业务逻辑，监控只显示宏观指标。只有抓包，才能看到每个数据包的“微观行为”。
1.6 本章知识体系
下面这张图总结了本章的核心逻辑：
1.7 本章小结
这一章我们聊了三件事：
- 抓包是什么：被动监听网络通信，记录每个数据包的细节。
- 为什么能解决性能问题：因为网络是系统的“神经系统”，任何问题都会在这里留下痕迹。
- 工具怎么用：Wireshark 适合分析，Tcpdump 适合生产环境抓取。