編者按： 攝像頭是物聯(lián)網(wǎng)世界的眼睛，擁有體積小且節(jié)能的特征，而視頻監(jiān)控一直是跟音視頻緊密結(jié)合的領(lǐng)域，同時成本控制要求嚴苛。傳統(tǒng)的視頻監(jiān)控解決方案陳舊且復雜，不能滿足靈活訪問控制的要求，在視頻大時代的背景下，如何才能適應日益增長的需求呢？攝像頭雖小，但對音視頻秒開、低延遲的要求卻一點都不低；隨著 RTC 的日漸普及，大家對其了解逐漸深入，會發(fā)現(xiàn)并不是只有 WebRTC 才擁有這個特性。本次分享將回顧視頻大時代的發(fā)展脈絡，介紹 P2P 網(wǎng)絡架構(gòu)的協(xié)議擴展，并結(jié)合 RTC 理論，探索在 IoT 視頻監(jiān)控領(lǐng)域上的應用落地實踐。

文 / 張鵬

整理 / LiveVideoStack

大家好，我是張鵬，我來分享一下，對等網(wǎng)絡在物聯(lián)網(wǎng)上的應用，已經(jīng)成功應用到消費級家用攝像頭、智能門鈴 / 門鎖等產(chǎn)品。這次分享主要有 3 個部分，介紹、高效傳輸、總結(jié)，將重點分享我們結(jié)合對等網(wǎng)絡如何在物聯(lián)網(wǎng)上做到極致體驗的。

1、Introduction

在此之前，先介紹一些概念。

首先就是一個網(wǎng)絡拓撲，其實 P2P 算是音視頻領(lǐng)域的一個老朋友了，兩年前我在 LiveVideoStackCon 分享過一次，但當時 P2P 主要是是用來節(jié)省帶寬，放在現(xiàn)在的環(huán)境里依然適用，幫助企業(yè)降本增效。那 P2P 是什么呢？現(xiàn)在流行的 Web3，它的底層網(wǎng)絡就是 P2P，所以 P2P 的應用場景不僅僅是節(jié)省帶寬那么簡單，還有很多場景是可以發(fā)揮。我今天分享的就是 P2P 在 IoT 場景的應用。

再說物聯(lián)網(wǎng)，這個概念已經(jīng)提出好多年了，但大家對物聯(lián)網(wǎng)的規(guī)?？赡苓€不太了解。舉個例子對比一下，微信已經(jīng)有十億的用戶了，但物聯(lián)網(wǎng)的規(guī)模是上百億的，這里面的增長性是很好的，到處都充滿機會。而騰訊又是專注于連接的一家公司，之前是連接人與人、人與服務，連接線上和線下，現(xiàn)在我們把這個連接擴展到連接人與物、設備與設備，把這個連接做得更徹底。

IoT 行業(yè)很大，今天分享的主要是在 IoT Video 行業(yè)，跟 LiveVideoStackCon 音視頻技術(shù)大會的主題也非常相關(guān)。上圖都是一些攝像頭設備，大家對攝像頭應該不陌生，可能已經(jīng)買了一些攝像頭在家里做監(jiān)控。攝像頭是整個物聯(lián)網(wǎng)世界的眼睛，它非常重要，現(xiàn)在有些新興的行業(yè)，比如做機器人的，已經(jīng)把音視頻作為基礎(chǔ)，在此之上做智能化。別小看這些攝像頭，它的要求絲毫不亞于常規(guī)直播，如智慧門鈴、智慧門鎖這些，都要求延遲要在 1 秒以內(nèi)且要絲滑流暢，但這些設備和我們手機相比，無論是算力還是網(wǎng)絡都差遠了，而且對里面能安裝的軟件要求非常苛刻，都是很底層的接入方式。在這基礎(chǔ)上，還要做到低成本、低延遲、秒出圖，挑戰(zhàn)是非常大的。

2、Effective Communication

接下來分享一下，我們是在 IoT 上如何做到音視頻的極致體驗優(yōu)化的。

首先是 P2P，之所以選擇 P2P，考慮的依然是隱私和成本，因為 IoT 非常注重隱私，同時客戶的成本訴求也很強烈，P2P 打洞成功率越高，就越能節(jié)省成本，而 RFC 中的 NAT 劃分、ICE 的打洞方式相對比較古老，在國內(nèi)的打洞成功率并不高。而騰訊的 P2P 依托 QQ、旋風下載、QQ 影音、騰訊視頻、微信等積累，能把打洞成功做到大于 80% 的水平，像端口預測、生日攻擊這些技術(shù)，應有盡有，打洞握手耗時僅 200ms。

