建設StarTimesOn在線視頻平臺過程中積累的豐富數(shù)據(jù)

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

大家好，我是四達時代的研發(fā)總監(jiān)張亮，本次分享的內(nèi)容是基于四達時代在非洲做在線視頻服務時所遇到的一些問題和一些優(yōu)化的經(jīng)驗。大家都知道，非洲的網(wǎng)絡環(huán)境非常復雜，甚至可以說幾乎沒有比非洲更差的網(wǎng)絡環(huán)境了，因此我們這里介紹的是一個比較極端的情況，僅供大家參考。 分享的內(nèi)容主要分為三部分。首先是對StarTimes On App的簡單介紹，由此引出我們的產(chǎn)品到底應該關(guān)心哪些指標，優(yōu)化必須要明確最核心的目的，想一起優(yōu)化所有的指標肯定是不可行的。第二部分會列出一些實際數(shù)據(jù)讓大家了解非洲的實際網(wǎng)絡情況。第三部分會重點和大家分享在如此極端的網(wǎng)絡環(huán)境下我們具體采用了哪些優(yōu)化方式、方法，并最終取得了怎樣的效果。 1 StarTimes On APP 簡介

也許之前大家不太了解四達時代，因為我們主要的業(yè)務是在非洲做電視運營。在非洲，四達時代可以說是一家家喻戶曉的公司，我們已經(jīng)在非洲耕耘了十四年，在四十五個非洲國家做運營，目前已經(jīng)擁有超過1000萬的付費電視用戶，所以我們的整體收入規(guī)模和影響力還是具備一定水平的。同時我們也是“萬村通”項目的實施方，這是我們國家“一帶一路”中的一個重要項目。 1.1 StarTimes On APP

StarTimes On 這個APP做的比較晚，直到2017年才上線，上線直接面臨的就是2018年世界杯的考驗。最初我們對于非洲的網(wǎng)絡環(huán)境有多差是沒有作心理準備的，只是從APM廠商那里獲得了一些數(shù)據(jù)，但實際真實的數(shù)據(jù)比拿到的數(shù)據(jù)還要差的多，因此在世界杯的轉(zhuǎn)播過程中還是出現(xiàn)了一些問題，不過好在我們都及時想辦法解決掉了。 現(xiàn)在，StarTimes On已經(jīng)基本上具有一定的知名度，在Google Play娛樂板塊上也一直是名列前茅。

1.2 商業(yè)模式與運營指標

從APP的商業(yè)模式上可以找到我們的核心指標。首先，我們的內(nèi)容都是版權(quán)內(nèi)容。用戶分為兩類，一類是免費用戶，另一類是付費用戶。 免費用戶觀看視頻需要看廣告，廣告會給我們帶來收入。免費用戶看VIP內(nèi)容則有限制，只能試看三分鐘。所以我們的運營指標就是免費用戶看了多少視頻，因為觀看視頻就意味著廣告播放的增加，其次播放次數(shù)多則意味著更有潛力成為付費用戶。 對于付費用戶來說我們的收入來源是訂閱費，付費用戶不需要看廣告，所有的內(nèi)容權(quán)益也相應解鎖。因此對于付費用戶，我們則重點關(guān)注用戶觀看視頻的數(shù)量和觀看的時長?？吹枚?、看得久就代表滿意度高，滿意度高就會繼續(xù)付費，所以這是我們運營上的指標。

有了運營指標的要求，我們就可以進一步拆解指標，從技術(shù)角度上進行分析，哪些地方需要優(yōu)化。運營指標可以拆解成觀看視頻數(shù)量與觀看視頻時長。 觀看視頻數(shù)量很容易理解，如果視頻啟動失敗了，觀看數(shù)量自然也就會降低，而如果每次打開視頻都能成功，都能順利看到第一幀，那就是一個好的結(jié)果。所以QoE部分我們就會關(guān)注用戶的主動退出率，用戶為什么會主動退出，大部分情況都是因為等待的時間太久，比如用戶等待的時間超過8秒鐘，那可能大部分用戶都會選擇退出。QoS角度則會關(guān)注首屏時間，就是首屏時間越快、越小，主動退出率越低。 觀看時長有兩種度量方法。對于電視劇、電影，我們會關(guān)注用戶觀看時長占視頻總時長的比例。如果是直播頻道，則關(guān)注觀看的時間長度。影響用戶觀看時長最核心的QoS因素是卡頓。用戶普遍會有一個心理預期，例如看一部電影，可以容忍視頻卡三次，如果出現(xiàn)太多次卡頓用戶可能就會放棄觀看。 經(jīng)過以上分析，我們可以導出此業(yè)務模式下最核心的兩個QoS指標：首屏時間和卡頓比。之前和很多同學交流，有很多做互動、RTC方面的同學會更多關(guān)注延遲，但是在我們這個業(yè)務模式下延遲并不需要特別關(guān)注。后面會介紹到，我們還會有一些優(yōu)化策略是通過犧牲延遲來獲得其它收益。 2 非洲網(wǎng)絡狀況與挑戰(zhàn) 接下來和大家說一下非洲網(wǎng)絡的真實情況。 2.1 非洲網(wǎng)絡基本情況

