详解HTTP1.01.12.0版本区别/优化
Posted 狱典司
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了详解HTTP1.01.12.0版本区别/优化相关的知识,希望对你有一定的参考价值。
HTTP1.0、1.1、2.0版本区别/优化
1、HTTP 1.0
- 是一种无状态,无连接的应用层协议
- 规定浏览器和服务器保持短暂的链接。
- 浏览器每次请求都需要与服务器建立一个TCP连接,服务器处理完成以后立即断开TCP连接(短连接),服务器不跟踪也每个客户单,也不记录过去的请求(无状态)。
- 这种无状态性可以借助cookie/session机制来做身份认证和状态记录。
- 存在的问题:
- 无法复用连接:每次发送请求/返回响应,都需要进行一次TCP连接,而TCP的连接释放过程又是比较费事的。这种无连接的特性会使得网络的利用率变低。
- 队头阻塞(head of line blocking):由于HTTP1.0规定下一个请求必须在前一个请求响应到达之后才能发送,假设前一个请求响应一直不到达,那么下一个请求就不发送,后面的请求就阻塞了。
Http 1.0
的致命缺点:
无法复用
TCP
连接和并行发送请求,这样每次一个请求都需要三次握手,而且其实建立连接和释放连接的这个过程是最耗时的,传输数据相反却不那么耗时。不支持文件断点续传。
本地时间被修改导致响应头
expires
的缓存机制失效的问题。
2、HTTP1.1
HTTP1.1继承了HTTP1.0的简单,克服了HTTP1.0性能上的问题。
HTTP1.1也是当前使用最为广泛的HTTP协议
- 1. 长连接:HTTP1.1增加Connection字段,通过设置Keep-Alive保持HTTP连接不断开,直到连接的某一段主动提出断开连接的请求(Connection:Close)。避免每次客户端与服务器请求都要重复建立释放建立TCP连接。提高了网络的利用率。如果客户端想关闭HTTP连接,可以在请求头中携带Connection:Close来告知服务器关闭请求。
- 2. 管道化:HTTP1.1支持请求管道化(pipelining)。基于HTTP1.1的长连接,使得请求管线化成为可能。 管线化使得请求能够“并行”传输。但需要注意的是:服务器必须按照客户端请求的先后顺序依次回送相应的结果,以保证客户端能够区分出每次请求的响应内容。
- 也就是说,HTTP管道化可以让我们把先进先出队列从客户端(请求队列)迁移到服务端(响应队列),如果,客户端同时发了两个请求分别获取html和css,假如说服务器的css资源先准备就绪,服务器也会先发送html,再发送css。 换句话来说,只有等到html响应的资源完全传输完毕后,css响应的资源才开始传输,不允许同时存在两个并行的响应。
- 可见,HTTP1.1还是无法解决队头阻塞(head of line blocking)的问题,只是把先进先出队列从客户端(请求队列)迁移到服务端(响应队列)。
- 3. RANGE:bytes字段: 是HTTP/1.1新增内容,断点续传,表示要求服务器从文件XXXX字节处开始传送。
- 4. 真并行传输 — 浏览器优化策略
- HTTP1.1支持管道化,但是服务器也必须进行逐个响应的送回,这个是很大的一个缺陷。实际上,现阶段的浏览器厂商采取了另外一种做法,它允许我们打开多个TCP的会话,也就是说,其实是不同的TCP连接上的HTTP请求和相应,这也就是我们所熟悉的浏览器对同域下并行加载6~8个资源的限制。
- 5. 缓存处理 — 强缓存、协商缓存,启发式缓存(新增)
- 此外,HTTP1.1还加入了缓存处理(强缓存和协商缓存),新的字段如cache-control,支持断点传输,以及增加了Host字段(使得一个服务器能够用来创建多个Web站点)
Http 1.1的致命缺点:
- 1.明文传输。
- 2.其实还是没有解决无状态连接的。
- 3.当有多个请求同时被挂起的时候 就会拥塞请求通道,导致后面请求无法发送(没有真正的解决队头阻塞)。
- 4.臃肿的消息首部:HTTP/1.1能压缩请求内容,但是消息首部不能压缩;在现今请求中,**消息首部占请求绝大部分(**甚至是全部)也较为常见。
我们也可以用
dns-prefetch和 preconnect tcp
来优化~
<link rel="preconnect" href="//example.com" crossorigin>
<link rel="dns=prefetch" href="//example.com">
Tip
:webpack
可以做任何事情,这些都可以用插件实现
3、HTTP2.0
相较于HTTP1.1,HTTP2.0的主要优点有:
- 采用二进制帧封装
- 传输变成多路复用
- 流量控制算法优化
- 服务器端推送
- 首部压缩
- 优先级
1、 二进制帧封装 / 二进制分帧
HTTP1.x的解析是基于文本的,基于文本协议的格式解析存在天然缺陷,文本的表现形式有多样性,要做到健壮性考虑的场景必然很多。
而HTTP2.0会将所有传输的信息分割为更小的消息和帧,然后采用二进制的格式进行编码,HTTP1.x的头部信息会被封装到HEADER frame(单独成帧,不再在后续数据传输中携带),而相应的RequestBody则封装到DATAframe里面。
不改动HTTP的语义,使用二进制编码,实现方便且健壮。
2、 多路复用 && 优先级
所有的请求都是通过一个 TCP 连接并发完成。
HTTP/1.x 虽然通过 pipeline 也能并发请求,但是多个请求之间的响应会被阻塞的,所以 pipeline 至今也没有被普及应用,而 HTTP/2 做到了真正的并发请求。
同时,流还支持优先级和流量控制。当流并发时,就会涉及到流的优先级和依赖。
即:HTTP2.0对于同一域名下所有请求都是基于流的,不管对于同一域名访问多少文件,也只建立一路连接。优先级高的流会被优先发送和响应。图片请求的优先级要低于 CSS 和 SCRIPT,这个设计可以确保重要的东西可以被优先加载完(相较HTTP1.1,响应不再死板的按照请求顺序返回,而是根据流中请求数据的优先级响应)。
3、 流量控制
TCP协议通过sliding window(滑动窗口)的算法来做流量控制。
发送方有个sending window,接收方有receive window。http2.0的flow control是类似receive window的做法,数据的接收方通过告知对方自己的flow window大小表明自己还能接收多少数据。
只有Data类型的frame才有flow control的功能。对于flow control,如果接收方在flow window为零的情况下依然更多的frame,则会返回block类型的frame,这种场景一般表明http2.0的部署出了问题。
4、 服务器端推送
服务端推送是一种在客户端请求之前发送数据的机制。可以做到(客户端的)缓存。
服务器端的推送,就是服务器可以对一个客户端请求发送多个响应。
除了对最初请求的响应外,服务器还可以额外向客户端推送资源,而无需客户端明确地请求。 当浏览器请求一个html,服务器其实大概知道你是接下来要请求资源了,而不需要等待浏览器得到html后解析页面再发送资源请求。
5、 首部压缩
-
HTTP 2.0 在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键-值对,对于相同的数据,不再通过每次请求和响应发送;
通信期间几乎不会改变的通用键-值对(用户代理、可接受的媒体类型,等等)只需发送一次。事实上,如果请求中不包含首部(例如对同一资源的轮询请求),那么 首部开销就是零字节。此时所有首部都自动使用之前请求发送的首部。
-
如果首部发生变化了,那么只需要发送变化了数据在Headers帧里面,新增或修改的首部帧会被追加到“首部表”。首部表在 HTTP 2.0 的连接存续期内始终存在,由客户端和服务器共同渐进地更新 。
-
本质上是为了减少请求,通过多个js或css合并成一个文件,多张小图片拼合成Sprite图,可以让多个HTTP请求减少为一个,减少额外的协议开销,而提升性能。
当然,一个HTTP的请求的body太大也是不合理的,有个度。文件的合并也会牺牲模块化和缓存粒度,可以把“稳定”的代码or 小图 合并为一个文件or一张Sprite,让其充分地缓存起来,从而区分开迭代快的文件。
HTTP/1.1并不支持 HTTP 首部压缩,为此 SPDY 和 HTTP/2 应运而生, SPDY 使用的是通用的DEFLATE 算法,而 HTTP/2 则使用了专门为首部压缩而设计的 HPACK 算法。
以上是关于详解HTTP1.01.12.0版本区别/优化的主要内容,如果未能解决你的问题,请参考以下文章