文章目录
- 引言
- 正文
- HTTP/1.1与HTTP/1.0
- 1、长连接代替短链接
- 2、管道传输
- 缺点
- HTTP2.0和HTTP1.1
- 1、头部压缩
- 2、二进制格式
- 3、并发传输
- 4、服务器主动推送资源
- 缺点
- HTTP/3和HTTP/2
- 1、无队头阻塞
- 2、更快的连接建立
- 3、连接迁移
- 面试题
- 1、HTTP是长连接还是短链接?
- 2、HTTP长连接和短链接有什么区别?
- 3、HTTP/1.0和HTTP/1.1有什么区别?
- 4、HTTP/2.0和HTTP/1.1有什么区别?
- 5、HTTP/2.0和HTTP/3.0有什么区别?
- 总结
引言
- 最近面试总是被问到关于HTTP/2、HTTP/3的改进等等,之前学过,但是忘得有点多,这里回顾一下,做一下总结!
正文
HTTP/1.1与HTTP/1.0
1、长连接代替短链接
简介
- 使用长连接的方式改善了HTTP/1.0短链接造成的性能开销
- 长连接,只要任意一端没有明确提出断开连接,则保持TCP连接状态。
具体使用
- 通过connection字段,Keep-Alive值实现
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中的帧必须要是的严格有序的
总结
- 通过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的连接
- 本质还是利用TCP连接
- 利用的是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年才被标准化,而且暂时没有很普及!以后有机会回去好好了解的!
- 继续加油,看看还有哪些知识是忘记了,赶快拾起来!