http://www.ox-holdings.com

WebRTC并非一夜之间就出现的技术新匍京娱乐场手机版),比如电信用户和美国用户通话时丢包大

摘要因为音视频通话 = 音视频处理 + 网络传输,而公共互联网不是为了实时通信设计的。所以说开发真正可用的实时音视频服务,从demo到生产上线,中间还差1万个WebRTC。前言  WebRTC开源之前,实时音视频通信听起来好高级:回声消除、噪声抑制……对于看到傅里叶变换都头疼的工程师很难搞定这些专业领域的问题。  Google收购了GIPS,开源了WebRTC项目之后,开发者可以自己折腾出互联网音视频通信了。下载、编译、集成之后,第一次听到通过互联网传过来的喂喂喂,工程师会非常兴奋,demo到万人直播现场只差一步了。  但是,电信行业要求可用性4个9,而刚刚让人兴奋的“喂喂喂”,1个9都到不了。某公司在展会上演示跨国音视频,多次呼叫无法接通,自嘲说我们还没有做网络优化嘛。这就等于互联网全民创业时期的”就差个程序员了“,本质上是和demo与真正产品之间的差距,是外行与内行之间的差距。  小红说家里WIFI聊QQ、打斗地主毫无压力,用你的音视频通话就卡的不行。想开发分享到微信这个功能,百度个文档照着一步步干就好了;但是找不到这样一个文档,照着做就能解决用户报的这些问题,进而把音视频通话做到电信水平。  音视频通话对教育、社交、约会类APP是刚需功能,上述问题会迫使用户使用更稳定的skype或微信来沟通。技术原因造成用户流失,是每个工程师都不愿意看到的事情。实时音视频难在哪?  因为音视频通话 = 音视频处理 + 网络传输,而公共互联网不是为了实时通信设计的。难点如下:协议方面:tcp有无法忍受的延时,udp有丢包延时抖动乱序。政治方面:各个国家出口光缆屈指可数,带宽也有严格限制。商业方面:由于成本原因,跨运营商的网络传输惨不忍睹。用户设备:无线路由器从802.11G开始才支持实时通信模式;多个路由器使用相同的频段会造成信号污染;2G网络上行带宽只有20kbps。架构方面:公共网络每个节点都不可靠,后台工程师熟悉的mtr命令可以分析哪个路由节点丢包高,如果此时正在传输音视频,质量必然受到影响。  要在这样一个公共互联网上传输音视频数据,却没有做任何网络传输的工作,不遇到问题的话可以买彩票了。网络传输要怎么搞?老师没讲过、网上搜不到,是不是有一种深深的无力感。具体怎么解决?可以从以下几个方面入手:质量评估:声音卡成翔,首先需要通过网络参数来评估语音质量。数据统计:用户的使用情况到底怎么样,需要完善的数据统计模型和支撑系统,不然开发者就是睁眼瞎。智能接入:影响质量的原因——不同的ISP会有不同的丢包水平,需要多线服务器。智能路由:随着用户扩张到海外,比如电信用户和美国用户通话时丢包大,没有一边电信一边美国这种多线服务器,可能通过日本转发过去就不丢包了,这就是智能路由。虚拟专线:智能接入加上智能路由,可以媲美网络专线的质量了,这就是所谓的虚拟专线。丢包对抗:用户抱怨明显少了很多,还剩下一些自己网络不给力的用户。用户x一直用2G,用户y在公司里很多WIFI有信号污染,那么就需要丢包对抗机制。网络可用性:用户报虹桥机场打不通,小发现公共场所WIFI有很多限制,所以需要考虑网络可用性。后台高可用:用户没问题了,但各种互联网公司事件让运营者担心自己服务器电源也被挖掘机铲断,所以需要后台高可用。

2)FEC:

FEC有很多种,主要特点是主动抗丢包,通过增加冗余数据实现抗丢包效果。缺点是浪费带宽。一般的说,只有在丢包大于10%的时候才使用FEC。FEC技术有以下分类方法。

  • 不分级的FEC

  • 信源FEC

  • Inband FEC

  • Outband FEC

  • 信道FEC

  • Read SolomonCode

  • DigitalFountain Code

  • 分级的FEC

  • PLCPLC的意义在于当FEC和重传之后还无法恢复的时候,通过信号处理的方法对丢失的数据进行补偿。

