快速掌握HTTP1.0 1.1 2.0 3.0的特点及其区别( 二 ) 作者公众号：org_yijiaoqian

多路复用（链接共享）— 真并行传输

流（stream）：已建立连接上的双向字节流。
消息：与逻辑消息对应的完整的一系列数据帧。
帧（frame）：HTTP2.0通信的最小单位，每个帧包含头部，至少也会标识出当前所属的流（stream_id）

所有HTTP2.0通信都在一个TCP链接上完成，这个链接可以承载任意流量的双向数据流。
每个数据流以消息的形式发送，而消息由一或多个帧组成。这些帧可以乱序发送，然后再根据每个帧头部的流标识符（Stream_id）重新封装。
多路复用（连接共享）可能会导致关键字被阻塞， HTTP2.0里每个数据流都可以设置优先级和依赖，优先级高的数据流会被服务器优先处理和返回客户端，数据流还可以依赖其他的子数据流。
可见， HTTP2.0实现了真正的并行传输，它能够在一个TCP上进行任意数量的HTTP请求。而这个强大的功能基于“二级制分帧”的特性。
头部压缩在HTTP1.X中，头部元数据都是以纯文本的形式发送的，通常会给每个请求增加500-8000字节的负荷。
比如cookie ，默认情况下，浏览器会在每次请求的时候，把cookie附在header上面发给服务器。
HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header_files表，既避免重复header的传输，又减少了需要传输的大小。
高效的压缩算法可以很大的压缩header ，减少发送包的数量从而降低延迟。
服务器推送服务器除了最初请求的响应外，服务器还可以额外向客户端推送资源，而无需客户端明确的需求。
HTTP3.0Google搞了一个基于UDP协议的QUIC协议，并且使用在了HTTP/3上，HTTP/3之前的名称为HTTP-over-QUIC 。
早期Quic协议，存在IETF和Google两个版本，直到它被证实命名为HTTP3.0
IETF的QUIC工作小组创造了QUIC传输协议。 QUIC是一个使用UDP来替代TCP的协议。最初的时候， Google开始助力QUIC ，其后QUIC更多地被叫做“HTTP/2-encrypted-over-UDP “ 。
社区中的人们已经使用非正式名称如iQUIC和gQUIC来指代这些不同版本的协议，以将QUIC协议与IETF和Google分开（因为它们在细节上差异很大）。通过“iQUIC”发送HTTP的协议被称为“HQ”（HTTP-over-QUIC）很长一段时间。
2018年11月7日， Litespeed的Dmitri宣布他们和Facebook已经成功地完成了两个HTTP/3实现之间的第一次互操作。 Mike Bihop在该主题的HTTPBIS会话中的后续介绍可以在这里看到。会议结束时达成共识称新名称是HTTP/3！
0-RTT — QUIC协议相比HTTP2.0的最大优势缓存当前会话的上下文，下次恢复会话的时候，只需要将之前的缓存传递给服务器，验证通过，就可以进行传输了。
0-RTT建连可以说是QUIC相比HTTP2最大的性能优势。
什么是0-RTT建连？

传输层0-RTT就能建立连接
加密层0-RTT就能建立加密连接

多路复用QUIC基于UDP ，一个连接上的多个stream之间没有依赖，即使丢包，只需要重发丢失的包即可，不需要重传整个连接。
更好的移动端表现QUIC在移动端的表现比TCP好，因为TCP是基于IP识别连接，而QUIC是通过ID识别链接。无论网络环境如何变化，只要ID不便，就能迅速重新连上。
加密认证的根文 — 武装到牙齿TCP协议头没有经过任何加密和认证，在传输过程中很容易被中间网络设备篡改、注入和窃听。
QUIC的packet可以说武装到了牙齿，除了个别报文，比如PUBLIC_RESET和CHLO ，所有报文头部都是经过认证的，报文Body都是经过加密的。
所以只要对 QUIC 做任何更改，接收端都能及时发现，有效地降低了安全风险。
向前纠错机制QUIC协议有一个非常独特的特性，称为向前纠错（Foward Error Connec ， FEC），每个数据包除了它本身的内容之外还包括了其他数据包的数据，因此少量的丢包可以通过其他包的冗余数据直接组装而无需重传。