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开始.

对于一个需要重复发送的字段,在第一次在动态表构建好后,客户端和服务器的动态表中都会生成该字段的索引,在之后再使用该字段及该字段的值时会利用索引代替,这样就避免了大量重复的字符串去占用空间的问题.

但动态表的大小不能无线扩大,否则会造成服务器性能变差.因此服务器会提供一种配置来限制动态表的最大大小.

利用静态表,动态表和Huffman编码来对HTTP报文的头部进行压缩.

二进制数据帧

HTTP/2将HTTP/1.1中的纯文本格式改进为二进制格式的数据,提高了HTTP传输效率.

HTTP/2中数据包被划分为两种类型的帧:首部和消息负载.

其中,帧头只有9个字节,其中前3个字节表示数据帧的长度,后面的帧类型表示数据帧的传输类型:数据帧/控制帧,标志位用于携带简单的控制信息,流标识符就是Stream ID,用以区分一个数据包属于哪个数据流,其中首位保留不用.

帧数据中存放的是利用HPACK算法压缩的头部和数据.

并发传输

HTTP/1.1中存在响应报文队头阻塞的问题,HTTP/2解决了HTTP/1.1中的队头阻塞问题,可以实现在一个连接中并发传输.

HTTP/2实现并发传输的关键是Stream,一个连接中可以并发传输多个Stream,一个Stream中可以有多个Message,一个Message中含有多个Frame,Frame是以二进制格式压缩的内容(头部和数据).一个连接中,不同Stream的数据帧时可以乱序发送的,由Stream ID用以区分不同的数据帧,其中客户端数据帧的Stream ID是奇数,服务器是偶数.同时Stream ID是递增的,而不会发生重复.所以当Stream ID递增到某一个上界时,会通过一个控制帧来关闭该连接,同时HTTP/2中还可以为不同的数据帧设置优先级(在帧的帧头的标志位中描述)

不同的Stream中的帧(Frame)是可以乱序发送的,因为有Stream ID保障,但同一个Stream中的帧必须是严格有序的,即发送的时候是一个请求的头部就必须在接收端第一个被接收,发送的时候是一个请求的尾部就必须在接收端最后一个被接收.

服务器推送

在HTTP/2中可以实现服务器主动推送消息.具体实现为:客户端向服务器发送请求,服务器在返回响应的同时会告诉客户端接下来要推送的消息的具体的Stream ID,然后并发的发送要推送给客户端的消息.

HTTP/3

HTTP/2的不足

HTTP/2从头部压缩,二进制帧,并发传输,服务器推送等方面大幅度提升了HTTP/1.1的特性,但在队头阻塞,TCP与TLS握手延迟,网络迁移需要重新连接方面存有缺陷.

队头阻塞

HTTP/2中多个请求是可以在一个TCP连接中传输的,当TCP发生丢包重传时,整个TCP连接里的请求都需要等待丢的包重传后才能被HTTP层接收.

因为TCP是面向字节流的,所以TCP接收到的数据必须是完整且有序的,当序号较小的TCP包发生丢包后,序号较大的TCP包即使被接收HTTP层也无法从内核中获取到,必须等丢掉的包到达后才能整体被HTTP接收.这种阻塞影响的不仅仅是同一个流,而是同一个连接中的所有流.

​ 因此HTTP/2中队头阻塞问题是发生在TCP传输层的.

TCP与TLS握手延迟

发送HTTP数据前,需要经历TCP三次握手和TLS四次握手之后才能正常通信,整个过程需要消耗3RTT.另外由于TCP的拥塞控制的特性,还需要等待TCP的一个慢启动的过程.

网络迁移需要重新连接

HTTP/2中是基于四元组[源IP,源端口,目的IP,目的端口]来定位接收方的,在数据传输过程中,四元组是不发生改变的,这意味着当通信一方如果网络发生迁移(如从流量到WIFi),建立的连接就会因为IP地址的改变而断开,本次连接中发送的数据就无法到达接收方,需要重新发送.而重新连接有需要经历TCP与TLS握手的延迟.这个弊端是基于TCP建立在有连接的基础上进行通信的,因此要想优化这个弊端,就需要更换传输层协议,HTTP/3就是如此.

QUIC协议

HTTP/3采用了基于UDP的QUIC协议来代替TCP协议.UDP是面向无连接的,不可靠的一个传输层协议.且UDP是面向数据报的,对数据的顺序是无要求的.QUIC在UDP的基础上又实现了类似于TCP的连接管理,拥塞控制,流量控制等特性来实现可靠传输.

QUIC协议就可以解决HTTP/2协议中的那些弊端

无队头阻塞

因为QUIC协议是基于UDP的,UDP对数据的顺序是没有要求的,所以对于不同Stream中的帧,即使发生丢包现象,也只会影响这一个Stream中的数据的到达(因为同一个Stream中的帧是要求严格有序的),而不会影响其他Stream中数据的到达.

更快的连接建立

对于HTTP/3之前的HTTP协议,TCP和TLS是分层的,分别属于内核实现的传输层和openssl库实现的表示层,因此需要先TCP握手,再TLS握手

而HTTP/3在传输前需要进行QUIC握手,这个握手只耗费1个RTT,为了确定客户端和服务器的[连接ID],而因为HTTP/3中每个帧中会携带TLS的记录,且HTTP/3采用的是TLS1.3,所以QUIC握手和TLS握手同时进行,耗费1RTT,甚至在第二次连接时采用会话复用实现0RTT建立连接

连接迁移

HTTP/3之前的协议是基于四元组确认TCP连接,这种连接会随着网络迁移而断开,QUIC协议是基于连接ID来确认连接的.因此即使因为网络环境变化导致IP地址变化,只要上下文信息不会令连接ID改变,连接就不会断开.

HTTP/3协议

HTTP/3采用的也是二进制数据帧,与HTTP/2不同的是,HTTP/3可以直接使用QUIC协议提供的Stream,而不需要在帧头中添加关于Stream的标识

在进行头部压缩时,HTTP/3对头部压缩算法进行了升级:QPACK ,QPACK也采用了静态表,动态表和Huffman编码,与HTTP/2不同的是,HTTP/3中QPACK的静态表中的选项从61扩展到了91项,且动态表的使用也与HTTP/2有所差异.

HTTP/2在首次发送协议后客户端和服务器会将静态表中没有包含的字段更新到各自的动态表中,后续就会使用该字段对应的索引数字.但这样存在时序性问题,当首次发送的协议发生丢包时,服务器并没有更新动态表,而客户端在之后的发送过程中使用的数字索引就无法被服务器识别.

因此HTTP/3改善了这一弊端:QUIC有两个特殊的单向流,只允许一方发送消息给另一方.数据传输时使用的是双向流,这两个单向流用以更新动态表.

一个单向流负责将字典传递给对方,客户端可以将不属于静态表的字典发送给服务器

一个单向流负责响应对方,服务器通过这个单向流告知客户端自己的动态表是否已经更新.

打个比方:

HTTP/2相当于我直接给你发信息,信息里面含有我之后发信息的暗号表,之后我就直接用暗号给你发信息,没有考虑第一次对方接收不到信息的情况.

HTTP/3相当于我在通信前先把暗号表发送给你并等待你的确认通知,对方确认收到后会发送确认通知给我,当确认双方都有暗号表之后,我再用暗号发送信息给你.