在公司國做一個運營活動，上線后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階段過長，往往是丟包所致，這也意味着網絡或服務端有問題。