IPv4报文头部详解：字段、分片与网络排查核心知识

做网络排查做得久了，你会发现一个特别有意思的现象：很多人能把TCP的三次握手、四次挥手讲得天花乱坠，可一旦你把抓包工具里的一帧数据展开，让他逐字节解释一下IPv4头部，他反而会卡壳。TCP、UDP这些传输层协议太出名，以至于真正负责“把数据从A点搬到B点”的IPv4报文，反倒成了最熟悉的陌生人。

这篇文章想干的事很单纯：把IPv4报文从头到尾拆开，每个字段都讲清楚它为什么存在、怎么工作、踩坑时怎么用它。顺带把网络层“尽力而为”这句话背后的设计逻辑翻出来晒一晒——它并不是“随便传一下”，恰恰是一堆精巧妥协堆出来的护城河。适合刚入门网络的同学建立完整认知，也适合干了几年运维、想补齐细节的人看。

1. 逐字段解剖：IPv4头部为什么长这样

1.1 先看一张完整的地图

IPv4头部最小20字节，最大60字节。日常抓包里见到的绝大多数报文，头部都是20字节，也就是没有带选项的标准头。下面这张表列的就是这20字节的完整布局，建议先保存下来，后面所有内容都围绕它展开：

我入行那年，师傅跟我说过一句话：这些字段没有一个是多余的。哪怕是最不起眼的某个位，背后都能牵出一段网络工程的历史。刚开始我觉得夸张，后来踩的坑多了，才慢慢信了。

1.2 版本号与首部长度：两个4比特的讲究

版本号占了4比特，IPv4就是4，IPv6就是6。设计这个字段，本意是让同一台设备能同时识别不同版本的IP报文。这个远见在IPv4和IPv6过渡的今天显得非常值钱——虽然NAT和隧道技术让共存变得很复杂，但至少设备能从第一个字节就判断出“这是谁家的孩子”。

首部长度字段同样占了4比特，但它的存在更现实：IPv4头部带选项，长度是可变的，接收端必须知道头部到底有多长，才能知道数据从第几个字节开始。这个字段的单位是4字节，所以最小值是5，对应20字节的标准头；最大值是15，对应60字节。头部再想长一点，这个4比特字段就表达不了了，这是IPv4天生的硬限制。

这个设计在当时很聪明，放到现在却成了转发设备的一个小负担。你想，硬件路由器每收到一个包，都得先做一次“首部长度乘4”的运算，才知道偏转起点在哪。如果每个包都是固定20字节，流水线不知道能简化多少。IPv6把头部直接固定在40字节，其实就是在向“高速转发”低头，用灵活性换性能。

1.3 服务类型：从没人用的TOS到DSCP和ECN

服务类型这个8比特字段，是IPv4头部里改朝换代最典型的例子。最初的设计叫TOS，分成了3比特的优先级和若干标志位，想表达“这个包的优先级高，请优先处理”。理想很丰满，现实很骨感：很长一段时间里，几乎没有网络设备真正按这套规则做事，TOS字段在生产环境里基本是个摆设。

后来人们发现，完全不用太浪费，于是改造成我们今天熟知的DSCP（区分服务编码点）。前6比特用于标记服务等级，语音、视频、背景流量各归各的队列，路由器就可以按优先级进行拥塞管理。后面2比特是ECN（显式拥塞通知），这个机制更巧妙：路由器不丢包，而是在拥塞时悄悄把ECN位打上标记，接收端看到标记后就通知发送端放慢速度。

DSCP和ECN的出现，算是给“尽力而为”做了一次外科手术——IP层仍然不保证任何东西，但至少允许你表达“我想要什么”，让中间设备在力所能及时给你一点优待。这个字段也常被拿来排查问题：如果你发现某个应用的流量抓包时DSCP值是0x00，但实际网络上存在QoS策略，先别急着怀疑网络，很可能是应用自己没打标。

1.4 总长度、标识、标志、片偏移：为分片而生的三位一体

总长度字段16比特，单位是字节，代表整个IP报文的大小。最大值65535字节，这就是IP层的理论报文上限。但实际网络里，二层链路的MTU一般只有1500字节，所以绝大多数情况下IP报文会被限制在1500以内，总长度字段很少出现夸张的数值。

