本文整理自即构科技互动白板技术负责人陈晓聪在LiveVideoStack的线上分享，内容主要围绕白板与音视频的同步和白板的多端实时互动两个角度，深度解析即构在互动白板方面的技术探索实践。
文 / 陈晓聪
整理 / LiveVideoStack
大家好，我是来自即构的陈晓聪，现在主要负责互动白板的技术研发工作。接下来我将为大家分享即构在互动白板的技术探索实践。
![]()
本次分享先主要围绕以下3个方面展开，互动白板的产品能力简要介绍，互动白板的整体技术框架介绍还有互动白板的技术优势解析。技术点主要围绕音视频与白板的同步和多端实时互动同步讲解。
首先我们为大家介绍即构互动白板的产品特点，它依托于即构成熟的亿级海量用户实时信令网络，提供了功能齐全的百人实时在线白板互动服务，具有以下几个特点。全面覆盖主流平台、主流框架：我们各个平台的技术方案都是基于原生平台的技术框架开发，不依赖第三方框架，这主要是方便进行性能优化还有降低SDK包的大小。互动涂鸦实时同步：这个功能可以做的很简单，但是要能够适应各种变化操作请求和网络环境的话，还是比较有难度的，这也是我们要探讨的一个技术点。l白板绘制与音视频实时同步：这是对于提升用户体验还是很大的一个功能点，也是我们此次分享要重点探讨的。主流文档格式支持，包括PPT/PPTX/DOC/DOCX/XLS/XLSX/PDF/PNG/JPG/JPEG/BMP/TXT等常见的PPT、DOC、XLS，各种图片格式、文档格式等，且支持动态PPT。根据我们的了解，在支持文档格式方面，即构应该是现在行业内支持最全的。丰富的白板教具，包括画笔、问题、直线、矩形、椭圆、激光笔、橡皮擦等标准的工具。白板与音视频的实时同步录制：这个功能主要是用于音视频和白板的实时云端录制，目前还处于内测阶段，相信很快就可以上线了，大家到时候可以关注一下。
从上图可以看到，我们的整体技术框架主要由5个模块构成。互动白板服务主要负责信令数据的处理、存储、转发，同步信令就是由这个服务来完成的。文档转码服务主要负责文档的转码和文件访问的鉴权控制，我们的转码服务支持转码出pdfPDF和SVGsvg，这两种文件格式都支持矢量放大，所以在客户端可以呈现一个较好的放大效果现场结果。云录制服务用于对音视频流和白板进行实时现场云端录制。对象存储和内容分发网络主要是基于云厂商提供的存储和分发能力。大家可以看到，我们整体的设计思想是课件的存储与互动相分离，以便于进行扩容。转码与存储相分离，除了可以使用即构的对象存储，我们给了客户更多的选择，比如客户可以不使用即构的对象存储和内容分发，而选择使用自己的云存储和内容分发。毕竟有的客户，比如说教育行业对课件的安全性是比较敏感的。整个服务目前已经实现全球部署、就近接入，我们的互动白板服务、文件转码服务、云录制服务都在国内外部署了集群和全球的代理节点，便于用户的信令就近访问。依赖云厂商提供的全球能力存储和内容分发，我们也能够实现客户对文档资源的就近访问。这套技术框架从我们的实现来看，在并发性和吞吐性方面的表现是很出色的，这其实也是依赖我们在音视频信令方面的技术积累。以上就是对整个技术框架的简单介绍。
关于技术优势的解析，我们主要围绕白板音视频同步和多端实时互动这两个常见的技术难点进行解析。从上图展示的场景，很明显我们可以知道在这个场景中白板比音视频流先到达了学生端，从而导致学生端先看到了白板的操作再收到音视频流。我们把上面从老师到学生的过程抽象为3个阶段，分别为采集、传输阶段和渲染阶段。采集阶段是在老师端，老师这边的音视频采集和白板操作其实是同步进行的，经过传输后到达渲染，渲染出的结果并不同步，我们由此可以确定的是，这个问题是在传输阶段产生的。那么接下来我们就来探讨白板和音视频是怎么进行传输的。我们都知道音视频的传输是通过流媒体网络与视频流进行传输。根据我们的了解，白板的传输在业内目前主要有两种通用模式，一种是以视频流模式传输互动白板，另一种是以文件+信令的模式来传输互动白板。我们先讲解视频流模式是怎样传输的，比如在教育领域，老师端会经常采集和共享某个窗口、屏幕或区域，然后通过对窗口、屏幕、区域进行画面采集，通过视频前处理、编码、传输达到学生端，学生端再进行解码后处理，并最终渲染出来，整个过程和音视频没什么区别。而文件+信令的模式是依赖信令服务的模式，通过文档服务对文件进行上传、转码、分发、下载和渲染。在这个过程中，当有操作时便通过信令服务转发操作信令。了解完两种模式的白板传输，我们来比较一下这两种模式的特点。首先在带宽占用上，因为视频流模式很明显，它具有更高的带宽占用，尤其是在分辨率和帧率越高，码率越大的情况下，带宽占用也会相应的增多。文件+信令模式除了文件上传和下载还有中间的信令传输，数据量比较小，所以它的带宽占用比较低，而且是在有操作的情况下才有信令传输。在带宽占用方面，文件+信令模式是有优势的。在清晰度方面，视频流模式不支持矢量放大，且容易受网络状态的影响，在网络条件较差时，为了保证音视频流畅度往往需要降低码率，从而导致清晰度更低。文件+信令模式则受网络状态的影响较低，只要网络条件能够确保把文件下载下来，通过矢量放大就可以达到很高的清晰度。在成本方面占比较大比重的是带宽，所以文件+信令模式具有更低的成本。在互动性方面，由于通过视频流传输是单向性的，而文件+信令模式是双向性，所以相应的互动性比较高。在终端性能方面，由于视频流模式会涉及视频的编解码、处理、渲染，所以对终端的性能要求比较高，而文件+信令模式只是文件和图元的渲染，对终端的性能要求比较低。当然视频流模式也有它的优点，由于它是单向传输的，所以内容比较丰富、易于扩展。比如在教育场景下，只要老师端做好，学生端就可以观看到。文件+信令模式在这方面扩展性会受限于课件和教具，比如说白板的工具等，扩展性会稍差一些。因为通过视频流模式，白板和音视频都是使用流媒体网络，所以它们比较容易进行同步，而文件+信令模式因为一个是流媒体服务一个是信令服务，所以两者比较难以同步。通过以上比较我们发现，文件+信令模式在宽带占用、清晰度、成本、互动性、终端性能等方面具有明显的优势，对复杂多样的设备和网络环境具有更强的适应性，所以该模式越来越成为业界的主流技术方式。但是该模式要解决的问题就是白板和音视频同步问题。而白板和音视频不同步的根本原因就在于音视频走的是流媒体服务通道，互动白板走的是信令服务通道，两者彼此相互独立，没有同步时间戳，各自渲染，当两者传输延迟差超过200ms时用户就能够感觉到不同步的问题。大班课场景。为了降低成本，大班课场景都会采用直播模式，音视频流往往需要转推CDN，这个时候的音视频流传输延迟达到秒级，而白板信令的传输延迟是几十毫秒。所以问题很明显，白板信令和音视频流延时时间差达到秒级以上，从而导致不同步问题。小班课场景。在小班课场景下，为了达到一个良好的实时效果，一般会采用低延迟实时音视频方案，在正常网络下，现在主流的音视频厂商，都可以做到音视频的延迟在100ms以内，所以这个时候，音视频的传输延迟和互动白板的传输延迟其实并不大，观看端是感受不到不同步的问题。但是一旦进入弱网情况，两者的网络传输延迟差会变大，因为音视频流是采用UDP协议，而信令服务一般的传输协议是TCP协议，TCP协议在抗弱网方面天然就比UDP协议差，从而出现不同步的问题。所以我们后面的优化方案将主要针对这两种问题进行优化。既然白板信令比音视频流的传输延时低，但是我们又没办法控制传输的延时，所以只能从控制渲染入手。那么要控制渲染，就需要在接收端进行时间戳的对齐，对齐之后再抛出来渲染。我们的解决思路是，当老师发起白板操作时，白板信令带上当前的时间戳，同时把时间戳注入到音视频流的SEI中。音视频流和白板信令分别经过流媒体服务和白板信令服务分发后，此时白板信令会先到达学生端，对白板数据进行缓冲，等到音视频流到达后，解析出其中SEI的时间戳，对齐后再一起抛出渲染。通过这种方案可以达到一个完全的同步效果。针对小班课场景白板信令网络传输抗弱网性较差的问题，我们的解决思路是对白板的网络传输进行优化，提高白板信令的抗弱网性能，降低传输时延。基于我们在音视频信令方面的技术实践，我们从网络传输协议入手，把TCP协议优化为QUIC协议，相比TCP协议，QUIC协议具有以下优势：l降低连接延时，对QUIC协议有所了解的同学应该知道，QUIC协议的传输协议是UDP，所以它可以减少握手次数，大部分场景下可以实现0RTT建连。l改善拥塞控制，使用新的ACK确认机制，在丢包率高的网络下，减少重传量，提升网络的恢复速度。l多路复用避免对头阻塞，一个连接的多个stream之间是没有依赖的，不会互相影响，导致阻塞。l连接平滑迁移，客户端切换网络之后，如果是用TCP的话，会导致TCP的断开和重连，但在QUIC协议之下，可以仍使用原来的连接。比如说客户端从4g4G网络切换到wifiWiFi网络，可以实现不用重新连接的过程。在具体的实践上，我们在客户端和白板信令服务之间接入了调度服务，这个服务是基于QUIC协议自研的调度服务。一方面，我们优化了从客户端到服务端的网络传输协议，另一方面，接入的调度服务可以在全球进行多地部署，实现客户端的就近接入。从以上两方面来解决用户最后一公里的接入问题，有效降低了白板信令的网络传输延迟，提高了对弱网的抗性，从我们实际测试的效果来看，较之前有明显的改善。接下来，我们来探讨一下多端实时互动同步的问题以及解决方法。什么是多端实时不同步呢？我们还是以教育场景老师和学生为例，老师和学生同时对一个课件翻页或移动处理，结果两端呈现出来的结果不一致。通过对各种场景的分析，多端不一致的问题主要可以归纳为以下三点：多端同时操作同一个对象产生冲突，导致多端的不同步。比如说a和b两个人操作同一个对象，a把对象往左拖，b把对象往右拖，结果是a看到的对象在左边，b看到的在右边，两者呈现不一致。这个问题的根本原因主要在于冲突导致，这个问题解决方案是：当多端发起操作时服务端如何进行冲突处理，客户端该执行什么样的策略，确保各端执行同样的规则，从而实现多端的一致性。操作乱序主要是由网络乱序和服务端的并发请求导致的多端不同步。我们以上图中的场景为例介绍乱序的问题。左边是操作端，右边是观看端，操作端把一个对象从a点快速移到b点，又快速移到c点，所以它的最后结果是在c点。而观看端收到的结果却是，这个对象被从a点移到c点又移到b点，最终结果是b点，导致两者呈现不一致。该问题的难点是如何解决由信令请求在网络传输过程中乱序和并发请求导致的不同步问题。操作丢失一般是由于白板信令方没有到达接收端导致的多端不同步。比如说老师在互动白板上画了个矩形，结果课堂里有部分同学收到了矩形，有部分同学没有收到，从而导致所有人的结果不一致。该问题的原因一般是接收端因为网络原因没有收到该操作指令，导致操作端和接收端结果不一致。针对以上痛点我们分别对其进行了优化，其实在线协作文档里面临的最大问题就是多端同步问题，这方面比较成熟的方案是用OT算法。互动白板在协作性上其实和在线文档较为类似，因此，我们在互动白板上借鉴了该思路，采用了中心化的思想来做多端同步。它的思路是这样的，OT中心负责对客户端的操作请求，根据客户端版本、操作对象、操作类型等信息，进行操作请求的冲突判定、合并操作、转换生成统一操作，通知客户端，客户端只需要根据服务端的通知进行相应的处理即可。由于客户端只需要执行服务端的操作，那么整个的冲突判定还有合并处理全由服务端来处理，这样就比较容易达到多端同步，这是一个中心化的思想。互动白板里其实比较难的点应该是文本编辑，这里可以做的很简单，也可以做的很复杂，如果做的很复杂的话，其实有点类似于在线协作文档，如果有对这方面感兴趣的同学，可以去网上搜一些相关的OT开源算法进行了解，我们不在这里对这个点进行阐述。这就是多端操作同步的思路。关于操作乱序，大家可以看到完整的单向互动流程是像上图这样的，我们可以把整个过程分成clientA到server和server到clientB两个阶段，来分别看看这两个阶段因此乱序的原因是什么。客户端对服务端发起并发的http请求的时候，多个请求有可能走不同的网络链路，这个时候，有一个链路的网络有问题就可能导致请求后发先至，也就是服务端收到的请求是乱序的。比较简单粗暴的解决方案就是客户端执行串行发送，每一个请求都等服务端回包完成之后再执行下一个请求。根据我们的实践，这种方法可以很好的解决客户端到server的乱序问题。因为服务端推送到客户端一般采用的是TCP长连接，所以这里的乱序问题一般不是由网络传输导致的，更多的是由于服务器的设计方案导致。比如说在服务端没有做串行的设计而是选择并发的请求，就有可能从服务端发出去的请求是乱序的。那么较为简单的解决思路就是把服务端做成串行发送的模式。但是，根据我们的经验，出于对服务端性能的考虑，我们并没有采用这个方案。我们采用的方案是把这个工作交给客户端来做，在客户端进行一个乱序重排，这样可以有效的分担服务端的压力，对服务端的并发和吞吐性具有更好的效果。操作丢失的问题可以看一下上图的例子，操作端发送了两个操作都到达了白板信令服务，白板信令服务也按顺序发了，先发了操作1接受端收到了，但当发操作2时，接收端网络掉线了，导致接收端没有收到该指令。那么在这种情况下，接收端怎么去把这个丢失的请求同步回来呢？我们的解决思路主要是两种，第一，接收端需要对网络状态进行监控，当察觉到网络异常时，在断网重连后能够主动去发起同步。第二，在接受端和服务端维持一个心跳同步协议，这样就可以确保无论什么时候，即使稍微慢点也能把丢失的操作同步回来。我们通过以上两种方案，基本可以完全解决操作丢失的问题。我们通过以上三点，对多端操作同步进行优化，从而达到一个较佳的效果，但多端操作的冲突里面，最复杂的应该是OT中心的转换，因为这里面操作比较多，所以需要去做不同的策略，同时也需要去探索寻找更好的解决方案。总结一下以上的内容主要是介绍即构互动白板的产品能力，阐述了整体的技术框架，针对白板音视频同步和多端实时同步两个技术难点分享了我们的相关探索和实践。大家如果觉得我们的方案有什么不合理的地方也可以告知我们，或者有更优的方案也欢迎提出来帮助我们进行改进。关于互动白板的其他技术点的解析，我们也发布了相关的文章，大家感兴趣的话，可以关注下。白板体验Demo:https://www.wjx.top/m/87298128.aspx
![]()
LiveVideoStackCon 2020 北京