一、背景

隨著直播行業(yè)的近年來(lái)的發(fā)展，直播技術(shù)現(xiàn)已日趨成熟。本文主要介紹目前主流的直播技術(shù)原理，以及在直播在發(fā)布會(huì)場(chǎng)景下的應(yīng)用以及過(guò)程中遇到的問(wèn)題及解決方案。

二、直播原理

2.1 流媒體技術(shù)

2.1.1 流媒體簡(jiǎn)介

目前在網(wǎng)絡(luò)中傳輸音視頻的多媒體信息主要有兩種方式——下載方式和流式傳輸。下載方式很好理解，用戶需要將一個(gè)音視頻完全下載后才可以進(jìn)行播放；流式傳輸指將音視頻通過(guò)服務(wù)器向客戶端進(jìn)行連續(xù)的實(shí)時(shí)傳輸。基于流式傳輸?shù)奶攸c(diǎn)，就不難理解流媒體的定義——流媒體（streaming media）是在由提供商提供的同時(shí)能夠不斷的被終端用戶接收，并呈現(xiàn)給終端用戶的多媒體。動(dòng)詞“流”（streaming）很好的描述了這種媒體的傳遞和獲取的過(guò)程。

好比一個(gè)完整的word文檔，我需要全部下載才可以打開(kāi)，甚至下載完給我來(lái)一個(gè)損壞提示，相比這時(shí)候心情一定十分惱火，但如果一頁(yè)一頁(yè)進(jìn)行下載，像小人書(shū)一樣呢？

圖1：word示意圖

圖2：小人書(shū)示意

2.1.2 流式傳輸概述

所謂流式傳輸是指將整個(gè)A/V等多媒體文件經(jīng)過(guò)特殊的壓縮方式分成一個(gè)一個(gè)的壓縮包，通過(guò)服務(wù)器將這一個(gè)個(gè)的壓縮包向終端用戶連續(xù)、實(shí)時(shí)發(fā)送，用戶還沒(méi)有接收到完整的多媒體信息前就能處理已接收的部分信息，并對(duì)該部分音視頻進(jìn)行播放，剩余部分繼續(xù)在服務(wù)器后臺(tái)下載。（類比計(jì)算機(jī)處理問(wèn)文件的方式）。

?流媒體傳輸主要分為以下兩種方式：

• 順序流式傳輸（Progressive Streaming）
  即用戶在觀看在線媒體的同時(shí)下載文件，在某一時(shí)刻用戶只能觀看已下載的部分而不能跳轉(zhuǎn)到未下載的部分進(jìn)行觀看。順序流式傳輸能夠很好的保證節(jié)目播放質(zhì)量，比較適合在網(wǎng)站上發(fā)布的、可供用戶點(diǎn)播的、高質(zhì)量的視頻。典型例子——電視節(jié)目。

• 實(shí)時(shí)流式傳輸（Real-Time Streaming）
  這種傳輸方式需要保證媒體信號(hào)帶寬與網(wǎng)絡(luò)連接匹配，使得音視頻可以被實(shí)時(shí)的觀看，一般需要專門的流媒體服務(wù)器與傳輸協(xié)議。這種方式允許用戶通過(guò)服務(wù)器對(duì)媒體發(fā)送更多級(jí)別的控制如快進(jìn)、快退等，同時(shí)在傳輸過(guò)程中音視頻質(zhì)量能夠根據(jù)用戶的網(wǎng)絡(luò)帶寬進(jìn)行調(diào)整。

2.1.3 流媒體技術(shù)與直播

由于流媒體技術(shù)的快速發(fā)展在一定程度上突破了網(wǎng)絡(luò)帶寬對(duì)多媒體信息的限制，將過(guò)去的傳統(tǒng)媒體的“推”式傳播轉(zhuǎn)變?yōu)橛脩艨蛇x擇的“拉”式傳播，用戶可根據(jù)自己的喜好選擇性的接收自己需要的媒體信息。正是這種技術(shù)和時(shí)代的進(jìn)步使得如今直播平臺(tái)快速發(fā)展，豐富的業(yè)務(wù)也能扎根直播完成其使命。

2.2 直播流程

了解直播所需的基本概念后，咱們?cè)僖徊讲阶哌M(jìn)直播的原理。

