QUIC 将会是 WebRTC 的未来么？

本文转载自WebRTC中文网，文章翻译自 Dr.Alex 的博客

QUIC 自从2013年为人所知，最近两年一直是讨论的热门话题。原因是，QUIC作为传输层协议发挥了TCP、UDP的优点，添加了加密，速度倍增，其它方面也有改进，使得设备上部署速度和更新速度较之前都有提升。

你可能认为传输层协议应该与在它上面运行的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 小组也有任何理由继续迟疑。

下面是一些我们知道的一些举措，可能有更多。

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

B.  为了在媒体栈中提供更灵活的pipeline，就像在斯德哥尔摩的一次会议提出的一样，Google团队正在推动WebRTC中更多的模块类来允许人们使用自己的编解码器，加密方式，媒体和网络传输方式。

这里有一些关于下一代 WebRTC 版本的信息：

支持添加与视频帧层第一个包不同的RTP扩展

重构类表示编码的视频frame

将代表视频编解码配置的类数量降低到合理的数字

将每一帧加密接口集成到WebRTC

实现可插入的媒体传输

将图片Id加入一般的RTP打包形式

C.  RMCAT工作组的主席，负责处理带宽评估和拥堵控制的问题，和来自callstats.io的另一位成员，一同在做 direct-media-over-QUIC与RTP-over-QUIC 。

D.  AVTCORE工作组，负责管理与RTP有关的一切，正在研究QUIC多路传输，以及其它RTP需要支持的协议。

E.  TAPS工作组正在关注如何如何支持QUIC为它们的传输协议之一。

这些工作组各自的目标不同，并且在同一个分组里可能还有更多的分支。QUIC的使用情况数量等于UDP和TCP的使用情况数量之和。当然了，对于每个人来说，他们的use case才应该是最重要的。

1.0为止不再增加新特性

这是包括Apple在内的许多公司的明确立场。不同的人对此有不同的理由。W3C工作组正在结束目前章程的进度，但是一些计划的延期执行和simulcast所需的 APIs使得simulcast测试变得困难。就像近期在Lyon的一次会议上提到的：“Simulcast目前最大的难题，像一座高山。不仅需要考虑难度，更大的疑问是需要花费我们多少时间。”对于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,邮件，会议），显示出了他们的兴趣导向和与主席达成认同的可能性。