通往HTTP/3的漫漫长路
虽然HTTP/3规范还在起草阶段，但最新版本的Chrome浏览器已经默认支持它。Chrome占据了大约70%的浏览器市场份额，可以说HTTP/3已经成为主流。
这一基本协议的新修订旨在使网络更高效、更安全，并缩短内容交付延迟。在某些方面，这是对HTTP2的大胆尝试：通过用新的、专门构建的协议Quic替换底层TCP协议来实现类似的目标。解释Quic好处的最好方法是说明TCP作为HTTP请求传输的不足之处。要做到这一点，我们将从头开始。
1991年，当Tim Berners-Lee爵士正式设计了一个简单的单行超文本交换协议时，TCP已经是一个古老、可靠的协议。后来被称为HTTP 0.9的原始定义文档特别提到TCP是首选的(尽管不是唯一的)传输协议：
当然，这个概念验证版本的HTTP与我们今天所了解和喜爱的HTTP几乎没有相似之处。没有标头，也没有状态代码。典型的请求就像GET/PATH一样简单。响应只包含HTML，并以关闭TCP连接结束，因为浏览器还没有出现，用户应该直接阅读HTML。可以链接到其他资源，但是这个早期版本的HTML中没有一个标记异步请求额外的资源。单个HTTP请求提供了一个完整的、自给自足的页面。
在接下来的几年里，互联网呈爆炸式增长，HTTP发展成为一种可扩展和灵活的通用协议，尽管传输HTML仍然是它的主要专长。HTTP有三个关键更新实现了这一演变：
方法的引入允许客户端识别它想要执行的操作类型。例如，创建POST是为了允许客户端将数据发送到服务器进行处理和存储。
状态代码为客户端提供了一种方式，用于确认服务器已成功处理请求，如果未成功，则可了解发生了哪种错误。
Header添加了将结构化文本元数据附加到请求和响应的功能，这些请求和响应可能会修改客户端或服务器的行为。例如，编码和内容类型的报头不仅允许HTTP传输HTML，还允许传输任何类型的有效负载。“Compression”标头允许客户端和服务器协商支持的压缩格式，从而减少通过连接传输的数据量
同时，HTML高级支持图像、样式和其他链接资源。浏览器现在被迫执行多个请求才能显示单个网页，而最初的按请求连接架构不能处理这一点。建立和结束TCP连接涉及大量来回分组交换，因此延迟开销相对较高。当网页由单个文本文件组成时，这并不重要，但是随着每页请求数量的增加，延迟也随之增加。
下图说明了为每个请求建立新的TCP连接所涉及的开销。
创建了一个“Connection”标头来解决此问题。客户端发送带有“Connection：Keep-Alive”报头的请求，以表示有意保持TCP连接打开以供后续请求使用。如果服务器理解此标头并同意尊重它，则其响应也将包含“Connection：Keep-Alive”标头。这样，双方都保持TCP通道打开，并将其用于后续通信，直到任何一方决定关闭它。随着SSL/TLS加密的普及，这一点变得更加重要，因为协商加密算法和交换密钥需要在每个连接上进行额外的请求/响应周期。
当时，许多HTTP改进都是自发出现的。当流行的浏览器或服务器应用程序发现需要新的HTTP功能时，他们会简单地自己实现，并希望其他方也能效仿。具有讽刺意味的是，一个分散的网络需要一个集中的管理机构，以避免分裂成不兼容的部分。该协议的最初创建者Tim Berners-Lee认识到了这种危险，并在1994年成立了万维网联盟(W3C)，该联盟与互联网工程任务组(IETF)一起致力于使互联网技术栈正规化。作为给现有环境带来更多结构的第一步，他们记录了当时在HTTP中使用的最常见的特性，并将产生的协议命名为HTTP/1.0。然而，因为这个“规范”描述了各种各样的、经常不一致的技术，就像“在野外”看到的那样，它从未获得过标准的地位。相反，新版本的HTTP协议的工作已经开始。
HTTP/1.1修复了HTTP/1.0的不一致性，并调整了协议，使其在新的Web生态系统中性能更佳。引入的两个最关键的更改是默认情况下使用持久TCP连接(Keep-Alive)和HTTP管道。
HTTP管道只是意味着客户端在发送后续HTTP请求之前不需要等待服务器响应请求。此功能可以更高效地使用带宽并减少延迟，但还可以进一步改进。HTTP流水线仍然要求服务器按照接收到的请求顺序进行响应，因此如果流水线中的单个请求完成速度较慢，则对客户端的所有后续响应都将相应延迟。此问题称为队头阻塞。
在这个时间点上，网络获得了越来越多的交互功能。Web2.0即将到来，一些网页包含数十甚至数百个外部资源。为了避免队头阻塞并降低页面加载速度，客户端需要在每个主机上建立多个TCP连接。当然，连接开销从未发挥作用。实际上，情况变得更糟了，因为越来越多的应用程序使用SSL/TLS加密HTTP流量。因此，大多数浏览器都设置了最大可能同时连接的限制，试图达到微妙的平衡。
许多较大的网络服务已经认识到，现有的限制对于它们异常繁重的交互式网络应用程序来说太有限了，所以他们通过通过多个域名分发应用程序来“玩弄系统”。不知何故，这一切都奏效了，但解决方案远非完美。
尽管有一些缺点，但HTTP/1.0和HTTP/1.1的简单性使它们获得了广泛的成功，十多年来没有人认真尝试改变它们。
2008年，谷歌发布了Chrome浏览器，这款浏览器因其快速和创新而迅速流行起来。它让谷歌在互联网技术问题上投下了强有力的一票。在2010年代初，谷歌在Chrome上增加了对其网络协议SPDY的支持。
HTTP/2标准是在SPDY的基础上做了一些改进。HTTP/2通过在单个开放的TCP连接上多路复用HTTP请求，解决了队头阻塞问题。这允许服务器以任何顺序响应请求，然后客户端可以在接收到响应时重新组装响应，从而在单个连接中使整个交换速度更快。
事实上，使用HTTP/2，服务器甚至可以在客户端请求资源之前就将资源提供给客户端！举个例子，如果服务器知道客户端很可能需要样式表来显示HTML页面，它可以将CSS“推送”到客户端，而无需等待相应的请求。虽然在理论上是有益的，但这一特性在实践中很少见，因为它需要服务器理解它所服务的HTML的结构，而这种情况很少发生。
除了请求正文之外，HTTP/2还允许压缩请求头，这进一步减少了通过线路传输的数据量。
HTTP/2为Web解决了很多问题，但不是全部。TCP协议层仍然存在类似类型的队头问题，它仍然是Web的基础构建块。当TCP数据包在传输过程中丢失时，在服务器重新发送丢失的数据包之前，接收方无法确认传入的数据包。由于TCP在设计上不受更高级别的协议(如HTTP)的影响，因此单个丢失的数据包将阻塞所有正在传输的HTTP请求的流，直到丢失的数据被重新发送。这个问题在不可靠的连接上尤为突出，在移动设备无处不在的时代，这并不罕见。
由于HTTP/2的问题不能完全在应用层解决，因此协议的新迭代必须更新传输层。但是，创建新的传输层协议并非易事。传输协议需要得到硬件供应商的支持，并由大多数网络运营商部署，但由于涉及的成本和努力，这些运营商不愿更新。以IPv6为例：它是24年前推出的，还远远没有得到普遍支持。
幸运的是，还有另一个选择。UDP协议与TCP一样受到广泛支持，但它足够简单，可以作为在其上运行的自定义协议的构建块。UDP数据包是即发即忘：没有握手、持久连接或纠错。HTTP3背后的主要思想是放弃TCP，转而采用基于UDP的Quic协议。Quic以一种对Web环境有意义的方式添加了必要的功能(那些以前由TCP提供的功能，以及更多)。
与HTTP2不同，HTTP2在技术上允许未加密的通信，而Quic严格要求加密才能建立连接。此外，加密应用于流经该连接的所有数据，而不仅仅是HTTP有效负载，从而避免了整个类别的安全问题。在Quic中，建立持久连接、协商加密协议，甚至发送第一批数据都合并到单个请求/响应周期中，从而显著降低了连接延迟。如果客户端具有本地缓存的加密参数，则可以使用简化的握手(0-RTT)重新建立到已知主机的连接。
为了解决传输级的队头阻塞问题，通过Quic连接传输的数据被分成多个流。流是持久的Quic连接中短暂的、独立的“子连接”。每个流处理其自己的纠错和传送保证，但使用连接全局压缩和加密属性。每个客户端发起的HTTP请求都在单独的流上操作，因此丢失一个数据包不会影响其他流/请求的数据传输。
UDP是一种无状态协议(持久连接只是其上的抽象)，使Quic能够支持在很大程度上忽略了数据包传递复杂性的功能。例如，客户端在连接过程中更改其IP地址(就像智能手机从移动网络跳到家庭WiFi一样)理论上不应该中断连接，因为该协议允许在不同IP地址之间迁移，而无需重新连接。
目前，Quic协议的所有现有实现都运行在用户空间中，而不是操作系统内核中。由于客户端(例如浏览器)和服务器的更新通常都比操作系统内核更频繁，因此这有望更快地采用新功能。
虽然HTTP/3标准，在我看来，是迈向更快更安全的互联网的一大步，但它并不完美。它的一些问题是由其新颖性引起的，而另一些问题似乎是该议定书固有的。
TCP协议由来已久，路由器很容易理解。它具有清晰的未加密标记，用于建立和关闭连接，可用于跟踪和控制现有会话。在网络硬件学会理解新协议之前，它将把Quic流量简单地视为独立的UDP数据包流，这将使网络配置变得复杂得多。
从客户端缓存“恢复”连接的能力使协议容易受到重播攻击：在某些情况下，恶意攻击者可以重新发送以前捕获的数据包，这些数据包将被服务器解释为有效的，并且来自受害者。许多Web服务器，就像那些提供静态内容的服务器一样，不会受到这样的攻击的损害。攻击场景有效的应用程序必须记住禁用0-RTT功能。
到目前为止，这就是HTTP的故事。我认为HTTP/3是向前迈出的一大步，当然希望HTTP/3能在不久的将来得到广泛采用。
