摘要：為了處理解決這個問題，需要提高海外直播的接流覆蓋率，并針對鏈路進行優化，從而有效降低整體從推流到拉流的卡頓率。

今天主要分享我們海外直播鏈路優化的問題和解決問題的一個思路，介紹的主要流程，大概就是拋出一個問題，簡單介紹我們解決的思路，在這個過程中碰到的一些問題和我們具體進行的一些思考，以及后續可以再進行一些額外優化的處理。

在介紹整體內容之前，首先定義一下我們的性能指標，由于我們暫時不考慮實時性，所以主要考慮的是卡頓率。卡頓指的就是觀眾在播放一個視頻的時候，由于網絡原因，播放器緩沖區中沒有接收到新的數據數據了，這個時候畫面就一直轉圈，然后一直等待新數據的到來，這時候就無法播放。

網易云對卡頓有兩種衡量指標，一種是實時卡頓率，以秒級為單位，如果播放器緩沖區空了，這一秒就記為卡頓，總卡頓率的計算方法就是直播卡頓的秒數除以總直播秒數；但是通常我們還會用另一種卡頓率的指標，也是以秒級為單位，但是觀察的不是單純一秒之內的卡頓，我們考慮的是連續兩秒卡頓，這個時候用戶會非常明顯的感覺到播放異常，此外，卡頓的出現一般也不會是跳躍式的卡頓，如第一秒卡，第三秒卡，第五秒卡這樣，因此兩秒內連續卡頓發生，我們就標記整分鐘卡頓，這個的總卡頓率就是一個直播卡頓的總分鐘除以總的直播時間。一般來說選擇一分鐘卡頓率這種指標會比較嚴格一點，因為它更可以直觀反映出用戶體驗。

網易云提供了一個平臺級融合 CDN 的服務，主要針對企業級用戶提供解決方案，其中包括使用我們的 SDK，或者繞過我們的 SDK 直接使用推流器進行推流。我們今天探討的海外推流的問題，主要場景是我們當時接入了網易新聞的業務，在聯合開發的過程中，發現當一些主播在國外進行推流，而觀眾卻是在國內的這種場景下，卡頓率就會非常的高，經常就在轉圈，甚至有些就直接拉不到了，用戶體驗極差。為了處理解決這個問題，需要提高海外直播的接流覆蓋率，并針對鏈路進行優化，從而有效降低整體從推流到拉流的卡頓率。

原因分析

首先分析一下原因，當直接使用 CDN 資源時，但是有些 CDN 廠商在國外是沒有部署源站的，這個時候主播推流會直接傳回國內源站，但是一般來說主播的網絡都不是特別好，國外鏈路到國內源站這段鏈路質量一般都是比較差的，此外由于 RTMP 流是基于 TCP 可靠傳輸的所以在鏈路很差的時候，TCP 反映會更劇烈，這樣在主播到國內源站這一段時間內就已經發生非常大的一個卡頓，不管從國內源站到其的邊緣節點延遲有多低，這個時候觀眾拉到的流一定都是卡的。

還有一種場景是部分 CDN 廠商在國外是有一些源站的，但是他們在源站和自己國內的節點之間沒有進行相應的鏈路優化，這個時候從國外源站一直到下發到邊緣節點的這一段過程，網絡傳輸效果較差，相當于只是把主播到國內源站的這一段推流過程放到了網絡傳輸的中間一公里，以上是出現問題的主要兩種場景。

對于不同的 CDN 廠商，有一些是有國外源站覆蓋的，但是仍有一些 CDN 廠商跟國外主播是完全沒有辦法接流的。對于有國外部署源站的廠商，如果覆蓋率不夠，不能滿足客戶分布需求的話，它只能解決一部分場景，比如解決一些比較熱門的城市，但是這些熱門城市并不一定是主播比較集中的地點，而主播集中的地點它反而可能沒有辦法完全的覆蓋到，這種場景下依靠 CDN 自身的源站能解決的卡頓問題是比較少的。

解決思路

針對于這個問題，網易云通過自建 CDN 源站節點來處理這種場景，因為用戶上行節點推流一般網絡狀況都不一樣，有WiFi、4G，我們需要通過自建 CDN 先把主播的流接過來，然后再通過自建的 CDN 和回國鏈路之間進行中間一公里的一些優化，來徹底解決這個問題。但是部署節點也有一個比較麻煩的問題，就是成本和性能，如果選擇了一個源站覆蓋密度非常高，這個時候用戶體驗肯定會好很多，但是你的成本也就特別高，而且你的主播也并不是一定會用到所有的節點，容易造成資源的浪費；相反，源站覆蓋密度比較粗，那主播的問題就很有可能并沒有得到解決，成本還是浪費了。

因此需要在成本和性能之間找到一個比較好的平衡點。我們首先根據一年多以來的歷史數據，進行分析，選擇海外主播密度較高的幾個主要區域進行一定規模數量的節點部署，完成后我們需要針對這些節點進行相應的質量評估，評估這些節點是否有能力承載我們的這些訴求。除此以外，我們還可以進行一些相應的優化，比如說如果是使用一些第三方云服務云主機，我們是可以用他們之間的一些專線來進行鏈路調度上額外的優化；最后一點是分布式系統必須要經常考慮的一個問題，就是節點的高可用。

