雲計算之路系列博文分享的是我們將網站從IDC機房遷移至雲計算平台的實際經歷，目前已遷入阿里雲，這次分享的是我們對之前的博文“解決images.cnblogs.com響應速度慢的詭異問題”中遇到的雲服務器並發連接問題的猜想。不妥之處，歡迎批評指正。
這里再簡單描述一下這個問題：我們的圖片站點（靜態文件）遷移至雲服務器后，在IIS並發連接數達到3500左右的時候，出現了響應速度奇慢的問題。后來，通過多台雲服務器分流，將每台雲服務器的IIS並發連接降至2000以下，問題得到解決。
也許這只是某種特殊情況下的偶發問題，但問題持續了一個工作日，背后肯定有它潛在的原因。對於雲平台這樣復雜的、承載客戶關鍵業務的系統，任何一個響應速度奇慢的問題都值得重視。雖然現在還沒引起阿里雲的足夠重視，但是我們會繼續研究。
與阿里雲客服溝通下來，他們始終以“沒有對IIS的並發連接進行限制”為理由，懷疑問題出在IIS。
而我們卻有不同的想法：
1、同樣的站點、同樣的IIS設置之前在我們自己的服務器上運行多年，從沒出現這樣的問題。——直接證明IIS設置沒問題
2、我們在IIS設置的最大並發連接數限制是5000，出現問題時，發連接數只有3500左右。——與IIS的並發連接數限制無關
3、3500的並發連接對IIS來說是小菜一碟，而且這里是靜態文件，更加是小小菜。我們以前用自己的服務器，在單台服務器上不僅一個ASP.NET站點支撐2萬並發連接沒問題，而且這台服務器同時正常跑着同樣的圖片站點。——與IIS的處理能力無關
4、如果是IIS的原因，會有一個很直接的表現，通過性能監視器監測當前站點的當前連接數（Current Connections），會看到連接數不斷增加。根據我們的觀察，出現這個問題時，這個值在3500左右波動，並沒有不斷增加。——監測數據反映IIS在正常工作
根據我們的分析，我們沒有找到一條可以把問題歸罪於IIS的理由，再加上磁盤IO正常、帶寬充足。如果只置身於雲服務器中，你根本感覺不到有問題存在，一切都正常運轉，世界很美好。
但是，這是一個虛擬的世界，支撐這個虛擬世界的背后是虛擬化平台。我們的猜想就從這個點出發。
當瀏覽器發出一個圖片請求時，請求會先到達虛擬化平台，經過虛擬化平台到達雲服務器的IIS，IIS收到這個正常的請求后作出正常的響應，將圖片內容發向請求端，到這里一切都正常（可以通過雲服務器的監測數據看出）。
但是，響應內容不是由雲服務器的IIS直接發向瀏覽器，而是經由虛擬化平台處理。也就是在客戶瀏覽器與雲服務器的IIS之間橫亘着虛擬化平台，如果雲服務器中一切正常，客戶瀏覽器得到的響應卻極不正常，那會不會可能是虛擬化平台的某個處理環節出現問題了呢？。。。
這就是我們的猜想，也只能猜想。猜想也是一種對問題的思考，每個問題只要認真對待，總會有收獲。
希望這只是一次特殊情況下的偶發現象，也希望阿里雲能重視這個問題，排除可能的潛在原因。