基于ATS的直播加速緩存系統(tǒng)設計

馬邦陽，魏偉剛，浦云明，尤志寧，王 巍，陳凱萌

(1.集美大學網(wǎng)絡中心，福建 廈門 361021;2.集美大學計算機工程學院，福建 廈門 361021)

0 引言

網(wǎng)絡上直播數(shù)據(jù)的請求和傳輸都要通過網(wǎng)絡直播服務器處理，當用戶過多，服務器即處于過載狀態(tài)，響應速度也會隨之下降，出現(xiàn)網(wǎng)絡延遲。王彥輝等[1]基于立方體網(wǎng)絡結構，進行了網(wǎng)絡傳輸延遲分析，認為網(wǎng)絡中存儲和轉發(fā)都要耗費一定的系統(tǒng)資源，因而信息傳輸節(jié)點數(shù)決定了通信效率的高低。越來越多研究關注用戶訪問和服務器的交互作用。李銳等[2]從負載均衡性方面出發(fā)，研究了分布式緩存副本策略，匹配服務器處理性能最大化利用緩存資源。張國強等[3]研究了ICN(信息中心網(wǎng)絡)緩存網(wǎng)絡中緩存大小規(guī)劃、應用無關的緩存空間共享機制、緩存決策策略、網(wǎng)絡內置緩存對象的可用性以及緩存網(wǎng)絡的理論模型和性能優(yōu)化方法等。蔡君等[4]研究了ICN全網(wǎng)內置緩存架構，為使被緩存的內容對象在空間和時間上分布更合理，提出了一種基于節(jié)點社團重要度的緩存策略(CSNIC)，保證了不同流行度內容對象在各社團內節(jié)點處的時間分布的合理性?，F(xiàn)有的相關研究工作，各類緩存策略都側重于提高系統(tǒng)整體性能，而在企業(yè)實際的應用中，為解決網(wǎng)絡中來回傳送數(shù)據(jù)的問題，一般使用緩存設備實現(xiàn)本地存儲，同時緩存設備與源服務器進行刷新檢驗，以保證存儲在緩存中數(shù)據(jù)的時效性。

ATS(apache traffic server)是模塊化的Http網(wǎng)絡代理緩存服務器。ATS緩存包括一個高速的對象數(shù)據(jù)庫，數(shù)據(jù)庫根據(jù)用戶請求的URL和請求頭部中相關的參數(shù)來組成對應的Key，用于索引對象[5]。李潤知等[8]研究了緩存的新鮮度及數(shù)據(jù)分片點擊率等指標，評估節(jié)點緩存空間利用率，提出了頻度限制的緩存替換算法。在新鮮度檢測中，如果內容新鮮，則ATS會向客戶端發(fā)送回復標頭；否則流量服務器將打開到源服務器的連接，請求內容并檢測資源新鮮度。如果資源新鮮，ATS將該對象發(fā)給用戶，如果資源不新鮮，則ATS緩存新鮮的對象并轉發(fā)給用戶。在任何階段出現(xiàn)錯誤，Http狀態(tài)機將跳轉到“Send Reply Header”狀態(tài)并發(fā)送回復，如果回復錯誤，則事務關閉。當客戶端向服務器請求一個資源時，當資源在其他網(wǎng)絡位置，服務器向客戶端打回一個重定向的回復，客戶端根據(jù)該回復去正確的URL獲取資源[9]。

ATS自身沒有直播代理的功能，因此，系統(tǒng)需要開發(fā)直播代理的插件。ATS插件開發(fā)是基于協(xié)程TSCont、鉤子Hook和事件池來實現(xiàn)的。本文采用基于ATS的網(wǎng)絡直播加速緩存系統(tǒng)設計，以期解決網(wǎng)絡直播的延時和卡頓問題，同時也減少網(wǎng)絡的負載。

1 系統(tǒng)模塊設計

1.1 系統(tǒng)模塊

在ATS緩存系統(tǒng)中，主要是設計事務處理模塊，圖1為系統(tǒng)獲取關鍵字流程，主要功能是調用Boost庫獲取關鍵字、檢索關鍵字、源站請求資源、給用戶發(fā)送資源等[10]。

1)獲取關鍵字：由于ATS中的資源都是以關鍵字唯一表示，而關鍵字又是從用戶的請求中獲取的，因此，處理模塊首先請求、獲取關鍵字。

2)檢索關鍵字：獲取關鍵字之后，對關鍵字進行檢索，查看該資源是否存在于本地，若存在，則給用戶發(fā)送該資源，如果不存在，則ATS將會去源站進行請求，先獲取該資源，再將該資源發(fā)送給用戶。

3)去源站請求資源：當用戶請求的資源本地不存在時，ATS將會去源站資源請求。

4)給用戶發(fā)送資源。

1.2 獲取關鍵字處理

獲取關鍵字是事務處理的第一步，為后續(xù)模塊處理做準備，主要是創(chuàng)建功能對象和回調函數(shù)，發(fā)送到ATS的請求事務一旦觸發(fā)就進入回調函數(shù)。功能入口代碼為：

