2011年Google将WebRTC项目开源,据即时通讯云服务商融云8月29日消息

摘要作为Google开源的技术,WebRTC实时音视频技术并不是一个可以拿来就用、并且性能很好的产品。本文主要来谈一谈WebRTC的优缺点。  2011年Google将WebRTC项目开源,让许多开发者眼前一亮,忍不住的加入了研究WebRTC的队伍中。作为Google开源的技术,WebRTC并不是一个可以拿来就用,并且性能很好的产品。本文主要来谈一谈WebRTC的优缺点。  一、发展及现状  WebRTC在被Google开源之前,其价值就已经得到了充分的认可。比如QQ就使用了WebRTC的部分技术。WebRTC的发展情况可以从标准规范和浏览器支持这两个方面看。WebRTC标准是由W3C和IETF所联合制定的,在2016年1月28日,W3C公布了最新的WebRTC标准,标准中定义了WebIDL中一系列的ECMA
Script
API来允许使用合适的RTP的浏览器或设备来接收/发送媒体,详细内容可以访问  二、优点  1.方便。对于用户来说,在WebRTC出现之前想要进行实时通信就需要安装插件和客户端,这是一个复杂的过程。现在,WebRTC技术内置于浏览器中,用户不需要使用任何插件或者软件就能通过浏览器来实现实时通信。对于开发者来说,在Google将WebRTC开源之前,浏览器之间实现通信的技术是掌握在大企业手中,这项技术的开发是一个很困难的任务,现在开发者使用简单的HTML标签和JavaScriptAPI就能够实现Web音/视频通信的功能。  2.免费。虽然WebRTC技术已经较为成熟,其集成了最佳的音/视频引擎,十分先进的codec,但是Google对于这些技术不收取任何费用。  3.强大的打洞能力。WebRTC技术包含了使用STUN、ICE、TURN、RTP-over-TCP的关键NAT和防火墙穿透技术,并支持代理。  三、缺点  1.编译WebRTC的源码就是一个比较大的挑战,搭建其复杂的编译环境往往会遇到很多意想不到的问题,导致当初计划用几个星期的时间来搞定项目,却发现这几个星期连编译都没搞定。  2.WebRTC中很多的参数都是由GIPS公司的工程师们依靠经验所设定的值,这就会出现卡顿、延时、回声、丢包、多人视频不稳定等问题。  3.WebRTC缺乏服务器方案的设计和部署。  4.传输质量难以保证。WebRTC的传输设计基于P2P,难以保障传输质量,优化手段也有限,只能做一些端到端的优化,难以应对复杂的互联网环境。比如对跨地区、跨运营商、低带宽、高丢包等场景下的传输质量基本是靠天吃饭,而这恰恰是国内互联网应用的典型场景。  5.WebRTC比较适合一对一的单聊,虽然功能上可以扩展实现群聊,但是没有针对群聊,特别是超大群聊进行任何优化。  6.设备端适配,如回声、录音失败等问题层出不穷。这一点在安卓设备上尤为突出。由于安卓设备厂商众多,每个厂商都会在标准的安卓框架上进行定制化,导致很多可用性问题(访问麦克风失败)和质量问题(如回声、啸叫)。  7.对Native开发支持不够。WebRTC顾名思义,主要面向Web应用,虽然也可以用于Native开发,但是由于涉及到的领域知识(音视频采集、处理、编解码、实时传输等)较多,整个框架设计比较复杂,API粒度也比较细,导致连工程项目的编译都不是一件容易的事。  总而言之,WebRTC虽然提供了一套音视频实时通讯的解决方案,但是在实际应用中,由于网络传输、设备适配以及多方通话上都存在很多问题,效果并不理想。(WebRTC开源工程官方网站:

摘要即时通讯云服务商LeanCloud
2016年8月5日因由于缓存集群超负载崩溃,导致即时通讯服务瘫痪30分钟之久!以下消息来自LeanCloud官方:8
月 5 日晚上 7 点 10 分开始,LeanCloud
中国节点上的某一缓存集群因为流量过大,CPU
资源被占满而停止了服务,从而导致数据存储及依赖它的服务(云引擎、推送、实时聊天)出现约半小时的中断,在此期间有部分应用可能会遇到请求无法完成的情况。详细报告如下。故障节点和影响范围只有中国节点出现了问题,受影响的服务与时间段列举如下,其他服务未受到影响。服务名区域受影响时段范围数据存储中国19:10
– 19:41全部不可用云引擎中国19:10 – 19:41全部不可用实时通信中国19:10 –
19:41部分不可用(消息 hook 功能不可用、离线推送延迟)消息推送中国19:10 –
20:02推送大面积延迟统计服务中国19:10 –
20:23全部不可用(数据收集接口关闭)故障时间线19:10:内部监控报警,确认
redis 异常(CPU 资源占满,失去响应)。19:13:redis
机器无法直接重启,开始尝试逐步关停其他服务(依次是推送、聊天推送、云引擎、统计),以降低请求压力。19:41:redis
集群恢复可用,同时数据存储、云引擎和实时通信三个服务开始恢复。20:02:消息推送服务开始恢复,redis
集群运行正常。20:23:成功为统计服务单独搭建 redis
集群,统计服务的数据收集接口开放,新老 redis
集群运行正常。至此所有服务全部恢复。后续措施将该 redis
集群从业务层面进行拆分,小集群化。将 redis
集群进行高可用架构升级,避免单点故障。对集群加强容灾演练,确保异常条件下服务稳定。对于本次故障,我们诚恳地向您道歉。我们将免掉您账户中全部应用在
8 月 5 日当天的所有费用,以表诚意。

摘要2016年8月29日,即时通讯去服务商融云的日消息量突破1000亿条,刷新 IM
云海量消息处理纪录。融云官方消息正文:据即时通讯云服务商融云8月29日消息:全球最大的即时通讯云服务商融云宣布其日消息量峰值突破1000亿条,平均每分钟处理7000万条消息,这是国内即时通讯云服务平台日消息量首次达到1000亿条规模,突破千亿也意味着融云在海量消息处理能力上又有突破。资料显示,融云客户覆盖社交、生活服务、娱乐游戏、电商、视频、教育、医疗健康、金融理财和协同办公等9大领域。原文链接:

相关文章