海外弱網下的在線視頻平臺優化實踐

**
文 / 張亮**

整理 / LiveVideoStack

你們好，我是四達時代的研發總監張亮，本次分享的內容是基於四達時代在非洲作在線視頻服務時所遇到的一些問題和一些優化的經驗。你們都知道，非洲的網絡環境很是複雜，甚至能夠說幾乎沒有比非洲更差的網絡環境了，所以咱們這裏介紹的是一個比較極端的狀況，僅供你們參考。

分享的內容主要分爲三部分。首先是對StarTimes On App的簡單介紹，由此引出咱們的產品到底應該關心哪些指標，優化必需要明確最核心的目的，想一塊兒優化全部的指標確定是不可行的。第二部分會列出一些實際數據讓你們瞭解非洲的實際網絡狀況。第三部分會重點和你們分享在如此極端的網絡環境下咱們具體採用了哪些優化方式、方法，並最終取得了怎樣的效果。

1 StarTimes On APP 簡介

也許以前你們不太瞭解四達時代，由於咱們主要的業務是在非洲作電視運營。在非洲，四達時代能夠說是一家家喻戶曉的公司，咱們已經在非洲耕耘了十四年，在四十五個非洲國家作運營，目前已經擁有超過1000萬的付費電視用戶，因此咱們的總體收入規模和影響力仍是具有必定水平的。同時咱們也是「萬村通」項目的實施方，這是咱們國家「一帶一路」中的一個重要項目。

1.1 StarTimes On APP

StarTimes On 這個APP作的比較晚，直到2017年才上線，上線直接面臨的就是2018年世界盃的考驗。最初咱們對於非洲的網絡環境有多差是沒有做心理準備的，只是從APM廠商那裏得到了一些數據，但實際真實的數據比拿到的數據還要差的多，所以在世界盃的轉播過程當中仍是出現了一些問題，不過好在咱們都及時想辦法解決掉了。

如今，StarTimes On 已經基本上具備必定的知名度，在Google Play娛樂板塊上也一直是名列前茅。

1.2 商業模式與運營指標

從APP的商業模式上能夠找到咱們的核心指標。首先，咱們的內容都是版權內容。用戶分爲兩類，一類是免費用戶，另外一類是付費用戶。

免費用戶觀看視頻須要看廣告，廣告會給咱們帶來收入。免費用戶看VIP內容則有限制，只能試看三分鐘。因此咱們的運營指標就是免費用戶看了多少視頻，由於觀看視頻就意味着廣告播放的增長，其次播放次數多則意味着更有潛力成爲付費用戶。

對於付費用戶來講咱們的收入來源是訂閱費，付費用戶不須要看廣告，全部的內容權益也相應解鎖。所以對於付費用戶，咱們則重點關注用戶觀看視頻的數量和觀看的時長。看得多、看得久就表明滿意度高，滿意度高就會繼續付費，因此這是咱們運營上的指標。

有了運營指標的要求，咱們就能夠進一步拆解指標，從技術角度上進行分析，哪些地方須要優化。運營指標能夠拆解成觀看視頻數量與觀看視頻時長。

觀看視頻數量很容易理解，若是視頻啓動失敗了，觀看數量天然也就會下降，而若是每次打開視頻都能成功，都能順利看到第一幀，那就是一個好的結果。因此QoE部分咱們就會關注用戶的主動退出率，用戶爲何會主動退出，大部分狀況都是由於等待的時間過久，好比用戶等待的時間超過8秒鐘，那可能大部分用戶都會選擇退出。QoS角度則會關注首屏時間，就是首屏時間越快、越小，主動退出率越低。

觀看時長有兩種度量方法。對於電視劇、電影，咱們會關注用戶觀看時長佔視頻總時長的比例。若是是直播頻道，則關注觀看的時間長度。影響用戶觀看時長最核心的QoS因素是卡頓。用戶廣泛會有一個心理預期，例如看一部電影，能夠容忍視頻卡三次，若是出現太屢次卡頓用戶可能就會放棄觀看。

