网络协议梳理实战：从抓包到TCP/HTTP排障

上周有人发来一个 pcap 文件，说他们的服务每隔 30 秒就断一次连接，日志里只有一行干巴巴的 timeout。我打开抓包文件翻了两屏就看到了问题：客户端发出的 SYN 一直没等到回包，但目标端口在同一台机器上是通的——中间隔了一层安全组，只放行了半个方向的流量。这件事的根子不在代码，而在于他们对这条链路上的协议行为没有一张完整的图。

网络协议梳理这四个字听起来像是教科书目录，实际上它是排查一切网络问题的前置工作。它要做的事很简单：把一条请求从发出到落地经过的每一层、每一个头部字段、每一次握手、每一个超时都摊开，形成一张能对照着看的图。适合谁看？写过 socket 但被粘包折磨过的后端、调过接口但说不清 keep-alive 什么时候断的前端、被 DNS 缓存坑过的运维，以及所有在抓包软件里看到一堆十六进制就发懵的人。下面我把这套梳理方法按我实际的顺序摊开讲，不含背概念的部分。

1. 协议梳理的起点不是 OSI 七层，而是你想回答的问题

很多人一上来就开始画七层模型，画完发现对解决问题毫无帮助。原因在于 OSI 是教学模型，实际协议栈是四层甚至更扁，而且真正决定行为的不是"分几层"，而是"这条链路上有哪些参与方、每一步的约定是什么"。所以我做梳理时从来不从模型出发，从问题出发。

1.1 三个不同的问题，对应三种完全不同的梳理深度

我一般把梳理需求分成三档，深度差得很远，混着做会浪费大量时间。

第一档是连通性梳理，回答"能不能通"。这时候只需要关心：DNS 能不能解析出地址、目标端口有没有监听、中间有没有设备拦截、路由是否可达。对应到协议就是 IP 层和传输层的端口，抓包看 SYN 有没有回 SYN-ACK 就够了，应用层一个字都不用看。

第二档是行为梳理，回答"通的时候数据长什么样"。这时候要往下钻到应用层：请求头有哪些、响应码什么含义、连接是复用还是每次新建、超时是谁定的。绝大多数线上问题落在这一档，比如接口偶发 502、长连接莫名断开、上传大文件卡在 99%。

第三档是性能梳理，回答"为什么慢"。这一档最费劲，要同时看传输层的窗口和重传、应用层的并发模型、以及 TLS 握手的往返次数。我见过最典型的一个例子：接口 P99 从 80ms 涨到 400ms，代码一行没改，最后定位到是服务端把 TCP_NODELAY 关了，小包被 Nagle 算法攒着发，每次都多等一个 ACK。

动手前先明确自己在哪一档，能省掉至少一半工作量。

1.2 把"协议"还原成两段代码之间的约定，抽象感立刻消失

协议这个词被讲得太玄。剥掉包装，它就是两段代码约定好的字节格式和交互顺序。举个例子，HTTP 请求的第一行永远是方法 路径 版本，用空格分隔，用\r\n结尾，后面跟头部，再一个空行，再跟 body。这不是什么高深设计，就是双方约定"我按这个格式写，你也按这个格式读"。

一旦用这个视角看，梳理就变成了三件具体的事：

• 格式：字段有哪些、各占多少字节、字节序是大端还是小端、变长字段怎么定界。
• 顺序：谁先说话、说几句、什么情况下可以插话、什么情况下必须等回复。
• 异常：对方不按约定来怎么办、超时多久算失败、失败之后是重试还是断开。

任何协议你都能用这三条拆开。我梳理一个私有协议时习惯先把它写成一张字段表，标明偏移、长度、含义，写不出来就说明还没看懂。这个方法看起来很笨，但比读十遍文档管用。

1.3 梳理之前先画一张"参与方地图"，别漏掉中间那几跳

新手最容易犯的错是只盯着客户端和服务端两个点。实际链路上通常还有：DNS 服务器、负载均衡、反向代理、网关、CDN 节点、数据库连接池。每一个都可能改写协议行为。

举几个真实会踩的例子。反向代理默认会在头部加X-Forwarded-For，但如果它配置了不透传，后端拿到的就是代理的 IP。负载均衡如果工作在四层，它不看 HTTP 内容，Connection: close传过去也没用；工作在七层则可能自己维护连接池，客户端看到的"长连接"其实是两段拼接的。CDN 节点缓存了 301 响应，你改了源站配置但用户端还是跳旧地址。

