Http协议不同版本的区别

Http协议不同版本的区别

请添加图片描述

HTTP/0.9/1.0/1.1/2.0

1.0 1.1 2.0
长连接 需要使用keep-alive 参数来告知服务端建立一个长连接 默认支持 默认支持
HOST域 ✔️ ✔️
多路复用 - ✔️
数据压缩 使用HAPCK算法对header数据进行压缩,使数据体积变小,传输更快
服务器推送 ✔️

http0.9特性

  • 只有GET方法
  • 使用ASCII字符流传输

http1.0特性

  • 添加请求头和响应头,Accept-* <=> Content-*字段

  • 添加HTTP版本号

    但是

  • 无状态:服务器不跟踪不记录请求过的状态

  • 无连接:浏览器每次请求都需要建立tcp连接

无状态

对于无状态的特性可以借助cookie/session机制来做身份认证和状态记录

无连接

无连接导致的性能缺陷有两种:

1. 无法复用连接
每次发送请求,都需要进行一次tcp连接(即3次握手4次挥手),使得网络的利用率非常低

2. 队头阻塞
http1.0规定在前一个请求响应到达之后下一个请求才能发送,如果前一个阻塞,后面的请求也给阻塞的

http1.1特性

为了解决http1.0的性能缺陷,http1.1出现了

http1.1特性:

  • 长连接:新增Connection字段,可以设置keep-alive值保持连接不断开; Host头字段,对虚拟主机的支持
  • 管道化:基于上面长连接的基础,管道化可以不等第一个请求响应继续发送后面的请求,但响应的顺序还是按照请求的顺序返回
  • 缓存处理:新增字段cache-control
  • 断点传输

长连接

http1.1默认保持长连接,数据传输完成保持tcp连接不断开,继续用这个通道传输数据

管道化

基于长连接的基础,我们先看没有管道化请求响应:

tcp没有断开,用的同一个通道

请求1 > 响应1 --> 请求2 > 响应2 --> 请求3 > 响应3

管道化的请求响应:

请求1 --> 请求2 --> 请求3 > 响应1 --> 响应2 --> 响应3

即使服务器先准备好响应2,也是按照请求顺序先返回响应1

虽然管道化,可以一次发送多个请求,但是响应仍是顺序返回,仍然无法解决队头阻塞的问题

缓存处理

当浏览器请求资源时,先看是否有缓存的资源,如果有缓存,直接取,不会再发请求,如果没有缓存,则发送请求

通过设置字段cache-control来控制

断点传输

在上传/下载资源时,如果资源过大,将其分割为多个部分,分别上传/下载,如果遇到网络故障,可以从已经上传/下载好的地方继续请求,不用从头开始,提高效率

在 Header 里两个参数实现的,客户端发请求时对应的是 Range 服务器端响应时对应的是 Content-Range

http2.0特性

  • 二进制分帧
  • 多路复用: 在共享TCP链接的基础上同时发送请求和响应
  • 头部压缩 : HTTP 2.0会对HTTP的头进行一定的压缩,将原来每次都要携带的大量key value在两端建立一个索引表,对相同的头只发送索引表中的索引。
  • 服务器推送:服务器可以额外的向客户端推送资源,而无需客户端明确的请求

二进制分帧

将所有传输的信息分割为更小的消息和帧,并对它们采用二进制格式的编码。常见的帧有Header帧,用于传输Header内容,并且会开启
个新的流。再就是Data帧,用来传输正文实体。多个Data帧属于同一个流。

多路复用

基于二进制分帧,在同一域名下所有访问都是从同一个tcp连接中走,http消息被分解为独立的帧,乱序发送,服务端根据标识符和首部将消息重新组装起来

http协议区别

  1. http1.0 到http1.1的主要区别,就是从无连接到长连接
  2. http2.0对比1.X版本主要区别就是多路复用

例如我们的一个页面要发送三个独立的请求,一个获取css,一个获取js,一个获取图片jpg。如果使用HTTP1.1就是串行的,如果使用HTTP2.0就可以在一个连接里通过发送多个请求和回应,且不用按照顺序一一对应。

img

HTTP2.0将三个请求变成三个流,将数据分成帧,乱序发送到一个TCP连接中。

imgHTTP2.0解决了HTTP1.1队首阻塞问题,同时不需要通过HTTP1.x的pipeline机制用多条TCP连接实现并行请求与响应;减少了TCP连接数对服务器性能的影响,同时将页面的多个数据通过已给数据连接进行传输,加快页面的传输速度。

QUIC协议

HTTP 2.0虽然大大增加了并发性,但还是有问题的。因为HTTP 2.0也是基于TCP协议的**,TCP协议在处理包时是有严格顺序的。**

**当其中一个数据包遇到问题,TCP连接需要等待这个包完成重传之后才能继续进行。**虽然HTTP 2.0通过多个stream,使得逻辑上一个TCP连接上的并行内容,进行多路数据的传输,然而这中间并没有关联的数据。一前一后,前面stream 2的帧没有收到,后面stream 1的帧也会因此阻塞。

于是,就又到了从TCP切换到UDP,进行“城会玩”的时候了。这就是Google的QUIC协议。

机制一:自定义连接机制

TCP连接是通过四元组标识的,即源IP、源端口、目的IP、目的端口。一旦其中一个元素发生变化,需要断开重连。在移动互联情况下,当手机信号不稳定时,都会导致重连,即进行三次握手,导致时延。

基于UDP就可以在QUIC自己的逻辑里维护连接的机制,不再以四元组标识,而是以一个64位的随机数作为ID来标识。所以当IP或端口变化时,只要ID不变,就不需要重连。

机制二:自定义重传机制

TCP为了保证可靠性,使用序号和应答机制,来解决顺序问题和丢包问题。

任何一个序号的包都要在一定的时间内应答,否则超时重发。超时时间怎么定合适呢? 它是通过采样往返时间RTT(Round-trip time)不断调整。

但是TCP的超时采样不准确。QUIC的超时采样相对准确。

机制三:无阻塞的多路复用

同一条QUIC连接上可以创建多个stream,来发送多个HTTP请求。QUIIC基于UDP,一个连接上的多个stream之间没有依赖。假如stream2丢了一个UDP包,后面跟着stream3的一个UDP包,虽然stream2需要重传,但是stream3无需等待。

机制四:自定义流量控制

TCP的流量控制是通过滑动窗口协议。QUIC的流量控制也是通过window_update,来告诉对端它可以接受的字节数。但是QUIC的窗口是适应自己的多路复用机制的,不但在一个连接上控制窗口,还在一个连接中的每个stream控制窗口。

协议小结

  1. HTTP协议虽然很常用,也很复杂,重点记住GET、POST、PUT、DELETE这几个方法,以及重要的首部字段;
  2. HTTP2.0通过头压缩、分帧、二进制编码、多路复用等技术提升性能;
  3. QUIC协议通过基于UDP自定义的类似TCP的连接、重试、多路复用、流量控制技术,进一步提升性能。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇
下一篇>>