HTTP的进化之路

翻译原文：Evolution of HTTP - HTTP | MDN

HTTP (超文本传输协议) 是万维网的基础协议。 由Tim Berners Lee及其团队在1989-1991年间开发的HTTP经历了许多变化，这些变化有助于保持其简单性，同时塑造其灵活性。继续阅读，了解HTTP是如何从一个设计用于在半信半疑的实验室环境中交换文件的协议演变为一个以高分辨率和3D方式传送图像和视频的现代互联网迷宫的。

万维网的发明

1989年，蒂姆·伯纳斯-李在欧洲核子研究中心工作期间，提出了一项在互联网上建立超文本系统的建议。最初称为网格，后来在1990年实施期间更名为万维网。建立在存在的TCP和IP协议之上， 它有四个基础块组成:

• 一个文本格式来表示超文本文档，超文本标记语言（HTML）。

• 一个简单的协议来交换这些文档，超文本传输协议（HTTP）。

• 一个展现这些文档的客户端，第一个网页浏览器被称为WorldWideWeb。

• 一个服务端提供这些文档的获取通道，早期的版本是httpd。

这四个构建模块于1990年底完成，第一批服务器于1991年初在CERN之外运行。1991年8月6日，蒂姆·伯纳斯·李在公共alt.hypertext新闻组上发帖。这现在被认为是万维网作为一个公共项目的正式开始。

早期阶段使用的HTTP协议非常简单。它后来被称为HTTP/0.9，有时被称为单线协议。

HTTP/0.9-单线协议

HTTP 的初始版本没有版本号;它后来被称为0.9，以区别于后来的版本。HTTP/0.9非常简单：请求由一行组成，并以唯一的方法GET开始，后跟资源的路径。不包括完整的 URL，因为协议、服务器和端口在连接到服务器后就不是必需的。

GET /mypage.html

响应也非常简单：它只包含文件本身。

  A very simple HTML page

与随后的演变不同，此时还没有HTTP标头。这意味着只能传输HTML文件。没有状态或错误代码。如果存在问题，则会生成一个特定的 HTML 文件，其中包含问题描述以供用户使用。

HTTP/1.0-构建可扩展性

HTTP/0.9 功能非常有限，但浏览器和服务器很快使它成为多面手：

• 版本控制信息在每个请求中发送（HTTP/1.0 附加到 GET 行）。

• 在响应报文的开头也会发送状态码。这允许浏览器本身识别请求的成功或失败，并相应地调整其行为。例如，以特定方式更新或使用其本地缓存。

• HTTP 标头的概念是为请求和响应引入的。元数据可传输，协议变得非常灵活和可扩展。

• 幸亏Content-Type标头，可以传输的文档不仅仅是纯HTML文件。

此时，一个典型的请求和响应看起来像下面这样：

GET/mypage.htmlHTTP/1.0User-Agent:NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date:Tue, 15 Nov 1994 08:12:31 GMTServer:CERN/3.0 libwww/2.17Content-Type:text/html
A page with an image
  

紧随其后的是第二个连接和获取图像的请求（带有相应的响应）：

GET/myimage.gifHTTP/1.0User-Agent:NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date:Tue, 15 Nov 1994 08:12:32 GMTServer:CERN/3.0 libwww/2.17Content-Type:text/gif
(image content)

在1991-1995年之间，这些被介绍在一个try-and-see的项目研究里。服务器和浏览器将添加一个特性，并看看是否它会得到发展。互操作性问题很常见。为了解决这些问题，1996年11月出版了一份描述通用做法的资料文档。这被称为RFC 1945，并定义了HTTP / 1.0。

HTTP/1.1-标准化协议

与此同时，适当的标准化正在进行中。这与HTTP / 1.0的各种实现同时发生。HTTP的第一个标准化版本HTTP/1.1发布于1997年初，仅比HTTP/1.0晚了几个月。

HTTP/1.1澄清了歧义并引入了许多改进：

• 一个连接可以重复使用，从而节省时间。它不再需要多次打开来显示嵌入在单个原始文档中的资源。

