項目終于上線了，伴隨著人數的逐步上升，最近查看日志，發現了大量連接超時的日志。項目中使用的是TCP長連接，為了保證網絡資源及時有效的釋放，程序中是1分鐘一次心跳，3分鐘無心跳即認為超時。此為本文的背景
相對于TCP連接建立時的三次握手，我想很多人對斷開連接的四次招呼就不是那么熟了，這里先談一下TCP的斷開，下面給出TCP斷開連接的過程圖：
（peakflys注：TIME_WAIT狀態到CLOSED狀態的轉變視SO_LINGER選項的設置）
從上圖可以看到，在服務器不主動關閉客戶端TCP連接的情況下，需要客戶端發送一個FIN分節，然后服務器端OS TCP棧對這個數據包回復ACK后，服務器處理程序從TCP棧內取出此連接斷開的消息，一般服務器程序的處理是：做完收尾清理工作后馬上調用close或者shutdown操作來關閉相應的socket。這樣雙方都調用了關閉套接口的操作，經過后面的一次確認后才正常的關閉全雙工工作的TCP連接。但是如果客戶端出現了異常，導致FIN包發不到服務器端，那服務器端就只能一直保持這種“死連接”存在。目前解決這種問題的方法有兩個：一、開啟TIME_OUT選項，默認情況下TCP棧兩小時后?；钜淮危ㄈ绻淖冞@個值，需要修改TCP的全局配置選項，對所有在此機器上跑的TCP程序都生效?。?，保活失敗后則關閉連接、回收資源，但這種?；顧C制有很多明顯或隱藏的問題，不建議使用）；二、在應用層面上定義?；顧C制，即在應用層固定時間雙方保持數據的交換即可，超出這個固定時間就認為連接已不存在，執行回收關閉的操作。
之前我對TCP超時的理解就是Client端環境（或者中間路由）發生了異常 導致TCP不優雅的斷開，這種異常存在于兩種情況：
①、客戶端OS崩潰(peakflys注：
程序崩潰時，OS會代進程發送FIN，所以這種情況的出現時在OS負責TCP處理的內核機制失效時，這種失效可以是軟件層面的，如OS自身bug，或驅動層面的故障亦或是直接硬件損壞導致的)
②、雙方網絡中斷(peakflys注：這種中斷可能是中間網絡服務商的路由出現故障，或者客戶端機器的網線拔掉了，斷開了同最后一跳的路由器直接的連接，這種情況下就回觸發TCP的重傳機制，linux下是基于Berkaly的實現方法，默認重傳15分次，持續時間半個小時左右)
上述情況最終表現出來的結果為“主機不可達”或“重傳超時”的錯誤(peakflys注：如果第一種情況被最后一跳的路由器探測到，更新完路由表后就會反饋"主機不可達"的錯誤，探測不到或者第二種情況的重傳機制規定次數還是失敗的話就會反饋“重傳超時”的錯誤)，在這兩種錯誤后，TCP棧就無能為力了。這時服務器端就出現了不優雅的“死鏈接”。
其實這兩種錯誤很容易理解，這就像兩個打電話的人約定如果要掛電話必須要讓對方知道，第二種情況對應的場景是：一方突然被綁架，嘴上被綁上膠帶，然后使勁在心里喊我要掛電話了，我要掛電話了，但是對方聽不到，只能一直傻傻的等著。第一種情況對應的場景是：一方直接被爆頭了，連遺言都沒來得及說就掛了，對方沒聽到他說掛電話，所以也只能傻傻的等到花兒也落了……
言歸正傳，重新回到本次事件的描述上?？吹酱罅康倪B接超時的日志（一天有四百多條記錄，當時用戶量才3000人左右），首先基本排除網絡問題，因為通過對超時的連接IP分析，發現并沒有明顯的區域性，美國很多州的IP都有。那么最有可能的就是客戶端問題了，因為客戶端如果出現死循環或者進程死鎖之類的問題時，因為進程未崩潰，OS的TCP棧不會管你的，這時候客戶端也無力處理服務器發送過來的保活信息，導致服務器端程序認為此鏈接已不存在。但是客戶端的同事說應該不會出現這么多客戶端異常的情況吧，因為測試了很久，最近也沒放出特別的代碼，內部QA人員也從沒有反饋有這種情況。
沒辦法，繼續搜集日志，找找規律。當時的思維就停留在這里了，非優雅連接產生除了客戶端問題，還可能有什么情況？ 不同地方這么多用戶的OS一天內都崩潰？概率應該很小啊，而且前后連續的幾天都是這樣的情況，從概率上講應該是0了吧？ 難道是不同地方的這么多用戶網絡一天內都出現問題？倒是可能出現，但是美國那邊的產品經理和運維人員都說沒有聽過這種情況……
直到第二天和QA的經理在聊起時他說了一句話：如果對方電腦休眠會出現這種情況嗎？我才柯南一般的靈光一閃，電腦休眠或者待機時應該會出現這種情況吧。馬上去微軟官網幫助信息里查找關于待機、休眠的描述：
“休眠”將保存一份桌面及所有打開文件和文檔的映像，然后關閉計算機電源。打開電源時，文件和文檔就會按原來離開時的樣子在桌面上打開。“待機”功能則切斷所用硬件組件的電源，從而減少計算機的電源消耗。“待機”可切斷外圍設備、顯示器甚至硬盤驅動器的電源，但會保留計算機內存的電源，以不至于丟失工作數據。
從上面可以看到休眠直接關閉了計算機的電源，就算是待機也是關閉了外圍設備，因為網絡功能的處理肯定都是最終通過網卡來實現的，如果它關閉了，自然一切的網絡功能都失效了，而且OS還無恥的自己直接“睡”了，導致在服務器程序不知情的情況下，客戶端程序直接被“雪藏”了……
在自己電腦上模擬了一下，日志表現出來的狀況也證實了應該是個答案。至于為什么這種情況每天有上百個，因為外網環境復雜，使用者的習慣更難以捉摸，但持續觀察了很多天，都沒有人反饋客戶端有什么異常，所以基本可以肯定是因windows電源管理策略的待機和休眠導致的。
其實這種情況可以歸為第一種情況：客戶端OS“崩潰”，認真想一下應該可以想到休眠這種情況的，但是當時思維愣是沒往那方面想，一直認為可能是客戶端程序出了問題，導致浪費了將近一天的時間，虛驚一場。很多事情都是這樣，結果出來后再去倒推感覺每個過程都是順理成章的，但是正推時如果有一層窗戶紙沒捅開，就很可能跑到迷宮的另一個方向了……
--peakflys 16:42:04 Monday, May 27, 2013