面向國(guó)內(nèi)直播行業(yè)的分布式彈幕爬蟲研究

王雪瑞　劉　淵

(江南大學(xué)數(shù)字媒體學(xué)院　江蘇 無錫 214122)

0　引　言

近年來國(guó)內(nèi)直播產(chǎn)業(yè)迅速發(fā)展，涌現(xiàn)出一大批直播服務(wù)，普遍提供彈幕功能，即實(shí)時(shí)覆蓋視頻內(nèi)容之上呈現(xiàn)的文字評(píng)論。彈幕作為網(wǎng)絡(luò)語言與社交的載體之一，無論從語言學(xué)或監(jiān)管角度看，均有潛在價(jià)值可供挖掘。尤其值得注意的是，圍繞直播平臺(tái)與網(wǎng)絡(luò)主播群體的負(fù)面新聞不斷，很多直播間的語言風(fēng)格也較為負(fù)面，這表明彈幕環(huán)境同網(wǎng)絡(luò)社交平臺(tái)輿論環(huán)境一樣需要適當(dāng)監(jiān)管。目前國(guó)內(nèi)針對(duì)直播彈幕的學(xué)術(shù)研究尚屬空白，無論是彈幕語料庫，還是面向彈幕的自然語言處理技術(shù)都急需建立與研究。

在國(guó)外，圍繞西方世界最大的電子競(jìng)技類直播網(wǎng)站Twitch.tv及其彈幕社區(qū)已有少量相關(guān)研究，例如Claypool等[1]與Nascimento等[2]通過視頻流、彈幕流與主播開關(guān)播時(shí)間等維度的分析研究直播視頻與直播社區(qū)。但Twitch.tv采用成熟而開放的IRC協(xié)議傳輸實(shí)時(shí)評(píng)論，并提供開發(fā)者API使IRC機(jī)器人方便接入[3]，沒有專門為之開發(fā)爬蟲的必要。因此，國(guó)外也就沒有開展彈幕爬蟲方面的研究。

國(guó)內(nèi)的彈幕服務(wù)現(xiàn)狀，與國(guó)外恰好相反。出于歷史與商業(yè)原因等國(guó)情，國(guó)內(nèi)流行的彈幕服務(wù)數(shù)量較多，與西方Twitch.tv一家獨(dú)大的狀況不同。這些服務(wù)無一采用現(xiàn)行開放標(biāo)準(zhǔn)構(gòu)建，并且只有少數(shù)開放相應(yīng)API，這使得彈幕信息難以輕易獲取。國(guó)內(nèi)的彈幕研究遂集中于視頻點(diǎn)播平臺(tái)的彈幕服務(wù)，而沒有能夠覆蓋直播彈幕，這表明直播彈幕爬蟲的研究有其必要性。

對(duì)不開放API的彈幕服務(wù)，我們需要模擬用戶訪問服務(wù)的過程來獲得彈幕數(shù)據(jù)。考慮到我們感興趣的彈幕服務(wù)均有Web客戶端，可以使用瀏覽器模擬的方式解決。瀏覽器模擬是在動(dòng)態(tài)Web爬蟲領(lǐng)域已有廣泛應(yīng)用的成熟技術(shù)。早期研究中，彭軻等提出并測(cè)試了基于瀏覽器服務(wù)的爬蟲[4]，劉兵基于JavaScript模擬執(zhí)行進(jìn)行鏈接分析[5]；此后，張媚[6]、管翠花[7]、段子飛[8]、錢程等[9]均在Ajax爬蟲方向進(jìn)行了研究，魏少鵬等直接使用Chrome瀏覽器擴(kuò)展方式實(shí)現(xiàn)爬蟲[10]，郭津丞等則僅僅改動(dòng)WebKit渲染引擎實(shí)現(xiàn)以輔助抓取[11]。然而，不開放API的彈幕服務(wù)其客戶端均以Adobe Flash技術(shù)實(shí)現(xiàn)，頁面上JavaScript僅僅作為Flash播放器插件的輔助而存在。因此上述瀏覽器模擬技術(shù)有的不能直接應(yīng)用，有的因?yàn)橹荒茉贘avaScript層面工作而效率低下，不能實(shí)現(xiàn)有效抓取。