P2P 打洞是一個很好的 P2P 入門技術(shù)，它很有技巧性，你了解了以后會猛然發(fā)現(xiàn)，網(wǎng)絡原來還可以這樣玩。比如 TCP 打洞，學過計算機網(wǎng)絡的同學可能知道，有一種 TCP 四次握手機制，兩邊同時去發(fā) SYN 主動連接。在工作的幾年里，我始終沒見到哪兒會用到這種握手，甚至網(wǎng)絡上都要搜不到相關(guān)資料了。后來才發(fā)現(xiàn)，原來是在 TCP 打洞時會用到這種技術(shù)，兩方都是直接連對方，心中一陣暗暗稱奇。

打洞之后，就是傳輸了，節(jié)點可以相互去直連傳輸通信，但如果不受控制的傳輸，是萬萬不行的，所以必須要有傳輸速率控制，流量控制等。早期 P2P 為什么它的名聲比較差，一方面它傳輸?shù)膬?nèi)容侵犯了版權(quán)，另一方面是它無情地搶占了帶寬資源，把網(wǎng)絡搞得很擁擠，給運營商治理網(wǎng)絡造成了很大的困擾，運營商索性就把它封殺了。P2P 之前是這樣一個狀態(tài)，但這是不對的，打洞成功后，一定不能瘋狂地發(fā)數(shù)據(jù)，干這種傻事，而是要和所有其他傳輸協(xié)議一樣，友好、公平地一起利用好網(wǎng)絡。

我們自主研發(fā)的傳輸協(xié)議 ETC，則是將 Pacing 和 Burst 相結(jié)合，因為它們單獨來講都有各自的優(yōu)缺點，ETC 則是綜合這兩者的優(yōu)點，抑制它們彼此的缺點，最終得到了一個能最大程度利用帶寬，延遲低，反應快，友好、公平的效果。如右圖所示，在 100M 的鏈路空間內(nèi)，1 個流的時候要利用到 100M，2 個流的時候每個 50M，5 個流時每個 20M，利用率很高。反應靈敏，帶寬調(diào)整收斂速度快，相比慢啟動而言能一下子利用到 100M，2 個流的時候，一下子各自帶寬調(diào)整到 50M，很公平。因為網(wǎng)絡是實時變化的，這一刻可能 5 個流，每個 20M，下一刻可能就是剩下 4 道流每條 25M，這種就是要能做到立刻感知，也就是不停地探測、調(diào)整，傳輸協(xié)議最好的辦法就是不停地向上探測一下有沒有可用帶寬，超過了就向下調(diào)整一下，以打水漂的方式來回探測，而且在穩(wěn)定態(tài)這個打水飄探測的幅度越小越好，這塊 ETC 做得相當不錯。

有了 P2P 和傳輸之后，接下來要解決低延遲、秒出圖的需求。這里有個前輩 WebRTC，它也有 P2P 和傳輸，又和音視頻結(jié)合，很值得借鑒。

這里想先和大家探討下，WebRTC 是怎么做到低延遲的？我之前聽到最多的一句回答，就是使用了 UDP，但 UDP 和低延遲還差了十萬八千里。也有常見回答說因為使用了 P2P，兩個節(jié)點直連或許會更好一點，比如在同一個內(nèi)網(wǎng)下，但也有時候可能還沒經(jīng)過公網(wǎng)轉(zhuǎn)發(fā)時效果好。

如果對 WebRTC 了解更深刻一點，可能會回答說，因為使用了 RTP/RTCP，或者是因為 WebRTC 有內(nèi)置 TCC 傳輸控制，這是比較好一點的答案了。

如果再對 WebRTC 更了解一點的話，會回答說是因為 WebRTC 有非常優(yōu)秀的 jitter buffer 管理，這已經(jīng)接近標準答案了，但大家對 jitter buffer 可能還是只知概念，不知具體怎么管理的，覺得 jitter buffer 是不是播放器的緩沖區(qū)少了就把它給拉長慢放，緩沖區(qū)多了就快進一些，跳幀追幀，然后是不是就實現(xiàn)低延遲了？那是不是把 jitter buffer 策略挪到 TCP 上實現(xiàn)，TCP 上也能實現(xiàn)低延遲了呢？帶著這些疑問，我們繼續(xù)向下深究。

