本次分享先主要圍繞以下3個方面展開，互動白板的產(chǎn)品能力簡要介紹，互動白板的整體技術(shù)框架介紹還有互動白板的技術(shù)優(yōu)勢解析。技術(shù)點主要圍繞音視頻與白板的同步和多端實時互動同步講解。

互動白板產(chǎn)品簡介

首先我們?yōu)榇蠹医榻B即構(gòu)互動白板的產(chǎn)品特點，它依托于即構(gòu)成熟的億級海量用戶實時信令網(wǎng)絡(luò)，提供了功能齊全的百人實時在線白板互動服務(wù)，具有以下幾個特點。 全面覆蓋主流平臺、主流框架：我們各個平臺的技術(shù)方案都是基于原生平臺的技術(shù)框架開發(fā)，不依賴第三方框架，這主要是方便進行性能優(yōu)化還有降低SDK包的大小。 互動涂鴉實時同步：這個功能可以做的很簡單，但是要能夠適應(yīng)各種變化操作請求和網(wǎng)絡(luò)環(huán)境的話，還是比較有難度的，這也是我們要探討的一個技術(shù)點。 l白板繪制與音視頻實時同步：這是對于提升用戶體驗還是很大的一個功能點，也是我們此次分享要重點探討的。 主流文檔格式支持，包括PPT/PPTX/DOC/DOCX/XLS/XLSX/PDF/PNG/JPG/JPEG/BMP/TXT等常見的PPT、DOC、XLS，各種圖片格式、文檔格式等，且支持動態(tài)PPT。根據(jù)我們的了解，在支持文檔格式方面，即構(gòu)應(yīng)該是現(xiàn)在行業(yè)內(nèi)支持最全的。 豐富的白板教具，包括畫筆、問題、直線、矩形、橢圓、激光筆、橡皮擦等標準的工具。 白板與音視頻的實時同步錄制：這個功能主要是用于音視頻和白板的實時云端錄制，目前還處于內(nèi)測階段，相信很快就可以上線了，大家到時候可以關(guān)注一下。 以上就是對即構(gòu)互動白板產(chǎn)品能力的介紹。

互動白板技術(shù)框架 接下來，我們來了解一下互動白板的整體的技術(shù)框架。

從上圖可以看到，我們的整體技術(shù)框架主要由5個模塊構(gòu)成。互動白板服務(wù)主要負責信令數(shù)據(jù)的處理、存儲、轉(zhuǎn)發(fā)，同步信令就是由這個服務(wù)來完成的。文檔轉(zhuǎn)碼服務(wù)主要負責文檔的轉(zhuǎn)碼和文件訪問的鑒權(quán)控制，我們的轉(zhuǎn)碼服務(wù)支持轉(zhuǎn)碼出pdfPDF和SVGsvg，這兩種文件格式都支持矢量放大，所以在客戶端可以呈現(xiàn)一個較好的放大效果現(xiàn)場結(jié)果。云錄制服務(wù)用于對音視頻流和白板進行實時現(xiàn)場云端錄制。對象存儲和內(nèi)容分發(fā)網(wǎng)絡(luò)主要是基于云廠商提供的存儲和分發(fā)能力。 大家可以看到，我們整體的設(shè)計思想是課件的存儲與互動相分離，以便于進行擴容。轉(zhuǎn)碼與存儲相分離，除了可以使用即構(gòu)的對象存儲，我們給了客戶更多的選擇，比如客戶可以不使用即構(gòu)的對象存儲和內(nèi)容分發(fā)，而選擇使用自己的云存儲和內(nèi)容分發(fā)。畢竟有的客戶，比如說教育行業(yè)對課件的安全性是比較敏感的。整個服務(wù)目前已經(jīng)實現(xiàn)全球部署、就近接入，我們的互動白板服務(wù)、文件轉(zhuǎn)碼服務(wù)、云錄制服務(wù)都在國內(nèi)外部署了集群和全球的代理節(jié)點，便于用戶的信令就近訪問。依賴云廠商提供的全球能力存儲和內(nèi)容分發(fā)，我們也能夠?qū)崿F(xiàn)客戶對文檔資源的就近訪問。 這套技術(shù)框架從我們的實現(xiàn)來看，在并發(fā)性和吞吐性方面的表現(xiàn)是很出色的，這其實也是依賴我們在音視頻信令方面的技術(shù)積累。以上就是對整個技術(shù)框架的簡單介紹。

