网络层协议仿真实战：从IP封装到路由与分片实现-代码聚汇网

网络层协议仿真实战：从IP封装到路由与分片实现

流浪小鱼·2026-08-30·阅读 21 GEO检测（免费）

网络层协议仿真IP协议

|难度：普通|阅读约 35 分钟

写在前面

十几年前我刚开始啃协议栈的时候，总觉得网络层是个“高不成低不就”的夹心层——上面有TCP/UDP这种应用能感知的存在，下面有以太网这种看得见摸得着的物理链路，IP协议躲在中间，除了配个IP地址好像就没它什么事了。直到我真正动手做网络层协议仿真，才意识到这个想法错得有多离谱。IP层才是整个TCP/IP协议栈里最需要“全局视野”的一层：它不关心你的数据是网页还是视频，不关心你的网卡是千兆还是百兆，它只做一件事——把数据包从源地址送到目的地址，中间穿过可能完全异构的网络。

这篇博文是通信协议仿真系列的第二篇，聚焦网络层协议仿真。我默认你已经对TCP/IP整体架构有基本认知，或者看过本系列第一篇关于数据链路层仿真的内容。我们会从网络层到底要仿什么、仿真环境怎么搭、IP/ARP/ICMP三类协议如何逐步实现、到测试验证和踩坑实录，走一遍完整的网络层协议仿真流程。整篇文章用的是我实际项目里的一套精简实现方案，代码以示例形式给出，你可以直接照着搭，也可以按自己的需求裁剪。

1. 网络层协议仿真：先搞清楚你要仿什么

1.1 网络层在协议栈中的定位

在动手写代码之前，先把网络层到底负责什么这件事理清楚。TCP/IP协议栈的四层模型里，网络层处于第二层，承上启下：它从传输层拿到数据段（Segment），封装成数据包（Packet），交给数据链路层去传输；同时它从数据链路层收到帧（Frame），解封装后识别上层协议，把数据交给传输层。

网络层的核心职责可以拆成四块：

寻址（Addressing）：给每个节点分配逻辑地址，就是IP地址，让数据包能识别源和目的地。
路由（Routing）：根据目的IP地址，决定数据包下一跳该往哪个方向走。
分片与重组（Fragmentation & Reassembly）：当数据包超过链路层最大传输单元（MTU）时，把包拆小，到对端再拼回去。
差错处理（Error Handling）：网络层自己也有差错报告机制，这就是ICMP协议的活儿。

做仿真的时候，这四个核心职责最好拆开实现、分开验证，别一上来就追求“全功能”，否则出了问题你根本没法定位。我的经验是先做单节点的收发，再做两个节点之间的IP通信，最后才加路由功能。

1.2 一次完整通信中网络层做了什么

拿一个最常见的场景看网络层的工作：你在自己的电脑上执行 ping 8.8.8.8，这个命令背后网络层做了什么？

第一步，应用层发起ICMP回显请求，这个报文往下传的时候，IP层会先查路由表。因为8.8.8.8不是本机所在网段的地址，所以路由表给出的下一跳是默认网关。接着IP层封装IP头：源IP填本机地址，目的IP填8.8.8.8，协议号填1（ICMP），TTL填64，然后计算头部校验和，把数据包交给链路层。

第二步，链路层需要知道默认网关的MAC地址，于是发出ARP请求去解析网关IP对应的MAC。如果ARP缓存里有记录，这一步就省了；没有的话就是一次广播请求加单播响应。

第三步，网关收到数据包之后，查自己的路由表，把包从合适的接口转出去。这个过程中如果需要经过不同MTU的网络，可能还会触发分片。

第四步，目的主机收到数据包后，IP层校验、解封装、看协议号、把数据交给ICMP模块，ICMP生成回显应答，再沿着原路返回。

所以你在终端里看到的“64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=12.3 ms”，背后其实经历了路由查找、ARP解析、多次封装解封装、TTL变化这一整套流程。仿真网络层，目标就是把这条链路上的关键环节在可控环境里重新实现一遍。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 仿真环境搭建与基础架构设计

2.1 仿真技术路线：为什么选择纯用户态协议栈