雖然此前有針對(duì)Flash內(nèi)容爬蟲的相關(guān)研究[12]，但此Flash組件并非內(nèi)容載體，僅僅與彈幕服務(wù)器連接并動(dòng)態(tài)解析、渲染彈幕，因此常見的Flash爬蟲技術(shù)如文獻(xiàn)[12]等也不能應(yīng)用，需要找到更為底層的機(jī)制以繞過Flash黑箱的限制。

本文即針對(duì)國(guó)內(nèi)市場(chǎng)份額較大的彈幕服務(wù)，介紹了一種分布式彈幕爬蟲方案，具備支持多種開放與否彈幕協(xié)議的能力，以及可橫向伸縮的承載規(guī)模。

1　分布式彈幕爬蟲

1.1　原　理

彈幕服務(wù)雖然具有實(shí)時(shí)通信、傳輸彈幕信息的共性，但其應(yīng)用層協(xié)議各不相同，有些甚至還引入認(rèn)證機(jī)制與防爬蟲機(jī)制。考慮到這些服務(wù)為了吸引用戶，無一例外地允許匿名用戶觀看所有彈幕，因此這些機(jī)制的引入原因只可能是出于商業(yè)考慮，而不可能出于技術(shù)原因，并且所有此類機(jī)制必然放行匿名用戶。正如任何數(shù)字限制管理(Digital Restriction Management)方案都不可避免地存在所謂“模擬漏洞”(analog hole，任何非交互性的受保護(hù)數(shù)字內(nèi)容要為人類用戶所感知，必須最終被轉(zhuǎn)化為模擬形式，而這一最終模擬形式不可被任何機(jī)制限制)一般。這意味著我們完全可以通過模擬觀看直播的匿名用戶，實(shí)現(xiàn)針對(duì)任何不開放API彈幕服務(wù)的爬蟲。額外地，由于當(dāng)前主流彈幕服務(wù)的使用協(xié)議均于用戶注冊(cè)時(shí)生效[13-16]，而無論是對(duì)不開放API進(jìn)行逆向工程還是實(shí)際抓取均不需要注冊(cè)用戶帳號(hào)，因此此種機(jī)制不存在法律問題。

除規(guī)避防爬蟲機(jī)制的考慮之外，我們不需要特意關(guān)心高并發(fā)連接對(duì)源服務(wù)可能造成的影響。因?yàn)樯鲜龉ぷ髟硪馕吨词乖谂廊∪镜臉O端情況下，爬蟲在源服務(wù)的“足跡”也僅相當(dāng)于每個(gè)房間多出一名匿名用戶。這對(duì)任何已經(jīng)能夠承載正常數(shù)量用戶的服務(wù)而言都可以忽略不計(jì)。

同樣地，在不觸發(fā)目標(biāo)服務(wù)防爬蟲機(jī)制的前提下，我們也不需要刻意追求請(qǐng)求來源IP的分散化，雖然這樣做自有好處。這是因?yàn)閺膹椖环?wù)器的角度來看，它無法區(qū)分來自同一個(gè)IP的并發(fā)連接到底是多名穿過NAT的正常用戶，還是理想情況下在任何方面行為都與正常用戶相同的爬蟲連接。何況部署了反爬蟲或反DDoS機(jī)制的正常HTTP服務(wù)也不能做到上述區(qū)分，以至于真正攻擊者的存在往往會(huì)使同一網(wǎng)段或內(nèi)網(wǎng)的其他用戶無故被限制訪問。

退一步講，即使彈幕服務(wù)器確實(shí)設(shè)置了來源IP的并發(fā)限制，我們總是可以通過引入負(fù)載均衡，給爬蟲系統(tǒng)分配更多IP地址資源的方式來解決。

1.2　系統(tǒng)架構(gòu)

系統(tǒng)整體架構(gòu)如圖1所示，圖中黑色矩形節(jié)點(diǎn)代表不同程序模塊或節(jié)點(diǎn)；黑色邊代表數(shù)據(jù)流。

圖1　分布式彈幕爬蟲系統(tǒng)架構(gòu)

