协议|从HTTP到HTTP/3的发展简史 html|蒂姆|tcp|标头|发展

作者 | Scorpil
译者 | 王强
策划 | 万佳
虽然 HTTP/3 规范仍处于起草阶段，但最新版本的 Chrome 浏览器已经默认支持它了。Chrome 拥有约 70％的浏览器市场份额，所以，可以说 HTTP/3 已经进入主流世界。

文章插图
这一基础协议的最新修订版旨在让 Web 更加高效、安全并缩短内容交付延迟。从某些角度来说，它是 HTTP2 的完善：通过使用新的专用协议 QUIC 替换基础 TCP 协议来解决和之前类似的目标。
想要弄明白 QUIC 的优点，最好的办法是讲清楚 TCP 作为 HTTP 请求的传输方式有哪些不足之处。
为此，我们将从头开始细细道来。
1
HTTP：起源
1991 年，当蒂姆·伯纳斯·李爵士设计出一个简单的单行超文本交换协议时，TCP 已经是一个古老而可靠的协议了。前者的原始定义文档（也就是后人熟知的 HTTP 0.9）特别提到 TCP 是首选的（尽管并非唯一的）传输协议：
注意：HTTP 当前运行在 TCP 上，但也可以运行在任何面向连接的服务上。
当然，HTTP 的这个概念验证版本与我们现在所知道和喜欢的 HTTP 几乎没有相似之处。没有标头，也没有状态码。典型的请求只有而已。响应仅包含 HTML，且 TCP 连接关闭就会结束。
由于浏览器尚未流行，因此用户需要直接阅读 HTML。可以用它链接到其他资源，但是在这个 HTML 早期版本中存在的所有标签都不会异步请求其他资源。一个 HTTP 请求就传递了一个完整的、自给自足的页面。
【 协议|从HTTP到HTTP/3的发展简史】2
HTTP/1.0 出现
在随后几年中，互联网迎来爆炸式的发展，尽管传输 HTML 仍然是 HTTP 的主要特色，但它逐渐发展成一种可扩展且灵活的通用协议。HTTP 的三大重要更新奠定了这一演变的基础：
方法的引入使客户能确定其想要执行操作的类型。例如，引入 POST 是为了允许客户端将数据发送到服务器以处理和存储；
状态码为客户端提供了一种确认服务器已成功处理请求的方法——如果处理失败，则可以用它了解发生了哪种错误；
标头增加了将结构化文本元数据附加到可以修改客户端或服务器行为的请求和响应上的功能。例如，编码和内容类型头使 HTTP 不仅可以传输 HTML，还可以传输任何类型的负载。“压缩”标头允许客户端和服务器协商支持的压缩格式，从而减少了通过连接传输的数据量。
同时，HTML 也不断进化，支持了图像、样式和其他链接资源。
现在，浏览器需要执行多个请求来显示一个网页，而原始的“按请求连接”架构是做不到的。建立和终止 TCP 连接涉及大量的数据包来回交换，因此在延迟开销方面相对昂贵。网页不见得一定由单个文本文件组成，但是随着每页请求数量的增加，延迟也随之增加。
下图说明了每建立一个新的 TCP 连接涉及多少请求开销。

文章插图
TCP 连接需要三个请求才能建立连接，四个请求可以完全关闭
人们创建了一个“连接”标头来解决这个问题。客户端发送带有“”标头的请求，以表明意图为后续请求保持 TCP 连接的打开状态。如果服务器理解此标头并同意遵守该标头，则其响应还将包含“”标头。
这样，双方都保持 TCP 通道打开并使用它进行后续通信，直到任何一方决定关闭它为止。随着 SSL/TLS 加密技术的发展，这一点变得更加重要，因为协商加密算法和交换加密密钥需要在每个连接上增加一个请求 / 响应周期。

文章插图
单个 TCP 连接可以通过“connection:keep-alive”标头重用于多个请求
当时，许多 HTTP 改进都是自发出现的。当流行的浏览器或服务器应用程序需要新的 HTTP 功能时，它们会自己实现该功能，并希望其他各方也能效仿。具有讽刺意味的是，去中心化的 Web 需要一个中心化的管理机构来避免碎片化造成的不兼容问题。
该协议的最初创建者蒂姆·伯纳斯·李（TimBerners-Lee）意识到了这种危险，并于 1994 年成立了万维网联盟（W3C），该联盟与互联网工程任务组（IETF）一起致力于规范互联网的技术栈。作为为已有环境带来更多规范的第一步，他们记录了当时 HTTP 中最常用的一些功能，并将其命名为 HTTP/1.0 协议。
但是，由于这种“规范”描述的是多种多样的，通常在“实践”中用法不一致的技术，因此它从未获得过标准地位。相比之下，关于 HTTP 协议新版本的工作已经开始了。