程光，房敏，吳樺

（1.東南大學(xué)網(wǎng)絡(luò)空間安全學(xué)院，江蘇 南京 211189；2.東南大學(xué)計(jì)算機(jī)網(wǎng)絡(luò)和信息集成教育部重點(diǎn)實(shí)驗(yàn)室，江蘇 南京 211189；3.東南大學(xué)計(jì)算機(jī)科學(xué)與工程學(xué)院，江蘇 南京 211189）

1 引言

近年來，隨著網(wǎng)絡(luò)基礎(chǔ)設(shè)施的不斷建設(shè)及用戶數(shù)量的不斷增加，互聯(lián)網(wǎng)業(yè)務(wù)和應(yīng)用飛速發(fā)展，尤其是視頻點(diǎn)播服務(wù)成為主流，網(wǎng)絡(luò)中的視頻數(shù)據(jù)規(guī)模急劇膨脹[1]。2017 年全球視頻流量占互聯(lián)網(wǎng)總流量的75%，到2022 年預(yù)計(jì)達(dá)到82%[2]。以視頻平臺(tái)YouTube 為例，其擁有超過10 億用戶，占互聯(lián)網(wǎng)總?cè)藬?shù)的近三分之一，視頻觀看總次數(shù)中有超一半來自移動(dòng)設(shè)備。可以預(yù)見的是，對(duì)于移動(dòng)網(wǎng)絡(luò)運(yùn)營商（MNO，mobile network operator）而言，亟需解決在有限的移動(dòng)網(wǎng)絡(luò)帶寬上承載大量視頻數(shù)據(jù)的挑戰(zhàn)。除了加大網(wǎng)絡(luò)基礎(chǔ)設(shè)施的投入外，要提高網(wǎng)絡(luò)的利用率，使硬件資源得到充分利用，就需要了解用戶的視頻體驗(yàn)質(zhì)量（QoE，quality of experience），通過準(zhǔn)確地監(jiān)測(cè)和評(píng)估用戶視頻QoE，動(dòng)態(tài)地調(diào)整網(wǎng)絡(luò)資源和相關(guān)參數(shù)，提高移動(dòng)網(wǎng)絡(luò)的綜合利用率。

研究表明，與用戶視頻QoE 關(guān)系最密切的是觀看視頻過程中出現(xiàn)的緩沖次數(shù)和緩沖總時(shí)長(zhǎng)。文獻(xiàn)[3-5]對(duì)YouTube 底層數(shù)據(jù)傳輸特征、應(yīng)用層播放狀態(tài)和用戶的QoE 體驗(yàn)做了深入分析研究，發(fā)現(xiàn)視頻的播放狀態(tài)（播放、緩沖等）與緩沖區(qū)狀態(tài)密切相關(guān)，兩者的關(guān)系如圖1 所示。

圖1 視頻播放狀態(tài)與緩沖區(qū)對(duì)應(yīng)關(guān)系

1)a點(diǎn)前，緩沖區(qū)內(nèi)視頻可播放時(shí)長(zhǎng)小于Θ1，視頻處于緩沖狀態(tài)，緩沖區(qū)內(nèi)數(shù)據(jù)只增加不消耗。

2)a到b點(diǎn)，緩沖區(qū)內(nèi)視頻可播放時(shí)長(zhǎng)大于Θ1，視頻處于播放狀態(tài)，緩沖區(qū)內(nèi)數(shù)據(jù)增加大于消耗。

3)緩沖區(qū)內(nèi)數(shù)據(jù)不會(huì)無限制增加，b到d點(diǎn)，緩沖區(qū)內(nèi)視頻可播放時(shí)長(zhǎng)維持在Θ2上下。

4)外部原因?qū)е戮彌_區(qū)內(nèi)數(shù)據(jù)被耗盡，e到f點(diǎn)，視頻再次緩沖，緩沖區(qū)需重新緩存至Θ1。

綜上，視頻發(fā)生緩沖與否由緩沖區(qū)的狀態(tài)決定，而下載速率、碼率等相關(guān)參數(shù)只能預(yù)測(cè)發(fā)生緩沖的趨勢(shì)，并不是決定性因素[6]。Θ1的值即代表初始緩沖隊(duì)列長(zhǎng)度，可以看出，初始緩沖隊(duì)列的存在是導(dǎo)致視頻緩沖的根本原因，利用其準(zhǔn)確值可以測(cè)量視頻緩沖的發(fā)生和總時(shí)長(zhǎng)，對(duì)于MNO 評(píng)估用戶視頻QoE 有重要價(jià)值。

目前，優(yōu)酷、愛奇藝、騰訊視頻等國內(nèi)主流視頻平臺(tái)在移動(dòng)端還未采用加密協(xié)議傳輸數(shù)據(jù)，而YouTube、Netflix 等國外主流視頻平臺(tái)已全面采用加密協(xié)議承載數(shù)據(jù)。本文面向移動(dòng)網(wǎng)絡(luò)，研究了非加密視頻平臺(tái)優(yōu)酷和加密視頻平臺(tái)YouTube 的初始緩沖隊(duì)列長(zhǎng)度測(cè)量方法，給出了相關(guān)實(shí)驗(yàn)方案和測(cè)量結(jié)果。對(duì)于非加密的優(yōu)酷平臺(tái)，建立視頻指紋庫，分析視頻流與播放狀態(tài)的關(guān)聯(lián)關(guān)系，通過控制視頻終端接收的視頻數(shù)據(jù)量，實(shí)現(xiàn)精確測(cè)量初始緩沖隊(duì)列長(zhǎng)度值。對(duì)于加密的YouTube 平臺(tái)，首先關(guān)聯(lián)加密視頻流與播放狀態(tài)的對(duì)應(yīng)關(guān)系，建立流量行為模型；其次構(gòu)建加密視頻指紋庫，支撐加密數(shù)據(jù)的解析；再次分析誤差，排除干擾，設(shè)計(jì)實(shí)驗(yàn)環(huán)境；最后基于上述支撐，測(cè)量計(jì)算初始緩沖隊(duì)列長(zhǎng)度值。實(shí)驗(yàn)結(jié)果表明，2 個(gè)平臺(tái)的測(cè)量結(jié)果均能精確到幀，完全滿足MNO 評(píng)估用戶視頻QoE 的需要。

本文的主要貢獻(xiàn)有以下三點(diǎn)。

