http://www.ox-holdings.com

利用它构建的应用可在这三个操作系统上面运行,实时通信的场景包括语音、视频电话会议、网络电话等

摘要2018年度RTC实时互联网大会已于9月7、8两日在北京喜来登长城饭店顺利举行,本次大会精彩纷呈。引言话说,这种变化似乎就发生在一夜之间……从跨国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 KleinhouHuib 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大会的相关报道后续会接踵而至,敬请期待。

即时通信(im)和实时通信(声网Agora.io)都是一套网络通信系统,其本质都是对信息进行转发。其最大的不同点,是对信息传递的时间规定。二者的区别可以从以下几个方面:

作者简介:张乾泽,声网 Agora Web 研发工程师

最近看到腾讯云支持QUIC的文章,突然意识到还没有好好认识HTTP2、QUIC,而要认识HTTP2,就需要从HTTP1.0开始讲起,才能清楚HTTP的发展历程。

摘要2018年11月21日,“声网Agora”正式宣布完成7000万美元C轮融资,由全球科技股对冲基金Coatue Management领投,SIG海纳亚洲、Morningside晨兴资本和顺为资本跟投。从YY到声网声网Agora成立于2014年,由前YY语音CTO赵斌在硅谷创立,定位全球实时通信云服务商,其核心技术为RTC。实时通信(Real-time Communication, 简称RTC),即允许两人或多人使用网络实时的传递文字消息、文件、语音与视频交流,也就是现在很多应用内都会有的聊天、语音、视频功能。通过调用声网的API,开发者可以快速创建这些功能,实现例如视频社交、互动直播、游戏开黑、AR远程协作、视频报警、视频客服、机器人视频陪伴等场景。自研算法优化底层技术音视频传输,通常需要经过“采集—预处理—编码—传输—端处理—解码”等一系列流程,不同服务商会在每一个环节进行优化,从而提高传输速率、质量。例如,声网的预处理已经不仅包括美颜、瘦脸等基础功能,还加入了“人机交互”——在直播中,用户用手势比一个心型,那么系统就会自动识别出来,发几个颗心给对方。再比如,对音视频传输质量影响很大的编、解码环节。编、解码可以理解为压缩、解压缩,原则上,在网络传输出现问题时压缩包会丢失,丢的越多,出现的卡顿就越多。在这方面,声网首席科学家、国际编解码专家钟声曾表示:“视频编码,声网的新算法在高丢包率、低延迟情况下,能体现更多优势。相同质量下只需要一半的码率,比如延迟只有4帧情况下,丢包率是60%,基本上码率只有原来的一半,同时编码的质量和复杂性没有本质变化。如果拿到很模糊的图像,需要在低码率、低分辨率情况下还原,基于传统多像位滤波、三次发差值等方法还原出来的图像,总体上比较模糊。用了深度学习算法之后,细节明显提升,即使在较差网络条件、带宽受限的情况下,依旧可以还原清晰画质。但深度学习有一个大问题,就是需要在大模型、大数据、大平台上实现,可用户基本都在使用移动端,对于算法的实现是一个挑战。声网在这方面也做了很多优化,比如在iPhone6上把一个放大9倍算力支持到每秒200帧,已经达到实时。在音频方面,声网自研的抗丢包音频编码 Agora Solo™ 已发布进化版Solo X™,具有抗丢包特性,即使是在 50% 的丢包下,用户都可以听清对方所讲的内容。同时,自研的分组信号互补技术,兼容Opus和WebRTC。”音视频普及带动场景延伸据悉,除了硅谷,声网已于上海、北京、广州、伦敦、班加罗尔、东京等地有分布式协作团队。目前已在全球自建200多个数据节点的SD-RTN™ 软件定义实时网,服务了全球超20万开发者,覆盖全球超过20亿终端用户,每日支持通话分钟数超过3亿,客户包括社交、直播、游戏、教育等、民生、政务、医疗、金融、物联网等行业,同时与小米、陌陌、中国移动在线、The Meet Group、Hike Messenger、Badoo、Musical.ly、V-cube、好未来、招商银行等建立了战略合作关系。列举一个应用场景,目前重庆市已推出急救视频 120 自救互救服务,在拨打 120 或下载相关App后,医生可通过视频对话,指导现场人员进行自救或互救,若用户此前并未下载 App,拨打120后,手机会收到一条包含 URL 的短信,用户可通过 Web 端与急救医生视频对话。该场景的实时视频通话就是通过声网SDK实现的。再比如,郑州铁路警方用AI警务眼镜筛查网上在逃人员的新闻中,采用的是亮亮视野推出的搭载VPU的AR眼镜,其中内嵌了声网的语音通话技术。谈及未来,声网CEO赵斌表示,目前看来,RTC技术服务平台市场规模超80亿美金,亚洲和欧美市场使用量最大,中东、俄罗斯、非洲等市场增长较快。随着语音聊天室、视频社交、互动课堂等成熟使用场景的普及,音视频互动已成为用户最为主流的使用习惯,未来更多线下的真实互动场景将被搬到线上,构建新的线上世界。声网Agora官网

