为什么大家都在使用 WebRTC?
WebRTC代表网络实时通信。它是一种非常令人兴奋,强大且具有高度破坏性的尖端技术和标准。自从WebRTC诞生以来,80%的浏览器都开始支持它。有数据显示,2017年~2021年期间,WebRTC市场将以34.37%的年均复合增长率增长。
什么是WebRTC
众所周知,浏览器本身不支持相互之间直接建立信道进行通信,都是通过服务器进行中转。比如现在有两个客户端,甲和乙,他们俩想要通信,首先需要甲和服务器、乙和服务器之间建立信道。甲给乙发送消息时,甲先将消息发送到服务器上,服务器对甲的消息进行中转,发送到乙处,反过来也是一样。这样甲与乙之间的一次消息要通过两段信道,通信的效率同时受制于这两段信道的带宽。同时这样的信道并不适合数据流的传输,如何建立浏览器之间的点对点传输,一直困扰着开发者。WebRTC应运而生。
WebRTC是一个由Google发起的实时通讯解决方案,其中包含视频音频采集,编解码,数据传输,音视频展示等功能,我们可以通过技术快速地构建出一个音视频通讯应用。 虽然其名为WebRTC,但是实际上它不光支持Web之间的音视频通讯,还支持Android以及IOS端,此外由于该项目是开源的,我们也可以通过编译C++代码,从而达到全平台的互通。
WebRTC 解决了什么问题?
在没有 WebRTC 前,对于开发者而言 RTC 通信的难点主要来自于互联网网络复杂、延时敏感、实时音视频流畅度及清晰度较低以及运营成本较高等。但这些问题在 WebRTC 出现后都得到了较好的解决:
1、互联网网络复杂 不同的 NAT、防火墙对媒体 P2P 的建立带来了很大的挑战。而 WebRTC 的出现为浏览器提供了端到端的直接通信,使开发者可以轻松地实现这种连接。同时,WebRTC 里面有 P2P 打洞的开源项目 libjingle ,支持 STUN,TURN 等协议。
2、延时敏感 在早期的 RTC 技术中,TCP(Transmission Control Protocol-传输控制协议)由于自身机制的缺陷,只能使用 UDP 传输,但这需要开发人员解决重传、乱序等问题。而 WebRTC 则提供了 NACK,FEC 技术,不再需要通过服务器进行路由,减少了延迟和带宽消耗。直接通信可提高数据传输和文件共享的速度。
3、流畅性 互联网网络不稳定,特别一些小运营商,在流量使用高峰期往往无法保证足够的带宽。需要一套自适应的算法来应对网络拥塞、平滑发送等问题。WebRTC 中提供了 TCC + SVC + PACER + JitterBuffer 技术支持。
4、语音清晰 由于终端设备和环境复杂,会有噪声、回声的干扰,这时候 WebRTC 提供了 3A 算法 + NetEQ,让实时环境中的声音处理及互动体验得到了大幅的提升。
对于开发人员或企业而言,使用 WebRTC 的过程中只需要下载兼容 WebRTC 的浏览器并使用,不需要额外的软件、插件或持续的服务器的参与就可以将音视频应用轻松嵌入到任何网站中,并通过 Internet 进行连接,大大节省了开发时间和成本。
目前主流的浏览器如 Microsoft Edge、Google Chrome、Mozilla Firefox、Safari、Safari、Opera、Vivaldi 等都已支持 WebRTC。
WebRTC 的现状与未来
自2020年浏览器的发展和兼容性发生了变化,WebRTC的延时性、安全性得到了提升和保护,尤其是疫情爆发后,实时视频的需求比之前增长了30倍,这更刺激了WebRTC产品的持续快速发展。
而且基于WebRTC的研发产品不受限于传统的互联网应用或浏览器的终端运行环境。实际上WebRTC无论终端运行环境是PC、Android、iOS还是设备,只要达到WebRTC的规范都可以互通。所以基于WebRTC研发的产品在延展性、应用场景和使用终端上,基本都能兼容,这就使得在线教育、视频会议、远程医疗、在线直播等应用场景得到了极大发展。
现在基于WebRTC研发的产品最大优势是标准化,它提供了所有需要进行实时通信的终端统一的、开放的实时通信能力描述和连接建立标准。不足的地方则是由于各厂家浏览器兼容性不一,需要集成的APP中的SDK不同,这就致使目前的音视频产品的互通性会存在一些问题。
所以在未来,作为终端技术规范,虽然WebRTC只是实时通信解决方案中的一部分,但却是最贴近用户的一部分,也许是最重要的一部分。终端技术规范的标准化,是一个很好的开始。就连一向以封闭的技术生态而闻名的Apple都开始拥抱WebRTC了,这也将促进WebRTC技术的发展和普及,会有越来越多的互联网应用基于WebRTC构建实时通信服务。
像类似VR、AR、自动驾驶等新应用场景的出现,也会给WebRTC技术带来新的需求和动力,应用场景的商业化成功也将为技术发展持续注入活力和物质资源。近年来基于互联网的视频应用的猛烈发展和火热,一次次催动着基于互联网的实时音视频通信技术的发展,呼唤着WebRTC这样的统一、开放、透明的标准规范成熟和落地。
在将来,我们可以想象一下。在基于webRTC构建的世界中,所有终端建立连接的过程是统一的,只要终端之间开放了通道,就可以建立实时通信。
比如,微信与WhatsApp能建立视频通话,就像你在中国用手机,给美国朋友家里的座机打电话。甚至你还可以用微信连接到汽车的屏幕,提前放音乐、开空调。
在实时音视频通信的场景中,anyRTC能够根据不同需求,提供一站式音视频解决方案,帮助企业降本增效,让视频创造价值。
anyRTC将继续在音视频领域不断钻研,为不同领域的客户提供创新、优质的解决方案,为行业的发展贡献自己的一份力量。
上一篇: 利用链表数据结构优化页面渲染
推荐阅读
-
为什么大家都在使用 WebRTC?
-
纯干货分享 | 研发效能提升——敏捷需求篇-而敏捷需求是提升效能的方式中不可或缺的模块之一。 云智慧的敏捷教练——Iris Xu近期在公司做了一场分享,主题为「敏捷需求挖掘和组织方法,交付更高业务价值的产品」。Iris具有丰富的团队敏捷转型实施经验,完成了企业多个团队从传统模式到敏捷转型的落地和实施,积淀了很多的经验。 这次分享主要包含以下2个部分: 第一部分是用户影响地图 第二部分是事件驱动的业务分析Event driven business analysis(以下简称EDBA) 用户影响地图,是一种从业务目标到产品需求映射的需求挖掘和组织的方法。 在软件开发过程中可能会遇到一些问题,比如大家使用不同的业务语言、技术语言,造成角色间的沟通阻碍,还会导致一些问题,比如需求误解、需求传递错误等;这会直接导致产品的功能需求和要实现的业务目标不是映射关系。 但在交付期间,研发人员必须要将这些需求实现交付,他们实则并不清楚这些功能需求产生的原因是什么、要解决客户的哪些痛点。研发人员往往只是拿到了解决方案,需要把它实现,但没有和业务侧一起去思考解决方案是否正确,能否真正的帮助客户解决问题。而用户影响地图通常是能够连接业务目标和产品功能的一种手段。 我们在每次迭代里加入的假设,也就是功能需求。首先把它先实现,再逐步去验证我们每一个小目标是否已经实现,再看下一个目标要是什么。那影响地图就是在这个过程中帮我们不断地去梳理目标和功能之间的关系。 我们在软件开发中可能存在的一些问题 针对这些问题,我们如何避免?先简单介绍做敏捷转型的常规思路: 先做团队级的敏捷,首先把产品、开发、测试人员,还有一些更后端的人员比如交互运维的同学放在一起,组成一个特训团队做交付。这个团队要包含交付过程中所涉及的所有角色。 接着业务敏捷要打通整个业务环节和研发侧的一个交付。上图中可以看到在敏捷中需求是分层管理的,第一层是业务需求,在这个层级是以用户目标和业务目标作为输入进行规划,同时需要去考虑客户的诉求。业务人员通过获取到的业务需求,进一步的和团队一起将其分解为产品需求。所以业务需求其实是我们真正去发布和运营的单元,它可以被独立发布到我们的生产环境上。我们的产品需求其实就是产品的具体功能,它是我们集成和测试的对象,也就是我们最终去部署到系统上的一个基本单元。产品需求再到了我们的开发团队,映射到迭代计划会上要把它分解为相应的技术任务,包括我们平时所说的比如一些前端的开发、后端的开发、测试都是相应的技术任务。所以业务敏捷要达到的目标是需要去持续顺畅高质量的交付业务价值。 将这几个点串起来,形成金字塔结构。最上层我们会把业务目标放在整个金字塔的塔尖。这个业务目标是通过用户的目标以及北极星指标确立的。确认业务目标后再去梳理相应的业务流程,最后生产。另外产品需求包含了操作流程和业务规则,具需求交付时间、工程时间以及我们的一些质量标准的要求。 谈到用户影响的地图,在敏捷江湖上其实有一个传说,大家都有一个说法叫做敏捷需求的“任督二脉”。用户影响地图其实就是任脉,在黑客马拉松上用过的用户故事地图其实叫督脉。所以说用户影响地图是在用户故事地图之前,先帮我们去梳理出我们要做哪些东西。当我们真正识别出我们要实现的业务活动之后,用户故事地图才去梳理我们整个的业务工作流,以及每个工作流节点下所要包含的具体功能和用户故事。所以说用户影响地图需要解决的问题,我们包括以下这些: 首先是范围蔓延,我们在整张地图上,功能和对应的业务目标是要去有一个映射的。这就避免了一些在我们比如有很多干系人参与的会议上,那大家都有不同想法些立场,会提出很多需求(正确以及错误的需求)。这个时候我们会依据目标去看这些需求是否真的是会影响我们的目标。 这里提到的错误需求,比如是利益相关的人提出的、客户认为产品应该有的、某个产品经理需求分析师认为可以有的....但是这些功能在用户影响地图中匹配不到对应目标的话,就需要降低优先级或弃掉。另外,通常我们去制定解决方案的时候,会考虑较完美的实现,导致解决方案括很多的功能。这个时候关键目标至关重要,会帮助我们梳理筛选、确定优先级。 看一下用户影响到地图概貌 总共分为一个三层的结构: 第一层why,你的业务目标哪个是最重要的,为什么?涉及到的角色有哪些? 第二层how ,怎样产生影响?影响用户角色什么样的行为? (不需要去列出所有的影响,基于业务目标) 第三层what,最关键的是在梳理需求时不需一次把所有细节想全,这通常团队中经常遇到的问题。 我们用这个例子来看一下 这是一个客服中心的影响地图,业务目标是 3个月内不增加客服人数的前提下能支持1.5倍的用户数。此业务目标设定是符合 smart 原则的,specific非常的具体,miserable 是可以衡量的,action reoriented是面向活动的, real list 也是很实际的。 量化的目标会指引我们接下来的行动,梳理一个业务目标,尽量去量化,比如 :我们通过打造一条什么样的流水线,能够提高整个部署的效率,时间是原来的 1/2 。这样才是一个能量化的有意义的目标。 回到这幅图, how 层级识别出来的内容,客服角色:想要对它施加的影响,把客户引导到论坛上,帮助客户更容易的跟踪问题,更快速的去定位问题。初级用户:方论坛上找到问题。高级用户:在论坛上回答问题。通过我们这些用户角色,进行活动,完成在不增加客户客服人数的前提下支持更多的用户数量。 最后一个层级,才是我们日常接触比较多的真正的功能的特性和需求,比如引导到客户到论坛上,其实这个产品就需要有一个常见问题的论坛的链接。这个层次需要我们团队进一步地在交付,在每个迭代之前做进一步的梳理,细化成相应的用户故事。 这个是云智慧团队中,自己做的影响地图的范例,可以看下整个的层级结构。序号表示优先级。 那我们用户影响地图可以总结为:
-
趣谈留言队列,搞清楚留言队列到底是什么!-说到消息队列,洪觉大概能猜到人们听到消息队列的反应,大致可以分为以下几类人。 第一类人,懵懵懂懂,刚上大学接触编程,还没用过消息队列,甚至还以为消息队列就是代码里面要新建一个List之类的;第二类人,听过消息队列,了解消息队列,但具体是什么还不是太明白,只知道一说到消息队列,脑海里马上出现了三组词,削峰、异步、解耦;第三类人,用过消息队列,对它有一定了解,但不知道为什么要这样设计,消息队列有什么样的前世今生,是如何演化到现在的模式的?**第四类人,已经对消息队列有了足够的了解,可以阅读本帖作为复习和温习。**你属于哪一类?无论你对消息队列了解多少,读完这篇文章后,我相信你都会有所收获。 什么是消息队列?我们为什么要使用消息队列?真的只是因为它看起来很勉强、很常用吗?当然不是,一项技术的出现往往是为了解决某种痛点,我们就从这个痛点出发,看看消息队列到底是为了解决什么问题而诞生的。 相信大家在工作之前,或者工作中接触单片机的次数会多一点,不管什么业务都一股脑塞进一个系统里,这种情况下接触消息队列的场景会比较少。但随着业务的增长,量上去了,单机系统就很难维护了,也扛不住并发量的增长,就需要把原来的单体应用拆分成多个服务。例如,牛奇网采用分布式架构,将原来的单体系统拆分成用户服务、题库服务、求职服务、论坛服务等,每个分布式节点都有一个集群,保证高可用性。 那虽然在这样的微服务架构下,如果某个核心业务并发量过大,系统就扛不住了。比如淘宝、淘票票、拼多多、京东等电商场景中的支付场景,你在某宝下单并支付后,调用支付服务,完成支付后,还需要更新订单的状态,这个时候就需要调用订单服务,那我们平时也下单,除了简单完成这些操作外,还会给你相应的积分;商家也会收到订单消息,并给您发送旺旺消息,确认订单无误;同时,也会给您发送消息,确认订单无误。确认订单无误;同时您还可以查看您的物流状态;还有系统为了给您推荐更适合您的商品,会根据您的订单做类似的推荐等等,我说的这些都是当我们下单后,肉眼可以感知到系统所做的动作。 **一个支付动作如果还需要调用那么多服务,等他们响应成功,最后再告诉用户你支付成功了,用户在系统中的整个体验会非常糟糕。**设想一下,假设请求服务+处理请求+响应总共需要 50ms,我们上面列出的场景:支付服务、订单服务、积分服务、商家服务、物流服务、推荐服务,总共需要 300ms。
-
什么是新零售?为什么大家都在做?