手工封装以太网帧与IP头：数据链路层和网络层底层实验

1. 这个实验不是“背概念”，而是亲手把数据包从网线里拽出来看它怎么喘气

很多人一看到“数据链路层和网络层综合实验”这几个字，脑子里立刻浮现出课本上OSI七层模型那张被画满箭头的示意图，再配上几行ARP、ICMP、IP分片的定义——然后就默默关掉文档，觉得“这又是个纯理论验证”。我带过三届网络工程方向的实训课，几乎每届都有学生在实验前夜发消息问：“老师，这个实验是不是只要Wireshark抓个包，截图交报告就行？”
答案是：完全不行。
这个实验真正的价值，从来不在“看到包”，而在于“让包按你写的逻辑走”。比如，你用Python手动构造一个以太网帧，把源MAC设成你本机网卡的真实地址，目的MAC填成隔壁实验室某台Linux服务器的地址，再往里面塞一个自定义的IPv4报头——这时候你发出去的帧，不会被交换机丢弃，不会被路由器拦下，它真真切切地跑过了物理线缆，在目标主机的网卡驱动里被收下来，然后……被内核直接扔进垃圾桶，因为它的协议字段写着0x88B5（一个未注册的自定义协议号）。但正因如此，你才第一次真正“摸到”了数据链路层和网络层之间那道看不见的墙：链路层只管“送到门口”，网络层才决定“敲不敲门”。
关键词里虽然没写，但所有实操者都绕不开三个硬核动作：手工封装帧头、篡改IP首部字段、拦截并解析原始套接字收到的二进制流。这不是调API，这是在操作系统网络栈的毛细血管里做微创手术。适合谁？不是刚学完《计算机网络》期末考完就忘的本科生，而是已经能用tcpdump过滤出SYN洪泛流量、知道为什么ping -s 1500在某些网段会失败、对/proc/sys/net/ipv4/ip_forward这个开关背后发生了什么有本能好奇的人。如果你现在打开终端还能顺手敲出ip link show eth0并说出mtu 1500对TCP MSS协商的影响，那这篇就是为你写的。

2. 实验环境不是“装个VM就完事”，而是必须亲手拆开网卡驱动看它怎么喂数据给内核

很多教程一上来就说“用VirtualBox配两台Ubuntu虚拟机”，听起来省事，实则埋下第一个巨坑：虚拟网卡驱动（如e1000、virtio-net）会自动处理大量本该由你手动实现的底层逻辑。比如，当你用raw socket发送一个IP包时，真实网卡驱动会检查校验和是否正确、MTU是否超限、甚至帮你把大包自动分片；而虚拟网卡驱动呢？它可能直接把校验和计算甩给宿主机内核，或者干脆在QEMU层就给你补全了IP头里的TTL字段。结果就是——你构造了一个TTL=1的IP包，发出去后居然能被目标主机响应ICMP超时，这根本不符合真实网络行为。
所以，我们第一步必须“降级”：用物理机+双网卡直连，彻底绕过虚拟化层的干扰。具体配置如下：

• 主机A（实验发起端）：Intel i210千兆网卡，驱动版本5.15.0-107-generic（Linux 5.15内核），禁用所有offload功能（ethtool -K eth0 tx off rx off tso off gso off gro off lro off）
• 主机B（接收端）：同型号网卡，同样禁用offload，额外关闭IPv4转发（echo 0 > /proc/sys/net/ipv4/ip_forward）
• 物理连接：一根Cat6直通网线，两端分别插在两台主机的独立网卡上，不经过任何交换机或路由器

提示：为什么必须禁用GRO（Generic Receive Offload）？因为GRO会在网卡驱动层就把多个小包合并成一个大skb（socket buffer）再往上送。你用原始套接字监听eth0时，收到的将是一个长度为2800字节的“伪大包”，里面混着3个独立的IP数据报——而你根本无法从中分离出单个IP头。实测发现，开启GRO后，Wireshark显示的帧长和你程序recvfrom()返回的长度永远对不上，这就是典型信号污染。

更关键的是网卡工作模式。默认情况下，网卡只接收目的MAC匹配自身或广播地址的帧。但我们要做的是“链路层嗅探”，必须让网卡进入混杂模式（promiscuous mode）：

# 在主机A上执行（注意：不是ifconfig up，而是直接操作驱动） ip link set eth0 down ip link set eth0 address 00:11:22:33:44:55 # 手动设置一个测试MAC ip link set eth0 up # 验证是否生效 cat /sys/class/net/eth0/flags | grep -q "0x1002" && echo "混杂模式已启用"