通過以上分析，咱們能夠導出此業務模式下最核心的兩個QoS指標：首屏時間和卡頓比。以前和不少同窗交流，有不少作互動、RTC方面的同窗會更多關注延遲，可是在咱們這個業務模式下延遲並不須要特別關注。後面會介紹到，咱們還會有一些優化策略是經過犧牲延遲來得到其它收益。

2 非洲網絡情況與挑戰

接下來和你們說一下非洲網絡的真實狀況。

2.1 非洲網絡基本狀況

首先，你們看數據圖中的南非，南非算得上是一箇中等發達國家，網絡狀況還算能夠。南非到歐洲CDN的延遲在閒時約爲100多毫秒，忙時200毫秒，這其實還算能夠。但若是往西邊看，尼日利亞、加納、科特等一些國家就糟糕多了。像尼日利亞，在忙時的RTT能超過600毫秒。這意味着咱們在作任何網絡操做的時候，哪怕是下載一個字節的文件，也須要600毫秒的等待，由於網絡一來一去硬指標就在那裏。若是咱們業務上的後臺放在歐洲，那麼執行任何操做都須要600毫秒的延遲，很是影響用戶的體驗。

而東邊像肯尼亞、烏干達、坦桑尼亞其實網絡狀況也不太好。在國內，若是最北邊地區的用戶訪問最南邊地區的機房花幾十毫秒，已經能夠算做比較慢了，而在非洲動輒就是幾百毫秒，他們的網絡狀況相比國內差十倍甚至幾十倍，這也就意味着咱們面臨的是一個艱鉅的挑戰。

下面是丟包率，丟包問題如今更嚴重。近期咱們收集過一次數據，相比於疫情前，丟包率呈現翻倍的狀況。受疫情影響，你們會更多使用手機流量，而非洲的帶寬資源又很是不足，因此丟包狀況變得更加嚴重。如圖中所示，在高峯期丟包率會有24~25%左右，在這樣的丟包率的狀況下，下載速度是確定上不去的。

再來看其它的一些指標，建連的成功率有80%，指標相對比較穩定，5次裏會失敗1次。咱們會經過長鏈接緩解建連失敗的影響，但長鏈接也會出現斷連，因此不少時候仍然須要重連。DNS解析時間也很長，要1秒左右，數據都比較差勁。

視頻封裝咱們使用的是HLS協議，CDN上有大量M3U8索引文件和視頻切片文件。索引文件大小几百個字節，下載這樣一個文件可能須要10002000毫秒。視頻切片下載速度在200400kbps左右。以上就是非洲目前的網絡狀況。

2.2 問題發生的緣由

接下來咱們簡單梳理下非洲的網絡問題究竟出如今哪裏，只有定位了問題所在，才能夠更好地探索優化的思路。

非洲網絡丟包率很高，延遲很大。丟包的產生有不少緣由，這裏我列了兩個比較主要的：一個是無線接入網丟包，由於在非洲網絡資源（接入網）是很是不足的，雖然你們都使用3G，也有部分的4G基站，可是基站數量太少，若是你們同一時段一塊兒使用的話，基站資源明顯是不夠的。因此高峯期信號弱、小區切換會有不少問題，這就會致使數據包丟掉。另外一個緣由是擁塞，不論在非洲哪一個國家擁塞都是很是嚴重的，擁塞在運營商的出口方面會體現的很是明顯。若是網絡一直處於擁堵的狀態，但你們還在大量發送包，或者去請求包，那最後大機率就是丟包。

延遲能夠分爲幾類，像傳輸延遲和處理延遲等。排隊延遲說到底仍是和擁塞有關係，若是網絡擁塞的很厲害，那中間的交換機，路由器都要排隊，排隊會花費更多的時間。通過實際分析咱們發現：排隊延遲是最主要的問題。重發延遲是指丟包以後從新發包帶來的延遲，從應用層的角度看，這也是一種延遲。