1)針對(duì)非加密和加密兩類視頻平臺(tái)的初始緩沖隊(duì)列長(zhǎng)度展開研究，測(cè)量結(jié)果精確到幀，測(cè)量方法可推廣或借鑒至其他視頻平臺(tái)。

2)基于數(shù)據(jù)層面流量特征與應(yīng)用層面播放狀態(tài)的關(guān)聯(lián)關(guān)系，建立流量行為模型，打通了下層數(shù)據(jù)傳輸與上層用戶感知。

3)針對(duì)加密視頻數(shù)據(jù)的分析，利用中間人技術(shù)，設(shè)計(jì)了新的加密視頻指紋庫構(gòu)建方案，改進(jìn)了傳統(tǒng)指紋庫存在的缺陷。

2 相關(guān)研究

視頻業(yè)務(wù)的飛速發(fā)展，推動(dòng)了視頻數(shù)據(jù)傳輸機(jī)制和視頻QoE 評(píng)估的相關(guān)研究。Ho?feld 等[7-9]提出，目前視頻平臺(tái)在傳輸層采用可靠的TCP 協(xié)議，用戶不會(huì)觀察到視頻圖像的失真，與文獻(xiàn)[3-4]的結(jié)論一致，認(rèn)為用戶的視頻QoE 主要與觀看視頻時(shí)產(chǎn)生的緩沖有關(guān)，其中，緩沖又分為視頻開始播放之前的初始緩沖和視頻播放過程中的卡頓緩沖。為了量化用戶的視頻觀看體驗(yàn)，華為公司聯(lián)合牛津大學(xué)建立了一個(gè)用戶視頻觀看體驗(yàn)的量化模型vMOS（video mean opinion score）[10]，模型模仿語音業(yè)務(wù)，利用MOS 量化語音質(zhì)量[11]的思想，根據(jù)在線視頻初始緩沖時(shí)延（sStartDelay）、視頻源質(zhì)量（sQuailty）、視頻卡頓因素（sStalling）等客觀因素來量化用戶觀看視頻的體驗(yàn)。綜合已有研究可以發(fā)現(xiàn)，緩沖決定了用戶視頻QoE，造成緩沖的初始緩沖隊(duì)列長(zhǎng)度是視頻QoE 評(píng)估的重要參數(shù)。

目前還沒有針對(duì)國內(nèi)視頻平臺(tái)初始緩沖隊(duì)列長(zhǎng)度的相關(guān)研究，國外視頻平臺(tái)的相關(guān)研究主要聚焦在YouTube 上。文獻(xiàn)[3]給出了初始緩沖隊(duì)列長(zhǎng)度的定義，并利用初始緩沖隊(duì)列長(zhǎng)度描述了YouTube 的流量模型。但是文獻(xiàn)[3]的模型中并未給出測(cè)量方法，而是直接采用了Ameigeiras 等[12]和Schatz 等[13]的研究結(jié)果，他們給出的初始緩沖數(shù)據(jù)可播放時(shí)長(zhǎng)分別為2.2 s 和1.9 s。Ameigeiras 等[12]利用接收速率、視頻碼率、帶寬等參數(shù)估算初始緩沖數(shù)據(jù)時(shí)長(zhǎng)，Schatz 等[13]則利用的數(shù)據(jù)分組的時(shí)間特征，如分組到達(dá)時(shí)間、分組間隔時(shí)長(zhǎng)等參數(shù)來估算。但這2 個(gè)研究結(jié)果是在YouTube 未采用加密協(xié)議，且應(yīng)用層采用漸進(jìn)式視頻下載技術(shù)（HPD，HTTP progressive download）時(shí)得到的，而當(dāng)前YouTube 已全面采用加密協(xié)議承載數(shù)據(jù)，在應(yīng)用層已棄用 HPD，改用 DASH（dynamic adaptive streaming over HTTP）視頻傳輸技術(shù)，兩者在傳輸機(jī)制和流量特征上有很大區(qū)別。

Burger 等[14]基于離散時(shí)間分析對(duì)視頻緩沖區(qū)狀態(tài)進(jìn)行建模，利用視頻的分片到達(dá)時(shí)間、分片傳輸時(shí)長(zhǎng)、分片平均下載速率、分片平均碼率等分片在傳輸層面的參數(shù)，計(jì)算出描述緩沖區(qū)模型的3 個(gè)關(guān)鍵閾值：初始緩沖閾值（initial buffering threshold）、暫停緩沖閾值（pause buffering threshold）和繼續(xù)緩沖閾值（continue buffering threshold）。其中初始緩沖閾值的結(jié)果約為0 s。Burger 等[14]的研究重點(diǎn)是描述視頻平臺(tái)流量模型，并未關(guān)聯(lián)播放狀態(tài)，實(shí)驗(yàn)中的網(wǎng)絡(luò)狀況相對(duì)較好，只有初始緩沖，且緩沖時(shí)延很短，因此0 s 的初始緩沖閾值對(duì)文獻(xiàn)[14]中QoE 評(píng)估的準(zhǔn)確性影響有限。但當(dāng)網(wǎng)絡(luò)狀況較差時(shí)，初始緩沖的時(shí)延相當(dāng)明顯，0 s 顯然不能再用來描述初始緩沖隊(duì)列的長(zhǎng)度。Krishnamoorthi 等[15]設(shè)計(jì)了測(cè)量檢測(cè)系統(tǒng)BUFFEST，可以從HTTP 和HTTPS 的流量中識(shí)別出視頻流量，并評(píng)估當(dāng)前的緩沖區(qū)狀態(tài)，BUFFEST 利用的是TCP 和IP 層分組的相關(guān)特征，如到達(dá)時(shí)間、分組大小、分組間隔時(shí)長(zhǎng)等參數(shù)。與Krishnamoorthi 等[15]的研究類似的有Tsilimantos 等[16]的研究，僅通過IP 層視頻分組的相關(guān)特征值，利用機(jī)器學(xué)習(xí)方法訓(xùn)練模型，實(shí)時(shí)地分析檢測(cè)緩沖區(qū)的狀態(tài)。但是，Krishnamoorthi 等[15]和Tsilimantos 等[16]的研究也都沒有實(shí)現(xiàn)對(duì)初始緩沖隊(duì)列的精確測(cè)量。

