一、背景

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

二、直播原理

2.1 流媒體技術

2.1.1 流媒體簡介

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

好比一個完整的word文檔，我需要全部下載才可以打開，甚至下載完給我來一個損壞提示，相比這時候心情一定十分惱火，但如果一頁一頁進行下載，像小人書一樣呢？

圖1：word示意圖

圖2：小人書示意

2.1.2 流式傳輸概述

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

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

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

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

2.1.3 流媒體技術與直播

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

2.2 直播流程

了解直播所需的基本概念后，咱們再一步步走進直播的原理。

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

圖3：直播流程

2.2.1 視頻推流端

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

1. 采集：主播/導播通過攝像機、手機等錄制設備進行音畫采集；

2. 處理：在導播臺將原始音畫進行一定的處理如美顏、加水印、濾鏡等；

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

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

2.2.2 流媒體服務器

流媒體服務器是流媒體應用中的核心系統(tǒng)，是運營商向用戶提供流媒體服務的關鍵平臺。

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

2.2.3 播放端

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

播放端的步驟如下：

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

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

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

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

通過以上幾個步驟，用戶端就能夠順利的開始播放直播啦。

2.2.4 直播架構

為完成2.2所述直播流程，一般直播架構如下：

圖4：簡單直播架構示意

2.3 直播協(xié)議

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

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

2.3.1 RTMP

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

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

圖5：RTMP 消息構成

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

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

RTMP的推拉流流程如下：

圖6：RTMP 推拉流過程

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

2.3.2 HLS

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

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

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

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

• 首先需要從導播端獲取視頻數(shù)據(jù)，通過其他支持推流的協(xié)議，將視頻流傳輸?shù)椒掌魃先ァ?/p>
• 其中Stream segmenter（流切片器）會從Media encoder（編碼器）讀取數(shù)據(jù)，然后將著這些數(shù)據(jù)一組相等時間間隔的小媒體文件。雖然每一個片段都是一個單獨的文件，但是他們的來源是一個連續(xù)的流，切完照樣可以無縫重構回去。

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

• Distribution相當于一個Http文件服務器，Client通過訪問Distribution中的索引文件，便可以自動播放HLS流了。

圖7：HLS 處理流程

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

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

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

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

圖9：直播 m3u8請求

2.3.3 HTTP-FLV

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

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

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

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

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

2.4 小結

本章對直播原理及常用的三種協(xié)議進行分析，供讀者了解直播技術中涉及的基本概念?？赡苡行┳x者對枯燥的技術知識表示“抗議”，在此以物流系統(tǒng)對直播系統(tǒng)進行類比以供大家輕松愉快地理解：

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

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

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

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

相信通過這個形象的例子，大家一定對直播架構有了基本概念。

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

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

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

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

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

3.2技術保障

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

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

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

圖12：多級緩存演變示意圖

3.2.2 發(fā)布會降級方案

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

圖13：熔斷示意圖

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

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

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

圖14：令牌桶算法示意圖

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

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

3.4 小結

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

四、寫在最后

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