我們整個行業(yè)，把低延遲的大部分精力放在兩個方向上，第一個是編解碼，如何能更快地編碼出幀來發(fā)送給對方；第二個就是去搞傳輸協(xié)議，認為低延遲和傳輸協(xié)議很相關(guān)。其實我們前面做的直連、P2P、傳輸協(xié)議都已經(jīng)很優(yōu)秀了，但距離低延遲依然有一定差距，為什么呢？編解碼是有一定作用，可是現(xiàn)在編碼性能已經(jīng)很高，基本都是硬件加速，編碼出一幀只需要幾毫秒小幾十毫秒，對 1 秒 2 秒的延遲占比很小，它并不構(gòu)成延遲的主要成因。

要探討這個問題，就要老生常談延遲到底發(fā)生在什么地方。如圖所示，延遲可能發(fā)生在編碼、采集、前處理、端到端延時、解碼、后處理等，這里像編碼、采集、前處理、后處理都是硬件控制的，對延遲不苛刻到百毫米以內(nèi)的話，編解碼和網(wǎng)絡時延的占比對延遲的影響微乎其微，基本就是 10 毫秒量級。距離的影響也不大，雖然深圳到北京肯定要比上海到北京要慢，但基本上也都是 30 毫秒一個 RTT，差不太多。那這里面是什么造成了延遲，我們能控制的又是什么呢？一個是 GOP 的長度，另一個就是大家經(jīng)常忽略的全鏈路的緩沖時長，這個才是重點，最值得關(guān)注。

從 GOP 入手降低延遲，比較典型的就是 HLS 和 LL-HLS。直接降低 GOP 長度，把 TS 切片從 10s 降低到 2s。但這有一點問題，GOP 短了，會影響壓縮效率，所以 GOP 肯定還是大于 2s，那還是有平均 1s 的延遲解決不了。

從緩沖區(qū)入手降低延遲，經(jīng)常的做法就是如果播放器緩沖區(qū)變長，那就快進，兩年前我和一個同事還聊到，標準直播能不能做到低延遲的程度，當時的結(jié)論是可以，配合播放器，播放器如果有緩沖，就去快進，就能實現(xiàn)低延遲，但很少有播放器做這個策略，我們的視立方有做，大家可以試用一下，其實絕大部分情況下也都能滿足。但做了這個之后，有些場景下的延遲效果依然不盡人意，為什么呢？因為忽略了發(fā)送側(cè)的發(fā)送緩沖區(qū)！

如果把 WebRTC 的 jitter buffer 放到 TCP 上去實現(xiàn)的話，TCP 依然做不到低延遲。因為 TCP 發(fā)送端有一個內(nèi)核里的發(fā)送緩沖區(qū)，當網(wǎng)絡變差時，發(fā)送緩沖區(qū)會先填滿，應用層卻控制不了，因為在內(nèi)核里面。此時，應用層還不知道發(fā)送緩沖區(qū)已經(jīng)擁堵了，之后發(fā)送緩沖區(qū)會被填滿，無法寫進，這時應用層的才能感知到，網(wǎng)絡擁堵了，要開始應對了，但這時已經(jīng)晚了。TCP 就是這種，感受網(wǎng)絡的變化太晚了，而且應用層對發(fā)送緩沖區(qū)內(nèi)的數(shù)據(jù)無能為力。

可以看到，產(chǎn)生延遲的另一個重要原因是在發(fā)送端的緩沖區(qū)，這是播放器快進追幀策略鞭長莫及的。再對比一下 RTP 和 RTCP 的是如何解決這個問題的，RTP 和 RTCP 配合 WebRTC 的傳輸從根本上而言是讓傳輸和音視頻的特性緊密的結(jié)合起來，來實現(xiàn)的低延遲。當對端發(fā)現(xiàn)網(wǎng)絡卡的時候，它會通過 RTCP 立即告訴發(fā)送端，網(wǎng)絡差了，數(shù)據(jù)少發(fā)些，因為這時網(wǎng)絡資源變得緊缺了，然而少發(fā)哪些數(shù)據(jù)也是有講究的，不是說把這 1s 的后半秒全都丟了，而是均勻地去丟才好，先把均勻地丟 B 幀，再是均勻地丟 P 幀，它需要發(fā)送端配合做一些決策，或者更直接地降低碼率，讓數(shù)據(jù)依然能均勻地發(fā)送到對端。