做协议仿真有好几条路可走：用网络模拟器（如GNS3、EVE-NG）、用虚拟化方案（如Mininet）、或者自己写用户态协议栈。我在这个系列里选的是第三条路——纯用户态协议栈。

原因很简单：网络模拟器虽然方便，但底层是黑盒，你改不了协议细节；Mininet偏重于拓扑实验，不适合做协议栈本身的开发调试。自己写用户态协议栈则可以完全控制每一层的处理逻辑，还能在关键位置打日志、做断点、注入异常包。配合Linux的TUN/TAP虚拟网卡，可以让自研协议栈收发真实的网络数据包，验证效果相当接近真实环境。

之前整理过一部分协议栈的源码走读和实现笔记，如果你之前接触过Linux内核里的TCP/IP协议栈数据流，会发现在用户态重写一遍网络层后，再看内核的 ip_rcv、ip_forward 这些函数会轻松很多。内核里一堆用于性能优化的指针跳转和缓存，搬到用户态仿真时都可以先砍掉，核心逻辑反而一目了然。

开发语言我用的是C，方便操作指针和字节；如果你更熟悉Go或Rust，思路完全一样，只是内存布局的处理方式稍有差别。

2.2 核心数据结构定义：从IP头到路由表

写协议栈，第一步是定义好数据结构。IP头是网络层最基础的结构，RFC 791里有明确定义。我这里直接给出一个可用于捏包、解析包的C结构体（注意用 __attribute__((packed)) 避免编译器对齐问题）：

c复制struct iphdr {
    uint8_t  version_ihl;      // 版本(4bit) + 头部长度(4bit，单位4字节)
    uint8_t  tos;              // 服务类型
    uint16_t tot_len;          // 总长度（头部+数据）
    uint16_t id;               // 标识字段，用于分片重组
    uint16_t frag_off;         // 3bit标志 + 13bit片偏移
    uint8_t  ttl;              // 生存时间
    uint8_t  protocol;         // 上层协议号：1=ICMP, 6=TCP, 17=UDP
    uint16_t check;            // 头部校验和
    uint32_t saddr;            // 源IP地址
    uint32_t daddr;            // 目的IP地址
    // 可选项和填充数据在头部之后，这里不展开
} __attribute__((packed));

头两个字节 version_ihl 在构造报文时，一般直接赋值 0x45：4表示IPv4，5表示头部长度为20字节。这是最简单的IP头，不带选项，真实世界里绝大多数包也都是这种形式。

然后是路由表项。仿真的路由表不需要像真实路由器那样复杂，一张静态路由表就够了：

c复制struct route_entry {
    uint32_t dest;        // 目的网络地址
    uint32_t mask;        // 子网掩码
    uint32_t gw;          // 下一跳网关（0表示直连）
    char     ifname[16];  // 出接口名称
    int      metric;      // 优先级，越小越优先
};

struct route_table {
    struct route_entry entries[64];
    int count;
};

路由查找逻辑就是遍历这张表，把目的IP和每条表项的掩码做按位与，匹配到网络地址的表项就是候选路由，最后选metric最小的那条。这个逻辑虽然简单，但路由表的组织方式会直接影响查找效率——真实设备用前缀树（Trie）或者哈希表，仿真环境表项数量少，线性遍历完全够用。

3. 网络层核心机制仿真实现

3.1 报文封装与解封装：最基础的收发路径

网络层仿真最难的不是单点机制，而是把封装、解封装、路由查找、分片这些环节串成一条完整的数据通路。先从最基础的收发讲起。

发送路径：传输层调用IP层的发送接口，传入目的IP、协议号和payload缓冲区。IP层按顺序完成这些事：

填充IP头各字段，源IP取当前出接口的IP。
查路由表，确定下一跳IP和出接口。
判断是否需要分片（payload长度 + IP头长度 > 出接口MTU）。
计算头部校验和。
交给链路层的发送接口，并传入下一跳的IP（供ARP解析用）。