綜合已有關(guān)于視頻初始緩沖隊(duì)列長(zhǎng)度的研究，發(fā)現(xiàn)主要是利用的網(wǎng)絡(luò)側(cè)分組數(shù)據(jù)的特征參數(shù)，來測(cè)量評(píng)估緩沖區(qū)的大小，進(jìn)而估算初始緩沖隊(duì)列的大小。同時(shí)，已有的估算值大多精確到秒，而視頻數(shù)據(jù)的基本單位為幀，視頻緩沖區(qū)實(shí)際排列的是解碼后的原始視頻幀隊(duì)列，因此能夠精確描述初始緩沖隊(duì)列長(zhǎng)度的單位是視頻幀個(gè)數(shù)，而非可播放幾秒鐘的時(shí)長(zhǎng)。本文針對(duì)非加密優(yōu)酷和加密YouTube 這2 個(gè)視頻平臺(tái)的初始緩沖隊(duì)列長(zhǎng)度展開研究，精確測(cè)量隊(duì)列長(zhǎng)度值，測(cè)量結(jié)果精確到幀。

3 非加密平臺(tái)優(yōu)酷的測(cè)量方法

對(duì)于采用非加密協(xié)議傳輸視頻的平臺(tái)，研究初始緩沖隊(duì)列長(zhǎng)度先要確定滿足播放所需的最小視頻數(shù)據(jù)量，由于數(shù)據(jù)未加密，容易算出數(shù)據(jù)量對(duì)應(yīng)的幀數(shù)。本節(jié)基于優(yōu)酷視頻傳輸機(jī)制和數(shù)據(jù)特征的研究分析，建立優(yōu)酷視頻幀偏移信息指紋庫；通過控制優(yōu)酷終端應(yīng)用接收的視頻數(shù)據(jù)量，建立視頻流量與播放行為的關(guān)聯(lián)關(guān)系，分析計(jì)算優(yōu)酷終端的初始緩沖隊(duì)列長(zhǎng)度值。

3.1 非加密平臺(tái)測(cè)量方法總體思路

優(yōu)酷移動(dòng)端平臺(tái)采用非加密協(xié)議傳輸視頻數(shù)據(jù)，因此通過采集分析中間端數(shù)據(jù)，可以實(shí)時(shí)計(jì)算當(dāng)前終端應(yīng)用已經(jīng)接收到視頻數(shù)據(jù)量。反之，在中間端通過阻斷視頻數(shù)據(jù)的傳輸，可以定量控制終端應(yīng)用接收到的視頻數(shù)據(jù)量。

優(yōu)酷視頻的MP4 文件格式如圖2 所示，解析MP4 文件可以定位“stco”結(jié)構(gòu)體，其中描述了視頻每一幀相對(duì)于視頻文件頭的偏移信息，以此建立優(yōu)酷視頻的視頻幀偏移信息指紋庫。理論上，逐幀控制優(yōu)酷終端應(yīng)用接收的視頻數(shù)據(jù)量，可以找到恰好滿足播放條件的幀數(shù)，此值即為優(yōu)酷移動(dòng)終端的初始緩沖隊(duì)列長(zhǎng)度。

3.2 非加密平臺(tái)測(cè)量方法實(shí)施步驟

步驟1建立視頻的幀偏移信息指紋庫

確定實(shí)驗(yàn)視頻集，預(yù)先抓取對(duì)應(yīng)分辨率的完整視頻，利用算法1 解析每個(gè)優(yōu)酷視頻MP4 文件，建立幀偏移信息指紋庫。

算法1優(yōu)酷視頻的幀偏移信息指紋庫建立算法

輸入優(yōu)酷視頻MP4 文件file

輸出優(yōu)酷視頻幀偏移信息指紋庫

圖2 優(yōu)酷視頻MP4 文件格式

步驟2中間端視頻數(shù)據(jù)控制

移動(dòng)終端連接PC 共享的Wi-Fi，PC 作為中間端，部署基于winpcap 開發(fā)的優(yōu)酷視頻流測(cè)量程序。根據(jù)算法2，中間端程序?qū)崟r(shí)分析數(shù)據(jù)分組，若有優(yōu)酷視頻請(qǐng)求，就跟蹤該請(qǐng)求的TCP 流，當(dāng)此流的視頻響應(yīng)數(shù)據(jù)總量大于預(yù)先設(shè)定的斷網(wǎng)條件，就在程序中調(diào)用程序斷網(wǎng)模塊，切斷Wi-Fi。此時(shí)，移動(dòng)終端優(yōu)酷應(yīng)用接收到的視頻數(shù)據(jù)量約等于預(yù)先設(shè)定的斷網(wǎng)條件，若大于初始緩沖隊(duì)列長(zhǎng)度，終端優(yōu)酷視頻可以播放；若小于初始緩沖隊(duì)列長(zhǎng)度，終端優(yōu)酷視頻無法播放。

算法2控制終端接收定量視頻數(shù)據(jù)算法

輸入斷網(wǎng)條件condition

輸出終端優(yōu)酷視頻播放狀態(tài)，“1”表示播放，“0”表示未播放

1)實(shí)時(shí)監(jiān)聽網(wǎng)絡(luò)，利用winpcap 接口讀取分組packet

2)判斷packet 是否是優(yōu)酷視頻請(qǐng)求分組

3)記錄終端優(yōu)酷視頻是否播放，“1”表示播放，“0”未播放

4)數(shù)據(jù)綜合分析

每次測(cè)量過程中，在移動(dòng)終端側(cè)使用tcpdump采集pcap 數(shù)據(jù)分組，用來確定終端優(yōu)酷應(yīng)用實(shí)際接收到的數(shù)據(jù)量，配合幀偏移信息指紋庫可以確定該數(shù)據(jù)量對(duì)應(yīng)的幀數(shù)和可播放時(shí)長(zhǎng)。若當(dāng)次測(cè)量?jī)?yōu)酷視頻可以播放，實(shí)際接收到的幀數(shù)大于或等于初始緩沖隊(duì)列長(zhǎng)度；若當(dāng)次測(cè)量?jī)?yōu)酷視頻無法播放，實(shí)際接收到的幀數(shù)小于初始緩沖隊(duì)列長(zhǎng)度。

3.3 非加密平臺(tái)測(cè)量方法誤差分析