總結(jié)一下就是，全鏈路緩沖區(qū)管理防積壓，網(wǎng)絡不足時主動減，減有降碼率和降幀率兩種方法，我們在做物聯(lián)網(wǎng)時，端到端各項參數(shù)都由我們控制，比如幀率 40fps，網(wǎng)絡變差了，我們可以讓發(fā)送端直接變成 20fps。其他場景下，直播可以利用 SVC 編碼，不斷地能把 B 幀 P 幀優(yōu)先丟掉，均勻地去丟幀，也能把幀率降下來。關(guān)鍵還要及時反饋，像 RTCP 一旦網(wǎng)絡變差，可以馬上傳送給接受端，TCP 的弱點就在不能馬上反饋給發(fā)送端，RTCP 就可以根據(jù)視頻幀級別的去反饋，jitter buffer 機制的核心就在這里。

現(xiàn)在知道了低延遲是怎么做的了，那如何擴展到非 WebRTC 場景呢？這里面有幾個難點。第一個在于發(fā)送緩沖區(qū)有多少數(shù)據(jù)未發(fā)送，其實發(fā)送端絲毫不知情，但這里面可能積壓有數(shù)秒的數(shù)據(jù)了，造成的延遲已經(jīng)很高了。第二個難點是播放端要有一個及時反饋的通道，這個通道大部分直播方案是沒有的，唯一的解法，好像只有通過將音視頻的特性和傳輸協(xié)議相結(jié)合的 RTP。RTP/RTCP 將網(wǎng)絡傳輸與音視頻特性相結(jié)合的思路是好的，但很多傳輸協(xié)議卻又是分層的，設計時并不替音視頻應用特性考慮。這里也借此糾正一個誤區(qū)，前段時間遇到個說法 RTMP/HTTP-Flv 等這些都是傳輸層的，其實并不是，他們都是應用層的，比如 RMTP 就感知不到 TCP 的緩沖區(qū)積壓了多少。

以上 2 個難點不好解決，但也并非毫無辦法，主要思路便是通過應用層接管緩沖區(qū)管理?？梢栽趹脤咏⒆约旱膸墑e的隊列，接收端收到一個幀就要向發(fā)送端反饋一個 Ack，此 Ack 非傳輸層的 Ack，而是應用層自己的，這樣就能越過傳輸層，令發(fā)送端能感知到發(fā)送緩沖區(qū)里的幀數(shù)據(jù)是否已經(jīng)傳輸過去。

更具體一點，首先把發(fā)送緩沖區(qū)設置足夠小，接收緩沖區(qū)一有數(shù)據(jù)就馬上讀出來。然后，作為直播應用層協(xié)議的 HTTP GET 請求，是沒有及時反饋通道的；但變成 POST 請求，POST 請求帶請求體的，就可以讓 POST 請求每解析完一幀，就在請求體中寫一行在什么時間點收到了一幀，幀的 pts 是多少，播放器的 buffer 多少，這樣就建立起了一個反饋通道。這個反饋通道完全是應用層的，可以告訴服務器（發(fā)送端)，讓服務器及時調(diào)整。最后，因為發(fā)送端并沒有把很多數(shù)據(jù)寫給發(fā)送緩沖區(qū)，相當于應用層接管了待發(fā)送數(shù)據(jù)的管理權(quán)，所以當網(wǎng)絡變差，發(fā)送端就可以根據(jù) POST 請求的反饋去降幀率 / 碼率，這樣就能夠?qū)崿F(xiàn)低延遲了。

回顧一下直播興起的歷程，其實直播的興起離不開 HTTP。整個音視頻里有很多協(xié)議，這無形中增加了大家進入音視頻行業(yè)的門檻，而 Web 能發(fā)展如此迅速，就是因為它只有一個大家都耳熟能詳?shù)?HTTP 協(xié)議。直播興起的時候，恰逢 HTTP-FLv、HLS 和 DASH 的出現(xiàn)，他們有很明顯的特征，就是都是 HTTP 的，因此能很方便的被接入到互聯(lián)網(wǎng)的任何一個角落，比如瀏覽器，使用 HTTP 發(fā)送請求，就非常 easy，但如果你讓瀏覽器 RTMP 去拉一個直播流就會非常麻煩。像 IoT 這個行業(yè)，它的協(xié)議簇也非常繁雜，但我們覺得如果要把 IoT Video 進一步擴展到互聯(lián)網(wǎng)每個角落，都統(tǒng)一收斂到一個 HTTP 的話，在 HTTP 上又能實現(xiàn)低延遲、低成本、好效果，那無疑是能讓很多人更快進入這個領(lǐng)域。

