HTTP1.1——HTTP2.0——HTTP3.0

Posted 2021-09-17 _BitterSweet

HTTP版本演变

• HTTP1.1优化1.0，但存在性能瓶颈
• HTTP2.0优化1.1的性能瓶颈
• • 1.头部压缩
  • 2.二进制格式
  • 3.数据流
  • 4.多路复用
  • 5.服务器推送
• HTTP3.0优化HTTP2.0的缺陷
• • 1.HTTP3.0把TCP换成了UDP
  • 2.QUIC协议

HTTP1.1优化1.0，但存在性能瓶颈

HTTP1.1相比HTTP1.0性能上的改进

1. 使用TCP长连接的方式改变了1.0短链接造成的性能开销
2. 支持管道网络传输，只要第一个请求发出去了，不必等待回来，就可以发第二个请求出去，减少整体的响应时间

HTTP1.1的性能瓶颈

1. 请求/响应头部未经压缩就发送，首部信息越多延迟越大，只能压缩Body部分
2. 发送冗长的首部，每次互相发送相同的首部造成的浪费较多
3. 服务器是按照请求的顺序响应的，如果服务器响应慢，会导致客户端请求不到数据，也就是队头阻塞
4. 没有请求优先级控制
5. 请求只能从客户端开始，服务器只能被动响应

HTTP2.0优化1.1的性能瓶颈

1.头部压缩

• 2.0会压缩头部，如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分
• 这就是所谓的HPACK：头部压缩算法：在客户端和服务器同时维护一张头信息表，所i有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就可以提高速度了。

2.二进制格式

• 2.0不像1.1中的纯文本形式，全面采用二进制格式，头信息和数据体都是二进制，并且统称为帧：头信息帧和数据帧
  
• 计算机只懂二进制，收到报文后，不需要再将明文的报文转成二进制，而是直接解析二进制报文，增加了数据传输的效率

3.数据流

• HTTP2.0的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应
• 每个请求或回应的所有数据包，称为一个数据流。每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数，服务端发出的数据流编号为偶数
• 客户端还可以指定数据流的优先级。优先级高的请求，服务器就优先响应该请求
  

4.多路复用

• 2.0可以在一个连接请求中并发处理多个请求或者回应，不用按照顺序一 一对应
• 移除了1.1中的串行请求，不需要排队等待，也就不会再出现队头阻塞的问题，降低了延迟，大幅度提高了连接的利用率
• 比如说在一个TCP连接里，服务端同时收到客户端A,B两个请求，发现处理A十分耗时，就回应A请求已经处理好的部分，接着回应B的请求，完成后，再回应A请求剩下的部分

5.服务器推送

• 2.0在一定程度上改善了传统的请求——应答模式，服务不再是被动地响应，也可以主动向客户端发送消息
• 在浏览器请求html的时候，就提前把可能会用到的JS，CSS文件等静态资源主动发给客户端，减少延时的等待，也叫服务器推送（Server Push）

HTTP3.0优化HTTP2.0的缺陷

• HTTP2.0缺陷：如果多个HTTP请求复用一个TCP连接，下层的TCP协议是不知道有多少个HTTP请求的。一旦发生了丢包现象，就会触发TCP的重传机制，这样在一个TCP连接中的所有的HTTP请求都必须等待这个丢了的包重传回来
• HTTP1.1中的管道传输中如果有一个请求阻塞了，那么队列后请求也被统统阻塞
• HTTP2.0多个请求复用一个TCP连接，一旦丢包，就会阻塞住所有的HTTP请求

1.HTTP3.0把TCP换成了UDP

• UDP发生是不管顺序的，也不管丢包的，所以不会出现HTTP1.1的队头阻塞和HTTP2.0中的一个丢包全部重传问题

2.QUIC协议

• UDP虽然不可靠，但是基于UDP的QUIC协议可以实现类似TCP的可靠性传输
• QUIC有自己的一套机制可以保证传输的可靠性的，当某个流发生丢包时，只会阻塞这个流，其它流不受影响
• TLS3升级成了 1.3 版本，头部压缩算法变为 QPack
• HTTPS要建立一个连接，要花费6次交互，先是建立三次握手，然后是TLS/1.3的三次握手。QUIC直接把以往的TCP和 TLS/1.3的6次交互合并为3次，减少了交互次数
  
• QUIC是一个在UDP之上的伪 TCP + TLS + HTTP/2.0的多路复用的协议
• QUIC 是新协议，现在的普及率还不高