基于P2P串流技術(shù)的異構(gòu)網(wǎng)絡(luò)家庭聯(lián)合監(jiān)視系統(tǒng)

先柯樺

（四川建筑職業(yè)技術(shù)學(xué)院，四川 德陽 618000）

責(zé)任編輯:薛 京

在傳統(tǒng)家庭監(jiān)視系統(tǒng)中，若緊急事件發(fā)生時房主不在家，就無法即時處理事件[1-2]。本文采用Web 2.0方法，將房主的好友、鄰居等加入監(jiān)視群體，只需其中任何一位成員發(fā)出警示信息，就可立即將監(jiān)視畫面?zhèn)鹘o其他監(jiān)視群體成員。因為單一Camera的上傳帶寬有限，本文還將采用P2P網(wǎng)絡(luò)串流技術(shù)[3-4]，來節(jié)省視頻上傳所需的帶寬[5-7]。本文還設(shè)計了具備監(jiān)視視頻加密功能的安全聯(lián)防網(wǎng)絡(luò)系統(tǒng)[4]，包含金鑰管理和交換機制，還有為滿足不同成員終端設(shè)備的需求，在Camera端采用視頻網(wǎng)絡(luò)編碼，將監(jiān)視畫面轉(zhuǎn)換編碼成800×600，640×480和480×360三種不同的分辨力，可以分別在PC、筆記本式計算機和智能手機上顯示。最后，通過實驗來驗證本文所設(shè)計系統(tǒng)的穩(wěn)定性和視頻加密效能。

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

如圖1所示，本文所提出的家庭聯(lián)合監(jiān)視系統(tǒng)，主要包括3個部分，包括IP Camera和Source PC端、Web Portal端和P2P網(wǎng)絡(luò)上的監(jiān)視終端。

圖1 家庭聯(lián)合監(jiān)視系統(tǒng)架構(gòu)

1）IP Camera與Source PC端:IP Camera端可以基于RTSP協(xié)議，發(fā)送監(jiān)視視頻數(shù)據(jù)到Source PC。Source PC端可以采用VLC視頻編碼技術(shù)，將Camera產(chǎn)生的RTSP串流轉(zhuǎn)換編碼成MPEG-4/H.264串流。再采用OpenSSL將編碼后的串流以對稱式加密法進行加密，并使用Hash Function在串流中加入驗證碼，以確保數(shù)據(jù)完整性。最后通過所建立的安全通道向管理中心，進行注冊/認證，以及發(fā)送解密金鑰。

2）Web Portal端:主要負責(zé)記錄、維護每一戶的聯(lián)防群體名單，當有緊急事件發(fā)生時，Source PC端會向Web Portal端取得群體名單，并以P2P方式將監(jiān)視畫面進行傳輸。此外還支援IP Camera與Source PC端的注冊/登入/認證功能，并進行金鑰發(fā)布及金鑰更新。如圖2所示，Web Portal端的核心模組簡要說明如下:

（1）Apache Kernel:采用Apache軟件來構(gòu)建服務(wù)器，提供一個友善的界面，允許Peer從遠端通過HTTP通信協(xié)議進行聯(lián)防群體的設(shè)定。

（2）Database:所架設(shè)的Web服務(wù)器，可以通過開放式數(shù)據(jù)庫系統(tǒng)接口來存取后端的數(shù)據(jù)庫，并在Repository中存放大型二進制檔案的磁盤空間，如聯(lián)防的多媒體數(shù)據(jù)。

（3）Transmission Kernel:前述欲發(fā)送的數(shù)據(jù)包，可以采用不同的通信協(xié)議，應(yīng)用不同的網(wǎng)絡(luò)拓撲架構(gòu)，發(fā)送到遠端的聯(lián)防成員。

（4）金鑰管理模組:它是一個集中式的金鑰管理框架，主要用來支援IP Camera與Source PC端的注冊/登入/認證和進行金鑰發(fā)布及金鑰更新。

圖2 Web Portal端的功能模組

3）P2P網(wǎng)絡(luò)上的監(jiān)視終端:監(jiān)視終端設(shè)備將負責(zé)把Transcoding和加密后不同分辨力的監(jiān)視視頻，經(jīng)緩沖、解密和解碼，最終顯示在監(jiān)視設(shè)備上。

2 研究方法

在本節(jié)中將介紹3個主要研究方法，包括IP Camera和Source PC間的RTSP通信、金鑰發(fā)布中心和監(jiān)視視頻轉(zhuǎn)換編碼架構(gòu)。各個方法的描述如下。

2.1 IP Camera和Source PC端的RTSP通信

