基于libpcap的TCP数据包解析与四元组流分析实践

简介面向高校计算机网络课程学习者与 TCP 协议实践者这份燕大计算机网络三级项目资料提供可运行的 TCP 传输数据包工程围绕连接建立、数据分片重组、流量控制与拥塞控制展开可用于课程设计、实验复现及网络编程进阶练习。压缩包共 60 个文件、约 27.88MB包含 cpp 源码与 h 头文件、sln 解决方案、exe 可执行程序以及 tlog、log 日志和 pdb 调试信息等覆盖客户端与服务器实现、工程编译、运行验证和过程排查。已有 1355 人学习下载可作为燕大三级项目的参考样本。读者可对照梳理三次握手、四次挥手、滑动窗口、ACK 确认与重传逻辑并借助慢启动、快速重传、快速恢复等算法理解 socket 收发流程日志和调试文件也便于定位异常适合需要完整工程范例与排错线索的读者。1. 抓了一个下午全是空包这个 TCP 数据包三级项目到底交什么去年帮人看一个计算机网络三级项目的验收程序跑起来终端刷得飞快抓的全是长度 0 的空包答辩前一晚还在怀疑是不是网卡坏了。问题其实很小抓包长度参数给成了 0链路层头都没读进来。这类项目看着是「写个程序打印 TCP 数据包」真做起来是一整条链路工程——打开网卡、设过滤规则、按字节拆帧、算四元组、还原一次连接的握手和挥手。某高校计算机网络课程的这个三级项目交付的就是这么一套东西一个能实时抓取本机 TCP 流量、把以太网帧/IP 头/TCP 头逐字段打印出来、并做基础连接统计的解析器。适合刚学完协议栈、想把手绘图变成能跑代码的同学也适合把它当抓包分析工具底座继续往上加功能的人。下面按我拆这份工程的顺序讲先看骨架再看头部解析然后跑通、排坑最后说怎么改。2. 工程骨架从网卡到回调函数的四层拆分这类项目最容易写成一个大 main 文件两百行串到底编译能过改一处崩三处。真正好验收、好扩展的版本通常按「采集层 → 解析层 → 会话层 → 展示层」切开。核心原因在于职责边界采集层只关心「拿到一帧原始字节」解析层只关心「把字节翻译成字段」会话层只关心「这些包属于哪条连接」展示层只关心「怎么打得好看」。分开之后任何一层出问题都能单独定位而不是对着一个巨型回调里的 printf 猜是哪一步错了。2.1 目录树与文件职责先给一份我拆的时候整理的目录不同人实现细节会有出入但分层大致是这套tcp-sniffer/ ├── Makefile ├── include/ │ ├── capture.h # 采集层接口初始化、启动、停止 │ ├── parse.h # 解析层接口以太网/IP/TCP 结构体与函数声明 │ ├── flow.h # 会话层接口四元组流表 │ └── stats.h # 统计项定义 ├── src/ │ ├── main.c # 参数解析、模块装配、信号处理 │ ├── capture.c # 基于 libpcap 的打开/过滤/回调 │ ├── parse.c # 逐字节解析头部填充自定义结构 │ ├── flow.c # 哈希流表、握手状态机、超时回收 │ └── stats.c # 计数、按流输出、结束时汇总 └── scripts/ └── traffic.sh # 造流量的验证脚本parse.h里通常会自己定义一套头部结构体而不是直接用系统netinet/tcp.h里的struct tcphdr。理由很实在一来课程验收要求「手工算偏移」用现成结构体等于把作业交给内核头文件二来系统头文件在不同平台字段顺序和位域处理不完全一致尤其 Windows 下那套命名交叉编译时容易翻车。自己按 RFC 定义一份uint8_t数组 位域反而是最稳的。2.2 一次抓包在代码里的完整流转路径整条链路是回调驱动的主线程调pcap_loop阻塞在那里每来一个包libpcap 回调一次参数里带三个东西——用户上下文、包头信息时间戳、抓到的长度、线上真实长度、指向原始字节的指针。真正的解析全部在回调里完成所以要特别注意别在回调里做耗时操作比如同步写磁盘或者大量内存分配否则会丢包。采集层初始化这一步是实现里最关键的一段写不好后面全是玄学问题// src/capture.c —— 打开网卡、编译过滤规则、进入回调循环 #include pcap.h #include capture.h #include parse.h int capture_start(const char *dev, const char *filter, int snaplen) { char errbuf[PCAP_ERRBUF_SIZE]; struct bpf_program fp; bpf_u_int32 net 0, mask 0; /* 1. 打开设备promisc0 只收自己网卡的包超时 1000ms */ pcap_t *handle pcap_open_live(dev, snaplen, 0, 1000, errbuf); if (handle NULL) { fprintf(stderr, open_live failed: %s\n, errbuf); return -1; } /* 2. 确认链路层类型不是以太网的要在解析层走另一套分支 */ if (pcap_datalink(handle) ! DLT_EN10MB) { fprintf(stderr, warning: datalink%d, not ethernet\n, pcap_datalink(handle)); } /* 3. 编译并挂载 BPF 过滤规则把非 TCP 流量挡在内核层 */ if (pcap_compile(handle, fp, filter, 0, mask) -1) { fprintf(stderr, compile filter failed: %s\n, pcap_geterr(handle)); pcap_close(handle); return -1; } if (pcap_setfilter(handle, fp) -1) { fprintf(stderr, setfilter failed: %s\n, pcap_geterr(handle)); pcap_freecode(fp); pcap_close(handle); return -1; } pcap_freecode(fp); /* 规则已下沉到内核这里可以立刻释放 */ /* 4. 进入循环-1 表示抓到 Ctrl-C 为止 */ pcap_loop(handle, -1, packet_callback, NULL); pcap_close(handle); return 0; } /* 每来一个包回调一次caplen 是抓到的字节数len 是线上真实长度 */ static void packet_callback(u_char *user, const struct pcap_pkthdr *hdr, const u_char *bytes) { (void)user; handle_frame(bytes, hdr-caplen, hdr-len, hdr-ts); }这段的逻辑链条是先开设备拿到句柄再用 BPF 把tcp这类过滤条件下沉到内核避免用户态处理无关流量最后交给pcap_loop无限循环。参数上要盯住几个点promisc设 0 表示不启用混杂模式本机流量够用设 1 会收到同网段他人的帧反而增加噪声也确实有越界嫌疑课程项目一般不该开timeout单位是毫秒只影响pcap_next_ex这类返回式的用法对pcap_loop的阻塞语义影响不大snaplen是每个包最多抓多少字节128 到 256 够解析头部但要看载荷就得给 1514 甚至 65535。hdr-caplen和hdr-len必须分开看前者是实际复制给你的字节数后者是帧在链路上的真实长度。caplen len就说明被 snaplen 截断了此时载荷不完整解析层必须检查长度再读否则读越界程序时好时坏——这就是那个「抓了一下午空包」的直接原因。pcap_datalink这个检查别省。以太网返回DLT_EN10MBLinux 回环口常见的是DLT_LINUX_SLL或SLL2抓到的是「伪链路层头」16 字节而不是 14 字节的以太网头。如果不判断本地跟自己通信的流量解析全部错位IP 版本号读出来是个奇怪的数你会以为是自己 IP 头写错了其实是链路层类型不一样。3. 头部逐字节解析以太网、IP、TCP 三层怎么对齐偏移解析层的核心就一句话所有字段的位置都由前面头部的长度字段算出来不能写死常量。以太网头固定 14 字节含 VLAN 时 18IP 头长度由 IHL 字段乘 4 得到TCP 头长度由 data offset 乘 4 得到载荷起点是三者累加。写死偏移量在第 90% 的包上不会出错剩下 10% 带选项的包会让整门课的成绩变成玄学。3.1 链路层与 IP 层字节序和可变长头部先定义结构体字段用uint8_t/uint16_t明确宽度别用unsigned int那个在 64 位平台上会悄悄变 8 字节。// include/parse.h —— 按 RFC 定义的头部结构全部大端序存放 #include stdint.h #define ETH_HLEN 14 #define ETH_TYPE_IP 0x0800 #define ETH_TYPE_VLAN 0x8100 #define ETH_TYPE_IPV6 0x86DD typedef struct { uint8_t dst_mac[6]; uint8_t src_mac[6]; uint16_t ether_type; /* 大端序须 ntohs 后再比较 */ } eth_hdr_t; typedef struct { uint8_t ver_ihl; /* 高 4 位版本低 4 位首部长度(单位 4 字节) */ uint8_t tos; uint16_t total_len; uint16_t id; uint16_t flags_frag; /* 高 3 位标志低 13 位片偏移 */ uint8_t ttl; uint8_t proto; uint16_t checksum; uint32_t src_ip; uint32_t dst_ip; } ip_hdr_t; typedef struct { uint16_t src_port; uint16_t dst_port; uint32_t seq; uint32_t ack; uint8_t offset_reserved; /* 高 4 位 data offset(单位 4 字节) */ uint8_t flags; /* CWR ECE URG ACK PSH RST SYN FIN */ uint16_t window; uint16_t checksum; uint16_t urg_ptr; } tcp_hdr_t;结构体只是给编译器算偏移用的模板真正读取时一律做「指针 长度校验 ntohs转换」三件事// src/parse.c —— 以太网与 IP 层的解析与边界检查 #include parse.h #include arpa/inet.h #include string.h int parse_ethernet(const uint8_t *buf, uint32_t caplen, uint16_t *ether_type, uint32_t *l3_off) { if (caplen ETH_HLEN) return -1; /* 连头都不全直接扔 */ const eth_hdr_t *eth (const eth_hdr_t *)buf; uint16_t type ntohs(eth-ether_type); uint32_t off ETH_HLEN; /* 802.1Q VLAN 标签4 字节类型字段前移必须循环剥 */ while (type ETH_TYPE_VLAN) { if (caplen off 4) return -1; type ntohs(*(const uint16_t *)(buf off 2)); off 4; } *ether_type type; *l3_off off; return (type ETH_TYPE_IP) ? 0 : 1; /* 1 表示非 IPv4跳过 */ } int parse_ipv4(const uint8_t *buf, uint32_t caplen, uint32_t l3_off, const ip_hdr_t **ip_out, uint32_t *l4_off) { if (caplen l3_off sizeof(ip_hdr_t)) return -1; const ip_hdr_t *ip (const ip_hdr_t *)(buf l3_off); uint8_t version ip-ver_ihl 4; uint8_t ihl (ip-ver_ihl 0x0F) * 4; /* 首部字节数 */ if (version ! 4 || ihl 20) return -1; if (caplen l3_off ihl) return -1; /* 带选项时再校验一次 */ /* 分片片偏移非 0 的包没有完整 TCP 头交给重组模块 */ uint16_t frag ntohs(ip-flags_frag) 0x1FFF; if (frag ! 0) return 2; *ip_out ip; *l4_off l3_off ihl; return 0; }逻辑要拆开说清楚。链路层先校验最低长度然后处理 VLAN市面上没人天天跑 VLAN 环境可只要你抓的是虚拟机桥接网卡或者交换机镜像口标签就冒出来了不剥这一层IP 头会从 VLAN 标签的位置开始读版本号显示成0x00或者干脆乱码。剥完之后l3_off记得跟着加 4不是固定 14。IP 层三个判断不能省版本号必须是 4IHL 小于 20 说明畸形成帧caplen必须覆盖到l3_off ihl因为 IP 选项会让首部变成 24、28 字节。分片那条判断更关键——UDP 分片常见TCP 理论上少见但 TCP 段超过 MTU 时 IP 层照样切片片偏移非 0 的包载荷里没有 TCP 头硬当 TCP 解析会解析出完全不存在的端口号和序列号统计表里莫名其妙多出一堆「幽灵连接」。字段单位也顺手确认一下ver_ihl里 IHL 的单位是 4 字节所以要乘 4total_len是整个 IP 数据报长度含首部不是载荷长度flags_frag里高 3 位才是标志DF/MF低 13 位是片偏移做掩码0x1FFF才是偏移值。3.2 TCP 头data offset 决定载荷从哪儿起TCP 层比 IP 层多一个坑头长度藏在offset_reserved的高 4 位里单位也是 4 字节最小 20最大 60。写死 20 在纯 SYN、纯 ACK 这种没选项的包上完全正常一旦遇到 SYN 带 MSS/SACK/WScale 的就全乱后续所有字节偏移都错载荷打印出来是几个字节的乱码。// src/parse.c —— TCP 层解析顺带把 flags 拆成可读标记 #include stdio.h #define TCP_FIN 0x01 #define TCP_SYN 0x02 #define TCP_RST 0x04 #define TCP_PSH 0x08 #define TCP_ACK 0x10 #define TCP_URG 0x20 typedef struct { uint16_t sport, dport; uint32_t seq, ack; uint8_t flags; uint16_t window; uint32_t payload_len; const uint8_t *payload; } tcp_info_t; int parse_tcp(const uint8_t *buf, uint32_t caplen, uint32_t l4_off, uint16_t ip_total_len, tcp_info_t *out) { if (caplen l4_off 20) return -1; const tcp_hdr_t *tcp (const tcp_hdr_t *)(buf l4_off); uint8_t doff (tcp-offset_reserved 4) * 4; /* 首部字节数 */ if (doff 20 || caplen l4_off doff) return -1; out-sport ntohs(tcp-src_port); out-dport ntohs(tcp-dst_port); out-seq ntohl(tcp-seq); out-ack ntohl(tcp-ack); out-flags tcp-flags; out-window ntohs(tcp-window); /* 载荷长度要用 IP 总长反推caplen 可能被 snaplen 截断 */ uint32_t seg_len ip_total_len - (l4_off - ETH_HLEN) - doff; uint32_t avail caplen - l4_off - doff; out-payload_len (seg_len avail) ? seg_len : avail; out-payload buf l4_off doff; return 0; } /* 把 flags 字节翻译成 SNY/ACK 这类短标记方便日志里看握手 */ void flags_to_str(uint8_t flags, char *dst, size_t n) { snprintf(dst, n, %s%s%s%s%s%s, (flags TCP_SYN) ? S : , (flags TCP_ACK) ? A : , (flags TCP_FIN) ? F : , (flags TCP_RST) ? R : , (flags TCP_PSH) ? P : , (flags TCP_URG) ? U : ); }这里的重点是载荷长度不能只用caplen算。caplen是「抓到了多少」不是「这个 TCP 段有多少」。正确做法是用 IP 头里的total_len减去 IP 首部长度、再减 TCP 首部长度得到逻辑上的段长度然后跟caplen能提供的可读字节数取小值。否则 snaplen 给 128 的时候你会把最后半截 TCP 头后面的残留内存当成 HTTP 报文打印看着像乱码其实是读了别人的数据。seq和ack必须做ntohl这两个是 32 位字段大小端搞反之后序列号显示成0x0100007f这种数肉眼根本看不出握手是否连续做丢包分析也就没法做了。window字段同理16 位。3.3 四元组流表把散包拼成一次连接单包解析完只是流水账。三级项目要拿得出手的部分通常是把包归到连接上源 IP、源端口、目的 IP、目的端口加上协议号构成五元组因为只做 TCP四元组就够。归一化方向很重要——同一个连接的两个方向要落到同一条记录里否则一次下载会被算成两条流。// src/flow.c —— 用开放寻址哈希表管流键做双向归一化 #include string.h #include flow.h #define FLOW_SLOTS 4096 typedef struct { uint32_t key[5]; /* 归一化后的 src/dst ip port */ uint64_t pkts[2]; /* [0] 正向 [1] 反向 */ uint64_t bytes[2]; uint32_t syn_cnt, fin_cnt, rst_cnt; time_t first, last; int used; } flow_entry_t; static flow_entry_t g_flows[FLOW_SLOTS]; static uint32_t hash_key(const uint32_t *k) { uint32_t h 2166136261u; for (int i 0; i 5; i) { h ^ k[i]; h * 16777619u; } return h % FLOW_SLOTS; } /* 返回值 0 表示正向1 表示反向方便分别累加 */ flow_entry_t *flow_lookup(uint32_t sip, uint16_t sp, uint32_t dip, uint16_t dp, int *dir) { uint32_t k[5], rk[5]; k[0]sip; k[1]sp; k[2]dip; k[3]dp; k[4]6; rk[0]dip; rk[1]dp; rk[2]sip; rk[3]sp; rk[4]6; /* 小端序的 IP/端口数值直接比大小保证两个方向落到同一格 */ int swap (sip dip) || (sip dip sp dp); uint32_t *use swap ? rk : k; uint32_t idx hash_key(use); for (int i 0; i FLOW_SLOTS; i) { uint32_t pos (idx i) % FLOW_SLOTS; flow_entry_t *e g_flows[pos]; if (!e-used) { e-used 1; memcpy(e-key, use, sizeof(use[0]) * 5); e-first e-last time(NULL); *dir swap ? 1 : 0; return e; } if (memcmp(e-key, use, sizeof(use[0]) * 5) 0) { e-last time(NULL); *dir swap ? 1 : 0; return e; } } return NULL; /* 表满课上项目直接放弃插入即可 */ }逻辑上做了两件事用 IP 和端口的数值大小关系定一个固定顺序让A→B和B→A哈希到同一个槽命中后用dir告诉调用方这一包属于哪个方向统计时分别累加。哈希函数用 FNV-1a 就够4096 个槽应付一台机器几千条并发连接没什么压力。syn_cnt / fin_cnt / rst_cnt三个计数器看着简陋实际很有用SYN出现但SYNACK没出现多半是握手包被丢在抓包之前或者过滤规则挡掉了RST计数偏高说明服务端在拒绝不是网络问题FIN是奇数个说明有半关闭连接没走完。这些在验收时被问到「你怎么证明程序解析对了」比翻一屏包详情有说服力得多。4. 跑起来编译、权限、造流量三步走通环境这一步翻车率最高跟代码质量关系不大基本都卡在权限和依赖上。4.1 依赖与权限别在第一步翻车Linux 下装开发库Debian 系和 RedHat 系命令不同按自己的发行版来# Debian/Ubuntu 系 sudo apt update sudo apt install -y build-essential libpcap-dev tcpdump curl # RedHat/CentOS 系 sudo dnf install -y gcc make libpcap-devel tcpdump curl抓包要原始套接字权限两种做法直接sudo跑或者给可执行文件加能力位。课程演示我一般用前者本地长期调试用后者因为sudo跑出来的文件属主是 root改完代码再编译容易撞上权限问题。# 方式一临时提权运行 sudo ./tcp-sniffer -i eth0 -f tcp # 方式二给二进制加能力位之后普通用户也能跑 sudo setcap cap_net_raw,cap_net_admineip ./tcp-sniffer getcap ./tcp-sniffer # 确认 cap_net_raw 已生效Windows 下对应的是 Npcap安装时勾选「支持 WinPcap 兼容模式」SDK 目录要加到编译器的 include 和 lib 路径里。管理员权限启动终端否则pcap_open_live直接返回空句柄错误串是The capture session could not be initiated看着像代码问题其实是权限。4.2 编译与运行参数怎么传给一份能直接用的 Makefile注意-lpcap放在源文件后面链接顺序错了会报一堆 undefined referenceCC gcc CFLAGS -O2 -g -Wall -Wextra -Iinclude LDFLAGS -lpcap SRCS $(wildcard src/*.c) OBJS $(SRCS:.c.o) TARGET tcp-sniffer $(TARGET): $(OBJS) $(CC) $(OBJS) -o $ $(LDFLAGS) %.o: %.c $(CC) $(CFLAGS) -c $ -o $ clean: rm -f $(OBJS) $(TARGET)-Wall -Wextra一定要开指针类型不匹配、有符号无符号比较这些警告在解析代码里往往就是越界读的前兆。-g保留符号出问题好挂 gdb。主函数负责解析参数并装配各层参数不用多够用就行// src/main.c —— 命令行参数与模块装配 #include stdio.h #include string.h #include signal.h #include pcap.h #include capture.h static volatile sig_atomic_t g_stop 0; static void on_sigint(int s) { (void)s; g_stop 1; } int main(int argc, char **argv) { const char *dev NULL, *filter tcp; int snaplen 65535; for (int i 1; i argc; i) { if (!strcmp(argv[i], -i) i 1 argc) dev argv[i]; else if (!strcmp(argv[i], -f) i 1 argc) filter argv[i]; else if (!strcmp(argv[i], -s) i 1 argc) snaplen atoi(argv[i]); else { printf(usage: %s -i iface [-f filter] [-s snaplen]\n, argv[0]); return 1; } } if (!dev) { char errbuf[PCAP_ERRBUF_SIZE]; pcap_if_t *alldevs; if (pcap_findalldevs(alldevs, errbuf) 0 alldevs) dev alldevs-name; printf(no -i given, fallback to %s\n, dev ? dev : none); } signal(SIGINT, on_sigint); return capture_start(dev, filter, snaplen); }运行就是三条命令先确认网卡名再启动ip addr | grep -E ^[0-9]: # 看有哪些网卡别写错成 lo make sudo ./tcp-sniffer -i eth0 -f tcp and port 80 or port 443参数含义-i指定网卡本机跟外网通信一般用主网卡抓本机自连用lo-f是 BPF 过滤表达式tcp抓全部 TCP加上and host 10.0.0.5可以只看跟某个地址的交互语法跟 tcpdump 一致-s是抓包长度默认给满要看载荷就不用改。Ctrl-C退出时应该打印统计汇总如果没打印说明信号处理只置了标志位循环还是阻塞在pcap_loop里——这算个小瑕疵改进方式是用pcap_breakloop。4.3 造流量验证用 curl 和 iperf 对着自己打别拿真实业务流量验证不可复现。开一个本地 HTTP 服务然后用 curl 打几次抓到的包序列你能完整预判三次握手 SYN / SYNACK / ACK一两个 PSHACK 带请求报文服务端回 ACK 和响应最后 FIN 两轮。这条链路对不上就说明解析有偏差。# 终端 A起一个本地服务 python3 -m http.server 8080 # 终端 B抓包只看回环口上的 8080 sudo ./tcp-sniffer -i lo -f tcp port 8080 # 终端 C制造一次完整的请求 关闭 curl -s http://127.0.0.1:8080/ /dev/null如果程序输出里没有S打头的包先看过滤表达式有没有写错端口再看 BPF 是否在pcap_setfilter之后就被释放了pcap_freecode释放的是程序副本句柄里那份还在这个顺序没错。如果握手序列全了但序列号看着不是1递增八成是没做ntohl。大数据量验证用 iperf3 打十秒钟重点看统计里的包数和字节数有没有明显丢——丢得多不是网络问题是回调里做了阻塞操作。一个实用的对照手法同一个条件下用tcpdump -i lo -nn tcp port 8080 -c 20抓二十个包逐条跟你程序打印的端口、序列号、标志位比对。对不上的那条就是解析 bug 的位置比盯着代码找快得多。这个习惯我建议从课程项目就养成省下来的时间比多写两百行代码值。5. 排查记录五个让程序「看着能跑」却结果不对的坑这类项目的坑有共性基本都在「看起来跑起来了但数据不可信」这个阶段。下面五条是我遇到过、并且别人代码里也反复出现的。现象一终端刷得很快但每个包长度都是 0字段全是 0。原因pcap_open_live的snaplen传了 0libpcap 认为你一个字节都不要回调里caplen就是 0parse_ethernet第一句长度判断直接返回 -1。解决snaplen给 65535 或者至少 128并让解析层在长度不足时打印告警而不是静默 return静默返回会让这种参数错误伪装成「网络没流量」。现象二本地回环口抓到的包IP 版本号不是 4端口号离谱。原因回环口链路类型是DLT_LINUX_SLL头部 16 字节不是以太网 14 字节按以太网偏移去读 IP 头整体错位 2 字节。解决启动时用pcap_datalink判断类型DLT_EN10MB走以太网分支其他类型要么跳过 16 字节伪头要么换DLT_LINUX_SLL2对应结构。别指望「先只支持以太网」糊弄过去课程演示十有八九是在本机lo上跑的。现象三抓 HTTP 请求时载荷打印出来是乱码或者多了几个字节。原因TCP 头长度写死 20实际 SYN 包带 MSS、SACK Permitted、Window Scale 选项头长 32 或 40 字节payload指针算早了。解决从offset_reserved高 4 位取 data offset 乘 4且校验范围在 20 到 60 之间载荷长度用 IPtotal_len反推后再跟caplen取小值。现象四统计表里连接数暴涨同一条下载被拆成几百条。原因四元组的键没做归一化A→B和B→A各自建了一条记录或者哈希键里混进了会变的字段比如序列号。解决键只放源 IP、源端口、目的 IP、目的端口、协议号五项用地址端口的数值大小定固定顺序后再哈希方向用返回值区分。哈希表容量给足4096 起步别用 64。现象五程序退出时统计不打印或者打印一半就没了。原因Ctrl-C只置了标志位主线程还阻塞在pcap_loop永远走不到pcap_close后面那段汇总另一种是在回调里直接printf大量内容缓冲区还没刷就被信号打断。解决信号处理里调pcap_breakloop(handle)把句柄存成全局或者通过user上下文传进去回调里尽量只累计计数输出放到循环结束后统一做日志用行缓冲或者在退出前fflush(stdout)。提示排查顺序建议固定成「先看 caplen 和 snaplen → 再看 datalink 类型 → 再看 IHL/doff → 最后看字节序」。这四步能覆盖九成以上的解析错误比从头读代码快。6. 二次开发把它改成能出报告的流分析模块课程验收完这套代码还有利用价值。最顺手的方向是把「实时打印」改成「离线分析 报告输出」接口基本不用动改三处就够。改造点原来改成收益数据源pcap_open_live实时pcap_open_offline读 pcap 文件结果可复现能反复调试输出每包 printf结束时按流汇总写 CSV能拿去做表格和图表状态无连接生命周期SYN/FIN/RST 计数 超时回收能判断连接是否正常关闭核心是分离「解析」和「输出」把packet_callback里的打印全删掉只往流表里累加末尾统一导出// src/stats.c —— 遍历流表导出 CSV供表格工具直接打开 void stats_dump_csv(flow_entry_t *flows, int n, FILE *fp) { fprintf(fp, src_ip,src_port,dst_ip,dst_port,pkts,bytes,dur_s,syn,fin,rst\n); for (int i 0; i n; i) { flow_entry_t *e flows[i]; if (!e-used) continue; char s[INET_ADDRSTRLEN], d[INET_ADDRSTRLEN]; struct in_addr a { .s_addr e-key[0] }, b { .s_addr e-key[2] }; inet_ntop(AF_INET, a, s, sizeof(s)); inet_ntop(AF_INET, b, d, sizeof(d)); fprintf(fp, %s,%u,%s,%u,%llu,%llu,%ld,%u,%u,%u\n, s, e-key[1], d, e-key[3], (unsigned long long)(e-pkts[0] e-pkts[1]), (unsigned long long)(e-bytes[0] e-bytes[1]), (long)(e-last - e-first), e-syn_cnt, e-fin_cnt, e-rst_cnt); } }验证方式也简单先用tcpdump -w test.pcap -i lo tcp port 8080存一段流量再用改造后的程序离线跑输出的连接数应该跟tcpdump -r test.pcap | wc -l大致对得上一条连接对应多条报文看的是流的条数不是包数。数字对不上就回到第 5 章那四条排查顺序走一遍。想再往前一步可以做流重组按序列号排序载荷拼出完整的应用层报文这时候就能看到 HTTP 请求头。这一步的坑在重传和乱序初始序列号要用 SYN 包的 seq1 作为基准否则拼出来永远差一位。我当时的教训是抓了一晚上以为是乱序问题最后发现是 SYN 包的序列号没加一。从那以后我每次写这类解析代码都强制先用tcpdump抓一份固定的小 pcap 当回归样本改完代码先跑它输出跟预期序列逐条比对对上了再去抓实时流量。这个习惯让后面所有协议相关的调试都省了至少一半时间。希望帮到你。本文还有配套的精品资源点击获取