标识、标志、片偏移这三个字段，是三位一体、专为分片服务。标识字段16比特，分片时用同一个编号标记一组同源的碎片，接收端靠它知道“这些碎片原本是一家人”。标志字段里真正有用的只有两个位：DF置1表示“禁止分片”，如果报文超过链路MTU就直接丢弃，这是路径MTU发现机制的基础；MF置1表示“后面还有分片”，最后一个分片的MF一定为0。片偏移字段13比特，它表达“本片在原始报文中的位置”，单位是8字节。

为什么偏移量偏偏要用8字节作单位？这里有个数学上的讲究：片偏移一共13比特，最大值是8191。如果单位是1字节，最多只能表达8191字节的偏移，可IPv4报文最大有65535字节，根本不够用。把单位放大到8字节，就能覆盖到65528字节的偏移范围，几乎够用，还不会太浪费精度。代价是每个分片的数据长度必须是8字节的整数倍（最后一片除外）。

1.5 协议号、TTL、首部校验和：可靠性的三个小门神

协议号字段告诉接收端“我肚子里装的是谁”：6是TCP，17是UDP，1是ICMP。接收端拆掉IP头之后，就靠这个字段把数据正确地交给对应的上层协议去处理。它实现了网络层和传输层的“多路分解”，相当于一栋楼里的门牌号。

TTL字段的官方名字很坑，叫“存活时间”，实际上它计的是跳数，不是秒数。最大255，通常初始值用64、128或255。每经过一台路由器减1，减到0还到不了目的地，路由器就会把包丢掉，并发一个ICMP超时的消息。评论区很多人问过“TTL太小会怎样”，答案很直接：网络中如果出现转发环路，TTL是最后一道防环的保险，没有它，一个坏包能在网络里转圈转到地老天荒。

首部校验和字段比较简单粗暴：发送端把IP头部按16比特一组做二进制反码求和，得到的结果取反填进去；接收端收到后，把头部连同校验和一起做同样的反码求和，正常情况下结果应该全是1。只要有一位翻转，结果就不对，包会被静默丢弃。注意它只校验头部，不管数据。这不是偷懒，而是因为数据的完整性由TCP、UDP各自负责，IP层只需要保证自己写给别人的“快递面单”是清楚的。

1.6 源地址、目的地址与选项字段：面单上的寄件人和收件人

源地址和目的地址各占32比特，是IPv4最核心的信息。路由器就是拿这两个字段做路由表查询，决定下一步往哪个端口送。这里必须提醒一句：源地址是可以被伪造的。很多攻击都带着假源地址出门，所以任何安全设备如果“无条件相信”源地址，迟早要出事。

选项字段就更有历史感了。早期设计里，它支持记录路由、时间戳、甚至源路由——源路由允许发送端自己指定路径，这等于把路由器的活儿抢了，危险性极大，后来基本被所有设备禁用。选项字段把IPv4头部变得可长可短，这也是上面讲“首部长度”字段存在的原因。实际抓包里，几乎看不到有人用选项，头部全是干净的20字节。

2. 分片机制：IPv4的妥协与智慧

2.1 为什么要分片：每一段链路都有“窄门”

IP层设计目标是把异构网络互联起来，可不同二层链路的脾气各不相同：以太网帧最大载荷1500字节，老式X.25、ATM链路可能更小。如果发端不知道路径上最小MTU是多少，就只能在中间让路由器出面解决。于是IPv4定了一个规矩：中间设备发现包太大时，自己动手把它拆成多片，每片独立转发，到了终点再由对方拼回去。

这个设计把“联网”的复杂度下放给了网络设备，保证了源端不必知道全路径的MTU信息。代价是中间设备要多做分片运算，而且每一片都要复制一份IP头部，开销反而变大。更重要的是，分片之后如果丢了一片，整组报文全部作废，接收端会重组失败，这给网络可靠性带来了隐患。

2.2 分片到底怎么拆：以3000字节报文为例

我经常用这个例子讲分片，建议收藏。假设一个IP报文，头部20字节、数据2980字节，要穿过MTU为1500的链路。

