秋招突击——知识复习——HTTP/2、HTTP/3的改良

文章目录

引言

最近面试总是被问到关于HTTP/2、HTTP/3的改进等等，之前学过，但是忘得有点多，这里回顾一下，做一下总结！

正文

HTTP/1.1与HTTP/1.0

1、长连接代替短链接

简介

使用长连接的方式改善了HTTP/1.0短链接造成的性能开销
长连接，只要任意一端没有明确提出断开连接，则保持TCP连接状态。

具体使用

通过connection字段，Keep-Alive值实现

bash 复制代码

Connection：Keep-Alive

开启上述机制之后，就会保持连接
- 当客户端发送另外一个请求是，会使用同一个链接

2、管道传输

简介

支持管道传输，请求发送不受限制 ，不用等待第一个请求的响应回复即可发送第二个请求。、
- 但是服务器必须按照接受请求的顺序发送响应

特点

解决了请求的队头阻塞问题，但是没有解决响应的队头阻塞问题

缺点

1、首部未压缩

请求和响应的头部含有大量的冗余信息，未经压缩就发送，浪费资源延迟大。
- HTTP/1.0仅仅压缩了Body

2、队头阻塞

服务器是按照请求的顺序响应的，服务器响应慢，会出现队头阻塞问题

队头阻塞没有搞清楚！

3、被动响应

请求只能从客户端开始，服务器只能被动响应，无法主动推送。
一个网页的多个构成，可以打包多个消息一块发送吗？
基于请求，为什么不能多发几个信息？

4、无优先级控制

没有请求优先级控制

HTTP2.0和HTTP1.1

1、头部压缩

简介

如果发送多个请求，头都是一样的或者相似的，协议会帮助消除重复部分，减少冗余部分。

具体实现原理

客户端和服务端共同维护一个静态表和动态表
- 请求和响应头的信息，使用动态表和静态表中的所以索引号来发送，去除冗余消息

通过索引号代替头部信息，加快发送速度

静态表如下

2、二进制格式

简介

对头信息和数据体都采用二进制进行存储 ，并统称为帧：头信息帧 + 数据帧

作用
计算机收到报文之后，无需再转成二进制 ，少了两个步骤，加快了数据传输的速率

3、并发传输

简介

实现多个Stream复用一个TCP连接 ，借此实现并发传输
- 不用像之前的版本共用一个连接，必须等待前面的响应结束后，才能进行下一次请求响应
- 这里可以直接使用一个新的stream，相当于增加了stream（类似连接）并行工作
每一个Stream的帧都会带有当前Stream独一无二的编号 ，并行发送乱序到达也没事，会通过StreamID进行组装。

特点

多个Stream运行在一个TCP连接中
同一个HTTP请求和响应是在同一个Stream中
不同Stream的帧是可以乱序发送的，并行运行，这个具体见下图
- 同一个Stream中的帧必须要是的严格有序的

总结

通过Stream来复用连接，提高数据传输的并发性，省去了反复建立连接的握手以及断开连接的挥手开销

仍旧未解决队头阻塞问题？

HTTP/2.0是基于TCP协议来传输数据的，其实面相字节流的协议，必须保证收的字节数据是完整并且连续的才行，内核的数据才会返回给HTTP应用。
- 只要有一个数据没达到，后面的数据就一直卡在缓冲区，直到这一字节到达才行。

4、服务器主动推送资源

为什么不一次把所有信息都发送过去？

之前想的是既然请求网页了，为什么不一次把HTML还有对应的CSS文件一次全部发送过去，这样就不需要二次请求了，后来经过了解发现有以下几个问题
- 减少传输时间和带宽消耗
  - 一个网页是由CSS、HTML还有JS构成，全部打包发送，文件大传输时间增加
  - 一次发只能串行化，一个一个下载，效率太低了，分开发能够并行化下载，效率更高
- 动态内容
  - HTML、CSS和JS本身就是分离动态的，比如说用户显示的界面不一样，绑定发送复杂低效
- 报文限制
  - 报文存在限制，Nginx1MB，Tomcat是2MB，一个网页一般是超过这个限制的。

上图中，推送CSS信息，可以使用不同的Stream，这样就可以并行操作了

缺点

未能彻底解决对头阻塞问题！
还是需要建立链接和释放链接，耗费时间！
更换网络，全部作废，一切重头！

HTTP/3和HTTP/2

HTTP/2.0的原生弊端

HTTP/2.0是基于TCP实现的，所以永远解决不了
- 队头阻塞问题
- TCP和TCL建立连接的延迟
- 网络迁移需要重新链接
  - 确定一个TCP连接需要使用四元组确定，一旦任何一个改动了，都需要重新握手

HTTP/3.0为解决这个问题，使用UDP替换TCP，并实现了QUIC协议

QUIC协议特性

在应用层实现了类似TCP的连接管理、拥塞窗口、流量控制的特性
无队头阻塞
更快的链接建立
连接迁移

下面将针对上述三个特征逐个图解