在瞭解了非洲網絡延遲與丟包的狀況後，咱們想定位一下這些問題究竟發生在哪一個環節，隨後再去尋找相應的解決辦法。上圖是從手機發送請求到最後IDC中的服務器收到並響應的過程。一開始用戶的手機須要先鏈接基站，向基站發送無線信號，基站內部處理後，把網絡的請求經過運營商的互聯網出口傳出，隨後有一個更大的互聯網，但其實這裏面有不少層網絡供應商，最終送到了IDC，以上全部的環節均可能發生問題。

最初咱們想經過MTR或者Ping這些工具來診斷問題，但在實際操做中發現，若是是在移動端上收集數據，基本上是採集不到數據的，有多是運營商對這些數據比較敏感。在國內作MTR能夠看到不少的數據，但在非洲幾乎全部的環節看到的數據都是「***」，表示它不容許探測。

2.3 肯定問題所在

最後咱們設計了幾個實驗來肯定網絡問題的源頭，總的來講能夠分紅三組。

首先咱們要確認是否是真的存在十分嚴重的擁塞。咱們分別在閒時和忙時觀測視頻卡頓和啓動時間這些指標，發現差異很大。相較於忙時，閒時的首屏能夠減小30%，卡頓下降40%，這是很是顯著的差別，這也說明了擁塞的存在，可是具體在哪一部分還不能肯定。

接下來咱們想驗證用戶接入網的差異是否爲形成差別的因素。咱們知道4G網確定比3G網好不少，可是在非洲4G用戶較少，咱們推測網絡擁塞狀況應該也相對良好，經過實驗得以驗證確實如此，使用4G網絡的狀況會比使用3G網絡的狀況好不少，但也沒有像閒時與忙時的差別那樣顯著，所以接入網並非主要的問題所在。

接下來驗證是否爲運營商出口網絡的問題。在運營商內部咱們也設置了一些服務器，經過它們來作測試。結果顯示與歐洲的CDN相比，運營商網內設置服務器更具備收益，但並不顯著。這也就說明了運營商的出口也存在問題，但不是主要問題。

在非洲還有一些IXP，國內IXP可能比較少。所謂IXP，簡單來講就是設置一個機房，各個運營商把它們的線路都拉到這個機房內，從這裏能夠很方便地連上各個運營商，運營商彼此間也能夠交換流量。但實際上非洲IXP與運營商之間的網絡也有擁塞，若是把CDN放在IXP的話，優化效果相比於放在運營商網絡內會更差一些。

經過以上測試咱們得出了這樣一個定性的判斷：從手機到基站這部分的網絡擁塞是最嚴重的，從運營商互聯網出口出去後也存在必定的問題，由此以後的流程則沒有太大的問題。在這種狀況下，優化實際上是比較困難的。但至少咱們已經認識到了問題的所在，接下來就是思考具體的解決辦法。

2.4 非洲網絡狀況總結

總地來講，非洲的網絡從鏈路和網絡層來看，帶寬嚴重不足，很是擁塞。

從傳輸層角度來看，不是傳輸層自己的問題，而是鏈路層和網絡層影響了傳輸層，傳出層的表現爲丟包率高、RTT高。到應用層，解析域名很慢、下載速度很慢，並常常出現下載失敗的問題。以上就是非洲的基本網絡狀況。

3 高延遲、高丟包視頻體驗優化

在有了對網絡基本狀況的判斷後，接下來咱們須要肯定如何進行優化。

3.1 肯定優化目標

回到具體指標，由於咱們作的是版權長視頻，因此會更關心首屏和卡頓的問題。延遲對咱們而言不是特別關鍵，由於直播電視頻道並不涉及到互動環節，觀衆對延時不是太敏感。因此咱們的工做重心會放在解決首屏和卡頓的問題上。

用戶體驗和成本這部分，由於咱們的核心用戶是付費用戶，他們對視頻質量是有必定要求的。但因爲是在非洲，他們的要求確定沒有中國或者美國用戶的要求那麼高，關鍵在於如何定義「必定的需求」。

