从Timing看HTTP请求的优化方向

编程

1, 背景

在Chrome开发者工具中,有一个Timing菜单,可以查看每一个HTTP请求" title="HTTP请求">HTTP请求耗时分布,如下

2, 内容

Queued at 8.4 ms

Started at 8.4 ms

Resource Scheduling DURATION

Queueing 2.98 ms

Connection Start DURATION

Stalled 16.94 ms

Proxy negotiation 0.76 ms

DNS Lookup 5.42 ms

Initial connection 16.58 ms

SSL 10.43 ms

Request/Response DURATION

Request sent 41 us

Waiting (TTFB) 84.12 ms

Content Download 5.48 ms

(Total:) 132.21 ms

我们依次从上往下,对照官方文档来看。

2.1 Queued at 8.4ms, 它表示当前的这个请求在这个页面加载过程中,加入到请求队列中的时间。这个数值是从0开始计算的,然后按照加入队列的顺序,依次累加的。

为什么会排队呢?因为浏览器对同一时间,同一个Host发起的HTTP1.1并发请求的个数做了限制,不是所有的请求都能发出去,所以需要排队。

个数限制详情如下

 BrowserVersion | ConnectionsPerHostname | MaxConnections

----------------------------------------------------------

Chrome34/32 | 6 | 10

IE9 | 6 | 35

IE10 | 8 | 17

IE11 | 13 | 17

Firefox27/26 | 6 | 17

Safari7.0.1 | 6 | 17

Android4 | 6 | 17

ChromeMobile18 | 6 | 16

IE Mobile9 | 6 | 60

Note: ConnectionsPerHostname is the maximum number of concurrent http requests that browsers will make to the same domain. To increase the number of concurrent connections, one can host resources (e.g. images) in different domains. However, you cannot exceed MaxConnections, the maximum number of connections a browser will open in total - across all domains.

注意: ConnectionsPerHostname是浏览器对同一个域名能发起的http请求的最大并发数量。为了增加这个并发连接数,可以把资源(比如图片)放置到在不同的域名下。然而,你不能超过 MaxConnections, 这是浏览器对所有的域名能发起的http请求的最大并发数量。

数据来源: https://stackoverflow.com/questions/985431/max-parallel-http-connections-in-a-browser

本次请求的User-Agent是Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36,http请求连接最大并发数量为6。

2.2 Started at 8.4 ms,表示加入到队列之后,实际开始处理的时间。

2.3 Resource Scheduling    DURATION
      Queueing                       2.98 ms

资源排期,排队,表示排队等待时间,就是 从添加到待处理队列 到 实际开始处理的 时间间隔。

Queuing
A request being queued indicates that:
The request was postponed by the rendering engine because it’s considered lower priority than critical resources (such as scripts/styles). This often happens with images.
The request was put on hold to wait for an unavailable TCP socket that’s about to free up.
The request was put on hold because the browser only allows six TCP connections per origin on HTTP 1.
Time spent making disk cache entries (typically very quick.)

队列

一个排队中的请求表明:

这个请求被渲染引擎延迟了,因为比起关键的资源(比如脚本/样式),这个请求被当做为低优先级的。这经常发生的图片请求中。

这个请求被hold住,为了等待一个暂不可用的 待释放的TCP套接字。

这个请求被hold住,因为浏览器在HTTP1.0上 只允许 每个Host 6个 TCP连接。

花费在创建硬盘缓存实体的时间(一般会非常快)。

2.4 Connection Start       DURATION
              Stalled                16.94 ms
     Proxy negotiation      0.76 ms
       DNS Lookup             5.42 ms
       Initial connection     16.58 ms
               SSL                    10.43 ms

连接开始,延迟

Stalled/Blocking
Time the request spent waiting before it could be sent. It can be waiting for any of the reasons described for Queueing. Additionally, this time is inclusive of any time spent in proxy negotiation.

延迟/阻塞

在请求可以被发出去之前的等待时间。它可能在等待哪些用来描述成为排队的理由。此外,这个时间包含了用到代理协商中的时间。一般是代理协商、以及等待可复用的TCP连接释放的时间,不包括DNS查询、建立TCP连接等时间等。

Proxy Negotiation
Time spent negotiating with a proxy server connection.

代理协商

花费在和代理服务器连接的协商上的时间。


DNS Lookup
Time spent performing the DNS lookup. Every new domain on a page requires a full roundtrip to do the DNS lookup.

DNS 查询

花费在DNS查询上的时间。每一个页面上的新的域名都需要一个完整的回路来做这个DNS查询。当本地DNS缓存没有的时候,DNS查询的时间可能是有一段长度的,但是你一旦在host中设置了DNS,或者第二次访问,由于浏览器的DNS缓存还在,这个时间就为0了。


Initial Connection / Connecting
Time it took to establish a connection, including TCP handshakes/retries and negotiating a SSL.

初始化连接/连接中

花费在建立连接上的时间,包括 TCP握手/重试 和 协商SSL。相当于客户端从发请求开始到TCP握手结束这一段,在数值上,它包括了SSL处理时间。


SSL
Time spent completing a SSL handshake.

花费在完成SSL握手上的时间。

2.5 Request/Response       DURATION
           Request sent           41 us
         Waiting (TTFB)         84.12 ms
     Content Download       5.48 ms


Request Sent / Sending
Time spent issuing the network request. Typically a fraction of a millisecond.

请求已发送 / 发送中

花费在发送网络请求的时间。通常是1毫秒的一小部分。


Waiting (TTFB)
Time spent waiting for the initial response, also known as the Time To First Byte. This time captures the latency of a round trip to the server in addition to the time spent waiting for the server to deliver the response.

等待(TTFB)

花费在等待初始化响应的时间,也经常被称为 Time To First Byte, 从发出请求到第一个字节返回的时间。这个时间获取到的是 从浏览器到服务器 到 服务器处理、返回响应的 一个回路时间,包含网络延迟时间。服务器优化的目的就是要让这个时间段尽可能短。


Content Download / Downloading
Time spent receiving the response data.

内容下载/下载中

花费在接收响应数据的时间。收到响应的第一个字节,到接受完最后一个字节的时间,就是下载时间。

 

3,优化

我们同样从上到下来看

3.1 增大浏览器的Http并发请求数量,减少排队时间,比如升级HTTP1.1 到 SPYD,HTTP2.0,利用这两者的长连接和多路复用技术,减少TCP初始化连接。

3.2 减少延迟/阻塞时间,在服务端减少代理跳转,重定向,在请求中开启 Keep Alive, (临时)关闭SSL,用HTTP代替HTTPS;

3.3 优化进程管理,代码执行层面的优化,缓存,DB,同异步,接口调用等;

 

以上是 从Timing看HTTP请求的优化方向 的全部内容, 来源链接: utcz.com/z/510493.html

回到顶部