这里有一个容易被忽视的细节：IP头的校验和只覆盖头部，不覆盖数据部分。计算方法是先把校验和字段置0，然后按16位一组做二进制反码求和，最后把结果取反写入校验和字段。收包的时候同样做一次反码求和，结果应该是0xFFFF，不是0——很多人在这里踩过坑。

c复制uint16_t ip_checksum(void *data, int len) {
    uint16_t *buf = (uint16_t *)data;
    uint32_t sum = 0;
    while (len > 1) {
        sum += *buf++;
        len -= 2;
    }
    if (len == 1)  // 奇数长度，剩一个字节需要特殊处理
        sum += *(uint8_t *)buf;
    while (sum >> 16)
        sum = (sum & 0xFFFF) + (sum >> 16);
    return ~sum;
}

接收路径：链路层把帧解出来之后，把IP包的数据部分（不含以太网头）交给IP层。IP层收包后的处理顺序是：

校验版本号，不是4就丢。
检查头部校验和，不对就丢并计数。
检查目的IP是不是本机地址或者广播地址（或本机所在子网的广播地址），不是就尝试转发。
看 frag_off 有没有带MF标志或非零片偏移，有则走重组流程。
根据 protocol 字段分发到上层协议处理函数。

封装解封装最容易出的问题就是字节序。IP头里的 saddr、daddr、id、frag_off 都是网络字节序（大端），在x86机器上直接读取打印会发现IP地址是反的，比如 0x08080808 才是 8.8.8.8。做协议仿真一定要养成习惯：内存里的多字节字段统一用网络字节序存，显示和计算性能相关的部分再转主机字节序。

3.2 分片与重组：仿真里最容易踩坑的地方

分片功能在真实网络上并不常用——现在的以太网MTU普遍是1500，TCP的MSS协商也基本能让报文直接塞进一个帧里。但做协议仿真不能不做分片，因为UDP流量和某些PPPoE环境（MTU降到1492）都会触发这个机制，而且分片重组是网络层里逻辑最绕的部分。

分片的核心规则是：所有分片除了最后一个，其他分片的payload必须是对齐到8字节的整数倍（因为片偏移字段的单位是8字节）。假设原始IP包总长度是3020字节，IP头20字节，payload是3000字节，MTU是1500。那么每个分片的最大payload是 (1500 - 20) / 8 * 8 = 1480 字节。

第一个分片：IP头 + payload[0:1480]，frag_off 的MF=1，偏移=0。
第二个分片：IP头 + payload[1480:2960]，frag_off 的MF=1，偏移=185（1480/8=185）。
第三个分片：IP头 + payload[2960:3000]，frag_off 的MF=0，偏移=370。

三个分片的ID字段相同，目的IP相同，才能被对端正确重组。

我实现分片时用的关键代码逻辑：

c复制int ip_fragment(struct iphdr *ip, uint16_t mtu, 
                void (*send_fn)(void *pkt, int len)) {
    int iph_len = (ip->version_ihl & 0x0F) * 4;
    int total_len = ntohs(ip->tot_len);
    int data_len = total_len - iph_len;
    int max_frag_data = (mtu - iph_len) / 8 * 8;
    int offset = 0;
    int frag_id = ntohs(ip->id);
    uint8_t *data = (uint8_t *)ip + iph_len;
    
    while (offset < data_len) {
        int frag_data_len = (data_len - offset > max_frag_data) 
                          ? max_frag_data : (data_len - offset);
        int frag_total_len = iph_len + frag_data_len;
        int last = (offset + frag_data_len >= data_len);
        
        struct iphdr *frag = alloc_and_copy(ip, iph_len);
        frag->tot_len = htons(frag_total_len);
        frag->frag_off = htons((offset / 8) | (last ? 0 : 0x2000));
        memcpy((uint8_t *)frag + iph_len, data + offset, frag_data_len);
        ip_checksum_and_send(frag, frag_total_len);
        
        offset += frag_data_len;
    }
    return 0;
}

重组则是反向流程：收到一个分片后，根据 (源IP, 目的IP, ID, 协议号) 四元组找对应的重组队列。队列里维护一个位图记录哪些分片已经到了，哪些还缺。每到一个分片，就填充位图、更新到达时间戳。只有MF=0的分片到了，才能知道总长度，才能判断是否收齐。如果中间有个分片丢了，必须等超时后把整个队列扔掉——这个超时值在Linux里默认是30秒，仿真的话建议设短一些，方便测试。