所以梳理的第一步动作我一直是：画出这条请求经过的所有节点，标出每个节点工作在 OSI 的哪一层。四层设备只认 IP 和端口，七层设备会解析应用层内容，这个区分决定了它能改什么、不能改什么。

2. 一包数据从应用到网卡：每层加了什么，为什么必须加

这一节讲的是数据形态。不理解封装，抓包时看到的就是一堆无意义的十六进制。理解了封装，你甚至能靠偏移量直接读出字段。

2.1 逐层封装：每个头部解决一个特定问题

应用层数据往下走，每经过一层就被套上一个头部。以一次 HTTP GET 为例，完整的一帧大概长这样（以太网环境）：

每一层只解决一个问题，这是分层的核心价值。以太网头只管"这一跳怎么走"，IP 头只管"最终送到哪台机器"，TCP 只管"字节流按序可靠送达"。我经常用快递类比：以太网头是同一栋楼内保安指路，IP 头是快递单上的收件地址，TCP 头是签收单和物流跟踪，应用层就是箱子里的东西。

有个细节值得单独说：IP 头里的协议号字段。6 表示 TCP，17 表示 UDP，1 表示 ICMP。抓包时看到一个包既不像 TCP 也不像 UDP，先看这个字段，很多"神秘流量"就是 ICMP 或某种隧道协议。

2.2 MTU、MSS 与分片：这里算错一次就要排查一整天

这是我认为最容易翻车的地方。以太网默认MTU 是 1500 字节，指的是一个以太网帧能承载的最大数据部分（不含 14 字节帧头）。也就是说 IP 包最大 1500 字节。

IP 头 20 字节，TCP 头 20 字节，那么 TCP 能承载的数据最大是1500 - 20 - 20 = 1460 字节，这个数叫MSS。如果是 UDP，头只有 8 字节，上限是1472 字节。

问题来了：如果应用层一次写了 3000 字节交给 TCP 会怎样？答案是不会分片，TCP 是字节流协议，它会把这 3000 字节切成若干个不超过 MSS 的段发出去，对端收到后再拼起来。这就是"粘包"的根源之一，后面细讲。

但如果是 UDP 写了 3000 字节，IP 层就必须分片，切成两个包各带一个 IP 头，标志位里标记"还有更多分片"，偏移量标明位置。分片的坑在于：

• 只要任意一个分片丢失，整个 UDP 数据报就废了，因为 IP 层没有重传。
• 中间某些设备会直接丢弃分片（尤其是首片之外的），导致一个 2000 字节的包永远发不出去。
• 分片后的包在各层看到的长度信息会不一致，抓包分析时容易误判。

我在一个跨机房的项目里踩过：MTU 是 1500，但中间一条隧道链路实际只能过 1400，超过就静默丢弃。表现是小的请求全正常，稍大一点的 POST 永远超时，日志里没有任何报错。最后是靠ping -M do -s 1472逐级探测才找到边界。这个排查方式的原理是：-s指定数据长度，-M do禁止分片，能通说明这条路径能承载这个尺寸。

2.3 校验和与序列号：两个被严重低估的字段

校验和存在于 IP 头和 TCP/UDP 头里。IP 头校验和只覆盖头部本身，TCP 的校验和覆盖整个段（含伪头部）。它的作用是发现比特错误——线路抖动、内存出错都可能导致某一位翻转。注意这不是安全机制，只防意外不防篡改。抓包里如果看到 checksum 错误，先别急着下结论，绝大多数情况是网卡做了校验和卸载（checksum offload），抓包抓到的是还没算完的包。这个误判太常见，我第一次看的时候还以为链路有问题，查了半天。

序列号是 TCP 的灵魂。它不表示"第几个包"，而是第几个字节。初始序列号（ISN）是随机选的，之后每发 N 字节数据，序列号就加 N。这个设计直接导致了：

• 确认号 ACK = 期望收到的下一个字节序号，是累积确认，不是逐个确认。
• 丢包后接收方一直回同一个 ACK，发送方收到三个重复 ACK 就触发快速重传。
• 序列号回绕的问题在高速链路上真实存在，所以有 PAWS 和时间戳选项。

