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

然而技术的发展总是让人目不暇接，2018年10月，HTTP/3又发布了。虽然已经有一些中文技术媒体做了报道，但大多数是翻译的，而且内容大同小异。最近我专门学习了点关于HTTP/3的知识，在这里随便写写，和大家做个分享。

先简单回顾一下HTTP/2吧。自从1999年HTTP 1.1发布之后，Web一直在迅猛发展，可惜HTTP协议一直没有更新。等不及的Google自己搞了个SPDY(读音是“speedy”)，并依靠Chrome浏览器大肆推广。看到SPDY的效果确实很好(可以带来近50%的性能提升)，IETF推动制定了HTTP/2。 SPDY和HTTP/2的主要特性展示如下

如今HTTP/2已经不新鲜了，根据2019年2月对访问量最大的1000万个网站的统计，33.5%已经支持HTTP/2。在国内，如果你打开浏览器看看调试模式，会发现各大厂已经广泛使用HTTP/2，尤其是放置css、js、图片的资源站，HTTP/2基本是标配。这也很好理解，基本什么都不用做，就可以直接享受多路复用带来的好处，何乐而不为?

在传统HTTP中，概念模型非常简单：下层TCP通讯与上层HTTP完全不搭架，但TTP与TCP的“连接”是重合的，TCP传输的单位是packet，HTTP则采用request-response的模型。

在HTTP/2中，概念模型有所变化，HTTP/2中传输的基本单位是帧(frame)。与HTTP 1.1的明文传输不同的是，HTTP/2的帧是二进制的，同时TCP承载的“逻辑连接”叫数据流(stream)，所有的状态流转、流控、优先级等等特性都是在数据流上实现的。HTTP/2中为大家所津津乐道的“多路复用”，简单说就是把数据流分解为多个帧，多个数据流的帧混合之后以同一个TCP连接来发送。

值得注意的是，HTTP有1.0和1.1的区分，所以写作HTTP 1.0，HTTP 1.1，但HTTP/2不会有其它小版本，所以不要写作HTTP 2.0，而应当写成HTTP/2。

虽然HTTP/2已经带来了巨大的性能提升，但大家对性能的渴求是没有止境的。在应用层的许多问题解决之后，下一个优化的重点就是传输层了。无论SPDY还是HTTP/2，传输层协议都是TCP，TCP有一些娘胎里带来的问题，比如慢启动，如果拥塞窗口尺寸设置不合理，TCP的性能会急剧下降。关于这个问题，网络上已经有许多讨论，这里不赘述。

另一个重要问题是，HTTP/2的多路复用带来的效果并不如想象的那么好。虽然HTTP/2中的传输连接可以多路复用，但仍然无法避免队头阻塞的情况出现。因为TCP是需要保证有序的，假如单个TCP连接同时承载了四路逻辑连接，其中某个逻辑连接丢包了，则其它三路都会受影响，都必须从丢包的时刻开始重传，这无疑是极大的浪费。测试表明，如果丢包率超过2%，那么HTTP/2甚至不如HTTP 1.1，因为HTTP 1.1中各连接物理隔离，不会互相影响。

所以思路自然就是“改掉TCP的这些毛病”。考虑到现实中已经有成千上万的网络设备，它们只能识别TCP和UDP，软件不会进化，如果更新TCP协议当然不可行——虽然2014年12月发布了TCP的Fast Open，但现实应用中的情况并不让人满意。因此，可用的只有UDP了。对了，还有人考虑过SCTP，但SCTP在队头阻塞、TLS、四次握手等方面仍然存在缺陷，尚不能让人满意。

大概有人听过QUIC(读音quick)，知道它是基于UDP的HTTP，也知道它依然是Google最先提出来的。确实，上次是Google率先搞出了SPDY，这次Google又率先搞出了QUIC。根据Google本意，QUIC是把传统的HTTP/TCP/IP协议栈中的TCP换成UDP(当然需要加密)，能通过加密的UDP传输HTTP/2的帧。

按照Google的说法，这样的好处很多，比如UDP建立连接的延迟会低很多，而且避免了队头阻塞。除此之外，Google还提供了一个非常诱人的特性FEC(Forward Error Correction)。简单说，它想做到的是，一旦有packet丢失，接收方可以根据之前和之后的packet推断出丢失packet的数据，这样就避免了重传。但是这样必然要求增加冗余载荷，或者说，这就是网络协议中的RAID 5。按照目前看到的资料，其冗余比例大概是10%，也就是说，每10个pakcet中的冗余信息，就可以重构一个packet。

尽管Google的QUIC很先进，但QUIC不止这一家，IETF也有QUIC，如今已经改名HTTP/3，所以Google的QUIC有时候也写作gQUIC。与Google单纯在传输层动手，应用层基本沿用HTTP/2不同，IETF的QUIC是一个混合方案，既包括传输层的改动，也包括HTTP层的改动(比如全新的头部压缩)。从另一个角度来说，它更“完整”。虽然理论上QUIC也可以支持HTTP之外的其它上层应用，但目前这只是计划而已，第一版QUIC并不包含这方面内容。

在2018年11月，IETF正式宣布，HTTP-over-QUIC更名为HTTP/3。

本文讨论的是IETF版本的QUIC，Google已经宣布，会逐步把IETF的规范纳入自己的协议版本，实现相同的规范。

虽然TCP有各种问题，但换成UDP的话，TCP的不少功能也需要原样移植过来。许多人都知道，TCP是可靠的传输协议，而UDP是不可靠的。HTTP/3当然不能不可靠，所以它必须自己实现有序性、错误侦测、重传、拥塞控制、传输节奏调整等等特性。

HTTP/2“似乎”必须用到HTTPS，但规范并不强求HTTP/2使用HTTPS，也就是说，如果你用HTTP来跑HTTP/2，理论上也是可以成立的，虽然这有点怪异。

与此相反，QUIC的所有连接都是加密的，目前采用的是TLS 1.3。如果你仔细观察上面的图就会发现，TLS 1.3是“囊括”在QUIC当中的，也就是说，QUIC建立连接的握手过程当中就同时完成了加密握手。HTTP/3的握手很快，如果两台主机之间建立过连接，并且缓存了之前的secret，只要客户端验证之前缓存的server config就可以直接建立连接，相当于0-RTT，否则也只需要1-RTT就可以建立连接。此外，QUIC还容许在0-RTT的情况下从一开始就捎带数据，传统的“建立连接-加密握手-发送数据”如今可以三步并作一步(这个0-RTT和1-RTT的实现都非常有意思，有兴趣的话应当找资料来看看)。

（编辑：东莞站长网）

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