HTTP历史版本

HTTP历史版本

一、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版本协议栈概览

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值