91、HTTP 0.9 ~ HTTP 3.0的发展历程

目录

一、HTTP 0.9（1991）

二、HTTP 1.0（1996）

三、HTTP 1.1（1997）

四、HTTP 2.0（2015）

五、HTTP 3.0（2020）

---

 

一、HTTP 0.9（1991）

http0.9 特点：

1. http0.9 是第一个版本的http协议，比较简单，只支持get请求；
2. 只有一个请求行，没有请求头和请求体。因为一个请求行就可以完整表达客户端的需求了；
3. 服务器没有返回头信息，只需要返回HTML格式的数据即可（只能是HTML格式的）；
4. 无连接、无状态。浏览器的每次请求都需要与服务器建立一个TCP连接，服务器处理完成后立即断开TCP连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）。

过程：

1. 客户端先根据ip地址、端口和服务器建立TCP连接（tcp三次握手）；
2. 建立连接后，会发送一个get请求行的信息(GET /index.html)，请求html文件；
3. 服务器接受信息后读取对应的html文件，并将数据以ASCII字符流返回给客户端（使用ASCII对html文件编码）；
4. html文档传输完成后，断开连接；

缺点：

1. http0.9只支持html文件，其余类型的文件如何传输；
2. 文件格式不再仅仅局限于ASCII编码；

二、HTTP 1.0（1996）

相对于http0.9的改进：

1. 为了让客户端和服务器端更加深入的交流，http1.0引入了请求头和响应头；
2. 响应对象不只限于超文本html；
3. 支持get、post、head请求方法；
4. 支持缓存机制，用来缓存已经下载过的数据，以减轻服务器的压力；
5. 引入了状态码，以告诉浏览器服务器最终处理该请求的情况；

缺点：

1. 无连接、无状态；
2. http1.0 中只有前面的请求返回之后才能进行下一次请求，如果某个请求没有及时返回，会引起http层的队头阻塞；
3. HTTP1.0认为每台服务器都绑定一个唯一的IP地址，因此一个服务器只能支持一个域名；
4. 存在浪费带宽的现象。例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了。

三、HTTP 1.1（1997）

相对于1.0的改进：

1. 增加了持久连接。HTTP/1.0中默认使用Connection: close。在HTTP/1.1中已经默认使用Connection: keep-alive，减少了连接建立和释放的开销；
2. 增加了host字段。HTTP1.0认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报错（400 Bad Request）。
3. 增加了新的状态码100（继续）。100 表示请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分，正在等待其余部分。在发请求体之前先用请求头试探一下服务器，看服务器要不要接收请求体，再决定要不要发请求体。
4. 在一个TCP连接上可以传送多个HTTP请求和响应，但服务器必须按照客户端请求的先后顺序依次回送响应的结果（不允许同时存在两个并行的响应），以保证客户端能够区分出每次请求的响应内容。
5. 提供了范围请求功能(带宽优化)。http1.1在请求头中增加了range字段，它允许请求资源的某个部分，响应的状态码是206（partial content）。
6. 新增了24个错误状态码。如409(conflict)表示请求的资源与资源的当前状态发生冲突；410表示服务器上的某个资源被永久删除；
7. 新增缓存处理字段。引入了实体标签e-tags和Cache-control

缺点：

•  http层的队头阻塞问题。一个tcp连接中同一时刻只能处理一个请求，在当前的请求还没结束之前，其它请求只能处于阻塞状态。

四、HTTP 2.0（2015）

相对于1.1的改进：

• （1）引入二进制分帧层。二进制分帧层是http2.0性能增强的核心。http1.x在应用层以纯文本的形式进行通信，而http2.0将所有的传输信息分割为更小的消息和帧，并对它们采用二进制格式编码。

1. 帧：http2.0通信的最小单位。通过首部的流标识符对数据进行顺序标识；
2. 消息：由一个或多个帧组成，指逻辑上的http消息，如请求、响应。
3. 流：可以承载双向的消息（双向指响应和请求，如http请求是一个流，响应是一个流）。每个流有唯一的整数标识符，为了防止两端流id冲突，客户端发起的流具有奇数ID，服务端发起的流具有偶数ID；
4. 每个数据流以消息的形式发送，而消息由一个或多个帧组成。这些帧可以乱序发送，然后根据每个帧首部的流标识符重新组装。

• （2）使用了多路复用技术。所有的HTTP2.0通信都在一个TCP连接上完成，这个连接可以承载任意数量的双向数据流。每个数据流拆分成互不依赖的帧，这些帧可以乱序发送(还可以分优先级发送)，最后在接收端根据每个帧首部的流标识符把他们重新组合起来。
• （3）头部压缩。http1.x每次通信(请求/响应)都会携带首部信息。http2.0要求客户端和服务器端各自缓存一份首部表，因此每次通信都不需要再携带首部，新增的键值会更新到表尾；此外，http2.0使用了头部压缩技术，可以让报头更紧凑，更快速传输（与gzip压缩不同，gzip是对报文内容压缩，不是头部）。
• （4）请求优先级。可以为关键请求标上请求的优先级，服务器会优先处理优先级高的请求。0表示最高优先级。
• （5）服务端推送。服务端可以根据客户端的请求，提前返回多个响应，推送额外的资源给客户端。只需发送一次请求，服务端可推送多次资源。（与 Websocket 消息推送有很大的不同）

