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

互動白板產品簡介

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

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

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

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

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

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

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

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

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

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

多端操作沖突

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

操作亂序問題

操作亂序主要是由網絡亂序和服務端的并發請求導致的多端不同步。

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

操作丟失

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

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

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

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