首先在聊直播的時(shí)候，我們需要了解直播涉及到的三大角色——主播、流媒體服務(wù)器和觀看用戶。顧名思義，主播就是視頻的發(fā)起者，我們稱為視頻錄制端或視頻推流端；觀看用戶就是收看直播節(jié)目的受眾，我們稱為視頻播放端（拉流端）；而流媒體服務(wù)器是兩端的橋梁，承擔(dān)著處理流媒體及分發(fā)的任務(wù)。這三者構(gòu)成了直播的整體流程。

圖3：直播流程

2.2.1 視頻推流端

?視頻推流端工作流程主要分為四步：

1. 采集：主播/導(dǎo)播通過(guò)攝像機(jī)、手機(jī)等錄制設(shè)備進(jìn)行音畫采集；

2. 處理：在導(dǎo)播臺(tái)將原始音畫進(jìn)行一定的處理如美顏、加水印、濾鏡等；

3. 編碼和封裝：當(dāng)原始視頻被處理完畢后通過(guò)編碼器如H.264、H.265等進(jìn)行編碼，將龐大的音視頻源文件壓縮，并通過(guò)封裝將編碼好的媒體內(nèi)容封裝為規(guī)范的媒體文件格式如AVI、MOV、MPEG格等；編碼的核心思想是去除媒體信息中的冗余，包括：空間、時(shí)間、編碼、視覺(jué)等；而封裝的意義就好比用何種貨車去運(yùn)輸貨物（媒體內(nèi)容），讓播放變得簡(jiǎn)單。
   此步驟對(duì)流媒體傳輸有著至關(guān)重要的作用，涉及規(guī)范和知識(shí)也十分豐富，有興趣的同學(xué)可以尋找相關(guān)文章進(jìn)行了解，在此不進(jìn)行詳細(xì)說(shuō)明。

4. 推流：最終通過(guò)推流工具將該流媒體向服務(wù)器推送，“推”一動(dòng)詞形象地描述了主播主動(dòng)將流推送至服務(wù)器的過(guò)程。到此步被成為直播的第一里程碑。

2.2.2 流媒體服務(wù)器

流媒體服務(wù)器是流媒體應(yīng)用中的核心系統(tǒng)，是運(yùn)營(yíng)商向用戶提供流媒體服務(wù)的關(guān)鍵平臺(tái)。

當(dāng)主播使用推流軟件將流媒體推送至各種流媒體服務(wù)器之后，流媒體服務(wù)器可以將獲取到的媒體內(nèi)容進(jìn)行加強(qiáng)、轉(zhuǎn)碼等各式各樣的操作，同時(shí)服務(wù)器可根據(jù)解析出來(lái)的媒體內(nèi)容進(jìn)行額外的業(yè)務(wù)拓展如安全審核等，最終服務(wù)器會(huì)將處理好的媒體內(nèi)容以合適的流媒體協(xié)議將流媒體內(nèi)容傳輸至CDN，觀看用戶端便可以隨時(shí)拉取媒體內(nèi)容進(jìn)行播放。

2.2.3 播放端

也稱拉流端，用戶可使用各種流媒體播放app拉取想要獲取的信息。

播放端的步驟如下：

1. 拉流：通過(guò)播放app并選取合適的拉流協(xié)議進(jìn)行拉取媒體內(nèi)容；

2. 解復(fù)用：將處于“多媒體文件格式”的流解復(fù)用，成為“視頻編碼格式”和“音頻編碼格式”，通俗點(diǎn)說(shuō)就是把“音視頻信號(hào)源”分流出單獨(dú)的“視頻數(shù)據(jù)”和“音頻數(shù)據(jù)”。（如.FLV解復(fù)用后得到H.264視頻數(shù)據(jù)和AAC音頻數(shù)據(jù)）。

3. 解碼：硬解碼（GPU解碼 CPU輔助）或軟解碼（CPU解碼）將解復(fù)用得到的音視頻數(shù)據(jù)進(jìn)行解碼，解碼后得到Y(jié)UV或RGB格式的視頻以及PCM格式的音頻。

4. 音畫同步并輸出播放：解碼后終端會(huì)執(zhí)行音畫同步的操作，并將同步后的音頻輸送至音頻設(shè)備進(jìn)行播放，視頻通過(guò)輸送至視頻輸出設(shè)備進(jìn)行播放。

