雷鋒網按：本文作者冼牛，即構科技市場運營總監(jiān)，香港大學MBA，十年研發(fā)經驗，音視頻云服務技術專家，專注連麥互動直播技術應用研究。 本文系雷鋒網獨家文章。

借《讓子彈飛》中姜文的名言作為開場白：讓子彈飛一會兒。

某名人吐槽說：還要飛一會兒哪？這子彈的延遲也忒大了。

 該名人就是鄙人。

為什么低延遲很重要？

低延遲的子彈可以擊殺敵軍千米之外，低延遲的直播技術可以秒殺粉絲千里之外。

互動直播技術已經成為直播平臺的標配。沒有互動直播技術的直播平臺無法躋身直播行業(yè)第一梯隊。而要獲得互動直播技術，實現低延遲是必須的。

因此低延遲很重要。

那么，直播技術如何實現低延遲呢？

 請允許我根據即構科技直播技術的經驗，和各位分享一下如何實現低延遲。

 即構科技的連麥互動直播技術，連麥方的延遲400毫秒，觀看方的延遲1秒左右。目前映客直播，花椒直播，一直播和栗子直播都采用了即構科技的連麥互動直播技術。因此，這個直播技術經驗是經過市場驗證的，是從實操中得來的，而不是單憑理論分析得到的。

 一般來說，延遲低于800毫秒， 才能夠在直播中連麥，做一些比較高頻的互動，比如相聲或者談話節(jié)目。如果延遲高于800毫秒，在直播中連麥的效果就無法被觀眾接受了。因此，延遲400毫秒的直播技術，是有足夠的余地去實現連麥互動直播業(yè)務的。

要在直播技術中實現低延遲，有一個簡單而要務實的哲學：

1）選擇一條最優(yōu)的路徑；

2）在這條路徑上做到最優(yōu)；

3）保持所有路徑優(yōu)質。

下面我將按照這個思路來論述如何實現低延遲。 

選擇一條最優(yōu)的路徑

要選擇一條最優(yōu)的路徑，有很多方法。目前使用比較多的是網絡測速，用戶個人連接數據分析，和用戶群體連接數據分析等幾種方法來選擇最優(yōu)的網絡路徑。

• 網絡測速

推流端在推流之前，向各個路徑發(fā)送簡單的數據包，然后根據數據包響應的時間來推測哪條路徑最快。這個方法比較簡單，有效然而有限：選出來的路徑只是在該測試時間點最快的，而網絡狀況是隨著時間變化的；另外，簡單數據包測出來速度比較快，并不代表流媒體傳輸數據速度也比較快。因此，這個方法得到的結果只能作為一個指標來參考。

• 大數據分析

為了回避單個采樣時間點測速導致的偏差，可以采取對歷史大數據進行分析，預測哪個網絡路徑最優(yōu)。對歷史大數據進行的分析分為兩個維度：用戶個人連接數據分析和用戶群體連接數據分析。

1. 用戶個人連接數據分析

每個主播用戶的使用歷史數據是有規(guī)律可循的。通過分析這些歷史數據，可以發(fā)現主播用戶從哪里接入，在什么時候接入，接入到哪個服務器，走什么路徑的效果最優(yōu)。這些歷史數據積累得越豐富，歷史數據分析得出來的結論就越靠譜。這個方法能夠發(fā)現個人主播用戶周期性的網絡連接情況，能找出大部分時間連接效率最優(yōu)的網絡路徑。然而，這個方法的缺點是：數據采樣只是基于單個用戶，采樣點太少，沒有全局考慮到該用戶所在地區(qū)的整體網絡連接情況。

2. 用戶群體連接數據分析

為了彌補用戶個人連接數據分析的不足，這里引入另外一個維度的數據分析：某地區(qū)用戶群體連接數據的分析。針對某用戶所在區(qū)域的用戶群進行歷史數據分析，可以發(fā)現這個區(qū)域網絡連接隨著時間變化的規(guī)律，找出在不同的時間點，在不同的接入點連接到哪個服務器最好。

單點網絡測速，用戶個人連接數據分析，再加上用戶群體連接數據分析綜合得到結論，就能比較有效地預測哪條路徑最優(yōu)。選路這部分需要不斷地優(yōu)化，才能積累豐富的用戶數據，同時適應網絡的變化。

在這條路徑上做到最優(yōu)