一、场景

对于在线教育、医疗、视频会议等场景来讲,开发面向 Windows、Mac 的跨平台客户端是必不可少的一步。在过去,每个操作系统的应用需用特定的编程语言编写,每个客户端都需要单独开发。而现在我们可以利用多种工具、框架进行跨平台开发。Electron 就是其中最热门的一个。

HTTP1.x

HTTP(HyperText Transfer Protocol)超文本传输协议伴随着计算机网络和浏览器的诞生,HTTP1.0也随之而来,处于计算机中的应用层。HTTP是建立在TCP协议之上,所以HTTP协议的瓶颈及其优化技巧都是基于TCP协议本身的特性,如TCP三次握手四次挥手建立连接带来的RTT延迟时间等。
HTTP建立之初,就是为了将HTML文档从Web服务器传送到客户端浏览器。
影响一个HTTP网络请求的主要因素:带宽和延迟

  • 带宽
  • 延迟
    • 浏览器阻塞(HOL blocking):浏览器对同一个域名,会限制最大连接数。
    • DNS查询(DNS Lookup):缓存DNS
    • 建立链接(Initial connection):TCP三次握手

HTTP 1.1与HTTP 1.0的区别:

  1. 缓存处理,引入更多缓存头控制缓存策略
  2. 带宽优化及网络连接的使用,增加断点续传功能
  3. 错误通知的管理:新增24个错误状态码,如409(conflict)表示请求资源与资源当前状态冲突、410(Gone)表示服务器上某个资源被永久性删除。
  4. Host头处理。随着虚拟主机技术的发展,一台物理服务器上可以存在多个虚拟主机且共享同一个IP。HTTP 1.1请求和响应都支持host头,请求消息中如果缺少host,会抱400(Bad Request)
  5. 长连接,HTTP 1.1支持长连接(PersistentConnection)和请求的流水线(Pipelining)处理,在一个TCP连接上可以传送多个HTTP请求和响应,减少建立、关闭连接的消耗和延迟。HTTP 1.1中默认开启Connection:keep-alive。

HTTP 1.0与1.1存在的问题:

  1. HTTP传输数据,每次都要3次握手建立连接,增加了大量延迟
  2. 明文传输
  3. header携带内容过大,增加传输成本,并且每次请求header变化不大,移动端增加用户流量
  4. 虽然HTTP1.1支持了keep-alive,但是keep-alive使用多了同样给服务端带来大量的性能压力,因为文件被请求后,服务端需要保持不必要的连接很长时间。

常见的即时通信场景包括文字聊天、语音消息发送、文件传输、音视频播放等。通俗的说,就是发短信。

Electron 的前身是Atom Shell,是基于Node.js 和 Chromium 开源项目。它让前端开发者也可以使用 JavaScript,HTML 和 CSS 构建跨平台的桌面应用程序。

HTTPS

HTTPS(网景1994创建)就是安全版的HTTP,与HTTP的区别如下:

  1. HTTPS协议需要到CA申请证书,免费证书很少,一般需要交费。
  2. HTTP协议运行在TCP之上,所有传输内容都是明文;HTTPS运行在SSL/TLS(Transport Layer Secure)上,SSL/TLS运行在TCP上,所有传输内容都是加密的。
  3. HTTP和HTTPS使用端口不同:HTTP默认80,HTTPS默认443。
  4. HTTPS可以有效防止运营商劫持。

