在雲上，底層的東西你無法觸及，遇到奇怪問題時只能靠猜想，所以使用雲端計算會鍛鍊你的想像力。

（上圖中藍色是ASP.NET的Requests Queued，另外一個是HTTP.SYS的Arrival Rate）

昨天我們發現了一個重要的線索——“黑色30秒”到來時，最初的表現是請求出現排隊（Requests Queued上升），到達IIS的請求數量（Arrival Rate）下降。

而問題奇特之處就在Arrival Rate下降。如果只是Requests Queued上升，而Arrival Rate處於正常水平，我們首先會懷疑應用程式的原因——應用程式在處理請求時卡在哪個地方；而Requests Queued上升伴隨著Arrival Rate下降，說明不僅後面出不去（請求完成不了），而且前面進不來（請求到達不了IIS）。應用程式不管出什麼樣的問題，都不可能造成Arrival Rate下降，所以我們目前找不到任何理由去懷疑應用程式。

於是，我們針對“前面請求進不來，後面請求出不去”展開了風花雪月的想像，終於找到了一個看上去說得通的猜想，下面分享一下。

*先看一下使用者的請求是如何到達Web伺服器的？

使用者瀏覽器 -> SLB（阿里雲負載均衡） -> VM（虛擬機器）-> Web伺服器

*再看Web伺服器如何將響應傳送給使用者的？

Web伺服器 -> VM -> SLB -> 使用者瀏覽器

【猜想 】

假設SLB或VM在某種觸發條件下，偷偷地斷掉了一些TCP連線，並且不向使用者端與服務端傳送 FIN 或者 RST 報文，除了肇事者，誰也不知道。於是：

1） 使用者端不知道TCP連線被斷，還繼續用這個TCP連線發包，結果請求當然到不了Web伺服器，造成Arrival Rate下降。使用者端TCP層發包後，等回包（比如ACK包），遲遲等不到，一直等到超時（假設超時時間是30s），才知道TCP鏈路掛掉了；然後重建TCP連線重發請求，這時請求成功到達了Web伺服器，當前的請求+之前被斷連線的請求一起到達Web伺服器，這正好解釋了“黑色30秒”結束階段Arrival Rate會突增到一個高點。

2）Web伺服器端與SLB端（或者SLB端與使用者端）的TCP連線被斷，Web伺服器不知道，在處理完請求後還繼續用這個斷掉的TCP連線傳送響應包並等回包，遲遲等不到，造成請求處理不能完成而被堆積，從而進一步造成後續的請求沒有足夠的資源可用而排隊，於是Requests Queued上升；一直等到超時（假設超時時間是30s），Web伺服器才知道TCP鏈路掛掉了，然後放棄這些請求處理，於是有了足夠的資源處理佇列中的請求，這正好解釋了“黑色30秒”結束階段Requests Queued會突降。

這就是我們目前找到的唯一能解釋得通“黑色30秒”問題表現的一個猜想。