|
1、LISTENING狀態(tài) FTP服務啟動后首先處于偵聽（LISTENING）狀態(tài)。 2、ESTABLISHED狀態(tài) ESTABLISHED的意思是建立連接。表示兩臺機器正在通信。 3、CLOSE_WAIT 對方主動關閉連接或者網(wǎng)絡異常導致連接中斷，這時我方的狀態(tài)會變成CLOSE_WAIT 此時我方要調(diào)用close()來使得連接正確關閉 4、TIME_WAIT 我方主動調(diào)用close()斷開連接，收到對方確認后狀態(tài)變?yōu)門IME_WAIT。TCP協(xié)議規(guī)定TIME_WAIT狀態(tài)會一直持續(xù)2MSL(即兩倍的分 段最大生存期)，以此來確保舊的連接狀態(tài)不會對新連接產(chǎn)生影響。處于TIME_WAIT狀態(tài)的連接占用的資源不會被內(nèi)核釋放，所以作為服務器，在可能的情 況下，盡量不要主動斷開連接，以減少TIME_WAIT狀態(tài)造成的資源浪費。 目前有一種避免TIME_WAIT資源浪費的方法，就是關閉socket的LINGER選項。但這種做法是TCP協(xié)議不推薦使用的，在某些情況下這個操作可能會帶來錯誤。 5、SYN_SENT狀態(tài) SYN_SENT狀態(tài)表示請求連接，當你要訪問其它的計算機的服務時首先要發(fā)個同步信號給該端口，此時狀態(tài)為SYN_SENT，如果連接成功了就變?yōu)?ESTABLISHED，此時SYN_SENT狀態(tài)非常短暫。但如果發(fā)現(xiàn)SYN_SENT非常多且在向不同的機器發(fā)出，那你的機器可能中了沖擊波或震蕩波 之類的病毒了。這類病毒為了感染別的計算機，它就要掃描別的計算機，在掃描的過程中對每個要掃描的計算機都要發(fā)出了同步請求，這也是出現(xiàn)許多 SYN_SENT的原因。 根據(jù)TCP協(xié)議定義的3次握手斷開連接規(guī)定,發(fā)起socket主動關閉的一方 socket將進入TIME_WAIT狀態(tài),TIME_WAIT狀態(tài)將持續(xù)2個MSL(Max Segment Lifetime),在Windows下默認為4分鐘,即240秒,TIME_WAIT狀態(tài)下的socket不能被回收使用. 具體現(xiàn)象是對于一個處理大量短連接的服務器,如果是由服務器主動關閉客戶端的連接,將導致服務器端存在大量的處于TIME_WAIT狀態(tài)的socket, 甚至比處于Established狀態(tài)下的socket多的多,嚴重影響服務器的處理能力,甚至耗盡可用的socket,停止服務. TIME_WAIT是TCP協(xié)議用以保證被重新分配的socket不會受到之前殘留的延遲重發(fā)報文影響的機制,是必要的邏輯保證. HttpClient連接池拋出大量ConnectionPoolTimeoutException: Timeout waiting for connection異常排查 今天解決了一個HttpClient的異常，汗啊，一個HttpClient使用稍有不慎都會是毀滅級別的啊。 這里有之前因為route配置不當導致服務器異常的一個處理：http://blog.csdn.net/shootyou/article/details/6415248 里面的HttpConnectionManager實現(xiàn)就是我在這里使用的實現(xiàn)。 簡單來說CLOSE_WAIT數(shù)目過大是由于被動關閉連接處理不當導致的。 我說一個場景，服務器A會去請求服務器B上面的apache獲取文件資源，正常情況下，如果請求成功，那么在抓取完資源后服務器A會主動發(fā)出關閉連接的請求，這個時候就是主動關閉連接，連接狀態(tài)我們可以看到是TIME_WAIT。如果一旦發(fā)生異常呢？假設請求的資源服務器B上并不存在，那么這個時候就會由服務器B發(fā)出關閉連接的請求，服務器A就是被動的關閉了連接，如果服務器A被動關閉連接之后自己并沒有釋放連接，那就會造成CLOSE_WAIT的狀態(tài)了。 一、“多半是程序的原因”？這個還是交給程序猿吧 二、linux 下 CLOSE_WAIT過多的解決方法 情景描述：系統(tǒng)產(chǎn)生大量“Too many open files” 原因分析：在服務器與客戶端通信過程中，因服務器發(fā)生了socket未關導致的closed_wait發(fā)生，致使監(jiān)聽port打開的句柄數(shù)到了1024個，且均處于close_wait的狀態(tài)，最終造成配置的port被占滿出現(xiàn)“Too many open files”，無法再進行通信。 close_wait狀態(tài)出現(xiàn)的原因是被動關閉方未關閉socket造成 解決辦法：有兩種措施可行 一、解決： 原因是因為調(diào)用ServerSocket類的accept()方法和Socket輸入流的read()方法時會引起線程阻塞，所以應該用setSoTimeout()方法設置超時（缺省的設置是0，即超時永遠不會發(fā)生）；超時的判斷是累計式的，一次設置后，每次調(diào)用引起的阻塞時間都從該值中扣除，直至另一次超時設置或有超時異常拋出。 比如，某種服務需要三次調(diào)用read()，超時設置為1分鐘，那么如果某次服務三次read()調(diào)用的總時間超過1分鐘就會有異常拋出，如果要在同一個Socket上反復進行這種服務，就要在每次服務之前設置一次超時。 二、規(guī)避： 調(diào)整系統(tǒng)參數(shù)，包括句柄相關參數(shù)和TCP/IP的參數(shù)； 注意： /proc/sys/fs/file-max 是整個系統(tǒng)可以打開的文件數(shù)的限制，由sysctl.conf控制； ulimit修改的是當前shell和它的子進程可以打開的文件數(shù)的限制，由limits.conf控制； lsof是列出系統(tǒng)所占用的資源,但是這些資源不一定會占用打開文件號的；比如：共享內(nèi)存,信號量,消息隊列,內(nèi)存映射等,雖然占用了這些資源,但不占用打開文件號； 因此，需要調(diào)整的是當前用戶的子進程打開的文件數(shù)的限制，即limits.conf文件的配置； 如果cat /proc/sys/fs/file-max值為65536或甚至更大，不需要修改該值； 若ulimit -a ；其open files參數(shù)的值小于4096（默認是1024), 則采用如下方法修改open files參數(shù)值為8192；方法如下： 1.使用root登陸，修改文件/etc/security/limits.conf vim /etc/security/limits.conf 添加 xxx - nofile 8192 xxx 是一個用戶，如果是想所有用戶生效的話換成 * ，設置的數(shù)值與硬件配置有關，別設置太大了。 #<domain> <type> <item> <value> * soft nofile 8192 * hard nofile 8192 #所有的用戶每個進程可以使用8192個文件描述符。 2.使這些限制生效 確定文件/etc/pam.d/login 和/etc/pam.d/sshd包含如下行： session required pam_limits.so 然后用戶重新登陸一下即可生效。 3. 在bash下可以使用ulimit -a 參看是否已經(jīng)修改： 一、 修改方法：（暫時生效,重新啟動服務器后,會還原成默認值） sysctl -w net.ipv4.tcp_keepalive_time=600 sysctl -w net.ipv4.tcp_keepalive_probes=2 sysctl -w net.ipv4.tcp_keepalive_intvl=2 注意：Linux的內(nèi)核參數(shù)調(diào)整的是否合理要注意觀察，看業(yè)務高峰時候效果如何。 二、 若做如上修改后，可起作用；則做如下修改以便永久生效。 vi /etc/sysctl.conf 若配置文件中不存在如下信息，則添加： net.ipv4.tcp_keepalive_time = 1800 net.ipv4.tcp_keepalive_probes = 3 net.ipv4.tcp_keepalive_intvl = 15 編輯完 /etc/sysctl.conf,要重啟network 才會生效 /etc/rc.d/init.d/network restart 然后，執(zhí)行sysctl命令使修改生效，基本上就算完成了。 修改原因： 當客戶端因為某種原因先于服務端發(fā)出了FIN信號，就會導致服務端被動關閉，若服務端不主動關閉socket發(fā)FIN給Client，此時服務端Socket會處于CLOSE_WAIT狀態(tài)（而不是LAST_ACK狀態(tài)）。通常來說，一個CLOSE_WAIT會維持至少2個小時的時間（系統(tǒng)默認超時時間的是7200秒，也就是2小時）。如果服務端程序因某個原因?qū)е孪到y(tǒng)造成一堆CLOSE_WAIT消耗資源，那么通常是等不到釋放那一刻，系統(tǒng)就已崩潰。因此，解決這個問題的方法還可以通過修改TCP/IP的參數(shù)來縮短這個時間，于是修改tcp_keepalive_*系列參數(shù)： tcp_keepalive_time： /proc/sys/net/ipv4/tcp_keepalive_time 點擊打開鏈接 INTEGER，默認值是7200(2小時) 當keepalive打開的情況下，TCP發(fā)送keepalive消息的頻率。建議修改值為1800秒。 tcp_keepalive_probes：INTEGER /proc/sys/net/ipv4/tcp_keepalive_probes INTEGER，默認值是9 TCP發(fā)送keepalive探測以確定該連接已經(jīng)斷開的次數(shù)。(注意:保持連接僅在SO_KEEPALIVE套接字選項被打開是才發(fā)送.次數(shù)默認不需要修改,當然根據(jù)情形也可以適當?shù)乜s短此值.設置為5比較合適) tcp_keepalive_intvl：INTEGER /proc/sys/net/ipv4/tcp_keepalive_intvl INTEGER，默認值為75 當探測沒有確認時，重新發(fā)送探測的頻度。探測消息發(fā)送的頻率（在認定連接失效之前，發(fā)送多少個TCP的keepalive探測包）。乘以tcp_keepalive_probes就得到對于從開始探測以來沒有響應的連接殺除的時間。默認值為75秒，也就是沒有活動的連接將在大約11分鐘以后將被丟棄。(對于普通應用來說,這個值有一些偏大,可以根據(jù)需要改小.特別是web類服務器需要改小該值,15是個比較合適的值) 1. 系統(tǒng)不再出現(xiàn)“Too many open files”報錯現(xiàn)象。 2. 處于TIME_WAIT狀態(tài)的sockets不會激長。 在 Linux 上可用以下語句看了一下服務器的TCP狀態(tài)(連接狀態(tài)數(shù)量統(tǒng)計)： netstat -n| awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'服務器TIME_WAIT和CLOSE_WAIT詳解和解決辦法 在服務器的日常維護過程中，會經(jīng)常用到下面的命令：
它會顯示例如下面的信息： TIME_WAIT 814 常用的三個狀態(tài)是：ESTABLISHED 表示正在通信，TIME_WAIT 表示主動關閉，CLOSE_WAIT 表示被動關閉。 具體每種狀態(tài)什么意思，其實無需多說，看看下面這種圖就明白了，注意這里提到的服務器應該是業(yè)務請求接受處理的一方：
這么多狀態(tài)不用都記住，只要了解到我上面提到的最常見的三種狀態(tài)的意義就可以了。一般不到萬不得已的情況也不會去查看網(wǎng)絡狀態(tài)，如果服務器出了異常，百分之八九十都是下面兩種情況： 1.服務器保持了大量TIME_WAIT狀態(tài) 2.服務器保持了大量CLOSE_WAIT狀態(tài) 因為linux分配給一個用戶的文件句柄是有限的（可以參考：http://blog.csdn.net/shootyou/article/details/6579139），而TIME_WAIT和CLOSE_WAIT兩種狀態(tài)如果一直被保持，那么意味著對應數(shù)目的通道就一直被占著，而且是“占著茅坑不使勁”，一旦達到句柄數(shù)上限，新的請求就無法被處理了，接著就是大量Too Many Open Files異常，tomcat崩潰。。。 下 面來討論下這兩種情況的處理方法，網(wǎng)上有很多資料把這兩種情況的處理方法混為一談，以為優(yōu)化系統(tǒng)內(nèi)核參數(shù)就可以解決問題，其實是不恰當?shù)?，?yōu)化系統(tǒng)內(nèi)核參 數(shù)解決TIME_WAIT可能很容易，但是應對CLOSE_WAIT的情況還是需要從程序本身出發(fā)?，F(xiàn)在來分別說說這兩種情況的處理方法： 1.服務器保持了大量TIME_WAIT狀態(tài) 這種情況比較常見，一些爬蟲服務器或者WEB服務器（如果網(wǎng)管在安裝的時候沒有做內(nèi)核參數(shù)優(yōu)化的話）上經(jīng)常會遇到這個問題，這個問題是怎么產(chǎn)生的呢？ 從 上面的示意圖可以看得出來，TIME_WAIT是主動關閉連接的一方保持的狀態(tài)，對于爬蟲服務器來說他本身就是“客戶端”，在完成一個爬取任務之后，他就 會發(fā)起主動關閉連接，從而進入TIME_WAIT的狀態(tài)，然后在保持這個狀態(tài)2MSL（max segment lifetime）時間之后，徹底關閉回收資源。為什么要這么做？明明就已經(jīng)主動關閉連接了為啥還要保持資源一段時間呢？這個是TCP/IP的設計者規(guī)定 的，主要出于以下兩個方面的考慮： 1.防止上一次連接中的包，迷路后重新出現(xiàn)，影響新連接（經(jīng)過2MSL，上一次連接中所有的重復包都會消失） 關于MSL引用下面一段話：
再引用網(wǎng)絡資源的一段話：
也就是說HTTP的交互跟上面畫的那個圖是不一樣的，關閉連接的不是客戶端，而是服務器，所以web服務器也是會出現(xiàn)大量的TIME_WAIT的情況的。 現(xiàn)在來說如何來解決這個問題。 解決思路很簡單，就是讓服務器能夠快速回收和重用那些TIME_WAIT的資源。 下面來看一下我們網(wǎng)管對/etc/sysctl.conf文件的修改：
修改完之后執(zhí)行/sbin/sysctl -p讓參數(shù)生效。 這里頭主要注意到的是net.ipv4.tcp_tw_reuse net.ipv4.tcp_tw_recycle net.ipv4.tcp_fin_timeout net.ipv4.tcp_keepalive_* 這幾個參數(shù)。 net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle的開啟都是為了回收處于TIME_WAIT狀態(tài)的資源。 net.ipv4.tcp_fin_timeout這個時間可以減少在異常情況下服務器從FIN-WAIT-2轉(zhuǎn)到TIME_WAIT的時間。 net.ipv4.tcp_keepalive_*一系列參數(shù)，是用來設置服務器檢測連接存活的相關配置。 關于keepalive的用途可以參考：http://hi.baidu.com/tantea/blog/item/580b9d0218f981793812bb7b.html 2.服務器保持了大量CLOSE_WAIT狀態(tài) 休息一下，喘口氣，一開始只是打算說說TIME_WAIT和CLOSE_WAIT的區(qū)別，沒想到越挖越深，這也是寫博客總結(jié)的好處，總可以有意外的收獲。 TIME_WAIT狀態(tài)可以通過優(yōu)化服務器參數(shù)得到解決，因為發(fā)生TIME_WAIT的情況是服務器自己可控的，要么就是對方連接的異常，要么就是自己沒有迅速回收資源，總之不是由于自己程序錯誤導致的。 但 是CLOSE_WAIT就不一樣了，從上面的圖可以看出來，如果一直保持在CLOSE_WAIT狀態(tài)，那么只有一種情況，就是在對方關閉連接之后服務器程 序自己沒有進一步發(fā)出ack信號。換句話說，就是在對方連接關閉之后，程序里沒有檢測到，或者程序壓根就忘記了這個時候需要關閉連接，于是這個資源就一直 被程序占著。個人覺得這種情況，通過服務器內(nèi)核參數(shù)也沒辦法解決，服務器對于程序搶占的資源沒有主動回收的權利，除非終止程序運行。 如果你使用的是HttpClient并且你遇到了大量CLOSE_WAIT的情況，那么這篇日志也許對你有用：http://blog.csdn.net/shootyou/article/details/6615051 在那邊日志里頭我舉了個場景，來說明CLOSE_WAIT和TIME_WAIT的區(qū)別，這里重新描述一下： 服 務器A是一臺爬蟲服務器，它使用簡單的HttpClient去請求資源服務器B上面的apache獲取文件資源，正常情況下，如果請求成功，那么在抓取完 資源后，服務器A會主動發(fā)出關閉連接的請求，這個時候就是主動關閉連接，服務器A的連接狀態(tài)我們可以看到是TIME_WAIT。如果一旦發(fā)生異常呢？假設 請求的資源服務器B上并不存在，那么這個時候就會由服務器B發(fā)出關閉連接的請求，服務器A就是被動的關閉了連接，如果服務器A被動關閉連接之后程序員忘了 讓HttpClient釋放連接，那就會造成CLOSE_WAIT的狀態(tài)了。 所以如果將大量CLOSE_WAIT的解決辦法總結(jié)為一句話那就是：查代碼。因為問題出在服務器程序里頭啊。 參考資料： 1.windows下的TIME_WAIT的處理可以參加這位大俠的日志：http://blog./post/2010/11/17/How-to-deal-with-TIME_WAIT-problem-under-Windows.aspx 2.WebSphere的服務器優(yōu)化有一定參考價值：http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tprf_tunelinux.html 3.各種內(nèi)核參數(shù)的含義：http://haka./blog/BlogTopic/32309.htm 4.linux服務器歷險之sysctl優(yōu)化linux網(wǎng)絡：http://blog.csdn.net/chinalinuxzend/article/details/1792184 |
|
|