最終咱們肯定的目標是：第一，下降卡頓比，第二，減小首屏時間。卡頓比高，用戶主動退出率會增長，這是咱們不想看到的。首屏排在第二位是由於用戶對首屏仍是有必定的耐受度的，長視頻啓動慢一點相對來講能夠接受。但若是短視頻若是啓動慢，用戶應該會很難接受。所以咱們結合業務特色，但願將首屏時間限定在不能超過5秒。至於延時，在業務模式下相對來講是能夠犧牲部分的。

針對畫質咱們進行了市場調研，對一些關鍵的內容——例如球賽作了不少的調研，最後得出結論：對於球賽視頻，用戶的最低要求是能看到球。其實這個要求並非太容易知足，以非洲的網絡下載速度，視頻想要流暢播放就必須下降碼率，而碼率一旦下降，球就會模糊——球在天上飛的時候很是小，畫面裏就一兩個像素那麼大，編碼的時候很是容易把球編沒。因此常常的狀況是：球在天上飛找不到位置，過一會又出現落在地上。對於這個問題咱們也是作了很是多的優化才使其達到用戶可以接受的最低要求。而在其它方面包括新聞類節目，報道播出的時候須要清晰顯示新聞人物的人臉，在國內這些都是不用擔憂的事情，但在非洲則須要經過各類優化實現。以上就是咱們最終定下來的優化目標。

3.2 優化思路

具體的優化思路要從CDN層面提及。剛剛咱們提到非洲總體網絡慢、差、擁塞，那麼緣由到底是什麼呢？咱們從IDC角度來看就能發現一些問題，非洲的ISP很是多，和東南亞以及印度相似，規模偏小，彼此間的互聯互通作的也不好。打個比方，若是在非洲同一個國家兩個不一樣的運營商互相訪問，由於運營商之間沒有作互聯，因此流量須要跑到歐洲繞一圈，或者跑到南非繞一圈。

由此咱們想到或許能夠在非洲找一個IDC，或者經過雲的方式來解決這個問題，但最後發現並不行。由於IDC只會和某些運營商之間有Peering或者購買了運營商的Transit，它沒法和全部的運營商都作到徹底的互聯。假如在IDC裏設置服務器，某一個運營商的用戶會很是開心，但相對應其它運營商的用戶就很痛苦，這些用戶的流量須要先轉到歐洲，再繞回到非洲來，還不如直接使用歐洲的雲服務。

最初咱們也不知道這些信息，使用的是歐洲的CDN和雲服務來支持業務，後來嘗試挪到非洲本地，發現效果更差。最終咱們制定的策略就是在較大的ISP網內自建CDN，再使用歐洲的CDN做爲備份。

還有一個思路是找尋與ISP直連的第三方CDN，但實際上很難找到。所以第三方CDN只能做爲備份和輔助，這是針對非洲網絡特色設計的方案。

目前咱們自建CDN的部署規模已經相對比較大，圖中四達時代logo的位置表明咱們在非洲的運營商中鋪設的CDN服務器，這些CDN基本都是輕量級的，咱們在每一個機房裏就設置一臺服務器，服務器自己是高可用的，它看上去更像是普通的服務器，但內部全部的模塊都有備份，好比電源、風扇、背板、交換、計算、存儲等模塊都是雙份的，所以可靠性很是高。咱們經過大量鋪設這一類服務器，做爲邊緣的緩存節點，供用戶直接在網內訪問、播放視頻。

3.3 監控與調度系統

使用上面提到的自建CDN服務器，在調度上可能會遇到一些問題。

首先自建CDN僅能供內網用戶訪問，由於這些CDN沒有公網IP，它們的IP地址是相似10.x這樣的內網IP。若是調度出現錯誤，讓用戶去訪問另一個運營商網內的自建CDN，則必然沒法創建TCP鏈接，因此在調度上須要更加謹慎。

