算法系列:QUIC流的方法

一开始，有IP. IP产生了美女(TCP)和野兽(UDP)。. 一切都很好.

在IP(互联网协议)的第一个时代， TCP(传输控制协议)和UDP(用户数据报协议)都得到了各地IP架构师的青睐, 它们被宣布为有效的传输协议来携带IP. 但很快，TCP就获得了“好”的绰号，它开始超越UDP. 由于TCP能够协调多种类型的流量，人们对它倾注了大量的喜爱和关注, 它获得了万维网的桂冠. 与此同时, 是强大的, 有进取心的, 而更高效的UDP则潜伏在暗处, 支持几乎所有的IP流量, 除了所有通过HTTP或HTTPS的广受好评的网络流量.

万维网流量的第一个时代(IP的第二个时代)和谐地进行着, 其中图片和文本与基本的HTML框架和编码配合得很好. 然而，在第一个万维网流量时代接近尾声的某个时刻，流媒体诞生了.

流媒体架构师开始寻找一种更一致、更有效的方式在网络上传输视频——超越渐进式下载, 哪一种视频相当于静止图像——能够大规模地传输单播点播视频流. 视频传输领域的先知们宣称，只要我们都欢迎UDP作为TCP在互联网路由器上的平等伙伴回归，多播流就可以解决单播流的所有大规模问题.

然而，比起真正高效的大规模视频流，HTTP的吸引力更大, 所以万维网流量的第二个时代包含了更多的TCP，而不包括UDP. 而不是流媒体修复互联网, 互联网通过将“流”切割成HTTP小文件段来进行大规模传输，从而削弱了流媒体的能力. 这种方法很有效:流媒体越来越受欢迎, 数以亿计的消费者能够观看点播内容，这要归功于HTTP和TCP的结合，即HTTP/2.

然而，这些消费者对无法像当地有有线电视的邻居那样观看体育比赛感到沮丧, 卫星, 甚至无线天线也能看到它. 那些通过OTT流媒体观看体育直播的消费者往往是最后一个知道的——有时只差几秒钟, 其他时间按分钟计算——关于一个关键进球或得分.

如果有一种方法可以将体育直播推送到OTT机顶盒或移动设备上就好了零延迟. 那是当遗忘已久的 UDP突然开始感受到这份爱. 这也是万维网流量的第三个时代, 由两个IP子代(TCP和UDP)在同等程度上实现, 成形. 它被称为HTTP/3. 这很好.

什么是QUIC?

OK, 所以我关于流媒体和网络流量的简短历史可能听起来很老套, 但有必要了解算法系列这一部分的主题. 我将深入研究HTTP/3和QUIC(快速UDP互联网连接)协议的基础, 展示了自上世纪90年代末以来流媒体领域最大的革命之一的好处和背后的数学原理.

QUIC起源于近10年前. 作为2012年谷歌Chromium项目的一部分, 由吉姆·罗斯金领导, 使用UDP降低延迟的好处在一个被称为使用QUIC传输协议的HTTP/2语义或QUIC上的超文本传输协议(HTTP)的提议中被列出.

罗斯金，在 2013年的论文，描述了一种独特的方法来解决流媒体视频在网络上面临的问题:延迟. “我们希望减少整个互联网的延迟, 提供一组响应更快的用户交互,他说. “随着时间的推移,
全世界的带宽将会增长, 但是往返时间, 由光速控制, 不会减少. 我们需要一个协议来处理请求, 反应, 通过互联网进行交互，延迟更短，重传时间更短, 我们认为，目前的做法正在阻碍我们所有人."

快进到2018年, 谷歌(Google)的QUIC在降低整体网络延迟方面也获得了足够多的积极反馈互联网工程任务组(IETF)接管了维护和更新QUIC功能. IETF内部的目标, 这也有助于维护HTTP标准, 是将新版本的QUIC与新版本的HTTP结合起来. 今年年初, 一个IETF工作组就是这么做的, 发布了将QUIC合并到第三代HTTP中的规范草案, 现在统称为HTTP/3.

“我想建议，在与HTTP工作组协调之后，我们将我们的HTTP文档重命名为‘HTTP/3’,马克·诺丁汉写道, IETF HTTP和QUIC工作组主席, 回到2018年末. 这样做可以清楚地将其标识为HTTP语义到连接协议的另一个绑定, 就像HTTP/2一样."

为什么QUIC?

正如我前面提到的，TCP作为IP传输协议已经使用了很长时间. 事实上, 因为TCP代表传输控制协议, 该术语经常与HTTP混淆使用.

