企业官网建设流程全解析

1. 为什么用C语言模拟路由器，而不是装个模拟器

做网络实验的人，大多碰过这么几个选项：买几台真实设备、在电脑上装模拟器、或者用C语言自己动手写一个路由进程。前两个方案上手快，图形界面一点，拓扑一拖，就能看到路由表转发表跑起来。但有个问题始终绕不过去——模拟器把过程藏得太深了。你在界面上看到“路由表更新成功”，看到的只是一个结果，至于这个结果是怎么一步步算出来的，中间的关键结构长什么样，哪些环节可能出错，基本是黑盒。

用C语言模拟路由器，思路完全不一样。它不是去模拟一个完整设备，也不是替代模拟器，而是用代码去表达“一台路由器内部究竟做了什么”。简单说就是：你写一个常驻进程，给它几个虚拟网口，让它在内存里维护一张路由表，然后处理流入的报文，逐条匹配转发表，算下一跳、改源目的MAC、扣TTL、再发出去。每一步都能打印、能断点、能单步看状态。这个价值，是图形化模拟器给不了的。

它适合谁？如果你刚学完计算机网络，知道路由器的基本概念但是对“转发”这件事只有模糊印象，这类项目很值得动手写一遍。如果你在准备网络相关的笔试面试，拿这个项目练手，比背书要牢靠得多。如果你本身就是做网络开发或者嵌入式开发的，自己实现一个简化版路由进程，也能帮你把数据通路的每个细节串起来。

我们在下面设计的这个版本，属于“能跑通、能演示、能观察”的教学型模拟器。它用纯C实现，不依赖任何平台特定的网卡驱动，虚拟网络接口直接通过UDP socket模拟。也就是说，你在一台普通的Linux或者macOS机器上就能编译运行，不需要两叁台真机。整个程序代码量控制在千行左右，拆成几个模块，逻辑清楚，适合当学习模板来用。

2. 总体设计思路：把路由器拆成几个黑盒子

2.1 一台路由器转发到底做了什么事

把问题简化到最底层，一台路由器收到一个数据包之后，只关心四件事：包是谁发来的、包要去找谁、我怎么把这个包送到下一跳去、以及如果送不到怎么处理。

第一件事靠解封装看源IP和源MAC；第二件事靠查路由表；第三件事靠重写以太网帧的源/目的MAC，然后从对应的出口物理口发出去；第四件事靠TTL耗尽策略和ARP请求失败处理。这四件事环环相扣，缺一个环节，转发就断了。

写模拟器的时候，我建议你不要上来就写代码，先画一张数据流图。我当年第一次写这种项目就是没画图直接开干，写到ARP模块的时候发现收发两个方向的数据结构不一致，返工半天。后来老老实实把流程理顺，就好写多了。

简化后的转发流程大致长这样：

1. 从某个虚拟网口收到数据帧。
2. 校验帧类型（我们只处理IPv4，别的统统丢弃）。
3. 校验目的MAC，如果不是本路由器的某个接口MAC，或者不是广播MAC，直接丢。
4. 解析出IP头，查路由表。
5. 查不到路由，回ICMP目的不可达，或者直接丢弃（看配置）。
6. 查到了，检查TTL，减一，重新计算校验和。
7. 通过ARP表找到下一跳的MAC地址；如果不在ARP缓存里，先发ARP请求，把包暂时挂起。
8. 重写帧头，调用出口虚拟网口函数发送。

这个流程里每一步对应一个C函数，职责单一、参数明确，方便测试。

2.2 模块怎么切分

我切分了七个模块，每个模块对应一个C文件加一个头文件，层次依赖尽量是“单向的”——上层调用下层，下层不反向依赖上层。

• main.c：入口，负责初始化、启动定时器、循环接收。
• config.c：读配置文件，初始化路由器和虚拟网口。
• interface.c：虚拟网口驱动，内部封装UDP socket收发。
• ethernet.c：以太网帧封装和解封装（也就是模拟帧头）。
• arp.c：ARP表管理、ARP请求和应答处理。
• ip.c：IP头解析、校验和处理。
• route.c：路由表维护和最长前缀匹配。

