Raw Socket原理与实战：绕过内核封装，亲手构造网络包

1. raw socket 到底比普通 socket“原始”在哪里

1.1 普通 socket 帮你封装了哪些细节

普通 UDP socket 调用 sendto() 时，内核替你完成的事情可以列一长串：填充以太网头（经由网卡驱动）、计算 IP 头校验和、设置 IP 头总长度和标识、把 UDP 源端口与目的端口写进 UDP 头，最后查路由表选出口网卡。对应用层来说，UDP socket 意味着你不需要知道 IP 头长什么样，甚至不需要知道 IP 协议号是几。

raw socket 的“原始”体现在：内核不再替你封装完整头部，或者只替你封装一部分。以 AF_INET + SOCK_RAW 为例，接收方向你会拿到从 IP 头开始的数据（不只是载荷）；发送方向如果你设置 IP_HDRINCL，连 IP 头都得自己写，内核只负责按你给的源/目的地址查路由，把包从正确的网卡拉出去。换句话说，raw socket 把网络层的中间人角色让出了一大半，把真正的话筒交还给应用程序。

用生活化的类比解释：普通 socket 像快递公司，你只写收件人地址，剩下打包、贴单、运输全由快递公司负责；raw socket 像自己把包裹装箱、贴好面单，然后让快递公司只做最后一程运输。快递公司省了很多事，但你也失去了“丢给前台就不用管”的便利，一切细节都要自己把关。

1.2 创建参数的差异：SOCK_RAW 不是唯一的“原始”

创建 raw socket 的调用：

int sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP);

很多新手以为把 SOCK_STREAM 改成 SOCK_RAW 就能“为所欲为”，其实还有两个关键点。

第一，协议族要选对。AF_INET 表示工作在 IPv4 网络层，你看到的是 IP 头以上的内容；如果想直接操作以太网帧，要用 AF_PACKET（packet socket），那是另一个层次的“原始”。

第二，SOCK_RAW 类型在 AF_INET 里不能使用协议号为 0（IPPROTO_IP）。第三个参数必须指定一个实际协议号，比如 IPPROTO_ICMP、IPPROTO_TCP、IPPROTO_UDP。如果传 0，socket 调用通常会返回 EINVAL。这个参数同时决定接收过滤条件：内核把 IP 头里的 protocol 字段与它比较，匹配才投递副本。

raw socket 里没有“端口”概念，这一点也容易搞混。端口是 TCP/UDP 传输层的概念，如果你用 raw socket 发一个 TCP 包，端口号需要自己在 TCP 头里填；raw socket 只负责网络层及以下。

还要记住一个使用误区：很多人以为 raw socket 可以替代普通 socket 来做业务通信，这是不现实的。TCP 有滑动窗口、拥塞控制、重传、有序交付，raw socket 全都没有。需要用 raw socket 的是以下几类场景：

• 自己实现 ping、traceroute 这类依赖 ICMP 的工具
• 构造带特殊标志（DF、MF、自定义 TTL）的 IP 包做协议测试
• 抓包分析和网络监控
• 实现自定义的传输层协议或进行协议栈验证
• 构造特定报文验证防火墙、网关等网络设备的行为

上面这些场景里，普通 socket 要么做不到，要么做起来很别扭，raw socket 则是更对症的工具。

2. 创建 raw socket：参数、权限与第一个收包程序

2.1 权限问题：root、CAP_NET_RAW 与容器环境

在 Linux 上创建 raw socket 需要 CAP_NET_RAW 能力，传统说法是“需要 root”。root 用户天然拥有全部能力，所以 root 没问题；但 Linux 在现代内核里用的是 capabilities 机制，准确表述是“进程需要有 CAP_NET_RAW”。

容器场景经常踩坑：同一段代码，在宿主机上没问题，放进容器就报 EPERM，因为默认容器没有授予 NET_RAW capability。解决方法是 docker run 时加 --cap-add=NET_RAW，或者在集群环境的安全上下文中配置 capabilities 加上 NET_RAW。

