在雲上，底層的東西你無法觸及，遇到奇怪問題時只能靠猜想，所以使用雲計算會鍛煉你的想像力。
（上圖中藍色是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秒”問題表現的一個猜想。