当前位置: 首页>JAVA>正文

如何手動關閉close_wait,CLOSE_WAIT和TIME_WAIT

如何手動關閉close_wait,CLOSE_WAIT和TIME_WAIT

在服務器的日常維護過程中,會經常用到下面的命令:
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
會顯示例如下面的信息:
TIME_WAIT 814
CLOSE_WAIT 1
FIN_WAIT1 1
ESTABLISHED 634
SYN_RECV 2
LAST_ACK 1
常用的三個狀態是:ESTABLISHED 表示正在通信,TIME_WAIT 表示主動關閉,CLOSE_WAIT 表示被動關閉。
具體每種狀態什么意思,其實無需多說,看看下面這種圖就明白了,注意這里提到的服務器應該是業務請求接受處理的一方:

這么多狀態不用都記住,只要了解到我上面提到的最常見的三種狀態的意義就可以了。一般不到萬不得已的情況也不會去查看網絡狀態,如果服務器出了異常,百分之八九十都是下面兩種情況:
1.服務器保持了大量TIME_WAIT狀態
2.服務器保持了大量CLOSE_WAIT狀態
因為linux分配給一個用戶的文件句柄是有限的(可以參考:http://blog.csdn.net/shootyou/article/details/6579139)

TIME_WAIT和CLOSE_WAIT兩種狀態如果一直被保持,那么意味著對應數目的通道就一直被占著,而且是“占著茅坑不使勁”,一旦達到句柄數上限,新的請求就無法被處理了,接著就是大量Too Many Open Files異常,tomcat崩潰。。。

如何手動關閉close_wait,下面來討論下這兩種情況的處理方法,網上有很多資料把這兩種情況的處理方法混為一談,以為優化系統內核參數就可以解決問題,其實是不恰當的,優化系統內核參 數解決TIME_WAIT可能很容易,但是應對CLOSE_WAIT的情況還是需要從程序本身出發。現在來分別說說這兩種情況的處理方法:

1.服務器保持了大量TIME_WAIT狀態

這種情況比較常見,一些爬蟲服務器或者WEB服務器(如果網管在安裝的時候沒有做內核參數優化的話)上經常會遇到這個問題,這個問題是怎么產生的呢?
從上面的示意圖可以看得出來,TIME_WAIT是主動關閉連接的一方保持的狀態,對于爬蟲服務器來說他本身就是“客戶端”,在完成一個爬取任務之后,他就會發起主動關閉連接,從而進入TIME_WAIT的狀態,然后在保持這個狀態2MSL(max segment lifetime)時間之后,徹底關閉回收資源。為什么要這么做?明明就已經主動關閉連接了為啥還要保持資源一段時間呢?這個是TCP/IP的設計者規定的,主要出于以下兩個方面的考慮:

  • 1.防止上一次連接中的包,迷路后重新出現,影響新連接(經過2MSL,上一次連接中所有的重復包都會消失)
  • 2.可靠的關閉TCP連接。在主動關閉方發送的最后一個 ack(fin) ,有可能丟失,這時被動方會重新發fin, 如果這時主動方處于 CLOSED 狀態 ,就會響應 rst 而不是 ack。所以主動方要處于 TIME_WAIT 狀態,而不能是 CLOSED 。另外這么設計TIME_WAIT 會定時的回收資源,并不會占用很大資源的,除非短時間內接受大量請求或者受到攻擊。

MSL 為一個 TCP Segment (某一塊 TCP 網路封包) 從來源送到目的之間可續存的時間 (也就是一個網路封包在網路上傳輸時能存活的時間),由於 RFC 793 TCP 傳輸協定是在 1981 年定義的,當時的網路速度不像現在的網際網路那樣發達,你可以想像你從瀏覽器輸入網址等到第一個 byte 出現要等 4 分鐘嗎?在現在的網路環境下幾乎不可能有這種事情發生,因此我們大可將 TIME_WAIT 狀態的續存時間大幅調低,好讓 連線埠 (Ports) 能更快空出來給其他連線使用。

TIME_WAIT狀態存在的意義、值得一說的是,對于基于TCP的HTTP協議,關閉TCP連接的是Server端,這樣,Server端會進入TIME_WAIT狀態,可想而知,對于訪問量大的Web Server,會存在大量的TIME_WAIT狀態,假如server一秒鐘接收1000個請求,那么就會積壓240*1000=240,000個 TIME_WAIT的記錄,維護這些狀態給Server帶來負擔。當然現代操作系統都會用快速的查找算法來管理這些TIME_WAIT,所以對于新的 TCP連接請求,判斷是否hit中一個TIME_WAIT不會太費時間,但是有這么多狀態要維護總是不好。
HTTP協議1.1版規定default行為是Keep-Alive,也就是會重用TCP連接傳輸多個 request/response,一個主要原因就是發現了這個問題。

也就是說HTTP的交互跟上面畫的那個圖是不一樣的,關閉連接的不是客戶端,而是服務器,所以web服務器也是會出現大量的TIME_WAIT的情況的。
現在來說如何來解決這個問題。

解決思路很簡單,就是讓服務器能夠快速回收和重用那些TIME_WAIT的資源。

下面來看一下我們網管對/etc/sysctl.conf文件的修改:
在這里插入圖片描述
修改完之后執行/sbin/sysctl -p讓參數生效。

TIME_WAIT過多原因?這里頭主要注意到的是
net.ipv4.tcp_tw_reuse
net.ipv4.tcp_tw_recycle
net.ipv4.tcp_fin_timeout
net.ipv4.tcp_keepalive_*
這幾個參數。
net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle的開啟都是為了回收處于TIME_WAIT狀態的資源。
net.ipv4.tcp_fin_timeout這個時間可以減少在異常情況下服務器從FIN-WAIT-2轉到TIME_WAIT的時間。
net.ipv4.tcp_keepalive_*一系列參數,是用來設置服務器檢測連接存活的相關配置。
關于keepalive的用途可以參考:http://hi.baidu.com/tantea/blog/item/580b9d0218f981793812bb7b.html

2.服務器保持了大量CLOSE_WAIT狀態
休息一下,喘口氣,一開始只是打算說說TIME_WAIT和CLOSE_WAIT的區別,沒想到越挖越深,這也是寫博客總結的好處,總可以有意外的收獲。

TIME_WAIT狀態可以通過優化服務器參數得到解決,因為發生TIME_WAIT的情況是服務器自己可控的,要么就是對方連接的異常,要么就是自己沒有迅速回收資源,總之不是由于自己程序錯誤導致的。
但是CLOSE_WAIT就不一樣了,從上面的圖可以看出來,如果一直保持在CLOSE_WAIT狀態,那么只有一種情況,就是在對方關閉連接之后服務器程序自己沒有進一步發出ack信號。換句話說,就是在對方連接關閉之后,程序里沒有檢測到,或者程序壓根就忘記了這個時候需要關閉連接,于是這個資源就一直被程序占著。個人覺得這種情況,通過服務器內核參數也沒辦法解決,服務器對于程序搶占的資源沒有主動回收的權利,除非終止程序運行。

如果你使用的是HttpClient并且你遇到了大量CLOSE_WAIT的情況,那么這篇日志也許對你有用:http://blog.csdn.net/shootyou/article/details/6615051
在那邊日志里頭我舉了個場景,來說明CLOSE_WAIT和TIME_WAIT的區別,這里重新描述一下:
服務器A是一臺爬蟲服務器,它使用簡單的HttpClient去請求資源服務器B上面的apache獲取文件資源,正常情況下,如果請求成功,那么在抓取完資源后,服務器A會主動發出關閉連接的請求,這個時候就是主動關閉連接,服務器A的連接狀態我們可以看到是TIME_WAIT。如果一旦發生異常呢?假設請求的資源服務器B上并不存在,那么這個時候就會由服務器B發出關閉連接的請求,服務器A就是被動的關閉了連接,如果服務器A被動關閉連接之后程序員忘了讓HttpClient釋放連接,那就會造成CLOSE_WAIT的狀態了。

端口timewait如何解決,所以如果將大量CLOSE_WAIT的解決辦法總結為一句話那就是:查代碼。因為問題出在服務器程序里頭啊。
什么情況下,連接處于CLOSE_WAIT狀態呢?

   答案一:在被動關閉連接情況下,在已經接收到FIN,但是還沒有發送自己的FIN的時刻,連接處于CLOSE_WAIT狀態。通常來講,CLOSE_WAIT狀態的持續時間應該很短,正如SYN_RCVD狀態。但是在一些特殊情況下,就會出現連接長時間處于CLOSE_WAIT狀態的情況。答案二:出現大量close_wait的現象,主要原因是某種情況下對方關閉了socket鏈接,但是我方忙與讀或者寫,沒有關閉連接。代碼需要判斷socket,一旦讀到0,斷開連接,read返回負,檢查一下errno,如果不是AGAIN,就斷開連接。
  • 程序問題:如果代碼層面忘記了 close 相應的 socket 連接,那么自然不會發出 FIN 包,從而導致 CLOSE_WAIT 累積;或者代碼不嚴謹,出現死循環之類的問題,導致即便后面寫了 close 也永遠執行不到。
    響應太慢或者超時設置過小:如果連接雙方不和諧,一方不耐煩直接 timeout,另一方卻還在忙于耗時邏輯,就會導致 close 被延后。響應太慢是首要問題,不過換個角度看,也可能是 timeout 設置過小。
  • BACKLOG 太大:此處的 backlog 不是 syn backlog,而是 accept 的 backlog,如果 backlog 太大的話,設想突然遭遇大訪問量的話,即便響應速度不慢,也可能出現來不及消費的情況,導致多余的請求還在隊列里就被對方關閉了。

參考資料:https://blog.csdn.net/shootyou/article/details/6622226 https://huoding.com/2016/01/19/488

https://www.nshth.com/java/338449.html
>

相关文章:

  • 如何手動關閉close_wait
  • TIME_WAIT狀態存在的意義
  • TIME_WAIT過多原因
  • 端口timewait如何解決
  • Time
  • 端口timewait原因
  • 關閉time_wait端口
  • time_waiting
  • pdf去水印軟件免費版,java批量去除pdf簽名,刪除簽名圖標
  • java多線程面試題及答案,JAVA8線程池THREADPOOLEXECUTOR底層原理及其源碼解析
  • java編程,java.lang.Class:是反射的源頭
  • java基礎面試題及答案,HTML CSS 基礎 面試題
  • java編寫軟件工具,Xson:Java對象序列化和反序列化工具
  • nlp預訓練模型,NLP-D62-nlp比賽D31刷題D15
  • kafka如何使用,kafka javax.management.InstanceAlreadyExistsException: kafka.consumer:
  • ssm畢設項目企業部門報銷管理g9d62(java+VUE+Mybatis+Maven+Mysql+sprnig)
  • java小游戲合集,java 煙花_Java 美麗的煙花
  • table列合并,poi操作excel之列合并
  • 找不到指定模塊怎么辦,在烏版圖安裝軟件包時候報錯:E:無法定位軟件包
  • 學云計算好就業嗎,對不起,云計算技術又走錯路了
  • 數電模電基礎知識總結,數電模電實驗課程
  • java的基礎知識,「JavaSE」-面向對象
  • 擴展內存,Java編程內存分析簡要
  • java多線程面試題及答案,【階段一】java之面向對象上
  • java 工作流框架,Activiti工作流使用之SpringBoot整合Activiti
  • 模型的應用形態包括哪些,模型設計準則
  • c語言程序設計培訓班南寧,南寧從零開始學習編程
  • 服務器,Spring Security oAuth2創建認證服務器模塊
  • Java jdk14.0.1安裝簡單步驟
  • 安裝ug12.0當前頁面的腳本發生錯誤,ug提示找不到html文件,[圖文教程] 以下文件無法加載,導致打開操作失敗: 使用當前搜索選項找不到文件,部件已卸載.
  • java執行cmd命令找不到指定文件,java編譯找不到文件_解決cmd運行java程序“找不到文件”提示的方案
  • 線上學畫畫的機構排名,拍樂云推出業內首個「線上美術教學音視頻方案」,打造極致互動體驗
  • day18-java
  • 取兩者中較小值函數,求兩個數中的較大值
  • java多線程面試題及答案,python中的多任務-多線程和多進程
  • 關于Arthas如何遠程監視Java程序
  • Java8 Stream流中的 collect() 方法,遠比你想象中的強大
  • 劉德華《天若有情》,天若有情