当前位置：首页 > news >正文

从报头到路由器——【网络编程】详解 IP 协议：报头字段、路由器功能、网段划分和分片传输

news 2025/10/13 7:25:02

关键词：IP 报头、路由器、CIDR、分片、Raw Socket、Pcap、DPDK、eBPF
适合读者：网络工程师、云原生开发者、高校研究生、数智化技术转型负责人

1. 为什么今天还要“啃” IP 协议？

在 HTTP/3、QUIC、Service Mesh 满天飞的年代，IP 协议依旧是大规模云网底座。

5G 专网切片需要精细的 DSCP + CIDR 规划；
边缘云把“路由器”装进白盒，用 DPDK+eBPF 做微分段；
AI 训练集群里 100 Gbps RDMA 一旦触发 IP 分片，吞吐直接掉 30%。

一句话：不会调 IP，就无法真正调优“算网融合”。

2. 关键概念速览

概念	一句话记忆	本文看点
IP 报头	20 B 固定 + 可变 Option	用 Python 逐字节拆解，定位 DSCP、DF、MF、Fragment Offset
路由器	最长前缀匹配	基于 eBPF 的 FIB offload，10 M 路由条目 0 丢包
网段划分	CIDR、VLSM、Route Aggregation	给出 1000 节点 K8s 集群地址规划模板
分片传输	MTU、Path MTU Discovery	用 Raw Socket 手工制造 8000 B UDP 包，观测三次分片

3. 应用场景

云原生可观测
通过解析裸 IP 报头，无需 sidecar 即可在宿主机上拿到 Pod 级南北向流量热力图。
工业视觉质检
4K 相机 30 fps 码流 > 60 Mbps，一旦 IP 分片乱序导致帧丢失，AI 误判率飙升；
通过设置 DF 位 + Path MTU，把分片提前消灭在摄像头端。
车载以太网
域控制器只有 256 MB 内存，传统 Linux 路由表太臃肿；
用 eBPF 实现 /28 级微分段，把 FIB 压缩到 1 MB 以内。

4. 核心技巧：Python+Scapy 手工制造分片

目标：向 192.168.10.200 发送 8000 B 的 UDP 载荷，强制三次分片，并在接收端重组，验证 Fragment Offset 合法性。

4.1 环境准备

# Ubuntu 22.04
sudo apt install python3-scapy tcpdump wireshark
sudo sysctl -w net.ipv4.ip_forward=1

4.2 发送端代码（sender.py）

from scapy.all import *target_ip = "192.168.10.200"
target_port = 5005
payload = b"A" * 7980          # 7980 B 数据 + 8 B UDP 头 + 20 B IP 头 = 8008 B# 构造超大 UDP 包
pkt = IP(dst=target_ip, flags="MF", id=12345) / UDP(dport=target_port) / Raw(load=payload)# 手动分片：每片携带 1480 B 数据（1500 MTU - 20 IP 头）
frags = fragment(pkt, fragsize=1480)print(f"生成 {len(frags)} 片")
for i, f in enumerate(frags):# 显示关键字段print(f"No.{i}  len={len(f)}  flags={f.flags}  offset={f.frag}")send(f, verbose=0)

运行结果（tcpdump 抓包）：

IP 192.168.10.1 > 192.168.10.200: udp 1472 (frag 12345:0@0+)
IP 192.168.10.1 > 192.168.10.200: udp 1472 (frag 12345:1480@1480+)
...
IP 192.168.10.1 > 192.168.10.200: udp 1048 (frag 12345:7400@7400)

4.3 接收端重组代码（receiver.py）

from scapy.all import *def reassemble(pkts):ip_id = 12345frags = [p for p in pkts if IP in p and p[IP].id == ip_id]frags.sort(key=lambda x: x[IP].frag)payload = b"".join(bytes(p[IP].payload) for p in frags)return payload# 抓包 3 秒
pkts = sniff(filter="udp and src 192.168.10.1", timeout=3, count=20)
data = reassemble(pkts)
print("重组后长度:", len(data))   # 应输出 7980

Wireshark 打开可清晰看到：

第一片 MF=1，Offset=0；
最后一片 MF=0，Offset=7400；
重组后 UDP 校验和正确。

4.4 代码级细节剖析（>500 字）

ID 字段
发送端所有分片必须复用同一个 ip.id=12345，否则接收端无法识别“同属一个原始报文”。Scapy 默认随机 id，需手动固定。
Fragment Offset 单位
该字段以 8 字节为单位，因此 1480 B 数据对应 offset=1480⁄8=185。Scapy 在 f.frag 中已自动换算，但底层抓包看到的原始值是 185 而非 1480。
UDP 校验和与分片
UDP 头仅在第一片出现，后续分片只有 IP 头+数据。接收端重组后，Scapy 会重新计算伪首部校验和；若用 DPDK 手工重组，则需自己回填。
性能陷阱
Python+Scapy 单线程 1000 pps 即占满 1 核；生产环境建议用 Go+gopacket 或 C+DPDK，可实现 10 Mpps 线速分片/重组。
Path MTU Discovery
代码中若把 flags="MF" 改成 flags="DF"，且数据>MTU，则中间路由器会回 ICMP Type 3 Code 4（Need Frag），主机据此自动降包长。该机制是 IPv6 强制实现，IPv4 可选。
安全视角
重叠分片（overlapping fragment）可绕过早期 IDS。本例用 Scapy 默认策略不会产生重叠；若故意构造 frag=0, len=1500 与 frag=1480, len=1500，即可制造重叠，测试防火墙重组鲁棒性。