圖1中展示了1個(gè)支持的彈幕服務(wù)、1個(gè)房間源節(jié)點(diǎn)、1個(gè)爬蟲負(fù)載均衡節(jié)點(diǎn)、1個(gè)爬蟲節(jié)點(diǎn)以及1個(gè)存儲(chǔ)節(jié)點(diǎn)；實(shí)際上除爬蟲負(fù)載均衡節(jié)點(diǎn)之外，其余節(jié)點(diǎn)均支持任意數(shù)量的擴(kuò)展。彈幕爬蟲工作分為兩個(gè)階段：首先采用常規(guī)Web爬蟲技術(shù)請(qǐng)求所有指定彈幕服務(wù)的網(wǎng)頁端，得到可用房間列表；接著根據(jù)房間信息啟動(dòng)相應(yīng)協(xié)議的客戶端實(shí)現(xiàn)，以匿名身份連接房間，將接收到的彈幕發(fā)送至彈幕存儲(chǔ)組件，異步存儲(chǔ)入庫。組件之間靠消息隊(duì)列互相通信。

1.3　負(fù)載均衡機(jī)制

考慮使爬蟲節(jié)點(diǎn)的負(fù)載盡可能一致，房間連接的負(fù)載均衡直接采用round-robin方式。規(guī)定每個(gè)爬蟲節(jié)點(diǎn)均使用1個(gè)IP地址，針對(duì)不同彈幕服務(wù)對(duì)單IP最大連接數(shù)的限制，記錄所有節(jié)點(diǎn)每個(gè)服務(wù)已建立的連接數(shù)量。當(dāng)某彈幕服務(wù)的新房間連接請(qǐng)求到來時(shí)，將該請(qǐng)求分配到當(dāng)前時(shí)刻承載相應(yīng)服務(wù)連接數(shù)最少的節(jié)點(diǎn)。節(jié)點(diǎn)與彈幕服務(wù)不一一對(duì)應(yīng)，所有節(jié)點(diǎn)均支持建立到所有彈幕服務(wù)的連接，以保證系統(tǒng)易于橫向伸縮。具體算法如算法1、算法2所示。

算法1節(jié)點(diǎn)連接管理器

1. NodeID = 隨機(jī)字符串。

2. 向消息隊(duì)列訂閱NodeID頻道。

3. 啟動(dòng)心跳線程，周期性刷新內(nèi)存數(shù)據(jù)庫中NodeID的健康狀態(tài)。

4. 進(jìn)入事件循環(huán)：

a) 退出消息：退出循環(huán)。

b) 連接請(qǐng)求(Site, Room)：創(chuàng)建房間連接控制線程ControlThread(Site, Room)并啟動(dòng)。

5. 退出心跳線程。

6. 刪除內(nèi)存數(shù)據(jù)庫中NodeID狀態(tài)。

算法2房間連接請(qǐng)求分發(fā)(Site, Room)

1. 向內(nèi)存數(shù)據(jù)庫查詢健康節(jié)點(diǎn)列表。

2. 對(duì)每個(gè)健康節(jié)點(diǎn)：

a) 向內(nèi)存數(shù)據(jù)庫查詢其已經(jīng)建立的服務(wù)Site的房間連接數(shù)量；

b) 若達(dá)到或超過服務(wù)Site的每節(jié)點(diǎn)最大連接數(shù)，忽略該節(jié)點(diǎn)；

c) 記錄并更新連接數(shù)量最小的節(jié)點(diǎn)NodeID。

3. 通過消息隊(duì)列，向節(jié)點(diǎn)NodeID發(fā)送連接請(qǐng)求(Site, Room)。

1.4　房間連接建立機(jī)制

房間連接的建立，針對(duì)開放API的彈幕服務(wù)，直接采用各自開放API所述的協(xié)議連接即可，如算法3、算法4所示，使用算法5轉(zhuǎn)交接收的彈幕報(bào)文到存儲(chǔ)節(jié)點(diǎn)。而對(duì)不開放API的彈幕服務(wù)，連接方法于2.3節(jié)介紹。

算法3ControlThread(Site, Room)

1. 判斷服務(wù)Site的接口種類：

a) 開放API：創(chuàng)建房間連接工作線程WorkerThread(Site, Room)并啟動(dòng)；

b) 不開放API：創(chuàng)建瀏覽器模擬控制線程ShimThread(Site, Room)并啟動(dòng)。

2. 向消息隊(duì)列訂閱(Site, Room)頻道。

3. 進(jìn)入事件循環(huán)，阻塞，直到接收到退出消息。

4. 設(shè)置WorkerThread(Site, Room)線程的退出flag為真。

5. 等待WorkerThread(Site, Room)退出。

算法4WorkerThread(Site, Room)

1. 設(shè)置退出flag為假。