實(shí)驗(yàn)發(fā)現(xiàn)中間端PC 的斷網(wǎng)模塊存在時(shí)延（約0.5 s），由于該時(shí)延無法克服，終端優(yōu)酷應(yīng)用實(shí)際接收到的視頻數(shù)據(jù)量一定會(huì)大于中間端的預(yù)設(shè)斷網(wǎng)條件。

為了盡量減小與預(yù)設(shè)值的偏差，需要對(duì)網(wǎng)絡(luò)進(jìn)行限速，使斷網(wǎng)時(shí)延階段終端接收到盡量少的分組，以減小偏差。同時(shí)限速要在一定范圍內(nèi)，因?yàn)橄匏龠^大，會(huì)導(dǎo)致分組丟失增加，造成無法準(zhǔn)確計(jì)算實(shí)際接收的視頻數(shù)據(jù)量。通過實(shí)驗(yàn)驗(yàn)證，200 KB/s的限速標(biāo)準(zhǔn)可以滿足測(cè)量需求，此時(shí)從調(diào)用斷網(wǎng)模塊到實(shí)際終端停止接收分組，優(yōu)酷終端應(yīng)用還會(huì)接收到約40～100 KB 的視頻數(shù)據(jù)。

4 加密平臺(tái)YouTube 的測(cè)量方法

YouTube 等視頻服務(wù)商為了保護(hù)用戶隱私和網(wǎng)絡(luò)安全，相繼采用加密協(xié)議傳輸視頻數(shù)據(jù)。加密協(xié)議導(dǎo)致基于DPI（deep packet inspection）的傳統(tǒng)方法已無法分析。本節(jié)首先介紹了移動(dòng)網(wǎng)絡(luò)下YouTube 傳輸機(jī)制，基于傳輸機(jī)制的分析，同時(shí)借鑒優(yōu)酷平臺(tái)的測(cè)量方法，給出了測(cè)量方法的總體思路，并詳細(xì)描述了測(cè)量方法的實(shí)施步驟，設(shè)計(jì)實(shí)驗(yàn)方案來精確測(cè)量YouTube 的初始緩沖隊(duì)列長(zhǎng)度值。

4.1 YouTube 傳輸機(jī)制和文件格式

優(yōu)酷的傳輸機(jī)制雖對(duì)視頻進(jìn)行了分片，但分片相對(duì)簡(jiǎn)單，按照固定大小將視頻文件剪裁成幾塊。而YouTube 采用DASH 協(xié)議傳輸視頻，同時(shí)又采用了加密協(xié)議，測(cè)量初始緩沖隊(duì)列長(zhǎng)度首先需要了解YouTube 的DASH 傳輸機(jī)制。

DASH 視頻傳輸流程如圖3 所示，首先在視頻服務(wù)器部署同一個(gè)視頻的不同分辨率視頻分片組及MPD（media presentation description）分片目錄文件。當(dāng)用戶點(diǎn)擊播放視頻后，首先請(qǐng)求下載MPD文件，YouTube 客戶端的MPD 解析模塊對(duì)MPD 文件進(jìn)行處理，獲取該視頻所有分辨率、碼率視頻資源的URL 信息，然后根據(jù)目前終端網(wǎng)絡(luò)狀況向視頻服務(wù)器請(qǐng)求特定分辨率、碼率的視頻片段。同時(shí)，視頻播放過程中，YouTube 客戶端可以根據(jù)自身網(wǎng)絡(luò)狀況切換請(qǐng)求不同分辨率、碼率的視頻分片，實(shí)現(xiàn)視頻的自適應(yīng)播放。

借鑒非加密平臺(tái)優(yōu)酷的初始緩沖隊(duì)列長(zhǎng)度測(cè)量方法，控制YouTube 終端僅接收到一個(gè)視頻分片后切斷終端的網(wǎng)絡(luò)，發(fā)現(xiàn)視頻都會(huì)正常播放，因此YouTube 的初始緩沖隊(duì)列長(zhǎng)度小于一個(gè)分片的時(shí)長(zhǎng)。目前，YouTube DASH 的分片時(shí)長(zhǎng)一般為5 s和10 s 這2 種規(guī)格。

圖3 DASH 視頻傳輸流程

圖4 YouTube 的2 種文件格式

YouTube 的音頻和視頻是分離的，音頻、視頻分片的文件格式主要有MP4 和WEBM 這2 種文件格式，如圖4 所示。解析MP4 文件中的“trun”結(jié)構(gòu)體，或者讀取WEBM 中每一個(gè)“SimpleBlock”的位置，可以計(jì)算出每一幀相對(duì)于分片文件頭的偏移。但是由于YouTube 采用加密協(xié)議，無法直接從加密流量中解析這2 種文件格式，后文介紹的構(gòu)建加密視頻指紋庫用以解決此問題。

4.2 加密平臺(tái)測(cè)量方法總體思路

優(yōu)酷初始緩沖隊(duì)列長(zhǎng)度的測(cè)量方法是通過控制終端應(yīng)用接收到的視頻數(shù)據(jù)量，建立播放行為與流量的對(duì)應(yīng)關(guān)系，是一種相對(duì)簡(jiǎn)單的流量行為模型。參考這一思路，針對(duì)采用加密協(xié)議傳輸視頻數(shù)據(jù)的YouTube 平臺(tái)，仍要首先建立YouTube 的加密流量行為模型，關(guān)聯(lián)分析加密流量與視頻播放狀態(tài)，從而在加密流量中識(shí)別出初始緩沖階段的視頻數(shù)據(jù)。進(jìn)一步分析，由于YouTube 采用了加密協(xié)議，識(shí)別出的初始緩沖數(shù)據(jù)仍無法直接計(jì)算出初始緩沖隊(duì)列長(zhǎng)度值，這一難點(diǎn)可以通過構(gòu)建加密視頻指紋庫的方法得以解決。在建立流量行為模型和構(gòu)建加密視頻指紋庫的基礎(chǔ)上，本文分析YouTube 傳輸機(jī)制和加密協(xié)議對(duì)測(cè)量過程可能造成的誤差，排除相關(guān)影響因素，設(shè)計(jì)合理的實(shí)驗(yàn)環(huán)境。最后，針對(duì)YouTube實(shí)驗(yàn)視頻集，利用實(shí)驗(yàn)環(huán)境采集數(shù)據(jù)，綜合分析計(jì)算初始緩沖隊(duì)列長(zhǎng)度值。算法3 給出了測(cè)量方法的總體思路和步驟，下一節(jié)將針對(duì)算法中每一步驟進(jìn)行詳細(xì)介紹。