這是我們整個的流程圖，主播要開始推流的時候，會先登錄云管理中心去請求一個推流列表，推流列表經過云調度中心去把這個推流地址轉換成一個實際推流的源站 IP，云調度中心主要分成兩塊，一塊是中心調度，是實時的，能實時監控所有的源站；還有一塊是基于 DNS，因為網易云業務本身有不少第三方的推流用戶，這種場景是不經過中心調度的，因此我們需要擁有一個 DNS 調度中心，在這兩個調度背后還隱藏著一個大數據平臺，大數據平臺在整個解決問題的過程中發揮一個比較大的作用：所有的數據，包括推流和拉流，這些數據都會匯總到統計平臺上，統計平臺最后就會完成鏈路調度的選優。當主播獲取到這個相應的IP以后，會推流到自建的海外 CDN 源站然后走回到國內源站，在國內還可以利用融合 CDN 的優勢來通過不同的 CDN 網絡進行分發，便于不同的觀眾從質量較好的邊緣節點進行拉流觀看。

1、源站部署

源站部署是自建 CDN 的第一步，主要是借用第三方云服務廠商的云主機。第一步就是要在成本和性能之間做一個平衡，首先，我們利用統計平臺去分析之前將近一年的所有主播推流的數據，比如 IP 分布和一些推流數據的測量，篩選出主播最常用的一些地點，并把源站按照這些地域的熱度進行分布，并多選擇一些節點作為備選，以便后面能進行一些更好的測評。在完成節點部署以后，就需要對這些節點進行測評，測評主要分為兩部分：一部分是上行鏈路質量的測試，還有一部分是中間一公里傳輸的測試。在上行鏈路數據的收集，我們額外花了三個月的時間專門用來對這些源站進行鏈路數據收集，首先先過濾掉一部分性能完全都跟不上的節點，然后會在源站服務器上進行一個比較長時間的模擬推流，并在國內進行拉流，把所有數據匯總到了大數據平臺，最后根據大數據平臺上反饋的數據結果，結合上行數據，整合出一套調度方案。

這套調度方案不單純是基于區域，也會額外考慮收集到的這些數據，并賦予一定的權重，比如說有些是屬于比較偏遠省份的邊緣數據，可以對其進行一些額外的細化，根據調度數據選擇最合適的調度點，不一定是物理上所屬的那種區域概念。

2、智能調度

除了上面說的，我們還可以依托于云服務廠商的一些專線服務，根據我們自己部署在上面的一些測試腳本，對這些源站進行分級和分類，類似于 CDN 架構中的父節點和邊緣節點，在這些節點之間根據它的分級進行一個級聯型的調度，并測試級聯傳輸效率，級聯調度并不會造成額外的延遲，但是在合適的鏈路選擇下傳輸優化效果非常明顯，可以非常有效的降低相應的卡頓率。

這是新方案的流程，從主播推流再到中心調度這塊跟前面都是一樣的，唯一不同的是在源站接入節點以后，并不會直接推到國內的源站，而會根據配置的調度方案，在圖里面實線和虛線相當于是兩套調度方案，我們可以根據這兩套調度方案它的性能進行評估，然后進行一個相應的選入過程，在選擇一個最優質的鏈路調度以后，將它推回到國內源站，再通過我們的融合 CDN 進行分發。

這張圖是我們整體評估出來的一個測試結果，測試結果上面來看：我們的數據整體來說已經比原來 CDN 廠商要好很多，大部分都能優化將近一半以上。

3、高可用覆蓋

對于高可用來說， GSLB 是一個實時調度方案，它能實時和所有的源站服務器進行保活，還有它相應的數據收集功能，因此它是可以做到實時高可用的。但是對于一些第三方的推流用戶來說，他們的 DNS 并不屬于實時調度的，可能會有一些緩存，因此我們需要對 DNS 覆蓋下的所有服務器進行其他高可用方案，我們主要采用的是 keepalived 方案，進行一個高可用的保證，keepalived 可以使用多機器根據虛IP的漂移實現不同機制之間的組配切換。

后續優化

當然我們雖然做了這些，但其實后面還有很多要處理的東西，比如現在針對的產品是國外的推流用戶和國內的拉流用戶，但實際上還有一批用戶，觀眾并不在國內，這個時候我們還是需要對下行鏈路進行一個相應的處理，使其可以直接從國外繞出去，并不需要從國內再特地走一圈。此外我們還可以針對這種實時的鏈路質量進行更高精度的智能調度，我們現在也有收集實時數據，但調度還不是非常實時的處理，我們后續還可以根據這些鏈路數據進行一個比較實時的調度方案的智能選擇。

隨著音頻處理和壓縮技術的不斷發展，效果更好、適用范圍更廣、性能更高的算法和新的技術必將不斷涌現，如果你有好的技術或者分享，歡迎關注網易 MC 官方博客以及微信公眾號：

關注更多技術干貨內容：網易云信博客
歡迎關注網易云信 GitHub
歡迎關注網易云信官網
官網微信公眾號：