• 管道机制被添加。它允许在第一个应答被完整传输完之前，第二个request包能被发送。这减少了通信延迟。

• 分块的响应被支持。

• 额外的缓存控制机制。

• 内容协商，包括语言，编码，类型。客户端和服务端会协商决定哪种内容形式交互。

• 幸亏Host标头，使得服务器有相同IP地址但不同的域名。

在单连接里的一个典型的请求数据流如下：

GET/en-US/docs/Glossary/Simple_headerHTTP/1.1Host:developer.mozilla.orgUser-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language:en-US,en;q=0.5Accept-Encoding:gzip, deflate, brReferer:https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

200 OK
Connection:Keep-AliveContent-Encoding:gzipContent-Type:text/html; charset=utf-8Date:Wed, 20 Jul 2016 10:55:30 GMTEtag:"547fa7e369ef56031dd3bff2ace9fc0832eb251a"Keep-Alive:timeout=5, max=1000Last-Modified:Tue, 19 Jul 2016 00:59:33 GMTServer:ApacheTransfer-Encoding:chunkedVary:Cookie, Accept-Encoding

(content)

GET/static/img/header-background.pngHTTP/1.1Host:developer.mozilla.orgUser-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0Accept:*/*Accept-Language:en-US,en;q=0.5Accept-Encoding:gzip, deflate, brReferer:https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

200 OK
Age:9578461Cache-Control:public, max-age=315360000Connection:keep-aliveContent-Length:3077Content-Type:image/pngDate:Thu, 31 Mar 2016 13:34:46 GMTLast-Modified:Wed, 21 Oct 2015 18:27:50 GMTServer:Apache

(image content of 3077 bytes)

HTTP/1.1是在1997年1月以RFC 2068第一次发布的。

超过15年的扩展

HTTP的扩展性使它很容易就能创建新的标头和方法。 尽管 HTTP/1.1 协议经过两次修订改进，即 1999 年 6 月发布的 RFC 2616 和 2014 年 6 月发布的 RFC 7230-RFC 7235，在 HTTP/2 发布之前，它非常稳定地被使用了不止15 年。

使用HTTP做安全传输

在1994年末HTTP做出了一个大的改变。与HTTP直接基于TCP发送不同的是，科技公司Netscape创建可额外的加密传输，SSL。SSL 1.0从未向公众发布，但SSL 2.0及其后继者SSL 3.0允许创建电子商务网站。为此，他们加密并认证了服务器和客户端之间交换的信息。SSL最终被标准化，并成为了TLS。

在同一时期，有个明显的需求就是需要一个加密的传输层。网络不再是一个以学术为主的网络，而是变成了一个广告商、随机个人和犯罪分子争夺尽可能多的私人数据的丛林。随着通过HTTP构建的应用程序变得更加强大，并且需要访问地址簿，电子邮件和用户位置等私人信息，TLS在电子商务使用场景之外变得必要。

使用HTTP做复杂应用

Tim Berners-Lee最初并没有将HTTP设想为只读模式。他想创建一个人们可以远程添加和移动文档的网络——一种分布式文件系统。大约在1996年，HTTP被扩展为允许创作，并创建了一个称为WebDAV的标准。它发展到涵盖特殊的应用，如用于处理地址簿条目的CardDAV和用于处理日历的CalDAV。但是所有这些 *DAV 扩展都有一个缺陷：它们只有在服务器上实现了才可用。

2000年，设计了一种使用HTTP的新模式：表述性状态转移（或REST）。该API不是基于新的HTTP方法，而是依赖于使用基本HTTP / 1.1方法访问特定URI。这允许任何 Web 应用程序通过 API 检索和修改其数据，而无需更新浏览器或服务器。所有必要的信息都嵌入在网站通过标准HTTP / 1.1提供的文件中。REST模型的缺点是每个网站都定义了自己的非标准RESTful API，并完全控制了它。这与客户端和服务器可互操作的 *DAV 扩展不同。RESTful API 在 2010 年代变得非常普遍。

自 2005 年以来，更多的 API 可用于网页。其中一些 API 出于特定目的创建 HTTP 协议的扩展：​​​​

• Server-sent events，这样服务器可以推送信息给浏览器。

• WebSocket, 通过升级现有 HTTP 连接来设置的新协议。

放宽WEB的安全模型

​HTTP 独立于 Web 安全模型，称为同源策略。事实上，当前的web安全模型是在HTTP创建后开发的！多年来，在某些约束下取消这项策略的一些限制被证明是有用的。服务器使用一组新的 HTTP 标头向客户端传输解除此类限制的数量和时间。这些是在跨源资源共享 （CORS） 和内容安全策略 （CSP） 等规范中定义的。

​除了这些大型扩展之外，还添加了许多其他标头，有些只是实验性的。值得注意的标头是用于控制隐私的“请勿跟踪”（DNT）标头，X-Frame-Options和Upgrade-Insecure-Requests，但还有更多。

HTTP/2-更好性能的协议

多年来，网页变得越来越复杂。其中一些甚至本身就是应用程序。更多的视频媒体出现，交互性的脚本的数量也增加了很多。更多的数据通过HTTP请求传输，这为HTTP / 1.1连接带来了更多的复杂性和开销。为了解决这个问题，谷歌在2010年代初实施了一个实验性协议SPDY。这种在客户端和服务器之间交换数据的替代方案引起了在浏览器和服务器上工作的开发人员的兴趣。SPDY提高了响应能力，并解决了数据传输多路复用的问题，且成为了HTTP / 2协议的基础。

HTTP/2协议区别与HTTP/1.1在以下几个方面:

• 它是一个二进制协议，而不是文本协议。无法人为地读取和创建。尽管存在此障碍，但它仍允许实施改进的优化技术。

• 这是一个多路复用协议。并行请求可以通过同一连接发出，从而消除了 HTTP/1.x 协议的约束。

• 它压缩标头。由于这些请求在一组请求中通常是相似的，因此这消除了传输数据的重复和开销。

• 它允许服务器通过称为服务器推送的机制在客户端缓存中填充数据。

HTTP/2 于 2015 年 5 月正式标准化，2022 年 1 月达到峰值，占所有网站的 46.9%。高流量网站为了节省数据传输开销和后续预算方面就快速采用。这种快速采用可能是因为HTTP / 2不需要更改网站和应用程序。要使用它，只需要最新的浏览器与最新的服务器。只需要一组有限的组来触发，并且随着旧版浏览器和服务器版本的更新，使用量自然会增加，而无需 Web 开发人员进行大量工作。

Post-HTTP/2上的进化

HTTP的可扩展性仍然可用于添加新功能。值得注意的是，我们可以列举出2016 年出现的 HTTP 协议的新扩展：

• 对 Alt-Svc 的支持允许分离给定资源的标识和位置。这意味着更智能的 CDN 缓存机制。

• 客户端提示的引入允许浏览器或客户端主动将有关其要求和硬件约束的信息传达给服务器。

• 在 Cookie 标头中引入与安全相关的前缀有助于确保安全 Cookie 无法被篡改。

HTTP/3-QUIC上的HTTP

HTTP的下一个主版本是HTTP/3，与早期版本的HTTP具有相同的语义，但使用QUIC而不是TCP作为传输层部分。到 2022 年 10 月，26% 的网站使用 HTTP/3。

QUIC旨在为HTTP连接提供更低的延迟。与HTTP / 2一样，它是一种多路复用协议，但HTTP / 2通过单个TCP连接运行，因此在TCP层处理的数据包丢失检测和重新传输将阻塞所有流。QUIC 通过 UDP 跑在多个流上，并为每个流独立实现数据包丢失检测和重新传输，因此如果发生错误，只会阻止该数据包中包含数据的流。

HTTP/3在RFC 9114中定义，大多数主流浏览器都支持HTTP/3，包括Chromium（及其变体，如Chrome和Edge）和Firefox。