互動白板技術(shù)優(yōu)勢解析 關(guān)于技術(shù)優(yōu)勢的解析，我們主要圍繞白板音視頻同步和多端實時互動這兩個常見的技術(shù)難點進行解析。 白板音視頻同步 1. 痛點分析

（1）什么是白板音視頻不同步 從上圖展示的場景，很明顯我們可以知道在這個場景中白板比音視頻流先到達了學(xué)生端，從而導(dǎo)致學(xué)生端先看到了白板的操作再收到音視頻流。我們把上面從老師到學(xué)生的過程抽象為3個階段，分別為采集、傳輸階段和渲染階段。采集階段是在老師端，老師這邊的音視頻采集和白板操作其實是同步進行的，經(jīng)過傳輸后到達渲染，渲染出的結(jié)果并不同步，我們由此可以確定的是，這個問題是在傳輸階段產(chǎn)生的。那么接下來我們就來探討白板和音視頻是怎么進行傳輸?shù)摹?

（2）為什么會不同步 我們都知道音視頻的傳輸是通過流媒體網(wǎng)絡(luò)與視頻流進行傳輸。根據(jù)我們的了解，白板的傳輸在業(yè)內(nèi)目前主要有兩種通用模式，一種是以視頻流模式傳輸互動白板，另一種是以文件+信令的模式來傳輸互動白板。 我們先講解視頻流模式是怎樣傳輸?shù)?，比如在教育領(lǐng)域，老師端會經(jīng)常采集和共享某個窗口、屏幕或區(qū)域，然后通過對窗口、屏幕、區(qū)域進行畫面采集，通過視頻前處理、編碼、傳輸達到學(xué)生端，學(xué)生端再進行解碼后處理，并最終渲染出來，整個過程和音視頻沒什么區(qū)別。 而文件+信令的模式是依賴信令服務(wù)的模式，通過文檔服務(wù)對文件進行上傳、轉(zhuǎn)碼、分發(fā)、下載和渲染。在這個過程中，當有操作時便通過信令服務(wù)轉(zhuǎn)發(fā)操作信令。 （3）視頻流模式與文件+信令模式關(guān)鍵點對比 了解完兩種模式的白板傳輸，我們來比較一下這兩種模式的特點。 首先在帶寬占用上，因為視頻流模式很明顯，它具有更高的帶寬占用，尤其是在分辨率和幀率越高，碼率越大的情況下，帶寬占用也會相應(yīng)的增多。文件+信令模式除了文件上傳和下載還有中間的信令傳輸，數(shù)據(jù)量比較小，所以它的帶寬占用比較低，而且是在有操作的情況下才有信令傳輸。在帶寬占用方面，文件+信令模式是有優(yōu)勢的。 在清晰度方面，視頻流模式不支持矢量放大，且容易受網(wǎng)絡(luò)狀態(tài)的影響，在網(wǎng)絡(luò)條件較差時，為了保證音視頻流暢度往往需要降低碼率，從而導(dǎo)致清晰度更低。文件+信令模式則受網(wǎng)絡(luò)狀態(tài)的影響較低，只要網(wǎng)絡(luò)條件能夠確保把文件下載下來，通過矢量放大就可以達到很高的清晰度。 在成本方面占比較大比重的是帶寬，所以文件+信令模式具有更低的成本。 在互動性方面，由于通過視頻流傳輸是單向性的，而文件+信令模式是雙向性，所以相應(yīng)的互動性比較高。 在終端性能方面，由于視頻流模式會涉及視頻的編解碼、處理、渲染，所以對終端的性能要求比較高，而文件+信令模式只是文件和圖元的渲染，對終端的性能要求比較低。 當然視頻流模式也有它的優(yōu)點，由于它是單向傳輸?shù)?，所以?nèi)容比較豐富、易于擴展。比如在教育場景下，只要老師端做好，學(xué)生端就可以觀看到。文件+信令模式在這方面擴展性會受限于課件和教具，比如說白板的工具等，擴展性會稍差一些。 因為通過視頻流模式，白板和音視頻都是使用流媒體網(wǎng)絡(luò)，所以它們比較容易進行同步，而文件+信令模式因為一個是流媒體服務(wù)一個是信令服務(wù)，所以兩者比較難以同步。 通過以上比較我們發(fā)現(xiàn)，文件+信令模式在寬帶占用、清晰度、成本、互動性、終端性能等方面具有明顯的優(yōu)勢，對復(fù)雜多樣的設(shè)備和網(wǎng)絡(luò)環(huán)境具有更強的適應(yīng)性，所以該模式越來越成為業(yè)界的主流技術(shù)方式。但是該模式要解決的問題就是白板和音視頻同步問題。而白板和音視頻不同步的根本原因就在于音視頻走的是流媒體服務(wù)通道，互動白板走的是信令服務(wù)通道，兩者彼此相互獨立，沒有同步時間戳，各自渲染，當兩者傳輸延遲差超過200ms時用戶就能夠感覺到不同步的問題。 （4）最容易出現(xiàn)不同步問題的兩大場景