算法3YouTube 初始緩沖隊(duì)列長(zhǎng)度測(cè)量算法

步驟1建立流量行為模型。分析YouTube 加密視頻流與播放狀態(tài)的關(guān)聯(lián)關(guān)系，從而從加密流中識(shí)別出初始緩沖數(shù)據(jù)。

步驟2構(gòu)建加密視頻指紋庫。改進(jìn)傳統(tǒng)指紋庫構(gòu)建方案，輔助加密視頻流數(shù)據(jù)的分析。

步驟3影響因素分析排除。分析測(cè)量誤差，排除干擾因素，設(shè)計(jì)實(shí)驗(yàn)環(huán)境。

步驟4綜合計(jì)算分析。利用前三步的流量行為模型、加密視頻指紋庫和實(shí)驗(yàn)環(huán)境，采集實(shí)驗(yàn)視頻集流量數(shù)據(jù)，分析計(jì)算初始緩沖隊(duì)列長(zhǎng)度值。

4.3 加密平臺(tái)測(cè)量方法實(shí)施步驟

1)建立流量行為模型

圖5 給出了視頻播放過程中的所有狀態(tài)，初始緩沖數(shù)據(jù)就是“初始緩沖”至“達(dá)到播放條件”這一階段接收到的視頻數(shù)據(jù)。

圖5 YouTube 視頻的播放狀態(tài)

識(shí)別初緩數(shù)據(jù)，需要建立視頻流與播放狀態(tài)的對(duì)應(yīng)關(guān)系，而YouTube 原生APP 無法實(shí)現(xiàn)這一目標(biāo)。解決方案是借助YouTube 官方提供的YouTube Android API 庫[18]，開發(fā)基于原生APP 之上的Android 應(yīng)用，該應(yīng)用可以依賴原生APP 播放YouTube 視頻。同時(shí)，開發(fā)庫提供onVideoStarted、onBuffering、onPlaying、onVideoEnded 這4 個(gè)回調(diào)函數(shù)，可以在終端獲取準(zhǔn)確的視頻播放狀態(tài)。

表1 列出了播放狀態(tài)與YouTube API 回調(diào)函數(shù)的對(duì)應(yīng)關(guān)系，onBuffering在初始緩沖階段會(huì)執(zhí)行2次，第二個(gè)onBuffering 時(shí)間點(diǎn)與onPlaying 時(shí)間點(diǎn)幾乎一致，2 個(gè)onBuffering 回調(diào)函數(shù)之間下載的視頻數(shù)據(jù)即為初始緩沖隊(duì)列長(zhǎng)度對(duì)應(yīng)的初緩數(shù)據(jù)。

表1 YouTube 播放狀態(tài)與API 回調(diào)函數(shù)關(guān)系

利用API 可以在終端得到準(zhǔn)確的播放狀態(tài)，下一步需要將播放狀態(tài)和加密的視頻流建立關(guān)聯(lián)。解決方案是在回調(diào)函數(shù)處主動(dòng)構(gòu)造狀態(tài)標(biāo)識(shí)分組，則視頻流中混入播放狀態(tài)的“時(shí)間點(diǎn)”。如圖6 所示，通過此對(duì)應(yīng)關(guān)系可以在加密的視頻流中剝離出緩沖階段的流量數(shù)據(jù)，使視頻流量與播放狀態(tài)建立關(guān)聯(lián)關(guān)系，構(gòu)建流量行為模型。

圖6 建立視頻流與播放狀態(tài)關(guān)聯(lián)的流量行為模型

2)構(gòu)建加密視頻指紋庫

建立流量行為模型，識(shí)別出初始緩沖數(shù)據(jù)之后，需要確定初始緩存數(shù)據(jù)對(duì)應(yīng)的幀數(shù)，但由于視頻加密，無法直接得到這一數(shù)據(jù)。為實(shí)現(xiàn)初始緩沖隊(duì)列長(zhǎng)度測(cè)量結(jié)果精確到幀的目標(biāo)，需要構(gòu)建包括視頻幀偏移信息庫在內(nèi)的一系列加密視頻指紋庫。

構(gòu)建指紋庫是分析加密流量數(shù)據(jù)的一般做法，傳統(tǒng)YouTube 加密視頻指紋庫構(gòu)建方法，是對(duì)熱點(diǎn)視頻在測(cè)試終端進(jìn)行點(diǎn)播，同時(shí)在網(wǎng)絡(luò)接入點(diǎn)采集數(shù)據(jù)流量。對(duì)視頻請(qǐng)求分組后服務(wù)器響應(yīng)的一簇密集響應(yīng)分組進(jìn)行累加，認(rèn)定此簇分組對(duì)應(yīng)一個(gè)視頻片段，由此構(gòu)建視頻的指紋庫。傳統(tǒng)方法主要存在以下3 個(gè)問題。

①DASH 傳輸機(jī)制中音頻、視頻分離在2 條流中，傳統(tǒng)方法忽視了數(shù)據(jù)量較小的音頻片段被累加所造成的誤差。

② YouTube 采用自適應(yīng)的傳輸機(jī)制，每次傳輸時(shí)分辨率隨網(wǎng)絡(luò)狀況改變而改變，傳統(tǒng)方法無法確定所采指紋對(duì)應(yīng)的視頻分辨率。

③僅對(duì)加密數(shù)據(jù)傳輸進(jìn)行統(tǒng)計(jì)，實(shí)際上獲得的只是當(dāng)次的傳輸指紋，并不一定能獲取視頻所有可能的指紋信息。

針對(duì)上述問題，本文提出的構(gòu)建加密視頻指紋庫改進(jìn)方案如圖7 所示，該方案在中間采集設(shè)備上使用中間人技術(shù)，獲得目標(biāo)視頻的明文數(shù)據(jù)，解析采集的明文數(shù)據(jù)文件，獲得視頻的基本信息指紋，并基于YouTube視頻分發(fā)機(jī)制和DASH傳輸機(jī)制進(jìn)行組合分析，進(jìn)一步獲得與傳輸狀態(tài)相關(guān)的視頻傳輸指紋，將這些指紋存入數(shù)據(jù)庫中。表2 給出了指紋庫中包含的各類信息庫及其說明。

圖7 構(gòu)建加密視頻指紋庫

表2 加密視頻指紋庫的組成及其說明

