網絡編程中的 time_wait狀態

常常編寫socket程序的程序猿可能會碰到服務器端沒法創建鏈接，報的錯爲：「too many open files」，對不起你的文件描述符資源耗盡了。程序猿大驚：個人文件描述符最大限制爲65535，怎麼能一會兒耗光呢！四處找運維，最終獲得不幸的消息：文件描述符確實被耗光。緣由爲：大量的socket處於close_wait狀態不關閉釋放文件描述符資源。這是怎麼回事呢？
       咱們先看看tcp關閉時的四次握手狀況：

       

        從圖中能夠清楚的看到，close_wait狀態是發生在服務器端的，與上述狀況徹底一致。通常狀況下，socket編程中，客戶端到服務器端的鏈接都會設置超時，若是客戶端向服務器端發起請求，服務器端在規定時間內沒有響應，客戶端會認爲超時，主動關閉鏈接。此時，服務器端會收到客戶端發送的FIN而處於close_wait狀態，服務器端因爲一直在忙於作客戶端剛纔請求的事情，就不會調用close，於是長時間處於「close_wait」狀態。
       回到剛開始提到的場景，能用close_wait把文件描述符耗光的通常來講是服務器端的代碼編寫有問題，一般狀況下是服務器端一直在請求資源沒反應或發生死鎖。例如，服務器端去請求數據庫，結果數據庫配置錯誤，又沒有設置鏈接超時，就很容易發生close_wait狀態佔用完文件描述符。