分类:

  • 插0法:所谓插0法就是在丢包的位置全添0.

  • 预测法,插值法,快慢放(注意,快慢放有副作用,大家不愿意接受这种做法)

  • 基于编解码模型的PLC方法

    • 特点:被动抗丢包。

    • 优点:灵活不占带宽

    • 缺点:根据编解码器的类型,对抗能力有限对低压缩比的编解码器,可以做到比较高的抗丢包效果。对高压缩比的编解码器,一般看丢包能力在5%以下。

  • 高级PLC算法,盲宽带带宽扩展(BWE),就是把8Khz拓展到16Khz。

摘要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大会的相关报道后续会接踵而至,敬请期待。

从互联网发展历程看 —— 实时通信和互联网交叉融合所带来的改变

但实际上,始建于上世纪 60 年代的互联网本身并非为“实时”所设计,受限于当时的应用场景和技术,再加上不同国家、运营商之间人为制造的屏障,通信技术在实时传输、质量保证等各方面都可谓差强人意。

也正因如此,从互联网诞生之日起,一代又一代的技术人便在对通信技术进行不断地更新升级。1989年,还在欧洲粒子研究中心(CERN)的 Tim Berners-Lee 研制出了三项突破性的数字通信技术:可用于排列文本文件的 HTML 语言、连接文件的 HTTP 系统以及用来对特殊节点信息进行定位的 URL。这三项创新改变了整个通信系统,使得信息能够更容易地穿越计算机网络。而在1993年,Berners-Lee 更是建立起万维网联盟(World Wide Web Consortium,简称 W3C),负责 Web 相关标准的制定。浏览器的普及和 W3C 的推动,使得 Web 上可以访问的资源逐渐丰富起来,然而此时 Web 的主要通信还是浏览器向服务器请求静态 HTML 信息。

 

新匍京娱乐场手机版 1

 

不过,同在 1993 年,CGI(Common Gateway Interface,通用网关接口)的出现带动了 Web 上动态信息服务的蓬勃兴起。CGI 定义了 Web 服务器与外部应用程序之间的通信接口标准,Web 服务器可以通过 CGI 执行外部程序,让外部程序根据 Web 请求内容生成动态的内容。

 

新匍京娱乐场手机版 2

 

到了 1995 年,NetScape 公司设计的 JavaScript 被用作浏览器上运行脚本语言为网页增加动态性,不仅能够做出非常酷的页面动态效果,还可以减少与服务器端的通信开销,而十年后,也就是 2005 年,当 Google 的崛起掀开了 Web 2.0 的大幕,应运而生的 AJAX 更使得 javascript 再次大放异彩。

我们知道,在 Web 应用中,用户提交表单时就向 Web 服务器发送一个请求,服务器进行接收处理,并返回一个新的网页,前后两个页面中的大部分 HTML 代码往往是一样的,由此也就造成了返回时带宽资源的浪费。而 AJAX 应用仅向服务器发送并返回必要的数据,且在客户端采用 JavaScript 处理来自服务器的响应,更新页面的局部信息。这样不仅让浏览器和服务器的数据交换大大减少,且客户端也可以更快速地响应用户操作。

 

新匍京娱乐场手机版 3

 

而到了移动互联网时代,通信技术标准化也就成为了水到渠成的自然现象。在《苹果终于入伙 WebRTC,新一代移动 Web 应用爆发路上还有哪些坑?》一文中,我们曾谈到的 WebRTC 标准便是典型案例之一。

在 2011 年以前,浏览器之间要想实现实时通信,需要私有技术,其中大部分都是通过插件和客户端来安装使用。对于许多用户而言,插件的下载、安装和更新是一个复杂、繁琐和容易出错的操作。而对于开发人员来说,插件的调试、测试、部署、错误修复和维护同样困难重重,且不提还涉及到一些受版权保护的技术,整合相当复杂。再者,很多时候,服务提供商很难说服用户去安装插件。

但这一两头吃力还不讨好的局面就这样被 Google 将 WebRTC 项目开源所打破。2011 年,WebRTC 基于 BSD 协议开源,同年,W3C 启动 WebRTC 计划,让 WebRTC 成为了 HTML5 标准的一部分(目前,该规范还在开发中)。

另一方面,在移动互联网创业大潮涌动之时,不少创业者选择从移动 SDK 切入,将实时通信工具化,开发者及团队无需顾及实时通信背后繁琐的技术原理与逻辑实现,只需在应用开发中集成相应的 SDK 即可轻松实现实时通信功能。这方面的代表性企业可见声网 Agora.io,其提供了一个极简 SDK,让开发者接入 SD-RTN™ 实时虚拟通信网,在任何 App 和网站实现高质量的音频通话、视频通话、全互动直播。