有的读者可能会问：为什么不加RIP或者OSPF模块？这个问题问得对。严格来说，路由器的核心工作分两部分：路由学习（控制平面）和包转发（数据平面）。我们的模拟器重点放在数据平面，控制平面只用静态路由——也就是从配置文件里手动写死几条路由。这样可以先把转发链路跑通，避免一个项目里同时堆太多东西把自己绕晕。后面如果你想深入控制平面，可以在route.c里面扩展一个RIP模块，思路是相通的。

2.3 数据结构的整体预览

数据结构是整个项目的骨架。我用四张表把状态都装起来：

• 接口表：记录每个虚拟网口的IP、掩码、MAC，以及关联的socket fd。
• 路由表：记录目的网络、掩码、下一跳、出接口、优先级、开销。
• ARP表：记录IP到MAC的映射，以及表项老化时间。
• 转发暂存队列：用于处理“ARP未命中时，先停包、等ARP响应回来再放行”的场景。

初学的时候最容易做错的一步是把路由表和ARP表混在一起。有人直接在路由表里加个MAC字段，觉得一步到位。这么做在只有一个下一跳的时候能跑，一旦有等价多路径或者需要做ARP缓存老化，就会后悔。正确思路是：路由表管“往哪走”，ARP表管“下一跳长什么样”，两回事，别混。

3. 核心难点一：虚拟网口怎么实现

3.1 用UDP socket模拟物理端口

想要模拟两台路由器相连，传统做法是开TAP虚拟网卡，让数据包真正走内核协议栈。这个方案太复杂了，权限要求高，还会遇到IP转发开关、系统路由表干扰等问题。我选择了一个更巧的办法：用UDP socket模拟一条“虚拟链路”。

每个接口绑定一个UDP端口，收到UDP载荷就当作一个完整的以太网帧来处理。两个接口之间如果想互联，只需要把各自的“对端地址”配上——A口的远端UDP端口就是B口本地的UDP端口，这样一来，A口调用sendto()发出去的数据包，B口就通过recvfrom()收到了，行为很像一根网线连着两个网口。

这个方案的巧妙之处在于：内核的UDP协议栈替我们处理了全双工信道的底层细节，你不用管并发收发问题，专注在帧处理逻辑上就够了。