还有一种情况：某些安全模块会主动拦截 raw socket 的创建。在这种环境下，root 也可能创建失败，dmesg 里经常能看到相关日志。遇到这种情况，先确认是哪一层安全策略在起作用，再决定是放行还是绕开 raw socket（用 tun/tap 设备替代）。

2.2 一个最小收包程序：recvfrom 返回的数据从 IP 头开始

先把一个能跑的收包程序写出来，再解释行为：

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/socket.h> #include <netinet/ip.h> #include <netinet/in.h> #include <arpa/inet.h> int main(void) { int sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP); if (sockfd < 0) { perror("socket"); return 1; } char buf[65536]; struct sockaddr_in saddr; socklen_t addrlen = sizeof(saddr); ssize_t n = recvfrom(sockfd, buf, sizeof(buf), 0, (struct sockaddr *)&saddr, &addrlen); if (n < 0) { perror("recvfrom"); return 1; } struct iphdr *iph = (struct iphdr *)buf; printf("received %zd bytes, src=%s, proto=%d\n", n, inet_ntoa(saddr.sin_addr), iph->protocol); return 0; }

两个重要事实。

第一，AF_INET + SOCK_RAW 的 recvfrom() 返回的是从 IP 头开始的完整 IP 包，而不是 ICMP 载荷。buf 的第一个字节是 IP 头的 version 和 ihl 字段。想定位 ICMP 头，必须先用 iph->ihl * 4 跳过 IP 头。

第二，raw socket 收到的是内核协议栈处理过程中的数据包副本，不是抢占式拦截。你开一个 ICMP raw socket，系统自己的 ICMP 响应逻辑照常运行，原始报文也会继续正常传递，raw socket 只是在队列里拿到一份副本。

验证这个程序很简单：开一个终端运行程序，另一个终端 ping 任意目标地址。如果目标可达，你会看到 echo reply；如果目标不可达，至少能收到本机发出的 echo request（发送方向产生的帧在某些接口上是可见的）。多试几次就能理解“副本投递”的意思了。

2.3 多个 raw socket 之间的副本分发

如果你同时创建了 IPPROTO_ICMP、IPPROTO_TCP、IPPROTO_UDP 三个 raw socket，同一个数据包只会进入协议号匹配的那个 socket 队列，不会被所有 socket 同时接收，因为内核的 raw_local_deliver 逻辑就是按 IP 头的 protocol 字段做匹配。

如果要同时收多种协议，有两个思路：要么创建多个 raw socket 分别绑定协议号，要么用 AF_PACKET 让所有帧都进你的 socket。后面我会专门写 AF_PACKET 的用法。

3. 解析 IP 头：从 buf 的第一个字节说起

3.1 IPv4 头各字段的网络字节序

IPv4 头的标准结构大家应该都见过，这里列一个重点表格，标注哪些字段是网络字节序：

对 x86 这种小端机器来说，网络序（大端）的字段如果直接按主机序读取，值基本都是错的。最典型的就是 tot_len 和 id。我见过很多人打印 IP 包总长度，结果输出的数字大得离谱，就是因为忘了 ntohs()。

另外一个容易被忽略的点：frag_off 字段同时包含 DF、MF 标志和片偏移。它整体是网络序，必须先 ntohs()，再按位运算：

• DF 位：0x4000
• MF 位：0x2000
• 片偏移：0x1FFF，单位是 8 字节

如果直接读 frag_off 再拿它与 0x4000 做与运算，在 x86 上会因为字节序问题判断出错。

