HTTP1.0,HTTP1.1,HTTP2.0升级的变化和区别

原创 2019-01-03 21:09 阅读(302)次

HTTP协议

HTTP,文本传输协议,它是在应用层(第七层)上的协议,与它对接的传输层(第四层)的协议是TCP。

HTTP是基于TCP/IP协议的,创建一个TCP连接是需要经过三次握手的,有一定的开销,如果每次通讯都要重新建立连接的话,对性能有影响。因此最好能维持一个长连接,可以用个长连接来发多个请求。


HTTP 1.0:

HTTP1.0 是浏览器的每次请求都需要与服务器建立一个TCP连接,服务器处理完成后立即断开TCP连接(无连接),服务器不跟踪每个客户端也不记录过去的请求(无状态)。因为HTTP/1.0中默认使用Connection: close。


HTTP 1.1:

但其实HTTP 1.0也是可以建立长链接的,需要使用keep-alive参数来告知服务器端要建立一个长连接,而HTTP1.1默认支持长连接,即已经默认使用Connection: keep-alive。


虽然它是个长连接,但在连接中发送的多个请求还是会顺序处理。这样的话一旦有一个请求处理很久的话,那后面的请求就会被阻塞。这就是线端阻塞(head-of-line blocking)。在请求如此频繁的今天显然还是有些不太令人满意,虽然可以同时保持几个持久连接,但明显还有改进的地方。

同时HTTP1.1 还有以下一些新特性:

HTTP 1.1支持只发送header信息(不带任何body信息),如果服务器认为客户端有权限请求服务器,则返回100,否则返回401。客户端如果接受到100,才开始把请求body发送到服务器。这样当服务器返回401的时候,客户端就可以不用发送请求body了,节约了带宽。

HTTP 1.1还提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准。HTTP1.1则引入了更多的缓存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略带宽优化及网络连接的使用

在HTTP1.1中新增了24个错误状态响应码,如409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除

另外HTTP还支持传送内容的一部分。这样当客户端已经有一部分的资源后,只需要跟服务器请求另外的部分资源即可。这是支持文件断点续传的基础。通过Content-Length字段来判断当前请求的数据是否已经全部接收。不允许同时存在两个并行的响应。

HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)。



HTTP 2.0:

首先,它解决了1.1的长连接会遇到阻塞的问题。它采用的是多路复用的形式去解决这个问题。什么是多路复用呢?就是一个通道可以让多条线路同时占用而不搞混。这里的作法是为每一个请求带一个编号,它样服务器方就能为请求的回应对上号了。如果一个请求时间过长,那么服务器就可以先暂停这个请求,先处理下一个请求,处理完再回来处理这个长请求,如果找回这个长请求呢,那就靠这个编号了。并发请求的数量比HTTP1.1大了好几个数量级。

TCP连接有一个预热和保护的过程,先检查数据是否传送成功,一旦成功过,则慢慢加大传输速度。因此对应瞬时并发的连接,服务器的响应就会变慢。所以最好能使用一个建立好的连接,并且这个连接可以支持瞬时并发的请求。多路传输(Multiplexing)能很好的解决这些问题, 因为它能同时处理多个消息的请求和响应; 甚至可以在传输过程中将一个消息跟另外一个掺杂在一起。

它还规定了HTTP传输的所有内容都转为二进制进行传输而非文本格式,以前的版本只有头部信息会转为二进制,内容体并不会。不统一总会造成额外的麻烦。比如内容是文本,而文本是有多种样式的,这样的话解析它的一方就很麻烦了,要支持你各种样式。比起像HTTP/1.x这样的文本协议,二进制协议解析起来更高效、“线上”更紧凑,更重要的是错误更少。

首部压缩:HTTP1.1不支持header数据的压缩,HTTP2.0使用HPACK算法对header的数据进行压缩,这样数据体积小了,在网络上传输就会更快。

消息头为什么需要压缩?
假定一个页面有80个资源需要加载(这个数量对于今天的Web而言还是挺保守的), 而每一次请求都有1400字节的消息头(着同样也并不少见,因为Cookie和引用等东西的存在), 至少要7到8个来回去“在线”获得这些消息头。这还不包括响应时间——那只是从客户端那里获取到它们所花的时间而已。这全都由于TCP的慢启动机制,它会基于对已知有多少个包,来确定还要来回去获取哪些包 – 这很明显的限制了最初的几个来回可以发送的数据包的数量。相比之下,即使是头部轻微的压缩也可以是让那些请求只需一个来回就能搞定——有时候甚至一个包就可以了。这种开销是可以被节省下来的,特别是当你考虑移动客户端应用的时候,即使是良好条件下,一般也会看到几百毫秒的来回延迟。

服务器推送:当我们对支持HTTP2.0的web server请求数据的时候,服务器会顺便把一些客户端需要的资源一起推送到客户端,免得客户端再次创建连接发送请求到服务器端获取。这种方式非常合适加载静态资源。 当浏览器请求一个网页时,服务器将会发回HTML,在服务器开始发送JavaScript、图片和CSS前,服务器需要等待浏览器解析HTML和发送所有内嵌资源的请求。服务器推送服务通过“推送”那些它认为客户端将会需要的内容到客户端的缓存中,以此来避免往返的延迟。


本文完。