所以我們整個架構(gòu)是這樣的，底層利用了 IP/IPv6、ICMP、UDP，再做了一層 P2P，在之上的傳輸層，實現(xiàn)了高效可靠傳輸，再上面實現(xiàn)了應用層協(xié)議 HTTP，支撐各種各樣的應用場景。這樣的架構(gòu)最大的好處，就是分層清晰，對開發(fā)者很友好，大家都懂 HTTP，但如果是 WebRTC 這么復雜的東西，想必大家會感到很頭痛。

這樣我們做音視頻攝像頭的場景支持起來就非常的簡單，比如攝像頭是簡單的 HTTP 直播源服務器，手機便是 HTTP 直播客戶端，可以向服務器發(fā)起請求。不僅適用于 1v1 還適用于 1v 多，多人觀看攝像頭搭配 P2P 的方式。在效果上，使用前文講的低延遲之道，延遲也能做到很低。實現(xiàn)低延遲并不一定非要直接采用 WebRTC，更好的方式是把 WebRTC 的理念思想，給學習過來，應用到我們所需的場景中，把它的復雜度降低，才能促進產(chǎn)業(yè)的繁榮。

與 WebRTC 相比，WebRTC 的 P2P 是標準的 ICE，在國內(nèi)的環(huán)境里成功率沒那么高，成本高，WebRTC 也更復雜、更耗 CPU，在 IoT 去集成它是很難的，IoT 本來可用的存儲空間都已經(jīng)非常小，把 WebRTC 弄進去更難，所以它行不通。我們這個則是輕量級的，打洞成功率又高，又通過全鏈路緩沖區(qū)管控實現(xiàn)了很低的延遲，接入也非常簡單，只要懂 HTTP 協(xié)議，就可以輕松地理解使用。

3、Summary

最后總結(jié)一下。首先是低延遲之道，這張圖可以幫大家回答低延遲的關(guān)鍵步驟，除了很快的編解碼，還有經(jīng)常被忽視的、更重要的全鏈路緩沖區(qū)管理。第一步是起播的低延遲，因為我們是做 IoT 的，一開始就是 I 幀，沒有 GOP 的影響，但是如果做直播內(nèi)容分發(fā)，就有 GOP 影響了。起播低延遲處理最好的，應該是騰訊云的快直播 WebRTC，它的起播處理，非常有技巧性，這里因為時間原因就不再具體分享了，有興趣的話可以了解一下騰訊云快直播 WebRTC 產(chǎn)品。第二步就是傳輸協(xié)議的加持，傳輸協(xié)議的延遲，雖然不會影響很大，但還是很重要的，如果你用 TCP 也能做低延遲，但和 WebRTC 的低延遲相比還是差一些。第三步是播放端的反饋通道，要想辦法建立一個通道能及時反饋，播放器每收一幀，就把收幀時長反饋過去。第四步就是延遲保持，服務器和播放器中的緩沖就應該盡量小，大了播放器快進追幀，服務器則通過均勻丟幀降幀率或者降碼率來適配。

我們在 IoT 上還做了很多其他的工作。IoT 的使用場景都是智能硬件，有很多系統(tǒng)，比如 FreeRTOS、展銳 RTOS。我們適配了很多設備，這些設備可以按照統(tǒng)一的協(xié)議和安卓 iOS 互通。還能與小程序互動，直接在微信小程序上看家中攝像頭的直播。和微信小程序打通后，還帶來了其他收益，比如說，能夠把家中攝像頭很容易的分享給其他人，可以利用微信小程序的登錄、分享等諸多功能運營私域流量。

對比一下其他的 IoT Video 接入方式，如 RTMP 或者 H5+WebRTC，我們的優(yōu)勢在于，出圖時間快，延遲低，程序大小可以滿足 IoT 設備的要求，還是熟悉的 HTTP 協(xié)議，接入起來非常簡單，網(wǎng)絡直連率也比 WebRTC 要高，更加隱私同時節(jié)省成本。

以上就是我這次分享的關(guān)于 P2P 在 IoT 領(lǐng)域上的應用。P2P 之前是在內(nèi)容分發(fā)上幫助降本增效節(jié)省成本，做到了跨端，安卓 /iOS/ 小程序都支持，延遲、秒開質(zhì)量效果都很好，現(xiàn)在我們又成功地把這些功能特性拓展到物聯(lián)網(wǎng) IoT 領(lǐng)域，這套產(chǎn)品對用戶網(wǎng)絡和客戶開發(fā)者都很友好。最后，我們致力于將 P2P 和音視頻技術(shù)拓展到更多領(lǐng)域，希望大家共勉，謝謝！