同时,随着网络基础设施到位、硬件配件发展成熟,以及 4G、Wi-Fi 的普及,用户开始对更丰富的功能、场景有了更多的需求。譬如在当前人工智能如火如荼之时,诸多智能设备都集成了实时音视频的功能,前文提到的小米 AI 音箱即是其中之一。

对此,声网 Agora.io CEO 赵斌如此总结道:

中国互联网发展迅猛,基础云服务、开源技术、html5、移动 SDK 等技术,让中国的开发者能最快速地开发移动和网页 App,与世界比肩。下一个风口,一定会是融合了实时通信技术的应用。

未来在实时通信领域,WebRTC 依然是非常重要的一块拼图。

2、AVPM(Audio Video Processing Module)

AVPM在视频上指美颜、降噪。音频的一般前后后处理包括3A引擎、AEC、ANS、AGC、混音、加混响(音乐直播)、去混响(会议模式)。是否应该用GPU,什么情况下应该用GPU。用GPU是为了省电还是运算快?

那么,在风口之上,实时通信还存在哪些技术难点尚待完全攻克?

接下来,我们进行具体分析。

  • 网络传输:现存的互联网作为冷战时代的产物最早其实是为了用于保障美国通信网络,其在网络传输方面的种种局限也直接导致了现在的互联网在大文件传输、实时传输方面的窒碍难行。而语/视频通信、直播连麦对实时性要求非常高,要求延迟低至几百毫秒,因此,现存的互联网并不能满足这种新型的实时应用场景。

  • 编解码:传统的编解码算法,也非应用于复杂的互联网实时场景的良选,就导致卡顿、模糊等不可用的情况发生。

  • 硬件适配:在音视频通话中,除了延迟,还有一个严重影响用户体验的问题 —— 回声。所谓“回声”,即是指自己的声音传到远端再通过远端的麦克风录音传回来。我们需要通过信号处理算法来进行回声消除,但由于手机的音量控制是非线性的,不同的手机材质、手机壳会导致声音传导性有差异,设备种类差异导致算法不能普适。且Android 手机碎片化严重,也就直接导致了移动端适配工作量庞杂。

  • QoE 质量保障: 来自北欧的实时通信数据测试公司 Callstats.io 曾分享过欧美市场实时通信行业现状的调研数据,基于公网的 WebRTC 通话中有 16% 通话质量不可接受。而实际情况中,类似东南亚、中东这些基建不发达地区会糟糕得多。如何保障 RTC 服务的高连通性、高质量,也就成为了 RTC 领域的一大技术难点。

Google 在 Gtalk 中也使用了 GIPS 的授权。Google 在 2011 年收购了 GIPS,并将其源代码开源,加上在 2010 年收购的 On2 获取到的 VPx 系列视频编解码器(详见《即时通讯音视频开发:视频编码H.264、VP8的前世今生》),WebRTC 开源项目应运而生,即 GIPS 音视频引擎 + 替换掉 H.264 的 VPx 视频编解码器。

3)Device 的回声消除

安卓的碎片化,和回声消除的固有特点使得WebRTC在移动端无法满足让所有机型都处理的很好。

2017 已过大半,从年初盛起的《王者荣耀》、《狼人杀》却依然是最火爆的游戏产品,其共同特性都在于集成了实时语音功能,前者左手走位右手技能,语音自然也就成为了非常必要的属性,而后者更不用说,本就是纯粹依靠实时语音进行下去的游戏。

- 即时通讯开发交流3群:185926912[推荐]

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》

3)Opus/EVS时代

Opus在2012年横空出世,按照官网的说法,opus比HEAAC好,并给了一些demo。但事实真的是这样吗,Opus是由SILK+CELT混合的编码器,学术上的叫法叫做USAC,Unify Speech and Audio Coding。这点,EVS也是。意思是不区分音乐语音的编解码器。这个编解码器内有个一Music detector去判断当前帧是语音还是音乐,语音选择语言框架编码,音乐选择音乐框架编码(注意目前还没有统一框架,原因是框架一般是人体生理模拟,因为人有两个声学器官,嘴和耳朵,所以语音是针对声带,口腔,鼻腔见面,音乐是根据人耳朵结构的时间掩蔽,频域掩蔽,双耳暗示效益编码)。所以,Opus适合电台这种音乐语音混合编码器。但是由于Opus的音乐编码CELT的质量并不突出,所以Opus在双声道低速率(24kbps~32kbps左右)效果并不突出。在网站上的demo缺少钢琴,爵士,摇滚的demo。更多是流行音乐和民谣。高频分量相对弱些。但如果使用Opus有以下要注意事情,音频码率高些,不要限制编码器的模式。另外高通宣称有OPUS专利,来自大神Ken VOS。
EVS 主要是VoiceAge公司,Dolby公司,Fraunhofer,华为(北京苗磊兄弟,羡慕你们)联合开发的USAC编码器(这里面也有故事,和技术无关,我就不八卦了),低速率音乐编码器质量很好,源自dolby和Fraunhofer的HEAACv2技术。但是问题是,目前没有高效的嵌入式系统可用的编码器,不支持双声道,专利费不便宜哦。主要计划用在未来的VoLTE中(华为又要收苹果钱了哦)。 
新匍京娱乐场手机版 4

