quic java_HTTP3.0(QUIC的实现机制)

回顾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，就可以在一个连接里，客户端和服务端都可以同时发送多个请求或回应，而且不用按照顺序一对一对应