0

原文标题:QUIC is the future of #WebRTC ….. or is it?
作者:'agouaillard'

QUIC将会是WebRTC的未来,会么?

QUIC自从2013年为人所知,最近两年一直是网络会议讨论的热门话题。原因是,QUIC作为传输层协议发挥了TCP,UDP的最佳效果,添加了加密,速度倍增,其它方面也有改进,使得设备上部署速度和更新速度较之前都有提升。如果你想大概了解QUIC,wikipedia是一个不错的选择。进一步的了解可以通过IETF工作组获得更多详细信息。

简介

你可能认为传输层协议应该与在它上面运行的App分开设计,QUIC的历史卷入了HTTP/2之一,并且QUIC上的HTTP/2几乎是同时发展的。关于IETF103,QUIC工作组实际上需要正在进行的工作局限于单一使用情况。主题很热门,并且富有策略,投入了大量金钱,这就是为什么如今存在有16种不同的实现方式。

QUIC背后的主要参与者当然是网络公司,还有CDN。Akamai是此技术的一个实施者,并且其中许多员工都是规范和说明的制定者。

通常网络上的媒体会被分为两个世界:广播世界和实时世界。在广播世界里,大多数分布是基于文件和HTPP的,并且在QUIC上关注HTTP/2是合乎逻辑的。在现实世界里,大多数交流是基于RTP(RTSP/RTCP/STRP/WebRTC…)。

这里有一个关于RTP和QUIC的问题需要额外调查研究:我们应该用RTP作为实时媒体,还是应该放弃它,因为RTP中的某些机制对于QUIC中的某些机制来说是多余的?如果我们使用RTP,我们应该如何对应RTP和帧,并且如何多路传输这些协议。如果我们放弃它,我们如何管理不在QUIC中的媒体机制?

下面是一些我知道的出发点,可能有更多。

A
来自ORTC,一些人已经实现了早期的QUIC传输和QUIC流,代码可以在Chromium代码库找到。目标是只让数据转移,而不包括媒体。

B
为了在媒体栈中准备更灵活的流水操作,就像在Stockholm的期中会议提出的一样,Google团队正在推动WebRTC中更多的模块类来允许人们使用自己的编解码器,加密方式,媒体和网络传输方式。

关于NV的WebRTC期刊

支持添加与视频帧层第一个包不同的RTP扩展https://bugs.chromium.org/p/webrtc/issues/detail?id=9680.

重构类表示编码的视频frame
https://bugs.chromium.org/p/webrtc/issues/detail?id=9378

将代表视频编解码配置的类数量降低到合理的数字
https://bugs.chromium.org/p/webrtc/issues/detail?id=6883

将每一帧加密接口集成到WebRTC
https://bugs.chromium.org/p/webrtc/issues/detail?id=9681

实现可插入的媒体传输
https://bugs.chromium.org/p/webrtc/issues/detail?id=9719

将图片Id加入一般的RTP打包形式
https://bugs.chromium.org/p/webrtc/issues/detail?id=9582

WebRTC补丁:

将帧加密解密加入媒体频道中:
https://webrtc-review.googlesource.com/c/src/+/97000

向媒体传输接口加入视频支持
99304

媒体传输接口:
https://webrtc-review.googlesource.com/95960

对帧加密解密加入Java接口
https://webrtc-review.googlesource.com/96865

C
RMCAT工作组的主席,负责处理带宽评估和拥堵控制的问题,和来自call stats.io的另一位成员发表了一篇有趣的文章,描述了QUIC上的直接媒体和QUIC尚的RTP。

D
AVTCORE工作组,负责管理与RTP有关的一切,正在寻找多路QUIC和其它RTP需要支持的协议。

E
TAPS工作组正在关注如何如何支持QUIC为它们的传输协议之一。
这些工作组各自的目标不同,并且在同一个分组里,可能还有更多的分支。QUIC的使用情况数量等于UDP和TCP的使用情况数量之和。当然了,对于每个人来说,他们考虑的用例才应该是最重要最流行的。

不再更新,1.0终止

这是包括Apple在内的许多公司的明确立场。不同的人对此有不同的理由。W3C工作组关注当前方法的结果,即速度快,但是同时联播的统一计划和所需API使得测试同时联播变得困难。就像上周在Lyon提到的:同时联播是一座未知高度的山。我们不仅在上山,同时我们无法确定还要爬多高。对于W3C员工和主席,编辑来说,这是一个主要的担忧。Apple和其它的供应商也想稳定webrtc1.0版本,还有一些供应商表示,正在研究包括QUIC在内的其它方面。

QUIC简单,但不够成熟

在2018整年都在WebRTC小组中处于Mozilla位置,主要在Stockholm的期中面对面会议中表示,还有两周之前在Lyon的TPAC会议。那些不同意的人表示,QUIC小组的主席,一个Mozilla员工,致力于Q4标准文件,其它小组不应该等待太久,因此WebRTC应不应该采取QUIC是一个很棘手的问题。

多方组织似乎达成了认同,QUIC上的媒体需要一个不可靠的模式,至今还没有产生在表格上。最新的单向QUIC流同样破坏了某些部分。

我个人的想法更细致,但是我很谨慎:

QUIC是未来,我们可以延迟,但是不能避免它。WebRTC也一样。

直接放弃RTP将会对很多现存的WebRTC架构产生影响。IMHO是个太野蛮的方法。QUIC背后的团队起初花费了很多时间将设计投入现实使用测试,因此QUIC对于现今基于UDP的结构是个加强,并且速度更快。我相信他们处理实时媒体的时候也用到了同样的方法。在此,我希望应该把WebRTC媒体服务器开发者的反馈纳入考虑。

注意WebRTC1.0没有离去,所以你还是可以产生和使用RTP流,SCTP流。

结论:

在WebRTC中,当提到QUIC时有很多选择。如果你采取上面提到的不同的选择,你也会得到不同的结果。

IETF和W3C中,你可以随时提出自己的意见,没有想法会被埋没。你的意见会被听取,阅读。

你需要与其他人团结起来,达成认同,这是一个耗时的任务,需要非技术方面的技能。你需要使人信服,你的想法不但有效,并且值得他们花时间来研究。你需要使人信服,你提出的观点比他们的好,这意味着你首先要花时间了解他们想要的和不想要的,在最终观点中,将此加入考虑范围之内,这样就可以迎合别人的兴趣。这更像是一个交流问题。

如果你的范围太狭窄,就不能与更多人达成认同。如果你能不妥协,也是一样。如果你请求他人花时间帮助你,他们不会的。对于大多数人来说,他们已经没有足够的时间来处理他们该做的事了。
交流失败的一个明显标志没人理会你的邮件和问题。只有编辑和主席有责任回答。然而,在不同平台提出的问题(Github,邮件,会议),显示出了他们的兴趣导向和与主席达成认同的可能性。



期待你一针见血的评论,Come on!

不用想啦,马上 "登录"  发表自已的想法.