HTTP/2和HTTP/3特性介绍

HTTP/2 AND HTTP/3

HTTP/2

HTTP/1.1协议的性能问题

1. 延迟难以下降:随着带宽的增加,已经达到了延迟下降的下限.
2. 并发连接有限:软件对并发数量的限制,而且每个连接都要经过TCP和TLS握手耗时,以及TCP慢启动过程给流量带来的影响.
3. 队头阻塞问题:同一连接中只能在完成一个事务(请求和响应)后,才能进行下一个事务
4. 头部巨大且重复:因为HTTP是无状态的,所以每个数据包都需要携带头部.
5. 服务器不能主动推送:服务器不能主动向客户端发送消息,客户端需要获取通知时,还需要客户端主动向服务器定时发送请求.

兼容HTTP/1.1

HTTP/2兼容了HTTP/1.1,在用户使用方面,url的格式没有发生改变,只是在背后升级协议,使协议进行了平滑的升级;只在应用层作了改变,在传输层还是基于TCP传输的,在应用层又分为语义和语法两部分,语义不改动,大幅度改动了语法部分

头部压缩

HTTP协议是由Header+Body两部分组成,Body部分可以通过字段Content-Encoding提供的压缩方法进行压缩,但并没有压缩头部.

HTTP/1.1报文中Header部分存在的问题

1. 含有很多固定的字段,这些字段应该被压缩
2. 请求和响应报文中有很多重复的字段,应该避免重复字段占用冗余空间
3. 字段是ASCII编码,应该改为二进制编码

HTTP/2开发了HPACK算法来对报文的头部进行压缩.HPACK算法包括三部分:

1. 静态字典

2. 动态字典

3. Huffman编码

   客户端和服务器会维护字典,用一个长度较小的索引去代替重复的字符串,再用Huffman压缩数据.

静态表编码

HTTP/2为高频出现在头部的字段和字符串建立了一张静态表,这个表不会变化,共有61组,有Index(索引),Header Name(字段名),Header Value(字段值)

对于静态表中只有字段名而无字段值的数据,会根据Huffman编码动态生成一个数据.

动态表编码

不在静态表中出现的字段会在动态表中构建,动态表是实时更新的,索引从62开始.

对于一个需要重复发送的字段,在第一次在动态表构建好后,客户端和服务器的动态表中都会生成该字