共计 3195 个字符，预计需要花费 8 分钟才能阅读完成。

观感度：????????????????????

口味：黑糖珍珠

烹饪时间：15min

前端圈技术的爆发式增长随之而来的开发人员学不动的疲惫感、焦虑感和不想跳出舒适圈的拖延懒惰。

jQuery 华丽谢幕，React v16 已经普及、Angular9 和 Vue3 即将发布。三大框架越来越贴近 WebComponents 标准。
TypeScript 遍地开花，小程序日益火爆，快应用 /PWA 紧随其后……

站在浪潮之巅的我们最需要的是停下来思考，轰轰烈烈的技术本质是什么？

其实，轰轰烈烈的技术本质，是基础知识和核心概念。

看你这篇题目的文章，是要讲 HTTP 咯？HTTP 那么简单，我们大家每天都用，有什么好讲的？

在停下来思考技术本质的同时，我们也要不断的提高自己的认识层次，你所谓的简单是因为你没有听到“遥远的哭声”。

(shout out to 男神黄执中)

有请我们今天的主角登场：HTTP

我将带你从 HTTP 的历史发展到各版本迭代主要特性来从全局的角度重新认识 HTTP。

先来明确一下时间线，回到 30 年前的那个春天。

一切的一切都始于 1989 年的 3 月，万维网之父蒂姆·伯纳斯·李 (Tim Berners-Lee) 的一篇论文，创造了万维网，创造了 HTTP。

1991 年 HTTP/0.9 发布（没有 RFC，版本号是后加上去的）
1996 年 5 月 HTTP/1.0 在 RFC1945 发布
1997 年 1 月 HTTP/1.1 发布 RFC2616 是当前最新版本
2014 年 HTTP/1.1 再次修订，将大文档拆分为六份较小的文档，

RFC7230-7235

2015 年 HTTP/2 发布 RFC7540 (基于谷歌的 SPDY 协议)
2018 年，互联网标准化组织 IETF 提议将 HTTP over QUIC 更名为 HTTP/3

如果希望全面的了解 HTTP/3，推荐 Daniel Stenberg（CURL 作者）的 HTTP/ 3 详解

当然如果你想看最新同步的中文，可以看我翻译的版本。
欢迎指正错误和 StarHTTP/ 3 详解中文版

纵观 HTTP 的历史发展长河，究其原因，是技术和需求一直在推动着它的发展。

HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范。

HTTP 通常跑在 TCP/IP 协议栈 之上，依靠IP 协议实现寻址和路由、TCP 协议实现可靠数据传输、DNS 协议实现域名查找、SSL/TLS 协议实现安全通信。当然，WebSocket、HTTPDNS 依赖于 HTTP。

GET/index.html

HTTP/0.9当时是为了学术交流，基于请求和响应的模式，在网络中传输 HTML 超文本的内容。

如上所示，只有一个请求行，没有 HTTP 请求头和请求体。同样，服务器也没有响应头信息，只是返回了数据。

因为都是 HTML 格式的文件，决定了返回的文件内容通过 ASCII 字符流 进行传输。

1994 年低开启拨号上网，网景也在同年推出了第一款浏览器，人们对万维网的需求不再仅局限于学术交流。

W3C 和 HTTP 工作组 HTTP-WG 也在这个时代创建。为了满足人们对浏览器的需求(不光是 HTML，还有 CSS、JS、图片、音视频等)，文件格式不再局限于 ASCII 编码。

HTTP/1.0的解决办法是引入了请求头和响应头。

accept: text/html
accept-encoding: gzip, deflate, br
accept-Charset: ISO-8859-1,utf-8
accept-language: zh-CN,zh

同时也引入了 状态码 ，为了减轻服务器的压力，提供了Cache 机制。服务器需要统计客户端的基础信息(Windows 和 macOS)，加入了 用户代理字段。

一个 TCP 连接上可以传输多个 HTTP 请求，只要浏览器或者服务器没有断开连接，该 TCP 会一直保持。

持久连接是默认开启的，如果想要关闭，在请求头中加上 Connection:close 即可关闭。