其次是運營商網內的出口不穩定，緣由是非洲的運營商運維水平有限。舉個例子，咱們的一個CDN服務器鏈接到機房的交換機上，再從交換機出去，有時候機房交換機會丟包，如無任何徵兆地丟包90%。運營商本身也沒有監控，每次都是咱們發現問題後，聯繫重啓交換機進行解決——這其實很影響用戶體驗。

另外就是一些球賽、演唱會場景，這些場景對於作視頻的人來講就和「秒殺」的性質是同樣的，會瞬間進來一大批人，運營商的網內出口可能就直接被打爆了。

在發現這些問題後，對於CDN調度就須要作針對性處理，主要有如下3種策略：

**1. 基於用戶體驗的調度：**對於上述機房交換機的問題，即無徵兆地出錯並且也不報警，咱們在播放器中加了不少埋點，經過播放器實時上報卡頓、啓動成功率、下載速度等指標，後臺獲取到這些信息進行實時分析，分析結果可做爲調度策略的參考輸入。假設運營商網內出口不穩定，儘管這種狀況下CDN自己沒問題，但用戶體驗極差，則用戶體驗指標會報警，調度系統就會將用戶調至備用CDN。

**2. 基於CDN狀態的調度：**這點比較基礎，例如CDN服務器出現故障、機房網絡不通、或者CDN的帶寬已經打滿，那流量就不能再往這裏調度。

**3. 基於成本的調度：**咱們會優先將用戶調往網內的CDN，網內CDN不可用時再轉向第三方CDN。

3.4 音視頻技術

音視頻技術層面的內容會比較多，首先物理網絡自己就不太好，鋪設CDN後有必定的改善，但僅僅是少許的提高，並無質的飛躍，更多的優化須要從技術的角度進行。

具體能夠總結爲如下幾個層面：

業務接口的異步化：在播放視頻時，用戶會認爲點開視頻的連接，視頻就應該開始播放，但實際上業務後臺還要作不少事情，好比鑑權，廣告等一些策略，這些策略若是是串行執行的，會對首屏時間有很大影響。

網絡層的優化指經過優化傳輸協議、擁塞控制算法等提高下載速度、下降建連時間對首屏時間的影響等。

視頻封裝優化能夠減小播放器與CDN的交互次數，從而減小首屏時間、下降卡頓。

視頻編碼優化能夠下降碼率，一樣能夠減小首屏時間、下降卡頓率。

流媒體協議選擇

在分析更具體的問題前，先來講說流媒體協議的選擇，咱們最終選擇的是HLS封裝。起初，咱們考慮過國內使用較多的HTTP FLV封裝，它的延遲低、封裝開銷比較小，使用的人不少、技術也較爲成熟。但就對比實際的需求，咱們發現使用HTTP FLV會存在不少問題，例如咱們有多音軌和多字幕的需求，不少電影有2個音軌（如英語和法語），有些還要加上當地語言，這樣最終就可能會是四、5個音軌。若是咱們將全部的音軌打到同一個流裏，那這個流的封裝效率就很低，用戶只會使用一個音軌，但卻須要下載整個流。包括多字幕，也是一樣的問題，所以咱們須要將這些不一樣的流拆分開來。

除此以外，在音視頻數據流分離、平滑的碼率切換這些方面FLV作的都不太好。若是使用FLV，咱們還須要在它的基礎上進行二次開發。再有就是海外第三方CDN的支持問題，大部分海外CDN廠商都表示不支持FLV協議。

另外，當時還有個選擇就是DASH，不過咱們在2016年開始作研發的時候，DASH的開源工具還很是少，所以最終選擇了HLS，各方面需求支持都比較好，技術成熟度也很高。

3.5 首屏時間問題

接下來到具體問題的分析，首先咱們要解決的是首屏問題。從用戶點擊視頻到最後視頻成功播放須要幾個環節，如上面流程圖所示。