與傳統(tǒng)指紋庫構(gòu)建方案相比，本文提出的方案主要有以下3 個(gè)改進(jìn)。

①改進(jìn)方案基于中間人技術(shù)，解析所有分辨率下的明文數(shù)據(jù)，讀取各種碼率的音頻、視頻分片信息，避免了傳統(tǒng)方法無法區(qū)分音頻、視頻分片的問題。

② 從明文中讀取分片的長(zhǎng)度等信息碼，構(gòu)成了加密視頻的基本信息指紋?；趥鬏敊C(jī)制，對(duì)基本信息指紋進(jìn)一步分析，計(jì)算出在不同的網(wǎng)絡(luò)條件下所有音、視頻可能的傳輸組合，獲得視頻在不同的網(wǎng)絡(luò)服務(wù)質(zhì)量下所有可能的傳輸指紋。

③視頻指紋是從中間人設(shè)備采集的明文數(shù)據(jù)中獲得，與具體的傳輸環(huán)境無關(guān)，因此可以應(yīng)用于網(wǎng)絡(luò)性能不斷變化的真實(shí)網(wǎng)絡(luò)，具有較好的適用性。

3)影響因素分析排除

YouTube 在傳輸層之上采用了TLS 加密協(xié)議，TLS 協(xié)議會(huì)對(duì)應(yīng)用層視頻數(shù)據(jù)進(jìn)行分塊，一個(gè)數(shù)據(jù)塊大小一般為16 KB。在終端為了解密和驗(yàn)證每一個(gè)TLS 數(shù)據(jù)塊，必須保證16 KB 加密數(shù)據(jù)都已被完整接收。

圖8 給出不限速下YouTube 視頻數(shù)據(jù)到達(dá)終端的示意圖，圖中長(zhǎng)方塊表示一個(gè)16 KB 的TLS 塊。由于一般視頻幀的大小不會(huì)大于16 KB，故初始緩沖隊(duì)列長(zhǎng)度對(duì)應(yīng)的視頻幀大概率位于TLS 塊的內(nèi)部，第四個(gè)16 KB TLS塊中的黑色小方塊給出示意。在t1時(shí)間點(diǎn)時(shí)，對(duì)接收到的數(shù)據(jù)而言，已經(jīng)達(dá)到了播放條件，但由于上層應(yīng)用需要經(jīng)歷解協(xié)議、解封裝、解碼、判斷當(dāng)前緩沖隊(duì)列長(zhǎng)度等一系列過程，到視頻真正開始播放已經(jīng)在t1之后的t2時(shí)間點(diǎn)（t2時(shí)間點(diǎn)對(duì)應(yīng)YouTube API 回調(diào)函數(shù)中的onPlaying）。圖8 中，t1至t2時(shí)間段內(nèi)，又接收到第五個(gè)完整16 KB的TLS 塊。測(cè)量中會(huì)判定onPlaying 前的完整TLS塊均為初緩數(shù)據(jù)，因此第五塊會(huì)被當(dāng)作初始緩沖的數(shù)據(jù)，在計(jì)算初始緩沖隊(duì)列長(zhǎng)度時(shí)造成誤差。

圖8 不限速下接收到TLS 塊示意

圖9 是限速后的YouTube 視頻數(shù)據(jù)到達(dá)終端的示意圖，此時(shí)TLS 塊之間的時(shí)間間隔被拉長(zhǎng)，其中，時(shí)間點(diǎn)達(dá)到了播放條件，同樣是經(jīng)過一系列的過程，到時(shí)間點(diǎn)開始播放（時(shí)間點(diǎn)也對(duì)應(yīng)YouTube API 回調(diào)函數(shù)中的onPlaying）。至?xí)r間點(diǎn)第五個(gè)TLS 塊仍未接收完整，不會(huì)被算作初始緩沖的數(shù)據(jù)。此時(shí)初緩隊(duì)列長(zhǎng)度就是由初始緩沖隊(duì)列長(zhǎng)度對(duì)應(yīng)的視頻幀（第四個(gè)TLS 塊中的黑色小方塊給出示意）所在TLS 塊算出，誤差得以排除。

圖9 限速下接收到TLS 塊示意

綜上，為了保證初始緩沖隊(duì)列長(zhǎng)度測(cè)量結(jié)果的準(zhǔn)確性，需要對(duì)實(shí)驗(yàn)環(huán)境進(jìn)行設(shè)計(jì)，排除由于終端播放器正式播放時(shí)間點(diǎn)滯后于真實(shí)達(dá)到播放條件的時(shí)間點(diǎn)，導(dǎo)致會(huì)將多余的完整TLS 塊被誤判成初緩數(shù)據(jù)帶來的誤差。因此，在采集加密視頻流的實(shí)驗(yàn)環(huán)境中設(shè)計(jì)了限速模塊，限速的標(biāo)準(zhǔn)是既要保證視頻不會(huì)因?yàn)閹捥投鵁o法播放，也要保證排除“多余”TLS 完整塊的干擾。實(shí)驗(yàn)結(jié)果表明，限速為1 Mbit/s，可以滿足上述2 個(gè)要求。

4)綜合計(jì)算分析

至此已經(jīng)確定出初緩數(shù)據(jù)，并能夠確定初緩隊(duì)列長(zhǎng)度對(duì)應(yīng)的視頻幀所在的TLS 塊，但仍無法給出這一視頻幀的具體位置。如圖10 所示，虛線框出的視頻幀即為初始緩沖隊(duì)列長(zhǎng)度的準(zhǔn)確值。

圖10 初始緩沖隊(duì)列長(zhǎng)度值所在區(qū)間

對(duì)于一個(gè)視頻而言，無法直接確定初始緩沖隊(duì)列長(zhǎng)度具體對(duì)應(yīng)哪一幀，但如圖10 所示，可以參照指紋庫中的幀偏移信息，確定min 和max 的具體值，則初始緩沖隊(duì)列長(zhǎng)度位于[min,max]區(qū)間內(nèi)部。

對(duì)于實(shí)驗(yàn)視頻集而言，每一個(gè)視頻都可以計(jì)算出一個(gè)初始緩沖隊(duì)列長(zhǎng)度所在的區(qū)間，如圖11 所示，對(duì)所有視頻計(jì)算出的區(qū)間取交集，且滿足結(jié)果為整數(shù)的條件，即可得到一個(gè)精確到視頻幀的初始緩沖隊(duì)列長(zhǎng)度值，具體步驟如算法4 所示。

