最后一公里：從直播拉流讀懂直播鏈路

　　端監(jiān)控作為日志上報(bào)的起點(diǎn)，將客戶端產(chǎn)生的各類日志按照一定的規(guī)則(例如采樣率等)，進(jìn)行上報(bào);根據(jù)不同的 log_type，上報(bào)的日志會(huì)被分流并寫入到 Kafka 的不同 topic 中;根據(jù)數(shù)據(jù)不同的消費(fèi)場景及用途，日志會(huì)經(jīng)歷一系列處理(例如在 Flink 任務(wù)中進(jìn)行清洗等)，并最終呈現(xiàn)到各類數(shù)據(jù)工具當(dāng)中。

　　了解日志數(shù)據(jù)流對于定位日志相關(guān)的各類問題是非常有幫助的。例如在 Kibana 中找不到日志時(shí)，可以從日志是否上報(bào)(通過 Charles 抓取端監(jiān)控 monitor 接口上報(bào)數(shù)據(jù)確認(rèn))、分流是否正確(通過檢查 log_type 確認(rèn)，一般不會(huì)在該環(huán)節(jié)出現(xiàn)問題)、是否由于日志中存在非法字段而被清洗(通過檢查端監(jiān)控中的原始日志確認(rèn))等。

　　從直播鏈路理解優(yōu)化與問題

　　為什么拉不到流?

　　直播是一條完整的鏈路，鏈路上任何一個(gè)環(huán)節(jié)中斷都會(huì)導(dǎo)致拉流端出現(xiàn)拉流失敗的情況：

　　推流端-收流節(jié)點(diǎn)中斷：單路流所有檔位、所有觀眾將出現(xiàn)進(jìn)房時(shí)拉不到流或直播間內(nèi)卡頓;

　　收流節(jié)點(diǎn)-源站中斷：一般不會(huì)出現(xiàn)，故障源站上的所有流將出現(xiàn)異常;

　　轉(zhuǎn)碼異常：某一個(gè)或幾個(gè)轉(zhuǎn)碼檔位出現(xiàn)異常，源流正常，觀看轉(zhuǎn)碼檔位的觀眾報(bào)障;

　　源站-拉流節(jié)點(diǎn)中斷：從故障邊緣節(jié)點(diǎn)上拉流的全部觀眾將會(huì)異常;

　　拉流節(jié)點(diǎn)-拉流端中斷：單用戶拉流出現(xiàn)故障。

　　前述情況主要描述的鏈路上某個(gè)環(huán)節(jié)中斷導(dǎo)致的拉流失敗，有時(shí)拉流失敗其實(shí)是首幀耗時(shí)過長造成的，這種情況在拉流成功率指標(biāo)波動(dòng)分析時(shí)較為常見：首幀耗時(shí)增長導(dǎo)致了拉流成功率下降。

　　為什么首幀慢?

　　首幀分階段分析

　　以 HTTP-FLV 為例，從觸發(fā)播放器的 play 接口到最終完成首幀渲染，需要經(jīng)歷以下這些過程：

　　DNS 解析： 決定了要從 CDN 的哪個(gè)邊緣節(jié)點(diǎn)拉流。這一過程在拉流 SDK 以及播放器內(nèi)核中都會(huì)發(fā)生，后者往往是因?yàn)?SDK 層沒有解析到 IP 地址。DNS 解析耗時(shí)通常在 100ms 左右(localDNS，使用 HTTP-DNS 會(huì)進(jìn)一步增加)，因此 HTTP 場景下，我們可以采用 IP 直連的方式規(guī)避 DNS 耗時(shí)。

　　實(shí)現(xiàn) IP 直連需要在拉流前獲取到 IP 地址，其關(guān)鍵在于 DNS 緩存(緩存之前的 DNS 解析結(jié)果，拉流 SDK 層的 DNS 策略)和 DNS 預(yù)解析(在 App 啟動(dòng)之后一段時(shí)間，對可能用到的所有域名進(jìn)行 DNS 解析并緩存結(jié)果，節(jié)點(diǎn)優(yōu)選 SDK 的核心邏輯);

