2. 网络协议基础：TCP/IP 协议栈、HTTP、DNS
做抓包分析，说白了就是跟协议打交道。你连协议都不熟，抓回来的包就是一堆乱码。我个人习惯把协议栈当成一张地图——抓包时你看到的数据，最终都要落到这张地图的某个位置。今天咱就聊聊这张地图怎么画，以及它跟读写性能到底有啥关系。
2.1 TCP/IP 协议栈：抓包的“分层地图”
你想想看，数据从一台机器到另一台机器，中间经历了多少环节？物理线路、网络路由、传输控制、应用解析……每一层各司其职。TCP/IP 模型把这套流程拆成四层，每一层负责不同的事。我刚开始做抓包时，总想一口气看完所有字段，结果把自己看晕了。后来经验告诉我——逐层拆解，才是正解。
下面这张图是我自己常用的分层分析框架。左边是四层模型，右边是各层对应的抓包关注点。建议你保存下来，实战时对照着看。
2.2 HTTP：应用层的老大哥
HTTP 是抓包分析里出现频率最高的协议，没有之一。你打开浏览器、刷 App、调接口，底层全是 HTTP 在跑。说白了，读写性能好不好，HTTP 的表现是最直接的窗口。
我在项目中遇到过不少情况：接口响应慢，研发第一反应就是「后端代码有问题」。结果我抓包一看，HTTP 请求发出后等了 1.2 秒才收到第一个字节——这明显是网络或对端处理延迟，跟代码逻辑关系不大。所以，学会看 HTTP 交互细节，能帮你精准甩锅……啊不，精准定位问题。
抓包时我重点关注几个字段：
- 请求行：方法（GET/POST）、URI、版本。版本直接决定了连接复用和头部压缩能力。
- 状态码：2xx 正常，3xx 重定向，4xx 客户端问题，5xx 服务端问题。遇到 502/504 基本就是后端或网关的锅。
- 头部（Headers）：Content-Length、Transfer-Encoding、Cache-Control、Connection。这些直接影响传输效率和缓存行为。
- Body：payload 大小和传输时间。如果 Body 很大但带宽有限，性能瓶颈就在这里。
从客户端发出请求到收到第一个字节的时间。我一般把 TTFB > 500ms 视为异常，需要排查网络延迟或服务端处理耗时。
2.3 DNS：第一公里的隐形延迟
很多人做性能分析会忽略 DNS。但你想过没有——用户在浏览器里敲一个地址，第一步不是发 HTTP 请求，而是先做 DNS 解析。如果这一步慢了，后面所有动作都得等。
我曾经参与过一个海外项目的性能优化。用户反馈打开页面特别慢，我们查了一圈，CDN、后端、数据库全都没问题。最后抓包才发现——DNS 解析耗时 3 秒多！原因是当地递归解析器配置不当，每次都要去根服务器查。后来换了本地的 DNS 服务，首屏加载时间直接降了 40%。DNS 这个「第一公里」的延迟，影响比你想象的大得多。
抓包分析 DNS 时，我建议关注这几点：
- 解析耗时：从 DNS 请求发出到收到响应的时间。正常应该在 10-50ms 内。
- 响应码：NOERROR 正常，NXDOMAIN 域名不存在，SERVFAIL 服务端故障。
- CNAME 链长度：每多一层 CNAME 就多一次递归查询，延迟会叠加。
- TTL 设置：太短会导致频繁解析，太长不利于域名迁移。一般建议 300-600 秒。
2.4 TCP：传输层的“交通警察”
TCP 负责保证数据可靠到达。它做了很多事：三次握手建立连接、确认重传保证不丢、滑动窗口控制流量、拥塞控制避免网络崩溃。每个机制都可能成为性能瓶颈。
我记得有一次排查一个写操作的性能问题。客户端每写一次数据，服务端要等很久才返回。抓包一看，TCP 握手是正常的，但每次写操作后都跟了一个 PSH+ACK 的等待——窗口太小了，对端要等缓冲区腾出空间才能继续收。这就是典型的TCP 窗口不足导致的吞吐量下降。
抓包时 TCP 相关的核心指标：
| 指标 | 含义 | 性能影响 |
|---|---|---|
| 三次握手耗时 | SYN → SYN+ACK → ACK | 每次新连接增加 1-2 RTT 延迟 |
| 重传率 | 重传包数 / 总包数 | > 2% 说明网络丢包严重 |
| 窗口大小（Window） | 接收端能接收的数据量 | 窗口小 → 吞吐低 → 读写慢 |
| 序列号 / ACK 号 | 数据排序与确认 | 异常的 ACK 可能表示乱序或丢包 |
2.5 网络层与链路层：基础设施的底牌
这两层离应用最远，但出了问题影响最大。网络层看 IP 和路由，链路层看以太网和帧。抓包时如果发现丢包或延迟异常，先排除这两层的问题。
我遇到过最典型的案例：某个服务的读写延迟偶尔飙升到 5 秒以上。应用层、传输层都查了，没问题。最后抓包看网络层——发现大量 ICMP 超时报文，说明中间某条链路发生了路由环路。这就是网络层的锅，跟应用代码半毛钱关系都没有。
链路层重点关注 MTU。如果 MTU 设置过大，会导致 IP 分片，分片丢失又会触发 TCP 重传，性能直接雪崩。嗯，这里要注意：以太网标准 MTU 是 1500 字节，别随便改。
2.6 一张表总结：协议层与性能的关联
我把各层协议和最直接的性能指标整理成了下表。抓包分析时，对着这张表逐层排查效率最高。
| 协议层 | 核心协议 | 直接影响的性能指标 | 抓包排查要点 |
|---|---|---|---|
| 应用层 | HTTP / DNS | TTFB、首屏时间、状态码 | 请求耗时、头部大小、解析延迟 |
| 传输层 | TCP / UDP | 连接建立时间、吞吐量、重传率 | 握手包、窗口大小、序列号 |
| 网络层 | IP / ICMP | 延迟、丢包率、路由跳数 | TTL 变化、ICMP 差错报文 |
| 链路层 | 以太网 / MAC | 带宽利用率、帧碰撞 | 帧间隔、MTU 分片 |
好了，协议基础就聊到这儿。下一章咱们进入实操环节——我会带你配置抓包环境，并演示怎么跑一次完整的抓包流程。到时候你带着今天讲的这张「地图」，会发现抓包其实没那么玄乎。
（嗯，注意：上面这句不要理解为预告下一章，只是课程的自然过渡。以下进入本章小结。）
回顾一下这章的核心：TCP/IP 协议栈是抓包分析的地图，每一层都有自己的协议和性能特征。HTTP 告诉你请求成不成功，DNS 影响第一公里的延迟，TCP 控制传输的可靠性和速度，网络层和链路层是底层的基石。抓包时逐层排查，才能又快又准地找到性能瓶颈。