最可靠方式是按RFC规范字节偏移解析：以太网包跳过14字节ethhdr，IPv4头长=(iph->ihl&0xF)4，TCP头长=(tcph->th_off>>4)4，所有字段用ntohs/ntohl转换，并校验ip_p==IPPROTO_TCP后再解析。
用 libpcap 抓包后怎么提取 ip_hdr 和 tcp_hdr 字段
直接从原始数据指针偏移解析最可靠，别依赖系统头文件里的结构体对齐——不同平台或编译器可能插入填充字节，导致 ip_hdr->ip_len 读错。实际抓到的数据是连续字节流，必须按 RFC 791 / RFC 793 规定的固定偏移和位宽取值。
常见错误：把 struct iphdr* 强转后直接访问成员，结果在 macOS 或某些嵌入式工具链下崩溃或字段错位。
-
ip_hdr起始位置 = 数据包起始地址；IPv4 首部长度由iph->ihl（低 4 位）决定，单位是 32 位字，所以 IP 头长度 =(iph->ihl & 0xF) * 4 -
tcp_hdr起始位置 = IP 头起始地址 + IP 头长度；TCP 数据偏移字段（th_off）同样以 32 位字为单位，真实 TCP 头长 =(tcph->th_off >> 4) * 4 - 所有字段需用
ntohs()/ntohl()转换，比如ntohs(iph->ip_len)、ntohs(tcph->th_sport)
为什么 pcap_next_ex() 返回的数据包里没有 TCP 负载
不是丢包，是默认链路层封装类型影响了偏移计算。比如用 pcap_open_live("eth0", ...) 在以太网接口抓包，每个包开头有 14 字节 ethhdr，但很多人直接从 packet 指针开始当 IP 包处理，导致后续所有字段全偏移错。
正确做法是先判断 pcap_datalink() 返回值：
立即学习“C++免费学习笔记（深入）”；
- 返回
DLT_EN10MB（即以太网）→ 跳过14字节再找 IP 头 - 返回
DLT_RAW（如 Linux 的any接口或 tun 设备）→ 数据直接是 IP 层，无需跳过链路层 - 返回
DLT_LINUX_SLL（Linux cooked capture）→ 前 16 字节是伪头，IP 头从第 16 字节开始
漏判这个，iph->ip_p 可能读成 0x0800（以太网类型），而不是预期的 IPPROTO_TCP（6）。
如何安全地检查 TCP 包是否有 payload
TCP 负载是否存在，不能只看 tcph->th_flags & TH_PUSH 或简单判断端口——很多 HTTP/HTTPS 流量不带 PUSH 标志，而 DNS 查询可能用 TCP 但只有几字节。
关键看两个长度：
- 整个 IP 包长度：
ntohs(iph->ip_len) - TCP 头长度：
(tcph->th_off >> 4) * 4 - IP 头长度：
(iph->ihl & 0xF) * 4 - 负载长度 =
ntohs(iph->ip_len) - ip_header_len - tcp_header_len；结果 ≤ 0 表示无 payload
注意：ICMP 或 UDP 包混在同一次抓包中很常见，务必先校验 iph->ip_p == IPPROTO_TCP 再解析 TCP 头，否则 tcph 指针指向的是 UDP 或 ICMP 数据，th_sport 会读出乱值。
用 std::string_view 封装原始数据时要注意什么
很多人图省事把 pcap 拿到的 const u_char* 直接构造 std::string_view，结果一越界就 UB。因为 string_view 不检查边界，而 IP/TCP 头长度是动态的，后面还可能没足够字节。
安全做法是：先算出所需最小长度（比如 IP 头至少 20 字节，TCP 头至少 20 字节），再与捕获包总长对比：
- 若
caplen ，跳过该包（截断包，不可信） - 构造
string_view时用sv.data() + offset和明确长度，别用sv.substr()后再取.data()，避免空指针 - 对 payload 做任何操作前，必须确认
payload_len > 0且payload_len
网络协议解析里，最危险的不是逻辑错，是把未验证的内存当结构体解引用——它不会立刻 crash，但会在某个边缘 case 下静默读错数据，排查成本远高于加几行长度检查。
