4.3.3　快速UDP网络连接

HTTP是应用层协议而不是传输层协议，它的设计原本不应该过多地考虑底层的传输细节，从职责上讲，持久连接、多路复用、分块编码这些能力，已经或多或少超过了应用层的范畴。要从根本上改进HTTP，必须直接替换掉HTTP over TCP的根基，即TCP传输协议，这便是最新一代HTTP/3协议的设计重点。

推动替换TCP协议的先驱者并不是IETF，而是Google公司。目前，世界上只有Google公司具有这样的能力，这并不是因为Google的技术实力雄厚，而是由于它同时持有占浏览器市场70%份额的Chrome浏览器与占移动领域半壁江山的Android操作系统。

2013年，Google在它的服务器（如Google.com、YouTube.com等）及Chrome浏览器上同时启用了名为“快速UDP网络连接”（Quick UDP Internet Connection，QUIC）的全新传输协议。在2015年，Google将QUIC提交给IETF，并在IETF的推动下对QUIC进行重新规范化（为以示区别，业界习惯将此前的版本称为gQUIC，将规范化后的版本称为iQUIC），使其不仅能满足HTTP传输协议，日后还能支持SMTP、DNS、SSH、Telnet、NTP等多种其他上层协议。2018年末，IETF正式批准了HTTP over QUIC使用HTTP/3的版本号，将其确立为最新一代的互联网标准。

从名字上就能看出QUIC会以UDP协议为基础，而UDP协议没有丢包自动重传的特性，因此QUIC的可靠传输能力并不是由底层协议提供，而是完全由自己实现。由QUIC自己实现的好处是能对每个流做单独的控制，如果在一个流中发生错误，协议栈仍然可以独立地继续为其他流提供服务。这对提高易出错链路的性能非常有用，因为在大多数情况下，TCP协议接到数据包丢失或损坏通知之前，可能已经收到了大量的正确数据，但是在纠正错误之前，其他的正常请求都会等待甚至被重发，这也是在4.3.1节中笔者提到HTTP/2未能解决传输大文件慢的根本原因。

QUIC的另一个设计目标是面向移动设备的专门支持，由于以前TCP、UDP传输协议在设计时根本不可能设想到今天移动设备盛行的场景，因此肯定不会有任何专门的支持。QUIC在移动设备上的优势体现在网络切换时的响应速度上，譬如当移动设备在不同Wi-Fi热点之间切换，或者从Wi-Fi切换到移动网络时，如果使用TCP协议，现存的所有连接都必定会超时、中断，然后根据需要重新创建。这个过程会带来很高的延迟，因为超时和重新握手都需要大量时间。为此，QUIC提出了连接标识符的概念，该标识符可以唯一地标识客户端与服务器之间的连接，而无须依靠IP地址。这样，切换网络后，只需向服务端发送一个包含此标识符的数据包即可重用既有的连接，因为即使用户的IP地址发生变化，原始连接的连接标识符依然是有效的。

无论是TCP协议还是HTTP协议，都已经存在了数十年。它们在积累了大量用户的同时，也承载了很重的技术惯性，要使HTTP从TCP迁移走，即使由Google和IETF来推动依然不是一件容易的事情。一个最显著的问题是互联网基础设施中的许多中间设备，都只面向TCP协议去建造，仅对UDP提供很基础的支持，有的甚至完全阻止UDP的流量。因此，Google在Chromium的网络协议栈中同时启用了QUIC和传统TCP连接，并在QUIC连接失败时以零延迟回退到TCP连接，尽可能让用户无感知地扩大QUIC的使用面。

根据W3Techs的数据[1]，截至2020年10月，全球已有48.9%的网站支持HTTP/2协议，按照维基百科中的记录，这个数字在2019年6月时还只是36.5%。对于HTTP/3，今天也已经得到了7.2%的网站的支持。可以肯定地说，目前网络链路传输领域正处于新旧交替的时代，许多既有设备、程序、知识都会在未来几年时间里出现重大更新。

[1] 数据来源：https://w3techs.com/technologies/overview/site_element。