WebRTC、标准测试、大前端技术、实时网络质量……RTC2018帮你“划重点”！

话说，这种变化似乎就发生在一夜之间……

• 从跨国VoIP电话到连麦互动以及实时音视频通话；

• 从直播答题撒币到传统电商都可以实时在线抓娃娃；

• 将“新鲜”趁热打铁，火的不要不要的微信官方小程序也赶趟儿宣布开放了实时音视频通信接口；

• 就连人们熟知的教育、互联网金融、安防以及企业通信，也都纷纷对实时互动场景抛出了绣球，开展了“联姻”……

“实时”两个字满屏飞，背后呢？

这些让人感觉颇为新奇的“变化”统统都要归功于RTC技术。

RTC，如今人们经常说到的实时通信技术，从传统互联网过渡到移动互联网的过程中，在很多领域都有广泛应用。

如今开发者们完全可以通过各种实时通信API集成RTC云服务能力，在各种原生应用、Web网页、H5、硬件设备中加入实时通信功能，而WebRTC被称为网络实时通信，是 RTC子模块之一，被日渐重视。

相关数据显示，每周仅在Chrome浏览器上就会有超过15亿分钟的WebRTC音视频通话。

依照目前的统计，有超过1,300个从事WebRTC的公司和项目。

浏览器在日常生活中如此常见，据悉所有安装的浏览器中就会有80%已经内置了WebRTC。

应用频率如此之高，可见其技术发展日渐成熟。在此基础上，WebRTC1.0候选推荐标准也于去年正式被“呼出”。

可能出现的标准“新探”都在这里

基于此，在RTC2018大会上，WebRTC标准委员会委员Daniel C. Burnett 为与会开发者们详细介绍了该标准实施之后所开展的各项工作。他表示，其实在核心规范层面的变化是比较少的，说到发展，绝大多数是针对部分规范增强的“加码”！

通常来说，人们都比较注重安全问题，当然WebRTC也不例外。为防止信息泄露，通常都会对RPT的流量进行加密。

背后的理念就是加密捕获的媒体，必须要有指定个人进行解密，而且需要登陆之后才可以做到，

这点是需要额外注意的特殊功能之一。

进一步来说，WebRTC对于浏览器，一旦接触到媒体就会产生编码，可以使用任何想要的编码器进行解码工作，在这方面的拓展主要集中在让开发者可以使用java进行解密或者加密，从而对编码参数的控制更加有力。基于这个新功能，WebRTC达到的效果是可以做到不需要经常打开浏览器的窗口。

这究竟有何好处呢？

可以妥妥解决临时进入的电话接听问题。

“这个功能十分适合视频，过程中不需要经常打开浏览器窗口；而且还对背景语音的处理十分有效，尤其是语音识别方面。”Dan Burnett 补充道。

WebRTC标准委员会成员  Daniel C. Burnett 

此外，关于SVC的controls的性能加持也十分重要。

具体来说， Daniel C. Burnett 阐释道，本质上是一个可扩展的视频编码，具备后就可以在时间与空间上进行压缩，其中时间压缩能以比较慢的速率发送帧，比较高的速率插入可选的额外帧，类似于大家喜欢的联播。

其中空间压缩和时间压缩非常类似，能够发送低分辨率的帧，可以插入可扩展分辨率额外的帧等，所以可以采用比较低分辨率的帧。

“目前，我们正在设计一个加速 TLS以及HTTP新传送，这是受到WebRTC开发经验和教训的启发。这点Google非常支持我们，之前在quick领域做得很多开发实践都是基于WebRTC之前的经验和教训，如今可能涉及到不同的连接设置中往返需要时间这样类型的探索。”他说。

众所周知，让互联网更快的路就是通往QUIC的这一条。 Daniel C. Burnett也提出，quic流的数据通道作为大家都非常喜欢的概念，尤其是使用quic流的数据通道，在Java的语言下比较简单。