IP Camera與Source PC間通過RTSP協(xié)議進行視頻串流的溝通，所以Source PC需負責(zé)RTSP的對話，接收來自IP Camera的視頻串流，并且將串流視頻封裝為P2P的數(shù)據(jù)傳輸單位。

1）發(fā)送串流

當Source PC發(fā)起URL請求與IP Camera建立RTSP連接時，通常采用TCP進行可靠連線。IP Camera在這個連線上等待Source PC端發(fā)起RTSP會話，包括Options，Describe，Setup，Play等一系列的請求，請求步驟為:

（1）Options請求及回應(yīng):TCR連線建立后，Source PC向IP Camera發(fā)送Options請求，IP Camera的回應(yīng)則包括其所能提供的方法，如 Describe，Setup，Teardown，Play，Pause，Set_Parameter等。

（2）Describe請求及回應(yīng):Source PC采用Describe向IP Camera請求Requested Media Data的相關(guān)數(shù)據(jù)，這些數(shù)據(jù)以SDP協(xié)議描述。

（3）Setup請求及回應(yīng):獲得多媒體信息后，則需要告知IP Camera用何種機制接收數(shù)據(jù)，這里使用的是RTP與RTCP協(xié)議進行數(shù)據(jù)傳輸。

（4）Play請求及回應(yīng):Play Method本是用來告知所需的數(shù)據(jù)范圍，不過這里IP Camera要不停地發(fā)送監(jiān)視視頻，因此不需要加上。

（5）Teardown請求及回應(yīng):當應(yīng)用程序要結(jié)束時，可以采用Teardown告知IP Camera停止發(fā)送視頻，并釋放系統(tǒng)資源。

2）接收串流

當Play請求及回應(yīng)完成后，IP Camera會開始傳輸視頻數(shù)據(jù)，這里使用了RTP與RTCP兩種通信協(xié)議。由于Video Frame有可能會切割成數(shù)個RTP封包，對Source PC來說，可以采用RTP Header中的Timestamp信息來還原視頻數(shù)據(jù)。RTCP則是與RTP一起使用的，主要功能是發(fā)送品質(zhì)的監(jiān)視與回饋、媒體間的同步，能夠提供擁塞控制。

在RTCP的Setup會話中，可以要求RTP/RTSP協(xié)議使用UDP/TCP協(xié)議發(fā)送，如果使用UDP，在Setup會話過程中會告知雙方使用的Port。由于使用UDP傳輸會有丟失封包的可能，所以在解碼還原Video Frame的過程中，可能會有無法還原，須舍棄Video Frame的情況。若使用TCP協(xié)議進行傳輸，則直接利用RTSP會話的連線，并會在Header中加一段以區(qū)分RTP與RTCP封包，盡管TCP連線能保證封包不會遺失，但在網(wǎng)絡(luò)擁塞的情況下Source PC得到的畫面將會與IP Camera有一段時間上的延遲。

2.2 金鑰發(fā)布中心

對于數(shù)據(jù)量較大的視頻信息，例如入侵偵測和IP Camera錄下的內(nèi)容，本文將采用P2P方式加快監(jiān)視視頻播送的速度。為避免監(jiān)視視頻遭攔截竊取，設(shè)計了一個金鑰發(fā)布中心，并根據(jù)家庭聯(lián)防監(jiān)視群體的特性，增設(shè)GroupKey，方便管理群體數(shù)據(jù)的加解密。將采用OpenS?SL開發(fā)P2P Security功能，并提供金鑰管理機制與數(shù)據(jù)傳輸加密（安全強度為AES-128），完整通報流程包括以下3個階段:

1）IP Camera/Source PC端事件通報流程:IP Camera/Source PC端連線至Web Portal的金鑰發(fā)布中心，使用發(fā)布中心的公開金鑰將個人帳號、密碼、隨機數(shù)字及串流金鑰（將來供客戶端解碼串流信息用）加密后，傳至管理中心。由公開金鑰加密的過程完成了數(shù)據(jù)的保密性及完整性，并采用個人帳號/密碼來驗證IP Camera/Source PC端的身份。

2）金鑰發(fā)布中心通知聯(lián)防群體成員流程:金鑰發(fā)布中心連線至各聯(lián)防群體成員，將串流金鑰、IP Camera/Source PC端的信息和其公開金鑰，先使用金鑰發(fā)布中心的私密金鑰加密，再使用聯(lián)防群體成員端的公開金鑰加密傳至聯(lián)防群體成員端，因為過程中使用了聯(lián)防群體成員端的公開金鑰加密，如此確保了加密性，再者因為金鑰發(fā)布中心用了私密金鑰加密，聯(lián)防群體成員端可以用金鑰發(fā)布中心的公開金鑰將其解回。