首先，大家看數(shù)據(jù)圖中的南非，南非算得上是一個中等發(fā)達國家，網(wǎng)絡情況還算可以。南非到歐洲CDN的延遲在閑時約為100多毫秒，忙時200毫秒，這其實還算可以。但如果往西邊看，尼日利亞、加納、科特等一些國家就糟糕多了。像尼日利亞，在忙時的RTT能超過600毫秒。這意味著我們在做任何網(wǎng)絡操作的時候，哪怕是下載一個字節(jié)的文件，也需要600毫秒的等待，因為網(wǎng)絡一來一去硬指標就在那里。如果我們業(yè)務上的后臺放在歐洲，那么執(zhí)行任何操作都需要600毫秒的延遲，非常影響用戶的體驗。 而東邊像肯尼亞、烏干達、坦桑尼亞其實網(wǎng)絡情況也不太好。在國內(nèi)，如果最北邊地區(qū)的用戶訪問最南邊地區(qū)的機房花幾十毫秒，已經(jīng)可以算作比較慢了，而在非洲動輒就是幾百毫秒，他們的網(wǎng)絡情況相比國內(nèi)差十倍甚至幾十倍，這也就意味著我們面臨的是一個艱巨的挑戰(zhàn)。

下面是丟包率，丟包問題現(xiàn)在更嚴重。近期我們收集過一次數(shù)據(jù)，相比于疫情前，丟包率呈現(xiàn)翻倍的情況。受疫情影響，大家會更多使用手機流量，而非洲的帶寬資源又非常不足，所以丟包情況變得更加嚴重。如圖中所示，在高峰期丟包率會有24~25%左右，在這樣的丟包率的情況下，下載速度是肯定上不去的。

再來看其它的一些指標，建連的成功率有80%，指標相對比較穩(wěn)定，5次里會失敗1次。我們會通過長連接緩解建連失敗的影響，但長連接也會出現(xiàn)斷連，所以很多時候仍然需要重連。DNS解析時間也很長，要1秒左右，數(shù)據(jù)都比較差勁。 視頻封裝我們使用的是HLS協(xié)議，CDN上有大量M3U8索引文件和視頻切片文件。索引文件大小幾百個字節(jié)，下載這樣一個文件可能需要1000~2000毫秒。視頻切片下載速度在200~400kbps左右。以上就是非洲目前的網(wǎng)絡情況。 2.2 問題發(fā)生的原因

接下來我們簡單梳理下非洲的網(wǎng)絡問題究竟出現(xiàn)在哪里，只有定位了問題所在，才可以更好地探索優(yōu)化的思路。 非洲網(wǎng)絡丟包率很高，延遲很大。丟包的產(chǎn)生有很多原因，這里我列了兩個比較主要的：一個是無線接入網(wǎng)丟包，因為在非洲網(wǎng)絡資源（接入網(wǎng)）是非常不足的，雖然大家都使用3G，也有部分的4G基站，但是基站數(shù)量太少，如果大家同一時段一起使用的話，基站資源明顯是不夠的。所以高峰期信號弱、小區(qū)切換會有很多問題，這就會導致數(shù)據(jù)包丟掉。另一個原因是擁塞，不論在非洲哪個國家擁塞都是非常嚴重的，擁塞在運營商的出口方面會體現(xiàn)的非常明顯。如果網(wǎng)絡一直處于擁堵的狀態(tài)，但大家還在大量發(fā)送包，或者去請求包，那最后大概率就是丟包。 延遲可以分為幾類，像傳輸延遲和處理延遲等。排隊延遲說到底還是和擁塞有關(guān)系，如果網(wǎng)絡擁塞的很厲害，那中間的交換機，路由器都要排隊，排隊會花費更多的時間。經(jīng)過實際分析我們發(fā)現(xiàn)：排隊延遲是最主要的問題。重發(fā)延遲是指丟包之后重新發(fā)包帶來的延遲，從應用層的角度看，這也是一種延遲。