分片重组最容易漏的一个细节是：分片的IP头里的 tot_len 只代表这个分片自己的长度，不是一个完整包的长度。所以我有一个时期的重组代码总是提前报告“收齐了”，排查了半天，原因是拿第一个分片当成完整长度来用，后面分片压根没地方放。

3.3 路由查找与转发逻辑

有了路由表，转发逻辑就是网络层的重头戏。这里的核心差异在于：这个包是发给本机的，还是要转给别人的？

先确定几个边界条件：

目的IP是本机某个接口的IP，或者是127.0.0.1：交给本地上层协议栈处理。
目的IP是广播地址（如192.168.1.255）或组播地址：本地处理 + 可能按需转发。
其他地址：查路由表，如果匹配到表项就走转发流程，否则丢弃并返回ICMP目的不可达（net unreachable）。

转发流程比本地收包多几步：

把TTL减1（RFC规定转发时必须减，本地收包不用减）。
TTL减到0就丢弃，发ICMP超时报文（time exceeded）。
重新计算IP头校验和（因为TTL变了）。
如果下一跳的出口MTU小于包长，触发分片。
查ARP表拿下一跳MAC，重新封装成帧发给出去。

这里有个性能小技巧：TTL变化后不需要完整重算所有字段的校验和，RFC 1624提供了增量更新的算法，只调整TTL和校验和相关的两三个字段就行。但这个优化在仿真环境里意义不大，直接全量重算更稳妥，代码还简单。

路由表查找本身有个容易出错的点：掩码匹配的优先级。路由表里可能同时存在 192.168.1.0/24 和 192.168.1.128/25 两条表项，如果目的IP是 192.168.1.200，按最长前缀匹配原则应该选 /25 那条。很多人实现的时候先匹配到 /24 就直接返回了，这在路由表里存在重叠网段时会出大问题。所以即使表项不多，也不要提前return，应该先把所有匹配项遍历完，取掩码最长（即网络号位数最多）的那条。

c复制struct route_entry *route_lookup(struct route_table *rt, uint32_t daddr) {
    struct route_entry *best = NULL;
    int best_prefix_len = -1;
    for (int i = 0; i < rt->count; i++) {
        uint32_t masked = daddr & rt->entries[i].mask;
        if (masked == rt->entries[i].dest) {
            int prefix_len = __builtin_popcount(ntohl(rt->entries[i].mask));
            if (prefix_len > best_prefix_len) {
                best = &rt->entries[i];
                best_prefix_len = prefix_len;
            }
        }
    }
    return best;
}

4. 配套协议仿真：ARP与ICMP

4.1 ARP缓存与地址解析

网络层离开ARP几乎寸步难行。虽然ARP严格来说算链路层的协议，但它的请求和响应都是为IP服务发起的，做网络层仿真时必须一起做。

ARP的核心逻辑不复杂：给定一个目标IP，找到对应的MAC地址。实现上要维护一张ARP缓存表：

c复制struct arp_entry {
    uint32_t ip;
    uint8_t  mac[6];
    time_t   last_used;
    int      state;  // 0=INCOMPLETE, 1=REACHABLE, 2=STALE
};

发送任何IP数据包之前，都要先查ARP缓存。缓存未命中就发ARP请求（目的MAC填广播地址 FF:FF:FF:FF:FF:FF），同时把待发送的包暂时挂在队列里，等ARP响应回来之后再继续发送。Linux里的做法是把ARP请求的发送频率限制在每秒最多1次，避免目标主机不存在时广播风暴。仿真环境里也建议加这个限制，不然测试的时候万一目标IP错了，日志会被ARP请求刷屏。

还有一类常见问题：ARP缓存表需要老化。比如你仿真一台设备，把它的网卡down掉再up，它的IP可能是新的——如果对端ARP缓存里还是旧的MAC，包就发不过去了。实际测试时我经常手动清ARP缓存来模拟这种场景。

