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协议区别
- http1.0 到http1.1的主要区别，就是从无连接到长连接
- 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控制窗口。
协议小结
- HTTP协议虽然很常用，也很复杂，重点记住GET、POST、PUT、DELETE这几个方法，以及重要的首部字段；
- HTTP2.0通过头压缩、分帧、二进制编码、多路复用等技术提升性能；
- QUIC协议通过基于UDP自定义的类似TCP的连接、重试、多路复用、流量控制技术，进一步提升性能。