在了解了非洲網(wǎng)絡延遲與丟包的情況后，我們想定位一下這些問題究竟發(fā)生在哪個環(huán)節(jié)，隨后再去尋找相應的解決辦法。上圖是從手機發(fā)送請求到最后IDC中的服務器收到并響應的過程。一開始用戶的手機需要先連接基站，向基站發(fā)送無線信號，基站內(nèi)部處理后，把網(wǎng)絡的請求通過運營商的互聯(lián)網(wǎng)出口傳出，隨后有一個更大的互聯(lián)網(wǎng)，但其實這里面有很多層網(wǎng)絡供應商，最終送到了IDC，以上所有的環(huán)節(jié)都可能發(fā)生問題。 最初我們想通過MTR或者Ping這些工具來診斷問題，但在實際操作中發(fā)現(xiàn)，如果是在移動端上收集數(shù)據(jù)，基本上是采集不到數(shù)據(jù)的，有可能是運營商對這些數(shù)據(jù)比較敏感。在國內(nèi)做MTR可以看到很多的數(shù)據(jù)，但在非洲幾乎所有的環(huán)節(jié)看到的數(shù)據(jù)都是“***”，表示它不允許探測。 2.3 確定問題所在

最后我們設計了幾個實驗來確定網(wǎng)絡問題的源頭，總的來說可以分成三組。 首先我們要確認是不是真的存在十分嚴重的擁塞。我們分別在閑時和忙時觀測視頻卡頓和啟動時間這些指標，發(fā)現(xiàn)差別很大。相較于忙時，閑時的首屏可以減少30%，卡頓降低40%，這是非常顯著的差異，這也說明了擁塞的存在，但是具體在哪一部分還不能確定。 接下來我們想驗證用戶接入網(wǎng)的差別是否為造成差異的因素。我們知道4G網(wǎng)肯定比3G網(wǎng)好很多，但是在非洲4G用戶較少，我們推測網(wǎng)絡擁塞情況應該也相對良好，通過實驗得以驗證確實如此，使用4G網(wǎng)絡的情況會比使用3G網(wǎng)絡的情況好很多，但也沒有像閑時與忙時的差異那樣顯著，因此接入網(wǎng)并不是主要的問題所在。 接下來驗證是否為運營商出口網(wǎng)絡的問題。在運營商內(nèi)部我們也設置了一些服務器，通過它們來做測試。結(jié)果顯示與歐洲的CDN相比，運營商網(wǎng)內(nèi)設置服務器更具有收益，但并不顯著。這也就說明了運營商的出口也存在問題，但不是主要問題。 在非洲還有一些IXP，國內(nèi)IXP可能比較少。所謂IXP，簡單來說就是設置一個機房，各個運營商把它們的線路都拉到這個機房內(nèi)，從這里可以很方便地連上各個運營商，運營商彼此間也可以交換流量。但實際上非洲IXP與運營商之間的網(wǎng)絡也有擁塞，如果把CDN放在IXP的話，優(yōu)化效果相比于放在運營商網(wǎng)絡內(nèi)會更差一些。

通過以上測試我們得出了這樣一個定性的判斷：從手機到基站這部分的網(wǎng)絡擁塞是最嚴重的，從運營商互聯(lián)網(wǎng)出口出去后也存在一定的問題，由此之后的流程則沒有太大的問題。在這種情況下，優(yōu)化其實是比較困難的。但至少我們已經(jīng)認識到了問題的所在，接下來就是思考具體的解決辦法。 2.4 非洲網(wǎng)絡情況總結(jié)

總地來說，非洲的網(wǎng)絡從鏈路和網(wǎng)絡層來看，帶寬嚴重不足，非常擁塞。 從傳輸層角度來看，不是傳輸層本身的問題，而是鏈路層和網(wǎng)絡層影響了傳輸層，傳出層的表現(xiàn)為丟包率高、RTT高。到應用層，解析域名很慢、下載速度很慢，并經(jīng)常出現(xiàn)下載失敗的問題。以上就是非洲的基本網(wǎng)絡情況。 3 高延遲、高丟包視頻體驗優(yōu)化

在有了對網(wǎng)絡基本情況的判斷后，接下來我們需要確定如何進行優(yōu)化。 3.1 確定優(yōu)化目標