如果具体说说QUIC这条“捷径”，腾讯TEG基础架构部高级架构师罗成，曾在公开场合表示，其实QUIC的设计目的是为了减少传输延时。

为何TA能够有效减少传输延迟呢？主要还是由于几方面特性。

罗成认为，首先能够帮助0RTT建立连接，其次可以做到全用户态传输控制。

一般来说，TCP的运算控制都是基于内核操作系统协议站实现的，如果要在其中完成一些优化改进甚至监控部署都需要涉及到服务器操作系统的修改甚至客户端操作系统的修改，通常是不可能的，这个特性的部署升级压力非常大，但是QUIC不一样，是全用户态实现，可以非常精准地实现特性。

此外，QUIC可以避免队头阻塞的多路复用。由于QUIC请求和请求之间都是完全独立的，一个请求丢包只会影响“眼下”关联的一个请求，不会影响别的。

相比之下，TCP不知道对应了多少个请求，如果产生丢包现象，也就不知道剩下等待请求的数量，自然就会产生队头阻塞。

这么看，QUIC被高效利用“有情可原”，同样对其深入研究的新浪微博技术专家聂永则表示，其实QUIC还涉及到一个前期筛选的过程。

他介绍说，选用QUIC还需要从自身出发，注意很多实验机制、方案以及框架。“当时我们都在选择的过程中，出现了go-quic，由于用户不活跃就被排除了；另外一个就是谷歌的QUIC，想把它转换成生产级的发现则需要很大的努力，更重要的一点它是使用C++语言写的，因为我本身不会C++，所以就没选择它；一轮选择之后，我们发现Caddy+QUIC可以提供一站式网络堆栈服务，方便成熟且使用者众多，更新机制频繁。”聂永补充道。

尽管QUIC有这样那样的优势，但长期实践表明，对于企业来说采用之后还是存在一定的困难，例如首当其冲的表现就是协议复杂性。

由于未来需要实现TCP的可靠性、拥塞控制、流量控制以及安全的指标，所以必然会出现QUIC协议被陆续替换并趋于标准化的情况。

最重要的一点，技术的快速变化以及协议的快速迭代，差不多一个半月就有一个新的QUIC版本出现。QUIC现默认使用自己实现的握手协议，但后续计划使用TLS1.3替代，这就增加了自己架构的难度，关于这个问题，聂永提出借助开源的想法，如果在工具层面可以实现就减轻了“重复造轮子”的负担。

至此，我们不得不正视一个问题，如今整个社会还没有为QUIC的到来做好准备，运营商针对UDP的支持也是不足的，表现不稳定。

例如，有些ISP会直接屏蔽UDP，UDP有时需要被伪装成TCP才能正常传输，UDP带宽有时相比TCP狭窄，UDP流量可能会因QOS线速判定为丢包……

此外，QUIC穿透性差，NAT局域网路、交换机、防火墙等会禁止UDP 443同行，防火墙有时只“认可”TCP……相对来说，实验室数据还是比真实环境测评出来的数据漂亮很多，这一点需要企业在使用QUIC时多加注意。

会上，Dan Burnett还提到了解决NAT的问题的ICE。

通常，如果想从一个网络转换到另一个网络，就算使用的是移动终端，无线转换也非常耗费时间的，过程需要重新打包甚至还会出现丢包现象，所以ICE的使用过程中充满挑战。

此外还有一点，对于很多开发商来说不希望使用SDP是共同的“夙愿”。

如何在使用ICE的同时不用SDP，其实还存在其他的运输途径，例如quic。由于ICE想控制的是用户能够使用哪个地址的问题，包括APP地址以及其他，完成这些最重要的依旧是对速度的极致要求。

“WebRTC1.0版本现在运转得非常好，相信未来会越来越好，据了解已经有APP在使用WebRTC1.0版本。但值得注意的一点，如今WebRTC是一个平台，而且会不断延伸，衍生平台或产品未来会更加亮眼，越发被注意。”