那么,当实时通信无处不在之时,我们该怎么做?

当各式智能硬件、移动应用以及 Web App 中的许多模块都越来越依赖于音视频技术,实时通信已然成为了所有行业的一大基础设施,不仅仅是在直播、游戏这些泛娱乐行业,更渗透到在线医疗、教育、金融等领域。在不同场景下,推动着人们沟通互动方式的改变。

但是,就是这样一个已与各个垂直行业进行深度融合需求庞大的技术领域,却仍然匮乏核心技术高端人才。RTC 核心技术最需求的是通信工程相关专业的人才,而这些专业的应届毕业生此前就业一般集中于华为、爱立信等传统通信行业厂商,也不具有 RTC 的经验,一般都是工作后二次学习。开发者需要对实时通信有更深层次的理解,建立起 RTC 技术体系,帮助自己在各个行业开拓创新的可能。


最后,对于想要进入 RTC 领域的开发者,推荐即将于 9 月 21 -22 日在北京万豪酒店举行的 RTC 2017 实时互联网大会,主要有两点:一是在于集结了实时通信领域非常重量级的大咖,比如 WebRTC 标准之父、IETF 的参与者 Daniel C. Burnett,还有来自Google、声网、Slack、Houseparty、Atlaissian、陌陌、花椒、熊猫等公司的技术专家,可以在现场收获实时通信最新的第一手资源,同时也与讲者们进行更深入的沟通交流。其次,这一会议的分会场设置完全围绕 RTC 技术栈来,从底层到前端,从架构到编解码,从移动开发到行业技术实践,能够帮助所有想要学习 RTC 的开发者建立起学习架构体系。

 

第一:WebRTC 使用的是对点对传输,虽然节约了服务器资源的开销,但实际使用时也带来了传输质量的问题,比如跨国以及跨运营商网络之间的传输质量往往很难保证,虽然 webRTC 有优秀的端对端质量控制算法,但在错综复杂的网络条件下,表现也很难让人满意;

一、一个典型的IP通信模型

新匍京娱乐场手机版 5

而从游戏到直播、在线教育/医疗以及 VR/AR、AI 等互联网垂直行业及创新技术,这样的例子还有很多。比如转型做直播的陌陌在最新的 8.0 版本中推出了“快聊”、“狼人杀”、“派对”等实时视频社交玩法;小米在新发布智能音箱中也集成了实时语音云服务。随着互联网服务越来越廉价易得,诸如网络电话、视频通话、全互动直播等实时场景已然成为用户的普遍需求,越来越多的规模化应用基于使用模式及场景集成了实时音视频功能,“实时”俨然已是互联网最热的标签词之一。

基于这些先进技术,使用 WebRTC 的为我们带来的好处主要有以下几个方面:

三、Server2Device——Lastmile技术简介

我们在公网做实时音视频服务,丢包对抗是少不了的。

首先我们定义下什么是丢包:没按时到的包就是丢包。一个包应该在某个时间点到,但它晚到了,即使来了但是晚了,也叫丢包。因为播放的这段时间已经过去了,即使放了,体验也不好。从整个网络上看,丢包一定有时限,否则,都通过反复重传方法,一定能送达一个包。

Server到达device这块还可以分以下两种通路。

1、Server经过基站到Device

可以分为以下几种情况:

  • 不同类型的基站:3G/4G,TD和WDCDMA就不一样。

  • 相同类型的基站不同的地点:北京联通推出流量包月下行最高150kbps的服务

  • 相同基站相同地点不同时间:球赛,运动会,热点聚集区附近的基站

  • 不同国家的基站:中国的WCDMA和印度的WCDMA和美国的WCDMA

