HTTP的黑历史

HTTP的建立,主要就是为了将超文本标记语言文档(HTML)从Web服务器传送到客户端(浏览器)。但是到了WEB2.0后,我们的页面变得复杂,不仅仅单纯的是一些简单的文字和图片,同时我们的HTML页面有了CSS、Javascript、ajax异步取数据,来丰富我们的页面展示。同样移动互联网时代的到来,也为页面的展示提出更高的要求,因此人们不得不对HTTP进行优化。

影响一个 HTTP 网络请求的因素主要有两个:带宽和延迟

  • 带宽

  • 延迟 浏览器阻塞:浏览器会因为一些原因阻塞请求。浏览器对于同一个域名,同时只能有4个连接(这个根据浏览器内核不同可能会有所差异),超过浏览器最大连接数限制,后续请求就会被阻塞。 DNS查询(DNS Lookup):浏览器需要知道目标服务器的IP才能建立连接。将域名解析为IP的这个系统就是DNS。这个通常可以利用DNS缓存结果来达到减少这个时间的目的。建立连接:HTTP 是基于TCP协议的,浏览器最快也要在第三次握手时才能捎带HTTP请求报文,达到真正的建立连接,但是这些连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显,慢启动则对文件类大请求影响较大。

HTTP1.0和HTTP1.1的区别

HTTP1.0最早在网页中使用是在1996年,那个时候只是使用一些较为简单的网页上和网络请求上,而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中,同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在:

  • 缓存处理,在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准,HTTP1.1则引入了更多的缓存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

  • 带宽优化及网络连接的使用,HTTP1.0中,存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能,HTTP1.1则在请求头引入了range头域,它允许只请求资源的某个部分,即返回码是206(Partial Content),这样就方便了开发者自由的选择以便于充分利用带宽和连接。

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

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

  • 长连接,HTTP 1.1支持长连接(PersistentConnection)和请求的流水线(Pipelining)处理,在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟,在HTTP1.1中默认开启Connection: keep-alive,一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

HTTP1.X和HTTP2.0的区别,HTTP2.0的新特性

  • 新的二进制格式(Binary Format),HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷,文本的表现形式有多样性,要做到健壮性考虑的场景必然很多,二进制则不同,只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式,实现方便且健壮。

  • 多路复用(MultiPlexing),即连接共享,即每一个request都是是用作连接共享机制的。一个request对应一个id,这样一个连接上可以有多个request,每个连接的request可以随机的混杂在一起,接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。

  • header压缩,如上文中所言,对前面提到过HTTP1.x的header带有大量信息,而且每次都要重复发送,HTTP2.0使用encoder来减少需要传输的header大小,通讯双方各自cache一份header fields表,既避免了重复header的传输,又减小了需要传输的大小。

  • 服务端推送(server push)

HTTP相关问题解答

服务端推送Server Push

Server push说白了就是为了提前推送响应,如下图:

可以看到,使用 server push 后,两个静态资源文件随着 HTML 一同被推了回来。主要省去了两部分时间:一部分是接收和解析 HTML 的时间(不一定是接收和解析完整 HTML 的时间,浏览器很可能一发现引用了静态资源文件,就发起请求);另一部分是请求静态资源文件的时间。

但是,现阶段用 server push 推送静态资源并不是一件有意义的事情,原因在于:

  • HTML 文件通常不大,而且样式表一般很靠前,浏览器发现这类静态资源的时间几乎可以忽略不计

  • HTTP/2 已经能够复用 TCP 连接了,请求不再像以前那样昂贵,请求的实际数据很小,发送请求的时间也几乎可以忽略不计

  • 国内的 CDN 普遍不支持 server push,这意味着,如果要推送静态资源,就必须耗费自己服务器的带宽,同时也享受不到 CDN 的各种好处了

  • 静态资源通常会被缓存很长时间,提前推送的话,在大多数情况下反而会浪费流量

因此,Server push推送的资源并不是静态资源,而应该是 API。当然,Server push对要推送的资源是有限制的:其请求必须是可缓存的、安全的,而且不能带有请求体。换句话说,Server push可以推 GET 和 HEAD 请求的响应。

参考:

[1] HTTP2.0 规范文档

[2] HTTP1.0、HTTP1.1 和 HTTP2.0 的区别

[3] HTTP/2 头部压缩技术介绍

[4] 浅谈 HTTP/2 Server Push

Author:tenado
CeateTime:2019-05-16
Link:https://www.kelede.win/posts/HTTP1.0%E5%92%8CHTTP2.0%E7%9A%84%E5%8C%BA%E5%88%AB/
License:本站博文无特别声明均为原创,转载请保留原文链接及作者
Previous:输入url后发生了什么 Next:如何发布一个npm包