1 缘起
有一次，听到有人在议论招聘面试的人员，
谈及应聘人员的知识深度，说：问了一些关于Http的问题，如Http相关结构、网络结构等，
然后又说，问没问相关原理、来源？
我也是有些困惑了，Http的相关原理、来源？
对于开发者而言有多少用处？
当然是有的，这是基础必备知识，即使在开发过程中不关注这些也能正常实现功能，
在知识交流和考核过程中，看似不起眼的基础知识，就是死穴了。
听到过这么一句很有分量的话：连这些基础（原理）都不知道？
说起来惭愧，计算机领域有多少基础知识是不知道的！！！以及究其一生仍无法知道以及不得不借鉴（抄袭）才能得来，
但是，又大言不惭地说是自主知识产权。
牢骚过后，
本文主要分享Http的变迁，帮助读者轻松应对知识交流与考核，以及当做论文素材。
英文文档为：https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP
2 Http
HTTP（超文本传输协议）是万维网的基础（底层）协议，由Tim Berners Lee及其团队于1989-1991年间开发，
HTTP经历多次变更，使得HTTP得以保持简单、灵活。
本文介绍HTTP是如何从实验室（仅为交换文件而设计的一种传输协议）演变为现代互联网宫殿的，可以通过HTTP携带高分辨率图片、视频和3D模型等。
HTTP的大事年表如下图所示，这里没有把RESTful API放进去，不过还是提一下，
RESTful API的出现，推动并规范了互联网的发展（总之很重要），
RESTful AP首次出现于Roy Thomas在2000年的博士论文https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm。
2.1 万维网的发明
1989年，Tim Berners-Lee在CERN（欧洲核子研究中心）工作期间提出基于互联网构建超文本系统的建议。
最初这套超文本系统称为Mesh，后来在1990年实施期间更名为万维网（World Wide Web）。
万维网基于TCP和IP协议构建，由4部分组成：
（1）HTML：超文本标记语言，以文本形式表示超文本文档；
（2）HTTP：超文本传输协议，交换超文本文档的简单协议；
（3）客户端：展示和编辑超文本文档，第一个网络浏览器称为WorldWideWeb；
（4） 服务端：为超文本文档提供接入服务，httpd的早期版本。
万维网的这4个部分于1990年年底完成构建，第一批服务器于1991年初在CERN外运行。
1991年8月6日，Tim Berners-Lee在公共alt.hypertext新闻组发帖，这被认为是万维网正式作为公共项目的开端。
早期HTTP协议非常简单，后来被称为HTTP/0.9，有时称为单行协议（one-line protocol）。
2.2 HTTP/0.9：单行协议
HTTP初始版是没有版本号的，后来称为0.9，以示与后来的版本区分。
HTTP/0.9非常简单，请求由一行组成，以GET方法开始，拼接资源路径。
由于连接到服务器后不需要协议、服务器和端口，因此不包含完整的URL。
单行HTTP请求如下：
GET /mypage.html
请求的响应同样非常简单，只包含文件本身。
<html>
A very simple HTML page
</html>
与后续的HTTP不同的是，HTTP/0.9没有头部，意味着该协议只能传输HTML文件。
没有状态或错误代码，如果出现问题，将生成一个特定的HTML文件，包含问题的描述，供用户使用。
2.3 HTTP/1.0：构建可扩展性
HTTP/0.9功能非常有限，但是浏览器和服务器的发展是HTTP变得更加通用：
（1）每个请求中会发送版本信息（HTTP/1.0添加到GET请求行中）；
（2）响应的起始部分会发送状态码，这样浏览器就可以根据响应识别成功或是失败，并调整处理逻辑，如可以更新或使用本地缓存；
（3）HTTP头的概念嵌入到请求和响应中，可以传输元数据，协议的灵活性和可扩展性均有增强；
（4）请求头中使用Content-Type参数，HTTP可以传输HTML之外的文档。
2.3.1 样例
- 请求
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
- 响应
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
<IMG SRC="/myimage.gif">
</HTML>
获取图像的样例：
- 请求
GET /myimage.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
- 响应
200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(image content)
1991~1995年间，HTTP/1.0采用试看的方法，在服务器和浏览器中添加新功能，看看是否有吸引力。
交互问题是常见的问题，为解决这些问题，1996年出版了一份信息文档，用于描述通用处理方法，即RFC1945，定义了HTTP/1.0。
2.4 HTTP/1.1：标准化协议
与此同时，HTTP标准化火热进行中，与HTTP/1.0的相关实现并行进行，
第一个标准化的HTTP版本是1997年发布的HTTP/1.1，仅比HTTP/1.0晚了几个月。
HTTP/1.1阐明了引起歧义的地方并引入了诸多改进：
（1）可重用连接（节约时间）。无需多次打开嵌入到单个文档中的资源；
（2）添加管道。允许第一个请求收到响应前发送第二个请求，降低通信的延迟；
（3）支持分块响应；
（4）引入缓存控制机制；
（5）引入内容协商，包括语言、编码和类型。客户端和服务器现在可以根据交换的内容达成一致；
（6）由于主机头的存在，服务器具有从同一IP托管不同域的能力。
2.4.1 样例
- 请求
GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
- 响应
200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding
(content)
- 请求
GET /static/img/header-background.png HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
- 响应
200 OK
Age: 9578461
Cache-Control: public, max-age=315360000
Connection: keep-alive
Content-Length: 3077
Content-Type: image/png
Date: Thu, 31 Mar 2016 13:34:46 GMT
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
Server: Apache
(image content of 3077 bytes)
HTTP/1.1与1997年1月首次发表为RFC 2068。
2.5 15年的扩展期
HTTP的可扩展性使创建新的头和方法变得非常容易。
虽然HTTP/1.1经过两次修订（1999年6月发布的RFC2616和2014年6月【HTTP/2发布前】发布的RFC7230，RFC7235），
但是HTTP/1.1历经15年仍非常稳定。
2.5.1 建立安全传输
HTTP最大变更发生于1994年底，计算机服务公司Netscape Communications在HTTP上添加了加密传输层：SSL（Secure Socker Layer，安全套接字层），
而不是通过基本的TCP/IP栈发送HTTP。SSL1.0并没有向大众发布，但是SSL2.0和SSL3.0允许创建电子商务网站。
通过SSL加密，保证了服务器和客户端交换信息的真实性。SSL最终成为公认的标准，成为TLS（Transport Layer Security，传输层安全）。
与此同时，加密传输层是非常必要的。网络不再是一个主要的学术网络，而是一个丛林，广告商、个人和犯罪分子都在竭尽所能获取更多的私人数据。
随着基于HTTP构建的应用程序日益强大，并且需要访问地址簿、电子邮件和用户位置等私人信息，TLS在电子商务之外变得非常必要。
2.5.2 面向更复杂的应用
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在21世纪头10年非常通用。
自2005年以来，网页可用的API逐渐增多，一些API为了特殊的目的而扩展了HTTP协议：
（1）服务器发送事件，服务器可以将消息推送到浏览器；
（2）WebSocket，一种新的协议，以现有的HTTP连接进行升级。
2.5.3 宽松的网络安全模型
HTTP独立于Web安全模型，称为同源策略。
实际上，当前的Web安全模型是HTTP发明之后才产生的。
多年经验得知，某些限制条件下取消同源的限制是有用的，服务器使用一组新的HTTP头将解除此类限制的数量时间发送给客户端。
这些都是在跨源资源共享（CORS， Cross-Origin Resource Sharing）和内容安全策略（CSP，Content Security Policy）等规范中定义的。
除了这些大型拓展外，HTTP添加了许多其他头部（有时只是实验性质的）。
需要注意的头有：控制隐私的头、X-Frame-Options头和Upgrade-Insecure-Requests头等。
2.6 HTTP/2：更高性能的协议
经过多年发展，网页日趋复杂，其中一些甚至是自己的应用程序，
目前的网页可以展示更多的视觉媒体，但是增加互动性的脚本数量以及大小也随之增加。
通过大量的HTTP请求传输更多的数据，增加了HTTP/1.1的连接的复杂性和开销。
为解决这一问题，Google在2010年初实施了一项实验性协议SPDY。
这种在客户端和服务器之间交换数据的方案引起了使用浏览器和服务器开发人员的兴趣，
SPDY明确增加响应能力，并解决重复传输数据的问题，作为HTTP/2协议的基础。
HTTP/2协议与HTTP/1.1有如下几点不同：
（1）二进制协议而不是文本协议。无法手动读取和创建。虽然有这个障碍，但是可以通过改进进行优化；
（2）这是一个多路复用协议，同一连接可以接受并行请求，从而消除HTTP/1.1协议的限制；
（3）压缩头部。由于这些请求在一组请求中通常是相似的，压缩头部消除了数据传输的开销；
（4）允许使用服务器推送机制，即在客户端段缓存中填充数据。
2015年5月正式标准化，HTTP/2使用量在2022年1月达到峰值，
占所有网站的46.9%（统计数据https://w3techs.com/technologies/details/ce-http2）。
为节省数据传输开销和后续预算，高流量网站采用的速度最快。
这种快速拥抱HTTP/2的原因可能是因为不需要更改网站和应用程序。
使用HTTP/2只需要更新服务器，浏览器即可使用。
只需少量的组织来触发应用，随着浏览器和服务器的更新，使用量自然会增加，而Web开发者无需进行大量工作。
2.7 后HTTP/2时代的演变
HTTP的扩展仍在继续。引用2016年出现的HTTP扩展：
（1）支持Alt-Svc，允许分离给定资源的标识和位置，意味着更智能的CDN缓存机制；
（2）引入客户端提示，允许浏览器或客户端主动向服务器传输有关需求和硬件约束的信息；
（3）Cookie头中引入安全相关的前缀，有助于保证Cookie不会被更改。
2.8 HTTP/3：通过QUIC实现HTTP
HTTP的下一个主要版本HTTP/3，HTTP/3与早起的HTTP版本有相同的语义，
只是在传输层使用了QUIC，而不是TCP。
截至2022年10月，有26%的网站使用HTTP/3。
QUIC为HTTP连接提供更低的延迟。与HTTP/2一样，QUIC是一个多路复用协议，
但是HTTP/2运行在单个TCP连接上，因此，TCP在处理丢包检测和重传会阻塞所有流。
QUIC基于UDP运行多个流，并对每个流独立地执行丢包检测和重传，
如果发生错误，只会影响当前包的流。
