在弱網下，視頻啟動時間和播放卡頓都會增加。為提升弱網用戶體驗，需要識別出主要問題再針對性調優。本演講將結合四達時代在非洲建設”StarTimesOn在線視頻平臺“過程中積累的豐富數據，分享傳輸路由優化和傳輸協議優化相關的關鍵問題，以及各類針對性調優方案上線后的效果對比。

大家好，我是四達時代的研發總監張亮，本次分享的內容是基于四達時代在非洲做在線視頻服務時所遇到的一些問題和一些優化的經驗。大家都知道，非洲的網絡環境非常復雜，甚至可以說幾乎沒有比非洲更差的網絡環境了，因此我們這里介紹的是一個比較極端的情況，僅供大家參考。 分享的內容主要分為三部分。首先是對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索引文件和視頻切片文件。索引文件大小幾百個字節，下載這樣一個文件可能需要1000~2000毫秒。視頻切片下載速度在200~400kbps左右。以上就是非洲目前的網絡情況。 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個音軌（如英語和法語），有些還要加上當地語言，這樣最終就可能會是4、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包什么時候發，什么時候丟，為什么重發，重發的是否及時，每一個數據都拉回來做分析。至于播放器和業務埋點就更基本了，一定要埋全。 其次，要在分位線上看數據，不能只看平均值，平均值會掩蓋極端的情況，結果把我們導向錯誤的優化方向。 最后是抓核心指標，對于我們來說就是犧牲延遲，把其它指標做好。要能找到核心瓶頸并針對其進行優化，這樣才能保證比較高的做事效率。

原文標題：海外弱網下的在線視頻平臺優化實踐

文章出處：【微信公眾號：LiveVideoStack】歡迎添加關注！文章轉載請注明出處。

責任編輯：haq