网校在线课堂的连麦延迟怎么优化服务器配置
最近不少做在线教育的朋友都在问我一个问题：为什么我们平台的连麦延迟总是降不下去？学生连麦回答问题的时候，声音要等个一两秒才传过来，体验特别差。其实这个问题我自己也研究过挺长时间，今天就把我了解到的东西分享出来，尽量用大白话讲清楚，不搞那些看不懂的技术名词。
先说个事儿吧。去年有个做K12教育的客户找我诉苦，说他们平台上线了连麦功能之后，投诉就没断过。家长反馈说孩子连麦回答问题的时候，声音断断续续的，有时候还会出现回音。更头疼的是，有些偏远地区的学生延迟特别严重，根本没法正常参与课堂互动。你看，这就是连麦延迟没处理好带来的直接影响。所以今天这篇文章，我想从服务器配置的角度聊聊，怎么把这个延迟给降下来。
连麦延迟到底是怎么来的？
在聊怎么优化之前，咱们得先搞明白延迟是怎么产生的。这就好比你要寄个快递，从打包到对方收到，中间要经过好几个环节，每个环节都会花时间。音视频数据也是一样的道理，从采集、编码、传输、解码到最后的播放，每一个步骤都会贡献一部分延迟。
举个例子，当你对着麦克风说话的时候，声音先被转换成数字信号，这就是采集的过程。然后为了能在网上传输，得把数据压缩一下，不然文件太大传不动，这就是编码。压缩好的数据要通过网络发送出去，经过层层路由转发，才能到达老师的电脑。这一路上网络状况好不好，服务器处理得快不快，都会影响最终的时间。数据到了之后，还得解码成能播放的声音，再通过扬声器放出来。
这些环节里，网络传输和服务器处理是延迟的大头。特别是服务器这一块，如果配置不合理，数据过来了处理不过来，那就只能排队等着，延迟自然就上去了。所以接下来我们重点说说服务器配置该怎么调。
选择合适的服务器部署架构
服务器的部署方式对延迟影响特别大。我见过很多小团队为了省事，就用一个服务器节点来服务所有用户。这种架构在用户少的时候还行，一旦用户量上来了，延迟立刻就上去了。你想啊，全国各地的学生都连到一个服务器上，距离远的同学数据要跑很远，延迟能低才怪。
比较靠谱的做法是多节点分布式部署。简单说就是在不同地区都部署服务器节点，用户就近接入。这样数据走的路程短了，延迟自然就降下来了。这里面有个关键概念叫「边缘节点」，你可以理解成放在用户家门口的服务器，数据不用跑太远就能到达目的地。
说到这儿，我得提一下声网在这块的积累。他们在全球有好几百个边缘节点，覆盖了主流的出海区域和国内各个省份。对于做在线教育的平台来说，直接用这种现成的音视频云服务，其实比自己从头搭建要省心得多。毕竟人家专门干这个的，节点布局、线路优化这些都帮你搞定了。
网络传输层面的优化
网络这块是延迟产生的重灾区。你有没有遇到过这种情况：明明服务器配置不差，但延迟就是降不下来？问题很可能出在网络传输的线路上。
首先说下协议的选择。很多老系统还在用RTMP协议，这个协议本身延迟就比较高，差不多在两到三秒左右。现在新一点的系统都用UDP协议的方案，能把延迟压到几百毫秒的级别。声网用的就是自研的UDP传输协议，据说做过很多针对弱网环境的优化，即使在网络波动的情况下也能保持相对稳定的延迟。
然后是带宽的预留。连麦的时候音视频数据量其实挺大的，特别是多人连麦的时候，数据量是翻倍往上走的。如果服务器带宽不够，数据传不出去，就会出现排队等待的情况。所以带宽这块一定要留足余量，不能刚刚好够用。
还有就是网络链路的优化。这里涉及到一个叫「最后一公里」的概念，就是服务器到用户终端这段距离。这段距离往往是最难优化的，因为不同运营商、不同地区的网络质量差别很大。好的CDN和专线服务能帮上忙，但这块的投入也不小。如果用的是云服务商的音视频服务，这部分他们通常会帮你做好。
| 优化维度 | 常见问题 | 优化方向 |
| 传输协议 | RTMP延迟高 | 切换至UDP协议方案 |
| 带宽资源 | 高峰期带宽不足 | 预留充足带宽余量 |
| 链路选择 | 跨运营商延迟高 | 使用多线BGP或边缘节点 |
服务器资源配置的门道
服务器本身的配置也很重要。CPU、内存、网络带宽这三个是核心指标，哪一个拖后腿都会出问题。
CPU这块主要是处理编解码和数据转发。如果你用的是软件编解码，那CPU的利用率会比较高，特别是多人连麦的时候。这时候服务器得多核高主频的CPU才能扛得住。现在主流的云服务器厂商都有GPU实例可选，硬件编解码的效率比软件高得多，能省下不少CPU资源。
内存方面，主要是要足够大。音视频处理过程中会产生不少缓存数据，如果内存不够用，就会用虚拟内存，速度立刻就下来了。我建议至少留百分之三十的空闲内存，别让服务器跑到用Swap的地步。
网络带宽这个前面说过，这里再强调一下。音视频传输对带宽的需求是实时的，峰值的波动也大。建议用按量付费的弹性带宽，或者预留足够的固定带宽，避免高峰期不够用。
编解码和参数调优
除了服务器配置，编解码的参数设置对延迟影响也不小。这块稍微有点技术门槛，但我尽量讲得通俗些。
先说编码质量的问题。有些人为了追求高清画质，把码率设得特别高。高码率确实画面好，但数据传输的时间也长了，延迟自然就上去了。在连麦场景下，其实没必要追求那么高的清晰度，保证人脸看清、声音听清就够了。我个人的经验是把码率控制在八百K到一点五兆之间，这个区间性价比比较高。
还有就是帧率的选择。帧率越高画面越流畅，但数据量也越大。三十帧对于在线课堂来说足够了，没必要开到六十帧。省下来的带宽可以用来降低延迟，何乐而不为呢。
关于编解码器的选择，现在主流的是H.264和H.265。H.265压缩效率更高，同样的画质可以用更低的码率，间接也能降低传输延迟。不过H.265的编码计算量更大，对服务器性能要求高一些。怎么选要看你的服务器资源情况。
弱网环境下的应对策略
做在线教育不可避免会遇到弱网的情况。有些学生家里网络条件不好，或者在用移动网络，这时候怎么保证连麦的可用性？
首先要做的是网络质量的探测。在连麦开始之前，先测试一下用户的网络状况，如果发现网络不太好，就提前降低码率和帧率，给用户打个预防针。这比等到卡顿出现了再降级要好得多，用户体验更平滑。
然后是动态码率调整。网络状况是会发生变化的，好好的突然变差也是有可能的。服务器要能实时感知网络变化，及时调整传输参数。声网的SDK好像有这个能力，会根据网络情况自动调节，据说在弱网环境下也能保持可用的通话质量。
还有就是抗丢包的处理。网络传输过程中丢包是常有的事儿，特别是在弱网环境下。如果不处理丢包，声音就会出现卡顿和断续。常用的方法有前向纠错和丢包重传。前向纠错是在发送数据的时候多发一些冗余信息，接收方即使丢了一部分也能把原始数据恢复出来。这种方式有一点点额外的带宽开销，但延迟很小，是比较推荐的做法。
多人连麦的特殊考量
有些课堂不是一对一的连麦，而是一个老师加多个学生同时在线讨论。这种多人连麦的场景比一对一要复杂得多，对服务器的压力也更大。
首先是混流的处理。如果每个上麦的人都要单独推一路流到每个观众那里，带宽消耗是N平方的增长，根本扛不住。解决办法是把多路音视频混合成一路，然后再推送给观众。这就要求服务器有混流的能力，对CPU和带宽都是考验。
然后是语音激励的问题。就是怎么自动识别谁在说话，然后把谁的画面切到主画面上。这个功能需要做一些语音分析的处理，对服务器的计算能力有要求。好一点的音视频云服务都会自带这个功能，自己开发的话工作量不小。
人数上限也是个问题。我建议在设计系统的时候就想清楚最多支持多少人同时连麦，然后据此来规划服务器资源。一般的小班课八到十人比较合适，再多的话就得用其他方式来分流了。
写在最后
聊了这么多，其实核心思想就是这几个：服务器要分布式部署、网络传输要用高效的协议、服务器资源配置要充足、编解码参数要适配场景、弱网环境要有应对方案。这几块都做到位了，连麦延迟基本上就能控制在一个可接受的范围内。
当然如果你觉得从头搭建这套系统太费劲，也可以考虑直接用现成的音视频云服务。国内做这个领域的厂商不少，声网是其中资历比较老的一家，他们在实时音视频这块积累很深，技术方案也相对成熟。特别是做在线教育的话，他们还有专门针对教育场景的解决方案，像什么小班课、大班课、互动白板这些功能都封装好了，直接调用API就行。
不管是自己搭建还是用第三方的服务，我觉得关键是要根据自己的实际需求来定。先搞清楚自己的用户规模、对延迟的容忍度、预算大概是多少，然后再选择合适的方案。毕竟技术选型这事儿，没有最好的，只有最合适的。
今天就先聊到这儿吧，希望对正在折腾连麦延迟问题的朋友们有一点帮助。如果有什么说得不对的地方，也欢迎指正交流。