第一，業務鑑權。像咱們這樣的付費業務，用戶是否有權益是須要校驗的，而且校驗過程相對複雜。例若有不少人盜流，那咱們就須要防黑產，即要判斷當前用戶是不是合法用戶、是否有權限使用這個流。在這裏咱們作了大量的數據模型來判斷用戶是否爲機器人，只有真實用戶纔會得到CDN的token。其它業務邏輯還包括播放廣告的策略、是否續播、選擇用戶喜愛的碼率等，這些業務邏輯都是在用戶點擊播放按鈕以後執行的。

接下來就是選擇CDN。由於CDN的數量不少，算上第三方的大約有幾十甚至更多，須要做出最爲合適的選擇，選擇CDN後還要進行域名解析。解析域名後開始下載視頻文件，由於咱們使用了HLS協議，因此播放器要下載M3U8文件，以及切片文件，最後才能夠獲得首幀的數據。

整條鏈路是比較長的，若是不作任何的優化，首屏時間基本上要超過十幾個RTT。好比按照HLS的規範，m3u8和切片能夠放到不一樣的CDN上，可是這樣就不能用同一個TCP鏈接去下載，須要各自創建鏈接再前後下載。並且建連次數多還會影響首屏成功率，由於TCP握手的成功率也只有80%，連續建兩個鏈接都成功的機率就只有64%了。

咱們經過全流程再看幾個數據，第一個是首屏的成功率，這是一個總體的指標。錯誤率指的是在任何一個環節都有可能出錯，好比CDN可能會有錯，下載文件時可能會返回404或者403，再或者建連的時候失敗了，總之任何環節出錯，都會記到錯誤率指標中。還有主動退出率，假設用戶最終沒有觀看視頻，要麼是由於出錯，要麼是由於主動退出。若是是主動退出，咱們還要記錄主動退出的環節和時間，這些信息對後面的優化有很強的指導意義。

圖中展現的是咱們在定義指標後採集到的一些數據，上面的橫條是啓動時間的平均值，不一樣的顏色表明不一樣的環節。最左邊深綠色爲業務接口，藍色爲CDN選擇，和剛剛介紹的流程一致。按照流程咱們進行了一段時間的採集，經過查看平均的數據，咱們發現用戶花費了大量的時間在下載切片文件上，這個文件可能有幾百k左右的大小，而前面一些環節可能就幾十個字節，因此看起來也比較合理。

但實際上若是咱們須要優化首屏時間，咱們須要看下面的橫條，這是85分位的首屏時間分析，下載仍然是耗時最長的，不過由於前面的一些環節會佔到整個環節的2/3。若是咱們的目的是經過下降首屏時間來下降用戶的主動退出率，僅僅優化下載切片的時間是不夠的，就算優化成0，前面環節也須要5s左右的時間，用戶仍然難以接受。因此在拿到這個數據後咱們再分析根本緣由，很明顯是由於RTT很大，全部環節又都是串行執行，這就會致使首屏時間變得很是長。根據數據獲得結論後咱們就能夠定一個優化的思路。

首屏時間優化方案

首先看業務接口的優化，根據各企業業務的不一樣，優化方式也多種多樣。在咱們的業務中像鑑權、廣告播發這樣的邏輯均可以改成異步，好比向客戶端下發一個策略，客戶端異步執行，像續播、碼率的選擇，能夠交由客戶端本身實現，由於客戶端能夠記錄播放歷史，每次App啓動時和服務器進行同步。具體視頻開始播放時，是否續播由客戶端自行決定。這些優化能夠減小串行環節，總體流程上能夠減小1-2個RTT，在非洲就能夠體現爲幾百ms甚至1秒鐘左右的時間節省。

CDN選擇包括DNS的解析其實優化思路也是同樣的。爲節省CDN的選擇時間，咱們直接在列表頁上作CDN的選擇，在列表頁查看用戶的位置，將數據提供給後臺作快速選擇。APP端也能夠異步選擇CDN，好比手機的網絡有變化，從3G到4G或者切換到WIFI，有產生變化的時候，APP會作一個異步的選擇解析，這樣就能夠保證視頻的正常播放，同時在流程上也能夠減小2個RTT。