回到具體指標，因為我們做的是版權(quán)長視頻，所以會更關(guān)心首屏和卡頓的問題。延遲對我們而言不是特別關(guān)鍵，因為直播電視頻道并不涉及到互動環(huán)節(jié)，觀眾對延時不是太敏感。所以我們的工作重心會放在解決首屏和卡頓的問題上。 用戶體驗和成本這部分，因為我們的核心用戶是付費用戶，他們對視頻質(zhì)量是有一定要求的。但由于是在非洲，他們的要求肯定沒有中國或者美國用戶的要求那么高，關(guān)鍵在于如何定義“一定的需求”。 最終我們確定的目標是：第一，降低卡頓比，第二，減少首屏時間?？D比高，用戶主動退出率會增加，這是我們不想看到的。首屏排在第二位是因為用戶對首屏還是有一定的耐受度的，長視頻啟動慢一點相對來說可以接受。但如果短視頻如果啟動慢，用戶應該會很難接受。因此我們結(jié)合業(yè)務特點，希望將首屏時間限定在不能超過5秒。至于延時，在業(yè)務模式下相對來說是可以犧牲部分的。 針對畫質(zhì)我們進行了市場調(diào)研，對一些關(guān)鍵的內(nèi)容——例如球賽做了很多的調(diào)研，最后得出結(jié)論：對于球賽視頻，用戶的最低要求是能看到球。其實這個要求并不是太容易滿足，以非洲的網(wǎng)絡下載速度，視頻想要流暢播放就必須降低碼率，而碼率一旦降低，球就會模糊——球在天上飛的時候非常小，畫面里就一兩個像素那么大，編碼的時候非常容易把球編沒。所以經(jīng)常的情況是：球在天上飛找不到位置，過一會又出現(xiàn)落在地上。對于這個問題我們也是做了非常多的優(yōu)化才使其達到用戶能夠接受的最低要求。而在其它方面包括新聞類節(jié)目，報道播出的時候需要清晰顯示新聞人物的人臉，在國內(nèi)這些都是不用擔心的事情，但在非洲則需要通過各種優(yōu)化實現(xiàn)。以上就是我們最終定下來的優(yōu)化目標。 3.2 優(yōu)化思路

具體的優(yōu)化思路要從CDN層面說起。剛剛我們提到非洲整體網(wǎng)絡慢、差、擁塞，那么原因究竟是什么呢？我們從IDC角度來看就能發(fā)現(xiàn)一些問題，非洲的ISP非常多，和東南亞以及印度類似，規(guī)模偏小，彼此間的互聯(lián)互通做的也很差。打個比方，如果在非洲同一個國家兩個不同的運營商互相訪問，因為運營商之間沒有做互聯(lián)，所以流量需要跑到歐洲繞一圈，或者跑到南非繞一圈。 由此我們想到或許可以在非洲找一個IDC，或者通過云的方式來解決這個問題，但最后發(fā)現(xiàn)并不行。因為IDC只會和某些運營商之間有Peering或者購買了運營商的Transit，它無法和所有的運營商都做到完全的互聯(lián)。假如在IDC里設置服務器，某一個運營商的用戶會非常開心，但相對應其它運營商的用戶就很痛苦，這些用戶的流量需要先轉(zhuǎn)到歐洲，再繞回到非洲來，還不如直接使用歐洲的云服務。 最初我們也不知道這些信息，使用的是歐洲的CDN和云服務來支持業(yè)務，后來嘗試挪到非洲本地，發(fā)現(xiàn)效果更差。最終我們制定的策略就是在較大的ISP網(wǎng)內(nèi)自建CDN，再使用歐洲的CDN作為備份。 還有一個思路是找尋與ISP直連的第三方CDN，但實際上很難找到。因此第三方CDN只能作為備份和輔助，這是針對非洲網(wǎng)絡特點設計的方案。

目前我們自建CDN的部署規(guī)模已經(jīng)相對比較大，圖中四達時代logo的位置代表我們在非洲的運營商中鋪設的CDN服務器，這些CDN基本都是輕量級的，我們在每個機房里就設置一臺服務器，服務器本身是高可用的，它看上去更像是普通的服務器，但內(nèi)部所有的模塊都有備份，比如電源、風扇、背板、交換、計算、存儲等模塊都是雙份的，因此可靠性非常高。我們通過大量鋪設這一類服務器，作為邊緣的緩存節(jié)點，供用戶直接在網(wǎng)內(nèi)訪問、播放視頻。 3.3 監(jiān)控與調(diào)度系統(tǒng)