2、Server经过家用路由器到Device

2.4G路由和5G路由,2.4G路由覆盖面积广,但是2.4G频段很脏,容易干扰和丢包。5G路由相对好些,但是覆盖面积小。并且在公司内部,会有多个路由,很多人连一个路由。竞争严重,有时网络丢包会很高。并且有些路由器是有bug的,比如小米路由的梳状抖动模型。

想要从根源上解决这些问题,还需要先对 RTC 整个技术栈做个了解。

RTC 从功能流程上来讲,包含了采集、编码、前后处理、传输、解码、缓冲、渲染等诸多环节,下图是一个 RTC 通信的粗略流程,每一个细分环节还有更细分的技术模块。比如在前后处理环节,有美颜、滤镜、回声消除、噪声抑制等,采集有麦克风阵列等,编解码有 VP8、VP9、H.264 等。

 

新匍京娱乐场手机版 6

 

在这里,来自声网的技术专家分享了他们的实践:

  • 通过专为内容实时传输而设计的网络架构 SD-RTN 解决网络传输问题。在互联网上不同地区的数据中心放置软件组网单元,相互连接互相调度,在现有的公共互联网基础上构建一层新的虚拟网络;
  • 针对互联网信道的实时一对一、多人通讯设计了专门的私有编解码,以适应互联网丢包、抖动、延迟等问题;

 

新匍京娱乐场手机版 7

 

  • 将“免”适配和适配相互配合,依靠线上数据的反馈,判断“免”的效果;
  • 基于大数据开发了可供开发者 7*24 查看的“实时数据监控平台”。开发者可以查看的每个用户的通话质量情况,包括网路分布、设备分布、质量分布、通话质量、接通率、通话分钟数等。

值得一提的还有,不少开发者直接将 RTC 和 WebRTC 划上了等号。实际上,WebRTC 是 Google 的一个专门针对网页实时通信的标准及开源项目,只提供了基础的前端功能实现,包括编码解码和抖动缓冲等,开发者若要基于 WebRTC 开发商用项目,需要自行做服务端实现和部署,信令前后端选型实现部署,以及手机适配等一系列具体工作。除此之外,还要在可用性和高质量方面进行大量的改进和打磨,对自身开发能力的门槛要求非常高。而一个专业的 RTC 技术服务系统,除了涵盖上述的通信环节外,实际上还需要有解决互联网不稳定性的专用通信网络,以及针对互联网信道的高容忍度的音视频信号处理算法。当然,常规云服务的高可用、服务质量的保障和监控维护工具都只能算是一个专业服务商的基本模块。

而回望三大运营商的数据,语音通话量在 2015 年首次出现了负增长,可以看到互联网 OTT 应用对传统语音通话业务的冲击有多强烈。正是由于这些日益完善的基础设施,更快的智能手机,更快的网络,更丰富的使用场景,实时通信的需求越来越强烈。

1)重传:

传统物理信道传输中,无论是802.11还是3g/4g标准,本身就包含物理层重传机制,在IP信道中,重传也是非常有效的方法。
优点:节省带宽,按需重传。
约束条件,RTT时间短

第三:WebRTC 是为 1 对 1 通信场景设计的,如果要实现多人的场景,还是需要借助服务端方案。即使当前有很多开源的 webRTC 服务器实现,一个流媒体中转服务器或者混流服务器的部署以及维护也是非常复杂的;

3、丢包对抗的几种办法

但是受限于 WebRTC 自身的一些缺憾,一般开发者都不是直接完全使用 WebRTC,而是根据实际场景基于 WebRTC 进行二次开发。WebRTC 本身并不是万能钥匙,不可能一套代码以及接口可以解决所有问题。

此文较长,建议收藏起来看。

从 2015 开始不断涌现出的互动直播、狼人杀、抓娃娃、直播答题、线上 KTV 等创新,将常见的线下场景转至线上,也足以作为实时音视频通信风头正劲的有力佐证。

1、AVDM(Audio Video Device Module):

AVDM是主要针对device的播放,录音录像端做处理的模块。不同的平台会有不同的驱动和录音录像需求,比如XP、Vista、win7、win8。我们不能一概而论的统一选择dshow甚至是waveout来播放还是录音。在移动端、iOS、安卓,安卓本身也有java和opensles两种录音方法,并且还有一系列的配置参数。比如用什么样的参数能录立体声,关闭手机自带处理,录高音质声音,延时低等等。和device相关的还有就是硬件能力:GPU、CPU的能力,对于视频而言,不同的CPU能支持怎么样的视频编解码能力输出。