而後就是M3U8下載的問題，要下載就必須先創建TCP鏈接，而TCP握手須要花1RTT。咱們有2種方式來節省建連時間，第一種是CDN選擇結束後客戶端直接創建鏈接，而後作心跳保活。在非洲作鏈接保活很不容易，鏈接一會就斷了，發包發不過去，這時候重建鏈接就會浪費用戶的流量，但不重建的話，等須要下載視頻數據時從新建連會更浪費時間。總之要細調這個保活策略。

更理想的是使用QUIC，由於它具備0RTT快速鏈接的特性。QUIC也須要經過握手創建鏈接，但由於握手包和數據包是一塊兒發出的，從用戶的角度看，就至關於沒有握手的時間。固然也一樣會存在問題，它的生效比例不是特別高，在谷歌默認的策略裏，IP變了0RTT也會失效，這實際上是一個很強的約束，由於移動網絡的IP很容易就出現變化。根據實際測驗，0RTT生效的比例只有50%，谷歌本身的數據是60%左右，固然這也要考慮到地區差別性。作到上述優化又能夠節省1-2個RTT。

接下來是M3U8下載的問題。M3U8有master M3U8，也有子M3U8，並且咱們用到的是fragmented MP4的封裝，沒有用TS。封裝會增長一個init.mp4文件，文件不大但須要獨立地下載，獨立下載意味着又會增長一個RTT。因而咱們就將這些文件的內容合併到視頻的URL中，用戶在訪問URL時能夠直接獲取到文件內容，無需屢次單獨下載。這些文件的內容都是文本或是字符串，咱們只須要把字符串傳到客戶端，由客戶端在本地構造M3U8等文件後給到播放器，播放器就能夠正常播放。這樣作能夠節省1~2個RTT。

最後是切片下載的TCP建連時間，有的公司可能會把切片和m3u8放到兩個CDN上，這樣也就必須分別創建鏈接，但若是切片和m3u8在同一個CDN上，咱們能夠用同一個鏈接，至少在點播上是可行的，由於點播只須要下載一次M3U8，接着下切片文件。而直播可能就不行了，由於直播的M3U8的更新和切片的更新是獨立的，它們是在兩條線並行地更新，因此這時候必需要有兩個鏈接去作並行的下載。而這種狀況下咱們對於直播的優化策略就是建連的時候直接創建兩個鏈接。固然若是有使用HTTP2或者QUIC的協議就會更簡單一些，由於這些協議支持鏈接複用，HTTP2和QUIC的建連可能會更困難一些，由於他們建連的數據包更多，不過由於鏈接能夠複用，整體上來講又能夠減小1-2個RTT。

因此總體的優化思路其實特別簡單，目標也很明確，RTT高自己很難優化，那就直接減小RTT的個數。在全部的優化完成後，經過計算咱們發現大約減小有10個RTT，咱們在最差的基礎上作優化，最終減小10個RTT。那在現實中10個RTT的提高到底是什麼效果？用戶在列表頁點視頻的時候，沒有任何其餘環節了，甚至鏈接都建好了，播放器直接去下載視頻自己的數據，下載一點數據視頻首幀就能出來，因此啓動時間會有很是顯著的改善。

這就是咱們優化的結果。以前首屏時間85分位能到7s多，這個時間對於非洲的用戶來講也是難以忍受的，但咱們優化完成之後，如今的時間不到3s。對於國內的標準，雖然仍是會比較長，但對於非洲用戶來講這個時間是能夠接受的。

主動退出率這一塊也很明顯，以前是14%，100人看視頻，有14我的由於不肯意等就退出了，這是一個很糟糕的數據。咱們作了優化之後它下降了一半大概能到7%左右。固然還有一些用戶3s都不肯意等，咱們也分析這些用戶的行爲，發現這些用戶可能本身在操做習慣上有問題，好比他們會在頻道列表裏「亂點」，1s點好幾個視頻，頻繁退出，這樣的操做在後臺仍是會算成主動退出，因此整體上主動退出比例只下降了一半。但對於正常觀看視頻的用戶來講，這一首屏時間已經能夠接受了。