選好最優(yōu)的路徑以后，剩下的就是要在該路徑上做到最優(yōu)。這條路徑包括了下面幾個環(huán)節(jié)：采集，編碼，推流，轉碼，分發(fā)，拉流，解碼和渲染。在一個實時的音視頻系統(tǒng)架構里，每個環(huán)節(jié)都會有一定程度的優(yōu)化空間。行業(yè)內的小伙伴在這條路上已經有過很多探索，這里不想重復討論別人已經探索過的議題，而只重點討論下面幾個關鍵點。

• 選擇協(xié)議

傳輸協(xié)議的選擇十分重要。傳輸協(xié)議一定程度上就決定了延遲的范圍。選擇傳輸協(xié)議的時候要考慮是推流端還是拉流端。推流端的協(xié)議有RTMP, WebRTC和基于UDP的私有協(xié)議。

1. RTMP是基于TCP的標準協(xié)議，CDN網絡普遍支持，也能做到相對比較低的延遲。即構科技的互動直播技術在推流端使用RTMP協(xié)議，拉流端兼容三種協(xié)議：RTMP，HLS和FLV。HLS協(xié)議的延遲比較大，在需要進行連麥互動的場景下，不應該使用HLS協(xié)議。

2. WebRTC的好處在于用戶體驗好，不需要安裝東西，分享一個鏈接就可以看。但是它有一個缺點，就是WebRTC是Google推的一項技術，除了Google Chrome和Opera支持WebRTC，其他瀏覽器大部分不支持WebRTC。

換一句話說，40%的瀏覽器支持WebRTC，剩下60%瀏覽器不支持，所以適用范圍就比較局限。然后，在中國國內，WebRTC在Google Chrome上的表現也大打折扣。最后，因為瀏覽器沒有開放核心的能力，所以在瀏覽器上運行的協(xié)議比較難以做到比較低的延遲。

3. 基于UDP的私有協(xié)議十分適合做實時音視頻系統(tǒng)，它是面向無連接的，避免了TCP做網絡質量控制所需要的開銷，能夠做到比較低的延遲。但是它也有一個缺點，那就是私有協(xié)議的兼容性不好。

CDN支持標準的RTMP協(xié)議，但是不支持基于UDP的私有協(xié)議。為了吸納UDP的優(yōu)點，而避免UDP的缺點，即構科技的互動直播技術采用了基于UDP的私有協(xié)議作為補充，在有必要的時候用來彌補RTMP協(xié)議的不足。比如說，只有在網絡環(huán)境比較惡劣或者在跨國互通的情況下，才使用基于UDP的私有協(xié)議；比如說，只在推流端到媒體服務器這一段才使用基于UDP的私有協(xié)議，而從媒體服務器轉推流到CDN網絡這一段采用RTMP協(xié)議，在這兩段之間通過把UDP私有協(xié)議轉換成RTMP協(xié)議來進行適配和銜接。這樣一來，即構科技的直播方案既擁有超低延遲的優(yōu)勢，又保留了標準協(xié)議普遍被CDN網絡支持的好處。

• 前向糾錯和丟包重傳

前向糾錯簡稱FEC，英文全稱Forward Error Correction，是通過提前采取措施來對抗網絡損傷。丟包重傳主要針對丟包的情況下，有針對性地對丟失的數據包進行高效率的重傳。準確來說，它們的直接目的不是為了降低延遲，而是為了對抗網絡損傷。在不可預測的網絡環(huán)境中，能很好地處理網絡抖動帶來的負面影響，間接也會降低了延遲，同時保證了穩(wěn)定性和流暢性。

一般來說，前向糾錯和丟包重傳互補使用，前者屬于前驗的方法，比較節(jié)省時間，但是占用多余的帶寬；后者屬于后驗的方法，比較節(jié)省帶寬，但是會消耗比較多的時間。在網絡比較差情況下，丟包率比較高，那么可以通過前向糾錯方法來保證信息完整送達。比如說發(fā)送冗余信息，確保在一定丟包率之下，接受方也能準確而完整的還原發(fā)送方所要發(fā)送的信息。在網絡相對比較好的情況下，丟包率比較低，那么可以通過丟包重傳的方法來保證信息完整送達。比如說針對丟掉的數據包，通過高效的機制進行重傳，確保接受方能夠完整的收到發(fā)送方所要發(fā)送的消息。

• 緩沖自適應

由于有網絡抖動的存在，數據包的到達不是勻速的。