2. 初始化數(shù)據(jù)緩沖區(qū)Buffer，一個(gè)循環(huán)緩沖區(qū)RingBuffer。

3. 無限循環(huán)：

a) IP, Port = 解析服務(wù)器地址(Site)；

b) Socket = connect(IP, Port)；失敗則continue；

c) 使內(nèi)存數(shù)據(jù)庫中本節(jié)點(diǎn)已建立連接數(shù)原子自增1；

d) 在Socket上執(zhí)行服務(wù)Site的認(rèn)證序列；

e) 在Socket上執(zhí)行服務(wù)Site的進(jìn)入房間序列；

f) 無限循環(huán)，Length = recv(Socket, Buffer, sizeof(Buffer))：

i. 如退出flag為真，跳出最外層循環(huán)；

ii. 執(zhí)行ProcessIncomingDanmaku(Site, Buffer, Length, RingBuffer)。

4. 如循環(huán)中任何Socket操作失敗，或退出循環(huán)：

a) close(Socket)；

1.4 統(tǒng)計(jì)學(xué)方法 應(yīng)用SPSS 13.0統(tǒng)計(jì)軟件將兩組血壓控制情況、高血壓知識(shí)、技能掌握、年門診輸液或住院例次數(shù)情況進(jìn)行統(tǒng)計(jì)學(xué)分析。計(jì)量資料以±s表示。兩組間比較采用t檢驗(yàn);組間前后比較采用配對(duì)t檢驗(yàn);率的比較用χ2檢驗(yàn)。

b) 使內(nèi)存數(shù)據(jù)庫中本節(jié)點(diǎn)已建立連接數(shù)原子自減1；

c) Delay = random(最長(zhǎng)重試間隔時(shí)間)；

d) 等待Delay的時(shí)間；

e) continue(退出循環(huán)則return)。

算法5ProcessIncomingDanmaku(Site, Buffer, Length, RingBuffer)

1. Time = 當(dāng)前時(shí)間；

3. 循環(huán)從RingBuffer中讀服務(wù)Site的完整一幀報(bào)文，存放于Data，直到?jīng)]有完整報(bào)文：將(Time, Site, Data)通過消息隊(duì)列傳入存儲(chǔ)節(jié)點(diǎn)。

1.5　異步彈幕分類存儲(chǔ)機(jī)制

由于接收到的彈幕數(shù)量極為龐大，有必要對(duì)彈幕進(jìn)行異步存儲(chǔ)，以防止數(shù)據(jù)庫寫入性能成為瓶頸。考慮到上游彈幕協(xié)議隨時(shí)可能發(fā)生變化，為了最大限度保存原始報(bào)文信息，我們直接存儲(chǔ)原始彈幕報(bào)文入庫，留待下游處理組件詳細(xì)解析。

同時(shí)由于一些非聊天信息的實(shí)時(shí)事件，如用戶進(jìn)入直播間消息、贈(zèng)送禮物廣播消息等通常也使用彈幕方式進(jìn)行傳輸，為降低下游處理組件的復(fù)雜度及處理負(fù)擔(dān)，以及減少數(shù)據(jù)庫單個(gè)表的寫入壓力，我們依然在存儲(chǔ)前按照相應(yīng)的彈幕協(xié)議反序列化每個(gè)報(bào)文，并按照彈幕類型分為聊天彈幕與非聊天彈幕兩類，分別批量插入兩個(gè)表中。具體算法如算法6、算法7所示。

算法6存儲(chǔ)節(jié)點(diǎn)

1. 建立隊(duì)列ChatQueue與ControlQueue。

2. 向消息隊(duì)列訂閱原始報(bào)文頻道。

3. 創(chuàng)建StorageThread(ChatQueue, ControlQueue)線程并啟動(dòng)。

4. 進(jìn)入事件循環(huán)，接收消息：

a) 彈幕消息(Time, Site, Data)：

i. 用服務(wù)Site的協(xié)議反序列化Data；

ii. 取出Data的彈幕類型；

iii. 若Data為聊天彈幕，將(Time, Site, Data)放入ChatQueue，否則放入ControlQueue。

b) 退出消息：

i. 設(shè)置StorageThread線程的退出flag為真；

ii. 等待StorageThread線程退出；

iii. return。

算法7StorageThread(ChatQueue, ControlQueue)

1. 設(shè)置退出flag為假。

2. 無限循環(huán)，直到退出flag為真：