根據(jù)我們的經(jīng)驗，我們提煉出了以下兩個典型場景： 大班課場景。為了降低成本，大班課場景都會采用直播模式，音視頻流往往需要轉(zhuǎn)推CDN，這個時候的音視頻流傳輸延遲達到秒級，而白板信令的傳輸延遲是幾十毫秒。所以問題很明顯，白板信令和音視頻流延時時間差達到秒級以上，從而導(dǎo)致不同步問題。 小班課場景。在小班課場景下，為了達到一個良好的實時效果，一般會采用低延遲實時音視頻方案，在正常網(wǎng)絡(luò)下，現(xiàn)在主流的音視頻廠商，都可以做到音視頻的延遲在100ms以內(nèi)，所以這個時候，音視頻的傳輸延遲和互動白板的傳輸延遲其實并不大，觀看端是感受不到不同步的問題。但是一旦進入弱網(wǎng)情況，兩者的網(wǎng)絡(luò)傳輸延遲差會變大，因為音視頻流是采用UDP協(xié)議，而信令服務(wù)一般的傳輸協(xié)議是TCP協(xié)議，TCP協(xié)議在抗弱網(wǎng)方面天然就比UDP協(xié)議差，從而出現(xiàn)不同步的問題。所以我們后面的優(yōu)化方案將主要針對這兩種問題進行優(yōu)化。 2. 解決方案 （1）白板信令與音視頻流時間戳對齊

既然白板信令比音視頻流的傳輸延時低，但是我們又沒辦法控制傳輸?shù)难訒r，所以只能從控制渲染入手。那么要控制渲染，就需要在接收端進行時間戳的對齊，對齊之后再拋出來渲染。我們的解決思路是，當老師發(fā)起白板操作時，白板信令帶上當前的時間戳，同時把時間戳注入到音視頻流的SEI中。音視頻流和白板信令分別經(jīng)過流媒體服務(wù)和白板信令服務(wù)分發(fā)后，此時白板信令會先到達學(xué)生端，對白板數(shù)據(jù)進行緩沖，等到音視頻流到達后，解析出其中SEI的時間戳，對齊后再一起拋出渲染。通過這種方案可以達到一個完全的同步效果。 （2）白板信令網(wǎng)絡(luò)優(yōu)化