你理解最新的标准测试“那些事儿”吗？

标准呼出之后自然要观察适用效果，GoogleWebRTC产品经理HuibKleinhout对此深受感触。

他表示，关于WebRTC的1.0版本，标准在实践中加以测试很重要，可以借此判断任何时间条件下标准是否适用。

说到WebRTC的测试，据悉这与其他的网络标准并不相同。

例如，Google之间有一个kite，可以将两个浏览器进行连接，浏览器可以进入机器，也可以在原端，还可以是物理的硬件，而且能够把测试结果报告给安卓等，这样两个服务器就做到直接对话了。

更重要的一点，这种测试不单单针对标准的适用性，还能够测试基于WebRTC的应用。

Google WebRTC产品经理  Huib Kleinhou

Huib Kleinhou认为，WebRTC在开始阶段与现在的1.0版本有非常大区别，包括Google、chrome等都做了大量的工作。例如，关于chrome，加入一些API，避免直接使用SDP；调整到另外一个SDP，让浏览器会更加具有一致性。

反观浏览器的性能提升，例如chrome和safari，要保障它们更好的符合标准要求，同时又有一定的灵活性。未来对于Edge有需要进行更多提升，因为基于WebRTC以及API需要开展越来越多的工作。“我们的方向非常好，希望在未来将这个应用进一步改善和提升。”Huib Kleinhou说。

此外，关于WebRTC的1.0版本，还需要考虑其稳定性以及可靠性。

其中一个非常重要的修订是MacAudio，主要针对解决MacOS之前出现的相关问题；另外就是关于chrome的屏幕共享。

通常，我们与其他人进行平台共享时，不是带宽不够就是干脆没有网络，屏幕延迟以及死机都是常有的事儿。关于这方面，Google团队做了一定改进并保证更好的自动化，尽管效果不够完美，但针对相关问题总结后会有进一步提升。

“坑坑洼洼”的规模商用尚待成熟

话说，标准有了，测试做了，似乎说着说着还要落地到应用实践的层面。

聊到这里，可能不少开发者有这样的想法。

WebRTC并不算一个特别新的概念，就连1.0说话也就落地了，如今构建很多不同领域的应用，例如视频通话、远程医疗等，开发者们第一时间也可以想到WebRTC，证明这个普及程度还是十分令人欣喜额，此外关于一些to C产品的应用，例如Facebook message等，如此推测大规模商用的门槛高不高呢？

对此，声网Agora首席WebRTC架构师陈功在演讲“WebRTC在大规模的商业应用中的实践”中提出，其实从WebRTC到大规模的商用，还是会遇到非常棘手的问题。

首先可能就是通信质量的“那些事儿”。陈功表示，真正商用的场景中不可避免会有多人的场景，这就需要有一个KOS的优化策略。如果过程中所面向的用户客户是全球分布的，更需要智能路由以及全球化的部署服务节点的能力。

除了质量之外，在可用性方面，全球化部署的服务节点必然需要高可用的运维，同时服务的终端不会是单纯的PC端浏览器， 这么看还要有跨平台互通的，包括与移动端、其他第三方接入的互通能力。

关于以上这些问题的解决，从服务架构出发，陈功介绍，WebRTC协议站开发了WebRTC的Gateway网关，这个网关会负责浏览器端的Web用户和Agora大网进行接入，同时还负责一些频道的创建、媒体流的发布、媒体流的订阅、消息的传递和状态反馈，整个网关是一个就近接入的分布式部署，充分利用了Agora传输网络的优势，因为WebRTC本身是点对点的。

“另外，由于整个服务体系中非常重要的就是数据驱动，从数据方面可以看到大体可以分成三部分。”他总结道。

第一部分是在媒体服务器上或WebRTC网关上能看到的采集到的数据，包括延时、抖动、丢包，还包括网关和SD-RTN TM之间的传输状态。

