---

去年的这个时候，国内的网络环境开始普及和部署HTTP/2。一年之后，HTTP/2的普及率大幅提升，主要CDN厂商普及的广度和速度一直处于行业的前沿。甚至许多CDN供应商也在现场直播和一些HTTP场景中引入了QUIC。
QUIC上的HTTP/2是当前应用程序的唯一HTTP实现，它解决了传输层头阻塞的问题。那时，无论是通过TCP的HTTP/2还是通过QUIC（UDP）的HTTP/2，我们认为它是HTTP/2，但传输层使用的协议是不同的。这种略带模糊的模糊性在2018年11月成为历史：
在2018年10月28日的邮件列表讨论中，互联网工程任务组（IETF）HTTP和QUIC工作组主席马克诺丁汉提出了一个正式请求，将HTTP-over-QUIC重命名为HTTP/3，以“明确地将其识别为另一个绑定HTTP语义...让人们明白它与QUIC“不同”，在完成和发布草稿后，QUIC工作组继承到HTTP工作组。在接下来的讨论中，Mark Nottingham的提议被IETF成员接受，他们在2018年11月正式批准，将HTTP-over-QUIC识别为HTTP/3。
虽然看起来以前的HTTP/2比QUIC更改了它的名字（从我个人的角度来看，将它命名为HTTP/2.1可能更合适），但其背后是IETF对未来HTTP标准的态度和方向。也许几年后，这个名字的建立将使得理解其重要性变得更加重要。
HTTP上的HTTP/3和HTTP/2之间的区别
QUIC将成为通用的安全传输层协议
在此阶段，Google实施的QUIC与IETF实施的QUIC不兼容。 Google版本的QUIC只能用于HTTP/2，并且在协议级别对HTTP/2有一些强绑定。如QUIC帧映射HTTP/2帧。这导致许多制造商跟进QUIC，使得基于QUIC的HTTP/2基本上只能在谷歌自己的Chrome，Gmail和其他软件中使用，曾经引起业界唯一的“谷歌获得它的幻想。在加入IETF之后，很明显Google无法以这种方式发挥作用。 QUIC定位为通用安全传输层协议：
可以近似得到UDP上的QUIC将是TCP上TLS的下一代（或替代）。也就是说，QUIC将能够应用于任何应用层协议，但是将首先在HTTP中应用和验证当前阶段。
统一使用TLS 1.3作为安全协议
2018年，最终确定了几个重要的WEB标准，其中一个是RFC 8446 TLS 1.3。此标准对于减少延迟和改善用户体验非常重要，尤其是移动体验。虽然TLS 1.3和QUIC都可以实现0-RTT，从而减少延迟，但QUIC实现了一组安全协议。主要是因为当时没有发布TLS 1.3标准，QUIC需要一个安全协议：
QUIC加密协议是QUIC的一部分，它为连接提供传输安全性。 QUIC加密协议注定要死。它将来会被TLS 1.3取代，但是在TLS 1.3开始之前，QUIC需要加密协议。
如今，TLS 1.3标准已经发布，HTTP/3也包含在IETF中，因此QUIC也使用TLS 1.3作为其安全协议。谷歌在这些方面从来就不是一个小偷和墨水，就像它一样。
使用QHPACK标头压缩而不是HPACK
事实上，QPACK和HPACK在设计上非常相似。 QPACK主要是为了更好地适应QUIC。这也是Google从与HTTP/2的耦合中删除QUIC并完成IETF标准的必要步骤。
HTTP/3问题和挑战
UDP连接问题
由于易于理解的原因，几乎所有电信运营商都会“区分”UDP数据包。毕竟，历史上一些臭名昭着的DDoS攻击都是基于UDP的。中国某个城市的宽带直接禁止某些区域的非53端口UDP数据包，而其他运营商和IDC严格限制UDP，即使UDP没有被阻止。这不是很乐观，但我们相信随着标准的普及和推广，运营商将逐步改变对UDP流量的歧视策略。国外的情况会略好一些。根据谷歌的数据，他们部署的QUIC比例不到10％。QUIC不支持明文传输
对于用户来说，这是一个优点，而不是问题。这是国内内容审查环境的必要条件。但是，毕竟，QUIC基于TLS协议。国内HTTPS可以普及，QUIC的普及可能会更加乐观。
UDP消耗更多资源
在当前阶段，UDP消耗大量CPU资源并且处理缓慢。这是一个不争的事实，但我相信随着UDP应用程序的增加，内核和硬件优化将一直持续到达到或超过TCP的性能。由于QUIC是在应用层实现的，因此迭代速度更快，部署和更新难度更低，成本更低，并且TCP的协议刚性可以在一定程度上得到缓解。

• 上一篇: 蓝盟IT外包，元宇宙：四梁八柱是什么
  下一篇: WPA3中的“Dragonblood”缺陷允许恢复Wi-Fi密码

• 分享到：