第一个片：头部20字节 + 数据1480字节，总长度1500，MF置1，片偏移0。为什么数据部分取1480？因为片偏移单位是8字节，1480除以8等于185，正好是整数。 第二个片：头部20字节 + 数据1480字节，总长度1500，MF置1，片偏移185。 第三个片：头部20字节 + 数据20字节，总长度40，MF置0，片偏移370。

这里要特别强调一句：分片的单位不是“整个报文平摊”，而是把原始数据按8字节对齐切开。第三个片只有20字节数据，却要扛一个20字节的头部，转发效率极低。这就是为什么网络工程师看到分片包会皱眉——分片越多，额外开销越大，丢包风险越高。

2.3 为什么重组只能在终点做

你有没有想过，为什么路由器遇到分片不直接帮它拼回去，省得终点来回折腾？答案是：各片在网络上走的路径可能完全不同。原因在于IP是无连接的，每个片在转发时都是独立的包，完全可能走不同路由器、从不同链路到达。中间某台路由器根本没法保证能见到这一组的全部碎片，硬要重组就得一直等，等到超时就变成一个状态大户，这跟IP“无状态转发”的初衷矛盾。

所以IPv4规定，重组只能在最终目的主机做。目的主机把所有标识号相同的分片收齐之后，按片偏移顺序拼好，再交给上层协议。如果缺了几片，超过重组超时时间，直接把已经收到的部分全部丢弃，通知也不一定发。分片是这个协议的无奈之处，也是它“尽力而为”气质的集中体现。

2.4 分片带来的安全问题与PMTU黑洞

因为分片会扰乱防火墙的状态检查，历史上出现过大量针对分片的攻击手法。经典的是重叠分片攻击：攻击者发送偏移重叠的分片，使得重组后的数据里某个字节既可能是合法的老内容、也能被伪造的新内容覆盖，从而绕过防火墙的规则匹配。这类攻击推动了“状态化重组检查”的出现，现代安全设备基本都会把分片先重组检查一遍再转发，很多站点干脆直接过滤所有分片流量。

再说PMTU黑洞，这是运维里极难缠的问题。路径MTU发现机制依赖DF位：源端发出DF置位的探测包，如果某个链路的MTU不够，路由器会丢弃并回一个“需要分片但DF置位”的ICMP消息，源端据此调小报文长度。问题在于，很多安全设备把ICMP当成洪水猛兽直接过滤掉，探测包被静默丢弃，源端永远等不到回音，就会一直重传。表现就是你小包Ping得通，大包Ping不通，网页打不开，游戏掉线。IPv6干脆取消了中间分片，只允许源端自己分片，从设计上消灭了这条岔路。

3. “尽力而为”的真正含义：无连接与端到端原则

3.1 无连接：每个包都是独立行动的单兵

“尽力而为”的第一层含义是：IP层是无连接的。每个IP报文在转发时，路由器都会独立地查一次路由表，做一次选路决策。同一个TCP连接里的两个包，前一个可能走A路径，后一个可能走B路径。这跟打电话那种“先拨通、再通话”的面向连接方式完全不同，它更像在大街上各自赶路的行人，没有统一指挥，没有预定路线。

这种设计的优点很突出：路由器不需要为每个连接保存任何状态，完全可以做成“来包就转”的流水线；网络里某台设备挂了，影响的只是正在经过它的包，不会拖垮整条连接很久。缺点也很明显：报文可能乱序到达、可能重复、可能丢失、甚至可能压根没送到。传输层TCP存在的意义，就是给这样一位不靠谱的快递员“擦屁股”。

3.2 不可靠不等于没兜底：端到端原则的智慧

很多人听到“网络层不可靠”就慌，觉得怎么能在不靠谱的基础上建互联网。这里必须讲清楚端到端原则：尽量把功能放在通信的两端，而不是网络中间。IP层只负责“尽力转发”，转发不动了也不会主动重传；真正需要可靠性的时候，由传输层的TCP通过序号、确认、超时重传、滑动窗口把这些全包了。

