标准化进展情况

QUIC工作组自2016年底以来在积极标准化该协议,现计划于2019年7月之前完成。

到2018年11月为止,还没有过大型的HTTP/3互通性测试。目前来说,只有2个实现进行过测试,且这两个实现不基于浏览器和主流的开源服务器软件。

QUIC工作组的wiki页面目前列出了大约15种QUIC实现(QUIC实现列表),但距离它们都能与最新版的规范草案互操作仍有很长的路。

实现QUIC并不容易,且到目前为止,协议本身还在不断演变。

服务器

Apache和Nginx还没有对QUIC支持的公开声明。

客户端

还没有任何主流浏览器的任何状态的任何版本支持IETF版本的QUIC或者HTTP/3协议。

Google Chrome在数年前已经支持Google版的QUIC,但是该版本不能与官方的QUIC版本互操作,且它的HTTP实现与HTTP/3不同。

实现的障碍

为了避免重复发明轮子,以及依靠可信赖的现有协议,QUIC决定使用TLS 1.3作为它的加密和安全协议层。不过工作组决定大幅精简QUIC中TLS的使用,只使用“TLS信息”(TLS Messages)而不是协议中的“TLS记录”(TLS Records)。

这听上去可能人畜无害,但也事实上成为了很多QUIC堆栈实现者的重大障碍。现存的支持TLS 1.3的TLS库都没有提供此功能的API并允许QUIC访问它。有一些QUIC的实现由大型机构完成,这些机构可能有自己的TLS协议栈,但并不是所有实现都能如此。

例如,主流的重量级开源软件OpenSSL就没有这些API,且到目前(2018年11月)为止,没有表达过在任何时间点提供这些API的意愿。

这最终将成为QUIC协议栈部署的障碍。因为QUIC要么基于其他TLS库,要么使用补丁版OpenSSL或者等待OpenSSL版本更新。

操作系统内核、CPU负载

据Google和Facebook称,与基于TLS的HTTP/2相比,它们大规模部署的QUIC需要近2倍的CPU使用量。

对此的进一步解释包括:

  • Linux内核的UDP部分没有得到像TCP堆栈那样的优化,因为传统上没有使用UDP进行如此高速的信息传输。

  • TCP和TLS有硬件加速(负载卸载到硬件,offload),而这对于UDP很罕见,对于QUIC则基本不存在。

就上述理由,我们可以相信QUIC的CPU使用量能随着时间的推移得到改善。