　　緩存的 DNS 結(jié)果會(huì)過期，尤其是 CDN 進(jìn)行節(jié)點(diǎn)覆蓋調(diào)整時(shí)，緩存的 DNS 可能會(huì)導(dǎo)致調(diào)整不能及時(shí)生效，因此需要定期更新 DNS 結(jié)果;

　　用戶發(fā)生跨網(wǎng)時(shí)，由于運(yùn)營商變化，也會(huì)導(dǎo)致此前緩存的 DNS 不可用，因此需要在網(wǎng)絡(luò)狀態(tài)發(fā)生變化時(shí)更新 DNS 結(jié)果。

　　TCP 建聯(lián)： 與邊緣節(jié)點(diǎn)建立 TCP 連接，這一過程的耗時(shí)主要是三次握手，耗時(shí)1-RTT。要優(yōu)化建聯(lián)耗時(shí)，可以通過 TFO(TCP Fast Open，Wiki)，或使用 UDP 協(xié)議(QUIC、KCP)。

　　TCP 首包： HTTP 響應(yīng)完成，此時(shí)開始返回音視頻數(shù)據(jù)。如果此時(shí)邊緣節(jié)點(diǎn)上有這路流的緩存，那么將直接返回緩存數(shù)據(jù);如果沒有命中緩存，TCP 首包返回之前將發(fā)生回源。要優(yōu)化首包耗時(shí)，核心思路在于降低回源率，常見手段有增加邊緣節(jié)點(diǎn)緩存保持時(shí)間，對于大型活動(dòng)提前進(jìn)行預(yù)熱、以保證更多邊緣節(jié)點(diǎn)上有緩存。

　　視頻首包： 耗時(shí)主要發(fā)生在 avformat_find_stream_info 函數(shù)調(diào)用，播放器在播放前需要探測一定量的流數(shù)據(jù)，以確定流格式、編碼等流信息。由于目前在各個(gè)宿主中播放的格式相對固定，因此不需要探測過多的數(shù)據(jù)即可確定流信息。所以可以通過調(diào)節(jié)探測的數(shù)據(jù)量以優(yōu)化視頻首包耗時(shí)。通過減小探測數(shù)據(jù)量，首包耗時(shí)下降 300ms 左右。

　　降低流數(shù)據(jù)探測的數(shù)據(jù)量也可能會(huì)帶來不良后果。當(dāng)探測的數(shù)據(jù)量過少時(shí)，可能會(huì)導(dǎo)致讀取到的流信息不全，例如只探測到音頻數(shù)據(jù)、沒有探測到視頻數(shù)據(jù)(尤其是在音視頻數(shù)據(jù)交織不均勻的情況)，最終出現(xiàn)有聲無畫或聲音正常、畫面卡住的問題。

　　視頻首幀解碼和視頻首幀渲染： 分別完成視頻首幀解碼和視頻首幀渲染，優(yōu)化的主要方向是 decoder 及 render 實(shí)例的預(yù)初始化等。

　　快啟buffer

　　為了實(shí)現(xiàn)秒開，各家 CDN 都在邊緣節(jié)點(diǎn)上開啟了快啟 buffer 策略。快啟 buffer 的核心邏輯是基于邊緣節(jié)點(diǎn)上的緩存(GopCache)，調(diào)節(jié)緩存數(shù)據(jù)下發(fā)的具體數(shù)據(jù)范圍，同時(shí)保證視頻數(shù)據(jù)從關(guān)鍵幀開始下發(fā)�？靻� buffer 也存在不同的策略，例如上限優(yōu)先或下限優(yōu)先，后者會(huì)要求對接的 CDN 廠商按照下限優(yōu)先的原則下發(fā)緩存數(shù)據(jù)，比如下限 6s ，會(huì)先在緩存數(shù)據(jù)中定位最新 6s 的數(shù)據(jù)，然后向 6s 前的舊數(shù)據(jù)查找第一個(gè)關(guān)鍵幀下發(fā)(解碼器要從關(guān)鍵幀開始解碼，因此一定需要從關(guān)鍵幀開始下發(fā))。

