Page 364 - 《软件学报》2026年第4期

张宾 等: 基于大型 DNS 递归服务的域名访问模式测量与分析 1805

3 测量分析方案

对于 DNS 服务商提供的如此庞大的数据量, 如何进行有效的测量分析是本文首先要解决的问题. 测量需要实现
周期数据存储不遗漏, 数据不重算, 不少算; 每天汇总数据存储不遗漏, 累加数据不重算, 不少算; 并且在常态下, 分析
速度接近留存速度, 平均滞后在 30 min 以内; 同时, 保证分析程序状态和存储数据程序状态可被持续监控.
3.1 多机分布式并行测量机制
数据的分析目标是一系列大量的包括 DNS 报文的 PCAP 压缩文件, 需要对这些文件的内容进行快速有效的
读取和分析. 测试发现, 使用 Python 直接读一个 PCAP 压缩包耗时 120 s 以上, 而先解压缩再读包时间超过 50 s,
主要原因是直接读 PCAP 压缩包实际是在内存中解压输出文件流, 支持在内存中读压缩包的组件是 Python 内置
的, 性能比较差, 而通过执行 Linux 系统的 tar 命令解压, 采用 C 语言实现, 性能较好, 所以采用先解压再读方式读
取 PCAP.
但是, 对于这些文件, 需要考虑在一台机器中用一个线程一次读取一个文件, 还是用多个线程并行读取多个文
件, 哪种方式读取效率更高的问题. 表 1 是具体的测试数据, 按照正常推算, 在一台机器上单线程顺序读取两个文
件时间为 110 s, 小于表 1 中单台机器两个线程读取两个文件的时间 141 s, 在单台机器单线程顺序读取 5 个文件
的时间为 275 s, 远小于在单台机器上启动 5 个线程读取同样 5 个文件的时间, 对于更多的线程通过进一步测试,
并没有单线程处理文件效率更高. 可能的原因在于线程在使用多个内核或处理器的 CPU 密集型任务上获得更好
的性能, 但文件读取不是 CPU 密集型任务, 磁盘 IO 是大文件读取的主要性能瓶颈, 使用多线程对文件读取还额外
需要进行互斥锁的竞争, 反而降低了效率. 因此, 采用单线程的方式具有更加快速的读取效率.
但是, 由于要处理的文件量比较大, 采用分布式多机的处理方式, 需要把文件及时分发到不同机器上进行并行
处理, 具体分发 PCAP 的逻辑如图 2 所示. 主要机制是当解析文件速度不落后留存文件太多时 (≤3 个文件) 时, 只
让本机分发节点处理, 减少跨节点传输文件带来的时间消耗. 采用此分发机制的主要因素是 PCAP 文件较大, 特别
是应答报文要远大于请求报文, 传输的网络带宽有限, 而过于频繁的文件分发会降低文件的读取效率, 经过测试,
留存 3 个文件以内只在本机分发可以获得较好的文件处理效率. 后续, 对于文件的分发过程可以进行进一步的动
态优化, 对于较大的文件留存更少, 而较小的文件留存量增加, 同时增加网络状态参数进行控制.

分发 PCAP

待处理 否
PCAP 数
≤3?

表 1 不同线程读取时间的对比 是

线程数 耗时 (s) 读取的文件数
只分发到本机节点 均衡分发
1 55 1
2 141 2
5 1 007 5
分发结束
10 1 101 10
15 1 453 15
图 2 PCAP 压缩文件分发流程
这样, 一天 DNS 流量对应的 PCAP 压缩文件, 主要解析和分析流程如图 3 所示. 流程分为留存 PCAP 分发, 解
析 IP 和分析 IP, 其中分发流程由留存文件所在机器执行, 并轮询被分发的机器获取 IP 列表文件, 被分发的机器包
含多台, 每个机器启动解析 IP 的程序, 负责把分发的 PCAP 压缩包解析出 IP 文件; 分析 IP 程序也在 PCAP 留存
机器执行, 负责分析 IP 的归属地和运营商等信息, 并做实时累加统计, 完成分析每天留存文件后再通过 Kafka 发
送到一个分布式实时存储和搜索引擎 Elasticsearch 服务平台存储. 这样, 后续分析的所有特征和统计信息都进入
Elasticsearch 服务平台.