通過(guò)以上幾個(gè)步驟，用戶端就能夠順利的開(kāi)始播放直播啦。

2.2.4 直播架構(gòu)

為完成2.2所述直播流程，一般直播架構(gòu)如下：

圖4：簡(jiǎn)單直播架構(gòu)示意

2.3 直播協(xié)議

光有思路了還不夠，數(shù)據(jù)傳輸需要一定的規(guī)范，否則各家按各家行事到時(shí)候都只能在自己的框架里才能玩得轉(zhuǎn)，不符合互聯(lián)網(wǎng)共享精神，這時(shí)候就需要有一套規(guī)范的協(xié)議來(lái)約束數(shù)據(jù)的傳輸。

常見(jiàn)的直播協(xié)議有RTMP、HTTP-FLV、HLS?等，下面我們來(lái)簡(jiǎn)單介紹一下這三種協(xié)議。

2.3.1 RTMP

RTMP協(xié)議是Real Time Message Protocol(實(shí)時(shí)信息傳輸協(xié)議)的縮寫，最初是Macromedia（現(xiàn)歸Adobe所有）開(kāi)發(fā)的專有協(xié)議，用來(lái)解決多媒體數(shù)據(jù)傳輸流的多路復(fù)用（Multiplexing）和分包（packetizing）的問(wèn)題，可在Flash播放器和服務(wù)器之間通過(guò)Internet流式傳輸音頻，視頻和數(shù)據(jù)。是一種應(yīng)用層協(xié)議，同時(shí)支持推流和拉流。

RTMP傳輸時(shí)，會(huì)對(duì)數(shù)據(jù)內(nèi)容進(jìn)行格式化，這種消息格式被成為RTMP Message，該消息的構(gòu)成如下：

圖5：RTMP 消息構(gòu)成

可以看到根據(jù)Message的TypeId可以劃分為7種信息，這7種信息包含了對(duì)端連接、數(shù)據(jù)信息及控制信息等，用以完成流媒體的播放及操縱。

根據(jù)視頻數(shù)據(jù)“壓縮分段”的思想，RTMP在實(shí)際傳輸過(guò)程中會(huì)將Message劃分為一個(gè)個(gè)帶ID小塊，稱為Chunk，每一個(gè)Chunk可能是一個(gè)單獨(dú)的Message，也可能是一個(gè)Message的部分。每一個(gè)Message都有一個(gè)唯一的標(biāo)識(shí)——Message Stream ID，在還原Message時(shí)，每一個(gè)Chunk就通過(guò)這個(gè)標(biāo)識(shí)來(lái)辨別是否為同一個(gè)Message，最終在收到Chunk后進(jìn)行組裝。

RTMP的推拉流流程如下：

圖6：RTMP 推拉流過(guò)程

感興趣的小伙伴可以參考Adobe官網(wǎng)發(fā)布的 RTMP specification v1.0對(duì)RTMP進(jìn)行更深入的了解，本文不再贅述。

2.3.2 HLS

不管是RTMP還是HTTP-FLV，都逃不過(guò)一點(diǎn)——Flash。在12年Adobe發(fā)布RTMP specification v1.0時(shí)，本以為拿到流媒體金鑰匙的Adobe未曾想未來(lái)是個(gè)HTML5的世界，一個(gè)不需要Flash的世界。

在09年三月iphone 3.0發(fā)布會(huì)上，蘋果在新的操作系統(tǒng)宣傳中添加了關(guān)于流媒體功能的微妙暗示。同年五月HLS協(xié)議正式發(fā)布。HLS協(xié)議的出現(xiàn)最初是為了解決蘋果原生環(huán)境中的流媒體播放問(wèn)題，這個(gè)協(xié)議可以方便的讓Mac和iphone播放視頻流而不依賴Adobe。依賴自己往往是最大的力量保障。

HLS全稱HTTP Live Streaming，是一個(gè)由 Apple 公司實(shí)現(xiàn)的基于 HTTP 的媒體流傳輸協(xié)議。工作原理是通過(guò)將整條流切割成一個(gè)小的可以通過(guò) HTTP 下載的媒體文件, 然后提供一個(gè)配套的媒體列表文件, 提供給客戶端, 讓客戶端順序地拉取這些媒體文件播放。