越来越多的终端设备上,无需借助任何插件或者 native 应用,通过打开网页链接,即可进行高质量的音视频通话,应用开发者也无需关注音视频引擎实现细节,大大节约了开发成本。

2)AMRNB/WB,Speex,ILBC/ISAC,SILK时代

AMR系列:作为8kbps~12kbps的语音编解码器,在一段时间内,质量是不错的,毕竟他是WCDMA和TDCDMA标准选择的语音编解码器。也通过3GPP标准开源。在有一段时间Yy语音和QTalk,微信语音留言都使用了AMR编解码器。但是他的问题是,有专利费,固定比特率。抗丢包性能一般。

  • Speex:Speex是由Jean Marc Valin(也是CELT的主要发明人)开发的编解码器,特点是免专利费,开源。支持宽带超宽带。缺点是这个编解码器可能是为了避开专利,并且受限于很多因素,编码质量并不好。无论是窄带宽带超宽带,对抗丢包,质量都很一般。但是这也是站在今天的角度看当时的技术,并且在当时能够提供免专利费的全频带,低速率(16kbps左右)语音编解码器确实没有,可以说,Speex填补了空白。并且Speex有一个显著特点是,Speex实际上不是一个编解码器,是一个音频处理集。包括AGC,AEC,ANS。可以完整的应用在一个VOIP通信系统中,并且他的AEC的自适应滤波部分做的相当不错,在PC上可以拿来使用。

  • ILBC和ISAC:ILBC编解码器是GIPS(WebRTC前身)第一个开源出来的编解码器。8khz,13.3kbps。窄带编解码器。他的特点是,抗丢包性好。信源编码的基础是去冗余,信道编码的基础是加冗余。去冗余的弊端就是抗丢包差,所以ILBC反其道行之,减少帧间冗余的压缩,增加每个帧独立性,使得当发生丢包的时候,丢包对抗效果好。ILBC在部分呼叫中心公司有广泛应用。ISAC是在GIPS被收购之后伴随WebRTC开源的编解码器,他的特点是支持16khz,24khz,32khz。支持带宽估计(这是很多语音编解码器不具备的)。并且他不是基于CELP框架,使用了频域编码框架+格型编码+算数编码的框架。具有一定特殊性。ISAC继承了ILBC的抗丢包优点,但是缺点也相当突出,由于用了频域编码器,高频语音编码效果不好,听起来有金属音,PESQ-WB MOS分低。

  • SILK:SILK面世时代比较晚,是以上编解码器中最晚开发一个编解码器。他的发明人是Ken Vos,也是ILBC,ISAC的主要开发者。Ken VOS在离开GIPS之后去了高通,为高通开发了一个宽带编解码器。然后到Skype为Skype开发SILK。Skpye有一段时间也是使用GIPS的方案,用ILBC和ISAC。后面自己开发Codec,他们第一个自己的Codec是VSOPC(好像,这里缺一个wiki的链接)。但是质量很差,用户抱怨。故请来了Vos开发SILK。Vos又在Skpye尝试新框架,Vos的SILK使用了预测加噪声整形的混合框架(第一使用类似框架的是Broadcom的BV16,BV32编解码器)。使用STP+LTP+STNS+LTNS两层后反馈嵌套(BV16和BV32是一个前馈+一个后馈,这里差图和wiki链接)。并且引入Delay Decision量化搜索方法,使得标量量化具有矢量量化的性能指标。可以说SILK的质量是非常好的一个编解码器。(这里差一个表),无论主观还是客观。虽然他充分挖掘相关性,但由于做到极致和非常完美,使得在丢包对抗上有一定帮助。并且他开发了RED辅助编码算法,提高他的抗丢包能力。

我个人,是非常推荐初级和中级算法工程师仔细阅读SILK编解码器,代码质量好(EE工程师中少见),并且用了很多基础算法,很多小技巧,甚至包括自动控制理论。对提升自己的能力很有帮助。

有人说 2017 年是 WebRTC 的转折之年,2018 年将是 WebRTC 的爆发之年,这并非没有根据。就在去年,WebRTC 1.0 标准草案出炉(实际上WebRTC标准草案的早期版本早在2011年就已经发布,WebRTC并非一夜之间就出现的技术),并将于今年正式发布。与此同时,越来越多的浏览器和厂商都开始对它进行广泛的支持,WebRTC 即将成为互联网的基础设施了,或许门槛如此之高的实时音视频技术终有白菜化的那一天。

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