3.2 一个完整可编译的 IP 头解析程序

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/socket.h> #include <netinet/ip.h> #include <netinet/in.h> #include <arpa/inet.h> static void parse_ip_header(const unsigned char *buf, ssize_t n) { const struct iphdr *iph = (const struct iphdr *)buf; unsigned int ihl = iph->ihl * 4; unsigned int tot_len = ntohs(iph->tot_len); unsigned int frag_off = ntohs(iph->frag_off); if ((unsigned int)n < ihl) { printf("packet too short\n"); return; } int mf = (frag_off & 0x2000) ? 1 : 0; int df = (frag_off & 0x4000) ? 1 : 0; unsigned int frag_offset = (frag_off & 0x1fff) * 8; printf("len=%u ihl=%u ttl=%u proto=%u\n", tot_len, ihl, iph->ttl, iph->protocol); printf("src=%s dst=%s\n", inet_ntoa(*(struct in_addr *)&iph->saddr), inet_ntoa(*(struct in_addr *)&iph->daddr)); printf("frag: mf=%d df=%d offset=%u\n", mf, df, frag_offset); } int main(void) { int sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP); if (sockfd < 0) { perror("socket"); return 1; } char buf[65536]; struct sockaddr_in saddr; socklen_t addrlen = sizeof(saddr); while (1) { ssize_t n = recvfrom(sockfd, buf, sizeof(buf), 0, (struct sockaddr *)&saddr, &addrlen); if (n < 0) { perror("recvfrom"); break; } parse_ip_header((unsigned char *)buf, n); } return 0; }

这段代码的要点：先用 iph->ihl * 4 拿到 IP 头的实际长度，然后判断报文长度是否够；tot_len 和 frag_off 必须先 ntohs() 再解析；源/目的地址要转成 in_addr 结构再交给 inet_ntoa() 格式化。

有一点小提醒：inet_ntoa() 返回的字符串是静态缓冲区，连续打印两个 inet_ntoa() 会互相覆盖。上面的代码里 src 在第一个 printf 里输出，dst 在第二个 printf 里输出，分开使用没问题；如果你在一个 printf 里连续调用两个 inet_ntoa()，打印结果就会两个地址相同。这种细节容易让人排查半天。

3.3 收包方向最常见的误判

新手经常把 raw socket 当成“能看到原始以太网帧”，这在这里是不成立的。AF_INET + SOCK_RAW 看到的起点是 IP 头，不是 MAC 头。要看 MAC 头，必须用 AF_PACKET。这决定了你的解析代码的偏移量从哪里开始。

另外一个误判是“报文里只有我要的那个协议”。实际上，只要 IP 头的 protocol 字段匹配，整个 IP 包（包括所有选项字段）都会进队列。IP 头选项可能让 IP 头长度超过 20 字节，如果用固定偏移直接找 ICMP 头，遇到带选项的包就会解析错。用 ihl * 4 是必须的。

4. 手写 ICMP Echo：发送方向的自动填充与校验和

4.1 两种发送模式：内核自动填 IP 头与 IP_HDRINCL

AF_INET + SOCK_RAW 默认发送时，内核会替你填充 IP 头，包括源地址、目标地址、TTL、TOS、协议字段和 IP 头校验和。你只需要保证 payload 是正确的上层报文。以 ICMP 为例，type=8（ECHO）、code=0、校验和（先置 0 再算）、以及 id 和序列号都要自己填。

如果需要自定义 IP 头（比如设置 DF 标志、修改 TTL、控制分片），就要设置 IP_HDRINCL：

int one = 1; setsockopt(sockfd, IPPROTO_IP, IP_HDRINCL, &one, sizeof(one));

设置之后，内核不再填充 IP 头，你发送的缓冲区要包含一个完整的 IP 头。此时任何头部字段错误都由你负责，抓包时问题很容易暴露，但排查也更费劲。

用两个模式对比的话：默认模式像“只打内容不打包”，内核帮你贴包裹单；IP_HDRINCL 模式像“自己把包裹封好”，内核只负责叫快递来取件并选择路线。两者没有绝对优劣，取决于你要控制哪些字段。

4.2 ICMP 校验和：覆盖整个 ICMP 报文，不只是头部

校验和算法是标准的 16 位反码累加再取反：

uint16_t checksum(const void *data, size_t len) { uint32_t sum = 0; const uint16_t *ptr = (const uint16_t *)data; while (len > 1) { sum += *ptr++; len -= 2; } if (len == 1) { sum += *(const uint8_t *)ptr; } while (sum >> 16) { sum = (sum & 0xffff) + (sum >> 16); } return (uint16_t)(~sum); }

四个容易踩的点：

