本文由“聲網(wǎng)Agora”的RTC開發(fā)者社區(qū)整理。
1、概述
本文將分享新浪微博系統(tǒng)開發(fā)工程師陳浩在 RTC 2018 實(shí)時(shí)互聯(lián)網(wǎng)大會(huì)上的演講。他分享了新浪微博直播互動(dòng)答題架構(gòu)設(shè)計(jì)的實(shí)戰(zhàn)經(jīng)驗(yàn)。其背后的百萬(wàn)高并發(fā)實(shí)時(shí)架構(gòu)，值得借鑒并用于未來(lái)更多場(chǎng)景中。本文正文是對(duì)演講內(nèi)容的整理，請(qǐng)繼續(xù)往下閱讀。
另外，即時(shí)通訊網(wǎng)整理的直播答題相關(guān)文章有：
《近期大熱的實(shí)時(shí)直播答題系統(tǒng)的實(shí)現(xiàn)思路與技術(shù)難點(diǎn)分享》
《2018新“風(fēng)口”——直播答題應(yīng)用原理解析》
新浪微博團(tuán)隊(duì)分享的：《新浪微博技術(shù)分享：微博短視頻服務(wù)的優(yōu)化實(shí)踐之路》一文，您也可能感興趣。
（本文同步發(fā)布于：http://www.52im.net/thread-2022-1-1.html）
2、什么是直播答題
首先，如下圖所示，這是一個(gè)傳統(tǒng)的直播頁(yè)面。它的主頁(yè)面是直播的音視頻流，下面顯示的是消息互動(dòng)，包括評(píng)論、點(diǎn)贊和分享。什么是直播答題呢？
直播答題其實(shí)本質(zhì)上還是一個(gè)直播的場(chǎng)景，只是引入了答題的互動(dòng)方式。主持人可以通過(guò)口令控制客戶端的行為，比如控制發(fā)題。同時(shí)，直播答題通過(guò)獎(jiǎng)金激勵(lì)，帶動(dòng)更多用戶參與進(jìn)來(lái)。在每一次答題之后，會(huì)將數(shù)據(jù)實(shí)時(shí)展示出來(lái)。下圖展示的是直播答題的流程，中間的部分是會(huì)重復(fù)進(jìn)行的環(huán)節(jié)。
3、直播答題的技術(shù)挑戰(zhàn)
直播答題的核心需求用一句話就可以概括：海量用戶同時(shí)在線的場(chǎng)景下，確保用戶的答題畫面能展現(xiàn)，在直播過(guò)程中流暢地參與答題，最終分到獎(jiǎng)金。
這一句話中有三個(gè)關(guān)鍵點(diǎn)，分別對(duì)應(yīng)了不同的技術(shù)要求：
第一個(gè)：就是“海量用戶同時(shí)在線”。海量用戶帶來(lái)的就是海量的數(shù)據(jù)。在這個(gè)場(chǎng)景下第一個(gè)用戶高峰出現(xiàn)在活動(dòng)開始前，海量的用戶會(huì)在幾分鐘內(nèi)加入房間。在直播進(jìn)行中，答題的十秒倒計(jì)時(shí)內(nèi)，海量用戶會(huì)同時(shí)提交答案，會(huì)產(chǎn)生海量的答題消息，包括我們互動(dòng)與題目結(jié)果的消息，所以下發(fā)、上傳雙向都會(huì)出現(xiàn)高并發(fā)。這就考驗(yàn)我們對(duì)海量數(shù)據(jù)高并發(fā)的處理能力。
第二個(gè)：關(guān)鍵點(diǎn)是“答題畫面能夠展示”，這是非常基礎(chǔ)且首要的需求，因?yàn)橛脩魠⑴c答題，如果畫面都展示不出來(lái)，那么這場(chǎng)游戲就沒(méi)法進(jìn)行下去了。每一輪答題都可能淘汰一批用戶，淘汰答錯(cuò)題的用戶是正常的，但如果是因?yàn)槲茨苷故境龃痤}畫面而淘汰，那就是技術(shù)問(wèn)題。其技術(shù)難點(diǎn)在于海量題目的下發(fā)成功率要有保證，給技術(shù)提出的對(duì)應(yīng)要求就是服務(wù)的可靠性。
最后一個(gè)：是“流暢地參與答題”，這與用戶體驗(yàn)相關(guān)，每一輪答題時(shí)間間隔很短，一旦錯(cuò)過(guò)一道題的答題時(shí)間，用戶就沒(méi)法完成這個(gè)游戲，所以要保證消息下發(fā)后，10秒內(nèi)讓用戶收到并且正常展示。同時(shí)，每一輪答題后，主持人需要立刻看到答題數(shù)據(jù)，包括有多少用戶答對(duì)，有多少用戶使用了復(fù)活卡等。這給我們帶來(lái)的是對(duì)海量數(shù)據(jù)進(jìn)行實(shí)時(shí)下發(fā)、實(shí)時(shí)統(tǒng)計(jì)的挑戰(zhàn)。
4、答題直播技術(shù)方案
我們基于微博直播的技術(shù)現(xiàn)狀，設(shè)計(jì)了一個(gè)方案。如下圖所示，這是我們微博直播互動(dòng)的架構(gòu)圖。左側(cè)是微博的基礎(chǔ)設(shè)施服務(wù)，基本上都是自研的，比如最核心的短連使用的是自研的 wesync 協(xié)議，支持SSL，是支撐百萬(wàn)互動(dòng)消息下發(fā)的核心服務(wù)之一。長(zhǎng)連維護(hù)消息通道可動(dòng)態(tài)擴(kuò)容，海量用戶同時(shí)涌入后會(huì)進(jìn)行容量的計(jì)算，對(duì)我們的資源進(jìn)行擴(kuò)縮容。
在直播答題方案設(shè)計(jì)（下圖）中，最核心的就是解決答題信令通道的選擇問(wèn)題。我們想到了三個(gè)方案來(lái)解決。
方案一：輪詢
客戶端不斷進(jìn)行請(qǐng)求，由服務(wù)端控制時(shí)間窗口，到時(shí)間我們開放請(qǐng)求，結(jié)果返回。優(yōu)點(diǎn)是實(shí)現(xiàn)簡(jiǎn)單。缺點(diǎn)在于大量無(wú)用請(qǐng)求會(huì)消耗大量帶寬資源，給服務(wù)端帶來(lái)持續(xù)性的壓力。而且，題目到達(dá)時(shí)間與音視頻流到達(dá)時(shí)間難以保持一致。
方案二：復(fù)用音視頻通道
我們可以在音視頻流里面直接加入題目的信息。在主持人口令位置插入題目消息。客戶端播放音視頻流，收到題號(hào)數(shù)據(jù)的時(shí)候，直接把題目給展示出來(lái)。這個(gè)方案的特點(diǎn)就是題目展示的時(shí)間能和主持人口令一致，也就是說(shuō)用戶是感知不到時(shí)間差的，體驗(yàn)非常好。缺點(diǎn)是太依賴于音視頻流，一旦出現(xiàn)網(wǎng)絡(luò)抖動(dòng)，或者直播流中斷，用戶可能會(huì)收不到題目，這個(gè)游戲就沒(méi)法繼續(xù)下去了。
方案三：復(fù)用互動(dòng)通道
直播有音視頻流通道和互動(dòng)通道，題目使用互動(dòng)通道獨(dú)立下發(fā)。它的特點(diǎn)是題目下發(fā)不依賴于音視頻流，它的通道是獨(dú)立的，不受直播流的影響，即使直播中斷了，哪怕是黑屏，我們也可以把題目的畫面展示給用戶。缺點(diǎn)也是一樣，因?yàn)樗⒉皇歉粢曨l在一個(gè)通道，所以它們兩者時(shí)間難以保持一致。
我們從接入難度、擴(kuò)展性和音視頻同步三方面，對(duì)三個(gè)方案進(jìn)行了對(duì)比。針對(duì)以上三個(gè)方案，我們最終使用方案三。首先要保證答題不受直播流信號(hào)的影響。我們現(xiàn)在微博直播現(xiàn)有的架構(gòu)上能夠支持千萬(wàn)級(jí)消息的下發(fā)，我們把答題信息放到互動(dòng)通道下發(fā)，這是我們有能力支持的。答題和互動(dòng)的上行消息由短連服務(wù)支撐，在發(fā)題以及結(jié)果展示信息的時(shí)候，我們直接通過(guò)主動(dòng)推送，經(jīng)過(guò)廣播消息，通過(guò)長(zhǎng)連最終發(fā)給用戶。也就是說(shuō)整個(gè)答題就直接采用了互動(dòng)的通道，與音視頻流完全隔離開來(lái)。
5、如何解決實(shí)時(shí)性、可靠性與高并發(fā)？
針對(duì)實(shí)時(shí)性、可靠性和高并發(fā)，三個(gè)典型的問(wèn)題，我們也有不同的解決方法。
實(shí)時(shí)性問(wèn)題主要體現(xiàn)在兩方面，一個(gè)是答題畫面的實(shí)時(shí)展現(xiàn)，另一個(gè)是海量數(shù)據(jù)的實(shí)時(shí)統(tǒng)計(jì)。
5.1 答題畫面的實(shí)時(shí)展現(xiàn)
直播流經(jīng)過(guò)采編設(shè)備發(fā)給用戶客戶端是有延時(shí)的，中間經(jīng)過(guò)編解碼，到達(dá)客戶端的時(shí)間和主持人發(fā)出口令時(shí)間，有一個(gè)時(shí)間間隔。我們采用互動(dòng)通道的時(shí)候，這兩個(gè)時(shí)間我們是不容易做同步的。客戶端收到題目和視頻流最終到達(dá)的時(shí)間會(huì)出現(xiàn)不一致的情況。
我們看下圖，當(dāng)主持人 T0 時(shí)間發(fā)題，用戶在 T2 時(shí)間有可能才收到這個(gè)視頻流。如果我們 T0 的時(shí)間進(jìn)行發(fā)題，在 T1 的時(shí)間題目就到用戶客戶端了。問(wèn)題在于我們?nèi)绾文ㄈ?T2-T1 的時(shí)間差。對(duì)于用戶體驗(yàn)來(lái)說(shuō)，我們?cè)?T1 把題目畫面展示出來(lái)，在下一秒才能聽到主持人說(shuō)“請(qǐng)聽題”，這體驗(yàn)肯定不好。
我們的處理方式是在音視頻每隔一幀，或者一定幀數(shù)內(nèi)，插入服務(wù)器的時(shí)間戳。同時(shí)，我們?cè)谙掳l(fā)的消息體內(nèi)也埋入服務(wù)器的時(shí)間戳。客戶端播放音視頻流的時(shí)候，到達(dá)相應(yīng)的時(shí)間戳?xí)r，把跟這個(gè)時(shí)間戳相匹配的消息在頁(yè)面上渲染出來(lái)，也就是展示出了答題的畫面。通過(guò)使用統(tǒng)一時(shí)間戳進(jìn)行對(duì)標(biāo)，就抹平了視頻與題目的時(shí)間差。
5.2 海量用戶數(shù)據(jù)實(shí)時(shí)統(tǒng)計(jì)
我們每一輪答題結(jié)束的時(shí)候，都要統(tǒng)計(jì)用戶的答題狀態(tài)，比如用戶答案是否正確，用戶是否復(fù)活，以及他是否有復(fù)活卡。當(dāng)這些邏輯都放在一起需要處理，并且又是在一個(gè)海量數(shù)據(jù)場(chǎng)景下時(shí)，就變得非常復(fù)雜了。
另一方面，每一輪的答題只有發(fā)題和展示答案兩個(gè)指令。主持人在發(fā)題時(shí)會(huì)說(shuō)題目是什么，最終說(shuō)出結(jié)果是什么。沒(méi)有單獨(dú)指令觸發(fā)告訴服務(wù)器端什么時(shí)候進(jìn)行數(shù)據(jù)處理。而且，海量數(shù)據(jù)需要得到快速的計(jì)算。
把海量用戶產(chǎn)生的海量數(shù)據(jù)一次性的獲取出來(lái)，這是不現(xiàn)實(shí)的，耗費(fèi)資源相當(dāng)巨大，所以我們的思路就是化整為零，做并行處理。
首先，當(dāng)發(fā)題指令到達(dá)服務(wù)端的時(shí)候，我們按照一定的規(guī)則對(duì)用戶進(jìn)行細(xì)粒度的拆分。同時(shí)根據(jù)倒計(jì)時(shí)和流延時(shí)等等時(shí)間綜合考慮，能夠計(jì)算出我們什么時(shí)候才能開始進(jìn)行數(shù)據(jù)處理。然后將剛才做好的用戶分片，封裝成任務(wù)分片，放在延時(shí)隊(duì)列當(dāng)中。到達(dá)這個(gè)執(zhí)行時(shí)間的時(shí)候，由我們處理機(jī)的機(jī)群拉取這個(gè)任務(wù)，只有在執(zhí)行時(shí)間才會(huì)去處理這個(gè)任務(wù)，不會(huì)出現(xiàn)用戶答案沒(méi)有提交上來(lái)，我們就開始計(jì)算了。所以不會(huì)有將一部分用戶漏掉的狀況。
處理機(jī)拉到用戶的任務(wù)分片時(shí)，根據(jù)用戶選擇、狀態(tài)，以及長(zhǎng)連的地址，我們對(duì)用戶的消息整合。因?yàn)橛泻Ａ康挠脩簦泽w量巨大，但是答案選擇往往只有 A、B、C、D 四種，針對(duì)答案我們可以做一個(gè)分組，比如選 A 用戶有多少，選 B 用戶有多少。我們把單獨(dú)消息進(jìn)行合并，選A的用戶做為一個(gè)集合。
也就是說(shuō)這一個(gè)消息體其實(shí)包含了很多用戶的消息，從消息體量上，我們進(jìn)行降量，把小的消息合成成一個(gè)消息體，把一個(gè)消息體發(fā)給我們長(zhǎng)連接的服務(wù)，長(zhǎng)連接收到這個(gè)消息體的時(shí)候再進(jìn)行拆分。它類似于消息的一個(gè)包，我們把它按照用戶的維度進(jìn)行拆分，比如用戶選擇了什么答案，它是否使用過(guò)復(fù)活卡，以及它的狀態(tài)，進(jìn)行拆分后，最終下發(fā)給用戶。這樣在前面進(jìn)行拆，在后面進(jìn)行合，合完之后再拆一遍，這是我們解決海量數(shù)據(jù)實(shí)時(shí)計(jì)算的思路。
5.3 海量題目下發(fā)的可靠性
剛才我們提到，用戶如果在弱網(wǎng)情況下發(fā)生丟包，我們推送的消息有可能他沒(méi)法收到，他一旦收不到消息，整個(gè)答題沒(méi)有辦法進(jìn)行，有可能導(dǎo)致他在這一輪就被淘汰了。我們的解決方案是實(shí)現(xiàn)更穩(wěn)定更快速的自動(dòng)重連。雖然用戶的網(wǎng)絡(luò)環(huán)境是我們沒(méi)有辦法去保證的，但我們可以更快速發(fā)現(xiàn)他和我們長(zhǎng)連服務(wù)器斷連，并進(jìn)行更快速的重連。
同時(shí)，在答題倒計(jì)時(shí)內(nèi)我們無(wú)條件對(duì)題目消息進(jìn)行重傳。例如我們 T0 的時(shí)候發(fā)現(xiàn)用戶斷連，他在 T1 的時(shí)候，下發(fā)的題目收不到，然后我們?cè)?T2 進(jìn)行重連，在 T3 進(jìn)行無(wú)條件重傳的時(shí)候保證他收到這個(gè)題目。我們?cè)谙Ⅲw埋了一個(gè)最遲的展現(xiàn)時(shí)間，到這個(gè)時(shí)間后客戶端一定會(huì)把題目展示出來(lái)，保證他就算直播流斷了，我們也可以正常答題。面對(duì)黑屏的場(chǎng)景我們也可以完成答題的游戲。
5.4 高并發(fā)提交答案
每道題目下發(fā)后有一個(gè)10秒倒計(jì)時(shí)。假設(shè)有百萬(wàn)用戶在線，在10秒之內(nèi)都可以提交完答案，用戶提交答案大概集中在第3至第6秒之間，QPS 峰值預(yù)估會(huì)有30萬(wàn)。其次，我們保證用戶答案在短時(shí)間都能提交，因?yàn)樗怯袝r(shí)間限制的，如果我們做了削峰限流，他就會(huì)錯(cuò)過(guò)答題的時(shí)間窗口。所以我們不能對(duì)請(qǐng)求做削峰限流。
我們的解決方案就是用戶請(qǐng)求處理快速返回時(shí)，把重邏輯往后延，前面上行請(qǐng)求只是保證輕邏輯，讓它可以迅速返回。
同時(shí)，在資源層，我們對(duì)數(shù)據(jù)進(jìn)行處理時(shí)，把用戶提交的請(qǐng)求做一個(gè)合并，交給獨(dú)立的資源池進(jìn)行批量提交。我們的設(shè)計(jì)方案有一個(gè)閾值，當(dāng)遇到不可控，比如負(fù)荷達(dá)到我們?cè)O(shè)計(jì)的閾值時(shí)，我們有自動(dòng)隨機(jī)重試的機(jī)制，保證用戶把答案都可以提交上來(lái)。對(duì)于重試請(qǐng)求我們做針對(duì)性的時(shí)間補(bǔ)償，這樣保證流量達(dá)到我們負(fù)載的時(shí)候，答題請(qǐng)求也可以提交上來(lái)。
5.5 海量消息下發(fā)
一條題目消息，會(huì)被復(fù)制N份后下發(fā)給用戶。百萬(wàn)用戶產(chǎn)生的答案消息是海量的，對(duì)于千萬(wàn)級(jí)消息實(shí)時(shí)下發(fā)的系統(tǒng)來(lái)說(shuō)，訂閱端的網(wǎng)絡(luò)帶寬壓力也是巨大的。如下圖所示，消息出口的帶寬消耗非常大，因?yàn)槲覀兪轻槍?duì)海量用戶的連接。
我們的解決方法有兩方面。第一就是針對(duì)海量消息下發(fā)，對(duì)消息進(jìn)行體積上的壓縮，減少消息傳輸?shù)娜哂唷嚎s消息的時(shí)候我們采用了一個(gè)私有協(xié)議，我們盡量壓縮里面無(wú)用的東西，減小傳輸冗余，減小帶寬的消耗。
第二個(gè)是消息降量，我們根據(jù)用戶的答案進(jìn)行分組，按照分組把這些消息進(jìn)行合并，由原來(lái)的一條消息都要推送一次，轉(zhuǎn)變成下發(fā)一個(gè)消息集合。同時(shí)，我們提升消息的吞吐量，采用中間件的集群，進(jìn)行多端口并行的下發(fā)。
5.6 上線前的保障
直播答題場(chǎng)景有一個(gè)特別明顯的特征，它不像我們上線其它功能或者接口，我們可以進(jìn)行灰度放量。直播答題一上線，就是全量，沒(méi)有能通過(guò)灰度放量發(fā)現(xiàn)問(wèn)題的過(guò)程。所以我們對(duì)系統(tǒng)服務(wù)承載能力需要有一個(gè)量化的評(píng)估。
我們的處理方式就是進(jìn)行多輪壓測(cè)和持續(xù)的性能優(yōu)化。
首先我們做開發(fā)的時(shí)候已經(jīng)開始同步壓測(cè)。我們進(jìn)行一些功能問(wèn)題修復(fù)的時(shí)候，壓測(cè)的同事可以進(jìn)行做一些單接口的壓測(cè)，找出接口性能的臨界點(diǎn)。開發(fā)的同事做優(yōu)化的同時(shí)，壓測(cè)組模擬海量用戶在線的場(chǎng)景，搭建壓測(cè)的環(huán)境。
總體來(lái)講，有四輪壓測(cè)：
1）單機(jī)單接口壓測(cè)：掌握單機(jī)性能數(shù)據(jù)；
2）單機(jī)綜合壓測(cè)：定位性能損耗點(diǎn)，優(yōu)化業(yè)務(wù)處理邏輯；
3）負(fù)載均衡壓測(cè)：評(píng)估負(fù)載均衡數(shù)量；
4）集群全鏈路壓測(cè)：
- a. 搭建起壓機(jī)測(cè)試集群，保證能模擬百萬(wàn)量級(jí)用戶產(chǎn)生的數(shù)據(jù)量；
- b. 按照預(yù)估百萬(wàn)量級(jí)用戶消耗的公網(wǎng)帶寬配置起壓機(jī)出口帶寬，真實(shí)模擬線上業(yè)務(wù)場(chǎng)景；
- c. 按照預(yù)估用戶量和資源消耗量對(duì)線上服務(wù)及資源集群進(jìn)行擴(kuò)容，對(duì)線上服務(wù)真實(shí)壓測(cè)。
6、本文小結(jié)
簡(jiǎn)單總結(jié)一下，針對(duì)音畫與題目同步的實(shí)時(shí)性問(wèn)題，我們將直播流和互動(dòng)通道進(jìn)行對(duì)標(biāo)，解決題目與音視頻之間的同步問(wèn)題。
針對(duì)海量消息的實(shí)時(shí)下發(fā)問(wèn)題，我們通過(guò)將用戶分組，把大體量的消息任務(wù)化整為零，做分布式的分批次處理。
針對(duì)可靠性的問(wèn)題，我們通過(guò)完善快速自動(dòng)斷連重試機(jī)制，以及題目消息無(wú)條件重傳，來(lái)保證弱網(wǎng)下的用戶也能正常參與答題活動(dòng)。
另外，對(duì)于高并發(fā)問(wèn)題，我們將消息按照用戶選項(xiàng)進(jìn)行分組，化零為整，降低信息的推送量。同時(shí)，我們對(duì)消息結(jié)構(gòu)進(jìn)行了優(yōu)化，從這兩方面解決高并發(fā)問(wèn)題。
最后，還有一個(gè)關(guān)鍵的核心，就是壓測(cè)，通過(guò)壓測(cè)我們可以快速了解上述解決方案是否有效，讓我們可以持續(xù)優(yōu)化解決方案。
附錄1：更多直播技術(shù)文章參考
《淺談開發(fā)實(shí)時(shí)視頻直播平臺(tái)的技術(shù)要點(diǎn)》
《實(shí)現(xiàn)延遲低于500毫秒的1080P實(shí)時(shí)音視頻直播的實(shí)踐分享》
《移動(dòng)端實(shí)時(shí)視頻直播技術(shù)實(shí)踐：如何做到實(shí)時(shí)秒開、流暢不卡》
《技術(shù)揭秘：支持百萬(wàn)級(jí)粉絲互動(dòng)的Facebook實(shí)時(shí)視頻直播》
《移動(dòng)端實(shí)時(shí)音視頻直播技術(shù)詳解（一）：開篇》
《移動(dòng)端實(shí)時(shí)音視頻直播技術(shù)詳解（二）：采集》
《移動(dòng)端實(shí)時(shí)音視頻直播技術(shù)詳解（三）：處理》
《移動(dòng)端實(shí)時(shí)音視頻直播技術(shù)詳解（四）：編碼和封裝》
《移動(dòng)端實(shí)時(shí)音視頻直播技術(shù)詳解（五）：推流和傳輸》
《移動(dòng)端實(shí)時(shí)音視頻直播技術(shù)詳解（六）：延遲優(yōu)化》
《理論聯(lián)系實(shí)際：實(shí)現(xiàn)一個(gè)簡(jiǎn)單地基于HTML5的實(shí)時(shí)視頻直播》
《淺談實(shí)時(shí)音視頻直播中直接影響用戶體驗(yàn)的幾項(xiàng)關(guān)鍵技術(shù)指標(biāo)》
《如何優(yōu)化傳輸機(jī)制來(lái)實(shí)現(xiàn)實(shí)時(shí)音視頻的超低延遲？》
《首次披露：快手是如何做到百萬(wàn)觀眾同場(chǎng)看直播仍能秒開且不卡頓的？》
《Android直播入門實(shí)踐：動(dòng)手搭建一套簡(jiǎn)單的直播系統(tǒng)》
《網(wǎng)易云信實(shí)時(shí)視頻直播在TCP數(shù)據(jù)傳輸層的一些優(yōu)化思路》
《P2P技術(shù)如何將實(shí)時(shí)視頻直播帶寬降低75%？》
《近期大熱的實(shí)時(shí)直播答題系統(tǒng)的實(shí)現(xiàn)思路與技術(shù)難點(diǎn)分享》
《七牛云技術(shù)分享：使用QUIC協(xié)議實(shí)現(xiàn)實(shí)時(shí)視頻直播0卡頓！》
《實(shí)時(shí)視頻直播客戶端技術(shù)盤點(diǎn)：Native、HTML5、WebRTC、微信小程序》
《實(shí)時(shí)音頻的混音在視頻直播應(yīng)用中的技術(shù)原理和實(shí)踐總結(jié)》
附錄2：更多音視頻技術(shù)文章參考
[1] 開源實(shí)時(shí)音視頻技術(shù)WebRTC的文章：
《開源實(shí)時(shí)音視頻技術(shù)WebRTC的現(xiàn)狀》
《簡(jiǎn)述開源實(shí)時(shí)音視頻技術(shù)WebRTC的優(yōu)缺點(diǎn)》
《訪談WebRTC標(biāo)準(zhǔn)之父：WebRTC的過(guò)去、現(xiàn)在和未來(lái)》
《良心分享：WebRTC 零基礎(chǔ)開發(fā)者教程（中文）[附件下載]》
《WebRTC實(shí)時(shí)音視頻技術(shù)的整體架構(gòu)介紹》
《新手入門：到底什么是WebRTC服務(wù)器，以及它是如何聯(lián)接通話的？》
《WebRTC實(shí)時(shí)音視頻技術(shù)基礎(chǔ)：基本架構(gòu)和協(xié)議棧》
《淺談開發(fā)實(shí)時(shí)視頻直播平臺(tái)的技術(shù)要點(diǎn)》
《[觀點(diǎn)] WebRTC應(yīng)該選擇H.264視頻編碼的四大理由》
《基于開源WebRTC開發(fā)實(shí)時(shí)音視頻靠譜嗎？第3方SDK有哪些？》
《開源實(shí)時(shí)音視頻技術(shù)WebRTC中RTP/RTCP數(shù)據(jù)傳輸協(xié)議的應(yīng)用》
《簡(jiǎn)述實(shí)時(shí)音視頻聊天中端到端加密（E2EE）的工作原理》
《實(shí)時(shí)通信RTC技術(shù)棧之：視頻編解碼》
《開源實(shí)時(shí)音視頻技術(shù)WebRTC在Windows下的簡(jiǎn)明編譯教程》
《網(wǎng)頁(yè)端實(shí)時(shí)音視頻技術(shù)WebRTC：看起來(lái)很美，但離生產(chǎn)應(yīng)用還有多少坑要填？》
《了不起的WebRTC：生態(tài)日趨完善，或?qū)?shí)時(shí)音視頻技術(shù)白菜化》
《騰訊技術(shù)分享：微信小程序音視頻與WebRTC互通的技術(shù)思路和實(shí)踐》
>> 更多同類文章 ……
[2] 實(shí)時(shí)音視頻開發(fā)的其它精華資料：
《即時(shí)通訊音視頻開發(fā)（一）：視頻編解碼之理論概述》
《即時(shí)通訊音視頻開發(fā)（二）：視頻編解碼之?dāng)?shù)字視頻介紹》
《即時(shí)通訊音視頻開發(fā)（三）：視頻編解碼之編碼基礎(chǔ)》
《即時(shí)通訊音視頻開發(fā)（四）：視頻編解碼之預(yù)測(cè)技術(shù)介紹》
《即時(shí)通訊音視頻開發(fā)（五）：認(rèn)識(shí)主流視頻編碼技術(shù)H.264》
《即時(shí)通訊音視頻開發(fā)（六）：如何開始音頻編解碼技術(shù)的學(xué)習(xí)》
《即時(shí)通訊音視頻開發(fā)（七）：音頻基礎(chǔ)及編碼原理入門》
《即時(shí)通訊音視頻開發(fā)（八）：常見的實(shí)時(shí)語(yǔ)音通訊編碼標(biāo)準(zhǔn)》
《即時(shí)通訊音視頻開發(fā)（九）：實(shí)時(shí)語(yǔ)音通訊的回音及回音消除概述》
《即時(shí)通訊音視頻開發(fā)（十）：實(shí)時(shí)語(yǔ)音通訊的回音消除技術(shù)詳解》
《即時(shí)通訊音視頻開發(fā)（十一）：實(shí)時(shí)語(yǔ)音通訊丟包補(bǔ)償技術(shù)詳解》
《即時(shí)通訊音視頻開發(fā)（十二）：多人實(shí)時(shí)音視頻聊天架構(gòu)探討》
《即時(shí)通訊音視頻開發(fā)（十三）：實(shí)時(shí)視頻編碼H.264的特點(diǎn)與優(yōu)勢(shì)》
《即時(shí)通訊音視頻開發(fā)（十四）：實(shí)時(shí)音視頻數(shù)據(jù)傳輸協(xié)議介紹》
《即時(shí)通訊音視頻開發(fā)（十五）：聊聊P2P與實(shí)時(shí)音視頻的應(yīng)用情況》
《即時(shí)通訊音視頻開發(fā)（十六）：移動(dòng)端實(shí)時(shí)音視頻開發(fā)的幾個(gè)建議》
《即時(shí)通訊音視頻開發(fā)（十七）：視頻編碼H.264、VP8的前世今生》
《實(shí)時(shí)語(yǔ)音聊天中的音頻處理與編碼壓縮技術(shù)簡(jiǎn)述》
《網(wǎng)易視頻云技術(shù)分享：音頻處理與壓縮技術(shù)快速入門》
《學(xué)習(xí)RFC3550：RTP/RTCP實(shí)時(shí)傳輸協(xié)議基礎(chǔ)知識(shí)》
《基于RTMP數(shù)據(jù)傳輸協(xié)議的實(shí)時(shí)流媒體技術(shù)研究（論文全文）》
《聲網(wǎng)架構(gòu)師談實(shí)時(shí)音視頻云的實(shí)現(xiàn)難點(diǎn)(視頻采訪)》
《還在靠“喂喂喂”測(cè)試實(shí)時(shí)語(yǔ)音通話質(zhì)量？本文教你科學(xué)的評(píng)測(cè)方法！》
《如何用最簡(jiǎn)單的方法測(cè)試你的實(shí)時(shí)音視頻方案》
《簡(jiǎn)述實(shí)時(shí)音視頻聊天中端到端加密（E2EE）的工作原理》
《IM實(shí)時(shí)音視頻聊天時(shí)的回聲消除技術(shù)詳解》
《如何優(yōu)化傳輸機(jī)制來(lái)實(shí)現(xiàn)實(shí)時(shí)音視頻的超低延遲？》
《實(shí)時(shí)音視頻聊天技術(shù)分享：面向不可靠網(wǎng)絡(luò)的抗丟包編解碼器》
《專訪微信視頻技術(shù)負(fù)責(zé)人：微信實(shí)時(shí)視頻聊天技術(shù)的演進(jìn)》
《騰訊音視頻實(shí)驗(yàn)室：使用AI黑科技實(shí)現(xiàn)超低碼率的高清實(shí)時(shí)視頻聊天》
《微信團(tuán)隊(duì)分享：微信每日億次實(shí)時(shí)音視頻聊天背后的技術(shù)解密》
《福利貼：最全實(shí)時(shí)音視頻開發(fā)要用到的開源工程匯總》
《實(shí)時(shí)音視頻聊天中超低延遲架構(gòu)的思考與技術(shù)實(shí)踐》
《理解實(shí)時(shí)音視頻聊天中的延時(shí)問(wèn)題一篇就夠》
《寫給小白的實(shí)時(shí)音視頻技術(shù)入門提綱》
《微信多媒體團(tuán)隊(duì)訪談：音視頻開發(fā)的學(xué)習(xí)、微信的音視頻技術(shù)和挑戰(zhàn)等》
《騰訊技術(shù)分享：微信小程序音視頻技術(shù)背后的故事》
《微信多媒體團(tuán)隊(duì)梁俊斌訪談：聊一聊我所了解的音視頻技術(shù)》
《新浪微博技術(shù)分享：微博短視頻服務(wù)的優(yōu)化實(shí)踐之路》
《以網(wǎng)游服務(wù)端的網(wǎng)絡(luò)接入層設(shè)計(jì)為例，理解實(shí)時(shí)通信的技術(shù)挑戰(zhàn)》
《騰訊技術(shù)分享：微信小程序音視頻與WebRTC互通的技術(shù)思路和實(shí)踐》
>> 更多同類文章 ……
（本文同步發(fā)布于：http://www.52im.net/thread-2022-1-1.html）