最直接的降低延遲的方法就是把緩沖隊列的長度設置為零，接收到什么數據包就直接渲染什么數據包，然而這樣做的后果就是播放不流暢，會出現卡頓。

因此，延遲和流暢兩者本身就是一對矛盾的因素。我們要做的是尋找低延遲和流暢之間的平衡點，尋找平衡點的有效方法就是建立緩沖隊列。在拉流端和混流服務器都需要建立緩沖隊列。對于一個實時系統(tǒng)來說，緩沖隊列的長度必須不是固定的，而是自適應的：當網絡很好的時候，緩沖隊列的長度就會變得比較短，接近零，甚至為零；當網絡不好的情況下，緩沖隊列的長度會變得比較長，但是不能超過能接受的上限，畢竟緩沖隊列的長度本質上就是延遲的時間。

另外，還可以把緩沖自適應技術和快播或慢播技術結合起來使用。當網絡由差轉好的情況下，可以適當的播得快一點，盡快縮短緩沖隊列的長度。當網絡由好轉差的情況下，可以適當的播得慢一點，讓緩沖隊列適當變長，保持流暢性?？觳ズ吐ナ墙Y合觀眾的心理學模型，在適合快播和慢播的條件下采用，讓觀眾沒有覺察出播放速度的變化，同時整體感覺也顯得既流暢又低延遲。

• 碼率自適應

由于網絡環(huán)境的復雜多變，碼率要能自動適應網絡狀況的變化，也就是所謂的碼率自適應。 在網絡比較差的時候，要降低碼率，讓直播保持低延遲和流暢性；在網絡比較好的時候，要提高碼率，讓直播保持高清畫質。為了做到碼率自適應，對協(xié)議選擇也很考究。RTMP對碼率自適應能做的事情比較有限，因為它基于TCP, 而TCP 下層已經做了網絡質量控制，當網絡出現擁塞的時候，上層應用不會及時得到通知。基于UDP的私有協(xié)議更加適合做碼率自適應，因為它基于UDP，而UDP只負責發(fā)包和收包，把網絡質量控制交給應用層來做，這樣應用層會有足夠的空間來實現碼率自適應。

保持所有路徑優(yōu)質

那么，為了在直播技術中實現低延遲，要選擇一條最優(yōu)路徑，還要在該路徑上做到最優(yōu)。故事講完了嗎？沒有，我們忘記了一個前提：整體的道路網絡必須要足夠好。道路網絡不好，怎么選都是爛泥土路，選了爛泥土路，如何能夠跑的快呢？因此，要實現低延遲，網絡基建必須要足夠好。網絡基建的質量可以通過以下三個方面來提高：

• 全網充分覆蓋

一般來說，音視頻云服務的機房會分布在核心的幾個樞紐城市，邊遠地區(qū)的用戶的訪問質量是得不到保障的。另外，在中國國內，各個網絡運營商的覆蓋面是參錯不齊的，有些網絡運營商對一些邊遠地區(qū)也是覆蓋不足的。為了做到全網充分覆蓋，可以采用多節(jié)點代理和重定向，來確保全網充分覆蓋無盲點。這個需要經過實際充分測試，才能夠驗證各類網絡可以充分連通。

• 全方位保障QoE

網絡接入點的覆蓋面對QoE（Quality of Experience）十分的重要。從即構的經驗來看，通過部署遍布全球范圍的接入點能夠確保這一點。另外，由于在中國國內存在有“兩張大網，多張小網”這樣一個局面，BGP在這種情況下十分有必要。BGP能夠很好地解決不同網絡之間的互通問題。即構所有的網絡接入點都使用了BGP。

• 優(yōu)質的網絡節(jié)點資源

音視頻云服務是跑在網絡基建上面的，下層網絡基建的質量必須要優(yōu)質，而且音視頻云服務和下層網絡基建也要深度結合。為了實現直播技術的低延遲，最好能對接一線的網絡運營商，這樣部署的網絡節(jié)點資源無論是數量還是質量上都是有充分的保障。這也是即構團隊在過去十多年海量用戶運營的過程中總結出來的經驗。

綜合來說，要實現直播技術低延遲，必須要選好一條最優(yōu)的路徑，然后在該路徑上做到最優(yōu)，最后要確保所有路徑的質量都是好的。道理就是那么簡單，實現起來就是那么難，魔鬼都出在細節(jié)上。

雷峰網原創(chuàng)文章，未經授權禁止轉載。詳情見轉載須知。