我梳理 TCP 时最先看的就是序列号曲线，它能一眼看出重传、乱序、窗口阻塞。这块后面抓包那节会展开。

3. TCP 的可靠性不是免费的：握手、窗口、重传的真实代价

TCP 常被当成"可靠的"，好像开了它就万事大吉。实际上可靠性是拿延迟和状态换来的，每一份可靠性都有明确的价格。

3.1 三次握手与四次挥手：状态机才是重点

握手过程人人会背：客户端 SYN，服务端 SYN-ACK，客户端 ACK。但真正有用的是背后的状态机，因为它解释了所有"连接异常"的现象。

两个最容易被忽略的点。第一，SYN 队列是有限的。服务端收到 SYN 后会把连接放入半连接队列，如果队列满了，新的 SYN 会被丢弃，客户端看到的就是"连接超时"。这个现象在高并发短连接场景下非常典型，表现为压测时随机失败，日志里连一条记录都没有。第二，TIME_WAIT不是 bug 是设计，它保证最后一个 ACK 能重发、保证旧连接的迷路包不会污染新连接。端口耗尽时想优化，正确做法是调整tcp_tw_reuse或改成长连接，而不是简单粗暴地缩短超时。

3.2 滑动窗口与拥塞控制：吞吐量的天花板在哪

TCP 的吞吐量有一个非常直观的公式：

吞吐量 ≈ 窗口大小 / RTT

举个例子，窗口 64KB，RTT 100ms，那理论最大吞吐就是 64KB / 0.1s ≈ 640KB/s，大约 5Mbps。就算你的带宽是千兆，也只能跑这么点。这就是为什么跨地域传输大文件会慢得离谱——不是带宽不够，是窗口和延迟的乘积限制住了。

窗口字段在 TCP 头里只有 16 位，最大 65535 字节。为了突破这个限制，有窗口缩放因子选项，可以把窗口扩大到 2^14 倍。协商在握手阶段完成，双方各报一个自己的缩放值。如果中间有设备不认这个选项，把它剥掉了，窗口就退回到 64KB，长肥管道上的性能会断崖式下跌。这类问题在抓包里能看到：同一个连接，SYN 里有 Window Scale 选项，SYN-ACK 里却没有。

拥塞控制则是另一层，它决定"网络能承受多快"。慢启动阶段每个 RTT 窗口翻倍，到达慢启动阈值后进入拥塞避免，线性增长；遇到丢包就减半。常见的算法有 Reno、Cubic、BBR。BBR 不看丢包看带宽和延迟，在有一定丢包率的链路上表现明显更好。梳理时如果发现"带宽没用满但延迟很高"，先确认用的是哪个算法。

3.3 粘包与拆包：这不是 TCP 的缺陷，是字节流语义的必然结果

"TCP 粘包"这个说法本身有误导性。TCP 根本没有"包"的概念，它是字节流，只在内存里维护一个连续的字节序列。你写三次 100 字节，对端可能一次读到 300 字节，也可能分十次每次 30 字节，这是完全合法的。

真正的问题在于应用层假设了消息边界。要解决它，必须在应用层自己定义边界，常见方案三种：

• 长度前缀：报文头里固定位置放一个长度字段，先读 4 字节拿到长度，再读对应字节数。这是最通用、最高效的做法，私有协议基本都用它。
• 分隔符：用特定字符（如\r\n）标记结束。HTTP 的头部、Redis 的 RESP 协议都是这个思路。缺点是数据里不能出现分隔符，出现了要转义，解析时要处理跨缓冲区的情况。
• 固定长度：每个报文长度固定，简单但要浪费空间或限制消息大小。

写解码器时有个坑必须处理：不完整的数据要留在缓冲区里，等下一批数据到达再拼接。我见过太多实现是"读一次解析一次"，本地测试没问题，一上生产网络抖动就出错。正确的做法是维护一个可增长的缓冲区，循环尝试解析，直到数据不够就 break 退出，等下一次读取。

4. UDP、QUIC 与自建可靠传输的取舍

讨论协议选型时，总有人问"TCP 和 UDP 该用哪个"，这个问题问得太粗。真正该问的是"我的业务能容忍丢包吗、需要多低的延迟、是否需要多路复用"。

4.1 UDP 适合什么，不适合什么

UDP 头只有 8 字节，没有握手、没有确认、没有重传、没有拥塞控制。它是一个"尽力而为"的投递服务。适合它的场景有几个明确特征：