3.6 卡頓問題

接下來是卡頓。卡頓這一塊的指標體系會更簡單一些。播放器先下載M3U8，而後下載切片。若是是直播的話就輪流下載，點播就下載一次M3U8，後面不停下載切片就能夠了。再日後就是緩存、解碼的過程。這一環節很是簡單。

卡頓比這一塊的優化思路主要是提高下載速度，下載速度只有250kbps，並且播放器還不能一直下載，這就致使直播的卡頓比要比點播高得多，緣由就是直播不能一直下切片，要頻繁下載M3U8。

卡頓優化方案

這裏的優化思路就是M3U8和切片要並行下載，有一個方法是把M3U8的內容放到切片裏面去。這是一個比較有意思的改動，咱們直接將M3U8的文本放到切片的http response header中，由於m3u8自己就是個字符串，這樣播放器就不用單獨下載m3u8了，只須要不停地下載切片。由於每個切片裏都自帶了下一個m3u8，這樣就節省了單獨下載m3u8的時間，總體下載速度天然也就提高了。

而後是緩衝區的優化，由於咱們不關心延遲，因此就把緩存區加到了75s。

碼率這一塊，咱們用的fragmented MP4，這個封裝的Overhead很低。你們若是是用HLS，就必定要注意這個問題，由於大部分狀況下HLS用的是TS封裝，而TS封裝的Overhead很是高，在小碼率下能到10%，好比音視頻原始碼流的碼率是200kbps，封裝出來就變成220kbps了，這是很不划算的。而fragmented MP4只有1%的overhead，但一樣fMP4也有它本身的問題，它會把音頻編在前面去，視頻編在後面，這樣就會影響啓動的時間，因此咱們還須要本身去作一些交織的封裝。

編碼部分，剛剛有提到過咱們主要針對內容來進行優化，通過處理優化提高低碼率下的畫質以及播放流暢性。

CDN部分，經過自建CDN、優化CDN選擇策略等，也能夠明顯提升下載速度。

最後，關於BBR/QUIC這部分仍是值得說一下，起初咱們使用BBR的擁塞控制算法，收益並不明顯，與預期的差異很大，後面分析獲得結論多是由於擁塞過於嚴重。總地來講，BBR算是一個相對君子一點的算法，不像cubic同樣瘋狂發包直至丟包爲止，BBR是檢測到開始擁塞就中止發包，但因爲非洲的網絡自己擁塞就很嚴重，所以BBR的收益也就沒那麼顯著，後面咱們還會進行一些其它的嘗試。

卡頓優化以後的收益也是很是顯著的，在85分位下，原來直播的卡頓比有15%，如今不到2%，就在非洲來講這是個不錯的結果。而對於點播，85分位播放卡頓比不到1%，也是個不錯的結果。

這幾件事情作完之後咱們的用戶體驗獲得了很大的提高，促進了業務的發展。

3.7 優化思路總結

最後簡單總結一下。首先，數據是改進的基礎，想準確發現問題須要預先埋特別多的點。若是僅靠臆想問題所在，而後直接修改程序，那結果極可能是隨機的。所以咱們甚至在網絡協議棧中也埋了點把一部分用戶的網絡協議棧日誌拉回來，好比每個IP包何時發，何時丟，爲何重發，重發的是否及時，每個數據都拉回來作分析。至於播放器和業務埋點就更基本了，必定要埋全。

其次，要在分位線上看數據，不能只看平均值，平均值會掩蓋極端的狀況，結果把咱們導向錯誤的優化方向。

最後是抓核心指標，對於咱們來講就是犧牲延遲，把其它指標作好。要能找到核心瓶頸並針對其進行優化，這樣才能保證比較高的作事效率。