使用上面提到的自建CDN服務器，在調(diào)度上可能會遇到一些問題。 首先自建CDN僅能供內(nèi)網(wǎng)用戶訪問，因為這些CDN沒有公網(wǎng)IP，它們的IP地址是類似10.x這樣的內(nèi)網(wǎng)IP。如果調(diào)度出現(xiàn)錯誤，讓用戶去訪問另外一個運營商網(wǎng)內(nèi)的自建CDN，則必然無法建立TCP連接，所以在調(diào)度上需要更加謹慎。 其次是運營商網(wǎng)內(nèi)的出口不穩(wěn)定，原因是非洲的運營商運維水平有限。舉個例子，我們的一個CDN服務器連接到機房的交換機上，再從交換機出去，有時候機房交換機會丟包，如無任何征兆地丟包90%。運營商自己也沒有監(jiān)控，每次都是我們發(fā)現(xiàn)問題后，聯(lián)系重啟交換機進行解決——這其實很影響用戶體驗。 另外就是一些球賽、演唱會場景，這些場景對于做視頻的人來說就和“秒殺”的性質(zhì)是一樣的，會瞬間進來一大批人，運營商的網(wǎng)內(nèi)出口可能就直接被打爆了。 在發(fā)現(xiàn)這些問題后，對于CDN調(diào)度就需要做針對性處理，主要有以下3種策略： 1. 基于用戶體驗的調(diào)度：對于上述機房交換機的問題，即無征兆地出錯而且也不報警，我們在播放器中加了很多埋點，通過播放器實時上報卡頓、啟動成功率、下載速度等指標，后臺獲取到這些信息進行實時分析，分析結(jié)果可作為調(diào)度策略的參考輸入。假設運營商網(wǎng)內(nèi)出口不穩(wěn)定，盡管這種情況下CDN本身沒問題，但用戶體驗極差，則用戶體驗指標會報警，調(diào)度系統(tǒng)就會將用戶調(diào)至備用CDN。 2. 基于CDN狀態(tài)的調(diào)度：這點比較基礎，例如CDN服務器出現(xiàn)故障、機房網(wǎng)絡不通、或者CDN的帶寬已經(jīng)打滿，那流量就不能再往這里調(diào)度。 3. 基于成本的調(diào)度：我們會優(yōu)先將用戶調(diào)往網(wǎng)內(nèi)的CDN，網(wǎng)內(nèi)CDN不可用時再轉(zhuǎn)向第三方CDN。 3.4 音視頻技術(shù)

音視頻技術(shù)層面的內(nèi)容會比較多，首先物理網(wǎng)絡本身就不太好，鋪設CDN后有一定的改善，但僅僅是少量的提升，并沒有質(zhì)的飛躍，更多的優(yōu)化需要從技術(shù)的角度進行。 具體可以總結(jié)為以下幾個層面： 業(yè)務接口的異步化：在播放視頻時，用戶會認為點開視頻的鏈接，視頻就應該開始播放，但實際上業(yè)務后臺還要做很多事情，比如鑒權(quán)，廣告等一些策略，這些策略如果是串行執(zhí)行的，會對首屏時間有很大影響。 網(wǎng)絡層的優(yōu)化指通過優(yōu)化傳輸協(xié)議、擁塞控制算法等提升下載速度、降低建連時間對首屏時間的影響等。 視頻封裝優(yōu)化可以減少播放器與CDN的交互次數(shù)，從而減少首屏時間、降低卡頓。 視頻編碼優(yōu)化可以降低碼率，同樣可以減少首屏時間、降低卡頓率。 流媒體協(xié)議選擇

在分析更具體的問題前，先來說說流媒體協(xié)議的選擇，我們最終選擇的是HLS封裝。起初，我們考慮過國內(nèi)使用較多的HTTP FLV封裝，它的延遲低、封裝開銷比較小，使用的人很多、技術(shù)也較為成熟。但就對比實際的需求，我們發(fā)現(xiàn)使用HTTP FLV會存在很多問題，例如我們有多音軌和多字幕的需求，很多電影有2個音軌（如英語和法語），有些還要加上當?shù)卣Z言，這樣最終就可能會是4、5個音軌。如果我們將所有的音軌打到同一個流里，那這個流的封裝效率就很低，用戶只會使用一個音軌，但卻需要下載整個流。包括多字幕，也是同樣的問題，因此我們需要將這些不同的流拆分開來。 除此之外，在音視頻數(shù)據(jù)流分離、平滑的碼率切換這些方面FLV做的都不太好。如果使用FLV，我們還需要在它的基礎上進行二次開發(fā)。再有就是海外第三方CDN的支持問題，大部分海外CDN廠商都表示不支持FLV協(xié)議。 另外，當時還有個選擇就是DASH，不過我們在2016年開始做研發(fā)的時候，DASH的開源工具還非常少，因此最終選擇了HLS，各方面需求支持都比較好，技術(shù)成熟度也很高。 3.5 首屏時間問題