3）聯(lián)防群體成員端交換串流數(shù)據(jù)流程:在P2P傳輸過程中，聯(lián)防群體成員可能從其他聯(lián)防群體成員或是IP Camera/Source PC端得到串流數(shù)據(jù)，此串流數(shù)據(jù)的源頭一定是IP Camera/Source PC端，聯(lián)防群體成員端只負責(zé)將收到的串流數(shù)據(jù)轉(zhuǎn)發(fā)出去。聯(lián)防群體成員端首先使用AES-128對稱式加密法對串流片段（Streaming Segment）進行加密成E，然后再將E經(jīng)過SHA-1轉(zhuǎn)換成20 byte的Digest D。接著使用IP Camera/Source PC端的Private Key對D做數(shù)字簽章成SD，將E+SD透過P2P傳輸散布至所有的客戶端。因為串流片段本身已經(jīng)經(jīng)過AES-128加密，所以已達成保密性（要有串流金鑰才能解開）；再者因為D已經(jīng)做了數(shù)字簽章，聯(lián)防群體成員可以用IP Camera/Source PC端的公開金鑰將其解回，只有IP Camera/Source PC端本身才能做數(shù)字簽章，所以也驗證了IP Camera/Source PC端的身份，達成了驗證性。最后，因為有加密串流片段的Digest數(shù)據(jù)，所以可以驗證是否為原始的加密數(shù)據(jù)和中途是否經(jīng)過竄改或損壞，所以可完成完整性驗證。

2.3 監(jiān)視視頻轉(zhuǎn)換編碼

由于移動裝置，如Notebook和Smartphone的普及，終端設(shè)備趨于多樣化，單一分辨力的監(jiān)視畫面無法滿足需求，因此本文將開發(fā)一個動態(tài)多串流編碼技術(shù)，可以由Camera采集到的視頻，采用VLC進行轉(zhuǎn)碼，根據(jù)P2P網(wǎng)絡(luò)拓撲中各裝置的計算能力設(shè)計動態(tài)分群、群收視位元率評估和Peer在不同群間的Handoff機制，分成800×600，640×480和480×360三種不同分辨力的監(jiān)視視頻串流，會形成不同的聯(lián)防監(jiān)視群體，如圖3所示。

圖3 異構(gòu)聯(lián)防網(wǎng)絡(luò)示意圖

當Source PC端接收到異常事件通知時，會立即開啟IP Camera并接收監(jiān)視串流和播放，并且通知聯(lián)防群體中的所有成員進行協(xié)防監(jiān)視，Source PC會根據(jù)聯(lián)防成員的裝置種類和要求的串流品質(zhì)進行評估，決定是否直接連接IP Camera或分配到理想的Peer Group中來接收視頻，整體流程如圖4所示。

圖4 監(jiān)視串流品質(zhì)評估流程圖

3 實驗結(jié)果

在本文的實驗中，將驗證系統(tǒng)穩(wěn)定性、視頻加密效能，并采用臺式計算機、筆記本式計算機和智能手機，分別連接有線、無線網(wǎng)絡(luò)，以展示異構(gòu)家庭聯(lián)防應(yīng)用情境。整個系統(tǒng)展示情境設(shè)計如圖5所示，包括以下情境:

1）A住戶門窗傳感器偵測到異常。

2）A住戶警報器發(fā)出警報聲。

（1）聯(lián)防監(jiān)視成員用PC播放門附近的視頻串流（分辨力較大）；

（2）其他聯(lián)防監(jiān)視成員以Notebook或Smartphone播放門窗附近視頻串流。

3）B住戶警報器發(fā)出警報聲，并由家庭聯(lián)防計算機播放A住戶門窗附近視頻串流。

4）A或B住戶關(guān)閉事件通知。

5）A和B兩戶警報器及串流都停止運作。

圖5 系統(tǒng)展示情景示意圖

圖6是呈現(xiàn)當發(fā)生門窗被入侵時，會啟動聯(lián)防機制，監(jiān)視視頻會通過P2P網(wǎng)絡(luò)，發(fā)送到不同的監(jiān)視端，包括Netbook，Smartphone和Notebook。系統(tǒng)平均點對點的播放時間延遲約15～20 s，優(yōu)于目前Live P2P應(yīng)用程序，如PPStream。

圖6 異構(gòu)家庭聯(lián)防應(yīng)用情境（截圖）

在家庭聯(lián)防視頻監(jiān)視系統(tǒng)的驗證部分，本文通過非對稱式架構(gòu)和AES-128，來加密保護社群數(shù)據(jù)安全。首先探討啟動安全機制后，對系統(tǒng)整體效能的影響，并以傳感視頻數(shù)據(jù)的傳輸速率作為參考指標，跟未啟動安全機制的情況相比，啟動安全機制后監(jiān)視視頻的傳輸速率，由30 f/s（幀/秒）降低至 26～28 f/s，也就是額外增加的Overhead約為6%～10%左右。