过程：

1. push_promise帧是服务端向客户端有意推送资源的信号；
2. 如果客户端不需要服务端推送资源，可以在settings帧中设定服务端流的值为0，禁用此功能；
3. 如果客户端对于push_promise帧没有意见，服务端在push_promise帧后，发送data帧开始推送资源；

限制：

1. 推送资源必须对应一个请求
2. 所有的推送资源都必须遵守同源策略；
3. push_promise帧必须在返回响应之前发送，以免客户端出现竞态条件；

当两个线程竞争同一资源时，如果对资源的访问顺序敏感，就称存在竞态条件

缺点：

1.  tcp队头阻塞问题：由于单个数据包的丢失，而造成的阻塞；
2. tcp建立连接的超时：tcp三次握手也是影响传输效率的一个因素；

1）HTTP/1.1 中获取资源示意图： 每次请求都要建立连接

当网页使用了许多资源:HTML、样式表、脚本、图片等等。在HTTP/1.x中这些资源每一个都必须明确地请求。

2） HTTP/2 中获取资源示意图（服务器端推送）：只需发送一次请求

 在 Stream 1 中服务端基于 PUSH_PROMISE 帧告诉客户端 singwa.css 和 singwa.js 资源即将推送；

并且 Stream 1、Stream 2、Stream 3 可以并行推送（备注：不同 Stream 间可以并行发送，同一个 Stream 内的数据是有序的串行）。

五、HTTP 3.0（2020）

http3.0使用了QUIC协议。谷歌在UDP基础上改造一个具备TCP协议优点的新协议QUIC协议（Quick UDP Internet Connections），直译为快速UDP互联网连接。例如，实现了类似TCP的多路数据流、传输可靠性等；

QUIC协议的特点：

1. 实现了类似tcp的流量控制、传输可靠性的功能；
2. 集成了TLS加密功能；
3. 实现了http2.0中多路复用功能。不同的是QUIC实现了在同意物理连接上可以有多个独立的逻辑数据流，实现了数据流的单独传输，解决了TCP层队头阻塞的问题。
4. 实现了快速握手功能。QUIC是基于UDP的，所以QUIC可以实现使用0-RTT或1-RTT来建立连接。RTT (Round-Trip Time)，也就是数据包一来一回的时间消耗。

缺点：

•  服务器和浏览器都没有对HTTP3提供比较完整的支持；
• 很多网络设备对于UDP数据包做了很多不友好的策略，进行拦截从而导致成功连接率下降。

（1） TCP层队头阻塞问题

队头阻塞 Head-of-line blocking（缩写为HOL blocking），如果其中某个包丢失了，就必须等待重传，从而出现某个丢包数据阻塞整个连接的数据使用。

• 队头阻塞问题可能存在于HTTP层和TCP层，在HTTP1.x时两个层次都存在该问题。
• HTTP2.0协议的多路复用机制解决了HTTP层的队头阻塞问题，但是在TCP层的队头阻塞问题仍未解决。
• HTTP3.0的QUIC协议是基于UDP协议实现的，在一条链接上可以有多个流，流与流之间是互不影响的，当一个流出现丢包影响范围非常小，从而解决TCP层队头阻塞问题。

 （2）0RTT 建立连接 

 RTT包括三部分：往返传播时延、网络设备内排队时延、应用程序数据处理时延。

一般来说HTTPS协议要建立完整链接包括:TCP握手和TLS握手，总计需要至少2-3个RTT，普通的HTTP协议也需要至少1个RTT才可以完成握手。

QUIC协议可以实现在第一个包就可以包含有效的应用数据，从而实现0RTT。QUIC的0RTT也是需要条件的，对于第一次交互的客户端和服务端0RTT也是做不到的，毕竟双方完全陌生。因此，QUIC协议在非首次连接可以实现0RTT。

• 客户端和服务端首次连接时服务端传递了config包，里面包含了服务端公钥和两个随机数，客户端会将config存储下来，后续再连接时可以直接使用，从而跳过这个1RTT，实现0RTT的业务数据交互。
• 客户端保存config是有时间期限的，在config失效之后仍然需要进行首次连接时的密钥交换。

 

补充：如何用UDP协议来实现TCP协议的主要功能？

基于UDP主体将TCP的重要功能转移到用户空间来实现，从而绕开内核实现用户态的TCP协议，但是真正实现起来还是非常复杂的。