TCP/IP协议栈数据格式详解：从以太网帧到TCP/UDP报文

聊到TCP/IP，可能很多人的第一反应是大学课本里那张分层模型图。但真正让我把这套东西刻进脑子里的，不是考试，而是有一次线上服务出现诡异超时，抓包抓到手软，最后发现是TCP重传和接收窗口的博弈问题。从那时候起我就明白，背下七层架构、记住端口号没什么用，协议栈每一层的字节是怎么排布的、每个bit是什么意思、报文在网线上到底长什么样，这才是排障和调优的核心功底。

这篇东西不打算讲太虚的，直接以数据格式和字段说明为主线，配合典型的抓包例子，把以太网帧、IP报文、TCP段、UDP数据报这些结构从头到尾过一遍。适合刚入门想系统搞清楚协议细节的同学，也适合工作中经常要用Wireshark排查网络问题的开发、运维和测试朋友。看完之后你再打开抓包工具，看到的就不是杂乱十六进制流，而是一段段有逻辑、有意义的结构。

1. 分层模型与数据封装过程的底层逻辑

1.1 为什么必须分层：每一层都在解决一类独立问题

TCP/IP模型把网络通信拆成四层或五层，实际工程中我更习惯按五层模型来理解：应用层、传输层、网络层、数据链路层、物理层。每一层解决的是一类独立问题，这种分层设计不是学院派的纸上谈兵，而是真实工程演进的结果。

物理层解决的是比特怎么在线路上传输，用多高的电压、什么频率、怎么同步时钟；链路层解决的是同一网段内设备之间怎么找到彼此，靠的是MAC地址；网络层解决的是跨网段的路由寻址，核心设备是路由器，核心协议是IP；传输层解决的是端到端的可靠性、流量控制和多路复用，让多个应用程序能同时跑在同一台机器的网络上；应用层则是千奇百怪的协议，HTTP、DNS、FTP、SMTP，各自定义自己的语义。

这套设计的妙处在于职责隔离。比如应用层想加一个新协议，完全不必关心底层是走以太网还是WIFI，是光纤还是同轴电缆。我在实际项目里最深的体会是：分层让网络栈变成了一个高度可替换的流水线，每一层只对上下层暴露固定接口。你在浏览器里输入一个网址，根本不需要知道此刻数据是走WIFI还是5G，TCP不会因为物理介质变化而改变自己的字段结构。

1.2 数据封装全过程：从HTTP请求到比特流的加工流水线

我习惯用一个具体场景来理解数据封装：访问一个网站。整个加工流程是这样的：

应用层产生一个HTTP请求，这个请求在应用层眼里就是一个完整的文档，有请求行、请求头、请求体。传到传输层时，TCP把它当成一段连续的字节流，并不关心它是不是HTTP报文。TCP做的事是给这段数据前面加一个TCP首部，里面写上源端口、目的端口、序列号、校验和等字段，这段数据加首部后的结果叫TCP段。

网络层拿到TCP段后，再在前面加一个IP首部，写上源IP、目的IP、TTL、协议号等字段，变成了IP数据报。需要注意的是，如果数据报超过链路层的MTU，网络层还要负责分片，这是一块经常出问题的地方，后面会细讲。

链路层拿到IP数据报后，在前面加以太网帧头，后面加帧校验尾，封装成以太网帧。物理层最后把这个帧的每一个字节变成光信号或电信号发出去。接收方做完全相反的动作：物理层收比特，链路层去掉帧头和帧尾还原出IP数据报，网络层去掉IP头还原出TCP段，传输层去掉TCP头还原出应用数据。

所以“数据在TCP/IP模型中传输的过程图”画出来，就是数据在垂直方向和水平方向的两次旅行：垂直方向是一层层打包和拆包，水平方向是在每一层的对等实体之间逻辑通信。这个概念读懂了，后面所有字段的意义就都能串起来了。我见过不少同事拿着Wireshark抓包文件一头雾水，其实就是没有建立“当前看到的是哪一层”的意识，只要脑子里时刻想着“我现在看的这个报文，是站在哪一层视角上的”，分析就会清晰很多。

2. 链路层：以太网帧格式与每个字段的真实用途

2.1 以太网帧完整结构：从前导码到FCS

以太网帧是所有有线网络里最常见的数据帧格式。很多人以为帧就是从目的MAC开始的，其实在真正的线路上，帧头前面还有物理层的东西。一个完整的以太网帧在网线上的实际结构是：