这里有个极易被忽略的细节：ip link set eth0 address命令修改的是网卡驱动维护的MAC地址缓存，而非EEPROM里的物理地址。这意味着重启后失效，但恰好符合实验需求——你不需要永久改MAC，只需要在本次实验周期内让帧能被正确识别。我曾见过学生用ifconfig eth0 hw ether命令修改后，发现Wireshark里源MAC还是原来的值，原因就是该命令只改了内核网络栈的缓存，没同步到驱动层。真正的控制点在/sys/class/net/eth0/address这个文件，它是只读的，代表硬件真实地址；而驱动层的运行时MAC存在/sys/class/net/eth0/device/local_admin_address中，这才是你要动的地方（需root权限写入）。

3. 手工封装以太网帧：别信“随便填个MAC就行”，校验和错一位整个帧就被物理层丢弃

现在进入最硬核的部分：用C语言写一个裸帧发送器。别急着抄网上那些“struct ethhdr”模板，先问自己一个问题：当你的程序调用sendto()向AF_PACKET套接字发数据时，内核到底把什么内容塞进了网卡DMA缓冲区？答案是：你传进去的每一个字节，都会原封不动地变成网线上的电信号。这意味着，哪怕你在以太网帧头里多写了一个字节的padding，或者少算了一位FCS（帧校验序列），网卡物理层就会在CRC校验阶段直接把这个帧标记为“error”，然后静默丢弃——Wireshark里根本看不到它。
所以，我们必须严格遵循IEEE 802.3标准：

• 帧起始：7字节Preamble（10101010…） + 1字节SFD（10101011）→ 这部分由网卡硬件自动生成，你无需也不许写入
• 目的MAC（6字节）+ 源MAC（6字节）+ EtherType（2字节）→ 这14字节是你必须精确填充的
• 数据载荷（46~1500字节）→ 注意最小长度限制！如果IP包只有20字节，你必须补足26字节的padding，否则帧长<64字节，会被视为“runt frame”丢弃
• FCS（4字节）→ 同样由网卡硬件自动生成，你绝对不能写入

来看一段真实的C代码片段（关键逻辑已加注释）：

#include <stdio.h> #include <string.h> #include <sys/socket.h> #include <linux/if_packet.h> #include <net/ethernet.h> #include <arpa/inet.h> int main() { int sock = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)); struct sockaddr_ll sll; unsigned char frame[1514]; // 14字节帧头 + 1500字节载荷 // 1. 构造以太网帧头（严格14字节） memcpy(frame, "\x00\x11\x22\x33\x44\x55", 6); // 目的MAC：主机B的MAC memcpy(frame+6, "\xaa\xbb\xcc\xdd\xee\xff", 6); // 源MAC：主机A的MAC（已用ip link set设置） frame[12] = 0x08; frame[13] = 0x00; // EtherType = 0x0800 (IPv4) // 2. 构造IP载荷（此处简化为固定20字节IP头） unsigned char ip_header[20] = {0}; ip_header[0] = 0x45; // Version=4, IHL=5 ip_header[1] = 0x00; // DSCP/ECN ip_header[2] = 0x00; ip_header[3] = 0x14; // Total Length = 20 ip_header[4] = ip_header[5] = 0x00; // Identification ip_header[6] = ip_header[7] = 0x00; // Flags + Fragment Offset ip_header[8] = 0x40; // TTL = 64 ip_header[9] = 0x01; // Protocol = ICMP ip_header[10] = ip_header[11] = 0x00; // Header Checksum (暂置0，由网卡计算) ip_header[12] = ip_header[13] = ip_header[14] = ip_header[15] = 0xc0; // Src IP = 192.168.1.1 ip_header[16] = ip_header[17] = ip_header[18] = ip_header[19] = 0xa8; // Dst IP = 192.168.1.2 // 3. 拼接帧：帧头 + IP头 + padding（确保总长>=64字节） memcpy(frame+14, ip_header, 20); int payload_len = 20; if (payload_len < 46) { memset(frame+14+20, 0, 46-payload_len); // 补零至最小载荷46字节 payload_len = 46; } // 4. 绑定到指定网卡 memset(&sll, 0, sizeof(sll)); sll.sll_family = AF_PACKET; sll.sll_ifindex = if_nametoindex("eth0"); // 获取eth0的接口索引 sll.sll_halen = ETH_ALEN; memcpy(sll.sll_addr, "\x00\x11\x22\x33\x44\x55", ETH_ALEN); // 目的MAC // 5. 发送（注意：sendto的第三个参数是总长度，含帧头！） int ret = sendto(sock, frame, 14+payload_len, 0, (struct sockaddr*)&sll, sizeof(sll)); printf("Sent %d bytes\n", ret); return 0; }

