Http2.0和Http3.0

1. http2.0，或许是一个过渡协议

a. 它兼容1.1版本，2015年左右发布，目前部分知名网站已经开始使用，它依然基于TCP协议，主要focus on performance。

b.  很多请求都是头部很多内容，实际传输的内容很少，所以http2.0做了头部压缩。不过 HTTP/2 并没有使用传统的压缩算法，而是开发了专门的“HPACK”算法，“HPACK”算法是专门为压缩 HTTP 头部定制的算法，与 gzip、zlib 等压缩算法不同，它是一个“有状态”的算法，需要客户端和服务器各自维护一份“索引表”，也可以说是字典，压缩和解压缩就是查表和更新表的操作

• 这里注意http2中没有请求/响应行的概念了，都抽象为虚拟头，与其他头部一起放到索引表中管理。常见的头放到静态表中，新增的头，放到动态表中。
• 大致原理是，第一次发送请求时的“user-agent”字段长是一百多个字节，用哈夫曼（第一次这个内容还是全量的，所以需要哈夫曼编码压缩）压缩编码发送之后，客户端和服务器都更新自己的动态表，添加一个新的索引号“65”。那么下一次发送的时候就不用再重复发那么多字节了，只要用一个字节发送编号就好。

c. 二进制方式传输，（注意这里并没有加密），它把 TCP 协议的部分特性挪到了应用层，把原来的“Header+Body”的消息“打散”为数个小片的二进制“帧”（Frame），用“HEADERS”帧存放头数据、“DATA”帧存放实体数据。

d.　虚拟流的概念

• HTTP/2 为此定义了一个“流”（Stream）的概念，它是二进制帧乱序的双向传输序列，同一个消息往返的帧会分配一个唯一的流 ID。多个请求对应多个流ID，从而实现多路复用的目的，所以server不需要保持多个TCP链接，server端响应能力更好，以前需要为每一个客户端维持6个TCP的状态信息，现在只需要一个即可。
• 流还可以设置优先级，比如有些关键资源（js，css）可以优先发送
• HTTP/2 还在一定程度上改变了传统的“请求 - 应答”工作模式，服务器不再是完全被动地响应请求，也可以新建“流”主动向客户端发送消息，一定程度的双工。
• 多个请求对应多个流ID，不在是以前的串行发送了，可以一起发送，某个流的数据包全部收到了之后，就可以组装给上层应用使用了。某个流的数据被卡住或者丢包重串，不影响其他流，这就在应用层解决了对头阻塞的问题（注意这里TCP的阻塞依然存在）

e. 2015年发布http2的时候，TLS1.3还没有发布，所以只要求使用使用TLS1.2以上的协议，默认比1.1要求的更高，默认需要使用https加密传输。

注意：

http1.1里面的一些优化手段，对于2.0来说，可能起到反作用。比如合并js，css，雪碧图等。因为过大的文件，容易导致缓存失效，其中一个单元修改了，整个缓存就得重新获取。

更多的TCP连接，也对server端不友好，更小的资料，往往会很快会被使用，更快地给UI呈现。

2. Http3.0，真正的下一代可靠的高速应用层通信技术

a. http2中始终在使用TCP协议，所以无论如何都还是会有tcp传输层的对头阻塞问题，而http3彻底解决对头阻塞的问题，正式版本2022年6月6日发布。

• 让我们从协议栈的角度来仔细看一下。在 HTTP/2 把多个“请求 - 响应”分解成流，交给 TCP 后，TCP 会再拆成更小的包依次发送（其实在 TCP 里应该叫 segment，也就是“段”）。在网络良好的情况下，包可以很快送达目的地。但如果网络质量比较差，像手机上网的时候，就有可能会丢包。而 TCP 为了保证可靠传输，有个特别的“丢包重传”机制，丢失的包必须要等待重新传输确认，其他的包即使已经收到了，也只能放在缓冲区里，上层的应用拿不出来，只能“干着急”。比如这个流有3个包，现在收到了2个包，还有一个包没有收到，就会一直等，超时后还会要求重传。
• 在比如，这里有2个请求，就会有2个stream，我们假定他们编号是stream1，stream2，然后stream1被TCP拆分为p1-1，p1-2，p1-3，共3个包，stream2被TCP拆分出p2-1，p2-2 两个包。流拆包时可能时乱顺（可能会有优先级）给TCP传输的，比如p1-1，p1-2，p2-1，p1-3，p2-2的顺序。这样假如网络不好在传p1-3时候，一直没有收到确认收到的ACK消息，就会一直等，可能等到超时重传p1-3，这样p2-2就一直不能传输，而p2-1就只能呆在缓存区静静的等待，就导致了阻塞。

b.  所以google又（google在web协议发展中，总是领先推出一些协议，成为既定事实后，再由标准化组织给他正名，写入RFC）重新推了QUIC协议，彻底放弃使用TCP协议，而使用基于UDP的QUIC协议。

c. UDP协议不需要3次握手和4次挥手，所以天然比TCP协议快。

d. 同时2018年TLS1.3版本发布，可以获取更好的加密性能。QUIC 内含了 TLS1.3，只能加密通信，支持 0-RTT 快速建连；

e. QUIC协议自定义了连接机制，在IP地址发送变化，只要双方的通信Id没变，就会保持连接，特别适合移动互联网容易断网切网的应用场景， 不会像tcp那样不能变ip和port，如果变了就要重新建立耗时的TCP连接。

f. QUIC自定义重传机制，由于TCP重传机制算法不够优秀，往往不准确超时时间，所以QUIC使用自增ID计算，更好的计算出了重传时间。

g. 离开了TCP的底层重传，流之间没有依赖，包之间没有依赖，真正实现了多路复用，告诉传输数据。

h. 自定义流量控制，采用滑动窗口协议与http2相同。