　　詞語釋義：

　　IP 直連： 即將 HTTP 地址中的 host 部分直接替換為對應(yīng)的IP地址，并在 HTTP 請求的header中添加“Host”行，其值為原始的host，例如http://``x``.``x``.``x``.``x``/``app``/``stream`` .flv "Host: ``pull-host``.com\r\n"。前述方法最為規(guī)范，有的 CDN 也會(huì)支持在 host 前直接插入 IP 的方式實(shí)現(xiàn) IP 直連，但該方法并不通用，因此并不建議使用前插 IP 的方法。

　　為什么會(huì)卡頓?

　　拉流發(fā)生卡頓的直接原因是播放器中的緩存耗盡，此時(shí)播放器卡住其實(shí)是在進(jìn)行 Rebuffering 。

　　導(dǎo)致 buffer 耗盡的直接原因是播放器中 buffer 消費(fèi)的速度高于 buffer 接收的速度：最為常見的例子就是當(dāng)前拉流端的帶寬顯著低于視頻的碼率。同時(shí)，在帶寬充足的情況下，鏈路上前置環(huán)節(jié)的中斷也有可能導(dǎo)致拉流端卡頓。

　　因此為了對抗卡頓，一個(gè)最直接的方法就是在播放器中緩存更多數(shù)據(jù)，以期在緩存數(shù)據(jù)耗盡之前渡過網(wǎng)絡(luò)波動(dòng)。最直接的做法就是增大播放器的最大緩存，使播放器能夠緩存足夠多的數(shù)據(jù)。

　　但直播場景的特殊性在于直播內(nèi)容是實(shí)時(shí)產(chǎn)生的，在最大緩存允許的情況下，播放器中的緩存完全取決于當(dāng)前鏈路上有多少緩存(還記得 GopCache 嗎)。

　　在播放器數(shù)據(jù)消費(fèi)速度不變、帶寬充足的情況下，播放器在獲得了鏈路上所有的緩存后，buffer長度將不再變化，也就意味著播放器只能依賴這些緩存來對抗卡頓。在能獲得的緩存總量有限的情況下，進(jìn)一步增強(qiáng)現(xiàn)有的緩存對抗卡頓能力的手段就是調(diào)整播放器消費(fèi)數(shù)據(jù)的速度，例如在首幀之后判斷當(dāng)前水位( buffer 長度)以決定是否起播(對應(yīng)起播 buffer 策略)，或在水位較低時(shí)降低播放速度(對應(yīng)網(wǎng)絡(luò)自適應(yīng)策略)。

　　在有限的帶寬條件下，如果能夠更有效的利用帶寬、采用更加高效的傳輸協(xié)議，也可以有效地對抗弱網(wǎng)條件下的卡頓問題。因此 KCP、QUIC、QUICU 等相較于 TCP 更加高效的協(xié)議被應(yīng)用到了音視頻傳輸當(dāng)中。除此之外，在特定的帶寬情況下選擇合適的碼率，也是降低卡頓的有效手段之一，因此ABR也在直播中得到了應(yīng)用。

　　實(shí)際上“卡頓”在用戶反饋中涵蓋的情況很多，例如：App 本身的卡頓，或者 CDN 某些操作(數(shù)據(jù)積壓時(shí)丟棄視頻數(shù)據(jù)造成的視頻卡住、聲音正常，或者在數(shù)據(jù)積壓時(shí)主動(dòng)使播放器報(bào)錯(cuò)發(fā)生重試進(jìn)而導(dǎo)致播放器出現(xiàn)鬼畜)，甚至視頻本身幀率較低，都會(huì)導(dǎo)致用戶出現(xiàn)“卡頓”的感覺。為了更加貼近用戶對于卡頓的感受，我們增加了視頻渲染卡頓這一指標(biāo)。

　　為什么有延遲?

　　為了對抗卡頓，我們需要在直播鏈路中增加緩存，但是緩存的引入必然導(dǎo)致延遲的增加。

