從Timing看HTTP請求的優化方向

1, 背景

在Chrome開發者工具中，有一個Timing菜單，能夠查看每個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，同異步，接口調用等;