• 前导码（Preamble）：7个字节，内容是0x55的循环，也就是10101010的交替序列。作用是用来让接收方时钟同步，这个阶段不是帧的一部分，抓包工具不会显示。
• 帧起始定界符（SFD）：1个字节，0xD5，标志着帧数据正式开始。
• 目的MAC地址：6个字节。
• 源MAC地址：6个字节。
• 类型/长度字段：2个字节。
• 数据载荷：46到1500个字节。
• 帧校验序列（FCS）：4个字节，CRC32校验值。

抓包软件里展示的以太网部分是直接从目的MAC开始的，前导码和SFD已经被网卡剥离了，FCS也通常在网卡校验通过后被丢弃，所以你在Wireshark里看到的帧长度往往比线上实际传输的字节数小8个字节。

2.2 类型字段到底是干什么的：它决定了上层用哪个协议栈

MAC地址字段大家比较熟悉，但类型字段（EtherType）经常被忽略。这2个字节本身很简单，但它承载的信息很关键：它告诉接收方，这个帧的数据载荷应该交给哪个上层协议处理。

常见取值有：

这个字段的存在让一个以太网接口可以同时承载多种网络层协议。比如交换机在转发帧时，如果看到0x8100就知道要处理VLAN标签；网卡驱动收到0x0806的帧，就知道这是一个ARP请求或应答，需要交给内核的ARP模块处理，而不是交给IP模块。

我在野抓包时经常通过这个字段快速过滤报文，比如只关心ARP就抓ethertype 0x0806，只关心IPv6就抓0x86dd。别小看这个过滤技巧，在排查“二层广播风暴”或“莫名流量占用”时，它能帮你迅速定位以太网帧里跑的都是什么协议。

2.3 ARP报文格式：链路层和网络层之间的桥

ARP协议在网络层之下又和IP强相关，它负责把IP地址解析成MAC地址。ARP报文格式（以以太网+IPv4场景为例）最关键的是头部固定8个字节再加上4组地址字段：

• 硬件类型：2字节，以太网为1。
• 协议类型：2字节，IPv4为0x0800。
• 硬件地址长度：1字节，MAC地址为6。
• 协议地址长度：1字节，IPv4地址为4。
• 操作码：2字节，1表示ARP请求，2表示ARP应答。
• 发送方MAC：6字节。
• 发送方IP：4字节。
• 目标MAC：6字节，请求时为全0。
• 目标IP：4字节。

一个容易混淆的细节是：ARP请求的目标MAC填的是全0，因为这个时候还不知道对方是谁，全0的含义是“这个字段当前无效”。另外，ARP报文不需要经过IP层，它是直接封装在以太网帧里的，类型字段就是0x0806。所以你抓包的时候可以看到三层结构：以太网帧头、ARP报文、帧尾，根本没有IP头。

排查网络故障时ARP缓存的问题很常见。比如ARP表项老化异常、网关IP被伪造、ARP泛洪攻击。我曾经遇到过一台主机间歇性丢包，抓包发现局域网里同时有多个设备在响应同一个IP的ARP请求，典型IP冲突。这种问题如果不懂ARP报文格式，光看应用层永远找不到原因。

3. 网络层：IPv4数据报格式逐字段拆解

3.1 IPv4首部结构：20字节固定部分的使用频率差异

IPv4数据报格式是网络层最核心的内容。标准IPv4首部固定部分20字节，不含选项。我建议把每个字段按“排障时用得频率”来分个优先级，比按顺序死记硬背高效得多。

版本号占4位，值固定为4，代表IPv4；如果不为4可能是抓包抓到了IPv6报文，这类报文不会进入IPv4处理流程。首部长度IHL占4位，单位是4字节，所以最小值是5，也就是20字节；如果看到值是6或7，说明带有选项字段，这时候IP首部就不是20字节而是24或28字节。

服务类型TOS占1字节，在现代网络中这个字段主要是DSCP和ECN两部分：前6位是DSCP（差分服务代码点），用于QoS标记；后2位是ECN（显式拥塞通知），用于避免拥塞。抓包时很少看TOS，但在排查语音视频卡顿、配置QoS策略时这个字段很重要。

总长度占16位，指的是整个IP数据报的总字节数，包括首部和数据，最大65535字节。实际因为链路层MTU限制，一般不会这么大。排障时比较关键的是把IP首部里的总长度和链路层帧长度对比，能发现是否被填充或截断。