这种分工不是没有道理的。如果让IP层做得太可靠，每个路由节点都缓存无确认的数据，维护连接状态，那网络设备的成本会直线上升，转发速度反而被拖垮。而把可靠交到端到端用户手里，发送方可以根据真实网络状况灵活调整重传策略，接收方也可以按需缓冲。网络层保持简单，传输层负责补救，这是计算机通信的一次伟大分工。

3.3 为什么不能把所有可靠性都塞进网络层

你也可以反过来想：假如当年IP层对每一个包都做可靠确认，会是什么后果？首先，中间每一跳路由器都得记录“谁发了什么、我确认没确认、我缓存了哪些数据”，这种状态量的爆炸式增长，会让路由器从一个无状态转发器变成一个沉重的状态机。其次，不同链路的时延、带宽差异巨大，一个可靠的网络层必须按最慢链路的节奏来，整个网络的吞吐量会被木桶效应死死压住。

所以“尽力而为”不是躺平，而是深思熟虑后的最优解。它让IP成为一个可以在各种物理网络之上灵活运行的“通用层”，不管底下是光纤、双绞线还是无线，都能跑；也让网络设备能做减法、做并发、做线速转发。加上DSCP提供优先队列、ECN管理拥塞、ECMP做等价多路径，这套系统早就不是几十年前的蛮力转发了。

4. TTL与首部校验和：两个最容易忽略的细节

4.1 TTL的递减规则：为什么主机收到TTL=1的包还能正常处理

TTL的细节里有一个混淆点必须澄清：很多人以为TTL到1就应该被丢弃，其实不对。路由器转发时，如果发现TTL已经为0或减1后变成0，才会丢弃并回ICMP超时；而目的主机在收到TTL=1的包时，只要自己是终点，就直接交给上层处理，不再关心TTL还剩多少。

日常排查中，TTL初始值能透露不少信息。不同操作系统的TCP/IP协议栈默认初始TTL不一样，常见的就有64、128、255。Ping一个远程主机，看回包里的TTL值，多少能猜出它穿了大概多少跳，或者它跑在什么系统上。比如发出时是128，回来时剩118，路上就是10跳左右；如果回包TTL只有60，多半初始值是64的Linux/类Unix设备，而且距离我们很近。

4.2 首部校验和的计算与增量更新：一个把计算量省下来的老办法

计算IPv4校验和的算法特别老派，但很有效。把头部按16比特切分成一组一组，把所有组按“二进制反码求和”的方法加起来，也就是普通加法，但如果加出进位，就把进位循环加回最低位。全部加完后，把结果按位取反，填进校验和字段。接收端做同样运算时，如果头部没坏，总和一定是0xFFFF。

转发时TTL要减1，头部被改动，所以校验和必须更新。早期设计里，每跳路由器都要重新计算整个校验和，这在硬件转发时代是个负担。后来出现了增量更新算法：因为TTL只是减1，旧校验和与新校验和之间只要做一次修正即可，不必把20字节全重算一遍。这属于“为了高速转发抠细节”的典型案例，今天很多硬件转发芯片依然沿用这个思路。

还有一点容易让人误解：抓包时看到IP校验和显示错误，先别急着报故障，要想想是不是网卡硬件校验和卸载导致的假象。常见的抓包软件抓的是网卡送上来、还没做完校验的数据，软件按算法算了一遍觉得对不上，就会标红提醒。真正的网络故障是设备传输途中比特翻转，这种概率其实很低。

4.3 traceroute是怎么用TTL“钓”出每一跳路由器的

traceroute的原理简单说就是：利用TTL制造一系列“故意失败”的包。先发一个TTL=1的UDP探测包，第一台路由器转发时减1成0，直接丢弃，再顺手回一个ICMP超时消息。这个超时消息的源IP地址，就是第一跳路由器的地址。然后再发TTL=2的包，第二跳路由器就会回超时……以此类推，一路钓出路径上每台设备。

探测包到达目标主机后，端口大概率是关着的，目标会回一个ICMP端口不可达的消息。这个消息一来，你就知道已经到终点，路径探测结束。这个工具的价值在于，它让“看不见”的网络路径变成了逐跳可见的清单。排查“某一段网络不通”时，跑一次traceroute，星号出现在第几跳，问题就锁定在那一段，比挠头猜快多了。

5. 抓包实操：从十六进制到字段解读

