虽然HTTP/3规范仍处于起草阶段，但最新版本的Chrome浏览器已经默认支持它了。Chrome拥有约70％的浏览器市场份额，所以，可以说HTTP/3已经进入主流世界。
这一基础协议的最新修订版旨在让Web更加高效、安全并缩短内容交付延迟。从某些角度来说，它是HTTP2的完善：通过使用新的专用协议QUIC替换基础TCP协议来解决和之前类似的目标。
想要弄明白QUIC的优点，最好的办法是讲清楚TCP作为HTTP请求的传输方式有哪些不足之处。
为此，我们将从头开始细细道来。
1HTTP：起源年，当蒂姆·伯纳斯·李爵士设计出一个简单的单行超文本交换协议时，TCP已经是一个古老而可靠的协议了。前者的原始定义文档（也就是后人熟知的HTTP0.9）特别提到TCP是首选的（尽管并非唯一的）传输协议：
注意：HTTP当前运行在TCP上，但也可以运行在任何面向连接的服务上。
当然，HTTP的这个概念验证版本与我们现在所知道和喜欢的HTTP几乎没有相似之处。没有标头，也没有状态码。典型的请求只有GET/path而已。响应仅包含HTML，且TCP连接关闭就会结束。
由于浏览器尚未流行，因此用户需要直接阅读HTML。可以用它链接到其他资源，但是在这个HTML早期版本中存在的所有标签都不会异步请求其他资源。一个HTTP请求就传递了一个完整的、自给自足的页面。
2HTTP/1.0出现在随后几年中，互联网迎来爆炸式的发展，尽管传输HTML仍然是HTTP的主要特色，但它逐渐发展成一种可扩展且灵活的通用协议。HTTP的三大重要更新奠定了这一演变的基础：
方法的引入使客户能确定其想要执行操作的类型。例如，引入POST是为了允许客户端将数据发送到服务器以处理和存储；
状态码为客户端提供了一种确认服务器已成功处理请求的方法——如果处理失败，则可以用它了解发生了哪种错误；
标头增加了将结构化文本元数据附加到可以修改客户端或服务器行为的请求和响应上的功能。例如，编码和内容类型头使HTTP不仅可以传输HTML，还可以传输任何类型的负载。“压缩”标头允许客户端和服务器协商支持的压缩格式，从而减少了通过连接传输的数据量。
同时，HTML也不断进化，支持了图像、样式和其他链接资源。
现在，浏览器需要执行多个请求来显示一个网页，而原始的“按请求连接”架构是做不到的。建立和终止TCP连接涉及大量的数据包来回交换，因此在延迟开销方面相对昂贵。网页不见得一定由单个文本文件组成，但是随着每页请求数量的增加，延迟也随之增加。
下图说明了每建立一个新的TCP连接涉及多少请求开销。
TCP连接需要三个请求才能建立连接，四个请求可以完全关闭
人们创建了一个“连接”标头来解决这个问题。客户端发送带有“connection:keep-alive”标头的请求，以表明意图为后续请求保持TCP连接的打开状态。如果服务器理解此标头并同意遵守该标头，则其响应还将包含“connection:keep-alive”标头。
这样，双方都保持TCP通道打开并使用它进行后续通信，直到任何一方决定关闭它为止。随着SSL/TLS加密技术的发展，这一点变得更加重要，因为协商加密算法和交换加密密钥需要在每个连接上增加一个请求/响应周期。
单个TCP连接可以通过“connection:keep-alive”标头重用于多个请求
当时，许多HTTP改进都是自发出现的。当流行的浏览器或服务器应用程序需要新的HTTP功能时，它们会自己实现该功能，并希望其他各方也能效仿。具有讽刺意味的是，去中心化的Web需要一个中心化的管理机构来避免碎片化造成的不兼容问题。
该协议的最初创建者蒂姆·伯纳斯·李（TimBerners-Lee）意识到了这种危险，并于年成立了万维网联盟（W3C），该联盟与互联网工程任务组（IETF）一起致力于规范互联网的技术栈。作为为已有环境带来更多规范的第一步，他们记录了当时HTTP中最常用的一些功能，并将其命名为HTTP/1.0协议。
但是，由于这种“规范”描述的是多种多样的，通常在“实践”中用法不一致的技术，因此它从未获得过标准地位。相比之下，关于HTTP协议新版本的工作已经开始了。
3HTTP/1.1的标准化HTTP/1.1修复了HTTP/1.0的不一致之处，并调整了协议，使其在新的Web生态系统中具备更好的性能表现。新版引入的两个最关键的更改是默认使用持久TCP连接（保持活动状态）和HTTP管线化。
HTTP管线化的意思就是客户端无需在发送后续HTTP请求之前等待服务器响应请求。此功能可以更有效地利用带宽并减少延迟，但它的改进空间甚至更大。HTTP管线化仍要求服务器按照接收到的请求顺序进行响应，因此，如果管线化中的单个请求执行得很慢，则对客户端的所有后续响应都将相应地延迟下去。这个问题被称为线头阻塞。
由于首先请求了large-pictu.jpg，因此阻止了style.css的发布
在这个时候，Web正在获得越来越多的交互功能。Web2.0指日可待，一些网页包含数十个甚至数百个外部资源。为解决线头阻塞，并降低页面加载速度，客户端会在每个主机上建立多个TCP连接。当然，连接开销并没有消失不见。实际上情况变得更糟了，因为越来越多的应用程序开始使用SSL/TLS加密HTTP通信。因此，大多数浏览器都设置了最大可能同时连接数的限制，以寻求微妙的平衡。
许多较大的Web服务已经意识到，现有的限制对于其交互极为繁重的Web应用程序来说太过严格，因此它们会通过多个域名分发其应用程序来“玩弄系统”。这种办法好歹起效了，但是解决方案根本谈不上优雅。
尽管存在一些缺点，但是HTTP/1.0和HTTP/1.1的简单性使它们获得了广泛的成功，并且十多年来，没有人认真地尝试过改变它们。
4SPDY和HTTP/2谷歌在年发布了Chrome浏览器，这种浏览器因其快速和创新而迅速流行。它使谷歌在互联网技术问题上获得了强大的话语权。在年代初期，谷歌在Chrome中增加了对其Web协议SPDY的支持。
HTTP/2标准基于SPDY，并进行了一些改进。HTTP/2通过在单个打开的TCP连接上多路复用HTTP请求，解决了线头阻塞问题。这允许服务器以任何顺序响应请求，然后客户端可以在接收到响应时重新组合响应，从而在单个连接中加快整个交换的速度。
由于HTTP/2可以多路传输，因此在large-pictu.jpg之前返回了style.css
实际上，使用HTTP/2服务器甚至可以在请求之前就将资源提供给客户端！举个例子，如果服务器知道客户端很可能需要样式表来显示HTML页面，它可以将CSS“推”到客户端，而无需等待相应的请求。虽然这从理论上讲是有益的，但此功能在实践中很少见，因为它需要服务器了解其服务的HTML结构，但这种情况很少发生。
除了请求正文以外，HTTP/2还允许压缩请求标头，这进一步减少了通过网络传输的数据量。
HTTP/2解决了Web上的许多问题，但不是全部。在TCP协议级别上仍然存在类似类型的线头问题，而TCP仍然是Web的基础构建块。当TCP数据包在传输过程中丢失时，在服务器重新发送丢失的数据包之前，接收方无法确认传入的数据包。由于TCP在设计上不遵循HTTP之类的高级协议，因此单个丢失的数据包将阻塞所有进行中的HTTP请求的流，直到重新发送丢失的数据为止。这个问题在不可靠的连接上尤为突出，这在无处不在的移动设备时代并不罕见。
5HTTP/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协议的所有现有实现当前都在用户空间，而不是OS内核中运行。由于客户端（例如浏览器）和服务器的更新通常比操作系统内核更新的频率更高，因此人们希望可以藉此更快地采用新功能。
6HTTP/3存在的问题我认为HTTP/3标准虽然是向更快、更安全的互联网迈出的一大步，但它并不完美。它的某些问题是由其新颖性引起的，而其他一些问题似乎是该协议固有的。
TCP协议已经存在了很长时间，对于路由器来说很容易理解。它具有清晰的未加密标记（用于建立和关闭连接），可用于跟踪和控制现有会话。在网络硬件学会了解新协议之前，它将把QUIC流量简单地看作独立的UDP数据包流，这将使网络配置更加棘手。
从客户端缓存“恢复”连接的能力使该协议很容易遭受重播攻击：在某些情况下，恶意攻击者可以重新发送以前捕获的数据包，这些数据包将被服务器解释为有效的，来自受害者的。像那些提供静态内容的Web服务器一样，许多Web服务器不会受到此类攻击的伤害。对于身处易受攻击环境的应用程序来说，必须要记住禁用0-RTT功能。
这就是HTTP到今天为止的故事。我认为HTTP/3是向前迈出的一大步，并且当然希望HTTP/3在不久的将来会被广泛采用。
后台回复学习资料领取学习视频
如有收获，点个在看，诚挚感谢
预览时标签不可点收录于话题#个上一篇下一篇