标识、标志、片偏移这三个字段是分片相关的，也是初学者最头晕的地方。标识是16位的ID，同一个原始数据报分出来的所有分片共享同一个标识值。标志3位中第一位保留，DF位为1表示禁止分片，MF位为1表示后面还有分片。片偏移占13位，以8字节为单位，表示该分片在原始数据报中的位置。

TTL占8位，每经过一个路由器减1，减到0路由器就把报文丢弃，并通常回送一个ICMP超时报文。这个字段排障时极其有用，Traceroute的原理就是利用TTL的逐跳递减。协议字段占8位，标识上层协议：1是ICMP，2是IGMP，6是TCP，17是UDP。首部校验和占16位，只校验IP首部不校验数据部分，因为数据部分由TCP或UDP自己校验。

源IP和目的IP各占32位。这里有个注意点：IP首部里的地址是最终通信双方的真实地址吗？在一般场景是，但在NAT环境下，源地址可能已经被路由器改写了。排查时看到抓包文件的IP和实际主机对不上，优先怀疑NAT。

3.2 IP分片的触发条件和重组逻辑：常见的巨包与MTU问题

分片是一个隐蔽的故障点。以太网MTU是1500字节，默认不加VLAN标签，如果一个IP数据报超过1500字节，发送主机可能选择先分片再发送。分片后每个分片都是一个完整的IP数据报，有自己的IP首部，用标识、标志、片偏移三个字段关联。

我踩过的最典型一个坑是：某业务跨机房传大文件，偶尔出现慢和失败。抓包一看，TCP层一直正常，但IP层出现了大量分片，而且部分分片丢失。原因是中间有个设备设置了比较小的MTU，而发送主机开启了PMTUD路径MTU发现，本该通过ICMP告知“需要分片但DF置位无法发送”，结果中间的防火墙把ICMP过滤了，于是TCP连接就陷入了“黑洞”。这就是著名的PMTUD黑洞问题。

排查思路很简单，用带DF标志的大包去ping目标地址，观察回包情况：

• 如果包太大无法发送，路由器会回ICMP type 3 code 4的“分片需要但DF已置位”报文，说明路径MTU小于当前包长。
• 如果ping直接超时，可能就是ICMP被丢弃，需要改用其他方式猜测MTU，比如二分法试包长。

分片重组是在接收端完成的，而且是按标识和源IP、目的IP、协议等五元组（或更多元组）归类的。如果分片长时间到不齐，接收端会丢弃已收到的分片，并可能触发ICMP重组超时报文。大数据传输场景里，我一般会建议把TCP的MSS调小，比如设置为1400，让TCP段的长度加上IP首部不超过MTU，从根本上避免IP分片。要知道IP分片本身损耗非常大，任何一个分片丢了整个数据报都得重来，TCP又只能重发整个数据段。

3.3 IPv6首部的简化思路：对比中理解IPv4的设计

IPv6的首要变化就是固定首部变大为40字节，但字段数量反而精简了。没有首部校验和，没有分片相关字段在基础首部里（分片改为扩展头），没有IHL因为固定40字节。

IPv6基础首部字段包括：

• 版本：4位，固定为6。
• 流量类别：8位，类似IPv4的TOS。
• 流标签：20位，用于标记需要相同处理方式的报文流。
• 载荷长度：16位，表示IPv6首部之后的有效载荷长度，注意这个和IPv4的总长度语义不同，IPv4是首部加数据的全文，IPv6是纯载荷长度。
• 下一个首部：8位，类似IPv4的协议字段，也用来标识扩展头的类型。
• 跳数限制：8位，等价于TTL。
• 源地址：128位，目的地址：128位。

IPv6的地址字段本身从32位扩到128位，是为了地址空间的不足，但设计者也借机删除了校验和，理由是：链路层的FCS已经保证了帧的完整性，传输层的TCP和UDP也自带校验和，IPv6中间再加一层校验和收益极低，反而增加转发延迟。从分层角度看，这是非常合理的抽象，每一层只做自己该做的校验，上层和下层各自兜底。

4. 传输层：TCP段格式与UDP数据报格式的对照拆解

4.1 TCP首部核心字段：从端口到校验和的每一项实际作用

TCP段格式是整个TCP/IP协议栈中最复杂、也最能体现工程智慧的部分。标准TCP首部至少20字节，如果带选项会延长到最多60字节。逐字段来看：