有一点TCP做得不是很好, 但是——至少是时间敏感数据(如音频和视频流或交互式音频或视频会议)所需的亚秒级延迟——它可以足够快地解决错误，从而请求重新传输时间敏感数据. 如果你想想早期的网页, 文本首先呈现，内联图像(gif或jpg)缓慢生成, 在加载这些内联图像时，为纠正错误而增加的一到两秒钟是可以接受的消费者. 但是，对于实时、低延迟的视频传输，任何延迟都是不可接受的，而且效率非常低. 事实上, 对于像体育直播这样的场景, 许多TCP请求重传某些包最终是浪费时间, 作为视频帧的一部分，这些数据包在重新传输的数据包到达并立即被丢弃之前，早就被显示出来了——有时会出现错误.

QUIC背后的想法是在UDP的健壮性上建立一个“空间拥塞控制”，它理解HTTP/2交付系统的并行性(它本身是多路复用的，允许更快地交付更多的内容)。. 因为TCP的损失恢复机制甚至不能“看到”HTTP/2的多路复用, 这可能不仅仅是一个迟到的数据包. 事实上，HTTP/2和TCP结合在一起有风险在网页浏览器中拖延时间, 导致其他数据包无法发送到浏览器的连锁反应.

相比之下, 因为QUIC本身提供了本地多路复用, 丢包对其他数据流的影响不存在, 这意味着摊位不会像在TCP中那样在会话的各个部分(在TCP术语中)产生涟漪. 事实上, 因为UDP并没有会话的概念, 这个术语现在围绕着连接——以及对连接标识符的需求, 或cid，而不是会话.

对于那些有技术头脑的人，这里有一个很好的，简洁的描述能源科学网络可以把QUIC看作类似于在UDP上实现的TCP+TLS+HTTP/2."

QUIC在哪里实现?

新协议的缺点之一是，在它们成为事实上的标准之前，它们必须大规模实现. 例如, 超文本标记(“HTTP”中的“HT”)早在与web浏览器联系起来之前就已经存在了(参见 Vannevar 比如布什和罗伯特·海因莱因), 但直到1993年NCSA Mosaic出现，普通用户才可以访问超文本.

QUIC也是如此. 自从谷歌的罗斯金德创造了QUIC, 谷歌还开发了Chrome网络浏览器和Chrome操作系统, GQUIC支持在几年前就已经融入到Google web浏览器中，并且IETF的QUIC支持在最近几年才被添加进来，这并不奇怪.

超越铬和铬, 虽然, QUIC在许多主流网络浏览器中的应用正在激增. 至少在台式机和笔记本电脑上，所有主流浏览器都可以支持QUIC. 有些浏览器完全支持它，比如Chrome和微软的Edge浏览器. 其他人, 比如苹果的Safari和Mozilla的Firefox, 需要最新版本的浏览器，并通过命令行参数或启用开发人员设置来激活HTTP/3的功能图1).

快速浏览器兼容性

图1. QUIC在大多数主流网络浏览器中的应用正在激增, 如兼容性图表所示 caniuse.com/http3.

在移动设备方面, 虽然, 对于HTTP/3和QUIC的支持仍然很少，除了谷歌的Chrome for Android. 在机顶盒里, 奥特设备, 甚至在移动操作系统上专门的应用程序, 这种有限的可用性可能会减缓整体的采用.

我和我的搭档主持 SMAF每月网络直播在2021年7月与两家主要OTT公司的嘉宾讨论了这个话题. 虽然不是以官方身份发言, 两位嘉宾都指出，考虑到一些智能电视和OTT设备的局限性，实现HTTP/3支持OTT播放的步骤不仅需要关于通过HTTP/3支持哪些设备的技术决策, 他们中的许多可能缺乏处理能力或固件更新，但也要彻底了解添加HTTP/3是否会进一步分裂OTT市场.

尽管担心碎片化, QUIC提供了在应用层添加HTTP/3和修改QUIC的机会，这是TCP永远无法做到的. 因为TCP是在机器(操作系统)的最底层实现的, 路由固件)," 能源科学网络笔记, 考虑到需要进行的大量升级，对TCP进行更改几乎是不可能的. 因为QUIC是建立在UDP之上的, 它没有这样的限制，可以集成到终端主机应用程序中."

这种能力把QUIC, 甚至HTTP/3, 为流媒体提供商提供了一种方法，可以通过在应用程序中使用单个拨动开关来实现QUIC的好处. 这类似于今天的消费者可以在许多苹果iOS或谷歌Android设备上选择打开或关闭基于视频的应用程序使用蜂窝数据的方式.

QUIC的潜在缺点

两个主要问题, 一个处理延迟和加密，另一个处理基本的流量监控, 将UDP转换为基于会话或连接的解决方案.

“以减少启动时的延迟, 并加快对第一次接触的数据响应,罗斯金在他的论文中写道, 通过QUIC发送的第一个数据包通常包括会话协商信息以及一个或多个请求. QUIC被设计为推测性地假设客户机具有至少对请求进行初步加密所需的可接受的加密凭据."