HLS協(xié)議包含三個(gè)部分：Server、Distribution 和 Client.

• 首先需要從導(dǎo)播端獲取視頻數(shù)據(jù)，通過(guò)其他支持推流的協(xié)議，將視頻流傳輸?shù)椒?wù)器上去。

• 其中Stream segmenter（流切片器）會(huì)從Media encoder（編碼器）讀取數(shù)據(jù)，然后將著這些數(shù)據(jù)一組相等時(shí)間間隔的小媒體文件。雖然每一個(gè)片段都是一個(gè)單獨(dú)的文件，但是他們的來(lái)源是一個(gè)連續(xù)的流，切完照樣可以無(wú)縫重構(gòu)回去。

• 切片器在切片同時(shí)會(huì)創(chuàng)建一個(gè)索引文件(Index file)，索引文件會(huì)包含這些切片文件的引用。每當(dāng)一個(gè)切片文件生成后，索引文件都會(huì)進(jìn)行更新。索引用于追蹤切片文件的有效性和定位切片文件的位置。切片器同時(shí)也可以對(duì)你的媒體片段進(jìn)行加密并且創(chuàng)建一個(gè)密鑰文件作為整個(gè)過(guò)程的一部分。

• Distribution相當(dāng)于一個(gè)Http文件服務(wù)器，Client通過(guò)訪問(wèn)Distribution中的索引文件，便可以自動(dòng)播放HLS流了。

圖7：HLS 處理流程

通過(guò)上述流程，用戶拿到索引文件就相當(dāng)于拿到了流媒體的鑰匙，那么HLS生成的索引文件又是啥呢？讓我們來(lái)解開(kāi)他的神秘面紗——m3u8文件。

m3u8文件實(shí)際實(shí)質(zhì)上是一個(gè)播放列表（playlist），其主要的兩種形式為主播放列表（Master Playlist）和流媒體播放表（Media Playlist），也稱一級(jí)索引和二級(jí)索引。

圖8：m3u8文件內(nèi)容

可以看到主播放列表（一級(jí)索引）主要標(biāo)識(shí)有帶寬（BANDWIDTH）、視頻分辨率（RESOLUTION）、音頻編碼格式（CODECS）以及二級(jí)索引路徑；流媒體播放列表（二級(jí)索引）關(guān)鍵屬性為切片持續(xù)時(shí)間（EXTINF）以及視頻切片路徑（按上圖實(shí)例，該切片至少有9.009 9.009 3.003秒左右的延遲）；瀏覽器通過(guò)不斷訪問(wèn)最新m3u8文件即可獲得每個(gè)切片的地址并通過(guò)瀏覽器進(jìn)行播放。

圖9：直播 m3u8請(qǐng)求

2.3.3 HTTP-FLV

HTTP-FLV本質(zhì)上是RTMP在HTTP協(xié)議上的封裝，同樣都是傳輸?shù)膄lv格式的數(shù)據(jù)，由于通過(guò)80端口通信，相比RTMP其穿透性更強(qiáng)。HTTP-FLV在本文中不再過(guò)多闡述。

2.3.4 三種直播協(xié)議對(duì)比及選型

三種直播協(xié)議的對(duì)比如下：

圖10：三種協(xié)議對(duì)比

根據(jù)三種常用的協(xié)議對(duì)比，在直播協(xié)議的選擇上面可根據(jù)各自的特點(diǎn)進(jìn)行選擇——實(shí)時(shí)性要求（互動(dòng)直播等）：RTMP/HTTP-FLV ?穩(wěn)定性要求（發(fā)布會(huì)等）：HLS

2.4 小結(jié)

本章對(duì)直播原理及常用的三種協(xié)議進(jìn)行分析，供讀者了解直播技術(shù)中涉及的基本概念。可能有些讀者對(duì)枯燥的技術(shù)知識(shí)表示“抗議”，在此以物流系統(tǒng)對(duì)直播系統(tǒng)進(jìn)行類比以供大家輕松愉快地理解：