源端口、目的端口各占16位，端口本质上是“同一台机器上不同进程的网络入口编号”。序列号占32位，表示本报文段数据部分的第一个字节在整个发送字节流中的序号。确认号占32位，表示期望收到对方下一个字节的序号，同时也隐式确认了序号之前的所有字节都收到了。

数据偏移占4位，单位4字节，最常是5即20字节首部，如果带了选项就是6、7甚至更长，这个字段告诉接收方“TCP首部结束、数据开始”的位置。保留占6位，全部为0。标志位若干位中，最常用的六位分别是：

窗口大小占16位，表示发送方愿意接收的字节数，也就是接收窗口剩余空间的大小，这是流量控制的关键。校验和占16位，校验范围覆盖TCP首部加数据，并且还要包含一个伪首部。紧急指针占16位，只有当URG为1时才有意义，标记紧急数据结束位置。

TCP选项也是大头，常见的有MSS协商、窗口缩放、时间戳、SACK。后面这三个对高带宽长距离网络性能影响极大，如果你看到一个TCP连接在跨机房大带宽传输时吞吐上不去，八九成是窗口缩放或时间戳协商出了问题。

4.2 三次握手与四次挥手：报文里看到的连接生命周期

三次握手不是抽象概念，它就是三个TCP报文的语法。第一次握手，客户端发送SYN报文，SYN=1，ACK=0，序列号是一个随机值x；第二次握手，服务端回SYN+ACK报文，SYN=1，ACK=1，确认号是x+1，同时序列号为y；第三次握手，客户端发ACK=1，确认号为y+1，连接建立。注意，第二次握手的确认号是x+1，其中加1指的是“确认了SYN本身这个序号”，而不是“确认了x字节的数据”，SYN在序号空间里也是占一个号的。

四次挥手稍微绕一点。第一次挥手，主动关闭方发送FIN，表示数据发完了。第二次挥手，被动关闭方回复ACK，确认收到FIN，但被动关闭方可能还有数据要发。第三次挥手，被动关闭方数据也发完了，发送FIN。第四次挥手，主动关闭方回复ACK，连接彻底关闭。你抓包时会看到双方各有一个FIN和一个ACK，中间还夹着数据传输。

握手和挥手过程中最常见的故障是什么？是半关闭和TIME_WAIT。TIME_WAIT出现在主动关闭方回复完最后一个ACK之后，要持续2个MSL的时间。大量短连接场景下，TIME_WAIT会占满连接表，导致新连接无法建立。处理方式是开启tcp_tw_reuse、tcp_tw_recycle（后者在NAT环境慎用），或者改成长连接而非短连接。

4.3 UDP数据报格式：为什么它只有4个字段也能跑遍天下

UDP首部就8个字节，另加数据，格式简单得有一种暴力美学：

• 源端口：2字节，可选，不需要时可为0。
• 目的端口：2字节，必须有，否则对端内核不知道交给哪个应用。
• 长度：2字节，UDP首部+数据的总长度，最小是8。
• 校验和：2字节，覆盖伪首部、UDP首部和数据的校验和。

UDP没有序列号、没有确认号、没有窗口、没有重传机制，所以它不可靠。但反过来它的优势就是极低延迟和极小的处理开销。DNS查询、DHCP、RTP音视频、QUIC（基于UDP但内部实现了可靠机制）都是典型使用者。

抓UDP报文时有个细节要留意：IP层的分片一旦发生，UDP数据报的边界就被模糊掉了。如果MTU太小而UDP发送的数据太大，分片机制可能导致接收端重组失败，表现就是udp丢包。很多新手在排查UDP“丢包”时只盯着应用层日志，实际上最初的源头是分片重组失败。正确的做法是尽量让UDP包大小控制在MTU以内，一般建议不超过1472字节（以太网1500减去IP头20减去UDP头8）。

4.4 伪首部的校验原理：为什么TCP和UDP的校验和要虚拟一个IP头出来

伪首部是TCP和UDP校验和机制里的一个特殊设计。它不是一个真实传输的字段，而是计算校验和时临时组合的一段12字节结构：源IP地址4字节、目的IP地址4字节、协议类型1字节、TCP/UDP段长度2字节，外加一个字节的0填充。

