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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

責(zé)任編輯：haq