网络优化系列专题，聊一聊面对复杂多变的移动网络，我们需要掌握哪些网络基础知识，以及该如何做好网络优化这项工作。
网络优化系列专题
- 网络优化背景知识（待完善）
《关于 5G，你应该知道的发展史》
《HTTP 发展的前世今生》
《网络安全 — HTTPS》
《关于网络优化，你需要了解什么？》
《HTTP 的第一次变革 — HTTP/2》
《展望更好 — HTTP/3》
-
如何优化网络性能（待更）
...
如今，打开手机或电脑，只要你上网，不论是选择哪个操作系统，不论是用浏览器还是 App，不论是看新闻、短视频还是听音乐...，总会有 HTTP 在后台默默为你服务。
在享受如此便捷舒适的网络生活时，你是否有想过，HTTP 协议是怎么来的？它最开始是什么样子的？又是如何发展到今天，几乎“统治”整个互联网世界的呢？
今天我们就来聊一聊 HTTP 的发展历程，了解下它的成长轨迹。
诞生
1989 年 3 月 12 日，任职于 CERN（欧洲核子研究中心）的 Tim Berners-Lee（蒂姆.伯纳斯 - 李）提交了一篇名为《Information Management : a proposal》（关于信息化管理的建议）文章，提出了在互联网上构建超链接文档系统的构想，初步阐述了后来被称为 World Wide Web（万维网） 的信息管理概念，该篇文章中他确立了三项关键技术：
URI（Uniform Resource Identifier）：即统一资源标识符，作为互联网上资源的唯一身份；
HTML（Hypertext Markup Language）：超文本标记语言，描述超文本文档；
HTTP（Hypertext Transfer Protocol）：即超文本传输协议，用来传输超文本。
基于它们，就可以把超文本系统完美地运行在互联网上，让各地的人们能够自由地共享信息，这也是我们现在所熟知的 Web。
所以在这一年，HTTP 诞生了，从此开始了它的光辉之路。由于该篇文章，1989 年也被认为是蒂姆.博纳斯 - 李发明 World Wide Web 的年份。
HTTP/0.9
20 世纪 90 年代初期的互联网世界非常简陋，计算机处理能力弱，存储容量小，网速很慢，还是一片“信息荒漠”。网络上绝大多数的资源都是纯文本，很多通信协议也都使用纯文本，所以 HTTP 的设计也不可避免地受到了时代的限制。
这一时期的 HTTP 被定为 0.9 版本，结构比较简单，为了便于服务器和客户端处理，它也采用纯文本格式。蒂姆.博纳斯 - 李最初设想系统里的文档都是只读的，所以只允许用 “GET” 操作从服务器上获取 HTML 文档，并且在响应请求之后立即关闭连接，功能非常有限。
HTTP/0.9 虽然很简单，但它作为一个“原型”，充分验证了 Web 服务的可行性，而“简单”也正式它的优点，因为这蕴含了后来进化和扩展的可能性：把简单的系统变复杂，要比把复杂的系统变简单容易得多。
第一个网站
1990 年 12 月 20 日，蒂姆.博纳斯 - 李架设了人类历史上第一个网站，域名为 Info.cern.ch，它被用于 CERN 内部；所使用的服务器则是他的个人 NeXT 电脑，直到今天，这台 NeXT 电脑依然被作为人类首个网站的服务器，当然这个网站也被 CERN 保留了下来。
1991 年 8 月 6 日，蒂姆.博纳斯 - 李又将与 World Wide Web 项目相关的总结文档上传至互联网，这是第一个出现在互联网上的 Web 网站，距离现在已经整整 28 周年了。
HTTP / 1.0
但是在当时，World Wide Web 并没有迅速获得世人的认可。尽管博纳斯·李坚信自己的发明将会“统治世界”，但是到了 1992 年，他的论文还是被“超文本会议”拒绝了。
而这时，正在美国伊利诺大学 NCSA（美国国家超级计算应用中心） 学习（兼职）的马克.安德森出现了，年仅 22 岁的他已经对互联网颇为熟悉了；他觉得在 World Wide Web 加上图形更有意思，就与人合作开发出第一个可以图文混排的浏览器 Mosaic。该浏览器一经发布就受到了热烈欢迎。但由于 Mosaic 是由大学的资金和设备开发的，所以它的所有权归 NCSA 所有。
注意，Mosaic 并不是第一个图形接口浏览器，比它更早的例如由蒂姆.博纳斯 - 李本人开发的 WorldWideWeb（世界上第一个网页浏览器，后更名为 Nexus）、鲜为人知的 Erwise 和 ViolaWWW。但是 Mosaic 却是第一个可以在文字中嵌入图片，而不是在单独窗口中显示图片的浏览器。
同一时期，计算机多媒体技术也有了新的发展，1992 年 JPEG（联合图像专家小组） 图像格式诞生，1995 年发明了 MP3（动态影像专家压缩标准音频层面3）音乐格式。
这些新软件，新技术一经推出立刻就吸引了广大网民的热情，更多的人开始认识互联网，开始使用互联网，研究 HTTP 并提出改进意见，甚至实验性地往协议里添加各种新特性，从用户需求的角度促进了 HTTP 的发展。
于是在这些已有实践的基础上，经过一系列的草案，HTTP/1.0 版本在 1996 年正式发布，它在多方面增强了 0.9 版本，形式上已经和我们现在的 HTTP 差别不大了，例如：
- 增加了 HEAD、POST 等新方法；
- 增加了响应状态码，标记可能的错误原因；
- 引入协议版本号概念；
- 引入了 HTTP Header 的概念，让 HTTP 处理请求和响应更加灵活；
- 传输数据不在仅限于文本。
但是 HTTP/1.0 并不是一个标准，只是记录已有实践和模式的一份参考文档，不具有实际的约束力，就有点类似于备忘录。
所以 HTTP 1.0 的发布，对于当时正在蓬勃发展的互联网来说，并没有太多的实际意义，各方“势力”仍然按照自己的意图继续在市场上奋力“拼杀”。
HTTP / 1.1
前面我们有提到，第一个图文混排的浏览器 Mosaic 由马克.安德森与他人合作开发，但是它的所有权归 NCSA 所有，而 NCSA 最后决定将 Mosaic 交给了 Spyglass （实际是 NCSA 的一个分支，旨在将 NCSA 技术商业化）用于商业用途和运营。
于是，1994 年马克.安德森离开 NCSA，与人合作创办了 Netscape，也就是网景公司（最初叫做 Mosaic 公司，为了规避与 NCSA 的法律纠葛，同年 11 月公司最终变更为 Netscape），专门用来开发用于商业运作的图形浏览器，公司的产品也更名为网景浏览器。同年 12 月 15 日网景浏览器 1.0 正式发布，软件改名为 NetScape Navigator（网景导航者）。
网景浏览器是第一个大获成功的商业浏览器，它将蒂姆.博纳斯 - 李发明的 World Wide Web 从实验室带到了公众视野；正如博纳斯 - 李预言的那样，World Wide Web 开始了“统治世界”的进程。
随着网景公司的日益强大，公司开始尝试创做一种能够让用户通过浏览器操作的网络应用系统。这让微软感受到了威胁，担心网景可能威胁到微软的操作系统和应用程序市场。于是微软于 1995 年研发了自己的 Internet Explorer，这一年开始了著名的浏览器大战，网景的 NetScape Navigator 和微软的 Internet Explorer 都希望在互联网上占据主导地位。
虽然这场“战争”的结果你一定早就知道了，最终微软的 IE 取得了决定性的胜利，而网景则“败走麦城”（最后凭借 Mozilla Firefox 又扳回一局）。
具有讽刺意味的是，Internet Explorer 正是在马克.安德森开发的 Mosaic 的基础上发展而来的。当然，微软获得了伊利诺大学的许可。
不可否认，“浏览器大战”再一次极大地推动了 Web 的发展，HTTP/1.0 也在这个过程中经受了实践的检验。于是在 “大战” 结束之后的 1999 年，HTTP/1.1 发布了 RFC（Request for Comments）文档，编号为 2616，正式确立了延续十余年的传奇。
从版本号我们就可以看出，HTTP/1.1 是对 HTTP/1.0 的小幅度修正。但一个重要的区别是：它是一个正式的标准，而不是一份可有可无的参考文档。这意味着今后互联网上所有的浏览器、服务器、网关和代理等等，只要用到 HTTP 协议，就必须严格遵守这个标准，相当于是互联网世界的一个“立法”。
不过，说 HTTP/1.1 是小幅度“修正”也不太确切，它还是有很多实质性进步的。毕竟经过了多年的实战检验，比起 0.9 和 1.0 更加接近用户, 同时表述也更加严谨。HTTP/1.1 主要的变更有以下：
- 增加了 PUT、DELETE 等新方法；
- 增加了缓存管理和控制；
- 明确了连接管理，允许持久连接；
- 允许响应数据分块（chunked），利于传输大文件；
- 强制要求 Host 头，让互联网主机通关成为可能。
由此，互联网在它的“保驾护航”下迈开了新的步伐，开启了后续的 Web 1.0，Web 2.0 时代。现在许多知名企业都是在这个时间点左右创立的，例如 Google、新浪、搜狐、网易、腾讯等。
- 不过由于 HTTP/1.1 太过庞大和复杂，所以在 2014 年又做了一次修订，原来一个大文档被拆分成了六份较小的文档，编号为 7230 ~ 7235，优化了一些细节，但此外没有任何实质性的改动。
Google 开始领航
HTTP/1.1 发布之后，整个互联网世界呈现出了爆发式的增长，度过了十多年的“快乐时光”，更涌现了 Facebook、Twitter、淘宝和京东等互联网新贵。
然而，这期间也出现了一些对 HTTP 不满的意见，主要是连接慢，无法跟上迅猛发展的互联网，但 HTTP/1.1 标准一直“岿然不动”，无奈之下人们只好发明各式各样的“小花招”来缓解这些问题，比如以前常见的切图、JS 合并等网页优化手段。
HTTP/2.0
终于有一天，搜索巨头 Google 忍不住了，决定“揭竿起义”，那么它是怎么开始“造反”的呢？
Google 首先开发了自己的 Chrome 浏览器，然后推出了新的 SPDY 协议，并在 Chrome 里应用于自家的服务器，如同十多年前的网景和微软一样，从实际的用户来“倒逼” HTTP 协议的变革，这也开启了第二次“浏览器大战”。
历史再次重演，不过这次的胜利者是 Google，Chrome 目前在全球的占有率超过了 60%，“挟用户以号令天下”，Google 借此顺势把 SPDY 推上了标准的宝座，互联网标准化组织以 SPDY 为基础开始制定新版本的 HTTP 协议，最终在 2015 年发布了 HTTP/2.0 RFC 编号 7540。
- SPDY 并不是首字母缩略字，仅仅是 speedy 的缩写。Google 最早是在 Chromium 中提出 SPDY 协议，HTTP/2 的关键功能主要来自 SPDY 技术，换言之，SPDY 的成果被采纳而最终演变为 HTTP/2。SPDY 协议通过压缩、多路复用和优先级来缩短加载时间。
HTTP/2 的制定充分考虑了互联网的现状：带宽、移动和不安全，在高度兼容 HTTP/1.1 的同时更注重性能方面的改进，主要的特点有：
- 二进制协议，不再是纯文本；
- 可发起多个请求（多路复用），废弃了 1.1 里的通道；
- 使用专用算法压缩头部，减少数据传输量；
- 允许服务器主动向客户端推送数据；
- 增强了安全性，要求加密通信。
连接复用
网络连接这个环节需要经过 TCP 三次握手、TLS 秘钥协商，连接建立的代价是非常大的，这里优化思路是复用连接，这样不用每次请求都重新建立连接。这里我们利用的是 HTTP 协议里的 keep-alive。而 HTTP/2.0 的多路复用则可以进一步的提升连接复用率。它复用的这条连接支持同时处理多条请求，所有请求都可以并发在这条连接上进行。
HTTP/3
HTTP/2 这么好，是不是已经完美了呢？答案是否定的，H2 的多路复用在本质上依然是同一条 TCP 连接，如果所有域名的请求都集中在某一条连接上，在网络拥塞的时候容易出现 TCP 队首阻塞的问题。
这一次还是 Google，而且它要“革自己的命”。在 HTTP/2 还处于草案之时，Google 又发明了一个新的协议 — QUIC（Quick UDP Internet Connection），而且还是相同的“套路”，继续在 Chrome 和自家服务器里“试验着玩”，依托它的庞大用户量和数据量，持续地推动 QUIC 协议成为互联网上的“既成事实”。
在连接复用中我们说过 HTTP/2 + TCP 会存在队首阻塞的问题，基于 UDP 的 QUIC 才是终极解决方案。 QUIC 也确实因为自身素质过硬，在 2018 年，互联网标准化组织 IETF 提议将 “HTTP over QUIC” 更名为 HTTP/3 并获得成功，HTTP/3 正式进入了标准化制定阶段，也许几年以后就会正式发布，到时候我们说不定可以直接跳过 HTTP/2 直接进入 HTTP/3。
如下图所示，可以把 QUIC 简单理解为 HTTP/2.0 + TLS 1.3 + UDP。
目前 QUIC 还有很多坑还没有踩完，发现的主要问题例如有创建连接成功率和运营商劫持等。
小结
2019 年 3 月 12 日，是 World Wide Web 诞生 30 周年的纪念日，当然也是 HTTP 协议的整个发展过程，这里再简单总结下：
1. HTTP 协议始于三十年前蒂姆.博纳斯 - 李的一篇论文；
2. HTTP/0.9 是个简单的文本协议，只能获取文本资源；
3. HTTP/1.0 确立了大部分现在使用的技术，但它不是正式标准；
4. HTTP/1.1 是目前互联网上使用最广泛的协议，功能也非常完善；
5. HTTP/2.0 基于 Google 的 SPDY 协议，注重性能改善，改善的目标是低延迟，但其普及率并不高。
6. HTTP/3 基于 Google 的 QUIC 协议，目前正在制定中，将是未来发展的方向。
最后
通过今天的介绍，相信你对 HTTP 有了一个初步但清晰的认识。另外大家对 HTTP 的发展还有哪些理解和认识？欢迎大家留言分享或指正。
文章如果对你有帮助，请留个赞吧。
彩蛋
早期的 HTTP/0.9 是没有版本号的，0.9 这个版本号是后来才加上去的，用于区别之后的 1.0/1.1；
HTTP/1.0 的 RFC 编号是 1945，而 HTTP/0.9 则没有 RFC；
一个有趣的事实：“World Wide Web” 是英语中极少数缩写（WWW）比原文发音更长的词。
扩展阅读
UI 优化系列
- 关于 UI 渲染，你需要了解什么？
- Android 之如何优化 UI 渲染（上）
- Android 之如何优化 UI 渲染（下）
- Android 之 Choreographer 详细分析
- LayoutAnimation 炫酷的布局动画及原理分析
- Android 之你真的了解 View.post() 原理吗？
存储优化系列