4.2 ICMP差错报文与回显请求

ICMP协议在网络层仿真的角色，既是“排错工具”，也是“协议栈的反馈通道”。仿真实现里至少要做三类处理：

回显请求/应答（Echo Request/Reply）：这是ping使用的类型。收到type=8的请求后，把type改为0，交换源目的IP，重新计算校验和，原样回发。要注意的是，ICMP的校验和覆盖ICMP头部和整个数据区，跟IP头校验和只算头部不一样。

目的不可达（Destination Unreachable）：类型3。当我收到一个包，路由查找失败，或者本机监听的端口没人接，就应该给源地址发一个ICMP目的不可达报文。这个报文有个特别之处：它要把触发错误的那个IP包的IP头 + 至少前8字节数据一并放进ICMP的payload，方便对端定位是哪个连接出了问题。

超时（Time Exceeded）：类型11。TTL减到0或者重组超时，都会触发这个报文。traceroute这个工具就是靠TTL从1开始递增、逐跳收集type=11报文来画路由路径的。

ICMP报文段格式可以用这个结构体表示：

c复制struct icmphdr {
    uint8_t  type;
    uint8_t  code;
    uint16_t check;
    uint16_t id;      // echo专用
    uint16_t seq;     // echo专用
    // 差错报文复用其余字段存放生成该报文的原包信息
} __attribute__((packed));

实现上有个要注意的细节：ICMP差错报文发送时，源IP要填产生该错误的那个接口的IP，而不是随便填一个。比如路由器从eth0收到一个转发失败的数据包，发ICMP目的不可达时源IP应该是eth0的IP，这样回包才能被正确路由回来。

5. 网络层协议的测试验证与常见问题

5.1 测试用例设计：从简单到复杂的验证路径

协议仿真的测试不能靠“写完觉得没问题就上”，必须设计一套从简单到复杂的验证路径。我的做法分四步：

第一步：单节点自环测试。在同一个仿真实例里，通过本机回环接口发送一个IP包到本机自己的IP。这一步用来验证IP头的封装解封装是否正确、校验和是否合法、协议分发是否工作。

第二步：双节点互通测试。两个虚拟节点直连，配置同一网段的IP，什么路由都不配，验证ARP解析 + IP收发。从A ping B，能通就说明最基础的数据通路没问题。

第三步：跨网段路由测试。三个节点组成A - Router - B的拓扑，A和B在不同网段。A配置默认网关指向路由器，B也一样。这步验证查表转发、TTL递减、下一跳MAC重写这些转发路径上的核心逻辑。

第四步：异常场景测试。手工构造各种畸形包：校验和错误的、TTL为0的、需要分片的、分片乱序到达的、分片永远凑不齐的。这一步最考验协议栈的健壮性，也是仿真和真实协议栈行为差异最大的地方——真实内核会默默丢弃并统计计数，你的仿真协议栈如果不打日志，可能丢包了都看不出来。

另外强烈建议测试时在关键路径埋好日志点，比如：

code复制[IP] recv pkt src=192.168.1.1 dst=192.168.1.2 proto=1 len=84
[IP] route lookup: 192.168.2.3 -> via 192.168.1.254 dev eth0
[IP] frag: off=0 len=1480 mf=1
[IP] reassemble: queue 0x3e8 got 2/3 frags

这种日志在问题排查时就是救命稻草。

5.2 常见问题排查表

做网络层仿真，有几个问题出镜率极高，按我的经历整理成一张表：

现象	可能原因	排查方法
双节点直连ping不通	ARP解析失败或IP地址配置冲突	先看ARP表是否有对应条目，抓包确认是否有ARP请求发出
跨网段ping不通	路由表缺静态路由，或TTL递减后校验和没重算	在转发节点打印路由查找结果，确认下一跳是否正确
大包不通、小包能通	MTU配置不一致，或分片逻辑有bug	用小包确认通路正常后，逐步增大payload测试边界值
收包能收到但上层说数据不对	字节序转换遗漏或校验和计算错误	用逐字节打印工具对比发送端和接收端的16进制数据
转发后TTL没变化	转发路径没有执行TTL减一逻辑	在转发函数里加断点检查TTL字段
ICMP回收不到type=11	超时触发条件没写对，或回收路径路由不对	检查分片重组超时队列是否正常清理，sin用固定源IP发送错误报文