为什么要加这个东西？因为传输层报错时，如果不校验IP地址和端口的关系，可能出现一种情况：一个TCP报文本应发给A，却因为某种原因被路由到了B，如果接收方的TCP层不检查源IP和目的IP，就可能把这个错误报文交给上层应用处理。伪首部的作用就是把IP地址也纳入传输层的校验范围，保证同一个五元组内的包才是有效的。

实际计算时，发送方先构造伪首部，和TCP报文拼在一起，按16位为一组求和取反，得到校验和填入。接收方做同样的计算，如果结果不为全1，说明数据在传输中被破坏。我在抓包时判断一个TCP报文是否被转坏，第一眼就是看校验和是否valid。Wireshark里直接会标出来是good还是bad。

5. 应用层协议的数据格式观察视角

5.1 从下层视角看应用层：应用层数据本质就是传输层的数据载荷

严格说，TCP/IP模型里的应用层协议并没有一个像以太网帧头、IP头那样统一的“固定格式”。每种应用层协议定义自己的语义、字段、分隔方式。但从传输层的视角看，应用层的数据就是TCP或UDP的载荷部分。

HTTP协议就是一个典型例子。HTTP报文分为请求行/状态行、头部字段、空行、消息体四个部分。头部字段以回车换行为分隔，字段名和字段值之间用冒号分隔。

抓包分析HTTP时最常用的是“追踪TCP流”功能，因为它能把同一个TCP连接上的多个往返报文按顺序重组，还原出完整的应用层消息。这是因为TCP是字节流协议，它不保留应用消息的边界，应用层必须靠自己的规则来切割。比如HTTP用Content-Length或Transfer-Encoding来标识消息体的结束位置。

DNS则走了完全不同的路子，它的报文格式是强结构的二进制，有固定的12字节首部，包括事务ID、标志、问题数、回答数、权威数、附加数等字段。查询部分包含QNAME（以长度标记的域名）、QTYPE和QCLASS。回答部分则包含名字指针、类型、类、TTL、数据长度和资源数据。

5.2 抓包工具中如何从原始十六进制定位字段边界

实际抓包分析时，你看到的是一行行的十六进制字节。要根据协议格式分字段，需要知道每个字节的偏移量。以IPv4为例：以太网帧头占14字节，偏移0-5是目的MAC，6-11是源MAC，12-13是类型。如果类型是0x0800，从偏移14开始就是IP首部。IP首部从偏移14开始，前4位是版本，4-8位是IHL，以此类推。

Wireshark有个很好的功能是点击某个字段，对应的十六进制字节会自动高亮。我建议新手用这个功能来做练习：选中一个TCP段的源端口字段，看它在十六进制区是怎么表示出来的，然后手动数一数偏移位置。这样练过十几个报文之后，你对字段布局的印象会远超死记硬背。

另外一个实用技巧是使用自定义列过滤。比如同时分析多个协议时，我常配置这几列：Time、Source、Destination、Protocol、Length、Info。用tcp.port、ip.addr、eth.type这些过滤语法能快速切出想要看的协议族。比如tcp.flags.syn==1能筛出所有SYN包，icmp.type==3筛出所有不可达消息。

6. 常见问题与排查技巧实录

6.1 MTU与分片问题排查：抓包与ping结合法

MTU问题在所有网络故障里属于“看起来像灵异事件但根因很明确”的类型。现象通常是：网页打开慢、大附件发送失败、文件传输到一半卡住，而小包通信完全正常。排查路径可以这么走：

第一步，用带DF标志的ping探测路径MTU。Windows用ping -f -l 1400 target，Linux用ping -M do -s 1400 target。如果收到“需要分片但DF已置位”或“Frag needed and DF set”的ICMP错误，逐步减小包长，直到能通，就能大致估算出路径MTU。

第二步，开启PMTUD相关的sysctl参数，比如net.ipv4.ip_no_pmtu_disc设为0，并确保路径上的防火墙不拦截ICMP type 3 code 4。

第三步，在应用层做调整：HTTP服务器可适当调低TCP MSS，Linux端通过ip route add修改特定路由的MSS值。很多云厂商的负载均衡其实自动设置了MSS clamping策略，目的就是避免路径MTU发现失败导致的黑洞。

顺手列一个排查速查表：

6.2 TCP重传与乱序：用标志位和序号还原真相

TCP重传是抓包排查中最常见的观察对象。一个正常TCP连接的重传率应该是0或者极低，如果看到大量TCP Retransmission，说明丢了包或者对端没确认。重传的本质是发送方没在超时时间内收到ACK，于是用同样的序列号重新发送数据。

