HTTP历史版本

Posted 2021-09-20 zkccnb

HTTP历史版本

文章目录

• HTTP历史版本
• • 一、HTTP/1.0
  • • HTTP/1.0特性
  • 二、HTTP/1.1
  • • 1. 短连接与长连接
    • 2. 管道传输
    • HTTP/1.1特性
  • 三、HTTP/2.0
  • • 1. 头部压缩
    • 2. 二进制数据帧
    • 3. 数据流与多路复用
    • 4. 服务器主动推送
    • HTTP/2.0特性
  • 四、 HTTP/3.0
  • • 1. 下层采用UDP+QUIC协议
    • 2. 其他组件的优化

一、HTTP/1.0

就是最朴素的版本，后面版本先进的特性这里都没有，现在已经几乎不用了。

HTTP/1.0特性

• 不支持长连接，只有短链接
• 不支持管道传输
• 不支持服务器主动推送
• 不安全
• 不支持头部压缩
• 明文数据帧

二、HTTP/1.1

最常用的、现在普及最广的一个版本，相较于1.0主要改进了短连接的问题。

1. 短连接与长连接

什么是短连接、长连接呢？短连接意味着没发起一次请求之间都需建立一次TCP连接、服务器响应后又会触发TCP四次挥手断开连接。在频繁请求响应的情况下，这明显浪费了大量的带宽资源；长连接与之相反，在相同的TCP会话中可以进行多次HTTP请求和响应。

在HTTP/1.1之后，使用者可以自行选择采用长连接还是短连接。

图1 长连接与短连接

2. 管道传输

支持短连接后，自然可以支持管道传输，即，一个请求的响应还未到达即可发出第二个请求。（这有点类似TCP协议的改进做法）

图2 HTTP/1.1的管道传输

当需要多个请求时，这样做极大地提高了传输效率，但带来的问题是队头阻塞：试想第一个HTTP请求迟迟得不到服务器响应（此时服务器内部可能在疯狂处理请求），那后面的请求只能排队等着。那么此时会话中的一个方向是空闲的，没用数据发送，便浪费了带宽。

HTTP/1.1特性

• 支持长连接
• 支持管道传输
• 不支持服务器主动推送
• 不安全
• 不支持头部压缩
• 明文数据帧

三、HTTP/2.0

一个已经比较成熟的版本，现在大范围使用。相较于1.1，此版本做出了大量的性能改进：

1. 头部压缩

HTTP/2.0采用HPACK算法将请求头/响应头的字段存入一个头信息表中，由服务器和客户端共同维护。每个表项由一个索引和出现过的头字段组成。每次请求/响应时，查找头信息表的表项中是否已有需要的字段：如没有，则存入表中，并正常发送此字段；如有，则直接发送索引即可，对端通过查询表中索引即可得到此字段。

其实相当于对出现过的头字段进行缓存，以便下次出现时直接查找缓存，避免占用带宽发送重复的内容。

2. 二进制数据帧

HTTP/2.0之前都是采用明文数据帧，这样虽然利于人类观察阅读，但传输前必须在下层协议栈（传输层、网络层、链路层）将其转码成二进制，这也会增加传输的时间。所以这里干脆在上层（应用层）直接使用二进制格式的数据帧，无需下层协议再转码一遍，以便机器可以直接解析数据帧，增加传输效率。

3. 数据流与多路复用

数据流：

HTTP/2.0中，连续发送的HTTP报文可能不属于一个“数据流”，数据流是指已建立连接的双向字节流（一个会话）。HTTP/2.0会尽可能将多个这样的数据流放在一个TCP中，一个TCP可以接纳多个数据流，提高了传输的效率。

多路复用：

另外，HTTP/2.0可以并发的回应多个请求，而不是像之前那样串行的回应，即使服务器需要花一些时间处理上一个请求，也可以先把下一个简单的请求处理好先发走，同时慢慢处理耗时的请求。这样就避免了队头阻塞问题，更高效地利用带宽资源。

4. 服务器主动推送

HTTP/2 还在⼀定程度上改善了传统的「请求 - 应答」⼯作模式，服务不再是被动地响应，也可以主动向客户端发 送消息。这在一些场景下节约了一定带宽资源。

HTTP/2.0特性

• 支持长连接
• 支持管道传输
• 支持服务器主动推送
• 安全（强制采用HTTPS）
• 支持头部压缩
• 明文数据帧

四、 HTTP/3.0

HTTP/3.0是一个最新、但不成熟的协议，目前没有得到广泛应用。HTTP/3.0相对于之前版本做出了大胆的改进。

1. 下层采用UDP+QUIC协议

这听起来很离谱，之前TCP用得不好吗？UDP可以保证TCP的优秀特性吗？

TCP带来的问题：

HTTP/2.0引入了多路复用机制，目的是防止队头阻塞，即使第一个请求需要花较长时间处理，后面的请求也不会卡在这。这想法是好的，但是TCP在这里帮了倒忙！

TCP的超时重传机制保证：如果丢失TCP报文段，那么后面已经传过来的TCP报文段会等候丢失报文段超时重传过来，而不会交付给上层HTTP。这样，在HTTP层面看来，一旦发生丢包，就又产生了队头阻塞现象！
图3 TCP超时重传机制对上层协议栈（HTTP）的影响

可见，如果发生超时重传，那么已传过来的后序报文段会被阻塞在内核中，而不会及时交付给用户栈。对HTTP来说，同样会造成队头阻塞，HTTP/2.0的工作白忙乎了。这是下层协议的本质问题，不论在HTTP层做什么工作都无济于事，唯一的办法就是弃用TCP！

为此，HTTP/3.0使用了QUIC+UDP来代替TCP，避免了超时重传机制的同时，用QUIC协议确保其可靠传输。

2. 其他组件的优化

• 头部压缩算法升级为QPACK
• 采用QUIC+TLS/1.3协议，将建立连接握手次数从HTTP/2.0的7次压缩成3次

最后，附上重要HTTP版本的协议栈概览

图4 重要HTTP版本协议栈概览