　　例如在抖音上線低延遲 FLV 之前，端到端延遲在5~8s，而這些延遲的引入主要原因就在于 CDN 邊緣節(jié)點(diǎn)上的 GopCache --只有緩存到足夠的數(shù)據(jù)才會(huì)進(jìn)行下發(fā)，在這個(gè)過程中便引入了時(shí)延(當(dāng)然不管是推流端采集、服務(wù)端中間鏈路都會(huì)引入延遲，但是相對于緩存引入的延遲影響較小)。

　　在客戶端播放速度不變的情況下，延遲會(huì)一直保持下去，另外在發(fā)生卡頓(且未觸發(fā)重試)時(shí)延遲會(huì)不斷累積。

　　因此通過調(diào)節(jié)邊緣節(jié)點(diǎn)的 GopCache 大小可以直接影響到鏈路上的端到端延遲。與此同時(shí)，Gop 的大小也會(huì)影響到不同用戶之間的延遲差，在具體場景中就體現(xiàn)為兩個(gè)觀眾的延遲存在差異(比如內(nèi)購會(huì)別人看到主持人說了“3、2、1，開搶”，你才看到“3”)，兩名觀眾進(jìn)入直播間的時(shí)間差即使很短，但是延遲差可能達(dá)到一個(gè) Gop(以下圖為例，假設(shè)快啟 buffer 下限為 1.3s ，用戶分別在 1.2s 和 1.4s 進(jìn)入直播間，延遲分別是多少?)。

　　為了更好地保證觀眾端的延遲體驗(yàn)，我們在全面梳理了線上的延遲產(chǎn)生原因，實(shí)現(xiàn)了低延遲 FLV 方案，使得線上端到端延遲由 7s 左右下降至 3.5s 左右，并在抖音取得了顯著的 QoE 正向收益;與此同時(shí)，RTM 低延遲拉流方案也在穩(wěn)步推進(jìn)中。

　　如何判斷拉流異常問題的發(fā)生環(huán)節(jié)?

　　問題定位一般流程

　　如前文所述，直播是一個(gè)全鏈路的業(yè)務(wù)形態(tài)，尤其是拉流端處在整個(gè)鏈路的末端，各個(gè)環(huán)節(jié)的問題都會(huì)導(dǎo)致拉流端出現(xiàn)異常。因此如何根據(jù)現(xiàn)有信息及工具來定位問題的根源，便是解決問題的關(guān)鍵。定位問題一般要經(jīng)歷以下過程：

　　對于各類問題，首先需要的是明確的case與信息，針對具體case，需要的信息有：

　　拉流端device_id或user_id

　　問題現(xiàn)象描述(至少提供roomID或者流名)

　　問題發(fā)生時(shí)間

　　最好提供錄屏

　　在Trace平臺(tái)，根據(jù)前述信息檢索相關(guān)日志，可以根據(jù)問題現(xiàn)象進(jìn)一步查找對應(yīng)的事件(對應(yīng)event_key字段)

　　拉不到流?找到play_stop事件

　　根據(jù)first_frame_blocked字段判斷首幀卡在哪個(gè)階段

　　根據(jù)code字段判斷錯(cuò)誤碼是什么(錯(cuò)誤碼是0?還記得拉不到流的部分原因是首幀慢嗎?)

　　首幀慢?找到first_frame事件

　　根據(jù)前文中分階段耗時(shí)對應(yīng)的字段，尋找存在顯著異常的階段

　　卡頓?找到stall事件

　　根據(jù)流名查詢對應(yīng)時(shí)間點(diǎn)推流端的推流情況，是否推流端卡頓

　　根據(jù)拉流端在問題時(shí)間段前后的日志信息判斷是持續(xù)性卡頓、短時(shí)間波動(dòng)還是流相關(guān)卡頓

　　如果找不到stall事件，只有render_stall，那么可能的原因就是發(fā)生了丟幀

　　例如花屏、綠屏之類的問題，在日志上一般沒有特別明顯的錯(cuò)誤，此時(shí)可以通過查看流回放判斷源流是否有異常。如果源流回放沒有異常，且用戶播放轉(zhuǎn)碼流，且流已經(jīng)結(jié)束的情況下，就需要運(yùn)營同學(xué)持續(xù)關(guān)注相關(guān)反饋，盡可能保留現(xiàn)場(因?yàn)檗D(zhuǎn)碼流不會(huì)進(jìn)行錄制)。