相信大家平時(shí)都有網(wǎng)上購(gòu)物習(xí)慣，舉個(gè)例子：小明要在網(wǎng)上給女朋友買一個(gè)加熱出現(xiàn)照片的定制杯子，他會(huì)經(jīng)歷網(wǎng)上下單，物流運(yùn)輸、驛站存取等步驟，而商家擔(dān)任產(chǎn)品的制作需要經(jīng)歷杯子加工、打包、發(fā)貨等步驟；

在這里商家就是主播，杯子就是原始視頻，加上小明女朋友照片的杯子就是經(jīng)過(guò)了處理工序，而打包就是編碼封裝按一定的規(guī)格給快遞公司才給正常發(fā)貨嘛，而發(fā)貨就是相當(dāng)于推流，此時(shí)物流公司就擔(dān)任流分發(fā)的重任，將快遞分發(fā)到各個(gè)驛站（CDN），而小明的快遞便傳遞到了最近的驛站；

小明想起來(lái)要去拿快遞了，于是憑借著取貨碼（拉流協(xié)議），去拿到這個(gè)杯子，這個(gè)提貨的過(guò)程就相當(dāng)于拉流，整個(gè)過(guò)程如下圖所示：

圖11：物流系統(tǒng)類比圖

相信通過(guò)這個(gè)形象的例子，大家一定對(duì)直播架構(gòu)有了基本概念。

三、vivo官網(wǎng)發(fā)布會(huì)直播技術(shù)保障

3.1 發(fā)布會(huì)直播面臨的挑戰(zhàn)

本章主要介紹在vivo官網(wǎng)發(fā)布會(huì)直播過(guò)程中所遇到的問(wèn)題，以及其一般性解決思路。

新品發(fā)布會(huì)的影響力可想而知，特別是在發(fā)布會(huì)push發(fā)放節(jié)點(diǎn)以及發(fā)布會(huì)開(kāi)始節(jié)點(diǎn)，會(huì)有大量的觀眾進(jìn)入到官網(wǎng)直播間，此時(shí)的瞬時(shí)壓力成為面臨的第一道挑戰(zhàn)，而隨著發(fā)布會(huì)的進(jìn)行，持續(xù)大流量也成為系統(tǒng)的隱患之一；當(dāng)然由于發(fā)布會(huì)的特殊屬性，一切都建立在不容出錯(cuò)的基礎(chǔ)之上，保證發(fā)布會(huì)無(wú)異常發(fā)生。

可以看出發(fā)布會(huì)直播面臨的問(wèn)題實(shí)際上就是一個(gè)典型的高并發(fā)系統(tǒng)所面臨的問(wèn)題。而保護(hù)高并發(fā)系統(tǒng)的三大利器——緩存、降級(jí)、限流，便是發(fā)布會(huì)技術(shù)保障其中的一部分。

3.2技術(shù)保障

3.2.1 發(fā)布會(huì)緩存方案

正所謂網(wǎng)站性能優(yōu)化第一定律就是考慮使用緩存針對(duì)發(fā)布會(huì)我們做了許多緩存優(yōu)化方案。

細(xì)心的小伙伴會(huì)發(fā)現(xiàn)官網(wǎng)直播涉及到內(nèi)容輪詢獲取，如直播人數(shù)、直播評(píng)論、點(diǎn)贊數(shù)等，而優(yōu)化的第一步是調(diào)整輪詢的時(shí)間間距，減小峰值QPS；而降低QPS后仍然會(huì)有大量請(qǐng)求過(guò)來(lái)，這時(shí)候作場(chǎng)景考慮，部分配置信息以及圍觀人數(shù)、點(diǎn)贊等對(duì)發(fā)布會(huì)主流程無(wú)決定性影響且實(shí)時(shí)性要求并不高，而采用單純的redis集群會(huì)使得集群壓力劇增，最初直接集群訪問(wèn)的模式已不再適應(yīng)業(yè)務(wù)的發(fā)展，此時(shí)在技術(shù)層面考慮了這部分?jǐn)?shù)據(jù)采用本地緩存進(jìn)行存儲(chǔ)。雖然會(huì)造成短暫的數(shù)據(jù)不一致的“損失”，但在對(duì)業(yè)務(wù)沒(méi)有實(shí)質(zhì)性影響的情況下，極大的提升了直播業(yè)務(wù)的穩(wěn)定性。

圖12：多級(jí)緩存演變示意圖