a) 等待一固定時(shí)間；

b) 從ChatQueue中原子地取出所有項(xiàng)，批量插入聊天彈幕表；

c) 從ControlQueue中原子地取出所有項(xiàng)，批量插入非聊天彈幕表。

1.6　基于PPAPI旁路的瀏覽器模擬

考慮到非開放API的彈幕客戶端以Flash技術(shù)實(shí)現(xiàn)，F(xiàn)lash又以插件的形式與瀏覽器連接，我們即可在瀏覽器的插件界面附近引入旁路，直接從Flash插件與瀏覽器的交互過程中抓取彈幕信息。目前主流的瀏覽器插件機(jī)制有兩種，一種為上世紀(jì)Netscape瀏覽器使用的NPAPI，另一種為Google主導(dǎo)的相對(duì)更完善的PPAPI[17]。而NPAPI由于年代久遠(yuǎn)且安全性欠佳，其支持逐漸稀少，故我們選用PPAPI接口實(shí)現(xiàn)信息旁路，即為PPAPI旁路。如圖2所示。

圖2　PPAPI Flash插件與宿主交互示意

圖2中，在PPAPI插件架構(gòu)中，瀏覽器渲染引擎負(fù)責(zé)向插件(此處為PPAPI Flash，存在于共享庫文件libpepflashplayer.so中)暴露其可能需要的一切系統(tǒng)功能界面，如JavaScript對(duì)象互操作(PPB_Var接口)、TCP套接字(PPB_TCPSocket接口)以及瀏覽器界面集成(PPB_Instance接口)等。這主要是為了使不受信任的插件代碼能在嚴(yán)格受限的沙盒進(jìn)程中正常工作，同時(shí)也為信息旁路的實(shí)現(xiàn)提供了極大便利。我們?cè)赑PB_TCPSocket接口的實(shí)現(xiàn)中可以便捷地截獲Flash插件發(fā)起的所有TCP網(wǎng)絡(luò)活動(dòng)。由于只有Flash插件的網(wǎng)絡(luò)活動(dòng)才會(huì)流經(jīng)該接口，其中無關(guān)數(shù)據(jù)包比例明顯較鏈路層抓包時(shí)為小，有利于提高處理效率。實(shí)際實(shí)現(xiàn)的PPAPI旁路機(jī)制如圖3所示(圖中省略了無關(guān)部分)。

圖3　PPAPI 旁路數(shù)據(jù)流示意

如圖3所示，修改渲染引擎實(shí)現(xiàn)，在PPB_TCPSocket接口的Read接口實(shí)現(xiàn)中監(jiān)視插件的網(wǎng)絡(luò)流量，對(duì)其中屬于目標(biāo)彈幕協(xié)議的報(bào)文進(jìn)行解析，并以內(nèi)部協(xié)議轉(zhuǎn)發(fā)解析結(jié)果給彈幕存儲(chǔ)組件。而Flash插件并不能感知這些修改，使得此機(jī)制無需擔(dān)心被識(shí)別進(jìn)而被限制。

由于完整瀏覽器的代碼規(guī)模十分龐大，我們基于支持PPAPI并且規(guī)模適中的Electron項(xiàng)目進(jìn)行修改。Electron是基于Blink渲染引擎的桌面應(yīng)用框架(Blink是Google公司的WebKit fork)，支持通過WebView方式嵌入網(wǎng)頁，并能與網(wǎng)頁交換數(shù)據(jù)。考慮到服務(wù)器環(huán)境沒有圖形界面，無法直接啟動(dòng)瀏覽器實(shí)現(xiàn)乃至Flash插件，我們使用Xvfb作為X11顯示服務(wù)器以承載模擬瀏覽器窗口。由此，每個(gè)房間連接在網(wǎng)頁以及Flash看來即猶如Linux下Chrome瀏覽器用戶的正常瀏覽過程，實(shí)現(xiàn)了對(duì)可能的前端防爬蟲機(jī)制的規(guī)避，何況系統(tǒng)信息也可通過修改瀏覽器相應(yīng)接口的方式對(duì)網(wǎng)頁端JavaScript腳本予以欺騙。PPAPI瀏覽器模擬的實(shí)現(xiàn)如算法8-算法10所示。

算法8ShimThread(Site, Room)

1. 設(shè)置退出flag為假。

2. 無限循環(huán)：