目前浏览器中对于同一个域名，默认允许同时建立 6 个 TCP 持久连接。

HTTP/1.1 中试图通过 管线化的技术 来解决队头阻塞的问题。但是因为各种原因，被各大厂商放弃治疗了。

HTTP/1.0中每个域名都只绑定唯一的 IP 地址，因此一个服务器只能支持一个域名。

但是随着虚拟主机技术的发展，一台物理主机上绑定多个虚拟主机的需求大大提升，每个虚拟主机都有自己单独的域名，这些单独的域名都公用同一个 IP 地址。

因此，请求头中也增加了Host 字段，表示当前的域名地址，服务器可根据不同的 Host 值做不同的处理。

HTTP/1.0需要在响应头中设置完整的数据大小Content-Length：900，这样，浏览器就可以根据设置的数据大小来接收数据。

由于服务器端技术发展，页面都是动态生成的，传输数据之前并不知道最终数据大小，
导致浏览器不知道何时会接受完所有的文件数据。

HTTP/1.1通过引入 Chunk transfer 机制 来解决问题，服务器将数据分割成若干个任意大小的数据块，每个数据块发送时会附上上一个数据块的长度，最后使用一个长度为 0 的块作为发送数据完成的标志。

HTTP1.1引入了 客户端 Cookie 机制 和安全机制。

三个问题导致

TCP 的慢启动
同时开启了多条 TCP 连接，那么这些连接会竞争固定的带宽
HTTP/1.1 队头阻塞的问题

HTTP/2使用多路复用机制解决了上述问题。

一个域名只使用一个 TCP 长连接和消除队头阻塞问题。通过引入 二进制分帧层，实现了 HTTP 的多路复用技术。

服务器可以提前将数据推送到浏览器，浏览器有权选择是否接受。浏览器发送 RST_STREAM 帧 可以选择拒收。

头部的压缩大大的提升了传输效率。HTTP/ 2 开发了“HPACK”算法，在客户端和服务器建立“字典”，用索引号表示重复的字符串，还采用哈夫曼编码来压缩整数和字符串。

可以设置让某些重要的数据优先被服务器处理并返回。

在 TCP 传输过程中，由于单个数据包的丢失而造成的阻塞称为 TCP 上的队头阻塞。
HTTP/2只解决了应用层面的队头阻塞，队头阻塞的问题还存在于 TCP 协议本身。

TCP以及 TCP+TLS 建立连接的所产生的延时也是影响传输效率的一个主要因素。

中间件僵化

我们把在互联网的各处搭建的设备叫做中间设备 (中间件)，比如路由器、NAT、防火墙、交换机等，它们通常依赖一些很少升级的软件，这些软件使用了大量的 TCP 特性，设置之后便很少进行更新。这就对我们我们更新 TCP 的时候造成了很大的困难，
新协议的数据包经过这些中间件时，它们不会去理解包的内容从而丢弃掉这些数据包。

操作系统

因为 TCP 协议都是通过操作系统内核来实现的，应用程序只能使用不能修改。通常操作系统的更新都滞后于软件的更新，所以想要更新操作系统内核中的 TCP 协议也是非常困难的。

HTTP/3 选择了一个折衷的方法——UDP 协议，基于 UDP 实现了类似于 TCP 的多路数据流、传输可靠性等功能，我们把这套功能称为 QUIC 协议。

实现了类似 TCP 的流量控制、传输可靠性的功能
集成了 TLS 加密功能
实现了 HTTP/2 中的多路复用功能
实现了快速握手功能

关于 HTTP/ 3 更多详细的内容，请移步我翻译成中文版的 HTTP/ 3 详解。

欢迎 Star 仓库链接和提出错误或不对的地方。

参考：

《浏览器工作原理与实践》

《透视 HTTP 协议》

《趣谈网络协议》

《Web 协议详解与抓包实战》

欢迎关注我的个人公众号，优质文章将同步推送。

你的前端食堂，记得按时吃饭。

HTTP的世界观附HTTP3中文翻译