if(GLB_CONFIG_MANAGER().get_global_block().pattern_store_switch)

//判斷過去關鍵字模塊功能是否開啟{

m_store_url_sp=hm_store_url::create(); //創(chuàng)建功能對象

m_store_contp=TSContCreate(hm_store_url::store_url_event_cb，0);

//創(chuàng)建回調函數(shù)store_url_event_cb

TSContDataSet(m_store_contp，m_store_url_sp.get());

TSHttpHookAdd(TS_HTTP_POST_REMAP_HOOK，m_store_contp);

//添加全局鉤子，觸發(fā)鉤子進入回調函數(shù)}

代碼中，GLB_CONFIG_MANAGER().get_global_block().pattern_store_switch的返回值為一個布爾值，它代表store_url功能的開關，1表示開，0表示關。store_url功能是提取關鍵字功能，用來表示和存儲資源。

URL關鍵字提取規(guī)則在配置文件中配置，URL的匹配和存儲都是以正則表達式來處理的。當ATS接收到請求時將會調用該功能，并將結果寫到日志文件storeurl.log中。日志字段包括：用戶請求時間、用戶所在的網(wǎng)絡IP地址、用戶請求的URL、提取的關鍵字。

1.3 檢索關鍵字處理

項目中創(chuàng)建一個Map 用來存放已存在于本地的資源，創(chuàng)建代碼為：

Typedef boost::unordered_map video_stream_hash_container;

video_stream_hash_container m_stream_grp;

檢索部分的代碼為：

int video_stream_manage::setup_request(main_state *ms， int &client_num){

simple_recursive_guard lock(m_stream_mutex); //程序加鎖

video_stream_hash_iterator iter=m_stream_grp.find(ms->store_key);

if(iter == m_stream_grp.end())

return CTS_HLRS_MISS; //資源不存在

else

return CTS_HLRS_HIT；//返回檢索結果hit，資源存在}

當用戶所請求的資源不存在于本地時，返回CTS_HLRS_MISS，否則返回CTS_HLRS_HIT，系統(tǒng)會自動統(tǒng)計請求一個資源的用戶數(shù)量。然后將其寫入日志文件videolive.log中，日志信息包括：用戶所在網(wǎng)絡IP、狀態(tài)碼、同時請求該資源的用戶數(shù)、用戶請求的原URL。狀態(tài)碼為HTTP_LIVE_HIT表示用戶請求的資源存在于本地，為HTTP_LIVE_MISS表示用戶請求的資源本地沒有，為HTTP_LIVE_FETCH表示ATS無法從源站獲取資源。

1.4 數(shù)據(jù)的回源處理

數(shù)據(jù)的回源指的是當ATS 接收到用戶的數(shù)據(jù)請求，本地又沒有該數(shù)據(jù)資源，此時ATS 需要到源站請求數(shù)據(jù)到本地。程序插件需構建請求頭部、創(chuàng)建與源站的連接、解析源站回復的數(shù)據(jù)。

1)構建請求頭部，請求頭部的構建主要有兩個方法：

①voidvideo_live_stream::init_fetch_request(main_state *ms)；

該方法的主要功能是初始化構造頭部過程中所需要用到的參數(shù)，如源站的Host和請求的URL。需要注意的是在該方法中獲取到了用戶的IP地址和端口號，并存放在m_client_addr成員內。

②voidvideo_live_stream::build_request_line(TSHttpTxn txnp，std::string &request_line)

該方法是創(chuàng)建對源站進行請求的Request，將所需要用到的參數(shù)、主機地址、資源的URL等盡心拼接。并將結果放入Request_Line。

2)創(chuàng)建與源站的連接，創(chuàng)建連接使用了ATS的API。

voidvideo_fetch_request::start_connect(const struct sockaddr *addr){

//創(chuàng)建用于處理數(shù)據(jù)傳輸?shù)幕卣{函數(shù)；

//建立讀區(qū)源站回復的數(shù)據(jù)通道；

//建立寫入連接的數(shù)據(jù)通道；}

通過該方法建立與源站的連接，M_Req_Reader存放著與源站建立連接的Request。將該Request寫入連接M_Http_Vc就可建立與源站的連接。

3)解析源站回復的數(shù)據(jù)，包括回復頭部信息的解析和內容解析。

int video_fetch_request::handle_vconn_read_ready();

1.5 給用戶發(fā)送資源處理

給用戶發(fā)送數(shù)據(jù)首先要建立連接，然后建立數(shù)據(jù)傳輸通道，最后發(fā)送數(shù)據(jù)。

1)連接的建立：通過ATS提供的API接口來建立與客戶端的連接。

voidvideo_live_session::start_connect(){

m_contp=TSContCreate(video_live_session::state_video_live_event，TSMutexCreate()); //封裝回調函數(shù)

TSContDataSet(m_contp，this); //設置回調函數(shù)的傳入數(shù)據(jù)

TSHttpTxnIntercept(m_contp，m_txnp); //接管事務}

TSHttpTxnIntercept函數(shù)的作用是ATS服務器接管事務，同時生成一個與客戶端的連接TSVConn。

2)創(chuàng)建數(shù)據(jù)傳輸通道。

