https://www.cnblogs.com/jpfss/p/8963763.html
https://www.cnblogs.com/jpfss/p/8963766.html
在公司國做一個運營活動，上線後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階段過長，往往是丟包所致，這也意味著網路或服務端有問題。