針對小班課場景白板信令網(wǎng)絡(luò)傳輸抗弱網(wǎng)性較差的問題，我們的解決思路是對白板的網(wǎng)絡(luò)傳輸進行優(yōu)化，提高白板信令的抗弱網(wǎng)性能，降低傳輸時延。基于我們在音視頻信令方面的技術(shù)實踐，我們從網(wǎng)絡(luò)傳輸協(xié)議入手，把TCP協(xié)議優(yōu)化為QUIC協(xié)議，相比TCP協(xié)議，QUIC協(xié)議具有以下優(yōu)勢： l降低連接延時，對QUIC協(xié)議有所了解的同學(xué)應(yīng)該知道，QUIC協(xié)議的傳輸協(xié)議是UDP，所以它可以減少握手次數(shù)，大部分場景下可以實現(xiàn)0RTT建連。 l改善擁塞控制，使用新的ACK確認機制，在丟包率高的網(wǎng)絡(luò)下，減少重傳量，提升網(wǎng)絡(luò)的恢復(fù)速度。 l多路復(fù)用避免對頭阻塞，一個連接的多個stream之間是沒有依賴的，不會互相影響，導(dǎo)致阻塞。 l實現(xiàn)前向糾錯，減少超時重傳。 l連接平滑遷移，客戶端切換網(wǎng)絡(luò)之后，如果是用TCP的話，會導(dǎo)致TCP的斷開和重連，但在QUIC協(xié)議之下，可以仍使用原來的連接。比如說客戶端從4g4G網(wǎng)絡(luò)切換到wifiWiFi網(wǎng)絡(luò)，可以實現(xiàn)不用重新連接的過程。 在具體的實踐上，我們在客戶端和白板信令服務(wù)之間接入了調(diào)度服務(wù)，這個服務(wù)是基于QUIC協(xié)議自研的調(diào)度服務(wù)。一方面，我們優(yōu)化了從客戶端到服務(wù)端的網(wǎng)絡(luò)傳輸協(xié)議，另一方面，接入的調(diào)度服務(wù)可以在全球進行多地部署，實現(xiàn)客戶端的就近接入。從以上兩方面來解決用戶最后一公里的接入問題，有效降低了白板信令的網(wǎng)絡(luò)傳輸延遲，提高了對弱網(wǎng)的抗性，從我們實際測試的效果來看，較之前有明顯的改善。 多端實時互動同步 1. 痛點分析

接下來，我們來探討一下多端實時互動同步的問題以及解決方法。 什么是多端實時不同步呢？我們還是以教育場景老師和學(xué)生為例，老師和學(xué)生同時對一個課件翻頁或移動處理，結(jié)果兩端呈現(xiàn)出來的結(jié)果不一致。通過對各種場景的分析，多端不一致的問題主要可以歸納為以下三點：

多端操作沖突

多端同時操作同一個對象產(chǎn)生沖突，導(dǎo)致多端的不同步。比如說a和b兩個人操作同一個對象，a把對象往左拖，b把對象往右拖，結(jié)果是a看到的對象在左邊，b看到的在右邊，兩者呈現(xiàn)不一致。這個問題的根本原因主要在于沖突導(dǎo)致，這個問題解決方案是：當多端發(fā)起操作時服務(wù)端如何進行沖突處理，客戶端該執(zhí)行什么樣的策略，確保各端執(zhí)行同樣的規(guī)則，從而實現(xiàn)多端的一致性。

操作亂序問題

操作亂序主要是由網(wǎng)絡(luò)亂序和服務(wù)端的并發(fā)請求導(dǎo)致的多端不同步。

我們以上圖中的場景為例介紹亂序的問題。左邊是操作端，右邊是觀看端，操作端把一個對象從a點快速移到b點，又快速移到c點，所以它的最后結(jié)果是在c點。而觀看端收到的結(jié)果卻是，這個對象被從a點移到c點又移到b點，最終結(jié)果是b點，導(dǎo)致兩者呈現(xiàn)不一致。該問題的難點是如何解決由信令請求在網(wǎng)絡(luò)傳輸過程中亂序和并發(fā)請求導(dǎo)致的不同步問題。

操作丟失

操作丟失一般是由于白板信令方?jīng)]有到達接收端導(dǎo)致的多端不同步。比如說老師在互動白板上畫了個矩形，結(jié)果課堂里有部分同學(xué)收到了矩形，有部分同學(xué)沒有收到，從而導(dǎo)致所有人的結(jié)果不一致。該問題的原因一般是接收端因為網(wǎng)絡(luò)原因沒有收到該操作指令，導(dǎo)致操作端和接收端結(jié)果不一致。 2. 解決方案 （1）多端操作同步

