Chrome瀏覽器Network面板http請求時間分析

最近項目上面出現了這類問題，請求後等待數據回來的時間好久。雖然說能夠展現吧，可是也屬於一個較嚴重的問題。Chrome瀏覽器調試，能夠完美的詮釋了爲何會耗時那麼久。

Chrome瀏覽器開發者Network窗口下，能夠查看下載各個組建所須要的具體時間

根據上面的圖能夠分析出

Stalled （阻塞）

　　瀏覽器對同一個主機域名的併發鏈接數有限制，所以若是當前的鏈接數已經超過上限，那麼其他請求就會被阻塞，等待新的可用鏈接；此外腳本也會阻塞其餘組件的下載；

　　優化措施：

　　一、將資源合理分佈到多臺主機上，能夠提升併發數，可是增長並行下載數量也會增大開銷，這取決於帶寬和CPU速度，過多的並行下載會下降性能；

　　二、腳本置於頁面底部；

DNS Lookup（域名解析）

　　請求某域名下的資源，瀏覽器須要先經過DNS解析器獲得該域名服務器的IP地址。在DNS查找完成以前，瀏覽器不能從主機名那裏下載到任何東西。

　　優化措施：

　　一、利用DNS緩存（設置TTL時間）；

　　二、利用Connection:keep-alive特性創建持久鏈接，能夠在當前鏈接上進行多個請求，無需再進行域名解析；

Initial connection（初始化鏈接）

　　TCP創建鏈接的三次握手時間

SSL（包含於HTTPS鏈接中）

　　http是超文本傳輸協議，以明文方式發送內容，不提供任何方式的數據加密，若是被不法分子截取瀏覽器和服務器之間的傳輸報文，會獲取其中的信息。

　　https 是安全套接字層超文本傳輸協議，就是在HTTP的基礎上加入了SSL協議，SSL依靠證書來驗證服務器的身份，併爲瀏覽器和服務器之間的通訊加密。

　　所以創建HTTPS鏈接的時間至關於三次握手的時間+SSL時間。

　　聽說，Netscape公司當年設計SSL協議的時候，有人提過，將互聯網全部連接都變成HTTPs開頭的加密連接。這個建議沒有獲得採納，緣由之一是HTTPs連接比不加密

　　的HTTP連接慢不少。（另外一個緣由好像是，HTTPs連接默認不能緩存。）

　　HTTPs連接很慢。可是，它到底有多慢？下面解釋一下，爲何HTTPs鏈接比較蠻。

　　HTTPs連接和HTTP連接都創建在TCP協議之上。HTTP連接比較單純，使用三個握手數據包創建鏈接以後，就能夠發送內容數據了。

　　

　　

　　上圖中，客戶端首先發送SYN數據包，而後服務器發送SYN+ACK數據包，最後客戶端發送ACK數據包，接下來就能夠發送內容了。這三個數據包的發送過程，叫作TCP握手。

　　再來看HTTPs連接，它也採用TCP協議發送數據，因此它也須要上面的這三步握手過程。並且，在這三步結束之後，它還有一個SSL握手。

　　總結一下就是下面這兩個式子。

　　HTTP耗時 = TCP握手

　　HTTPs耗時 = TCP握手 + SSL握手

　　因此，HTTPs確定比HTTP耗時，這就叫SSL延遲。

Request sent（發送請求）

　　發送HTTP請求的時間（從第一個bit到最後一個bit）

　　優化措施：

　　一、減小HTTP請求，可使用CSS Sprites、內聯圖片、合併腳本和樣式表等；

　　二、對不常變化的組件添加長久的Expires頭（至關於設置久遠的過時時間），在後續的頁面瀏覽中能夠避免沒必要要的HTTP請求；

Waiting（等待響應）

　　一般是耗費時間最長的。從發送請求到收到響應之間的空隙，會受到線路、服務器距離等因素的影響。

　　優化措施：

　　一、使用CDN，將用戶的訪問指向距離最近的工做正常的緩存服務器上，由緩存服務器直接響應用戶請求，提升響應速度；

Content Download（下載）

　　下載HTTP響應的時間（包含頭部和響應體）

　　優化措施：

　　一、經過條件Get請求，對比If-Modified-Since和Last-Modified時間，肯定是否使用緩存中的組件，服務器會返回「304 Not Modified」狀態碼，減少響應的大小；

　　二、移除重複腳本，精簡和壓縮代碼，如藉助自動化構建工具grunt、gulp等；

　　三、壓縮響應內容，服務器端啓用gzip壓縮，能夠減小下載時間；