一个HTTP网站全站改造为HTTPS,需要关注的点:

  1. 安装CA证书
  2. 购买证书后,在证书提供网站上配置自己的域名,将证书下载下来后,配置自己的web服务器,同时进行代码改造。
  3. HTTPS降低用户访问速度。SSL握手会一定程度降低速度。如果使用SPDY,HTTPS速度甚至还要比HTTP快。
  4. HTTPS中大量的密钥算法计算,会消耗服务端大量CPU资源。

图片 1

Electron 兼容 Mac、Windows 和 Linux。利用它构建的应用可在这三个操作系统上面运行。我们在很多著名项目中都能看到它的身影,比如 Slack、Cocos Creator、Visual Studio Code 等 500 多个项目。

SPDY

SPDY位于HTTP之下,TCP和SSL之上,可以轻松兼容老版本的HTTP协议,也可以使用已有的SSL功能。
SPDY是Google2012年提出,主要解决如下问题:

  1. 降低延迟。针对HTTP高延迟的问题,SPDY采取了多路复用(multiplexing)。多路复用通过多个请求stream共享一个tcp连接,解决了HOL blocking问题,降低延迟同时提高了带宽的利用率。
  2. 请求优先级(request prioritization)。多路复用的连接共享机制有可能导致关键请求被阻塞。SPDY允许给每个request设置优先级,重要请求优先得到响应。
  3. header压缩。
  4. 基于HTTPS的加密协议传输,大大提高了传输数据的可靠性。
  5. 服务端推送(Server push)

实时通信的场景包括语音、视频电话会议、网络电话等。通俗的说,就是打电话。

本文将为大家分析利用 Electron 做视频会议应用的几种实现思路及其优缺点,同时结合 demo 实例,分享如何基于 Electron 与声网 Agora Web SDK 开发一个视频会议应用。

HTTP2.0

YouTube、淘宝已经支持http2.0.
HTTP2.0可以说是SPDY的升级版本,与SPDY的区别如下:

  1. HTTP2.0支持明文HTTP传输,而SPDY强制使用HTTPS。
  2. HTTP2.0消息头压缩算法使用HPACK,而SPDY使用DEFLATE。

HTTP2.0的主要目标是改进传输性能,实现低延迟和高吞吐量。

HTTP2.0新特性:

  1. 新的二进制(Binary Format)分帧层。HTTP1.x的解析基于文本,文本的展现形式多样,要做到健壮性考虑的场景必然很多,二进制则只有0和1,更高效健壮
  2. 多路复用(MultiPlexing),即连接共享,每一个request都是用作连接共享机制的。每一个request对应一个id,一个连接上可以有多个request,每个连接的request可以随机的混杂在一起,接收方根据request的id将request再归属到不同服务端请求里面。客户端只需要一个连接就可以加载一个页面。
  3. header压缩。避免了重复header的传输,又减少了需要传输的大小。
    1. HTTP2.0会压缩首部元数据,在client和server使用首部表跟踪和存储之前发送的健值对,对于相同数据,不需要每次请求响应都发送。首部表在HTTP2.0的连接有效期内始终存在,由client、server共同渐进地更新,每个新的首部健值对要么更新已有值要么append到表尾。
    2. 所有header必须全部小写,而且请求行要独立为健值对(即header+值)。
  4. 服务端推送(server push)。服务端可以对一个客户端请求发送多个响应。server push通过推送那些它认为客户端将会需要使用到的内容到客户端缓存中,以此避免往返的延迟。
    1. 客户端可以限定推送流的数量,也可以设置为0而完全禁用server push
    2. 所有推送都遵守同源策略,即服务器不能随便将第三方资源推送给客户端,而必须是经过双方确认的。
    3. PUSH_PROMISE帧:所有服务器推送流都通过PUSH_PROMISE发送,服务端发出有意push所述资源的信号,客户端接收到PUSH_PROMISE帧后,也可以拒绝这个流。
    4. 服务端必须遵循请求-响应的循环,只能借着对请求的响应推送资源。
    5. PUSH_PROMISE帧必须在返回响应之前发送,否则客户端会出现竞态条件。