另外，嘗試用緊急事件發(fā)生次數(shù)與聯(lián)防監(jiān)視網(wǎng)絡(luò)成功建立的比例關(guān)系來作為家庭聯(lián)合監(jiān)視系統(tǒng)穩(wěn)定性的評估指標。以往的主從式架構(gòu)的監(jiān)控串流設(shè)計，經(jīng)常因為服務(wù)器端的上傳帶寬過小，以及所有監(jiān)控裝置均要求同一品質(zhì)的監(jiān)控視頻，造成網(wǎng)絡(luò)斷線、負荷過載或系統(tǒng)的穩(wěn)定性降低。本文應(yīng)用安全P2P網(wǎng)絡(luò)串流技術(shù)，讓每一個監(jiān)控端成員都能夠負責(zé)上傳監(jiān)控視頻，減少服務(wù)器端的負載，讓系統(tǒng)穩(wěn)定性在95%以上，避免因為網(wǎng)絡(luò)、監(jiān)控裝置、使用者行為的異構(gòu)性，造成系統(tǒng)不穩(wěn)定、服務(wù)中斷的情況。在實驗期間模擬緊急事件發(fā)生次數(shù)共126次，其中聯(lián)防網(wǎng)絡(luò)成功建立次數(shù)為121次，系統(tǒng)穩(wěn)定性約96.03%。分析聯(lián)防網(wǎng)絡(luò)建立失敗的主要原因是Web Portal端的網(wǎng)絡(luò)不穩(wěn)定，造成緊急事件信息無法發(fā)送出去。為改善此問題，在Camera端加一信息序列的設(shè)計，當信息無法以HTTP Get的方式發(fā)送到Web Portal，將會放到此信息序列中再重新發(fā)送。經(jīng)過改善后，系統(tǒng)穩(wěn)定性已達100%。

4 結(jié)論

本文實現(xiàn)了一個家庭聯(lián)合監(jiān)視系統(tǒng)的系統(tǒng)樣機，采用P2P網(wǎng)絡(luò)串流技術(shù)，來節(jié)省監(jiān)視視頻上傳所需的帶寬。本文還設(shè)計了具備監(jiān)視視頻加密功能的安全聯(lián)防網(wǎng)絡(luò)系統(tǒng)，包含金鑰管理和交換機制。同時為了滿足不同成員終端設(shè)備的需求，在Camera端將采用視頻網(wǎng)絡(luò)編碼，將監(jiān)視畫面轉(zhuǎn)換編碼成800×600，640×480和480×360三種不同的分辨力，可以分別在PC、筆記本式計算機和智能手機上顯示。

將來，此家庭聯(lián)合監(jiān)視系統(tǒng)還可以與電信運行公司合作，以綁定促銷等方式將家庭聯(lián)合監(jiān)視系統(tǒng)及增值服務(wù)等推廣到一般家庭，使用者也可根據(jù)個人需求，自助定制追加其他傳感套件及服務(wù)。

[1]梅魯海.一種遠程監(jiān)控的家庭智能化系統(tǒng)設(shè)計[J].電視技術(shù)，2008，32（8）:85-87.

[2]李衛(wèi)，李志純，高強.基于嵌入式的P2P流量監(jiān)控系統(tǒng)的設(shè)計及實現(xiàn)[J].計算機工程與設(shè)計，2012（4）:121-125.

[3]張昱，郝瑩.一種支持結(jié)構(gòu)化P2P網(wǎng)絡(luò)性能優(yōu)化的雙向克隆節(jié)點模型[J].中國通信，2012（4）:368-372.

[4]鐘鋒，陸以勤.基于家庭網(wǎng)關(guān)的嵌入式遠程圖像監(jiān)控系統(tǒng)[J].計算機工程與設(shè)計，2011，32（5）:1626-1629.

[5]張守輝，于會山.家庭智能化網(wǎng)絡(luò)監(jiān)控系統(tǒng)的設(shè)計[J].通信技術(shù)，2011，44（11）:44-48.

[6]丁華，劉文超.運營商開展家庭視頻監(jiān)控業(yè)務(wù)的現(xiàn)狀和未來[J].電信科學(xué)，2008，36（10）:41-45.

[7]鄧光青，危婷，陳常嘉，等.P2P視頻點播系統(tǒng)的服務(wù)質(zhì)量模型[J].北京郵電大學(xué)學(xué)報，2012（2）:245-250.