　　問題范圍與定位方向

　　除了前述定位問題的一般過程，問題發(fā)生的范圍也是快速定位問題的有效依據(jù)。一般有以下判斷方法，根據(jù)問題(同一時(shí)間段)發(fā)生在不同用戶或場景判斷：

　　所有主播及觀眾 --> 這種情況非常少見，如果出現(xiàn)，一般意味著出現(xiàn)了整個(gè)系統(tǒng)級別的問題

　　單個(gè)主播的所有觀眾 --> 推流端本身或推流端到邊緣節(jié)點(diǎn)或源站引起，如果到邊緣節(jié)點(diǎn)日志正常，一般為源站問題

　　同一CDN下的多個(gè)主播的所有觀眾 --> 收流節(jié)點(diǎn)問題(收流節(jié)點(diǎn)相同)或源站問題(收流節(jié)點(diǎn)不同)

　　單個(gè)主播的部分觀眾(僅轉(zhuǎn)碼流觀眾或僅源流觀眾) --> 源站轉(zhuǎn)碼問題(默認(rèn)分辨率的存在導(dǎo)致判斷易受影響，如果只有轉(zhuǎn)碼流播放，那么發(fā)生問題即使的是源流，最終反饋問題的也只有轉(zhuǎn)碼流觀眾)

　　單個(gè)主播的部分觀眾(某一地區(qū)) --> 分發(fā)CDN問題，一般是某一節(jié)點(diǎn)問題，層級因地區(qū)而異

　　單個(gè)主播的部分觀眾(CDN聚集) --> 分發(fā)CDN問題，這種情況一般出現(xiàn)在活動(dòng)，有多家CDN參與分發(fā)

　　全量用戶(或有版本等特征)某一時(shí)間點(diǎn)后 --> 基本是放量引起的

　　某些版本一段時(shí)間出現(xiàn)激增并驟降 --> 一般是流相關(guān)的問題，在某些版本觸發(fā)了異常

　　問題定位的經(jīng)驗(yàn)是需要不斷積累的，不可能一蹴而就;除經(jīng)驗(yàn)外，還需要深入理解各個(gè)角色在整個(gè)鏈路中的作用，根據(jù)問題的表現(xiàn)推測根因，再基于推測進(jìn)行佐證。

　　止損手段

　　推拉流 SDK 對于新功能都會(huì)添加各類開關(guān)，以保證功能上線后、出現(xiàn)異常時(shí)可以及時(shí)關(guān)閉進(jìn)行止損。但是對于一些新問題或者一些歷史問題，如果沒有相應(yīng)開關(guān)進(jìn)行控制時(shí)，對于業(yè)務(wù)線會(huì)造成不同程度的影響。

　　這類問題一般會(huì)是流相關(guān)的，且在測試階段隱蔽性高(測試階段沒有辦法百分之百覆蓋到這些流問題，尤其是新問題)、突發(fā)性強(qiáng)(往往隨直播開播時(shí)發(fā)生、關(guān)播時(shí)結(jié)束)。這類問題在初步分析問題、確定問題可以通過調(diào)度等手段解決時(shí)，可以嘗試與轉(zhuǎn)碼、流調(diào)度配合完成這類問題的及時(shí)止損。隨后在新版本進(jìn)行問題修復(fù)。

　　總結(jié)

　　在實(shí)際的直播相關(guān)業(yè)務(wù)開發(fā)過程中，還有許許多多有趣且值得深入挖掘的內(nèi)容，這篇文章僅僅是對直播鏈路做了一個(gè)簡單的概覽，力求幫助沒有直播開發(fā)相關(guān)經(jīng)驗(yàn)的朋友對直播全鏈路有一個(gè)全局性的理解，相信各位朋友在理解了直播全鏈路之后，對于直播體驗(yàn)優(yōu)化或問題排查一定能夠更加得心應(yīng)手。