5.1 一张教学示例帧的逐字节读取

下面这行十六进制是我按真实抓包风格写的演示数据，为了方便讲解，校验和字段用了占位值：

45 00 00 3c 1c 46 40 00 40 06 00 00 ac d9 17 8a c0 a8 01 01

从左到右拆：

• 0x45：高4位是版本号4，低4位是首部长度5，头部20字节。
• 0x00：DSCP和ECN都是0，该包没有服务标记。
• 0x003c：总长度60字节，也就是头部20字节加40字节数据。
• 0x1c46：标识字段，十进制7246。
• 0x40：这是标志和片偏移的高字节。0x40换算成二进制是0100 0000，其中最高位保留0，DF位为1，MF位为0，片偏移低13位是0。说明这包没分片，而且不允许分片。
• 0x00：片偏移低字节，和上面的低5位组成完整偏移0。
• 0x40：TTL=64。
• 0x06：上层协议是TCP。
• 0x0000：示例校验和占位。
• 0xacd9178a：源地址，换算成点分十进制就是172.217.23.138。
• 0xc0a80101：目的地址，即192.168.1.1。

这个例子我们在脑子里过一遍，就明白了“版本+长度”共用第一字节、DF位藏在标志字节里的具体形态。平时抓包软件会直接帮你翻译成人话，但如果哪天工具坏了、字体乱了，能自己上手读hex，才是真的把协议吃透了。

5.2 用Python手工构造一个IPv4报文

验证自己对头部的理解，还有一个更极客的办法：自己动手把报文拼出来。下面这段Python代码可以构造一个最简单的UDP-over-IPv4报文，并在本地发送。核心在于按字段顺序用struct打包，再把校验和算对。

import socket import struct def checksum(data): if len(data) % 2: data += b'\x00' s = 0 for i in range(0, len(data), 2): s += (data[i] << 8) + data[i+1] while s >> 16: s = (s & 0xffff) + (s >> 16) return ~s & 0xffff def build_ipv4(src, dst, payload): version_ihl = 0x45 # IPv4, 20字节头部 tos = 0 total_len = 20 + len(payload) ident = 0x1234 flags_frag = 0x4000 # DF=1 ttl = 64 proto = 17 # UDP src_ip = socket.inet_aton(src) dst_ip = socket.inet_aton(dst) header = struct.pack('!BBHHHBBH4s4s', version_ihl, tos, total_len, ident, flags_frag, ttl, proto, 0, src_ip, dst_ip) chk = checksum(header) header = struct.pack('!BBHHHBBH4s4s', version_ihl, tos, total_len, ident, flags_frag, ttl, proto, chk, src_ip, dst_ip) return header + payload packet = build_ipv4('192.168.1.100', '192.168.1.1', b'hello ipv4') s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_RAW) s.sendto(packet, ('192.168.1.1', 0))

重点提两句：打包格式串!BBHHHBBH4s4s是大端序网络字节序的标准写法，字段顺序严格对应头部；校验和计算函数里的while s >> 16循环，就是处理“进位循环回最低位”的老规矩。这段代码只能用来学习，生产环境里请直接相信操作系统的协议栈。

5.3 抓包工具里的几个实用过滤表达式

做IPv4报文分析时，我常用的过滤表达式有这么几个，基本能覆盖日常排查：

• ip：只看IPv4流量。
• ip.src == 192.168.1.100：按源地址过滤。
• ip.dst == 192.168.1.1：按目的地址过滤。
• ip.ttl < 10：找出TTL已经很低、可能快出问题的包。
• ip.flags.df == 1：只看DF位的包，排查分片问题时很有用。
• ip.frag_offset > 0：只看非首片的分片。

分片重组是否正常，也可以通过抓包验证：抓到同一标识号（Identification）的多帧数据，它们的源地址、目的地址一致，但片偏移和MF位不同，说明这是一组分片。如果只看到首片、后面没有后续片，或者中间缺了几片，基本可以判断分片在网络上被丢了，就得回头查路径MTU。

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

6.1 MTU黑洞问题：小包通、大包不通的经典谜题