接下來到具體問題的分析，首先我們要解決的是首屏問題。從用戶點擊視頻到最后視頻成功播放需要幾個環(huán)節(jié)，如上面流程圖所示。 第一，業(yè)務鑒權(quán)。像我們這樣的付費業(yè)務，用戶是否有權(quán)益是需要校驗的，并且校驗過程相對復雜。例如有很多人盜流，那我們就需要防黑產(chǎn)，即要判斷當前用戶是否是合法用戶、是否有權(quán)限使用這個流。在這里我們做了大量的數(shù)據(jù)模型來判斷用戶是否為機器人，只有真實用戶才會獲得CDN的token。其它業(yè)務邏輯還包括播放廣告的策略、是否續(xù)播、選擇用戶喜好的碼率等，這些業(yè)務邏輯都是在用戶點擊播放按鈕之后執(zhí)行的。 接下來就是選擇CDN。因為CDN的數(shù)量很多，算上第三方的大約有幾十甚至更多，需要作出最為合適的選擇，選擇CDN后還要進行域名解析。解析域名后開始下載視頻文件，因為我們使用了HLS協(xié)議，所以播放器要下載M3U8文件，以及切片文件，最后才可以得到首幀的數(shù)據(jù)。 整條鏈路是比較長的，如果不做任何的優(yōu)化，首屏時間基本上要超過十幾個RTT。比如按照HLS的規(guī)范，m3u8和切片可以放到不同的CDN上，但是這樣就不能用同一個TCP連接去下載，需要各自建立連接再先后下載。而且建連次數(shù)多還會影響首屏成功率，因為TCP握手的成功率也只有80%，連續(xù)建兩個連接都成功的概率就只有64%了。 我們通過全流程再看幾個數(shù)據(jù)，第一個是首屏的成功率，這是一個整體的指標。錯誤率指的是在任何一個環(huán)節(jié)都有可能出錯，比如CDN可能會有錯，下載文件時可能會返回404或者403，再或者建連的時候失敗了，總之任何環(huán)節(jié)出錯，都會記到錯誤率指標中。還有主動退出率，假設用戶最終沒有觀看視頻，要么是因為出錯，要么是因為主動退出。如果是主動退出，我們還要記錄主動退出的環(huán)節(jié)和時間，這些信息對后面的優(yōu)化有很強的指導意義。

圖中展示的是我們在定義指標后采集到的一些數(shù)據(jù)，上面的橫條是啟動時間的平均值，不同的顏色代表不同的環(huán)節(jié)。最左邊深綠色為業(yè)務接口，藍色為CDN選擇，和剛剛介紹的流程一致。按照流程我們進行了一段時間的采集，通過查看平均的數(shù)據(jù)，我們發(fā)現(xiàn)用戶花費了大量的時間在下載切片文件上，這個文件可能有幾百k左右的大小，而前面一些環(huán)節(jié)可能就幾十個字節(jié)，所以看起來也比較合理。 但實際上如果我們需要優(yōu)化首屏時間，我們需要看下面的橫條，這是85分位的首屏時間分析，下載仍然是耗時最長的，不過因為前面的一些環(huán)節(jié)會占到整個環(huán)節(jié)的2/3。如果我們的目的是通過降低首屏時間來降低用戶的主動退出率，僅僅優(yōu)化下載切片的時間是不夠的，就算優(yōu)化成0，前面環(huán)節(jié)也需要5s左右的時間，用戶仍然難以接受。所以在拿到這個數(shù)據(jù)后我們再分析根本原因，很明顯是因為RTT很大，所有環(huán)節(jié)又都是串行執(zhí)行，這就會導致首屏時間變得非常長。根據(jù)數(shù)據(jù)得到結(jié)論后我們就可以定一個優(yōu)化的思路。 首屏時間優(yōu)化方案

