自通过HTTP / 2标准以来已经过去了三年半： RFC 7540规范于2015年5月发布，但尚未在所有地方使用。 自2015年底以来，该协议已在所有浏览器中实现，三年后，在1000万个最受欢迎的Internet网站中，只有31.2％支持HTTP / 2。 在最受欢迎的网站中，Google，Youtube，Wikipedia，Twitter，Vk.com等已切换到该网站。

但是，进展不会停滞不前-下一版HTTP / 3的工作已经在进行中。 众所周知 ，两个备选方案的开发人员已经实现了兼容性，并且HTTP-over-QUIC协议现在更改了名称，并正式称为 HTTP / 3 。 因此，在HTTP的未来版本中，TCP传输将被QUIC取代。

混淆了不同的QUIC选项

QUIC是可在UDP之上工作的TCP替代产品。 最初，这项技术是由Google工程师创建的，就像以前的SPDY协议一样，该协议成为HTTP / 2的基础。 最初，QUIC被称为“ HTTP / 2-encrypted-over-UDP”。

然后，QUIC开发被转移到IETF进行标准化。 这里分为两部分：传输和HTTP。 这个想法是，传输协议还可以用于传输其他数据，而不仅限于HTTP或类似HTTP的协议。 但是，名称保持不变：QUIC。 传输协议由Internet工程理事会（IETF）的QUIC工作组开发。

同时，Google继续致力于自己的实施-并在Chrome浏览器中实施了该实施。 尽管测试表明，如果网络不能保证数据包的传送，则Google的QUIC实施要明显比TCP差 。


在RTT为112毫秒，抖动为10毫秒的网络上，QUIC与TCP之间的性能差异（百分比）


RTT为112毫秒且抖动为10毫秒的网络上QUIC与TCP之间的性能差异（百分比），这会改变数据包的顺序， 源

一些开发人员通常将 UDP的QUIC的任何版本称为“最疯狂的实验” 。

Mozilla首席curl开发人员Daniel Stenberg 解释了 QUIC版本和命名中的矛盾，他一直在关注这个故事很长时间。

据他介绍，两个版本的QUIC的非正式名称已经在开发人员中广泛使用，因为IETF和Google的选择在实现细节上有很大不同：

• iQUIC（IETF版本）
• gQUIC（Google版本）

通过iQUIC（IETF版本）发送HTTP的协议一直被称为“ hq”（HTTP-QUIC）。

通常，没有为不同版本建立的名称。 在QUIC Workshop研讨会上，迈克·毕晓普（Mike Bishop）用像徽标一样的幻灯片吓everyone了所有人。


迈克·毕晓普演讲的幻灯片

研讨会的主持人要求迈克不再展示它 。

但是，2018年11月7日，该协议的主要开发者之一Dmitry Tikhonov 宣布 LiteSpeed Tech和Facebook已经实现了协议兼容性，现在开发将沿同样的方向进行。

马克诺丁汉（ Mark Nottingham）于9月将iQUIC和称为HTTP / 3的gQUIC组合在一起，他是最具影响力的IETF工程师之一，是多种Web标准的合著者。 据他介绍，这将有助于消除QIUC传输和HTTP的QUIC包装器之间的混淆。

因此， HTTP / 3是将使用QUIC transport的HTTP的新版本 。

QUIC运输

QUIC传输协议相对于TCP有什么优势？ 有很多优点，根据Mark Nottingham自己的看法，从过时的TCP过渡到新协议是不可避免的，因为现在很明显TCP效率低下。

“由于TCP按顺序是一种数据包传送协议，因此丢失一个数据包可能会干扰随后的数据包从缓冲区到应用程序的传送。 在多路协议中，这会导致性能上的巨大损失。” Mark Nottingham 解释道 。 “ QUIC试图通过有效地重建基于UDP的TCP（以及HTTP / 2流模型的某些方面）的语义来解决此问题。”



除了将大量流量从TCP切换到UDP之外，Google QUIC（gQUIC）和IETF QUIC（iQUIC）都需要强制加密：根本没有未加密的QUIC 。 iQUIC使用TLS 1.3设置会话密钥，然后加密每个数据包。 但是，由于它基于UDP，因此许多在TCP中打开的会话信息和元数据都在QUIC中进行了加密。

在文章“ Internet协议的未来”中， Mark Nottingham谈到了转向QUIC带来的重大安全性改进：

实际上，当前的“短头” iQUIC（用于除握手之外的所有数据包）仅给出数据包编号，可选的连接标识符和状态字节，这对于更改加密密钥和数据包类型（也可以被加密）是必需的。 其他所有内容都经过加密-包括ACK数据包，极大地提高了流量分析攻击的门槛。

另外，仅通过监视连接就无法被动地评估RTT和数据包丢失。 没有足够的信息。

可观察性的缺乏引起了电信运营商社区的一些代表的严重关注。 他们说，这种被动测量对于调试和分析其网络至关重要。

解决此问题的建议之一是引入自旋钻头 。 标头中的此位在往返中一次更改了其值，以便观察者可以评估RTT。 由于它不依赖于应用程序的状态，因此，除了网络位置的近似估算值之外，它不应生成任何有关端点的信息。

如果Google不急于在Chrome浏览器中实现其实现，那么QUIC标准的采用可能会更早实现，因此，现在iQUIC的专有版本已占Internet流量的7％以上。

尽管如此，取得进展是不可避免的，并且在未来几年中，各种新一代协议（包括基于QUIC传输的HTTP / 3）的标准化和广泛实施必将继续。

---