HTTP2.0的升级改造需要考虑的点:

  1. HTTP2.0其实可以支持非HTTPS的,但是主流浏览器如chrome、Firefox还是只支持基于TLS部署的HTTP2.0协议,所以要升级HTTP2.0还是先升级HTTPS好。
  2. 升级HTTPS后,如果使用NGINX,只需要在配置文件中启动相应的协议就可以。
  3. HTTP2.0完全兼容HTTP1.x,对于不支持HTTP2.0的浏览器,NGINX会自动向下兼容。

图片 2

实现视频会议的几种思路

如何利用 Electron 实现一个视频会议应用?这主要取决于使用什么技术来实现作为业务核心的 RTC 部分。

图片 3

第一种思路是使用 C++ SDK 来实现。我们可以通过 NodeJS 插件 node-gyp 将 C++ 的库编译成 NodeJS 可以直接使用的文件,界面部分则通过 Web 来实现,最后 RTC 业务部分则使用编译的插件直接调用 C++ 接口。

这种方式的优点是直接调用 C++ 接口,在性能和稳定性上有一定优势。但是,缺点是 Native 模块与 Web 模块的交互会相对复杂。

尽管 NodeJS 可以直接调用 C++ 的接口,但若 C++ 要通过回调向 Node 部分传递数据,则需要确保数据传输到 Electron 所在的线程上, Electron 才可以收到回调。又比如,若 C++ SDK 使用了具有平台差异的动态库依赖,则在使用 node-gyp 编译的过程中必须在不同平台上编译不同的版本才可以在 Electron 中正常使用。

图片 4

第二种思路是使用 WebRTC,即界面部分和 RTC 业务部分都通过 Web 来实现。

这种方法的优点是集成和调试十分简单,大部分工作可以在浏览器中完成后直接近乎无缝移植到 Electron。

不过,由于 WebRTC 缺少服务端设计和部署方案,我们首先还需要将 WebRTC 与 Janus 等开源项目结合,解决服务器的部署、NAT 穿透等问题,实现 RTC 部分,这也是这种实现方法的难点。但如果通过 Agora Web SDK 来实现 RTC 部分,则不需要担心以上问题,也是目前最快速简便的实现方法。

通过与 WebRTC 技术结合,Agora Web SDK 实现了网页端多方音视频通讯,可以快速实现 RTC 部分的开发。WebRTC 用户的音视频数据经由 Agora.io 的 SD-RTN 实时云传输,可以最大程度上保证公网的传输质量,结合 WebRTC 自有的丢包/丢帧重传,以及带宽预测,动态码率调整等策略,可以达到非常良好的多方通话用户体验。

针对这方面的集成,我们也已经在 Github 上提供了一个开源的 demo 项目。我们下面来简要梳理一下 demo 中如何实现核心音视频通话功能。

QUIC协议