首先看業(yè)務接口的優(yōu)化，根據(jù)各企業(yè)業(yè)務的不同，優(yōu)化方式也多種多樣。在我們的業(yè)務中像鑒權(quán)、廣告播發(fā)這樣的邏輯都可以改為異步，比如向客戶端下發(fā)一個策略，客戶端異步執(zhí)行，像續(xù)播、碼率的選擇，可以交由客戶端自己實現(xiàn)，因為客戶端可以記錄播放歷史，每次App啟動時和服務器進行同步。具體視頻開始播放時，是否續(xù)播由客戶端自行決定。這些優(yōu)化可以減少串行環(huán)節(jié)，整體流程上可以減少1-2個RTT，在非洲就可以體現(xiàn)為幾百ms甚至1秒鐘左右的時間節(jié)省。 CDN選擇包括DNS的解析其實優(yōu)化思路也是一樣的。為節(jié)省CDN的選擇時間，我們直接在列表頁上做CDN的選擇，在列表頁查看用戶的位置，將數(shù)據(jù)提供給后臺做快速選擇。APP端也可以異步選擇CDN，比如手機的網(wǎng)絡有變化，從3G到4G或者切換到WIFI，有產(chǎn)生變化的時候，APP會做一個異步的選擇解析，這樣就可以保證視頻的正常播放，同時在流程上也可以減少2個RTT。 然后就是M3U8下載的問題，要下載就必須先建立TCP連接，而TCP握手需要花1RTT。我們有2種方式來節(jié)省建連時間，第一種是CDN選擇結(jié)束后客戶端直接建立連接，然后做心跳?；睢Ｔ诜侵拮鲞B接?；詈懿蝗菀祝B接一會就斷了，發(fā)包發(fā)不過去，這時候重建連接就會浪費用戶的流量，但不重建的話，等需要下載視頻數(shù)據(jù)時重新建連會更浪費時間?？傊氄{(diào)這個?；畈呗浴? 更理想的是使用QUIC，因為它具有0RTT快速連接的特性。QUIC也需要通過握手建立連接，但因為握手包和數(shù)據(jù)包是一起發(fā)出的，從用戶的角度看，就相當于沒有握手的時間。當然也同樣會存在問題，它的生效比例不是特別高，在谷歌默認的策略里，IP變了0RTT也會失效，這其實是一個很強的約束，因為移動網(wǎng)絡的IP很容易就出現(xiàn)變化。根據(jù)實際測驗，0RTT生效的比例只有50%，谷歌自己的數(shù)據(jù)是60%左右，當然這也要考慮到地區(qū)差異性。做到上述優(yōu)化又可以節(jié)省1-2個RTT。

接下來是M3U8下載的問題。M3U8有master M3U8，也有子M3U8，而且我們用到的是fragmented MP4的封裝，沒有用TS。封裝會增加一個init.mp4文件，文件不大但需要獨立地下載，獨立下載意味著又會增加一個RTT。于是我們就將這些文件的內(nèi)容合并到視頻的URL中，用戶在訪問URL時可以直接獲取到文件內(nèi)容，無需多次單獨下載。這些文件的內(nèi)容都是文本或是字符串，我們只需要把字符串傳到客戶端，由客戶端在本地構(gòu)造M3U8等文件后給到播放器，播放器就可以正常播放。這樣做可以節(jié)省1~2個RTT。 最后是切片下載的TCP建連時間，有的公司可能會把切片和m3u8放到兩個CDN上，這樣也就必須分別建立連接，但如果切片和m3u8在同一個CDN上，我們可以用同一個連接，至少在點播上是可行的，因為點播只需要下載一次M3U8，接著下切片文件。而直播可能就不行了，因為直播的M3U8的更新和切片的更新是獨立的，它們是在兩條線并行地更新，所以這時候必須要有兩個連接去做并行的下載。而這種情況下我們對于直播的優(yōu)化策略就是建連的時候直接建立兩個連接。當然如果有使用HTTP2或者QUIC的協(xié)議就會更簡單一些，因為這些協(xié)議支持連接復用，HTTP2和QUIC的建連可能會更困難一些，因為他們建連的數(shù)據(jù)包更多，不過因為連接可以復用，總體上來說又可以減少1-2個RTT。 所以整體的優(yōu)化思路其實特別簡單，目標也很明確，RTT高本身很難優(yōu)化，那就直接減少RTT的個數(shù)。在所有的優(yōu)化完成后，通過計算我們發(fā)現(xiàn)大約減少有10個RTT，我們在最差的基礎上做優(yōu)化，最終減少10個RTT。那在現(xiàn)實中10個RTT的提升究竟是什么效果？用戶在列表頁點視頻的時候，沒有任何其他環(huán)節(jié)了，甚至連接都建好了，播放器直接去下載視頻本身的數(shù)據(jù)，下載一點數(shù)據(jù)視頻首幀就能出來，所以啟動時間會有非常顯著的改善。

這就是我們優(yōu)化的結(jié)果。之前首屏時間85分位能到7s多，這個時間對于非洲的用戶來說也是難以忍受的，但我們優(yōu)化完成以后，現(xiàn)在的時間不到3s。對于國內(nèi)的標準，雖然還是會比較長，但對于非洲用戶來說這個時間是可以接受的。 主動退出率這一塊也很明顯，之前是14%，100人看視頻，有14個人因為不愿意等就退出了，這是一個很糟糕的數(shù)據(jù)。我們做了優(yōu)化以后它降低了一半大概能到7%左右。當然還有一些用戶3s都不愿意等，我們也分析這些用戶的行為，發(fā)現(xiàn)這些用戶可能自己在操作習慣上有問題，比如他們會在頻道列表里“亂點”，1s點好幾個視頻，頻繁退出，這樣的操作在后臺還是會算成主動退出，所以總體上主動退出比例只降低了一半。但對于正常觀看視頻的用戶來說，這一首屏時間已經(jīng)可以接受了。 3.6 卡頓問題

接下來是卡頓?？D這一塊的指標體系會更簡單一些。播放器先下載M3U8，然后下載切片。如果是直播的話就輪流下載，點播就下載一次M3U8，后面不停下載切片就可以了。再往后就是緩存、解碼的過程。這一環(huán)節(jié)非常簡單。

卡頓比這一塊的優(yōu)化思路主要是提升下載速度，下載速度只有250kbps，而且播放器還不能一直下載，這就導致直播的卡頓比要比點播高得多，原因就是直播不能一直下切片，要頻繁下載M3U8。 卡頓優(yōu)化方案

這里的優(yōu)化思路就是M3U8和切片要并行下載，有一個方法是把M3U8的內(nèi)容放到切片里面去。這是一個比較有意思的改動，我們直接將M3U8的文本放到切片的http response header中，因為m3u8本身就是個字符串，這樣播放器就不用單獨下載m3u8了，只需要不停地下載切片。因為每一個切片里都自帶了下一個m3u8，這樣就節(jié)省了單獨下載m3u8的時間，整體下載速度自然也就提升了。 然后是緩沖區(qū)的優(yōu)化，因為我們不關(guān)心延遲，所以就把緩存區(qū)加到了75s。

碼率這一塊，我們用的fragmented MP4，這個封裝的Overhead很低。大家如果是用HLS，就一定要注意這個問題，因為大部分情況下HLS用的是TS封裝，而TS封裝的Overhead非常高，在小碼率下能到10%，比如音視頻原始碼流的碼率是200kbps，封裝出來就變成220kbps了，這是很不劃算的。而fragmented MP4只有1%的overhead，但同樣fMP4也有它自己的問題，它會把音頻編在前面去，視頻編在后面，這樣就會影響啟動的時間，所以我們還需要自己去做一些交織的封裝。 編碼部分，剛剛有提到過我們主要針對內(nèi)容來進行優(yōu)化，經(jīng)過處理優(yōu)化提升低碼率下的畫質(zhì)以及播放流暢性。 CDN部分，通過自建CDN、優(yōu)化CDN選擇策略等，也可以明顯提高下載速度。 最后，關(guān)于BBR/QUIC這部分還是值得說一下，起初我們使用BBR的擁塞控制算法，收益并不明顯，與預期的差別很大，后面分析得到結(jié)論可能是因為擁塞過于嚴重?？偟貋碚f，BBR算是一個相對君子一點的算法，不像cubic一樣瘋狂發(fā)包直至丟包為止，BBR是檢測到開始擁塞就停止發(fā)包，但由于非洲的網(wǎng)絡本身擁塞就很嚴重，因此BBR的收益也就沒那么顯著，后面我們還會進行一些其它的嘗試。

卡頓優(yōu)化之后的收益也是非常顯著的，在85分位下，原來直播的卡頓比有15%，現(xiàn)在不到2%，就在非洲來說這是個不錯的結(jié)果。而對于點播，85分位播放卡頓比不到1%，也是個不錯的結(jié)果。 這幾件事情做完以后我們的用戶體驗得到了很大的提升，促進了業(yè)務的發(fā)展。 3.7 優(yōu)化思路總結(jié)

最后簡單總結(jié)一下。首先，數(shù)據(jù)是改進的基礎，想準確發(fā)現(xiàn)問題需要預先埋特別多的點。如果僅靠臆想問題所在，然后直接修改程序，那結(jié)果很可能是隨機的。因此我們甚至在網(wǎng)絡協(xié)議棧中也埋了點把一部分用戶的網(wǎng)絡協(xié)議棧日志拉回來，比如每一個IP包什么時候發(fā)，什么時候丟，為什么重發(fā)，重發(fā)的是否及時，每一個數(shù)據(jù)都拉回來做分析。至于播放器和業(yè)務埋點就更基本了，一定要埋全。 其次，要在分位線上看數(shù)據(jù)，不能只看平均值，平均值會掩蓋極端的情況，結(jié)果把我們導向錯誤的優(yōu)化方向。 最后是抓核心指標，對于我們來說就是犧牲延遲，把其它指標做好。要能找到核心瓶頸并針對其進行優(yōu)化，這樣才能保證比較高的做事效率。

原文標題：海外弱網(wǎng)下的在線視頻平臺優(yōu)化實踐

文章出處：【微信公眾號：LiveVideoStack】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

責任編輯：haq