雷鋒網(公眾號：雷鋒網)按：本文作者冼牛，即構科技市場運營總監，香港大學MBA，十年研發經驗，音視頻雲服務技術專家，專注連麥互動直播技術應用研究。 本文系雷鋒網獨家文章。
借《讓子彈飛》中姜文的名言作為開場白：讓子彈飛一會兒。
某名人吐槽說：還要飛一會兒哪？這子彈的延遲也忒大了。
該名人就是鄙人。
為什麼低延遲很重要？
低延遲的子彈可以擊殺敵軍千米之外，低延遲的直播技術可以秒殺粉絲千裡之外。
互動直播技術已經成為直播平臺的標配。沒有互動直播技術的直播平臺無法躋身直播行業第一梯隊。而要獲得互動直播技術，實現低延遲是必須的。
因此低延遲很重要。
那麼，直播技術如何實現低延遲呢？
請允許我根據即構科技直播技術的經驗，和各位分享一下如何實現低延遲。
即構科技的連麥互動直播技術，連麥方的延遲400毫秒，觀看方的延遲1秒左右。目前映客直播，花椒直播，一直播和慄子直播都採用了即構科技的連麥互動直播技術。因此，這個直播技術經驗是經過市場驗證的，是從實操中得來的，而不是單憑理論分析得到的。
一般來說，延遲低於800毫秒， 才能夠在直播中連麥，做一些比較高頻的互動，比如相聲或者談話節目。如果延遲高於800毫秒，在直播中連麥的效果就無法被觀眾接受了。因此，延遲400毫秒的直播技術，是有足夠的餘地去實現連麥互動直播業務的。
要在直播技術中實現低延遲，有一個簡單而要務實的哲學：
1）選擇一條最優的路徑；
2）在這條路徑上做到最優；
3）保持所有路徑優質。
下面我將按照這個思路來論述如何實現低延遲。
選擇一條最優的路徑
要選擇一條最優的路徑，有很多方法。目前使用比較多的是網絡測速，用戶個人連接數據分析，和用戶群體連接數據分析等幾種方法來選擇最優的網絡路徑。
推流端在推流之前，向各個路徑發送簡單的數據包，然後根據數據包響應的時間來推測哪條路徑最快。這個方法比較簡單，有效然而有限：選出來的路徑只是在該測試時間點最快的，而網絡狀況是隨著時間變化的；另外，簡單數據包測出來速度比較快，並不代表流媒體傳輸數據速度也比較快。因此，這個方法得到的結果只能作為一個指標來參考。
為了迴避單個採樣時間點測速導致的偏差，可以採取對歷史大數據進行分析，預測哪個網絡路徑最優。對歷史大數據進行的分析分為兩個維度：用戶個人連接數據分析和用戶群體連接數據分析。
1. 用戶個人連接數據分析
每個主播用戶的使用歷史數據是有規律可循的。通過分析這些歷史數據，可以發現主播用戶從哪裡接入，在什麼時候接入，接入到哪個伺服器，走什麼路徑的效果最優。這些歷史數據積累得越豐富，歷史數據分析得出來的結論就越靠譜。這個方法能夠發現個人主播用戶周期性的網絡連接情況，能找出大部分時間連接效率最優的網絡路徑。然而，這個方法的缺點是：數據採樣只是基於單個用戶，採樣點太少，沒有全局考慮到該用戶所在地區的整體網絡連接情況。
2. 用戶群體連接數據分析
為了彌補用戶個人連接數據分析的不足，這裡引入另外一個維度的數據分析：某地區用戶群體連接數據的分析。針對某用戶所在區域的用戶群進行歷史數據分析，可以發現這個區域網絡連接隨著時間變化的規律，找出在不同的時間點，在不同的接入點連接到哪個伺服器最好。
單點網絡測速，用戶個人連接數據分析，再加上用戶群體連接數據分析綜合得到結論，就能比較有效地預測哪條路徑最優。選路這部分需要不斷地優化，才能積累豐富的用戶數據，同時適應網絡的變化。
在這條路徑上做到最優選好最優的路徑以後，剩下的就是要在該路徑上做到最優。這條路徑包括了下面幾個環節：採集，編碼，推流，轉碼，分發，拉流，解碼和渲染。在一個實時的音視頻系統架構裡，每個環節都會有一定程度的優化空間。行業內的小夥伴在這條路上已經有過很多探索，這裡不想重複討論別人已經探索過的議題，而只重點討論下面幾個關鍵點。
傳輸協議的選擇十分重要。傳輸協議一定程度上就決定了延遲的範圍。選擇傳輸協議的時候要考慮是推流端還是拉流端。推流端的協議有RTMP, WebRTC和基於UDP的私有協議。
1. RTMP是基於TCP的標準協議，CDN網絡普遍支持，也能做到相對比較低的延遲。即構科技的互動直播技術在推流端使用RTMP協議，拉流端兼容三種協議：RTMP，HLS和FLV。HLS協議的延遲比較大，在需要進行連麥互動的場景下，不應該使用HLS協議。
2. WebRTC的好處在於用戶體驗好，不需要安裝東西，分享一個連結就可以看。但是它有一個缺點，就是WebRTC是Google推的一項技術，除了Google Chrome和Opera支持WebRTC，其他瀏覽器大部分不支持WebRTC。
換一句話說，40%的瀏覽器支持WebRTC，剩下60%瀏覽器不支持，所以適用範圍就比較局限。然後，在中國國內，WebRTC在Google Chrome上的表現也大打折扣。最後，因為瀏覽器沒有開放核心的能力，所以在瀏覽器上運行的協議比較難以做到比較低的延遲。
3. 基於UDP的私有協議十分適合做實時音視頻系統，它是面向無連接的，避免了TCP做網絡質量控制所需要的開銷，能夠做到比較低的延遲。但是它也有一個缺點，那就是私有協議的兼容性不好。
CDN支持標準的RTMP協議，但是不支持基於UDP的私有協議。為了吸納UDP的優點，而避免UDP的缺點，即構科技的互動直播技術採用了基於UDP的私有協議作為補充，在有必要的時候用來彌補RTMP協議的不足。比如說，只有在網絡環境比較惡劣或者在跨國互通的情況下，才使用基於UDP的私有協議；比如說，只在推流端到媒體伺服器這一段才使用基於UDP的私有協議，而從媒體伺服器轉推流到CDN網絡這一段採用RTMP協議，在這兩段之間通過把UDP私有協議轉換成RTMP協議來進行適配和銜接。這樣一來，即構科技的直播方案既擁有超低延遲的優勢，又保留了標準協議普遍被CDN網絡支持的好處。
前向糾錯簡稱FEC，英文全稱Forward Error Correction，是通過提前採取措施來對抗網絡損傷。丟包重傳主要針對丟包的情況下，有針對性地對丟失的數據包進行高效率的重傳。準確來說，它們的直接目的不是為了降低延遲，而是為了對抗網絡損傷。在不可預測的網絡環境中，能很好地處理網絡抖動帶來的負面影響，間接也會降低了延遲，同時保證了穩定性和流暢性。
一般來說，前向糾錯和丟包重傳互補使用，前者屬於前驗的方法，比較節省時間，但是佔用多餘的帶寬；後者屬於後驗的方法，比較節省帶寬，但是會消耗比較多的時間。在網絡比較差情況下，丟包率比較高，那麼可以通過前向糾錯方法來保證信息完整送達。比如說發送冗餘信息，確保在一定丟包率之下，接受方也能準確而完整的還原發送方所要發送的信息。在網絡相對比較好的情況下，丟包率比較低，那麼可以通過丟包重傳的方法來保證信息完整送達。比如說針對丟掉的數據包，通過高效的機制進行重傳，確保接受方能夠完整的收到發送方所要發送的消息。
由於有網絡抖動的存在，數據包的到達不是勻速的。
最直接的降低延遲的方法就是把緩衝隊列的長度設置為零，接收到什麼數據包就直接渲染什麼數據包，然而這樣做的後果就是播放不流暢，會出現卡頓。
因此，延遲和流暢兩者本身就是一對矛盾的因素。我們要做的是尋找低延遲和流暢之間的平衡點，尋找平衡點的有效方法就是建立緩衝隊列。在拉流端和混流伺服器都需要建立緩衝隊列。對於一個實時系統來說，緩衝隊列的長度必須不是固定的，而是自適應的：當網絡很好的時候，緩衝隊列的長度就會變得比較短，接近零，甚至為零；當網絡不好的情況下，緩衝隊列的長度會變得比較長，但是不能超過能接受的上限，畢竟緩衝隊列的長度本質上就是延遲的時間。
另外，還可以把緩衝自適應技術和快播或慢播技術結合起來使用。當網絡由差轉好的情況下，可以適當的播得快一點，儘快縮短緩衝隊列的長度。當網絡由好轉差的情況下，可以適當的播得慢一點，讓緩衝隊列適當變長，保持流暢性。快播和慢播是結合觀眾的心理學模型，在適合快播和慢播的條件下採用，讓觀眾沒有覺察出播放速度的變化，同時整體感覺也顯得既流暢又低延遲。
由於網絡環境的複雜多變，碼率要能自動適應網絡狀況的變化，也就是所謂的碼率自適應。 在網絡比較差的時候，要降低碼率，讓直播保持低延遲和流暢性；在網絡比較好的時候，要提高碼率，讓直播保持高清畫質。為了做到碼率自適應，對協議選擇也很考究。RTMP對碼率自適應能做的事情比較有限，因為它基於TCP, 而TCP 下層已經做了網絡質量控制，當網絡出現擁塞的時候，上層應用不會及時得到通知。基於UDP的私有協議更加適合做碼率自適應，因為它基於UDP，而UDP只負責發包和收包，把網絡質量控制交給應用層來做，這樣應用層會有足夠的空間來實現碼率自適應。
保持所有路徑優質那麼，為了在直播技術中實現低延遲，要選擇一條最優路徑，還要在該路徑上做到最優。故事講完了嗎？沒有，我們忘記了一個前提：整體的道路網絡必須要足夠好。道路網絡不好，怎麼選都是爛泥土路，選了爛泥土路，如何能夠跑的快呢？因此，要實現低延遲，網絡基建必須要足夠好。網絡基建的質量可以通過以下三個方面來提高：
一般來說，音視頻雲服務的機房會分布在核心的幾個樞紐城市，邊遠地區的用戶的訪問質量是得不到保障的。另外，在中國國內，各個網絡運營商的覆蓋面是參錯不齊的，有些網絡運營商對一些邊遠地區也是覆蓋不足的。為了做到全網充分覆蓋，可以採用多節點代理和重定向，來確保全網充分覆蓋無盲點。這個需要經過實際充分測試，才能夠驗證各類網絡可以充分連通。
網絡接入點的覆蓋面對QoE（Quality of Experience）十分的重要。從即構的經驗來看，通過部署遍布全球範圍的接入點能夠確保這一點。另外，由於在中國國內存在有「兩張大網，多張小網」這樣一個局面，BGP在這種情況下十分有必要。BGP能夠很好地解決不同網絡之間的互通問題。即構所有的網絡接入點都使用了BGP。
音視頻雲服務是跑在網絡基建上面的，下層網絡基建的質量必須要優質，而且音視頻雲服務和下層網絡基建也要深度結合。為了實現直播技術的低延遲，最好能對接一線的網絡運營商，這樣部署的網絡節點資源無論是數量還是質量上都是有充分的保障。這也是即構團隊在過去十多年海量用戶運營的過程中總結出來的經驗。
綜合來說，要實現直播技術低延遲，必須要選好一條最優的路徑，然後在該路徑上做到最優，最後要確保所有路徑的質量都是好的。道理就是那麼簡單，實現起來就是那麼難，魔鬼都出在細節上。
雷鋒網原創文章，未經授權禁止轉載。詳情見轉載須知。