a) 啟動(dòng)ShimProcess(Site, Room)子進(jìn)程。

b) 每隔固定時(shí)間檢測(cè)退出flag：

i. 為真：終止PID，退出循環(huán)；

ii. 為假：檢查子進(jìn)程狀態(tài)，若異常退出則continue外層循環(huán)以恢復(fù)連接，否則什么也不做。

算法9ShimProcess(Site, Room)

1. 初始化循環(huán)緩沖區(qū)RingBuffer。

2. URL = 生成房間網(wǎng)址(Site, Room)。

3. 將內(nèi)置WebView指向URL，等待Flash插件自動(dòng)加載。

4. 重載WebView資源請(qǐng)求邏輯，拒絕所有圖像、聲音、視頻流的請(qǐng)求以節(jié)省流量，只放行播放器初始化所需腳本與Flash播放器本身。

并在渲染引擎的PPB_TCPSocket接口實(shí)現(xiàn)中：

修改Read接口實(shí)現(xiàn)，接口函數(shù)指針原型：int32_t (*Read)(PP_Resource tcp_socket, char *buffer, int32_t bytes_to_read, struct PP_CompletionCallback callback)[17]。

a) 正常執(zhí)行Bytes_Read = recv(tcp_socket, buffer, bytes_to_read)；

b) 添加：調(diào)用SideChannel(Site, buffer, Bytes_Read, RingBuffer)；

c) 正常回調(diào)callback。

算法10SideChannel(Site, Buffer, Length, RingBuffer)

1. 檢查Buffer頭部是否符合服務(wù)Site協(xié)議特征，不符合則return。

2. 執(zhí)行ProcessIncomingDanmaku(Site, Buffer, Length, RingBuffer)。

2　實(shí)驗(yàn)與分析

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

我們?cè)趪?guó)內(nèi)某知名彈幕服務(wù)進(jìn)行了實(shí)驗(yàn)，該服務(wù)有開放API可供利用，并提供了相關(guān)協(xié)議文檔。出于實(shí)驗(yàn)?zāi)康模覀円策x用該服務(wù)作為“不開放API”的測(cè)試服務(wù)。我們用Python實(shí)現(xiàn)了開放API的輕量級(jí)客戶端以及系統(tǒng)的其余部分，用JavaScript實(shí)現(xiàn)了不開放API彈幕服務(wù)到爬蟲系統(tǒng)內(nèi)部協(xié)議的轉(zhuǎn)換模塊，用C語言實(shí)現(xiàn)了該服務(wù)彈幕協(xié)議的識(shí)別與解析模塊。

測(cè)試環(huán)境為3個(gè)Linux節(jié)點(diǎn)，其中兩個(gè)為物理節(jié)點(diǎn)，一個(gè)為虛擬節(jié)點(diǎn)，所有節(jié)點(diǎn)各有一個(gè)公網(wǎng)IPv4地址。爬蟲系統(tǒng)中其他組件分別為消息隊(duì)列RabbitMQ、Redis以及數(shù)據(jù)庫PostgreSQL。這些服務(wù)均以Docker容器的形式部署。

2.2　開放API抓取實(shí)驗(yàn)

實(shí)驗(yàn)前，預(yù)先使用單節(jié)點(diǎn)單IP地址進(jìn)行了測(cè)試，發(fā)現(xiàn)單個(gè)IP地址最多只能建立200個(gè)房間連接。為確認(rèn)連接數(shù)限制發(fā)生在何處，同時(shí)進(jìn)行了由校網(wǎng)絡(luò)中心內(nèi)節(jié)點(diǎn)到校外服務(wù)器的高并發(fā)心跳連接測(cè)試，結(jié)果表明能夠維持至少500條并發(fā)連接且無一中斷。這排除了校網(wǎng)絡(luò)中心對(duì)所有出站連接數(shù)量進(jìn)行限制的可能，說明了該彈幕服務(wù)的開放API僅允許單IP保持200條連接。由于總共有3個(gè)IPv4地址可供使用，本次實(shí)驗(yàn)最多可同時(shí)維持該服務(wù)600個(gè)房間的連接。

為節(jié)省連接數(shù)，我們同時(shí)注意到?jīng)]有必要抓取小流量直播間的彈幕數(shù)據(jù)，因?yàn)檫@些語料將被大流量房間的海量數(shù)據(jù)所淹沒，不具備統(tǒng)計(jì)學(xué)意義，因此為系統(tǒng)增加了自動(dòng)斷開連續(xù)空閑5分鐘的房間連接的機(jī)制。

