从HTTP到HTTP的发展简史.docxVIP

从HTTP到HTTP/3的进展简史 2021-11-25 虽然 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 几乎没有相像之处。没有标头，也没无形态码。典型的恳求只要GET/path而已。响应仅包含 HTML，且 TCP 连接关闭就会结束。 由于扫瞄器尚未流行，因而用户需要直接阅读 HTML。可以用它链接到其他资源，但是在这个 HTML 晚期版本中存在的全部标签都不会异步恳求其他资源。一个 HTTP 恳求就传递了一个完整的、自给自足的页面。 2 HTTP/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）意识到了这种危急，并于 1994 年成立了万维网联盟（W3C），该联盟与互联网工程任务组（IETF）一起努力于规范互联网的技术栈。作为为已有环境带来更多规范的第一步，他们记录了当时 HTTP 中最常用的一些功能，并将其命名为 HTTP/1.0 协议。 但是，由于这种“规范”描述的是多种多样的，通常在“实践”中用法不全都的技术，因而它从未获得过标准地位。相比之下，关于 HTTP 协议新版本的工作已经开头了。 3 HTTP/1.1的标准化 HTTP/1.1 修复了 HTTP/1.0 的不全都之处，并调整了协议，使其在新的 Web 生态系统中具备更好的功能表现。新版引入的两个最关键的更改是默认使用长久 TCP 连接（保持活动形态）和 HTTP 管线化。 HTTP 管线化的意思就是客户端无需在发送后续 HTTP 恳求之前等