typedef struct net_interface { char name[16]; // 接口名，例如 eth0 uint32_t ip_addr; // 本接口IPv4地址 uint32_t netmask; // 子网掩码 uint8_t mac_addr[6]; // 本接口MAC地址（手工指定的虚拟MAC） int sock_fd; // UDP socket句柄 struct sockaddr_in peer; // 对端地址，也就是“对端路由器的对应接口” } net_interface_t;

注意一个问题：真实的以太网是一个多路访问链路，多个设备共享同一条线路。我们UDP点对点的模型模拟不出来广播。解决方案很简单，模拟广播时，用一个“广播组列表”——每个接口维护一个组播发送列表，向所有邻居各发一份UDP包，从效果上模拟广播。

3.2 为什么不用真实网卡RAW套接字

也有读者问：那我直接写一个raw socket，从真实网卡拉包处理，是不是更真实？

从体验上确实更真实，但从工程实践上看，坑太多了。首先生成ARP报文需要手动构造完整帧，写起来很繁琐；其次，本机发出的包不会从raw socket的接收路径进来，你处理回环包的方式要特殊化；再有，真实网卡收包涉及多队列、中断、内核协议栈抢占，很多干扰因素不是你想模拟的部分。顶多做到后面你自信心爆棚了，再写一个基于PCAP的版本。初版用UDP模拟链路，把精力花在转发本身上，绝对划算。

3.3 接口模块的收发封装

接口模块的发送函数设计成这个样子：

int interface_send(net_interface_t *iface, const uint8_t *frame, size_t len) { return sendto(iface->sock_fd, frame, len, 0, (struct sockaddr *)&iface->peer, sizeof(iface->peer)); }

接收就更简单了，主循环里对每个接口的socket做一次recvfrom()，非阻塞轮询。

为了让调度公平，接收循环的伪代码如下：

while (running) { for (int i = 0; i < iface_count; i++) { int n = recvfrom(iface[i].sock_fd, buf, sizeof(buf), MSG_DONTWAIT, ...); if (n > 0) { handle_frame(&iface[i], buf, n); } } check_timers(); // ARP老化、暂存队列超时重传 usleep(500); // 留一点CPU余量 }

这个500微秒的sleep很有必要。没有它，进程会把CPU吃满，尤其是在有多个接口轮询的时候，你会发现CPU温度比实验现象还显眼。

4. 核心难点二：路由表与最长前缀匹配

4.1 路由表为什么用链表而不是哈希表

这一点值得说透。很多人想当然觉得哈希表快，但是在模拟路由器里，路由表的规模顶多几十条，用链表完全没有性能问题。反而链表实现最长前缀匹配特别直观，你可以把表中的每条路由按掩码长度从大到小排序，查表时从头扫到尾，命中第一跳就是最长匹配，逻辑不可读性低。

也许有读者会说，可是在真实设备里，路由表用前缀树、哈希、各种优化结构，链表的效率不够。这当然对。但模拟器追求的不一样，它优先考虑代码可读性、可调试性。你拿着gdb或者打印日志，一条一条看查表过程多舒服。等你想把它做得接近工程化，再换成前缀树版不迟。

路由表节点结构体：

typedef struct route_entry { uint32_t dest; // 目的网络地址 uint32_t mask; // 掩码 uint32_t gateway; // 下一跳IP，直连网段时为0 char out_iface[16]; // 出接口名 int metric; // 路由开销 struct route_entry *next; // 链表指针 } route_entry_t;

4.2 直连路由与静态路由的注入

初始化的时候，路由器要根据每个接口的IP地址和网卡掩码自动生成直连路由。比如eth0的IP是192.168.10.1/24，那么对应就是一条目的192.168.10.0、掩码255.255.255.0、下一跳0、出接口eth0的路由。判断一个目的IP是不是直连可直达，只需把目的IP和掩码做按位与，结果等于接口IP和掩码按位与的结果即可。

静态路由通过配置文件注入，格式类似：

route: 10.0.20.0/24 via 192.168.10.254 dev eth0 metric 1

注意这里有个顺序问题：配静态路由时，如果下一跳不是直连网段上的设备，这个路由本质上是“不可达的”。所以解析配置文件的时候，要校验下一跳IP是否在某条直连路由的范围内，不在就报配置错误。我第一次跑通这个逻辑时，犯过配一个中间路由器IP的错，结果是查路由表能查到但ARP永远请求不到，排查了好久才发现是下一跳选择的问题。

4.3 最长前缀匹配的具体实现

route_entry_t *route_lookup(uint32_t dst_ip) { route_entry_t *best = NULL; int best_plen = -1; for (route_entry_t *r = route_table; r != NULL; r = r->next) { int plen = mask_to_prefix(r->mask); if (plen > best_plen && (dst_ip & r->mask) == (r->dest & r->mask)) { best = r; best_plen = plen; } } return best; }

细心的读者会发现这里有个小优化空间：既然初始化阶段已经按掩码前缀长度降序排列了，那找到第一个匹配返回就行，可以不维护best_plen。两种方式我都在不同版本里用过。排序版代码更短，但不利于你后面扩展“路由优先级”的概念；维护best_plen版略微繁琐，但天然支持“掩码长度相同、比较metric”的逻辑。建议读者写维护best_plen这版，因为后期如果加多路由协议，你一定会需要比较不同来源的优先级。

4.4 回环路由与默认路由

我在配置里总是加一条127.0.0.0/8 via loopback的回环路由，有些读者可能会扔。这条路由在真实系统中由内核维护，我们模拟器里加不加其实不影响转发逻辑。加上它的意义在于，当你用ping来测试路由进程时，发给本机的包也能被识别。比如你从路由进程自己所在的终端发一个ping 127.0.0.1，如果没有这条路由，进程会把这个包从某个接口发出去，然后因为找不到对端而报错，看着莫名其妙。

默认路由（0.0.0.0/0）我建议配置文件里默认加一条指向某个下游。没有默认路由时，任何未匹配的包都会被丢弃，这符合真实路由器的行为，但是初学者排查问题时少了一个分支，往往更难定位是“查表失败”还是“ARP失败”。

5. 核心难点三：ARP模块的完整实现

5.1 ARP表结构设计与老化机制

ARP模块是所有模块里最容易写乱的地方。问题在于它要同时处理两类角色：发ARP请求的一方，和回ARP应答的一方。一个程序要能同时扮两个角色，状态机就要理清楚。

ARP表项结构：

typedef struct arp_entry { uint32_t ip_addr; uint8_t mac_addr[6]; time_t timestamp; // 最后更新时间 int state; // 0 = 未解析, 1 = 已解析 struct arp_entry *next; } arp_entry_t;

老化时间我设置成60秒。定时器每5秒扫一遍表，超过60秒没更新的表项删除掉。这个机制很重要，模拟的是真实设备里ARP缓存因为拓扑变化而不失效的场景。你没做老化之前，测试时改了一台虚拟机的MAC地址，结果路由器一直用旧MAC发包，那种抓狂的感觉我不想再体验第二遍。

5.2 包暂存队列与重传机制

当查路由表找到下一跳是192.168.10.254，ARP表里却没有对应MAC时，标准做法是：构造ARP请求发出去，同时把这个待发送的IPv4包挂到“待解析队列”里。等ARP应答回来，再从队列里取出完整的包，填充目的MAC，走发送流程。队列节点结构：

typedef struct pending_pkt { net_interface_t *in_iface; // 从哪个接口进来的（用于记录入接口信息） net_interface_t *out_iface;// 要往哪个接口发 uint8_t frame[2048]; // 暂存完整以太网帧 size_t frame_len; uint32_t target_ip; // 待解析的下一跳IP int retries; // ARP重试次数 time_t first_sent; // 首次发送ARP请求的时间 struct pending_pkt *next; } pending_pkt_t;

重传策略：每1秒检查一次，对同一目标IP，如果还没收到ARP应答，重新发ARP请求，最多重试3次，超过3次就丢弃这个包，同时把ARP表状态标成“解析失败”。这一步对应真实世界的“ARP失败后发ICMP主机不可达”行为。不少初学者没做重传，一旦ARP请求在网络上丢了，包就永久卡在队列里，连超时都没有，进程跑着像死循环一样。

5.3 ARP报文构造

ARP报文本身长度固定28字节，加上以太网头部就是42字节，不够46字节还要补零到最小帧长。写构造函数前，最稳妥的方法是先画一个字段偏移图。我画过一张，到现在还记得：

• 以太网头：目的MAC(6) + 源MAC(6) + 类型(2) = 14字节
• ARP头：硬件类型(2) + 协议类型(2) + 硬件地址长度(1) + 协议地址长度(1) + 操作码(2) = 8字节
• ARP数据：发送端MAC(6) + 发送端IP(4) + 目标MAC(6) + 目标IP(4) = 20字节

总长度28字节，加上刚才的14字节字节就是42。这个计算很容易错，尤其是目标MAC“填0表示未知”这一点，我在初版代码里把目标MAC填成了自己接口的MAC，导致路由器收到自己发出的ARP请求并回了一个应答，看起来像精神分裂。这个坑踩完之后我学乖了，所有报文构造代码都照着一张手写的字段偏移表来写，不凭记忆。

构造ARP请求的核心片段：

uint8_t buf[64]; eth_hdr_t *eth = (eth_hdr_t *)buf; arp_pkt_t *arp = (arp_pkt_t *)(buf + 14); memcpy(eth->dst_mac, broadcast_mac, 6); // ff:ff:ff:ff:ff:ff memcpy(eth->src_mac, iface->mac_addr, 6); eth->ether_type = htons(0x0806); arp->hw_type = htons(1); // 以太网 arp->proto_type = htons(0x0800); // IPv4 arp->hw_len = 6; arp->proto_len = 4; arp->opcode = htons(1); // 1 = 请求 memcpy(arp->sender_mac, iface->mac_addr, 6); arp->sender_ip = iface->ip_addr; memset(arp->target_mac, 0, 6); arp->target_ip = target;

注意大小端处理。x86上默认小端，而网络字节序是大端，所有多字节字段都必须用htons、htonl转换。这一处写反，ARP应答回不来，查错半天才发现是字节序问题的人不在少数。我在代码里把所有构造报文的函数统一用htons包一层，不嫌烦，就为了少出一次这种低级错误。

5.4 ARP应答处理流程

收到一个ARP请求包后，先检查目标IP是不是自己某个接口的IP。如果是，且操作码是请求，则构造应答，源目的MAC翻转，操作码改成2，调interface_send发送。应答的帧头里，目标MAC填请求方的MAC，这个地址来自收到的ARP请求报文里的发送端MAC。

收到ARP应答后，把发送端IP和MAC更新到ARP表，然后遍历整个待解析队列，找出所有目标IP等于应答方IP的包，补全帧头目的MAC后发送出去。

我看到过有人用“ARP应答到达后，只更新ARP表，忘了放行暂存队列”的实现，导致网络表现为“第一包丢失，后面都正常”。第一包就是ARP学习过程中被暂存的包，丢了非常难查。我特意在代码注释里写上：此处必须遍历pending队列，千万别漏，就是怕自己以后又踩一遍。

6. 核心难点四：IP包处理与转发收尾

6.1 IP头校验和的计算

IP头校验和的计算是所有网络开发者的基本功，实现时最容易错的点是“反码求和”的顺序。算法不复杂：先把校验和字段当成0，然后对IP头每16位做二进制反码求和，结果再取反，填入校验和字段。

接收校验的时候同样把整个IP头按16位累加，如果结果得到0xFFFF，说明校验和正确。初学者容易在这处犯迷糊：发送时填入的结果要使校验和字段本身参与累加后得到一个全1的结果。所以发送时的公式是：校验和 = ~sum(头)，而接收验证的判断条件是：sum(头) == 0xFFFF。

C代码实现里有个经典技巧：先sum += *buf++;把每个16位都加进来，溢出进位要循环加回来。

uint16_t checksum(uint16_t *addr, int count) { uint32_t sum = 0; while (count > 1) { sum += *addr++; count -= 2; } if (count == 1) sum += *(uint8_t *)addr; while (sum >> 16) sum = (sum & 0xffff) + (sum >> 16); return (uint16_t)(~sum); }

而在每跳转发更新TTL后，IP头校验和必须重算。这是新手最常忽略的步骤。TTL变了，校验和却不更新，下一跳路由器校验失败直接丢弃。这个bug在模拟环境里不好察觉，因为整个环境都是我自己的代码，接收端校验写得放松的话可能就放过了，一旦接入真实协议栈，立刻露馅。

6.2 TTL处理和分片问题

TTL处理要注意一个细节：如果TTL减一之后结果为0，路由器应当丢弃这个包，并给源IP回一个ICMP超时消息。在整个模拟器里，ICMP只是简单封装成一种内部消息类型。回ICMP的时候，源IP要写成收到包的接口IP，而不是包头的源IP。

关于分片，我做了个简化决策：模拟环境里所有包的MTU设为65535，不实际触发分片。但你必须在代码里留出处理分片标志位的位置。否则以后把包长度降到1500测试时，会发现大包静默丢失无法定位原因。接口结构体里我预置了一个mtu字段，虽然初版都用大值，但字段在那里，逻辑入口也有注释说明，后续要模拟分片只需要在入口判断包长是否超过接口MTU，然后走分片路径。

6.3 以太网帧的源目的MAC替换原则

转发能不能成功，关键看两点：ARP表查到的下一跳MAC是不是正确；重写之后的帧头是不是“入接口收包时的状态”被破坏了。这里说的破坏不是内存溢出，而是逻辑上的串台。我在初版实现里，直接把收到的frame缓冲区的源MAC改掉，目的MAC改掉后发送。结果发现，源接口是eth0的包，重写时我用了eth1的MAC作为源MAC，转发是通了，但抓包看会发现源MAC和发送接口不一致。真实设备查这个属于“源MAC与出接口不匹配”，会导致对端设备收到来源非法的帧，影响二层转发。

修法很简单：构造一个新的发送缓冲区，不要把原帧改完之后再发。原帧可能还挂在暂存队列里，留着原始数据对排错有好处。

uint8_t out_frame[2048]; eth_hdr_t *oeth = (eth_hdr_t *)out_frame; memcpy(oeth->dst_mac, nexthop_mac, 6); memcpy(oeth->src_mac, out_iface->mac_addr, 6); oeth->ether_type = htons(0x0800); memcpy(out_frame + 14, pkt->data + 14, len - 14); // 注意：IPv4头从第14字节开始，直接拷贝，然后调整IP头字段

有经验的读者会问：为什么不把调整TTL和校验和放在拷贝到发送缓冲之后再做？因为这样更简洁，只改发送缓冲区的IP头，不影响暂存队列里的原包。对，这就是我的建议，发一个封装干净、独立的包出去，排错时会省非常多时间。

6.4 入接口与出接口相同时的处理

做模拟实验时，拓扑里经常出现一条静态路由的下一跳和源在同一个接口网段的情况——比如路由器收到来自192.168.10.0/24的包，查表发现下一跳还是192.168.10.1。这本身不合理，真实设备一般会避免这种配置，但万一配了，代码要能识别出“包从一个口进，又从同一个口出”的场景。

处理方式是：在查找出接口时，如果out_iface == in_iface，打印一条报警日志，并选择丢弃。因为真实设备里，一个二层域内不会通过路由器绕回去转发这么干。否则你的模拟环境广播环路马上教做人。

7. 实操过程：从零搭一台模拟路由器的完整步骤

7.1 实验拓扑设计

为了把转发逻辑讲透，我设计了一个最简单但能覆盖所有主要场景的拓扑：

• 主机A，模拟为192.168.10.2/24，通过UDP链路连到路由器R1的eth0。
• 路由器R1的eth0是192.168.10.1/24，eth1是192.168.20.1/24。
• 主机B，模拟为192.168.20.2/24，连到R1的eth1。
• 在R1的路由表里配置一条静态路由：目的0.0.0.0/0，下一跳为192.168.20.254（这里只做演示，模拟核心转发路径）。

更完整的拓扑可以放两台路由器串行连接，但初版建议只搞一台路由器加两个虚拟主机。把单路由器的转发链路打通了，再扩展多路由器，逻辑上就是重复调用而已。

7.2 配置文件的格式与解析

配置文件我用的是极简的键值对风格，避免引入第三方的解析库。示例：

# 接口配置 interface eth0 addr 192.168.10.1 mask 255.255.255.0 mac 02:00:00:00:00:01 interface eth1 addr 192.168.20.1 mask 255.255.255.0 mac 02:00:00:00:00:02 # 链路对端 link eth0 peer 127.0.0.1:7001 link eth1 peer 127.0.0.1:7002 # 静态路由 route 192.168.20.0/24 via 0.0.0.0 dev eth1 metric 1 route 0.0.0.0/0 via 192.168.20.254 dev eth1 metric 10

用C标准库的fgets加sscanf就能解析，不需要什么复杂状态机。注意解析MAC地址时要用%hhx来按字节读入，不然后果是MAC地址被读成一个整数然后存进uint8_t数组时发生截断，抓包后看到的MAC全是错的，排查难度会很大。

7.3 虚拟主机的实现

测试需要发数据包，手动构造太麻烦。我写了一个极简的虚拟主机程序，同样基于UDP socket。它绑定到某个端口后，可以执行三个命令：

• ping <目标IP>：构造一个ICMP回显请求并发送，等待回显应答。
• sendtcp <目标IP> <端口>：构造一个TCP SYN包（尽力而为，只测试转发路径）。
• arping <目标IP>：发送ARP请求，观察MAC学习过程。

虚拟主机的数据链路层也要封装一个以太网帧头，源MAC写死，目的MAC在“目标IP是直连网段时”填目标IP对应的MAC，目标MAC在“目标IP需要经路由器转发时”填默认网关MAC。这一层逻辑和真实主机的行为是对应的，初学阶段虚拟主机程序最好自己写一遍，不要抄，写一遍才会懂什么叫做“网关的MAC和目的IP的MAC是两回事”。

7.4 编译与运行流程

整个项目用CMake管理，编译只需要几条命令：

mkdir build && cd build cmake .. && make

本地测试时，先启动两个虚拟主机进程，分别监听7001端口和7002端口，再启动路由进程。路由进程启动时会读取配置文件，建立接口socket，初始化路由表和ARP表，然后进入主循环。

验证流程建议按这个顺序来：

1. 先不配置任何静态路由，只验证直连网段内的通信。从主机A ping192.168.10.1，目的MAC就是路由器eth0的MAC，包应该被路由进程接收，并且回包能原路返回。
2. 加一条静态路由，测试跨网段转发。从主机A ping192.168.20.2，看看路由器是否完成了“从eth0收，从eth1发”的转发。
3. 检查抓包输出，去验证源MAC、目的MAC、TTL这几个字段的变化是否符合预期。

那一次的实验结果我到现在都记得：第一次跑通跨网段ping时，控制台里打出完整的日志，从帧收进入到查表、ARP解析、重写、发出，每一步都看得清清楚楚，那种“原来数据包是这样在路由器里走的”的通透感，比看十遍教科书都来得直接。

7.5 日志设计：把整个转发过程可视化

调试这种程序，打印日志是唯一的制胜法宝。我设计了一套分级日志系统，三个级别：

• 级别1：只有帧收发的摘要，适合最终演示。
• 级别2：增加路由查找、TTL变化、ARP状态变化，适合排查大多数问题。
• 级别3：打印完整帧内容，用十六进制dump形式，适合处理“字段填错”类问题。

日志格式统一成一行，例如：

[2025-01-15 12:33:45] eth0 RX 60 bytes, src=02:00:00:00:00:02, dst=02:00:00:00:00:01, type=0x0800, sip=192.168.10.2, dip=192.168.20.2 [2025-01-15 12:33:45] route lookup 192.168.20.2 -> match 192.168.20.0/24 via 0.0.0.0 dev eth1 [2025-01-15 12:33:45] nexthop 192.168.20.2, ARP lookup miss [2025-01-15 12:33:45] send ARP request for 192.168.20.2 via eth1 [2025-01-15 12:33:45] ARP reply received, update arp table: 192.168.20.2 -> 02:00:00:00:00:02 [2025-01-15 12:33:45] TX on eth1, src=02:00:00:00:00:01, dst=02:00:00:00:00:02, type=0x0800, ttl=63

这套日志格式是我调试时最大的帮手。尤其是“ARP lookup miss”和“send ARP request”这两行，能瞬间定位问题方向——如果是查表失败，根本走不到ARP那一步，日志里只会有route lookup失败的消息；如果走到了ARP但一直miss，问题出在ARP交互上。

8. 常见问题与排错技巧实录

8.1 收不到包：多半是socket初始化顺序不对

模拟路由器和虚拟主机都基于UDP，最容易出现的问题是：对端还没bind端口，你就开始sendto，结果包被系统静默丢弃。测试时务必按照“先启动所有进程，再发包”的顺序。如果包总是丢，用strace看一下socket、bind的调用顺序，基本秒懂。

还有一种情况是sendto失败返回-1，错误码是ECONNREFUSED（111）。这是因为对端socket没有bind或者端口不对。这个错误码是UDP协议栈特有的，TCP链接拒绝也是111，但UDP这里特指ICMP端口不可达。看到这个基本就是对端端口写错。

8.2 ARP请求反复发送，但应答不回来

这个问题我遇到过不下五次，原因一般有三种：

1. ARP请求帧的目的MAC写成单播了，应该用广播ff:ff:ff:ff:ff:ff。这是初写代码时最常犯的错误，害处是只有目标主机能收到请求，而目标主机如果没监听那个MAC地址，直接丢掉。
2. 目标主机处理ARP请求时，把自己接口的MAC填错了位置，导致发送端收到应答后更新ARP表时把错误的MAC填进去。
3. 应答帧的源MAC写成了自己接口的MAC，这绝对错误——应答帧的源MAC必须是发出应答那个接口的MAC，但很多人从“目标MAC填对”的角度想，把逻辑弄反了。

排查手段：开级别3日志，dump出请求帧和应答帧的全部内容，逐字节对比。我记得有次就是看到ARP应答的sender_mac和target_mac反了，才知道是发送结构体字段错位。

8.3 ping通一个方向，另一个方向不通

模拟器里经常出现“A能ping通B，B ping不通A”的现象。多半不是路由器转发本身的问题，而是虚拟主机程序里的“默认网关处理”逻辑写错了。比如主机A的默认网关配置成了路由器的eth0地址，但主机A构造发往B的包时，目的MAC写成了B的MAC而不是网关的MAC，导致路由器收到后发现目的MAC不是自己的，直接丢弃。

我在虚拟主机程序里加了这样一段判断逻辑：

if (is_same_subnet(dst_ip, my_ip, my_mask)) { // 目的MAC填目标主机的MAC } else { // 目的MAC填默认网关的MAC }

这个逻辑看似简单，但它是“主机行为”和“路由器行为”最大的分水岭之一。路由器和主机的最大区别，就在这个判断上：主机只在直连网段内直接发；非直连一律走网关。路由器则只根据路由表做转发，不分“直连还是非直连”。

8.4 转发后TTL变小，但对端还是收不到

如果TTL处理正确，但对端仍然收不到，我建议你用tcpdump或者我们自带的dump工具抓一下出口的包，看看源MAC是不是成了路由器的MAC。如果没变，多半是重写帧头时漏改了源MAC。还有一种可能是IP层校验和没重算，导致下游主机或者路由器把它丢弃。这个错误在模拟环境里容易被我们自己的接收端忽略，但在真实环境马上暴露。

我这里有一个现成的校验小脚本：把转出来的包和转进去的包分别打印IP头的关键字段，对比TTL、校验和、源IP、目的IP。看到源IP没变就对了，目的IP没变也是对的，但校验和一定变化了，TTL一定减1了。这四条对上了，转发基本没问题。

8.5 暂存队列越积越多

如果你发现日志里一直在发ARP请求，但暂存队列越积越多，核心问题就是ARP应答没回来或者应答没被正确解析。按照上面的步骤排查。

如果ARP应答回来了，也更新表了，但暂存队列里的包没被发走，那问题在handle_arp_reply函数里漏了遍历暂存队列。这种问题日志不容易看出来，因为看起来已经“学习到MAC”了，但就是没有后续TX日志。解决方案就是在ARP学习成功的分支里强制加一行输出：“release pending packet for IP x.x.x.x”，这样有没有走释放逻辑一目了然。

8.6 字节序错误带来的怪异现象

模拟器里的大小端问题，常见表现是：查路由表显示命中了正确路由，但ARP请求发给一个完全不对的IP。例如路由表里存的是192.168.10.0，实际发出去的目标IP变成了10.168.192.0。这种字节序颠倒的错误，在看日志的时候很容易发现——IP地址打印出来往往和预期完全不同。排查时先在打印函数里统一使用inet_ntoa或者手动转成点分格式，避免直接打印整数。

说实在的，字节序错误在真实网络编程里就是一道入门门槛。我建议读者在编码阶段就养成一个习惯：所有需要网络传输的字段，在赋值时一律用hton*；所有从网络头里读取的字段，在逻辑比较前一律用ntoh*。别在比较时临时转换，那样代码很容易乱。

9. 扩展方向与个人体会

写完这个模拟器之后，我的体会是：路由器的转发原理从来不复杂，复杂的是在真实的工程环境里把正确性、性能、异常处理同时做好。我在模拟器里用链表查表，真实设备里用高性能查找算法；我这里用UDP模拟链路，真实设备里有专门的转发芯片；但这个项目的价值在于，你亲手用代码把每一个细节落实了一遍，那些之前靠死记的概念就真正长进了脑子里。

如果读完这篇还想继续往下做，有几个方向可以参考：

• 加上RIP协议模块，让路由表可以动态更新，观察路由收敛过程。
• 增加VLAN支持，在一个物理接口上模拟多个虚拟子接口。
• 加入NAT功能，模拟从内网访问外网的地址转换过程。
• 把虚拟网口换成TAP设备，让真实操作系统里的进程发出的包也能走到模拟器里。

最后分享一个我自己使用下来的调试小技巧：在模拟器里故意制造故障，然后观察现象。比如手动清空ARP表，观察重传行为；或者故意把TTL初始值设成3，观察包在复杂拓扑里是怎么被丢弃的。人为制造故障这个方法，比直接按正确方式跑一遍能学到多得多的东西。网络协议栈本来就是为各种异常设计的状态机，你主动给它制造异常的时候，才会发现教科书里那些“为什么要有这个字段”“为什么要有那个超时”的答案全部浮出水面。