羅永浩的帶貨首秀直播間觀看人數達到千萬級，LiveXLive 直播48小時不間斷，字節跳動如何保證這些直播活動穩定無障礙？直播的全鏈路流程是什麼樣的？哪些指標能衡量直播服務的質量？如何滿足千萬級別用戶對直播平臺高併發的挑戰？
本文整理自字節跳動火山引擎高級開發工程師徐永康在 InfoQ 技術公開課的分享。本次分享主要圍繞事件直播全鏈路窺探、字節跳動直播重保實踐、如何一天內讓清北網校擁有穩定直播能力等幾個部分進行展開。
以下爲分享內容：
今天給大家帶來的分享是字節跳動千萬用戶量級直播活動技術保障實踐。
我們先來看一下直播的全鏈路是什麼樣子的。
直播全鏈路
一般來說，直播都是從音視頻的採集開始的，有屏幕採集、攝像頭採集，還有聲音的麥克風採集。視頻是YUV/RGB的格式，音頻採集後是PCM格式。然後，我們會對採集過來原始信號進行音視頻的處理，比如進行美顏、加水印、加濾鏡等工作。
音視頻處理之後，需要對一些YUV、PCM格式的裸數據進行壓縮處理。因爲這些數據量級非常大，每秒鐘傳輸需要幾百兆的帶寬，我們現在的網絡帶寬環境是承受不住的，所以要對音視頻進行壓縮處理。目前業界主流的視頻壓縮算法是H264，大家也都在往H265、VP9方向發展。經過音視頻的壓縮之後，視頻信號就變成了H264信號，音頻就變成了AAC信號，也叫ACC。然後，我們把經過編碼器壓縮之後的數據，放入推流設備中。推流設備會進行FLV的打包，變成FLV的封裝格式，用RTMP的協議進行推流。
推流一般就是用CDN來進行加速和分發。用戶的播放就是一個推流的逆向過程，先接到壓縮後的數據進行解壓縮，解壓縮之後拿到YUV和PCM數據放入播放器，再進行畫面的渲染、音頻的輸出。
大家可以看到整個音視頻的處理過程，鏈路是非常長的，在實際直播過程中，我們也會遇到一些問題。
比如音頻的音畫不同步問題，可能是用戶看到主播張嘴說話了，但是沒有聲音，聲音延遲了。這些對於用戶的感官來說都是非常不舒服的。我們的經驗是，延遲如果超過200毫秒，用戶就會有非常明顯的感知。
還有音頻反向，這個在實際直播中確實遇到過。在早先一次直播中就出現過音頻反向的問題，當時一位歌手在唱歌，但中間有一段，唱歌的聲音聽不到，只聽到一些伴奏，其實是在揚聲器合成的時候，部分音頻相互抵消了。
除此之外，也還會遇到一些音頻方面的爆音、靜音等問題。
對於視頻的話，會有一些比如摩爾條紋的問題、清晰度低的問題。清晰度低的原因可能比較多，比如攝像頭採集過來的分辨率本來就不高；或設置的編碼器參數不太合理，或者推流設備參數設置不合理。類似碼率、分辨率設置的比較低，就會讓用戶感覺清晰度低，甚至會出現馬賽克。還有就是有邊緣鋸齒現象，比如我們採集的時候是隔行的，推流的時候是逐行的，在沒有做交織的情況下，就會有邊緣鋸齒。
鏈路中還有流分發過程，流分發是藉助了CDN的加速。
簡單說一下這個環節。首先我們通過推流設備進行推流，會把它通過DNS解析到CDN邊緣節點，也就是離用戶最近的一些節點。邊緣節點會把音視頻數據推到上層節點，再推到原站。當用戶拉流的時候會從解析到的邊緣節點去拉流，邊緣節點有流的話，就會直接傳給用戶了。特別情況下，當用戶第一次進入的時候，邊緣節點沒有流，它就會回源到上層去拉流，如果上層沒有流，還會回源到源站。
整個CDN加速的過程，其實也是比較複雜的。這麼長的一個鏈路，也會出現一些問題，比如邊緣節點故障、上層節點故障、源站故障，這些都會對用戶造成或多或少的影響。邊緣節點故障如果出現在上行鏈路上，那就可能對所有用戶都造成影響，如果出現在下行鏈路，那可能只是影響部分的用戶。
還有轉碼故障。轉碼故障可能導致用戶看不了轉碼流，只能觀看源流。這種情況下，一般碼率比較高，用戶會感到明顯的卡頓。
除了這些節點故障，還有跨網傳輸。剛纔講到邊緣節點一般是離用戶最近的，同網、同運營商、同區域內。但是如果DNS解析不正常，出現了跨網傳輸，就會極大影響體驗。比如北京聯通的用戶，從北京移動去拉流，這樣的網間傳輸就會帶來非常大的質量問題，可能會拉不到流，或者是直播畫面變得非常的卡頓。
還有一種情況是帶寬不足。我們一些大型的直播，它的人數是非常多的，可能是上千萬人，這樣的話，是任何一家CDN都扛不住的。然後還會有些區域覆蓋，特別是有些區域的CDN節點比較少，這樣就會有一些跨網的覆蓋，或者是跨運營商的覆蓋，用戶量也是會感到有明顯的質量的變差。
那我們如何去評價直播的質量？一個就是QoS指標，QoS就是服務質量，目前有五個指標：拉流成功率，百秒卡頓時長，百秒卡頓次數，端到端延遲，首幀時長。
拉流成功率表示用戶能夠成功拉到流的比例是多少，拉流成功率低，說明這個流幾乎是不可用的。百秒卡頓時長和百秒卡頓次數直觀的描述了用戶觀看的過程是否流暢。端到端延遲，也叫揮手延遲，就是說主播在這端揮揮手，到用戶能夠看到這個揮手的動作，中間所持續的時間是多長，主要需要降低端到端延遲。首幀時長是從點開直播，到看到了第一幀畫面中間所持續的時間。
這些QoS指標，我們會更細化到一些維度上面去，比如就是直播流、清晰度、主備線路、CDN、應用、省份、運營商、操作系統、版本號等等。我們通過這些維度能夠很快的歸因出，目前影響直播質量的到底是哪一個環節。
還有QoE指標，就是體驗質量。QoE指標有次均觀看時長，同時在線人數，還有萬條評論報卡率。特別是次均觀看時長和同時在線人數這兩個是比較相近的，如果它出現較大的變化的時候，比如用戶突然之間走了並不一定是服務出現問題，它也可能是直播內容不夠精彩，這時候次均人員觀看時長、同時在線人數就會有一個明顯的下降。
但是反過來，如果要是QoS指標出現問題，那麼它一定會影響到QoE指標。比如說拉流成功率突然降低了，CDN的結點出現故障了，這時候很多用戶是被強迫卡出去的，並不是我們的內容不精彩，在同樣內容情況下，是用戶看不到流了進不來了。這時候我們的次均觀看時長會降低，同時在線人數也會降低。這兩者有相互借鑑的一個作用，應該兩個結合起來去看問題，
然後萬條評論報卡率就是我們發評論的時候，主播可能是看不到的。比如主播是在全屏分享PPT，但是大家可能會在評論區發一些關於直播內容的消息，比如他們會說“好卡，已經卡了”。這些其實是非常重要的一些信息，我們可以把這個評論的內容收集過來，作爲一個QoE指標，將這些報卡的用戶比例與百秒卡頓時長、百秒卡頓次數這些Qos指標相互借鑑，我們會發現，報卡率也是一個非常正向的，非常有借鑑意義的一個QoE指標。
還有清晰度的問題，比如說畫面質量模糊，有馬賽克，看不清，這些也是一些QoE指標。我們目前也在梳理這些，我們也想把它作爲一個評論畫面質量相關的一個QoE指標。這個QE指標我們也把它細分到好多個維度：直播流，清晰度，主備線路，CDN度，應用。
事件直播
剛纔給大家簡單介紹了直播的全鏈路是什麼樣子，也列出了各個環節可能造成的質量相關的問題的風險點，以及如何用QoS和QoE指標去評價直播的質量，對直播的質量進行量化，如何去優化這些直播的質量，現在我們就來看一下字節跳動在事件直播的過程中一些重保實踐。
首先說一下什麼是事件直播。簡單舉幾個例子，比如抖音盛典，西瓜Play，頭號英雄，頭條盛典，跨年直播，火山盛典，LiveXlive48小時不間斷直播，羅永浩的首秀，當然還有一些明星的直播，比如汪峯、王祖藍、陳赫、AngelaBaby、張庭，他們都進行過直播帶貨。除此之外，還有草莓音樂節，SpaceX發射，清北網校在線課堂等等，這些都是屬於事件直播。
通過這些關鍵詞，我們可以簡單的概括事件直播是由組織發起的、非日常的開播，不是一個人對着手機或者是遊戲的開播。它的目的性比較強、主題比較明確，比如明星直播帶貨，它的目的就是直播帶貨；頭條盛典，火山盛典，抖音盛典，它們都是一場晚會。還有一個特點是影響力比較大，受衆廣泛。每一場事件直播都有很大的目標羣體，動輒就是幾十萬，上百萬，甚至近千萬的用戶觀看。
對我們而言，事件直播是值得花大力氣去保證的直播。這麼多的直播類型，形式都非常的不一樣，有的是一個機位，有的是多個機位，很難面面俱到的去覆蓋每一場場景，很難有一個統一的重保規範去覆蓋這些場景。重保需要case by case的去分析，梳理過程中可能存在的風險點，然後制訂一些重保方案。
通過這些的重保活動，我還是梳理出了一個比較通用的直播重保架構。
大家可以看一下上面這個圖，首先信號採集部分，可能會有多個機位，多個信號源。信號源把信號傳輸到導播臺，導播臺進行信號切分，最終會把信號傳到延遲器。延遲器把信號傳到推流器，推流器進行音視頻的編碼，壓縮，然後把它推到CDN網絡上去。上行是一個CDN，下行可能會掛在多個CDN去分發，就是多條線路，然後用戶從這些線路里面去選擇其中的一個去進行觀看，這是主要的流程。
通過上圖，大家可以看到，其中比較明顯的是從導播臺出來的信號是完全翻成了左右兩部分，就是主、備線路。左邊是個主線路，右邊是個備線路，主備是完全正交的。左側任何一個節點出現問題，都可以讓用戶去用備線路去拉流，這個也是自動實現的。
那麼導播臺這個地方爲什麼沒有去用主備導播臺呢？主要是因爲導播臺是有旁通的功能，它都是一些硬件設備的，至少目前是沒有出現過故障的，還有就是如果即使換成主備導播臺，就要求主備導播臺出的信號完全一致，但這個不是能夠輕易現實的。
然後延遲器，上圖虛線部分，意思是說延遲器我們是可以選擇的。延遲器的作用，主要是對內容進行容災。比如有些舞臺事故不希望讓用戶看到，就會在延遲器裏把事故的片段切掉，這樣用戶看到的是一段跳過去的內容。還有就是墊片，我們把它同時放到了導播臺、推流器、上行CDN。有些不同的容災的級別，比如傳入的信號出現了問題，這時候用導播臺去推墊片，然後把墊片放到推流器，我們容的是導播臺、延遲器這一層面的故障。也就是說進推流器的音視頻信號出現問題，我們就用推流器去推這個墊片，讓用戶看到的主備還是一樣的。不至於看到一個空白的黑屏，或者是說是一直在那裏轉圈圈。
還有大家可以看到導播臺出來了一個旁路信號，就是進了監視器，這個監視器代表着從導播臺出來的信號是被用戶可以看到的內容。
我們這裏能夠完整呈現包括導播臺輸出的音視頻的信號，一個是有個畫面顯示，另一個是有一個錄製功能，能夠在這裏把信號錄下來。前面提到的一個活動上出現的音頻反向，就是通過這個監視器錄製的信號，讓導播團隊知道是他們導出來的信號有問題。且不是在延遲器，或者是推流器，或者是CDN這一層面出現的反向問題。還有主備CDN下面會掛載多個線路，是爲了容災，每個線路都是一個CDN進行分發，其中線路一出現了問題，我還可以讓用戶切換到線路二和線路三去。
另外一些大型直播的用戶量級非常大，一條CDN線路是沒法承載這麼多用戶的。所以也得需要多個線路、多個CDN去共同承擔用戶的直播分發。我們有專門的人員劃分去進行不同的重保。人員劃分主要分爲上行容災、下行容災，還有體驗容災。對直播上行來說，主要是容的網和電。我們會在現場備一個UPS，就是不間斷電源。即使市電斷了，我們也可以再用UPS撐很長一段時間。網絡一般看活動的重要程度，有可能會拉專線，也有可能是用4G和Wi-Fi互備。當然也有可能是用聚合路由把信號聚合起來。
除了網和電的容災，還有是對內容的容災。比如推墊片，還有延時器的裁剪，這些是上行的一些容災措施。
下行的保障，主要是通過鏈路層面的保障能正常推到CDN上去。但是用戶觀看可能是受影響的，這時候我們可能會有一些主備切換。
另外還有清晰度的降級，主要轉碼流故障，或線路的調整，或CDN線路出現問題，我們會切換到另一個CDN線路上去。
還有一部分是負責體驗容災的，就是體驗保障。當用戶反饋卡頓，或者是不清晰，這時候會設置播放器的緩存，通過增加緩存來減少用戶的卡頓。還有區域運營商線路調整，當用戶在某一個區域運營商的時候比較卡頓，比較有集中性，那我們就會把這一個區域運營商的用戶換CDN去覆蓋。節點的調整，是某一個節點下的用戶出現問題，就讓用戶去用別的節點去覆蓋，從別的節點去拉流。降級的操作主要有音視頻信號的同步處理，音頻單聲道拷貝，主備切換，拉流轉推，設置房間默認清晰度，降低轉碼碼率，摘除轉碼，調整CDN權重。設置播放緩存，區域運營商切換CDN，節點優選，下掉CDN節點等等。
直播質量優化
直播質量的優化，首先是對普通用戶的優化，就是轉碼檔位設置。提升清晰度，一般情況下是提升碼率或者分辨率。但是什麼樣的碼率配置什麼樣的分辨率是需要去做嘗試的。首先我們得有一個平臺把不同編碼的左右兩個圖片參數編出來，然後進行對比打分，同樣的碼率下是480P還是540P更加好一些。
除了主觀打分，還有一些客觀的質量評判標準來進行評判。我們可以看到，並不是隨着碼率升高，清晰度是一直往上增加的，達到了一定的程度後，其實會趨於平緩，這時人們就感受不到碼率變高帶來的清晰度的改善。然後我們的經驗是說在1M以下，會分發480 P。在1-2M之間，可能會分發540 P。在2M以上，可能就會分發720 P。
還有針對一些弱網的用戶，是網絡不太好的用戶，比如4G用戶到了月底限流了，只能用幾百K的速度帶寬去觀看直播，這種情況我們其實也有一些優化，通過傳輸協議和丟幀策略優化。
現在國內主要就是FLV，然後還有HLS，RTMP，但是所有底層的傳輸協議還是用的TCP。TCP的超時重傳、擁塞控制都不是那麼好改變。除了TCP還有UDP。UDP沒有三次握手，包頭會比較小一點，這樣傳輸會更快一些。比如KCP， QUIC，是基於UDP實現的可靠傳輸。
丟幀策略有優雅丟幀、傳輸層丟幀、音視頻分離。音視頻分離其實是一種更極端的丟幀方式。在非常卡的情況下，我們可能只播放音頻，不播放視頻，這樣的話相當於把視頻全丟掉。
具體怎麼樣選擇協議和策略，我們可以通過上圖來看。首先我們對用戶的播放器日誌進行收集和數據分析。通過時段、設備類型、國家城市、運營商、觀看時長這些，最終去進行識別分類出一些指標，比如RTT、丟包率、帶寬、活動週期、碼率、觀看時長、卡頓數據、清晰度。然後把這些指標應用於模型訓練。通過模型我們進行策略的匹配與下發。決策出當前用戶在當前的網絡下，用TCP還是用基於UDP的KCP 、QUIC，以及初始參數、擁塞策略、丟包策略。同時根據最終用戶的觀看效果，QoS指標和QoE指標效果反饋到網絡模型上去進行進一步的優化。
除此之外我們還有對一些特徵的私有化部署。之前我們有一場發佈會活動，我們沒有想到用戶會有那麼多，當時幾乎是所有的同事在辦公環境下一起觀看直播，分配下來每一個人幾兆帶寬。因爲都是從公司的入口網關處拉流進來，這樣最先崩潰的是我們公司的網絡入口。這種情況下，我們就需要通過私有化部署來解決這個問題。現在我們內網的一些分享之類的全都通過私有化部署來解決了。
私有化部署是把CDN的邊緣節點部署到人員比較密集的地方去，比如每個辦公區部署一個節點。比如圖中紫色的部分，就是邊緣節點，綠色的就是一個辦公區。所有辦公區的用戶，我們通過DNS劫持，把他們通過同一個播放地址去拉流。私有化部署帶來的好處一個是信息安全，防止泄露，有一些活動分享其實是有保密性的，不希望能夠被外界感知到，所以私有化部署就很好地解決這個問題，並能解決入口帶寬的瓶頸。
直播賦能
賦能的一個比較典型的例子，就是在疫情期間，一天時間我們讓清北網校擁有了空中課堂的直播能力，並且保證了直播的穩定和質量。上圖是清北網校的網站，首先給直播開闢了一個單獨的入口，爲全國中小學生免費提供直播系統。快速搭建清北網校主要得益於下面5點：
- 一個是快速搭建頁面的能力，就是所見即所得。
- 頁面組件化，一行代碼能夠遷入。
- 完善的直播保障和容災體制機制。
- 支持推拉入等多種開播方式。
- 支持字節旗下的多平臺互通分發。
我們會用一個平臺重保管理，有一些操作都能夠自動進行，比如可以通過指示燈表述直播狀態。我們還可以進行自動巡檢，判斷是否可以自動做一些降級操作。我們還可以記錄歷史的報警信息等等。同時我們也提供了這個直播伴侶，客戶端，用直播伴侶客戶端可以直接進行開播操作。