直接读取pcap中TCP包得不到完整应用层数据，因为TCP是流式协议，数据跨多个分片、可能乱序重传，需重组才能获取完整字节流；pcap仅存原始帧，不包含重组逻辑，须手动或借助libtins等库维护连接状态、缓存排序、处理重叠丢包。
为什么直接读取 pcap 中的 TCP 包得不到完整应用层数据
因为 TCP 是流式协议，Wireshark 或 libpcap 捕获到的每个 tcp 数据包只是流中的一段（segment），可能被分片、重传、乱序；应用层协议（如 HTTP、DNS-over-TCP）的数据往往跨多个包。不重组就解析，strstr() 找不到完整请求头，json_parse() 会失败，甚至触发缓冲区越界。
关键点在于：pcap 文件本身不包含“重组逻辑”，它只存原始帧。你需要自己维护连接状态、按序缓存、处理重叠与丢包。
用 libtins 快速实现带状态的 TCP 重组（推荐入门）
libtins 封装了连接跟踪和流重组，比裸写 libpcap 省力得多，且默认处理 SYN/FIN/RST、滑动窗口、重复 ACK 等边界情况。
- 安装时确保启用
TINS_ENABLE_TCP_REASSEMBLY（CMake 选项），否则tcp_stream不工作 - 必须调用
stream.get_data()而非直接访问tcp.payload()，否则仍是单包碎片 - 注意：
stream.is_complete()返回true仅表示 FIN/RST 已收到，不代表所有中间段都已到达（网络丢包时可能永远为false）
using namespace Tins;
PcapFileReader reader("capture.pcap");
while (Packet pkt = reader.read_next_packet()) {
if (const TCP* tcp = pkt.pdu()->find_pdu<tcp>()) {
auto& stream = reassembler.add_packet(pkt);
if (!stream.empty() && stream.is_complete()) {
const auto& data = stream.get_data();
// data 是重组后的完整字节流，可交给 HTTP parser
}
}
}</tcp>
手动实现重组时必须处理的 4 类边界场景
若因嵌入式环境或性能要求必须手写，以下问题不处理就会导致数据错位或死锁：
-
SYN和FIN包携带的序列号会影响后续 payload 的起始偏移，必须减去SYN标志占用的 1 字节（RFC 793） - 重传包的 payload 可能与已有缓存重叠——需按
tcp.seq截断并覆盖，不能简单追加 - 乱序包到达时，若缓存中已有更高序号数据（比如先收到 [1000,1200)，后收到 [800,1000)），要合并区间，而非丢弃
- 长时间未完成的连接（如长连接空闲）需设超时清理，否则内存泄漏；建议用 LRU cache + TTL（例如 60 秒无新包则 flush）
重组后数据仍无法解析？检查这 3 个隐藏层
即使字节流拼对了，应用层解析失败往往不是重组问题，而是协议层细节被忽略：
- HTTP/1.1 响应可能含
Transfer-Encoding: chunked，此时get_data()返回的是带 chunk header 的原始流，需额外解 chunk，不是直接当字符串用 - DNS over TCP 前 2 字节是长度字段（network byte order），必须先读出
uint16_t len，再截取后续len字节才是 DNS 报文 - TLS 握手阶段的 ClientHello 等记录在 TCP 流中是明文，但后续
Application Data全部加密——重组只能还原密文流，无法得到 HTTP 明文（除非有密钥并集成openssl解密）
真正难的从来不是把包拼起来，而是知道拼完之后那堆字节到底属于哪一层协议、要不要再拆、谁负责解密、谁定义了长度字段。 pcap 是入口，不是终点。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
