Page 466 - 《软件学报》2025年第7期

吴桦 等: 面向 HTTP/2 流量多路复用特征的加密视频识别方法 3387

用技术, 在一个 CDU 中混杂传输的音视频无法分开, 本文的目标是将 CDU 作为一个整体进行长度修正, 因此, 需
要在音视频流中精准划分出可以修正的 CDU.
(1) 音视频数据流提取
由于标准的 TLS 加密数据使用 TCP 的 443 端口, 所以首先可以从所有数据流中筛选出使用 443 端口的加密
TCP 数据流. 其次, 虽然 TLS 协议因其加密性使其负载数据内容无法获知, 但在建立 TLS 连接时, 其握手信息
“Client Hello”中包含了一些未被加密的信息, 如服务器的 SNI (server name indication) 等, 可以利用 SNI 字段来区
分音视频流和非音视频流. 需要说明的是, 由于 HTTP/2 有多路复用机制, 多个 HTTP 请求可以通过 1 条 TCP 流传
输, 这意味着, 如果音频流和视频流的 SNI 相同, 那么音频数据和视频数据可以通过 1 条 TCP 流传输. 为了方便后
续叙述, 本文将音频流、视频流、音频和视频流统称为音视频流. 最后, 可以根据流的数据量大小区分是否为视频
的数据流. 经过以上过滤操作, 可以准确地提取出音视频流.
(2) TLS 记录序列提取
由于提取出的音视频流是位于传输层的 TCP 数据流, 因此还需要去除 TCP 数据包的头部信息长度, 并组合
出 TLS 记录序列, 便于计算后续 TLS 记录在传输数据中产生的干扰量. 为此, 本文实现了一个类似于 TCP 协议栈
端系统的缓冲机制, 将 TCP 报文根据其头部信息按序在缓冲区排序, 并基于 TLS 协议规范从 TCP 数据包中组合
出 TLS 记录. 根据 TLS 记录头部仅存的明文信息, 可以得到每个 TLS 记录的长度信息, 再根据每个 TCP 载荷的
实际长度信息, 将 TCP 数据包合并或者拆分到各 TLS 记录中, 构成 TLS 记录序列用于后续特征提取. 该过程可以
有效确保 TLS 序列的完整性和准确性, 从而对抗真实世界中的网络抖动和拥塞现象.
(3) 精准划分加密音视频组合数据单元 CDU
音视频组合数据单元 CDU 可能包含 1 到多个音视频数据片段组合. 由于 HTTP/2 的多路复用特性, 同一条
TCP 连接上会同时存在多条数据流的传输数据 (如图 7 所示), 为方便后续的修正还原工作, 需要精准划分出加密
数据流的音视频分组数据 CDU, 使划分出的每一组加密数据都只包含 1 个 CDU.

CDU

音频数据片段 a 1 a 2 a 3 a 4 a 5 a 6 a 7 a 8 a 9 a 10 a 11 a 12

视频数据片段 v 1 v 2 v 3 v 4 v 5 v 6 v 7 v 8

客户端 服务端
图 7 加密音视频分组数据单元 CDU 精准划分

对 CDU 的划分是通过特定长度的 TLS 记录作为标识. 根据 RFC 7540 标准, WINDOW_UPDATE 帧在
HTTP/2 中用于流量控制. 视频服务器响应各组音视频 CDU 数据时, 会先发送若干个 WINDOW_UPDATE 帧来更
新每条 HTPP/2 流的数据窗口大小, 且这些 WINDOW_UPDATE 帧被封装在同一个 TLS 记录中传输. 由于每个
WINDOW_UPDATE 帧大小固定为 13 B [35] , 通过观察, WINDOW_UPDATE 帧经 TLS 协议处理封装后, 大小变为
35 B, 包含两个 WINDOW_UPDATE 帧的 TLS 记录大小为 48 B, 正好增加一个 WINDOW_UPDATE 帧的长度, 依
此类推, 本文将 35 B、48 B、61 B、74 B 和 84 B 等大小的 TLS 记录作为标志 TLS 记录, 标识 CDU 的开始.

5.3 针对 TLS 协议干扰的修正
公式 (1) 中的参数 TLS _θ len 为单个 TLS 记录在承载传输数据后引入的干扰量的均值, 本节将根据修正还原公
式 (1) 构建线性回归修正模型, 利用回归修正模型估算参数 TLS _θ len .
在 HTTP/2 协议中, 音视频 CDU 会被分割后封装在 HTTP/2 DATA 帧中, 然后由 TLS 协议进一步封装到
TLS 记录中, 如果 HTTP/2 DATA 帧的长度超过了 TLS 记录的最大负载长度, 则会被切分到多个 TLS 记录中进行