排查重传问题的核心思路是判断丢包发生在哪个方向。比如我在一次数据同步延迟排查中，发现服务端一直在重传同一个数据段，而客户端的确认包没有出现在抓包里。进一步检查发现是交换机端口上的入方向丢包计数器在增长，问题定位在客户端方向的网络路径上。

乱序则表现为序列号不单调递增。抓包软件对乱序会标为TCP Out-of-Order。偶尔乱序不必紧张，骨干网络上多路径负载均衡经常导致少量乱序；但如果乱序比例高，接收方的TCP会触发快速重传机制，白白浪费带宽。这时候要看是不是有多条链路同时传输同一个TCP流，或者中间设备做了不合理的负载均衡。

6.3 抓包分析中的常见误判与操作注意

抓包工具本身也会骗人。以下几条是新手最容易踩的坑：

校验和显示bad不一定是网络传输损坏。很多网卡开启了TCP/UDP校验和卸载功能，由网卡硬件计算并填充校验和，Wireshark在捕获阶段来不及取到正确的计算值，就会误报bad checksum。验证方法是看同一抓包文件里是否所有报文的校验和都是bad，如果是，多半是抓包工具未识别卸载，不是真损坏。

Wireshark显示的包长度和线速不符。除了前面说的前导码和FCS被剥离，还可能是巨型帧和VLAN标签造成的长度差异。抓出口方向流量时如果看到帧长度接近或超过1518，要考虑MTU是不是被改大了。

环路重复包导致的分析混乱也很常见。如果抓包文件里同一个报文出现多次，检查是否配置了端口镜像环回，或者多个镜像口同时汇总到一个抓包端口上。这类问题不加过滤时会严重干扰后续分析。

在Linux上抓包还建议关注抓包自身的丢包情况，tcpdump退出时会输出统计信息，显示的“dropped by kernel”如果不为0，说明抓包过程中内核抓包缓冲区溢出了，这次抓包结果可能不完整，需要增大缓冲区或减小抓包范围。我通常用tcpdump -w大文件时会加 -B参数调buffer size到4096甚至8192。

7. 实操总结：一套完整的报文分析方法论

把前面的内容落成一套可执行的分析方法，我在实际工作中每次排查网络或协议问题都会按这个流程走：

先确认抓包目标，是用Wireshark、tcpdump还是硬件探针，这取决于环境；再决定抓包点，抓在客户端上、服务端上还是中间交换机上，决定了你看到的是发送视角还是接收视角，这两者可能存在不对称差异。

然后抓包前要规划过滤条件。用tcpdump抓全量流量的文件往往巨大无比，分析起来反而麻烦。我更倾向于用host、port、tcp或udp这些基础条件先粗筛，再在Wireshark里用display filter细筛。

拿到原始报文后，逐层展开分析：链路层看MAC和类型，网络层看IP、TTL和分片标志，传输层看端口、序列号、确认号、标志位和窗口，应用层看具体协议内容。从下往上一条条拆，每一步都问自己：这个字段的值是否符合预期？如果不符合，它在哪个环节被改写了？

有一件事我一直觉得值得强调：协议分析本质上是“对比预期和现实”的过程。你越熟悉协议格式的“正常值”，就越容易发现异常。比如TCP握手包里的MSS是1460，如果中间设备偷偷把它改成了1400，你就知道路径上存在MSS clamping，后续大包行为会受影响。如果你不看字段，光看应用层结果，这类问题会让你的排查半径大很多。

抓包之外，还可以配合系统层面的网络统计来交叉验证。Linux下用ss、netstat看连接状态，用ip -s link看接口统计，用nstat看内核网络栈计数器。协议格式分析给的是逻辑层的证据，系统统计给的是设备侧的物理证据，两者都对上，才能下结论。

回到开头说的那个线上超时问题，最后定位出来接收窗口是0，应用层把数据读走的速率跟不上对端发送速率，TCP的流量控制机制被触发，发送方进入持续探测窗口的模式。整个根因链路里没有一处是“坏了”，全是因为负载和流量特征把TCP协议的字段机制推到了极端。这一类经历让我越发觉得，TCP/IP的数据格式和字段不仅仅是考试知识点，它们就是网络世界里最底层的事实与规则。看懂它们，等于掌握了跟网络对话的语法。