端上最重要的就是pc.getStats，会挑选其中大多数比较有意义的进行采集，包括非常重要的带宽估计、关键帧请求等信息。最后的数据是SDK的logger，对分析的用户真正真实场景遇到的问题非常重要。

应用落地始终是打开大规模商用的第一步，所以针对不同场景的优化体验，声网把WebRTC用到大规模的商用要服务于不同垂直领域的客户，区分一些场景。

例如，直播场景就比较要求高清的画质，通信场景的重要指标就是流畅性，所以针对这些不同的场景像采用编码选择参数的设置、传输策略上进行根据场景的定制等。

此外，关于WebRTC前端应用中的经验和教训，TutorABC的资深架构师孙高朝列举了在线课堂系统中经常出现的问题，例如学生反映怎么看不到顾问，也听不到声音；顾问也反映听不到学生声音，看不到自己的影像。

孙高朝对与会开发者们表示，总结之后发现上述这几类问题，基本上归功于设备问题和网络问题，其中设备问题占了绝大部分。

通常提及的GetUserMedia并不能算真正的设备问题，只是调用这个函数会出现报错，这可能与设备相关；另外的设备异常就属于物理硬件上的异常。

“关于WebRTC文档上的关键事件，我们都会给予一定容错，甚至有时候要多个接口一起协同使用，而不是对单一的接口做一些判断，往往会存在不精准的现象。WebRTC的信令协商非常重要，取决于WebRTC网络连接或其他东西能不能正常使用，所以网络层的处理要格外精细，要考虑到丢包以及重连。”他说。

总体来说WebRTC文档可以参考，应用过程中需要因地制宜，还是需要根据自己的业务需求发现其中的问题做一些解决。

那些典型的实时场景与后端架构，TA们都是咋做的？

概括了应用层面的弯与坑之后，大家都知道，HQ Trivia直播答题掀起了今年一波实时热潮，但瞬间高并发的特点给系统架构提出了“新难题”。

具体来说，在高并发场景下的实时状态同步，包括PK、答题、或者大型直播间等，在消息丢失、消息延迟情况下如何做到消息实时状态的同步呢？

关于这个问题，李庆寿似乎最有发言权，花椒直播在产品中的技术实践更是值得探讨。

通常来说，答题、连麦以及直播间的PK 活动都有可能带来长连接的不稳定性。

试想瞬间增加服务器压力，处理能力有限导致数据丢失延迟等情况出现，由此出现长连接异常，用户体验自然不高。

此外据了解，长连接的固有性质导致丢失或者乱序，开启实时消息控制会导致它更加严重。此外，长连接超时状态的判别延迟，其中超时比http这种接口请求的超时长得多，出现网络问题时不可能立马断线连接、重新建连，所以就出现了消息丢失和延迟问题。

“我们当时考虑两个方案，首先转成IM消息，写扩散，进行消息编号等功能。但这个功能评估下来对系统的改造非常大；另外就是定时拉取接口做实时状态的同步，这个方案导致状态接口的请求量非常大。所以最后根据这个思路设计了Sync服务。”李庆寿说。

具体操作第一步就是要增加ID的版本号，将Sync消息写入现成连系统中，由长连系统推送到APP端，与此同时将带有版本号的信息同步写入到Sync中去。

作为APP端，要不就是网络特别好而且消息不是很多的情况下，正常接受消息可以展示出来；如果此时APP处于网络不稳定或者直播间消息众多，那就轮到Sync服务发挥作用了。具体来说，APP会寻找Sync服务的相关接口，如果版本号大于本地的最大版本号，就会用这个版本信息做业务处理。

直播环节看似没有坑了，那点播如何才能做的顺当？

沪江CCtalk CTO 杨继珩为现场开发者建议的解决方案是OCS。

这套系统是一套播放系统，可以理解为一个播放器，但它播的内容不像其他机构播一个视频那么简单。

作为一个富媒体播放器，就是把上课所有元素按直播时一个个放完，机制很复杂，但可以让录播用户得到更好的体验和学习效果更好。OCS的结构也很复杂，包括OCS的后台生成器、平台服务层的转码、打包、数据切片、富媒体包装等。