第一，计算校验和时，校验和字段本身必须先置 0，否则结果不对。 第二，累加器要用 32 位或更宽的类型，避免 16 位溢出，最后再把高 16 位的进位加回低 16 位。 第三，ICMP 校验和覆盖的是整个 ICMP 报文（头部加数据），长度参数要包含数据部分。我见过不少代码只对 struct icmphdr 的大小做校验，数据一多就校验失败，对端直接把包丢了。 第四，如果报文的长度是奇数，最后一个字节要当成低 8 位参与求和，补齐高 8 位为 0。

4.3 构造并发送 ICMP Echo Request

完整代码示例：

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/socket.h> #include <netinet/ip.h> #include <netinet/ip_icmp.h> #include <netinet/in.h> #include <arpa/inet.h> static uint16_t checksum(const void *data, size_t len); int main(void) { int sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP); if (sockfd < 0) { perror("socket"); return 1; } struct sockaddr_in dst; memset(&dst, 0, sizeof(dst)); dst.sin_family = AF_INET; inet_pton(AF_INET, "192.0.2.1", &dst.sin_addr); // 文档保留地址，测试时替换 char packet[64]; memset(packet, 0, sizeof(packet)); struct icmphdr *icmp = (struct icmphdr *)packet; icmp->type = ICMP_ECHO; icmp->code = 0; icmp->un.echo.id = htons(getpid() & 0xffff); icmp->un.echo.sequence = htons(1); int len = sizeof(struct icmphdr) + 32; memset(packet + sizeof(struct icmphdr), 0x42, 32); icmp->checksum = 0; icmp->checksum = checksum(packet, len); if (sendto(sockfd, packet, len, 0, (struct sockaddr *)&dst, sizeof(dst)) < 0) { perror("sendto"); return 1; } printf("icmp echo request sent to 192.0.2.1\n"); return 0; }

发送方向的注意点：

• sendto() 的 sockaddr_in 只用于告诉内核目的 IP 和路由选择。内核会自动选择合适的源 IP。
• id 和 sequence 都要 htons()，因为它们要放到网络字节序里。id 通常用 getpid() 的低 16 位，这样多进程同时抓包时能区分请求属于哪个程序。
• ICMP 校验和的长度参数是“头部 + 数据”，上面代码里 len 是 sizeof(struct icmphdr) + 32，传给 checksum()。

如果想在接收方向收到 echo reply，需要把上一章的收包循环接进来，判断 ICMP type 是否为 ICMP_ECHOREPLY 且 id 匹配。这里要注意一个现象：本机发送 echo request 后，内核协议栈本身也可能产生 echo reply（取决于目标地址的处理路径），你的 raw socket 可能同时看到 request 和 reply 两份报文。写工具时用 ICMP type 区分，就不会被搞晕。

5. AF_PACKET 与链路层视角：抓包和自定义以太网帧

5.1 AF_INET raw socket 与 AF_PACKET 的能力边界

抓包需求出现时，AF_INET raw socket 往往不够用：你看不到 ARP、看不到带 VLAN 标签的完整以太网头，也不能直接看到二层广播帧。这时需要把视角下移到数据链路层，用 AF_PACKET。

AF_PACKET + SOCK_RAW 创建：

int sockfd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));

第三个参数是 EtherType。ETH_P_ALL 表示接收所有以太网类型；如果只想看 IPv4，用 htons(ETH_P_IP)（0x0800）；想看 IPv6 用 htons(ETH_P_IPV6)；想看 ARP 用 htons(ETH_P_ARP)。

一个最小抓包程序：