針對以上痛點我們分別對其進行了優(yōu)化，其實在線協(xié)作文檔里面臨的最大問題就是多端同步問題，這方面比較成熟的方案是用OT算法?；影装逶趨f(xié)作性上其實和在線文檔較為類似，因此，我們在互動白板上借鑒了該思路，采用了中心化的思想來做多端同步。 它的思路是這樣的，OT中心負責對客戶端的操作請求，根據(jù)客戶端版本、操作對象、操作類型等信息，進行操作請求的沖突判定、合并操作、轉(zhuǎn)換生成統(tǒng)一操作，通知客戶端，客戶端只需要根據(jù)服務(wù)端的通知進行相應(yīng)的處理即可。 由于客戶端只需要執(zhí)行服務(wù)端的操作，那么整個的沖突判定還有合并處理全由服務(wù)端來處理，這樣就比較容易達到多端同步，這是一個中心化的思想。 互動白板里其實比較難的點應(yīng)該是文本編輯，這里可以做的很簡單，也可以做的很復(fù)雜，如果做的很復(fù)雜的話，其實有點類似于在線協(xié)作文檔，如果有對這方面感興趣的同學(xué)，可以去網(wǎng)上搜一些相關(guān)的OT開源算法進行了解，我們不在這里對這個點進行闡述。這就是多端操作同步的思路。 （2）亂序操作

關(guān)于操作亂序，大家可以看到完整的單向互動流程是像上圖這樣的，我們可以把整個過程分成clientA到server和server到clientB兩個階段，來分別看看這兩個階段因此亂序的原因是什么。 clientA到server階段： 客戶端對服務(wù)端發(fā)起并發(fā)的http請求的時候，多個請求有可能走不同的網(wǎng)絡(luò)鏈路，這個時候，有一個鏈路的網(wǎng)絡(luò)有問題就可能導(dǎo)致請求后發(fā)先至，也就是服務(wù)端收到的請求是亂序的。比較簡單粗暴的解決方案就是客戶端執(zhí)行串行發(fā)送，每一個請求都等服務(wù)端回包完成之后再執(zhí)行下一個請求。根據(jù)我們的實踐，這種方法可以很好的解決客戶端到server的亂序問題。 server到clientB： 因為服務(wù)端推送到客戶端一般采用的是TCP長連接，所以這里的亂序問題一般不是由網(wǎng)絡(luò)傳輸導(dǎo)致的，更多的是由于服務(wù)器的設(shè)計方案導(dǎo)致。比如說在服務(wù)端沒有做串行的設(shè)計而是選擇并發(fā)的請求，就有可能從服務(wù)端發(fā)出去的請求是亂序的。那么較為簡單的解決思路就是把服務(wù)端做成串行發(fā)送的模式。但是，根據(jù)我們的經(jīng)驗，出于對服務(wù)端性能的考慮，我們并沒有采用這個方案。我們采用的方案是把這個工作交給客戶端來做，在客戶端進行一個亂序重排，這樣可以有效的分擔服務(wù)端的壓力，對服務(wù)端的并發(fā)和吞吐性具有更好的效果。 （3）操作丟失

操作丟失的問題可以看一下上圖的例子，操作端發(fā)送了兩個操作都到達了白板信令服務(wù)，白板信令服務(wù)也按順序發(fā)了，先發(fā)了操作1接受端收到了，但當發(fā)操作2時，接收端網(wǎng)絡(luò)掉線了，導(dǎo)致接收端沒有收到該指令。那么在這種情況下，接收端怎么去把這個丟失的請求同步回來呢？ 我們的解決思路主要是兩種，第一，接收端需要對網(wǎng)絡(luò)狀態(tài)進行監(jiān)控，當察覺到網(wǎng)絡(luò)異常時，在斷網(wǎng)重連后能夠主動去發(fā)起同步。第二，在接受端和服務(wù)端維持一個心跳同步協(xié)議，這樣就可以確保無論什么時候，即使稍微慢點也能把丟失的操作同步回來。我們通過以上兩種方案，基本可以完全解決操作丟失的問題。 我們通過以上三點，對多端操作同步進行優(yōu)化，從而達到一個較佳的效果，但多端操作的沖突里面，最復(fù)雜的應(yīng)該是OT中心的轉(zhuǎn)換，因為這里面操作比較多，所以需要去做不同的策略，同時也需要去探索尋找更好的解決方案。 總結(jié)一下以上的內(nèi)容主要是介紹即構(gòu)互動白板的產(chǎn)品能力，闡述了整體的技術(shù)框架，針對白板音視頻同步和多端實時同步兩個技術(shù)難點分享了我們的相關(guān)探索和實踐。大家如果覺得我們的方案有什么不合理的地方也可以告知我們，或者有更優(yōu)的方案也歡迎提出來幫助我們進行改進。