未来关于在线视频教育的挑战，杨继珩认为这几点比较关键，给同行人带来些许建议。卡顿、低延迟优化的老生常谈的话题之一；此外，一些大型课程学生在场率超过50%的并没有很多，很多用户都是看录播，所以要保证MCU录制质量一定要高，这方面能力的建设以及稳定性比较重要。

如今，8亿-9亿网民中有超过六成的使用者或多或少玩过游戏，尽管从国家层面对其进行了相对严格的管控，但体量巨大带来的影响仍然是不容小觑。

更重要的一点，游戏对网络要求非常高。不像视频或其他电商类业务对网络的带宽、时延、抖动、丢包要求极致；常常玩FPS游戏的人们了解，如果网络不好的话基本没办法进行下去，客户体验会非常差，再加上如今公有云的网络基础设施还相对薄弱，这也是华为云游戏解决方案架构师王冰关注游戏网络质量优化的立足点。

王冰表示，将数据采集完成进行分析、网络预测，去动态调整网络流量流向等环节确实很关键，但更重要的一点，还是要对网络质量整体提升。

“网络出问题后，最终要改善网络，而不是总去预防，要总结、分析后对网络能力进行提升。例如可以从数据中心建设、骨干网的带宽和ISP带宽、POP点广泛覆盖、线路质量的提升、跨地域线路容灾能力以及IPV6的快速推广等方面着手。”他说。

从技术层面出发，随着RTC技术在更多行业的应用落地，不断迸发出更多创新业务场景，后端架构设计与传输也将时刻面临新的挑战。

小到教育画面的卡顿，大到工单以及客户系统的诸多问题， 声网Agora 首席数据架构师何丰作为RTC 大会的老朋友，这次带来了针对“质量透明” 的主题分享。

在分享中，何丰强调，需要把服务质量透明给用户，质量透明以后用户可以了解事态；此外可以有效帮助定性是网络问题还是设备陈旧问题，对质量改进形成非常快速的迭代。

具体来说，声网关于这方面的实践，主要是通过内部的工具和系统把这些问题定位诊断出来，因为有一套非常完善的质量数据体系。

这个数据的体系会从用户通话的每一个环节针对质量收集， 例如用户行为、网络切换、音视频采集、上行网络丢包、抖动、延迟等质量数据。

话说，中间的云作为传输大网，能够保障跨州、跨国传输的质量。大网中传输的质量指标、对方用户下行网络、对方接收解码播放渲染的运行状态……这些用户行为都会被全链路收集起来。

何丰进一步补充道，这些收集到的数据还可以做些分类，例如用户行为一类，运行时状态为一类，以及QoE和QoS两方面的质量数据等。这代表可以通过全方面数据去判断通话的相关情况，脱离用户访谈就可以对通话质量进行全方位把控。此外，会上Callstack.ioCEO VarunSigh还带来了有关WebRTC领域质量监控和优化的经验分享。

如今，实时互联网行业迎来爆发之年，很多创新的实时互动场景在RTC技术的激发下踏上风口，关于RTC 2018大会的相关报道后续会接踵而至，敬请期待。

_“征稿啦_”

CSDN 公众号秉持着「与千万技术人共成长」理念，不仅以「极客头条」、「畅言」栏目在第一时间以技术人的独特视角描述技术人关心的行业焦点事件，更有「技术头条」专栏，深度解读行业内的热门技术与场景应用，让所有的开发者紧跟技术潮流，保持警醒的技术嗅觉，对行业趋势、技术有更为全面的认知。

如果你有优质的文章，或是行业热点事件、技术趋势的真知灼见，或是深度的应用实践、场景方案等的新见解，欢迎联系 CSDN 投稿，联系方式：微信（guorui_1118，请备注投稿+姓名+公司职位），邮箱（[e-mail]）。

————— 推荐阅读 —————