Http协议不同版本的区别

Posted 2022-02-04 琦彦

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就可以在一个连接里通过发送多个请求和回应，且不用按照顺序一一对应。

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

HTTP2.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的连接、重试、多路复用、流量控制技术，进一步提升性能。