欢迎访问 RTC 开发者社区,与更多WebRTC、实时音视频开发者交流经验。
QUIC 自从2013年为人所知,最近两年一直是讨论的热门话题。缘由是,QUIC做为传输层协议发挥了TCP、UDP的优势,添加了加密,速度倍增,其它方面也有改进,使得设备上部署速度和更新速度较以前都有提高。web
你可能认为传输层协议应该与在它上面运行的App分开设计,QUIC的历史与HTTP/2有千丝万缕的联系,而且QUIC上的HTTP/2几乎是同时发展的。关于IETF103,QUIC工做组实际上须要正在进行的工做局限于单一使用状况。这项技术很热门,并有不少公司投入了大量资金,这就是为何现在有多种实施方式。网络
QUIC背后的主要参与者固然是网络公司,还有CDN。Akamai是此技术的一个重度参与者,而且其中许多员工都是规范和说明的制定者。架构
一般网络上的媒体会被分为两个生态系统:广播和实时。在广播领域里,大多数分布是基于文件和HTPP的。在实时领域里,大多数通讯是基于RTP(RTSP/RTCP/STRP/WebRTC…)。学习
这里有一个关于RTP和QUIC的问题须要额外讨论:咱们应该用RTP做为实时媒体,仍是应该放弃它,由于RTP中的某些机制对于QUIC中的某些机制来讲是多余的?若是咱们使用RTP,咱们应该如何规划架构,而且基于这些协议应该如何规划多路传输?若是咱们放弃它,咱们如何管理不在QUIC中的媒体机制?测试
事实上,许多组织和我的都很对于经过 QUIC 传输(实时)媒体感兴趣,而且开始着手去作了。QUIC 小组也有任何理由继续迟疑。优化
下面是一些咱们知道的一些举措,可能有更多。ui
A. 来自ORTC,一些人已经实现了早期的QUIC传输和QUIC流,代码能够在Chromium代码库找到。目标是只让数据传输,而不包括媒体。google
B. 为了在媒体栈中提供更灵活的pipeline,就像在斯德哥尔摩的一次会议提出的同样,Google团队正在推进WebRTC中更多的模块类来容许人们使用本身的编解码器,加密方式,媒体和网络传输方式。编码
这里有一些关于下一代 WebRTC 版本的信息:加密
将帧加密解密加入媒体频道中C. RMCAT工做组的主席,负责处理带宽评估和拥堵控制的问题,和来自callstats.io的另外一位成员,一同在作direct-media-over-QUIC与RTP-over-QUIC。
D. AVTCORE工做组,负责管理与RTP有关的一切,正在研究QUIC多路传输,以及其它RTP须要支持的协议。
E. TAPS工做组正在关注如何如何支持QUIC为它们的传输协议之一。
这些工做组各自的目标不一样,而且在同一个分组里可能还有更多的分支。QUIC的使用状况数量等于UDP和TCP的使用状况数量之和。固然了,对于每一个人来讲,他们的use case才应该是最重要的。
这是包括Apple在内的许多公司的明确立场。不一样的人对此有不一样的理由。W3C工做组正在结束目前章程的进度,可是一些计划的延期执行和simulcast所需的 APIs使得simulcast测试变得困难。就像近期在Lyon的一次会议上提到的:“Simulcast目前最大的难题,像一座高山。不只须要考虑难度,更大的疑问是须要花费咱们多少时间。”对于W3C员工和主席来讲,这是一个主要的担心。Apple和其它的供应商也想稳定webrtc1.0版本,还有一些供应商表示,正在研究包括QUIC在内的其它方面。
这是Mozilla在去年一直以来都坚持的态度,不只仅在斯德哥尔摩的面对面会议中提出过,还在近期在 Lyon 举行的 TPAC 会议中提到了。那些不一样意的人表示,QUIC小组的主席(一个Mozilla员工)致力于在Q4完成标准文档,其它小组(包括 WebRTC)不该该继续等下去,所以WebRTC应不该该采起QUIC成为了一个棘手的问题。也有人认为,QUIC 已经被应用了起来,因此若是 WebRTC 小组不做出决定,那么他们将本身来分别着手解决。(这样的争论也发生在 SVC condec 上)
我我的认为:
QUIC是将来,咱们能够推迟它,可是没法避免。WebRTC也曾有过相同经历。
直接放弃RTP将会让不少现存的WebRTC基础设施受到影响。QUIC背后的团队起初花费了不少时间设计技术选型,使得QUIC能够帮如今的传输技术获得更大的优化,而且让这项技术获得更快更普遍的采用。我相信他们也在 QUIC 应用于实时传输方面作出了一样的努力。
最后给但愿开发实时音视频App,或但愿学习 WebRTC 的开发者推荐 一些博文与资料