Thrift第八課 惡劣環境異常

1）中間由于長時間沒有進行交互，信道被路由器回收

????????客戶端沒有檢測到網絡連接斷線，服務器端異常捕獲。日志輸出如下：TSocket::read() recv() <Host: ::ffff:10.95.22.39 Port:50180>errno = 10060

錯誤查找10060

????????由于連接方在一段時間后沒有正確答復或連接的主機沒有反應，連接嘗試失敗

知識擴展?

????????TCP不提供及時連接丟失通知，對于實時保證TCP連接正常的應用程序，需要實現心跳。Thrift基于TCP連接，但不是真正的長連接，只能應用于系統內部穩定高速的網絡環境。為了實現真正的長連接，必須要手動在應用程序中添加心跳包，目前采用的方式是客戶端定時發送一個心跳包，然后服務器收到之后直接返回該心跳包，客戶端在10秒內沒有收到心跳包，說明連接斷開，重新連接。

2）網絡異常

服務器端的系統出現大量未釋放的網絡連接。用netstat -na查看，連接狀態為CLOSE_WAIT

這個問題主要因為TCP的結束流程未走完，造成連接未釋放。現設客戶端主動斷開連接，流程如下

?????? Client??????????????????????????? 消息??????????????????????????????????? Server
???????? close()
????????????????????????????????????? ------ FIN ------->
??????? FIN_WAIT1???????????????????????????????????????????????????????? CLOSE_WAIT
????????????????????????????????????? <----- ACK -------
??????? FIN_WAIT2
????????????????????????????????????????????????????????????????????????????????? close()
?????????????????????????????????????? <------ FIN ------????????????????????
??????? TIME_WAIT?????????????????????????????????????????????????????? LAST_ACK??????
????????????????????????????????????? ------ ACK ------->?
?????????????????????????????????????????????????????????????????????????????????? CLOSED
?????????? CLOSED

如上圖所示，由于Server的Socket在客戶端已經關閉時而沒有調用關閉，造成服務器端的連接處在“掛起”狀態，而客戶端則處在等待應答的狀態上。此問題的典型特征是：一端處于FIN_WAIT2 ，而另一端處于CLOSE_WAIT.?

核心原因是Thrift在刷新數據的時候，拋出異常，傳輸層無法調用關閉函數，套接字無法關閉，因此出現CLOSE_WAIT狀態