然而，如果这种猜测被证明是错误的，会发生什么呢? ，如果服务器拒绝接受凭据,罗斯金写道, “额外的往返谈判, 与TCP会话建立相当, 或SSL hello协商, 可能接踵而来.如果你想知道TCP会话建立是否会增加相当多的延迟, 答案绝对是肯定的.

在大规模方面，交通管理问题成为一个潜在的不足. 在一个 2020年SANS研究院白皮书, Lee Decker指出，QUIC“缺乏关键信息安全工具(如Wireshark)的可见性, Zeek, Suricata, 和Snort.他接着解释说，这种缺乏可见性的原因部分是由于使用了较新的TLS版本(1.3而不是标准的1.2)也因为简单的事实，大多数安全工具不能很好地处理UDP流量嗅探.

“防御者处于不利地位，因为选择性阻挡QUIC并不总是可能的,德克尔写道。. “此外, 一些QUIC流量可能是合法的, 因此，直接阻止使用QUIC的端点可能会导致比它解决的问题更多的问题."

所以我们可以用QUIC流? 简短的回答是肯定的和否定的. 更长的答案取决于您正在使用的流式传输方法.

大多数传统的流协议都是基于HTTP的，但这意味着HTTP版本1.1.1和2. 到目前为止, 所有的HTTP解决方案——包括苹果的HTTP 在线直播 (HLS)和MPEG的Dynamic Adaptive Streaming over HTTP (DASH)——都没有更新到可以使用HTTP/3和QUIC.

另一方面, 最古老的流媒体协议, 实时传输协议(RTP), 其中就有一些比较现代的交互式视频解决方案, 比如WebRTC, 为基础, 是民主党固有的吗. 加上包含某种形式的纠错的解决方案, 比如SRT, 哪一个是用UDP设计的.

在所有这些中间是一个与RTP互补的协议:实时流协议(RTSP). 而RTP和RTSP是直接相关的, RTSP创建时能够同时使用TCP和UDP进行IP视频传输. 经常, RTSP将TCP用于会话控制，UDP用于暴力传输视频数据包. 这种组合已经为基于rtsp的音频和视频流解决方案提供了20多年的良好服务.

快到QUIC黄金时代了吗?

这给QUIC的崛起带来了一个有趣的可能性. 因为QUIC的主要设计堆栈在UDP之上, 但也可以选择退回到TCP来建立初始握手, 它的功能似乎与RTSP的功能大致相同, 至少从流媒体的角度来看是这样.

这是否意味着QUIC有可能取代RTSP作为底层流协议? 也许. 更有可能的情况是，QUIC和HTTP/3将被修改以理解RTSP流, 也许到了RTSP流被转换成HTTP/3流的地步，没有中间人的传输服务或直接的用户干预.

这样做, 虽然, IETF将需要解决另一个基本的路由问题:数据包分段或碎片. 这不是我们在基于http的流媒体解决方案中想到的那种简单的分割，它将视频片段打包. 而, 它是互联网路由器的基本组成部分，它可以自由地将单个数据包分成多个较小的数据包，以便更好地将整个数据包路由到不同的拥塞路径上.

罗斯金在他的论文中总结了这个问题, 提醒读者，UDP数据包没有TCP数据包中使用的相当大的头的开销——这是一件好事，因为它增加了可以在单个数据包中携带的音频或视频数据的有效载荷. 但, 他说，缺乏报头信息实际上会导致额外的问题:“当数据包在IP级别上被碎片化时, 初始数据包将继续保留UDP源和目标端口说明符, 以及刑事调查处, 但是后面的所有片段都没有这种识别信息. 重组的唯一方法就是 IP级别的“标识”字段，长度只有16位. 结果是, 如果同时传输的数据包超过(大致)2^16的平方根, 碰撞(以及重组失败)的可能性将会很大."

换句话说, 即使对时间敏感的音频或视频数据包都以及时的方式到达，对这些碎片数据包进行重新排序可能会给重新组装工作增加足够的延迟，从而失去时间优势, or, 更糟糕的是, 可能发生错误的重组.

错误组装的数据包将被身份验证哈希检测为乱码,罗斯金写道. 结果是, 重组错误不会导致比丢弃可能分片的数据包更严重的协议错误."

在刚刚发表的一篇文章中，有一些潜在的解决方案 IETF QUIC工作组的草案. 例如, 它说，如果一个数据流“不能成功完成”, QUIC允许应用程序突然终止(重置)该流并通信一个原因."

除了, 更多的工作正在围绕缓存HTTP/3数据包内容以及如何与PUSH_PROMISE HTTP帧(提议的HTTP/3协议的一部分)交互进行.

随着时间的推移，我将继续关注这个话题. 现在, 虽然, 值得考虑的是，从现在起一年后(2022年中到年底)，你的HTTP/3和QUIC策略将是什么样子。, 在接下来的几个月里，HTTP/3将在移动浏览器上推出.

[编者注:本文首次发表于七月/八月版 of 流媒体 杂志.]