分片重组的问题在这里尤其容易复现：你用UDP发送一个3000字节的报文，对端上层始终只收到20字节，或者收到两段不完整的数据，大概率是重组队列的位图管理出了问题。不要怀疑是数据内容错误，先验证每个分片的 frag_off 和 MF 标志按你的预期设置好了，再验证对端的重组逻辑里，每个分片的偏移量计算是否一致。

一个特别隐蔽的坑是分片包的 frag_off 字节序。你在构造分片时如果直接写 frag_off = htons(mf_flag | (offset / 8))，这里的 mf_flag 必须是网络字节序视角下的值。我早期实现里直接 frag_off = htons(0x2000 | offset/8)，看起来没问题，但如果 offset/8 超过255，低字节和高字节就会错位，重组永远不成功。正确处理是先拼接好一个16位的整数值，再统一做字节序转换。

6. 网络层仿真的坑与我的实操心得

6.1 字节序：一半的bug都是它引起的

做协议仿真，如果你把整个项目里所有“查不出原因”的bug做个统计，字节序问题绝对占一半以上。我最痛苦的经历是整个周六下午都在查一个转发场景的丢包问题：每过一个节点，TTL就莫名其妙暴涨。最后发现是某处把 ttl 当成16位字段用 ntohs 转了，本来应该原样递减的字段被翻转了。

字节序问题之所以在仿真里特别突出，是因为你用的开发机几乎都是x86/ARM小端架构，而网络协议规定所有多字节字段都是大端（网络字节序）。最稳妥的办法是：

所有从网络上收进来的多字节字段，先转成主机字节序再进处理逻辑。
所有构造报文往外发的多字节字段，最后统一转成网络字节序。
别在同一个表达式里混用原始值和转换值，很容易看混。

6.2 日志比调试器好用

内核协议栈里可以用 printk、tracepoint、ftrace 这些工具来观察行为，但在自己写的仿真协议栈里，最直接的手段就是你自己的日志系统。我踩过的坑是初期日志打得太稀疏，出了bug只能靠猜；后来把日志打到每个关键路径，定位问题的时间从小时级降到了分钟级。

工业级协议栈里通常会有专门的调试开关，比如打开 DEBUG_IP_FRAG 就输出分片相关的详细日志，打开 DEBUG_ARP 就输出ARP解析过程。仿真项目也建议这么做，否则日志一多，正常的转发信息全被淹没，反而找不到有用的线索。

6.3 仿真代码和真实协议栈的差距

每次做完一个模块，我都会对照着Linux内核里对应的实现走读一遍代码。比如IP接收路径的 ip_rcv 和 ip_local_deliver，看内核是怎么处理路由查找失败、怎么处理畸形包的。对照下来你会发现，仿真实现往往是“只做正确路径上的事情”，而真实的协议栈把大量的边界条件都写进了代码里。这些边界条件——IP头太短、协议版本不对、选项长度非法——就是健壮性差距的来源。

作为后续扩展方向，你可以在仿真基础上继续做这些事：

增加DHCP客户端，让节点自动获取IP地址，而不是手动配置。
增加静态路由配置协议（比如模拟简单的路由协议），让路由表能动态变化。
把网络层和本系列第一篇做好的数据链路层对接，再和后续的TCP/UDP层打通，构成一个完整的协议栈闭环。
做一个可视化面板，把节点之间的路由路径、分片状态实时画出来，排错效率还能再上一个台阶。

我个人在做完网络层仿真之后，反过来再去读Linux的tcp协议栈数据流走读笔记，理解深度和之前完全不是一回事。很多原来觉得“这代码为什么这么绕”的细节，放在“为了支持任意拓扑、任意链路类型、任意异常场景”的视角下，就都说得通了。仿真不是为了替代真实内核，而是为了让你能在一个没有干扰的环境里把每一层协议吃透。这大概就是协议仿真项目最大的价值所在。