1、HTTP1.0 HTTP 1.1主要区别
1.1 长链接
HTTP 1.0需要使用keep-alive
参数来告知服务器端要建立一个长连接,而HTTP1.1默认支持长连接
。
HTTP是基于TCP/IP协议
的,创建一个TCP连接是需要经过三次握手的,有一定的开销,如果每次通讯都要重新建立连接的话,对性能有影响。因此最好能维持一个长连接,可以用个长连接来发多个请求。
虽然它是个长连接,但在连接中发送的多个请求
还是会顺序处理
。这样的话一旦有一个请求处理很久的话,那后面的请求就会被阻塞
。
1.2 节约带宽
HTTP 1.1支持只发送header信息
(不带任何body信息),如果服务器认为客户端有权限
请求服务器,则返回100,否则返回401。客户端如果接受到100,才开始把请求body发送到服务器。
这样当服务器返回401
的时候,客户端就可以不用发送请求body
了,节约了带宽
。
另外HTTP还支持传送内容的一部分
。这样当客户端已经有一部分的资源后,只需要跟服务器请求另外的部分资源即可。这是支持文件断点续传
的基础。
1.3 HOST域
现在可以web server例如tomat,设置虚拟站点是非常常见的,也即是说,web server上的多个虚拟站点
可以共享同一个ip和端口
。
HTTP1.0是没有host域的,HTTP1.1才支持这个参数。
2、HTTP 1.1、HTTP2.0主要区别
2.1 多路复用
HTTP2.0使用了多路复用
的技术,解决了HTTP1.1的长连接会遇到阻塞
的问题,做到同一个连接并发
处理多个请求,为每一个请求带一个编号
,它样服务器方就能为请求的回应对上号了。如果一个请求时间过长,那么服务器就可以先暂停这个请求
,先处理下一个请求
,处理完再回来处理这个长请求,如果找回这个长请求呢,那就靠这个编号了。
当然HTTP1.1也可以多建立几个TCP连接,来支持处理更多并发的请求,但是创建TCP连接本身也是有开销的。
TCP连接有一个预热和保护
的过程,先检查数据是否传送成功,一旦成功过,则慢慢加大传输速度。因此对应瞬时并发的连接,服务器的响应就会变慢。所以最好能使用一个建立好的连接,并且这个连接可以支持瞬时并发的请求。
2.2 数据压缩
HTTP1.1不支持header数据的压缩
,HTTP2.0使用HPACK算法对header的数据进行压缩
,这样数据体积小
了,在网络上传输就会更快
。假定一个页面有80个资源需要加载(这个数量对于今天的Web而言还是挺保守的), 而每一次请求都有1400字节的消息头
(这同样也并不少见,因为Cookie和引用等东西的存在), 至少要7到8个来回
去“在线”获得这些消息头。这还不包括响应时间——那只是从客户端那里获取到它们所花的时间而已。这全都由于TCP的慢启动机制,它会基于对已知有多少个包,来确定还要来回去获取哪些包 – 这很明显的限制了最初的几个来回可以发送的数据包的数量。相比之下,即使是头部轻微的压缩也可以是让那些请求只需一个来回就能搞定——有时候甚至一个包就可以了。这种开销是可以被节省下来的,特别是当你考虑移动客户端应用的时候,即使是良好条件下,一般也会看到几百毫秒的来回延迟。
2.3 服务器推送
当我们对支持HTTP2.0的web server请求数据的时候,服务器会顺便把一些客户端需要的资源一起推送到客户端
,免得客户端再次创建连接发送请求到服务器端获取。这种方式非常合适加载静态资源
。例如我的网页有一个sytle.css
的请求,在客户端收到sytle.css数据的同时,服务端会将sytle.js
的文件推送给客户端,当客户端再次尝试获取sytle.js时就可以直接从缓存
中获取到,不用再发请求了。
服务器端推送的这些资源其实存在客户端的某处地方,客户端直接从本地加载这些资源就可以了,不用走网络,速度自然是快很多的。
服务端推送过来的资源,会统一
放在网络与http缓存之间
的一个地方,在这里可以理解为“本地”。当客户端把index.html解析完以后,会向本地请求这个资源。由于资源已经本地化
,所以这个请求的速度非常快
,这也是服务端推送性能优势的体现之一。
2.4 新的二进制格式(Binary Format)
HTTP1.x的解析是基于文本
。基于文本协议的格式解析存在天然缺陷,文本的表现形式有多样性
,要做到健壮性考虑的场景必然很多,二进制则不同
,只认0和1的组合
。基于这种考虑HTTP2.0的协议解析决定采用二进制格式,实现方便且健壮
。