IPv4数据报结构：从比特流到网络世界的通行证
说实话，IPv4数据报结构是我刚入行时觉得最枯燥的东西。一堆字段，一堆偏移量，感觉就像在背电话号码。直到有一次我在机房排错，盯着抓包文件看了三个小时，才真正明白——这20字节的固定头部，就是网络世界的身份证和快递单的合体。
今天咱们就把这20字节掰开揉碎，一个一个字段过。我保证，看完你再看抓包工具里的那一串十六进制，会像看中文一样自然。
核心认知：IPv4数据报 = 头部（20字节固定 + 可选选项）+ 数据载荷。头部每个字段都有明确的设计意图，没有一个是多余的。
2.1 版本号与首部长度——头两字节定乾坤
数据报的前4位是版本号。IPv4就是4，IPv6就是6。这个字段其实没啥好说的，但有个小细节：接收端靠这个字段判断该用哪种协议栈解析。我见过有人把IPv6报文伪装成IPv4，结果路由器直接丢弃——版本号不匹配，后面的解析全是错的。
紧接着的4位是首部长度（IHL，Internet Header Length）。注意，单位是4字节。也就是说，如果值是5，表示头部长度是5×4=20字节（标准无选项的情况）。如果值是15，那就是60字节（最大）。
| IHL值 | 实际头部长度 | 常见场景 |
|---|---|---|
| 5 | 20字节 | 绝大多数标准IP报文 |
| 6 | 24字节 | 携带少量选项（如时间戳） |
| 15 | 60字节 | 选项塞满（极少见，现代网络基本不用） |
我的习惯：看抓包时，先看IHL字段。如果大于5，说明有选项字段，这时候要小心——有些老旧设备或安全设备会直接丢弃带选项的报文。我曾经在跨网段调试时，就是因为中间防火墙丢弃了带时间戳选项的包，折腾了两天。
2.2 服务类型（ToS）与总长度——优先级与尺寸的博弈
服务类型字段，8位。早期设计是用来做QoS（服务质量）的，比如给语音流量打高优先级标记。但说实话，在实际互联网中，这个字段基本被忽略了。运营商和大型企业内网可能会用DSCP（差分服务代码点）来重新定义这8位，但普通场景下，你看到的值基本都是0。
总长度字段就重要多了。16位，单位是字节，最大能表示65535字节。但实际中，以太网MTU（最大传输单元）是1500字节，所以IP层很少见到超过1500字节的报文——除非你搞了巨型帧（Jumbo Frame）。
这里有个坑：总长度字段包含头部本身。也就是说，如果总长度是100，头部是20，那数据载荷就是80字节。我见过新手写协议栈时，把总长度当成数据长度来用，结果解析出来的内容全错位了。
我曾经踩过的坑：有一次排查一个视频传输卡顿的问题，发现发送端设置了总长度为65535，但实际链路MTU只有1500。结果IP层分片后，接收端重组时发现总长度字段和实际收到的分片总和不一致，直接丢弃了整个数据报。嗯，从那以后我养成了习惯——抓包时第一眼就看总长度和分片标志。
2.3 标识、标志、片偏移——分片与重组的三角关系
这三个字段必须放在一起讲，因为它们共同完成了IP分片（Fragmentation）这个核心功能。
标识（Identification）：16位。发送端给每个数据报分配一个唯一ID。当数据报被分片时，所有分片共享同一个ID。接收端靠这个ID来识别哪些分片属于同一个原始数据报。
标志（Flags）：3位，但只有两位有用：
- DF（Don't Fragment）：置1表示不允许分片。如果路径MTU太小，路由器会直接丢弃并返回ICMP错误。这是PMTUD（路径MTU发现）的基础。
- MF（More Fragments）：置1表示后面还有分片。最后一个分片的MF=0。
片偏移（Fragment Offset）：13位，单位是8字节。表示当前分片在原始数据报中的位置。比如偏移0表示第一个分片，偏移100表示从第800字节开始。
分片重组的关键规则：
- 所有分片的ID必须相同
- 除了最后一个分片，其他分片的MF必须为1
- 片偏移 × 8 = 分片在原始数据报中的起始字节位置
- 接收端收到MF=0的分片后，开始启动重组计时器（通常30秒）
你想想看，为什么片偏移的单位是8字节而不是1字节？因为13位只能表示8192个偏移量，如果单位是1字节，最大只能表示8192字节的数据报。但IP数据报最大是65535字节。用8字节为单位，13位就能覆盖到65535字节了。这就是设计上的精妙之处。
2.4 生存时间（TTL）——网络世界的生命倒计时
TTL，8位。每经过一个路由器，TTL减1。减到0时，路由器丢弃该数据报，并发送ICMP超时消息给源端。
这个设计的初衷是防止数据报在网络中无限循环。早期互联网拓扑混乱，路由环路时有发生。没有TTL，一个数据报可能永远在路由器之间转圈，最终把网络带宽耗尽。
| 常见TTL初始值 | 操作系统/设备 |
|---|---|
| 64 | Linux、macOS、大多数网络设备 |
| 128 | Windows |
| 255 | 某些路由器、网络探测工具 |
实用技巧：用ping命令时，看TTL值就能大致判断对端是什么系统。比如你ping一个服务器，返回的TTL是118，说明初始值是128，经过了10跳。如果返回的是52，说明初始值是64，经过了12跳。这个技巧我在排查跨运营商延迟问题时经常用。
2.5 协议字段——数据交给谁处理
8位，标识上层协议。接收端IP层解析完头部后，根据这个字段把数据载荷交给对应的传输层协议处理。
| 协议号 | 协议名称 | 常见用途 |
|---|---|---|
| 1 | ICMP | ping、traceroute、错误报告 |
| 6 | TCP | Web浏览、邮件、文件传输 |
| 17 | UDP | DNS、视频流、VoIP |
| 89 | OSPF | 动态路由协议 |
这个字段其实是个多路复用/解复用的关键。你想想看，网卡收到一个IP数据报，IP层解析完头部后，怎么知道该把数据交给TCP还是UDP？就是靠这个协议号。我见过有人写网络抓包工具时，忘了解析这个字段，结果所有数据都按TCP处理——UDP报文全被当成乱码显示了。
2.6 首部校验和——防君子不防小人
16位，只校验IP头部，不校验数据载荷。算法很简单：把头部按16位一组求和，取反码，填入校验和字段。接收端重新计算一遍，如果结果不是全1（0xFFFF），说明头部在传输过程中被损坏了，直接丢弃。
为什么只校验头部？因为IP层不关心数据是否正确——那是上层协议（TCP/UDP）的责任。IP层只保证自己能正确解析头部，然后把数据交给正确的上层协议。说白了，IP层只管快递单填对了没有，包裹里的东西坏没坏，那是收件人（上层协议）的事。
注意：每经过一个路由器，TTL会减1，所以首部校验和必须重新计算。这也是路由器处理IP报文时最耗CPU的操作之一。我曾经优化过一个嵌入式路由器的转发性能，发现校验和计算占了CPU时间的30%。后来用了硬件加速和增量校验和算法，才把性能提上来。
2.7 源IP地址与目的IP地址——你是谁，你要去哪
各32位，IPv4地址。源地址必须是单播地址（不能是广播或多播），目的地址可以是单播、广播或多播。
这里有个常见的误解：源IP地址不一定是你本机的IP。NAT（网络地址转换）设备会修改源IP地址。代理服务器也会修改。甚至有些应用层协议（如FTP的PORT模式）会在数据载荷中携带IP地址信息，导致NAT穿越困难。
我记得有一次帮客户排查一个跨地域的视频会议问题。两边都能ping通，但视频就是连不上。抓包一看，视频流的源IP地址是内网地址（192.168.x.x），但数据包是从公网IP发过来的。嗯，NAT设备只修改了IP头部的源地址，但应用层协议里还嵌着内网地址——接收端一看，源地址是内网地址，直接丢弃了。这就是典型的NAT穿透问题。
2.8 选项字段——鸡肋还是利器
选项字段是可变长的，最多40字节。常见选项包括：
- 严格源路由（Strict Source Route）：指定数据报必须经过的路径。安全风险极高，现代网络基本禁用。
- 宽松源路由（Loose Source Route）：指定必须经过的某些节点，其他路径自由选择。同样安全风险高。
- 记录路由（Record Route）：让沿途路由器把自己的IP地址填入选项字段。最多记录9个。
- 时间戳（Timestamp）：记录每个路由器处理数据报的时间。
说实话，在现代互联网中，选项字段基本是个摆设。大多数运营商和企业的路由器会直接丢弃带选项的IP报文，因为处理选项字段太消耗CPU资源，而且存在安全漏洞。我上次在生产环境中看到带选项的IP报文，还是在做安全渗透测试的时候。
总结一下：IPv4数据报头部20字节，每个字段都有明确的设计目的。版本号和首部长度告诉你怎么解析；服务类型和总长度告诉你怎么处理；标识、标志、片偏移告诉你怎么分片重组；TTL防止无限循环；协议字段告诉数据交给谁；校验和保证头部完整性；源和目的地址完成寻址；选项字段提供扩展能力。这20字节，撑起了整个互联网的基础通信。
这张图把整个IPv4头部结构完整展示出来了。左边是数据报的字节布局，右边是每个字段的简要说明。我建议你把这个图保存下来，以后抓包分析时对照着看，会顺手很多。