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

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

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

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

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

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

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

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

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

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

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

在了解了非洲網(wǎng)絡(luò)延遲與丟包的情況后，我們想定位一下這些問題究竟發(fā)生在哪個環(huán)節(jié)，隨后再去尋找相應(yīng)的解決辦法。上圖是從手機發(fā)送請求到最后IDC中的服務(wù)器收到并響應(yīng)的過程。一開始用戶的手機需要先連接基站，向基站發(fā)送無線信號，基站內(nèi)部處理后，把網(wǎng)絡(luò)的請求通過運營商的互聯(lián)網(wǎng)出口傳出，隨后有一個更大的互聯(lián)網(wǎng)，但其實這里面有很多層網(wǎng)絡(luò)供應(yī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 確定問題所在

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

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

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

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

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

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

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

使用上面提到的自建CDN服務(wù)器，在調(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)度上需要更加謹(jǐn)慎。 其次是運營商網(wǎng)內(nèi)的出口不穩(wěn)定，原因是非洲的運營商運維水平有限。舉個例子，我們的一個CDN服務(wù)器連接到機房的交換機上，再從交換機出去，有時候機房交換機會丟包，如無任何征兆地丟包90%。運營商自己也沒有監(jiān)控，每次都是我們發(fā)現(xiàn)問題后，聯(lián)系重啟交換機進行解決——這其實很影響用戶體驗。 另外就是一些球賽、演唱會場景，這些場景對于做視頻的人來說就和“秒殺”的性質(zhì)是一樣的，會瞬間進來一大批人，運營商的網(wǎng)內(nèi)出口可能就直接被打爆了。 在發(fā)現(xiàn)這些問題后，對于CDN調(diào)度就需要做針對性處理，主要有以下3種策略： 1. 基于用戶體驗的調(diào)度：對于上述機房交換機的問題，即無征兆地出錯而且也不報警，我們在播放器中加了很多埋點，通過播放器實時上報卡頓、啟動成功率、下載速度等指標(biāo)，后臺獲取到這些信息進行實時分析，分析結(jié)果可作為調(diào)度策略的參考輸入。假設(shè)運營商網(wǎng)內(nèi)出口不穩(wěn)定，盡管這種情況下CDN本身沒問題，但用戶體驗極差，則用戶體驗指標(biāo)會報警，調(diào)度系統(tǒng)就會將用戶調(diào)至備用CDN。 2. 基于CDN狀態(tài)的調(diào)度：這點比較基礎(chǔ)，例如CDN服務(wù)器出現(xiàn)故障、機房網(wǎng)絡(luò)不通、或者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)絡(luò)本身就不太好，鋪設(shè)CDN后有一定的改善，但僅僅是少量的提升，并沒有質(zhì)的飛躍，更多的優(yōu)化需要從技術(shù)的角度進行。 具體可以總結(jié)為以下幾個層面： 業(yè)務(wù)接口的異步化：在播放視頻時，用戶會認(rèn)為點開視頻的鏈接，視頻就應(yīng)該開始播放，但實際上業(yè)務(wù)后臺還要做很多事情，比如鑒權(quán)，廣告等一些策略，這些策略如果是串行執(zhí)行的，會對首屏?xí)r間有很大影響。 網(wǎng)絡(luò)層的優(yōu)化指通過優(yōu)化傳輸協(xié)議、擁塞控制算法等提升下載速度、降低建連時間對首屏?xí)r間的影響等。 視頻封裝優(yōu)化可以減少播放器與CDN的交互次數(shù)，從而減少首屏?xí)r間、降低卡頓。 視頻編碼優(yōu)化可以降低碼率，同樣可以減少首屏?xí)r間、降低卡頓率。 流媒體協(xié)議選擇

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

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

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

