WebRTC技艺内置于浏览器中,即时通信实时音讯服务的计费依赖将是当天利用服务的客商数上限

摘要作为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进行相关优化,并在接下来的服务过程中启用改进和即时通讯云计费方式。以下为来自即时通讯云
LeanCloud官方的消息:LeanCloud
近期经历了比以往更频繁的稳定性方面的事故,其中有的是因为容量规划上的不足导致服务收到异常流量影响,有的是对上游服务商的域名攻击,有的是针对
LeanCloud 的 DDoS 攻击。LeanCloud
一直将服务的稳定性视为生命线,每次事故之后,都会严肃地总结并明确改进方案。我们也会把事故报告发布到博客上,确保用户们知晓事故原因和过程,以及后续我们要执行的改进措施。为让用户了解我们为此所做出的努力,我们想向大家通报一下在改进措施方面的进展。已经完成的改进措施有:为应对将来可能出现的上游服务商域名被攻击的情况,实现更灵活的域名动态切换,以便在必要时及时切换至其他域名,保证云服务对外服务的可用。完善应对
DDoS
攻击的策略和措施,把受攻击后恢复服务的时间缩短到分钟级。事故公告流程增加了短信通知渠道,确保开发者及时收到信息。(我们在最近的
DDoS
攻击的几十分钟内一共给所有用户发送了三次短信及时更新进展)。正在进行的措施有:增加新的监控措施,对前端网络入包量进行监控,防止网络转发量超过
VM 能力限制。调整前端 VM
配置,使用高包量机型,增大处理能力。改进前端服务器扩容方式,使用 docker
镜像来加快新节点部署上线的进度。API
服务对外增加多路备选域名,降低针对域名的攻击造成的影响。除了技术上的改进外,我们也对计费方式中的不合理之处进行了重新思考。过去我们的存储和即时通讯实时消息服务都是按照一个月的总使用量来计费的,这样造成了一些问题。比如如果一个应用在一个月里发生了
10 亿次 API
调用,我们并不区分这些调用是平均分布在整个月,还是集中在少数几天。而这两种情况对容量规划的要求是非常不同的,如果不做区分,就容易造成资源上的分配不及时,给运维工作造成风险和压力。另外由于存储和即时通讯实时消息是按月后付费,LeanEngine、LeanCache、短信是实时扣费,不同的计费周期和方式给很多用户造成了财务流程上的困扰。所以我们将把所有服务调整为一致的实时扣费的模式,并且存储和即时通讯实时消息服务将调整为按每天用户设定的容量上限收费,其中数据存储的计费依据将是并发请求数的上限,即时通讯实时消息服务的计费依据将是当日使用服务的用户数上限。这样用户可以自己调整预留的资源,确保满足需求。由于计费周期缩短到天,也能满足只在特定日期有超高流量的应用兼顾较低的预算和充足的资源。具体的方案和数字我们还在制定,会在第一时间与用户沟通。同时我们也会确保老用户有平滑的过渡体验。LeanCloud官方地址:

摘要2016年6月9日是开源实时音视频工程WebRTC开源5周年的日子,Google
WebRTC负责人Harald在社区里面写了一篇文章总结这几年的进展,并附上了自己5年前同样场景下写的一篇文章。前言2016年6月9日是WebRTC开源5周年的日子,Google
WebRTC负责人Harald在社区里面写了一篇文章总结这几年的进展,并附上了自己5年前同样场景下写的一篇文章。为了便于大家更好理解过去5年在WebRTC上都发生了什么,我将这两篇给翻译过来了。友情提醒:整个翻译并不是逐字逐句进行的,而是在理解了作者的意思后用自己的语言表达出来的,因为如果逐字逐句可能很多意思我们都无法正确理解。这就是为什么有些英文资料被翻译成中文后晦涩难懂。当然如果英语够好建议直接看原文。5年前的感慨今天谷歌开源了WebRTC技术,一个用于实时语音和视频通话的软件包,她即将被整合到Chrome。这是我们的第一波贡献,一切都是为了一个伟大的使命——在统一的标准的API下实现所有浏览器间的音视频通话。这个初始版本将提供我们设想的一些功能,具体详见:
Harald)今天的总结今天,回首往事,我们可以很自豪地说:“我们实现了我们所有的目标。”现在音视频交互变得越来越重要,许多产品和服务都支持Web和Native之间的无缝交换,而他们之中绝大部分都是基于我们现在开放出的标准API——这些API的底层实现基本上都是基于WebRTC
。一套通用标准促进了整个行业的发展,Firefox、Opera和微软都已经在支持WebRTC技术了。这已经导致超过20多亿浏览器用户使用了WebRTC技术,仅仅Chrome上每周就有超过10亿分钟的音视频通话,以及超过500T的数据传输(通过WebRTC的数据通道)。WebRTC从一开始就秉持一种很开放的态度,向视频编解码免版税方向迈进。在WebRTC中80%音频通信采用Opus,而最近推出的VP9比VP8节省70%的带宽。由于VP9的努力发展,媒体开放联盟在视频编解码免版税道路上又多了一种选择,以及增加了更多的合作空间。今天,WebRTC技术在音视频领域已经证明了自己的强大,在接下来的几年里,我们期望看到一个更加强大的WebRTC。接下来我们会持续改进音视频质量。我们在WebRTC中愿意采用一些通用的编解码来实现交互通讯,但有一些互操作的问题要去解决。另外作为未来编解码的VP9,他后面在压缩率方面会持续改进,以便更好支持低带宽下的通讯。今天的通信都发生在许多不同网络条件下,从EDGE到LTE。WebRTC面临多样化的网络条件,所以必须能够做出相应的调整。所以我们一直在努力改善拥塞控制算法和优化媒体传输配置来适应各种状况,这里面也有很多机会和方法来改善和简化媒体协议以适应当今网络需求。五年前,大多数通信发生在桌面上。但现在一切都变了,WebRTC技术已经发展到要满足各种移动通信应用的需求。展望未来,还有很多机会,如VR。WebRTC这个平台只会随着时间推移而价值愈加明显,现在仅仅是开始。我们要做的就是:努力做好WebRTC这个平台。(作者:Google
Harald)(原文链接:

发表评论

电子邮件地址不会被公开。 必填项已用*标注

相关文章

CopyRight © 2015-2020 新萄京娱乐3730-娱乐场官网app下载 All Rights Reserved.
网站地图xml地图