我們抓取了位于該服務(wù)所有房間列表第一頁的直播間。本次實(shí)驗(yàn)進(jìn)行了26.9 h，總共獲取了7 931 385條聊天彈幕與5 077 451條非聊天彈幕，抓取的原始報(bào)文如圖4、圖5，運(yùn)行狀態(tài)如圖6、圖7。平均抓取速度達(dá)到每秒134條，實(shí)際峰值速度達(dá)到每秒1 000條。

圖4　聊天彈幕示例

圖5　非聊天彈幕示例(全站禮物廣播、用戶進(jìn)入房間)

圖6　已建立房間連接數(shù)

圖7　斷開連接原因

如圖6所示，擁有足夠IP地址資源的系統(tǒng)確實(shí)能夠承載相應(yīng)的連接數(shù)量，并有效控制自身所維持的連接數(shù)。如圖7所示，其他原因造成的連接中斷消失，服務(wù)器主動(dòng)斷開連接的頻率也大大降低，每分鐘0.277次的斷開連接頻率已經(jīng)與使用官方客戶端觀看直播的彈幕服務(wù)器斷開頻率接近，完全滿足穩(wěn)定運(yùn)行的要求。

2.3　PPAPI旁路接口抓取實(shí)驗(yàn)

雖然上述彈幕服務(wù)已經(jīng)提供了開放API，出于驗(yàn)證目的，我們?nèi)匀挥闷湮臋n輔助實(shí)現(xiàn)了PPAPI旁路的彈幕協(xié)議識(shí)別與解析模塊，并以此種方式進(jìn)行了抓取。實(shí)際應(yīng)用中，面對(duì)未提供協(xié)議文檔的彈幕服務(wù)，這部分知識(shí)將通過流量嗅探、逆向工程等方式獲取。由于內(nèi)存占用的關(guān)系，我們僅僅選擇3.2節(jié)中使用的房間列表的前10個(gè)房間進(jìn)行抓取。

由于實(shí)驗(yàn)規(guī)模很小，且結(jié)果與開放API情形十分相似，實(shí)驗(yàn)數(shù)據(jù)從略。值得注意的是，因?yàn)槊總€(gè)直播間均對(duì)應(yīng)一個(gè)模擬瀏覽器實(shí)例，且Flash插件運(yùn)行需要虛擬X11顯示服務(wù)器支持，內(nèi)存占用十分驚人。實(shí)際測(cè)量單個(gè)房間連接的內(nèi)存使用與Chrome瀏覽器平均每個(gè)標(biāo)簽頁類似，為數(shù)十MB級(jí)別，這與輕量級(jí)客戶端數(shù)十KB的內(nèi)存占用差距甚大，而且屬于瀏覽器模擬機(jī)制的固有特性，不便進(jìn)一步降低。這說明不開放API彈幕服務(wù)的抓取應(yīng)為權(quán)宜之計(jì)，長(zhǎng)遠(yuǎn)來看，要對(duì)彈幕進(jìn)行大規(guī)模的外部研究乃至監(jiān)管，依然需要彈幕服務(wù)本身配合。

3　結(jié)　語

對(duì)于彈幕信息處理而言，實(shí)現(xiàn)高效可靠地采集是第一步，而目前國(guó)內(nèi)外此方面研究尚屬空白。本文針對(duì)我國(guó)直播行業(yè)國(guó)情，創(chuàng)新地提出并實(shí)現(xiàn)了一種分布式直播彈幕爬蟲方案，并在真實(shí)生產(chǎn)環(huán)境條件下進(jìn)行了實(shí)驗(yàn)，表明該爬蟲具有良好的工作性能，能夠?qū)崟r(shí)抓取峰值至少每秒1 000條量級(jí)的彈幕數(shù)據(jù)，并實(shí)現(xiàn)了與官方客戶端相近的連接中斷頻率，完全可以用于生產(chǎn)環(huán)境的數(shù)據(jù)抓取。