#include <stdio.h> #include <string.h> #include <unistd.h> #include <sys/socket.h> #include <net/if.h> #include <linux/if_ether.h> #include <linux/if_packet.h> #include <netinet/in.h> #include <arpa/inet.h> int main(void) { int sockfd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)); if (sockfd < 0) { perror("socket"); return 1; } struct sockaddr_ll sll; memset(&sll, 0, sizeof(sll)); sll.sll_family = AF_PACKET; sll.sll_protocol = htons(ETH_P_ALL); sll.sll_ifindex = if_nametoindex("eth0"); // 替换为实际网卡 if (bind(sockfd, (struct sockaddr *)&sll, sizeof(sll)) < 0) { perror("bind"); return 1; } unsigned char buf[65536]; while (1) { ssize_t n = recvfrom(sockfd, buf, sizeof(buf), 0, NULL, NULL); if (n < 0) { perror("recvfrom"); break; } struct ethhdr *eth = (struct ethhdr *)buf; printf("frame %zd bytes, dst MAC " "%02x:%02x:%02x:%02x:%02x:%02x, ethertype 0x%04x\n", n, eth->h_dest[0], eth->h_dest[1], eth->h_dest[2], eth->h_dest[3], eth->h_dest[4], eth->h_dest[5], ntohs(eth->h_proto)); } return 0; }

几个关键行为：

• recvfrom() 得到的 buf 从以太网头开始，先解析 ethhdr，再根据 EtherType 决定后续如何解析。
• 如果没有将网卡设置为混杂模式，非本机目的 MAC 的单播帧是看不到的；只有把接口设为混杂模式后，才能看到网络上其他单播帧。
• 协议过滤发生在创建 socket 时的 EtherType 参数和 bind 的协议参数上。想抓所有流量就统一用 ETH_P_ALL。

5.2 发送自定义 EtherType 帧：完全绕开 IP 协议栈

AF_PACKET 的发送方向适合做自定义链路层实验。比如定义一个私有 EtherType 0x88B5，封装一段自定义载荷，在两台机器之间直接通信，整个 IP 协议栈都不参与。

#include <stdio.h> #include <string.h> #include <unistd.h> #include <sys/socket.h> #include <net/if.h> #include <linux/if_ether.h> #include <linux/if_packet.h> #include <netinet/in.h> #include <arpa/inet.h> int main(void) { int sockfd = socket(AF_PACKET, SOCK_RAW, htons(0x88B5)); if (sockfd < 0) { perror("socket"); return 1; } unsigned char frame[64]; memset(frame, 0, sizeof(frame)); unsigned char dst_mac[6] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff}; unsigned char src_mac[6] = {0x00, 0x11, 0x22, 0x33, 0x44, 0x55}; memcpy(frame, dst_mac, 6); memcpy(frame + 6, src_mac, 6); frame[12] = 0x88; frame[13] = 0xB5; strcpy((char *)frame + 14, "hello-packet"); struct sockaddr_ll sll; memset(&sll, 0, sizeof(sll)); sll.sll_family = AF_PACKET; sll.sll_ifindex = if_nametoindex("eth0"); sll.sll_halen = 6; memcpy(sll.sll_addr, dst_mac, 6); int len = 14 + 12; if (sendto(sockfd, frame, len, 0, (struct sockaddr *)&sll, sizeof(sll)) < 0) { perror("sendto"); return 1; } return 0; }

这个示例里的“源 MAC”在大多数驱动下会被网卡用自己的真实 MAC 覆盖，别低估驱动的自主性。目的 MAC 如果是广播地址，交换机才会把帧广播出去；如果做点对点实验，需要把 sll.sll_addr 填成目标机器的真实 MAC。

一个现实约束是 MTU：以太网帧的数据部分不能无限大。超过接口 MTU 的值发送时，有的驱动直接丢弃，有的会返回 EMSGSIZE。自定义协议在设计时，载荷大小要留足余量。

6. 实测容易翻车的坑：字节序、缓冲区与权限细节

6.1 网络字节序：x86 上最顽固的失忆症

在 IP 头、TCP/UDP 头、ICMP 校验和里，几乎所有多字节字段都是网络字节序。x86 上本地是小端，直接赋值就是错的。常见的翻车现场：

• iph->tot_len 忘了 htons()：发出的包总长度字段错乱，对端解析出来长度对不上。
• IP 头 id 忘了 htons()：分片重组时标识不一致，对端无法重组。
• ICMP 的 id、sequence 忘了 htons()：收到 reply 时匹配不上，自己写的 ping 工具永远“丢包”。