圖11 取交集計(jì)算初始緩沖隊(duì)列長(zhǎng)度值示意

算法4實(shí)驗(yàn)視頻集處理方法

輸入實(shí)驗(yàn)視頻集{Vi|i=1,…,N}

輸出初始緩沖隊(duì)列長(zhǎng)度L取值區(qū)間，L∈[min,max]，且L為整數(shù)

①取實(shí)驗(yàn)視頻集中一個(gè)視頻Vi。

② 限速1 Mbit/s 采集實(shí)驗(yàn)數(shù)據(jù)，計(jì)算onPlaying前完整TLS 塊數(shù)Bi。

③查幀偏移信息庫，計(jì)算16(Bi-1)KB 和16BiKB 對(duì)應(yīng)幀數(shù)mini和maxi，以及Vi幀率。

④ 對(duì)所有視頻重復(fù)①到③，得到N個(gè)區(qū)間[mini,maxi]，i=1,…,N。

⑤ 相同幀率視頻的[mini,maxi]區(qū)間取交集，得到[min,max]。

5 實(shí)驗(yàn)分析

5.1 實(shí)驗(yàn)環(huán)境

實(shí)驗(yàn)共使用了4 部測(cè)試手機(jī)，測(cè)試手機(jī)的參數(shù)信息如表3 所示。

表3 測(cè)試手機(jī)參數(shù)信息

為滿足YouTube 加密視頻平臺(tái)的分析，全部測(cè)試手機(jī)均安裝了基于Android YouTube API 開發(fā)的應(yīng)用，應(yīng)用中集成了tcpdump 分組抓取模塊，可以在YouTube 視頻播放過程中自動(dòng)抓取流量數(shù)據(jù)。

圖12 給出了非加密優(yōu)酷平臺(tái)的實(shí)驗(yàn)數(shù)據(jù)采集環(huán)境，手機(jī)終端連接中間端PC 共享的Wi-Fi，中間端PC 開發(fā)部署優(yōu)酷視頻流測(cè)量程序。

圖12 優(yōu)酷平臺(tái)實(shí)驗(yàn)數(shù)據(jù)采集環(huán)境

YouTube 視頻流量數(shù)據(jù)采集自蜂窩網(wǎng)絡(luò)（3G/4G）和Wi-Fi 這2 種網(wǎng)絡(luò)環(huán)境，采集環(huán)境如圖13 所示。

5.2 數(shù)據(jù)采集

1)優(yōu)酷平臺(tái)數(shù)據(jù)采集

確定優(yōu)酷實(shí)驗(yàn)視頻集，選擇起始畫面變化相對(duì)劇烈的視頻，保證每一幀的數(shù)據(jù)量較大，使數(shù)據(jù)傳輸時(shí)，一幀需要多個(gè)分組，可以減小測(cè)量誤差。同時(shí)覆蓋優(yōu)酷視頻目前主流幀率：15 幀/秒、23 幀/秒和25 幀/秒。最終一共確定10 個(gè)測(cè)試視頻。實(shí)驗(yàn)前后共采集了10 組數(shù)據(jù)，每組數(shù)據(jù)約50 例。

圖13 YouTube 平臺(tái)實(shí)驗(yàn)數(shù)據(jù)采集環(huán)境

2)YouTube 平臺(tái)數(shù)據(jù)采集

確定YouTube 實(shí)驗(yàn)視頻集，選取標(biāo)準(zhǔn)有3 個(gè)條件：①覆蓋0～2 min、2～5 min 和大于5 min 這3 種時(shí)長(zhǎng)要求；② 視頻的開始幾秒鐘畫面變化比較劇烈，目的是使起始階段視頻幀的平均大小不至于太小，導(dǎo)致每個(gè)16 KB 的TLS 塊可能包含大量的幀，增大偏差；③覆蓋了目前YouTube 上最普遍的幀率，如4 幀/秒、25 幀/秒和30 幀/秒等。最終確定了61 個(gè)測(cè)試視頻。

實(shí)驗(yàn)前后共采集了4 批數(shù)據(jù)，具體的采集時(shí)間等信息如表4 所示。

表4 YouTube 數(shù)據(jù)采集信息

5.3 優(yōu)酷實(shí)驗(yàn)結(jié)果分析

表5 給出了10 組實(shí)驗(yàn)數(shù)據(jù)其中一組的部分結(jié)果，此視頻的幀率為23 幀/秒。

表5 優(yōu)酷一組實(shí)驗(yàn)數(shù)據(jù)的部分結(jié)果

表5 的“是否播放”列中，“1”代表此次實(shí)驗(yàn)優(yōu)酷終端應(yīng)用最終能夠播放，表明接收到的視頻數(shù)據(jù)量滿足了播放條件，即實(shí)際接收的幀數(shù)≥初始緩沖隊(duì)列長(zhǎng)度；“0”代表此次實(shí)驗(yàn)優(yōu)酷終端應(yīng)用未播放，即實(shí)際接收的幀數(shù)＜初始緩沖隊(duì)列長(zhǎng)度。

圖14 給出了表5 對(duì)應(yīng)數(shù)據(jù)所有結(jié)果的匯總。當(dāng)實(shí)際接收到幀數(shù)≥234 時(shí)，此次測(cè)量能夠播放；當(dāng)實(shí)際接收到幀數(shù)＜233 時(shí)，此次測(cè)量未播放。故此組實(shí)驗(yàn)結(jié)果表明，對(duì)于23 幀/秒的視頻而言，初始緩沖隊(duì)列長(zhǎng)度位于區(qū)間[233,234]內(nèi)。

圖14 幀率為23 幀/秒優(yōu)酷視頻的一組實(shí)驗(yàn)結(jié)果

綜合所有10 組實(shí)驗(yàn)數(shù)據(jù)，其結(jié)果如表6 所示，3 種幀率下初始緩沖隊(duì)列長(zhǎng)度值不同，但是換算成時(shí)長(zhǎng)，均略大于10 s。

表6 優(yōu)酷平臺(tái)初緩隊(duì)列長(zhǎng)度測(cè)量結(jié)果