QUIC(Quick UDP Internet Connections)是由Google提出的一种基于UDP改进的低时延的互联网传输层(其实有疑义,QUIC基于UDP,其实更像应用层协议)协议。
优点:具有SPDY的所有优点;0-RTT连接;减少丢包;前向纠错,减少重传时延;自适应拥赛控制,减少重新连接;相当于TLS加密。

  1. QUIC主要目标是减少连接延迟,客户端第一次连接服务器时,QUIC只需要1RTT的延迟就可以建立可靠安全的连接,相对于TCP+TLS的1~3次RTT要更加快捷。之后客户端可以在本地缓存加密的认证信息,再次与服务端建立连接时可以实现0RTT的连接建立延迟。
  2. QUIC同时复用了HTTP2.0的多路复用(Multiplexing)功能,但由于QUIC基于UDP,避免了HTTP/2的Head-of-Line Bolcking问题。
  3. QUIC基于UDP,运行在用户域而不是系统内核,使得QUIC协议可以快速部署和更新。
  4. 重传与恢复
    与TCP类似,QUIC每发送一个包后,都会等待回复一个确认包。当丢包率超过协议的纠错阀值,会显示与隐式进行重传。
    对于某些重要的数据包,在确认丢失前就会进行重传。这样在网络中会有若干个相同包同时传输,任何一个成功抵达就完成了连接,通过这样降低丢包率。接收方对于关键数据包的多次发送和普通数据包的超时重传,都采用相同的重复包处理机制。
    QUIC在拥塞避免算法上还加入了心跳机包,用于减少丢包率。
    QUIC使用FEC(前向纠错)来恢复数据,FEC采用简单的异或方式。每次发送一组数据,包含若干个数据包后,并对这些数据包依次做异或运算,最后结果作为一个FEC包再发送出去。接收方收到一组数据后,根据数据包和FEC包即可以进行考验和纠错。
  5. 安全性
    QUIC对每个散装的UDP包都进行了加密和认证的保护,并且避免使用前向依赖(如CBC模式)的方法,这样每个UDP包可以独立地根据IV进行加密或者认证处理。
    QUIC使用了两级密钥机制:初始密钥和会话密钥。初次连接时不加密,并协商初始密钥。初始密钥协商完毕后再马上协商会话密钥,这样可以保证密钥的前向安全性,之后通信过程还可以实现密钥的更新。接收方收到密钥更新时,需要用新旧两种密钥对数据进行解密,直到成功才会正式使用新密钥。
  6. 0RTT握手过程
    QUIC握手过程需要一次数据交互,0RTT即可以完成握手过程的密钥协商,比TLS相比效率提供了5倍。
    QUIC在握手过程使用Diffie-Hellman算法协商初始密钥,初始化密钥依赖于服务器存储的一组配置参数,该参数会周期性更新。初始密钥协商成果后,服务端会提供一个临时随机数,双方根据这个随机数再生成会话密钥。
    client具体握手过程如下:
    图片 5

二、产品需求点

基于 Agora Web SDK 实现音视频通话

我们需要在 Electron 环境中创建一个名为 web-app 的目录,在里面创建基本的 Web 部分内容并快速实现一个视频通话通能。

创建 AgoraRTC 实例并加入频道:

let client = AgoraRTC.CreateClient({mode:"interop"}) 

初始化 appid 并加入频道:

 client.init(options.key, () => {

                console.log("AgoraRTC client initialized")

                client.join(options.key, options.channel, options.uid, (uid) => {

                    console.log("User " + uid + " join channel successfully")

                    console.log(new Date().toLocaleTimeString())

                    // create localstream

                    resolve(uid)

                })

            })

创建本地流并推送:

let stream = AgoraRTC.creatStream(merge(defaultConfig.config))
localStream.init(() =>{
           client.publish(localStream, err => {
                  console.log("Publish local stream error: " + err);
                  localStream.play("element_id")
           })
},

在完成上面的步骤后,你应该就能看到自己的视频画面了,下一步我们要让这部分代码在 Electron 的 App 容器中跑起来。

创建 BrowserWindow 实例并读取 web-app 目录中的内容:

const electron = require('electron')
// Module to control application life.
const app = electron.app
// Module to create native browser window.
const BrowserWindow = electron.BrowserWindow

let mainwindow

function createWindow () {

  // Create the browser window.

mainWindow = new BrowserWindow({width: 800, height: 600})
 // and load the index.html of the app.
  mainWindow.loadURL(url.format({
    pathname: path.join(__dirname, './web-app/dist/index.html'),
    protocol: 'file:',
    slashes: true
  }))
mainWindow.webContents.openDevTools()

//Open the DevTools
//mainWindow.webContents.openDevTools()

//Emitted when the window is closed.
mainWindow.on('closed',function(){
  // Dereference the window object, usually you would store windows

  // in an array if your app supports multi windows, this is the time

  // when you should delete the corresponding element.
   mainWindow = null

})

完成后使用 npm start 启动 Electron 即可。

最后 点击这里 查看 demo 源码,同时可通过网站了解SDK接口。

郑重声明:本文版权归新匍京a奥门-最全网站手机版app官方下载所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。