HTTP/3就要来了，先看看我的解读

QUIC中虽然也有连接(Connection)，也基于IP和port建立，但它并不能直接与TCP的连接对应，也不同于HTTP/2中的连接。原因在于QUIC建立连接时既完成了经典的传输握手，又完成了加密握手——你可以认为这样分层责任不清晰，但它确实提升了效率。QUIC的连接与HTTP/2类似，一个物理连接也可以承载多个逻辑连接(也就是数据流)。但与HTTP/2不同的是，QUIC中的逻辑连接是彼此独立的，所以避免了TCP上出现的“逻辑连接甲丢包导致逻辑连接乙、丙、丁都需要重传”的情况。

QUIC连接的另一个特点是，每个连接都有一组连接ID。连接各端可以设定自己的连接ID，同时认可对方的连接ID。连接ID的作用在于从逻辑上标识当前连接。所以，如果用户的IP发生变化而连接ID没有变化，因为packet包含了网络ID标识符，所以只需要继续发送数据包就可以重新建立连接。而目前，如果用户的设备发生了网络切换，比如从Wi-Fi切换到4G，则所有连接都要断掉再重连。

如果你详细研究过HTTP/2，应当知道它的header压缩采用的HPACK，因为gzip做header压缩有安全性隐患。HTTP/3同样提供了header压缩，但不能直接沿用HPACK。原因在于，HPACK粗略来说就是一张动态表(dynamic table)，由request-response共同维护它，后续header中不会完整重复之前的条目，而是引用之前的条目，TCP的有序性保证了它一定是先修改再读取，也就是先编码再解码。

然而如果使用HPACK，多个流的顺序是无法保证的，这样会导致解析错误。QUIC的解决方案是QPACK，其原理很简单：所有的header必须通过同一数据流来传输，而且必须严格有序。但是这样一来，从HTTP 1.1开始就困扰HTTP已久的队头阻塞又出现了。因此，QUIC的长期目标之一就是解决header的队头阻塞问题。

做过在线升级的朋友都知道，在线升级中的一个必须成分是提供降级方案，以保证“退化”兼容。无论HTTP/2还是HTTP/3，都不能逃避这部分的工作量。HTTP/2虽然可以通过upgrade这个header来升级，但也有更简单的办法，就是在TLS握手时协商HTTP的版本，比如Nginx就有NPN(Nginx Protocol Negotiation)扩展，自动协商协议，并已经被IETF采纳，成为ALPN(Application Layer Protocol Negotiation)。

如果web server有这样的特性，应用服务代码就不必为兼容HTTP 1.1和HTTP/2做太多工作。但是，如果应用程序中使用了Push等新特性，还是免不了要做很多事情。在业界，Google、Youtube、Wikipedia等大厂早已经提供了完整服务，HTTP/2和HTTP 1.1无缝切换，客户端完全无感知，它们的经验值得参考。

与HTTP/2不同的是，HTTP/3中新定义了一个header，可以用来指示客户端“在另一个端口提供了专用的HTTP/3服务”。

Alt-Svc: h3=":20003"

这个header说明，在本主机的20003端口开启了HTTP/3的服务。所以，客户端之后可以尝试和这个端口建立纯粹的HTTP/3连接。

聊了这么多QUIC的好处之后，再谈谈它的问题，有些观点来自我个人，未必足够准确客观，欢迎讨论。

虽然QUIC有这么多好处，但可以看到，相比HTTP/2，它的改动相当大，所以问题也不会少。

第一个问题是与遗留的网络设备的兼容问题。

基于目前的应用情况，许多网络设备对TCP和UDP的策略相当固定，TCP限制在常用端口，而UDP大概只开放了53端口(DNS)。所以如果HTTP/3使用UDP，兼容性方面可能会有不少问题需要解决。

不过如果这个问题可以解决，未来大概不会再出现这种问题，因为HTTP/3的设计思想中已经为未来做了考虑，应用层和传输层职责严格隔离，避免再出现“传输层一看端口就知道应用层在干什么”的情况。

第二个问题是QUIC的性能问题。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!