这段代码里藏着三个致命陷阱：
第一，sll.sll_halen = ETH_ALEN必须显式设置，否则内核不知道目的MAC长度，会把sll_addr后面一堆垃圾内存当成MAC地址发出去；
第二，sendto()的长度参数必须是14+payload_len，即帧头14字节+载荷长度，绝不能只传载荷长度，否则内核会认为你只发了IP包，自动给你补上以太网帧头——而这恰恰破坏了你手工封装的意图；
第三，IP头校验和字段（第10-11字节）必须置0，因为Linux内核在发送时会检测到该字段为0，自动调用ip_fast_csum()函数计算并填入正确值；如果你提前算好填进去，内核反而会把它当垃圾数据处理。

注意：为什么不用libpcap？因为libpcap的pcap_inject()接口会绕过AF_PACKET套接字，直接走BPF过滤器路径，导致你无法控制帧的精确字节布局。真正的底层实验，必须直面AF_PACKET。

4. 网络层拦截与解析：当原始套接字收到数据时，你看到的其实是“裸奔”的二进制流

发送端搞定后，接收端才是真正的认知颠覆点。你以为用recvfrom()从AF_PACKET套接字读出来的数据，会像TCP Socket那样自动剥离以太网头、IP头、传输层头，只留应用层数据？错。原始套接字给你的是网卡DMA缓冲区里的原始镜像——从Preamble之后的第一个字节开始，直到FCS之前的所有内容。这意味着，你收到的数据块开头就是目的MAC（6字节），接着源MAC（6字节），再是EtherType（2字节），然后才是IP头……整条数据链路层到网络层的封装结构，赤裸裸地摊在你面前。
所以，解析流程必须严格按字节偏移进行：

来看一个真实解析场景：当你在主机A上发送一个TTL=1的ICMP Echo Request时，主机B收到的帧里IP头TTL字段值是1。但根据RFC 791，接收方不修改TTL字段，它只在转发时才减1。所以主机B看到的TTL仍是1，这说明该包没有被任何中间设备转发，是直连通信的铁证。而如果你在主机B上同时开启Wireshark，会发现它捕获到两个包：一个是主机A发来的Echo Request（TTL=1），另一个是主机B内核自动生成的ICMP Time Exceeded响应（TTL=64）。这两个包的以太网帧目的MAC完全不同——前者指向主机B的MAC，后者指向主机A的MAC。这正是链路层和网络层职责分离的活教材：网络层决定“该不该响应”，链路层负责“把响应包送到谁的网卡”。

提示：如何验证你解析的IP头是否正确？最简单的方法是用tcpdump -xx -r capture.pcap导出十六进制转储，然后逐字节比对。你会发现，tcpdump输出的第0010行（偏移16字节处）开始的4个字节，正好对应IP头里的总长度字段。这种“人肉对齐”过程虽然枯燥，但能让你彻底建立字节级的空间感——这是所有网络底层开发者的肌肉记忆。

5. 关键实验现象深度归因：为什么“ping不通”有时是链路层的错，有时是网络层的锅

实验中最让人抓狂的，莫过于“明明线连着，却ping不通”。此时新手常陷入无意义的循环：重启网卡、换网线、重装驱动……而资深从业者会立即启动分层诊断法。我们用一个真实案例说明：
现象：主机A（192.168.1.1）能成功ping通主机B（192.168.1.2），但主机B无法ping通主机A。Wireshark在主机A上能看到ICMP Echo Request到达，但没有发出Response。
排查链路层：

• 在主机A上执行tcpdump -i eth0 icmp and host 192.168.1.2，确认Request帧确实到达
• 检查主机A的ARP表：ip neigh show，发现主机B的MAC地址状态为FAILED
• 手动添加静态ARP：ip neigh add 192.168.1.2 lladdr 00:11:22:33:44:55 dev eth0 nud permanent
• 再次ping，成功！

根因分析：主机B发送的ICMP Request帧里，目的MAC是主机A的MAC地址（通过ARP请求获得），但主机A的内核在收到该帧后，检查IP头的目的地址（192.168.1.1）时，发现本机有多个IP地址绑定在eth0上（比如还配了10.0.0.1），于是触发“反向路径过滤”（rp_filter）。默认rp_filter=1时，内核会检查该包的源IP（192.168.1.2）是否能通过eth0路由回源，结果发现192.168.1.2的路由表项指向eth0，但ARP表里没有对应的MAC缓存（因为主机B没发过ARP请求给主机A），于是直接丢弃该包，且不生成ICMP Destination Unreachable。