症状通常很一致：Ping一个目标，小包秒回，大包直接超时；网页打开缓慢、图片加载不出来，但命令行交互又一切正常。这个问题我遇到不下十次，老老实实讲一下标准排查流程。

先做最大包长测量。常见系统上，Ping加“-l 1472”表示发送1472字节的ICMP数据载荷，加上IP头20字节和ICMP头8字节，刚好凑满1500字节。如果能通，说明端到端MTU至少有1500；如果1472不通但1460通，说明路径上某个环节MTU更小。再加DF位测试，命令里带上“-f”参数，情况就更明确了：如果加DF后不通、去掉DF后通，说明路径上有设备拒绝分片但没把ICMP错误消息回给你，PMTU黑洞实锤。

处理手段通常是：在TCP层开启PMTU探测相关参数，或者把会话的MSS压低，让TCP报文永远不触碰MTU红线；终极解法是整条路径统一协商MTU，但这在有多个第三方网络的情况下非常困难。这也是为什么IPv6宁可让源端强制分片、中间设备只管转发，彻底绕开这套黑盒逻辑。

6.2 TTL耗尽与路由环路：超时消息背后的线索

如果目标一直在“传输中TTL超时”状态，说明TTL被减到0了。可能是路径太长超出255跳（这基本不可能），更可能是网络出现了路由环路。抓包你会看到同一对源目地址的报文在反复横跳，而且TTL值逐跳递减，到达同一个路由器后再次出现。这时先看路由表，找有没有等价路由写错、静态路由指回自己这种低级错误。

环路还有一个伴生现象：CPU打满、带宽被垃圾流量塞满。环路里的包会不停复制扩散，严重时能拖垮整片区域网络。因此TTL这个字段，表面上是“限制包活多大岁数”，本质上是“网络保险丝”。排查线路质量时，所有故障点的证据都能在ICMP超时消息里找到线索，别只盯着Ping的结果看。

6.3 校验和错误到底要不要管

抓包软件里标红一个IP校验和错误，让人忍不住想查。我的建议是分三步走：第一，确认这个错误是不是网卡校验和卸载造成的假象——办法是看错误是不是集中在接收方向，而且应用通信正常；第二，如果是发送方向看到校验和错误，多半是驱动或特别老的硬件问题；第三，如果错误带着明显的丢包、连接中断，才需要怀疑传输链路有比特翻转，这时候可以顺着物理链路检查光模块、线缆衰减。

另外，中间设备修改TTL会导致校验和变化，如果设备没有同步更新校验和，接收端抓包也会看到错误。这种情况属于设备实现有缺陷，通常伴随大量丢包，因为接收端会把校验失败的报文直接扔掉。比如老式三层交换机转发时只改TTL、不改校验和的固件问题，我就踩过一次，升级固件后立刻好了。

6.4 分片丢失和重组超时：如何判断“缺了一片”

应用层症状是：大块数据传不完、进度条反复回退，但小文件传输正常。抓包去看标识号，如果发现某个标识号只出现了一部分分片，之后再也没有后续的分片帧，那就是中途丢了。再配合上游设备的丢包计数，基本能定位到是哪一跳丢的。

分片重组超时后，接收端会把已经收到的分片全部丢弃，这就导致一个反直觉的现象：一个15KB的报文被切成11片，如果只丢了1片，剩下的10片也没用了。应用层看到的结果就是整体重传，网络利用率直线下降。所以很多安全设备宁可把分片全部拆开重组检查，也不愿放一个不知道会拼出什么的怪物进去。对运维来说，最好的策略是让TCP的MSS不要触发分片，把分片扼杀在源端。

干这行久了，我最大的体会是：抓包时要先把十六进制当成唯一的事实来源，再去看工具给的“友好结果”。有一年排查一个跨地域传输问题，抓包软件显示一切正常，可应用就是卡得要命。我不信邪，逐字节翻了几十个包，才发现所有报文都被某台设备强行打了DF位、悄悄改了MSS，导致应用层大包永远卡在MTU边缘下不来。如果只盯着协议树看，这个问题可能还要拖很久。

IPv4报文就这么30多个字节，但它浓缩了互联网这么多年的经验与妥协。无论以后IPv6怎么普及，把一个IP报文读明白的能力，都值得花时间去磨一磨。