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