1、无队头阻塞

简介

实现类似Stream的多路复用功能，但是Stream没有依赖，相互独立，某个流发生了丢包，不影响其他流
数据可靠性保证
- 每一个数据包都有一个序号，唯一标识

下述是HTTP/2.0实现的Stream

在应用层面，是已经解决了队头阻塞问题
在传输层，基于TCP的超市重传和按序到达等机制，会停在这里，知道接受完全
- 本质还是利用TCP连接
  
  下述是基于UDP的连接
利用的是UDP，不需要再受到TCP的影响，超时了，直接重传就行了，Stream是真正并行的，相互独立的

2、更快的连接建立

传统的方式

TCP层和TLC层是分层的，分别属于内核实现的传输层和用户实现的应用层
- 需要分批次握手，现TCP，然后再是TLS握手

QUIC协议

QUIC包含了TLS
- QUIC只需要两次握手 ，确认双方的链接ID
- TLS1.3,只需要一个1RTT即可

3、连接迁移

传统方式

基于四元组（源IP、源端口、目标IP、目标端口），一旦一个修改了，就需要重新建立链接

QUIC方式

通过连接ID标记通信的两个端点
- 客户端和服务端各自选择一个连接ID标记自己，即使IP变了，连接ID不变，就不受影响，直接迁移

暂时还没有推出

面试题

1、HTTP是长连接还是短链接？

HTTP 1.0 虽然支持长连接，但是默认的连接行为是短链接，从HTTP1.1版本之后，都是默认长连接了。
通过Connection:keep-Alive字段确认

2、HTTP长连接和短链接有什么区别？

短连接-用完就废 :
- 每次通信请求都需要建立新的连接，请求完成后立即关闭连接。
- 这样每次请求都需要建立连接和释放连接，会增加通信开销和延迟。
长连接-用完放着 :
- 在通信过程中保持连接的持续性，多次请求可以共享同一个连接。
- 在长连接中，客户端和服务器建立连接后可以进行多次请求和响应，减少了连接建立和释放的开销，提高了通信效率。

3、HTTP/1.0和HTTP/1.1有什么区别？

1、长链接代替短链接

HTTP/1.1默认是使用长连接，除非连接的双方其中任何一方主动关闭连接，否则会一直存在，后续请求响应可以继续使用当前存在的连接。
不需要像HTTP/1.0一样，一个请求/响应就建立一个链接，频繁的建立和销毁连接，增加系统的消耗。

2、使用管道传输信息

使用管道传输，解决的请求的对头阻塞问题，不需要像之前传输，只有上一个请求得到响应才能继续发送下一个请求。
提高请求和响应的效率。

3、增加host字段

一个物理服务器可以承载多个域名和站点。

4、HTTP/2.0和HTTP/1.1有什么区别？

通过Stream实现多路复用

引入Stream的概念，不同的HTTP请求和响应用不同的Stream来区分
多个Stream复用同一个连接，
实现了多路复用和并发，在应用层面解决了请求的队头阻塞问题和响应的队头阻塞问题，提高了通信的效率。

请求/响应头采用HPack算法压缩

对Header采用HPack算法进行压缩，客户端和服务端同时维护动态表和静态表，使用索引代替header中重复字段，提高传输的效率。

基于二进制编码传输消息体

使用二进制对消息体进行编码，提高了通信效率，服务端无需在进行二次解码！

实现了主动推动

通过stream实现主动推送资源，不需要客户端再进行二次请求，减少了请求和响应的传递次数。

5、HTTP/2.0和HTTP/3.0有什么区别？

底层基于QUIC，彻底解决了队头阻塞问题

HTTP/2.0底层虽然在应用层面解决了对头阻塞问题，但是还是使用TCP，如果某一个Stream因为丢包未收集到完整地数据，后续的Stream就会陷入阻塞！
HTTP/3.0底层使用基于UDP协议开发的QUIC协议，彻底解决了对头阻塞问题，某一个Stream因为丢包陷入阻塞，不影响其他的Stream正常运行，真正实现了并发传输！

建立连接花销小

HTTP/2.0是基于TCP的，建立连接需要三次握手以及对饮的TLS四次握手
HTTP/3.0 是基于QUIC协议，QUIC本质是基于UDP，只需要两次握手确认双方身份就行，然后QUIC中还包含了TLS1.3，只需要两次握手就能实现信息加密，最终总共需要三次握手就能实现的连接建立！

即使网络更换，仍旧能够保持原始数据

HTTP/2.0是基于TCP进行连接的，需要四元组信息来确定唯一的连接，一旦其中一个更改，就需要重新建立链接。而QUIC协议是通过彼此的连接号来确定的，即使切换了网络，也不会影响原来的连接，消除重连的成本。

总结

我说之前怎么没怎么了解过HTTP/3.0，原来是我学的时候，还没出来，他是到2022年才被标准化，而且暂时没有很普及！以后有机会回去好好了解的！
继续加油，看看还有哪些知识是忘记了，赶快拾起来！