• 对延迟敏感，对完整性不敏感：音视频实时通话，丢一帧画面用户感知不到，但卡顿半秒就很明显。
• 一问一答且可重试：DNS 查询，超时了重新发一次就行，没必要维护连接状态。
• 一对多广播：服务发现、局域网广播，TCP 根本做不了。
• 自己做可靠性更划算：比如游戏里的状态同步，只需要最新的位置，历史数据丢了就丢了，用 TCP 反而会因为重传旧数据阻塞新数据。

不适合的场景也很明确：文件传输、支付交易、任何"少一个字节都不行"的业务。用 UDP 传文件，你得自己把 TCP 那套全部重新实现一遍，而且大概率做得更差。

4.2 在 UDP 上重建可靠性，四个模块缺一不可

如果业务确实需要 UDP 的灵活性，又要一定的可靠性，那就要自己造轮子。我这个模块梳理下来，有四块是绕不开的。

第一块是序列号与确认机制。每个包带一个递增的序号，接收方回 ACK 告诉发送方收到了哪些。这里推荐用位图而不是单个 ACK，因为乱序很常见，单一累积确认会造成不必要的重传。

第二块是重传策略。超时重传的 RTO 不能写死，要基于 RTT 采样动态计算。更高效的做法是冗余重传——不等超时，直接把上一包再发一遍，代价是带宽，收益是延迟。实时音视频普遍用这个思路。

第三块是拥塞控制。不做的话，一旦网络出现拥塞，你的 UDP 流量会把别人挤死，也会把自己挤死。至少要有一个类似"加性增乘性减"或者基于带宽估计的控制器。

第四块是连接标识。TCP 用四元组标识连接，UDP 没有，所以要自己在应用层放一个 connection ID。这不是可选项，因为它决定了 NAT 重绑定之后连接还能不能恢复。

现成的方案是 QUIC，它在 UDP 之上把上述问题都解了，还顺带做了 0-RTT 建连和多路复用，避免了 TCP 的队头阻塞。这里的关键区别值得记住：TCP 的队头阻塞发生在传输层，一个包丢了，后面所有字节流都得等；QUIC 的流之间是独立的，一个流丢了只影响那个流。HTTP/3 就建在 QUIC 上。

4.3 协议选型对照表

我在做技术方案评审时经常被要求给个直接结论，所以整理过一张表：

选型的原则我一直是：默认选 TCP，明确知道 UDP 能带来什么收益时才切换。为了一点理论上的延迟优势去维护一套自建可靠传输，长期成本通常远超预期。

5. 抓包是把梳理结果变成事实的唯一途径

文档写十遍不如抓一次包。这一节是全篇最实用的部分，我按实际操作顺序讲。

5.1 抓包点的位置决定了你能看到什么

这一点是很多人忽略的。同一个请求，在客户端抓和在服务端抓，看到的可能完全不同。

• 在客户端本机抓：能看到应用发出的原始数据，但如果是走本地回环，网卡上可能抓不到，需要抓lo接口。
• 在服务端抓：能看到最终到达的请求，但看不到中间代理加了什么头、改了什么路径。
• 在中间设备抓：能看到两端协商的全过程，但如果是加密流量，只能看到握手和长度。

最理想的做法是两端同时抓包，用时间戳对齐。我排查复杂问题时基本都会要求对方提供两端的 pcap，然后在分析工具里按时间排序，一眼就能看出延迟发生在哪一段。

另外一个实操细节：容器环境下，默认在宿主机抓不到容器内的流量，需要进入容器的网络命名空间，或者直接抓 veth 对。这个如果不知道，会浪费大量时间以为"流量没发出来"。

5.2 常用命令与过滤器写法

命令行我一般用 tcpdump，轻量且几乎所有 Linux 环境都有。

# 抓指定网卡、指定主机的 443 端口，不解析域名和端口名，完整包长，存文件 tcpdump -i eth0 -nn -s 0 -w capture.pcap 'host 10.0.0.5 and tcp port 443' # 只抓 SYN 包，用于看谁在发起连接、有没有回 tcpdump -i any -nn 'tcp[tcpflags] & tcp-syn != 0' # 抓 RST，用于排查连接被谁重置 tcpdump -i any -nn 'tcp[tcpflags] & tcp-rst != 0' # 抓 DNS 查询，看看解析请求发给了谁、有没有响应 tcpdump -i any -nn 'udp port 53' # 抓 ICMP，排查网络不可达、MTU 问题 tcpdump -i any -nn 'icmp'