展望未來研究方向，我們?nèi)匀恍枰_發(fā)相應(yīng)的數(shù)據(jù)處理流水線，如此才能將原始彈幕語料轉(zhuǎn)化為有效信息以支持各類下游應(yīng)用。我們希望本研究能夠在彈幕信息處理的領(lǐng)域拋磚引玉，通過收集彈幕信息，匯編彈幕語料庫，以使更大范圍的直播彈幕研究成為可能，進(jìn)而促進(jìn)彈幕信息處理手段的發(fā)展。

另外值得指出的是，雖然彈幕信息研究的需求日漸上升，各大彈幕服務(wù)對(duì)彈幕信息利用仍然缺乏開放性，法律地位大多也仍然不甚明確。因此本技術(shù)在產(chǎn)業(yè)化過程中必然面臨需要向各服務(wù)單獨(dú)獲取授權(quán)及相應(yīng)接口的境況。對(duì)于未來仍將繼續(xù)發(fā)展的彈幕產(chǎn)業(yè)而言，各大彈幕服務(wù)有必要認(rèn)識(shí)到構(gòu)建開放生態(tài)的重要性。

[1] Claypool M, Farrington D, Muesch N. Measurement-based analysis of the video characteristics of Twitch.tv[C]// IEEE Games Entertainment Media Conference. 2015.

[2] Nascimento G, Ribeiro M, Cerf L, et al. Modeling and Analyzing the Video Game Live-Streaming Community[C]// Latin American Web Congress. 2014:1-9.

[3] Twitch.tv. justintv/Twitch-API[EB/OL]. 2016(2016/06/29)[2016/06/29]. https://github.com/justintv/Twitch-API/tree/0d06204.

[4] 彭軻, 廖聞劍. 基于瀏覽器服務(wù)的網(wǎng)絡(luò)爬蟲[J]. 硅谷, 2009(4):53-54.

[5] 劉兵. 基于JavaScript等多鏈接分析的主題爬蟲設(shè)計(jì)實(shí)現(xiàn)[J]. 許昌學(xué)院學(xué)報(bào), 2010, 29(2):87-90.

[6] 張媚. Ajax友好的網(wǎng)絡(luò)爬蟲設(shè)計(jì)與實(shí)現(xiàn)[D]. 暨南大學(xué), 2011.

[7] 管翠花. 支持Ajax技術(shù)的Deep Web網(wǎng)絡(luò)爬蟲模型研究[D]. 大連海事大學(xué), 2011.

[8] 段子飛. 支持Ajax的Deep Web網(wǎng)絡(luò)爬蟲系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D]. 華南理工大學(xué), 2015.

[9] 錢程, 陽小蘭. 一種支持Ajax框架的網(wǎng)絡(luò)爬蟲的設(shè)計(jì)與實(shí)現(xiàn)[J]. 計(jì)算機(jī)與數(shù)字工程, 2012(4):69-71.

[10] 魏少鵬, 夏小玲. 基于Chrome擴(kuò)展的爬蟲系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[J]. 軟件導(dǎo)刊, 2016, 15(3):76-80.

[11] 郭津丞, 馮超, 張磊. 基于WebKit的網(wǎng)絡(luò)爬蟲[J]. 現(xiàn)代電子技術(shù), 2013(18):62-64.

[12] 錢晨, 張曉靜. 網(wǎng)絡(luò)Flash爬蟲搜索方法比較研究[J]. 中國(guó)教育技術(shù)裝備, 2014(14):32-34.

[13] 杭州邊鋒網(wǎng)絡(luò)技術(shù)有限公司. 戰(zhàn)旗直播注冊(cè)協(xié)議[EB/OL]. 2016(2016/04/23)[2016/04/23]. http://www.zhanqi.tv/common/agreement.html.

[14] 武漢斗魚網(wǎng)絡(luò)科技有限公司. 斗魚—用戶注冊(cè)協(xié)議[EB/OL]. 2016(2016/04/23)[2016/04/23]. http://www.douyu.com/protocal/member.

[15] 廣州華多網(wǎng)絡(luò)科技有限公司. 多玩通行證——用戶協(xié)議[EB/OL]. 2016(2016/04/23)[2016/04/23]. http://zc.yy.com/license.html.

[16] 上海熊貓互娛文化有限公司. 熊貓TV用戶注冊(cè)協(xié)議[EB/OL]. 2016(2016/04/23)[2016/04/23]. http://www.panda.tv/agreement.html.

[17] Google. Pepper API Reference (Stable)[S/OL]. 2016(2016/04/23)[2016/04/23]. https://developer.chrome.com/native-client/pepper_stable.