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