过滤器语法有几条经验值得记：

• -s 0一定要加，否则默认只抓 96 字节，应用层内容全被截断，看不了 HTTP 头和 TLS 证书。
• -nn关闭名称解析，避免抓包时因为 DNS 反查拖慢速度、产生额外流量。
• 表达式里andornot的优先级容易出错，复杂条件用括号包起来。
• 用-w写文件而不是直接打印，因为终端打印会丢包，尤其是高流量场景。

如果想按内容过滤，tcpdump 支持偏移量匹配，比如找 HTTP GET：

tcpdump -i any -nn -s 0 -A 'tcp port 80 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420'

这串的含义是：先取出 TCP 头第 12 字节的高 4 位，乘以 4 得到头部长度，再从这个偏移开始取 4 字节，和 "GET " 的十六进制比较。写起来不直观，但比抓到几十万包再手工翻要高效得多。

5.3 逐帧解读一次完整请求

下面是我梳理一个连接问题时的标准读法。假设已经抓到一个完整的 pcap，按顺序看这几帧：

第 1 帧：客户端 SYN。看源端口、目的端口、初始序列号、MSS 选项、窗口缩放因子、是否有 SACK_PERM。这些选项决定后面所有行为。如果 MSS 被改成很小的值（比如 536），往往说明中间有设备在干预。

第 2 帧：服务端 SYN-ACK。看它回的 MSS 和窗口缩放，最终生效的是双方各自上报的值中较小的那个。如果这一帧的响应时间明显偏大（超过几十毫秒），说明服务端处理慢或者中间跳数多。

第 3 帧：客户端 ACK。到这里连接建立完成。从第 1 帧到第 3 帧的时间差就是建连耗时，这个数在移动网络下可能到几百毫秒，是接口延迟的大头。

后续数据帧。重点看三个量：序列号是否连续（有跳跃说明丢包或乱序）、ACK 是否及时推进（长时间同一个 ACK 说明卡住了）、窗口是否持续缩小（缩小到 0 说明接收方处理不过来，触发了零窗口）。

最后 FIN 或 RST。RST 出现的位置很关键：建连阶段就 RST，通常是端口没监听或被防火墙拒绝；数据传输中 RST，可能是应用层主动关闭、可能是中间设备的会话超时、也可能是收到了无法解析的数据。

这套读法练熟之后，一个连接的问题基本能在五分钟内定性。

5.4 五个高频误判，每一个我都踩过

误判一：看到 checksum 错误就以为链路有问题。如前所述，网卡的校验和卸载会让抓包工具算出错的校验和。判断方法：如果只有出方向的包 checksum 错，入方向正常，基本就是卸载导致的，可以忽略。

误判二：看到 RST 就以为是对端拒绝。RST 可能是任何一方发的，也可能是中间设备伪造的。要看 RST 的序列号和 ACK 号是否在当前连接窗口内，如果完全对不上，多半是中间设备发的。

误判三：把重传当成丢包。有时抓包工具会在同一位置看到两个一样的包，其实是抓包点重复捕获（比如同时抓了 eth0 和 lo），不是真的重传。判断方法看 IP ID 和捕获接口。

误判四：认为没有 SYN 就没有请求。如果两端已经建立了长连接，后续请求根本不需要 SYN。很多"请求没发出去"的结论其实是错怪了网络，问题在应用层压根没调用发送。

误判五：把延迟归因于网络。抓包看到请求发出到响应回来隔了 2 秒，不代表网络慢。这 2 秒可能是服务端在查数据库，网络只占了 5ms。要精确判断，必须两端同时抓包，对比"请求到达服务端的时刻"和"响应离开服务端的时刻"。

6. 应用层协议梳理：DNS、HTTP、TLS 的依赖链

传输层通了不代表请求能成。实际业务里，用户的每一次点击背后都串着三个应用层协议，任何一个环节出问题表现都是"页面打不开"。

6.1 DNS 解析链路与超时叠加

一个域名解析出 IP，实际可能经过：浏览器缓存 → 系统缓存 → hosts 文件 → 本地 DNS 服务器 → 递归查询根、顶级域、权威服务器。每一层都有缓存，每一层也都有超时。