首先看業(yè)務(wù)接口的優(yōu)化，根據(jù)各企業(yè)業(yè)務(wù)的不同，優(yōu)化方式也多種多樣。在我們的業(yè)務(wù)中像鑒權(quán)、廣告播發(fā)這樣的邏輯都可以改為異步，比如向客戶端下發(fā)一個策略，客戶端異步執(zhí)行，像續(xù)播、碼率的選擇，可以交由客戶端自己實現(xiàn)，因為客戶端可以記錄播放歷史，每次App啟動時和服務(wù)器進行同步。具體視頻開始播放時，是否續(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)絡(luò)有變化，從3G到4G或者切換到WIFI，有產(chǎn)生變化的時候，APP會做一個異步的選擇解析，這樣就可以保證視頻的正常播放，同時在流程上也可以減少2個RTT。 然后就是M3U8下載的問題，要下載就必須先建立TCP連接，而TCP握手需要花1RTT。我們有2種方式來節(jié)省建連時間，第一種是CDN選擇結(jié)束后客戶端直接建立連接，然后做心跳?；睢Ｔ诜侵拮鲞B接?；詈懿蝗菀?，連接一會就斷了，發(fā)包發(fā)不過去，這時候重建連接就會浪費用戶的流量，但不重建的話，等需要下載視頻數(shù)據(jù)時重新建連會更浪費時間?？傊?xì)調(diào)這個?；畈呗?。 更理想的是使用QUIC，因為它具有0RTT快速連接的特性。QUIC也需要通過握手建立連接，但因為握手包和數(shù)據(jù)包是一起發(fā)出的，從用戶的角度看，就相當(dāng)于沒有握手的時間。當(dāng)然也同樣會存在問題，它的生效比例不是特別高，在谷歌默認(rèn)的策略里，IP變了0RTT也會失效，這其實是一個很強的約束，因為移動網(wǎng)絡(luò)的IP很容易就出現(xiàn)變化。根據(jù)實際測驗，0RTT生效的比例只有50%，谷歌自己的數(shù)據(jù)是60%左右，當(dāng)然這也要考慮到地區(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)化策略就是建連的時候直接建立兩個連接。當(dāng)然如果有使用HTTP2或者QUIC的協(xié)議就會更簡單一些，因為這些協(xié)議支持連接復(fù)用，HTTP2和QUIC的建連可能會更困難一些，因為他們建連的數(shù)據(jù)包更多，不過因為連接可以復(fù)用，總體上來說又可以減少1-2個RTT。 所以整體的優(yōu)化思路其實特別簡單，目標(biāo)也很明確，RTT高本身很難優(yōu)化，那就直接減少RTT的個數(shù)。在所有的優(yōu)化完成后，通過計算我們發(fā)現(xiàn)大約減少有10個RTT，我們在最差的基礎(chǔ)上做優(yōu)化，最終減少10個RTT。那在現(xiàn)實中10個RTT的提升究竟是什么效果？用戶在列表頁點視頻的時候，沒有任何其他環(huán)節(jié)了，甚至連接都建好了，播放器直接去下載視頻本身的數(shù)據(jù)，下載一點數(shù)據(jù)視頻首幀就能出來，所以啟動時間會有非常顯著的改善。

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

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

卡頓比這一塊的優(yōu)化思路主要是提升下載速度，下載速度只有250kbps，而且播放器還不能一直下載，這就導(dǎo)致直播的卡頓比要比點播高得多，原因就是直播不能一直下切片，要頻繁下載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的擁塞控制算法，收益并不明顯，與預(yù)期的差別很大，后面分析得到結(jié)論可能是因為擁塞過于嚴(yán)重?？偟貋碚f，BBR算是一個相對君子一點的算法，不像cubic一樣瘋狂發(fā)包直至丟包為止，BBR是檢測到開始擁塞就停止發(fā)包，但由于非洲的網(wǎng)絡(luò)本身擁塞就很嚴(yán)重，因此BBR的收益也就沒那么顯著，后面我們還會進行一些其它的嘗試。

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

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

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

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

責(zé)任編輯：haq