3.2.2 發(fā)布會(huì)降級(jí)方案

發(fā)布會(huì)場(chǎng)景的核心是保證直播音視頻的正常播放，給用戶了解咱們最新的產(chǎn)品。由于實(shí)際業(yè)務(wù)的需要與拓展，在發(fā)布會(huì)場(chǎng)景涉及到許多感知與互動(dòng)元素，而如果因?yàn)檫@些業(yè)務(wù)功能導(dǎo)致發(fā)布會(huì)核心被拖垮顯然得不償失。所以在設(shè)計(jì)之初對(duì)這些業(yè)務(wù)設(shè)置了一些降級(jí)策略以防止這種情況的發(fā)生。在此舉一種典型的場(chǎng)景以供大家理解進(jìn)入直播頁(yè)的第一道“工序”就是去查詢直播的基礎(chǔ)配置，而當(dāng)訪問(wèn)量到一定程度通過(guò)觀察日志發(fā)現(xiàn)部分請(qǐng)求超時(shí)甚至異常時(shí)，咱們就會(huì)開(kāi)啟強(qiáng)制熔斷，后續(xù)查詢就會(huì)走到fallback方法指向查詢本地緩存中的內(nèi)容，降低服務(wù)壓力的同時(shí)也不會(huì)對(duì)用戶的觀看體驗(yàn)造成很大影響。

圖13：熔斷示意圖

雖然上述方案在實(shí)際發(fā)布會(huì)過(guò)程中均未觸發(fā)，但未雨綢繆有備無(wú)患總是比出現(xiàn)問(wèn)題再解決問(wèn)題來(lái)的更加從容自然。

3.2.3 發(fā)布會(huì)限流方案

發(fā)布會(huì)直播評(píng)論抽獎(jiǎng)作為典型流量場(chǎng)景，使用限流手段讓部分抽獎(jiǎng)評(píng)論排隊(duì)等待，后續(xù)等處理完畢后再告知用戶中獎(jiǎng)信息。常見(jiàn)的限流算法有漏桶算法和令牌桶算法，而評(píng)論抽獎(jiǎng)的特性是到時(shí)間段的瞬間有大量評(píng)論進(jìn)入抽獎(jiǎng)邏輯，限流既要考慮流量整形，又要考慮突發(fā)請(qǐng)求，令牌桶算法再適合不過(guò)。

圖14：令牌桶算法示意圖

3.3 內(nèi)容安全保障

由于面向公眾，同時(shí)存在互動(dòng)類玩法，內(nèi)容安全性在發(fā)布會(huì)直播中也尤為重要，而在直播內(nèi)容安全（即視頻無(wú)敏感內(nèi)容）的前提下，與用戶側(cè)相關(guān)的文字內(nèi)容安全（涉黃、涉政、暴恐、違禁內(nèi)容等）處理成為需要解決的一大問(wèn)題。當(dāng)然在內(nèi)部諦聽(tīng)團(tuán)隊(duì)的支持下這一問(wèn)題也迎刃而解，避免重復(fù)造輪子。

3.4 小結(jié)

通過(guò)本章作者希望大家理解直播的核心是給大家看視頻聽(tīng)聲音的，為了保證這一需求不出錯(cuò)的同時(shí)在上面進(jìn)行一些拓展性的業(yè)務(wù)提升用戶互動(dòng)性需要面臨諸多挑戰(zhàn)，作為開(kāi)發(fā)者需要意識(shí)到這些挑戰(zhàn)并做好接受挑戰(zhàn)的準(zhǔn)備，為業(yè)務(wù)的提升打好基石。

四、寫在最后

如今直播的業(yè)務(wù)存在形式多種多樣，如發(fā)布會(huì)、游戲直播、教育直播、直播帶貨等，作者希望通過(guò)本文的介紹相信大家或多或少對(duì)直播技術(shù)有了一定的認(rèn)知，直播涉及到的各個(gè)細(xì)節(jié)都有一個(gè)龐大的知識(shí)體系支撐，由于篇幅及個(gè)人知識(shí)經(jīng)驗(yàn)有限，無(wú)法為大家呈現(xiàn)更多細(xì)節(jié)，有興趣的讀者可以以本文為參考對(duì)直播進(jìn)行深入的了解。