梳理时我关注几个数：TTL决定缓存多久，改解析后多久生效全靠它；超时时间决定最坏情况等多久，本地 DNS 通常 5 秒超时，重试两次就是 15 秒；解析结果数量，返回多个 IP 时客户端怎么选，是先连第一个还是轮询，这个行为直接影响故障转移效果。

常见的坑是 DNS 解析慢导致的接口超时。表现是首次访问特别慢，后续就正常。原因是本地没有缓存，每次都走完整解析链路。解决办法是在应用启动时预热，或者用长连接复用。

还有一个隐蔽的问题：DNS 的 UDP 包超过 512 字节会被截断，此时会回一个 TC 标志让客户端改用 TCP 重查。如果中间设备挡了 DNS 的 TCP 53 端口，解析就会失败。这种现象只在对记录特别多的域名上出现，非常难查。

6.2 HTTP 各版本对连接复用的影响

HTTP/1.0 每个请求新建一个连接，用完就关。HTTP/1.1 默认开启 keep-alive，一个连接串行处理多个请求，但同一时刻只能有一个请求在途，前一个响应没回来，后面的必须等。这就是浏览器为什么要对一个域名开 6 个并发连接——不是设计得不好，是被协议限制的。

HTTP/2 引入了多路复用，一个 TCP 连接上可以并发跑多个流，每个流有自己的 ID，互不阻塞。但它仍然建在 TCP 上，所以一旦底层丢包，所有流都被队头阻塞卡住。HTTP/3 换成 QUIC 才真正解决了这个问题。

梳理接口性能时我非常关注这几个头部：

Keep-Alive不一致这个坑很典型：客户端配 60 秒空闲超时，服务端配 5 秒，那么连接空闲 10 秒后客户端认为还能用，发出去就撞上服务端已经关掉的连接。表现是偶发失败，重试就成功。解决办法是让客户端的空闲超时小于服务端的。

6.3 TLS 握手在抓包里长什么样

加密流量看不到内容，但握手过程是明文，信息量非常大。TLS 1.2 完整握手需要 2 个 RTT，TLS 1.3 优化到 1 个 RTT，会话恢复可以做到 0 RTT。

抓包里依次能看到：

1. Client Hello：客户端支持的版本、加密套件列表、SNI（目标域名）、随机数。如果 SNI 为空，很多服务器会拒绝或返回错误证书。
2. Server Hello：选定的版本和套件、随机数。
3. Certificate：服务端证书链，这里能直接看到证书有效期、颁发者、SAN 列表。排查"证书过期"问题看这一帧最快。
4. Client Key Exchange / Finished 等：密钥协商和验证。

几个实战要点。握手耗时是可以量化的：从 Client Hello 到 Client Finished 的时间差，就是 TLS 建连成本。移动网络下这个值可能到 300ms 以上，是首屏慢的主要原因之一。会话复用能把这个成本降到接近零，判断方法是看 Server Hello 之后是否还有完整的 Certificate 帧——如果没有，说明走了恢复流程。证书链不完整是另一个高频问题，服务端只发了叶子证书没发中间证书，部分客户端能自动补全，部分不能，表现是"某些用户的 App 打不开，某些正常"。

7. 把梳理结论沉淀成团队能用的东西

梳理做完如果只留在自己脑子里，价值衰减得极快。我习惯每次梳理都产出两份东西。

7.1 一份协议清单模板

我用的模板大概长这样，字段不多但都必要：

填这张表的过程本身就是一次梳理，很多模糊的地方一填就暴露了。

7.2 一份排错速查表

按现象查原因，比按原理推导快得多：

7.3 文档的维护节奏比内容本身更重要

我见过太多梳理文档写完就没人看，三个月后彻底失效。有效的做法是把梳理结果绑到变更流程上：新增一个对外接口、更换一次网关、调整一次超时配置，都顺手更新对应的协议清单。文档不必写成长篇，一张字段表加一张时序说明，够用就行。

最后分享一个我自己一直在用的习惯。每次遇到网络问题，不管最后查出来是不是网络的原因，我都会把抓包文件留一份，按"日期 + 现象"命名存起来。半年下来积累了二十几个样本，再遇到类似现象时直接翻旧文件对照，比从头查快得多。协议梳理这件事，本质上就是把一次次踩坑的经验，沉淀成一张随时能查的地图。