int video_live_session::handle_accept_event(TSCont contp，TSEvent event，

void *edata){

//PluginVC

m_net_vc =(TSVConn)edata;

//edata是調用TSHttpTxnIntercept生成的連接，其類型是TSVConn

m_req_buffer=TSIOBufferCreate();

m_resp_buffer=TSIOBufferCreate();

m_resp_reader=TSIOBufferReaderAlloc(m_resp_buffer); //封裝緩存區(qū)

m_read_vio=TSVConnRead(m_net_vc，contp，m_req_buffer，INT64_MAX);

return 0;}

m_write_vio=TSVConnWrite(m_net_vc，m_contp，m_resp_reader，INT64_MAX);

上述代碼創(chuàng)建了數(shù)據(jù)傳輸通道M_Write_Vio，M_Resp_Reader 為封裝過后的數(shù)據(jù)緩存區(qū)。只要將數(shù)據(jù)寫入該緩存區(qū)就可以實現(xiàn)向用戶發(fā)送數(shù)據(jù)。

3)發(fā)送數(shù)據(jù)。

voidvideo_live_session::produce_output(const void *data，int64_t length)

2 實驗結果及分析

系統(tǒng)最低硬件環(huán)境：CPU 2.40GHz以上；RAM 4G以上；Disk空間512G以上。當服務用戶較多時，硬件要求也要隨之提高，否則服務器容易過載。管理員應監(jiān)控服務器的負荷情況，特別是直播高峰期時應做適當?shù)呢撦d均衡。軟件環(huán)境：CentOS 6.5、Python2.7、CURL開發(fā)工具、Tcpdump開發(fā)工具、Gcc、G++、Boost1.56開發(fā)工具。

本研究采集了基于ATS緩存系統(tǒng)的一天、一周和一月的流量數(shù)據(jù)，數(shù)據(jù)來源于上海移動某運營商的直播數(shù)據(jù)統(tǒng)計和回源情況，參見圖2～圖4?？梢钥闯鲋辈ゼ铀傩Ч^好，吐出流量減去回源流量等于本系統(tǒng)服務的流量，且吐出流量是回源流量的兩倍以上，高峰期可達到更高，如節(jié)假日、晚上21時至23時。從實驗測試數(shù)據(jù)看，ATS緩存服務達到了預期的設計要求。

3 結束語

系統(tǒng)在上海移動網(wǎng)進行了測試，數(shù)據(jù)分析表明，網(wǎng)絡直播緩存加速達到預期效果，解決了直播的延時和卡頓問題，同時也減少了網(wǎng)絡的負載。系統(tǒng)還需進一步的研究，主要包括：1)網(wǎng)絡數(shù)據(jù)塊的數(shù)據(jù)傳輸，實現(xiàn)*.ts和*.data等數(shù)據(jù)類型的直播；2)開發(fā)大文件的緩存、加速和反向代理服務等功能；3)熱點功能，當用戶過多時，如果服務器將每個用戶的請求都進行緩存，服務器資源消耗相當大，可以研究熱點功能的開設，將訪問數(shù)量較多的資源進行緩存。

[]

[1]王彥輝，張德全.兩類重要網(wǎng)絡的傳輸延遲分析[J].計算機工程與應用，2010,46(18):87-88.

[2]李銳,唐旭，石小龍，等.網(wǎng)絡GIS中最佳負載均衡的分布式緩存副本策略[J].武漢大學學報(信息科學版),2015,40(10):1287-1293.

[3]張國強,李揚，林濤，等，信息中心網(wǎng)絡中的內置緩存技術研究[J].軟件學報,2014,25(1):154-175.

[4]蔡君,余順爭，劉外喜.基于節(jié)點社團重要度的ICN緩存策略[J].通信學報，2015,36(6):2015222.DOI：10.11959/J.issn.1000-436x.2015222.

[5]SARA ALOUF，NICAISE CHOUNGMO FOFACK，NEDKO NEDKOV.Performance models for hierarchy of caches:application to modern DNS caches[J].Performance Evaluation,2016,97:57-82.

[6]張振偉，李志雄.網(wǎng)絡視頻直播緩存系統(tǒng)設計[J].計算機工程，2002，28(8):227-230.

[7]李云飛，謝偉凱，魯晨平,等.面向直播HTTP Streaming系統(tǒng)的HTTP緩存服務器行為優(yōu)化[J].計算機工程與應用，2012,48(1)：68-74.

[8]李潤知,郭純一，范明，等.P2P流媒體直播分布式緩存替換算法研究[J].計算機工程與設計，2011,32(1)：58-61.

[9]張曉軍，呂潔,張蓓.HTTP重定向在網(wǎng)關認證中的應用[J].大連理工大學學報，2005，45(s1):48-51.

[10]羅劍鋒.Boost程序完全開發(fā)指南[M].3版.北京：電子工業(yè)出版社，2015.