由于實(shí)驗(yàn)本身無法克服的誤差（斷網(wǎng)時(shí)延），無法精確控制終端應(yīng)用實(shí)際接收到的幀數(shù)，因此15 幀/秒幀率下沒有得到實(shí)際接收155 個(gè)或156 個(gè)視頻幀的情況，23 幀/秒幀率下沒有得到實(shí)際接收233 個(gè)視頻幀的情況，所以這2 種幀率下初始緩沖隊(duì)列長(zhǎng)度無法精確到具體的幀數(shù)。

5.4 YouTube 實(shí)驗(yàn)結(jié)果分析

如表7 所示，給出了YouTube 實(shí)驗(yàn)視頻集中的部分結(jié)果，表中所有數(shù)值均為視頻幀的個(gè)數(shù)。

實(shí)驗(yàn)視頻集中所有24 幀/秒視頻的測(cè)量結(jié)果如圖15 所示，可以看出，所有結(jié)果的區(qū)間存在重合，重合區(qū)域?yàn)閇60,61]。

表7 部分YouTube 視頻的計(jì)算結(jié)果

圖15 24 幀/秒視頻集測(cè)量結(jié)果

統(tǒng)計(jì)所有幀率的視頻，24 幀/秒視頻的初始緩沖隊(duì)列長(zhǎng)度區(qū)間為[60,61]，換算成時(shí)長(zhǎng)為[2.5,2.542]；25 幀/秒的區(qū)間為[62,63]，換算成時(shí)長(zhǎng)為[2.48,2.52]；30 幀/秒的區(qū)間為[75,76]，換算成時(shí)長(zhǎng)為[2.5,2.533]。因此，可以認(rèn)定YouTube 的初始緩沖隊(duì)列長(zhǎng)度以時(shí)長(zhǎng)來描述應(yīng)為2.5 s。

進(jìn)一步分析實(shí)驗(yàn)結(jié)果，初始緩沖隊(duì)列長(zhǎng)度在YouTube 內(nèi)部并不是一個(gè)不變的值，對(duì)于不同幀率的視頻，有一個(gè)不同的滿足播放條件所需的幀數(shù)。

1)對(duì)于24 幀/秒的視頻而言，當(dāng)已緩沖幀數(shù)≥60 即滿足播放條件。

2)對(duì)于25 幀/秒的視頻而言，當(dāng)已緩沖幀數(shù)≥63 即滿足播放條件。

3)對(duì)于30 幀/秒的視頻而言，當(dāng)已緩沖幀數(shù)≥75 即滿足播放條件。

在計(jì)算初始緩沖隊(duì)列長(zhǎng)度時(shí)，進(jìn)行了限速的處理，為了排除限速可能影響初始緩沖隊(duì)列長(zhǎng)度本身，又做了2 組對(duì)照試驗(yàn)，實(shí)驗(yàn)結(jié)果匯總?cè)鐖D16所示。圖16 中的○為圖8 中t1～t2的時(shí)間間隔，△為圖9 中t′1～t′2的時(shí)間間隔。t1～t2和t′1～t′2都是上層應(yīng)用經(jīng)歷的解協(xié)議、解封裝、解碼、判斷當(dāng)前緩沖隊(duì)列長(zhǎng)度等一系列過程的時(shí)長(zhǎng)，對(duì)于同一部硬件終端而言，這2 個(gè)時(shí)間間隔無論限速與否，應(yīng)大致相同。

圖16 不限速下t1～t2與限速下t′1～t′2對(duì)比

從圖16 的實(shí)驗(yàn)結(jié)果可以看出，t1～t2和t′1～t′2的時(shí)間間隔大致相同，可以論證限速并不會(huì)影響初緩隊(duì)列長(zhǎng)度的值，其值就是播放器內(nèi)部設(shè)置的一個(gè)確定閾值。

6 結(jié)束語

視頻終端初始緩沖隊(duì)列長(zhǎng)度是評(píng)估用戶視頻QoE 的重要參數(shù)，但現(xiàn)有關(guān)于隊(duì)列長(zhǎng)度的研究并未給出其準(zhǔn)確值。本文針對(duì)非加密優(yōu)酷和加密YouTube 這2 個(gè)視頻平臺(tái)，分別給出了面向移動(dòng)網(wǎng)絡(luò)的視頻初始緩沖隊(duì)列長(zhǎng)度的測(cè)量方法，以建立流量行為模型和輔助指紋庫為基礎(chǔ)，分析誤差，排除干擾因素，設(shè)計(jì)實(shí)驗(yàn)環(huán)境，采集特定網(wǎng)絡(luò)環(huán)境下實(shí)驗(yàn)視頻集的數(shù)據(jù)，分析計(jì)算初始緩沖隊(duì)列長(zhǎng)度，測(cè)量結(jié)果精確到視頻幀。

優(yōu)酷的測(cè)量方法核心思想是2 條：一是數(shù)據(jù)非加密，解構(gòu)視頻文件可確定每一幀的偏移；二是控制終端應(yīng)用接收到的視頻數(shù)據(jù)量，找到恰好達(dá)到播放條件的幀個(gè)數(shù)。這對(duì)于其他非加密平臺(tái)，如愛奇藝、騰訊視頻等同樣可以實(shí)現(xiàn)，因此優(yōu)酷平臺(tái)的測(cè)量方法對(duì)于其他非加密視頻平臺(tái)同樣適用。

YouTube 的測(cè)量方法關(guān)鍵步驟也是2 條：一是建立流量行為模型，識(shí)別初始緩沖數(shù)據(jù)；二是構(gòu)建加密視頻指紋庫，輔助加密數(shù)據(jù)分析。對(duì)于其他加密視頻平臺(tái)，加密視頻指紋庫構(gòu)建方案同樣適用；流量行為模型依賴于官方API 庫，目前top 級(jí)視頻平臺(tái)為擴(kuò)展平臺(tái)應(yīng)用，均會(huì)提供開發(fā)者API 接口。因此其他加密視頻平臺(tái)可依據(jù)自身開放接口情況，借鑒YouTube 的測(cè)量方法，實(shí)現(xiàn)初始緩沖隊(duì)列長(zhǎng)度的測(cè)量。

下一步的工作主要有兩部分：一是將兩類測(cè)量方法推廣至其他類似平臺(tái)，驗(yàn)證其通用性；二是結(jié)合視頻碼率識(shí)別技術(shù)，利用初始緩沖隊(duì)列長(zhǎng)度值計(jì)算初始時(shí)延和卡頓時(shí)延，完善視頻QoE 評(píng)估模型。