彩世界平台-彩世界时时app-彩世界开奖app苹果下载

热门关键词: 彩世界平台,彩世界时时app,彩世界开奖app苹果下载

您的位置:彩世界平台 > 新闻动态 > 构建高性能WEB之HTTP首部优化

构建高性能WEB之HTTP首部优化

发布时间:2019-12-09 12:53编辑:新闻动态浏览(73)

    构建高性能WEB之HTTP首部优化

    2015/10/03 · HTML5, JavaScript · HTTP

    本文作者: 伯乐在线 - 十三号线上的蝼蚁 。未经作者许可,禁止转载!
    欢迎加入伯乐在线 专栏作者。

    在「HTTP/2 与 WEB 性能优化(一)」这篇博客中,我主要写了 HTTP/2 中的 Server Push 给 WEB 性能优化带来的便利,今天继续来聊一聊 HTTP/2 其他方面的改变。

    0×00 前言

    在讨论浏览器优化之前,首先我们先分析下从客户端发起一个HTTP请求到用户接收到响应之间,都发生了什么?知己知彼,才能百战不殆。这也是作为一个WEB开发者,为什么一定要深入学习TCP/IP等网络知识

    我们知道,HTTP/2 并没有改动 HTTP/1 的语义部分,例如请求方法、响应状态码、URI 以及头部字段等核心概念依旧存在。HTTP/2 最大的变化是重新定义了格式化和传输数据的方式,这是通过在高层 HTTP API 和低层 TCP 连接中引入二进制分帧层来实现。这样改动的好处是原来的 WEB 应用完全不用修改,就能享受到协议升级带来的收益。

    0×01 到底发生什么了?

    当用户发起一个HTTP请求时,首先客户端将与服务端之间建立TCP连接,成功建立连接后,服务端将对请求进行处理,并对客户端做出响应,响应内容一般包括响应主体。
    (此处我们仅简单说明,但真实的一次请求其中发生的事情是相当复杂的,这里贴条连接,讲得比较详细)。
    从输入 URL 到页面加载完成的过程中都发生了什么事情?

    HTTP/2 的连接

    建立TCP连接

    为了进行可靠的数据传输,TCP在进行发送数据之前,会进行TCP三次握手,以此确定接收方能够成功收取传输的数据,而建立连接的过程,必然是要耗费系统资源,以及时间资源的。

    HTTP/1 的请求和响应报文,都是由起始行、首部和实体正文(可选)组成,各部分之间以文本换行符分隔。而 HTTP/2 将请求和响应数据分割为更小的帧,并对它们采用二进制编码。下面这幅图中的 Binary Framing 就是新增的二进制分帧层:

    服务端处理并响应

    当服务端接收到客户端发送来的请求之后,如果请求内容是静态资源,服务端会从硬盘中取出静态资源,然后将静态资源放在响应主体中,发送给客户端。如果是动态资源,服务端首先取出资源,并通过业务逻辑操作,动态生成最终的响应主体,然后发送给客户端。

     图片 1

    客户端渲染

    客户端接受到服务端传输过来的网络资源,然后进行渲染,绘制等,最终展示给用户。

    先来看看这几个概念:

    0×02 优化点在哪里?

    通过简单的了解,我们了解到TCP建立连接是有资源消耗,时间消耗的,那么如果我们无需每次简历TCP连接,那是否可以提高网站的性能呢?答案是肯定的。

    • 优化点1:减少TCP连接

    我们知道,在获取资源的时候,以获取速度从慢到快是:网络资源->本地硬盘资源->本地内存资源。而网络资源也分硬盘资源以及内存资源。并且网络资源的传输,也是有相当大的时延的。

    • 优化点2:对数据进行缓存
    • 优化点3:减少数据传输量

    帧(Frame):HTTP/2 数据通信的最小单位。帧用来承载特定类型的数据,如 HTTP 首部、负荷;或者用来实现特定功能,例如打开、关闭流。每个帧都包含帧首部,其中会标识出当前帧所属的流;

    0×03 如何进行优化?

    本篇文章主要说的优化点是与HTTP首部有关的优化,或者说是与浏览器端有关的优化,其它优化这里暂不赘述。

    消息(Message):指 HTTP/2 中逻辑上的 HTTP 消息。例如请求和响应等,消息由一个或多个帧组成;

    持久连接:Keep-Alive

    HTTP连接设计之初是请求-响应-关闭,也就是每建立一次HTTP连接,只能进行一次资源请求,当需要在同一目标服务器上获取多个资源的时候,就需要多次建立HTTP连接,而这个多次建立连接的过程,便降低了网站的性能。

    于是,出现了Connection:Keep-Alive,人称持久连接。Keep-Alive避免了建立或者说重新建立连接的过程,减少了HTTP连接。

    而与此配套的有Keep-Alive:timeout=120,max=5

    其中,timeout=120 是指这个TCP通道保持120S,max=5 指这个TCP通道最多接收5个HTTP请求,之后便自动关闭该连接。

    流(Stream):存在于连接中的一个虚拟通道。流可以承载双向消息,每个流都有一个唯一的整数 ID;

    修改时间:Last-Modified 和 If-Modified-Since

    Last-Modified首部是服务端对客户端的HTTP响应所加的一个与缓存有关的HTTP首部,该首部标记了所请求资源在服务端的最后修改时间。类似:

    Last-Modified : Fri , 12 May 2015 13:10:33 GMT

    当客户端发现HTTP响应头中有Last-Modified,会对资源进行缓存,在下次请求资源时,在HTTP请求头中添加If-Modified-Since首部,首部中将会添加上次成功请求资源时响应头部的Last-Modified属性值,即:

    If-Modified-Since : Fri , 12 May 2015 13:10:33 GMT

    当服务端接收到的HTTP请求中,发现有If-Modified-Since头部时,会将该属性值与请求资源的最后修改时间进行比对,如果最后修改时间与该属性值一致时,服务端会返回一个304 Not Modified响应,该响应中不包括响应实体。浏览器收到304的响应后,会进行重定向,获取本地缓存资源。如果最后修改时间与该属性值不一致,则会从服务端重新获取资源,做出200响应。

    连接(Connection):与 HTTP/1 相同,都是指对应的 TCP 连接;

    版本标记:ETag 和 If-None-Match

    ETag其实与Last-Modified是差不多的方式,但是ETag并没有选择以时间作为标记,而是对所请求文件进行某些算法来生成一串唯一的字符串,作为对某一文件的标记。当收到客户端对某一资源的请求时,服务端在响应时,添加ETag首部,如下:

    ETag:W/"a627ff1c9e65d2dede2efe0dd25efb8c"

    当客户端发现ETag头部时,同样会对资源进行缓存,并在下次请求时,在请求头部添加If-None-Match,如:

    If-None-Match:W/"a627ff1c9e65d2dede2efe0dd25efb8c"

    当服务端收到请求中含有该头部时,会使用同样的ETag生成算法对文件ETag进行计算,并与If-None-Match属性值进行比对,如果一致,则返回一个304 Not Modified响应,基本与上一种方式是一致的。

    在 HTTP/2 中,同域名下所有通信都在单个连接上完成,这个连接可以承载任意数量的双向数据流。每个数据流都以消息的形式发送,而消息又由一个或多个帧组成。多个帧之间可以乱序发送,因为根据帧首部的流标识可以重新组装。下面有一幅图说明帧、消息、流和连接的关系:

    缓存时间:Expires 和 Cache-Control

    上述两种方式中,每次请求资源时,虽然在有缓存的情况下,选择缓存进行渲染绘制,但是在这之前还是发起了一次HTTP请求,虽然并没有真实的响应实体,但是依然会造成一些资源消耗。而Expires与上述两种方式使用了不同的思路。

    当服务端希望客户端浏览器对某一资源进行缓存时,为了免去客户端每次都要询问自己:我上次的缓存现在还能用吗?所以,服务端选择了放权。只去告诉浏览器,我这次给你的资源你可以用多长时间,在这个时间段内,你可以一直使用它,无需每次咨询我。而服务端就是通过Expires属性来告诉客户端浏览器可以多长时间内不需要询问服务端。如下:
    Expires:Thu, 19 Nov 2015 15:00:00 GMT

    当客户端在响应首部中发现该属性值时,便会将该资源缓存起来,而缓存的过期时间即是Expires中的时间。在这个时间段内,浏览器完全自主。

    但是,Expires有一个不足的地方是,如果服务端时间与客户端本地时间不统一时,可能服务端让客户端可以对该资源缓存一个小时,而客户端本地时间比服务端时间快了两个小时,那就意味着,所有缓存都将不会生效。

    于是有了弥补该不足的一个属性,即:Cache-Control。如果服务端在响应首部添加该属性时,客户端将直接使用该属性值来生成本地时间的缓存过期时间,这样便解决了这个问题,如下:

    Cache-Control:max-age=3600

    如果客户端在2015年10月01日13时00分00秒收到该响应时,便会加上3600秒也就是2015年10月01日14时00分00秒作为缓存过期时间。如果响应头部既有ExpiresCache-Control,浏览器会首选Cache-Control

     图片 2

    0×04 结束

    这里,基本上说的都是与HTTP首部有关的网站性能优化。本文主要是在对《构建高性能WEB站点. 郭欣著》中第六章浏览器缓存的学习总结笔记。这本书对于WEB站点的优化,从各个层面都做了很详尽的讲解,确实是一本很棒的书,也在这里感谢HQBOSS的推荐。

    1 赞 1 收藏 评论

    TCP 协议本身更适合用来长时间传输大数据,这样它的稳定和可靠性才能显露出来。HTTP/1 时代太多短而小的 TCP 连接,反而更多地将 TCP 的缺点给暴露出来了。

    关于作者:十三号线上的蝼蚁

    图片 3

    哈哈哈 个人主页 · 我的文章 · 3 ·  

    图片 4

    HTTP/1 的连接

    在 HTTP/1 中,每一个请求和响应都要占用一个 TCP 连接,尽管有 Keep-Alive 机制可以复用,但在每个连接上同时只能有一个请求 / 响应,这意味着完成响应之前,这个连接不能用于其他请求(怎么判断响应是否结束,可以看这里)。如果浏览器需要向同一个域名发送多个请求,需要在本地维护一个 FIFO 队列,完成一个再发送下一个。这样,从服务端完成请求开始回传,到收到下一个请求之间的这段时间,服务端处于空闲状态。

    后来,人们提出了 HTTP 管道(HTTP Pipelining)的概念,试图把本地的 FIFO 队列挪到服务端。它的原理是这样的:浏览器一股脑把请求都发给服务端,然后等着就可以了。这样服务端就可以在处理完一个请求后,马上处理下一个,不会有空闲了。甚至服务端还可以利用多线程并行处理多个请求。可惜,因为 HTTP/1 不支持多路复用,这个方案有几个棘手的问题:

    服务端收到多个管道请求后,需要按接收顺序逐个响应。如果恰好第一个请求特别慢,后续所有响应都会跟着被阻塞。这种情况通常被称之为「队首阻塞(Head-of-Line Blocking)」;

    服务端为了保证按顺序回传,通常需要缓存多个响应,从而占用更多的服务端资源,也更容易被人攻击;

    浏览器连续发送多个请求后,等待响应这段时间内如果遇上网络异常导致连接被断开,无法得知服务端处理情况,如果全部重试可能会造成服务端重复处理;

    另外,服务端和浏览器之间的中间代理设备也不一定支持 HTTP 管道,这给管道技术的普及引入了更多复杂性;

    基于这些原因,HTTP 管道技术无法大规模使用,我们需要寻找其他方案。实际上,在 HTTP/1 时代,连接数优化不外乎两个方面:开源和节流。

    开源

    这里说的开源,当然不是「Open Source」那个开源。既然一个 TCP 连接同时只能处理一个 HTTP 消息,那多开几条 TCP 连接不就解决这个问题了。是的,浏览器确实是这么做的,HTTP/1.1 初始版本中允许浏览器针对同一个域名同时创建两个连接,在修订版(rfc7230)中更是去掉了这个限制。实际上,现代浏览器一般允许同域名并发 6~8 个连接。这个数字为什么不能更大呢?实际上这是出于公平性的考虑,每个连接对于服务端来说都会带来一定开销,如果浏览器不加以限制,一个性能好带宽足的终端就可能耗尽服务端所有资源,造成其他人无法使用。

    但是,现在包含几十个 CSS、JSS,几百张图片的页面大有所在。为了进一步榨干浏览器,开更多的源,往往我们还会对静态资源做域名散列,将页面静态资源分散在多个子域下加载。多域名能提高并发连接数,也会带来很多问题,例如:

    如果同一资源在不同页面被散列到不同子域下,会导致无法利用之前的 HTTP 缓存;

    本文由彩世界平台发布于新闻动态,转载请注明出处:构建高性能WEB之HTTP首部优化

    关键词:

上一篇:彩世界平台性能优化黑科技 Google AMP

下一篇:没有了