我的习惯是先画一个字段表，标出哪些字段需要网络字节序，再逐项转换。宁可慢一点，不要在抓包工具里反复看乱码。

6.2 校验和与网卡 offload 的纠缠

网卡硬件支持 checksum offload 时，驱动会在发送路径上重新计算部分校验和，此时抓包工具可能看到“checksum incorrect”，但线上包实际是好的。排查思路：先看 ethtool -k 的 tx-checksum-* 开关，必要时关闭再对比抓包结果。

ICMP 校验和的覆盖范围是“整个 ICMP 报文（头加数据）”，这点前面强调过，但每次实测都有人犯。TCP/UDP 的伪头部和校验范围和 ICMP 完全不同，写代码时不要套用同一个函数就算完了。

6.3 接收缓冲区小到丢包还没有提示

raw socket 的接收缓冲区默认值在流量大的时候是不够的。调大缓冲区是抓包工具的基本操作：

int rcvbuf = 4 * 1024 * 1024; setsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &rcvbuf, sizeof(rcvbuf));

缓冲区满后，内核直接丢弃新的数据包副本，不会通知应用层。所以当你发现“抓包有间隙”的时候，先检查网卡驱动统计（ethtool -S 里的 rx_dropped、rx_missed），再检查 socket 队列是否因为太满丢的。两者通常需要同时看，才能定位丢包发生在哪一层。

6.4 分片、DF 标志与重组责任

用 raw socket 发送大载荷时，如果没设置 IP_HDRINCL，内核会按 MTU 做 IP 分片；设置 IP_HDRINCL 后，分片行为由你的 IP 头字段决定。如果你设置 DF 位但载荷又超过 MTU，包会被出口逻辑丢弃，还可能收到 ICMP fragmentation needed 的路径反馈。

另一个容易忽略的点：raw socket 收包时不负责分片重组，你看到的是一个一个分片。如果你的工具目标是分析完整 TCP 流，就需要自己实现分片重组逻辑，或者用现成的抓包框架。这个工作量不小，所以我在实际项目里，只要允许，都会优先用成熟库而不是从零写重组。

6.5 容器权限和 EPERM 的排查顺序

创建 raw socket 返回 -1、errno=EPERM 时，排查顺序是这样：

1. 确认进程是不是 root，或者带没带 CAP_NET_RAW。
2. 如果跑在容器里，检查容器的 capabilities 配置。docker 里用 --cap-add=NET_RAW，K8s 里在 securityContext 的 capabilities 中加 NET_RAW。
3. 看 dmesg 有没有安全模块的拦截日志。
4. 如果安全策略不允许，考虑用 tun/tap 设备或者其他不依赖 raw socket 的方案。

容器环境里很多人会在这上面卡很久。我的经验是：先 dmesg，再权限，再代码顺序，能少做很多无用功。

6.6 多网卡、多 socket 并存时的陷阱

同时打开多个不同协议的 raw socket 时，每个 socket 都会收到自己协议匹配的数据包副本，不存在“谁抢到就算谁的”的竞争关系。这带来一个隐蔽问题：在多个 socket 的维度分别统计流量时，同一个数据包会被重复计数。

bind() 的语义也需要留意：AF_INET + RAW 绑定本地地址后，只会收到目标地址为本机的数据包副本；不 bind 时，能收到哪些数据包取决于路由和系统设置，并不保证能拿到所有非本机目标的数据包。所以如果你的需求是“抓所有经过网卡的包”，不要纠结于 AF_INET raw socket，直接上 AF_PACKET 并设置混杂模式，这才是链路层该做的事。

最后分享一个我自己的习惯：凡是做 raw socket 开发，第一步永远是先写一个最小收包程序，确认能看到预期流量，再开始构造和发送逻辑。调试协议字段时，尽量让抓包工具实时显示结果，每改一个字节就看一眼，不要凭感觉直接改大段代码。任何一次“包发出去了但对端没反应”，都值得按“抓包→字段→校验和→字节序→路由”的顺序过一遍，大部分时候问题就出在那些不起眼的细节上。