chrome的timeline中stalled問題解析

在公司國作一個運營活動，上線後PM老是抱怨訪問速度過慢，影響運營效果。然而從前端的角度來講我已經作了以下優化： css、js合併壓縮、圖片壓縮、雪碧圖、靜態資源所有上CDN。可是依然很慢，實在s是困惑，經過chrome的timeline分析，發現有些請求確實很慢，可是大部分時間消耗在stalled階段。以下圖:

下文來分析具體緣由。

什麼是stalled呢？下面是一段比較容易懂的解釋：

Time the request spent waiting before it could be sent. This time is inclusive of any time spent in proxy negotiation.Additionally, this time will include when the browser is waiting for an already established connection to become available for re-use, obeying Chrome’s maximum six TCP connection per origin rule.

也便是從TCP鏈接創建完成，到真正能夠傳輸數據之間的時間差。先讓咱們要分析TCP鏈接爲何要等待這麼久才能用？我用Wireshark抓包發現(以下圖)，TCP鏈接過程當中有屢次重傳，直到達到最大重傳次數後鏈接被客戶端重置。

爲何會發生重傳呢？

The sender waits for an ACK for the byte-range sent to the client and when not received, resends the packets, after a particular interval. After a certain number of retries, the host is considered to be 「down」 and the sender gives up and tears down the TCP connection.

TCP三次握手後，發送端發送數據後，一段時間內（不一樣的操做系統時間段不一樣）接收不到服務端ACK包，就會以 某一時間間隔(時間間隔通常爲指數型增加)從新發送，從重傳開始到接收端正確響應的時間就是stalled階段。而重傳超過必定的次數（windows系統是5次），發送端就認爲本次TCP鏈接已經down掉了，須要從新創建鏈接。 對比如下，沒有重傳的http請求過程。以下圖：

總結一下：stalled階段時TCP鏈接的檢測過程，若是檢測成功就會繼續使用該TCP鏈接發送數據，若是檢測失敗就會從新創建TCP鏈接。因此出現stalled階段過長，每每是丟包所致，這也意味着網絡或服務端有問題。