HTTP3.0(QUIC的实现机制)

Posted 2021-01-26 chenjinxinlove

回顾HTTP2.0

HTTP1.1在应用层以纯文本的形式进行通信，每次通信都要带完整的HTTP的头，而且不考虑pipeli模式的化，每次的过程总是像上面描述的那样一去一回。那样在实时性、并发想上都存在问题

头部压缩：HTTP2.0会对HTTP的头进行一定的压缩，将原来每次都要携带的大量key value在两端建立一个索引表，对相同的头只发送索引表中的索引

HTTP2.0协议将一个TCP的连接中，切分成多个流。每个流都有自己的ID，而且流可以是客户端发服务端，也可以是服务端发客户端，它其实只是一个虚拟的通道。流是有优先级的

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

通过这两种机制，http2.0的客户端可以将对个请求不同的流中，然后将请求内容拆成帧，进行二进制传输。这些真可以打散乱序发送，然后根据每个帧首部的流标识符重新组装，并且可以根据优先级，决定先处理那个流的数据

二进制传输就是以上

例子：

假设一个页面要发送三个独立的请求，一个获取css，一个获取js，一个获取图片jpg。如果使用HTTP1.1就是串行的，但是如果使用HTTP2.0，就可以在一个连接里，客户端和服务端都可以同时发送多个请求或回应，而且不用按照顺序一对一对应

http2.0成功解决了http1.1的队首阻塞问题，同时，也不需要通过http1.x的pipeline机制用多条tcp连接来实现并行请求和响应；减少了tcp连接数对服务器性能的影响，同时将页面的多个数据css，js，jpg等通过一个数据链接进行传输，能够加快页面组件的传输速度。

QUIC协议

HTTP2.0 也是基于TCP协议的，tcp协议在处理包时是有严格顺序的

当其中一个数据包遇到问题，TCP连接需要等待找个包完成重传之后才能继续进行，虽然HTTP2.0通过多个stream，使得逻辑上一个tcp连接上的并行内容，进行多路数据的传输，然而这中间没有关联的数据，一前一后，前面stream2的帧没有收到，后面stream1的帧也会因此堵塞

于是google的 QUIC协议从TCP切换到UDP

• 机制一：自定义连接机制
  一条tcp连接是由四元组标识的，分别是源ip、源端口、目的端口，一旦一个元素发生变化时，就会断开重连，重新连接。在次进行三次握手，导致一定的延时

在TCP是没有办法的，但是基于UDP，就可以在QUIC自己的逻辑里面维护连接的机制，不再以四元组标识，而是以一个64
位的随机数作为ID来标识，而且UDP是无连接的，所以当ip或者端口变化的时候，只要ID不变，就不需要重新建立连接

• 机制二：自定义重传机制
  tcp为了保证可靠性，通过使用序号和应答机制，来解决顺序问题和丢包问题

任何一个序号的包发过去，都要在一定的时间内得到应答，否则一旦超时，就会重发这个序号的包，通过自适应重传算法（通过采样往返时间RTT不断调整）

但是，在TCP里面超时的采样存在不准确的问题。例如发送一个包，序号100，发现没有返回，于是在发送一个100，过一阵返回ACK101.客户端收到了，但是往返的时间是多少，没法计算。是ACK到达的时候减去第一还是第二。

QUIC也有个序列号，是递增的，任何宇哥序列号的包只发送一次，下次就要加1，那样就计算可以准确了

但是有一个问题，就是怎么知道包100和包101发送的是同样的内容呢？quic定义了一个offset概念。QUIC既然是面向连接的，也就像TCP一样，是一个数据流，发送的数据在这个数据流里面有个偏移量offset，可以通过offset查看数据发送到了那里，这样只有这个offset的包没有来，就要重发。如果来了，按照offset拼接，还是能够拼成一个流。

• 机制三： 无阻塞的多路复用

有了自定义的连接和重传机制，就可以解决上面HTTP2.0的多路复用问题

同HTTP2.0一样，同一条 QUIC连接上可以创建多个stream，来发送多个HTTP请求，但是，QUIC是基于UDP的，一个连接上的多个stream之间没有依赖。这样，假如stream2丢了一个UDP包，后面跟着stream3的一个UDP包，虽然stream2的那个包需要重新传，但是stream3的包无需等待，就可以发给用户。

• 机制四：自定义流量控制

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

在TCP协议中，接收端的窗口的起始点是下一个要接收并且ACK的包，即便后来的包都到了，放在缓存里面，窗口也不能右移，因为TCP的ACK机制是基于序列号的累计应答，一旦ACK了一个序列号，就说明前面的都到了，所以是要前面的没到，后面的到了也不能ACK,就会导致后面的到了，也有可能超时重传，浪费带宽

QUIC的ACK是基于offset的，每个offset的包来了，进了缓存，就可以应答，应答后就不会重发，中间的空档会等待到来或者重发，而窗口的起始位置为当前收到的最大offset，从这个offset到当前的stream所能容纳的最大缓存，是真正的窗口的大小，显然，那样更加准确。