这个案例完美展示了两层的耦合与解耦：

• 链路层问题：ARP表缺失导致无法构建响应帧的目的MAC
• 网络层问题：rp_filter机制基于IP路由决策，但决策依据却依赖链路层的ARP缓存状态
• 解决方案必须跨层：既要修复ARP表（链路层动作），又要理解rp_filter的触发条件（网络层机制）

再看一个更隐蔽的问题：MTU不匹配导致的IP分片失败。当主机A发送一个1472字节的ICMP载荷（1472+20IP头+8ICMP头=1500字节）时，在主机B上用tcpdump -i eth0 'icmp[icmptype] == icmp-echoreply'能抓到响应，但主机A的ping命令却显示“100% packet loss”。原因在于：主机B的网卡MTU被误设为1400，当它构造ICMP Echo Reply时，IP头里的“Don't Fragment”标志位被置1（ping默认行为），而1472字节载荷+20IP头+8ICMP头=1500 > 1400，内核无法分片，只能丢弃并返回ICMP Fragmentation Needed消息。但主机A的ping程序默认不处理该消息，于是表现为超时。此时，tcpdump在主机A上能看到ICMP Type=3 Code=4的错误包，这才是真正的故障线索。

实操心得：每次遇到“ping不通”，先执行这三步：

1. arping -I eth0 192.168.1.2—— 验证链路层可达性（绕过ARP表，直接发ARP请求）
2. ping -M do -s 1472 192.168.1.2—— 测试DF位和MTU边界（-M do表示禁止分片）
3. ss -i—— 查看本机TCP连接的MSS值，反推路径MTU

6. 从实验到生产：为什么云厂商的VPC网络必须重写数据链路层逻辑

做完这个实验，你可能会问：这些手工封装帧、解析原始套接字的操作，在真实云环境中还有用吗？答案是：不仅有用，而且是云网络性能优化的核心战场。某头部云厂商的VPC网络架构文档里明确提到，其自研智能网卡（SmartNIC）固件中，有超过35%的代码量用于处理“用户态绕过内核协议栈”的数据平面加速。而这一切的技术源头，正是本实验所训练的底层能力。

举个具体例子：当一台ECS实例要访问同VPC内的另一台实例时，传统路径是：

应用层 → 内核Socket → TCP/IP协议栈 → netfilter → e1000驱动 → 网卡DMA

这条路径里，内核协议栈要完成三次内存拷贝（应用→内核、内核→驱动、驱动→DMA），还要做完整的TCP状态机维护、IP分片重组、校验和计算……延迟高达80~120微秒。而采用DPDK（Data Plane Development Kit）方案后，路径变为：

应用层 → 用户态DPDK库 → 网卡驱动旁路 → 直接操作网卡寄存器

此时，开发者必须自己实现：

• 以太网帧的DMA缓冲区管理（类似本实验的frame数组）
• IP头的校验和卸载（类似本实验中让内核自动计算）
• ARP表的用户态维护（类似本实验中手动ip neigh add）
• MTU自适应分片（类似本实验中检查总长度并补padding）

区别在于，实验中你用C语言写一个main函数就能搞定的事，在DPDK里要变成一个持续运行的轮询线程（polling thread），每秒处理数百万个数据包。但核心原理完全一致：你必须清楚知道每一个字节在链路层和网络层之间如何流转，否则一个校验和计算错误，就会导致整个集群的网络抖动。

我参与过某金融客户的核心交易系统迁移，他们要求跨可用区通信延迟稳定在200微秒以内。最终方案是在物理服务器上部署DPDK应用，其中最关键的一段代码，就是把本实验里那个14字节以太网帧头的构造逻辑，移植到了DPDK的rte_eth_tx_burst()调用之前。当监控系统发现某个网卡队列积压时，运维人员第一反应不是查CPU，而是用dpdk-proc-info工具 dump 出当前DMA缓冲区里的帧结构，逐字节比对EtherType和IP头长度——这和你在实验里用tcpdump -xx做的事儿，本质上毫无区别。

所以，别再说“这只是个教学实验”。当你在AWS控制台点击“创建VPC”时，后台正在运行的，就是成千上万个经过本实验锤炼过的工程师写的、处理以太网帧和IP包的代码。