解決連接數(shù)過多和半開攻擊

1、目錄解決TCP連接數(shù)過多的問題1解決方法：4解決半開攻擊的方法5解決方法：8解決TCP連接數(shù)過多的問題TCP狀態(tài)遷移，CLOSE_WAIT & FIN_WAIT2 的問題TCP狀態(tài)遷移對netstat -a命令很熟悉，但是，你有沒有注意到STATE一欄呢，基本上顯示著established,time_wait,close_wait等大家很明白TCP初始化連接三次握手吧：發(fā)SYN包，然后返回SYN/ACK包，再發(fā)ACK包，連接正式建立。但是這里有點出入，當(dāng)請求者收到SYS /ACK包后，就開始建立連接了，而被請求者第三次握手結(jié)束后才建立連接。但是大家明白關(guān)閉連接的工作原理嗎？關(guān)閉連接要四

2、次握手：發(fā)FIN包，ACK 包，F(xiàn)IN包，ACK包，四次握手！為什么呢，因為TCP連接是全雙工，我關(guān)了你的連接，并不等于你關(guān)了我的連接?？蛻舳薚CP狀態(tài)遷移：CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED服務(wù)器TCP狀態(tài)遷移：CLOSED->LISTEN->SYN收到 ->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED當(dāng)客戶端開始連接時，服務(wù)器還處于LISTENING，客戶端發(fā)一個SYN包后

3、，他就處于SYN_SENT狀態(tài),服務(wù)器就處于SYS收到狀態(tài),然后互相確認進入連接狀態(tài)ESTABLISHED.當(dāng)客戶端請求關(guān)閉連接時,客戶端發(fā)送一個FIN包后,客戶端就進入FIN_WAIT_1狀態(tài),等待對方的確認包,服務(wù)器發(fā)送一個ACK包給客戶,客戶端收到ACK包后結(jié)束FIN_WAIT_1狀態(tài),進入FIN_WAIT_2狀態(tài),等待服務(wù)器發(fā)過來的關(guān)閉請求,服務(wù)器發(fā)一個FIN包后,進入CLOSE_WAIT狀態(tài),當(dāng)客戶端收到服務(wù)器的FIN包,FIN_WAIT_2狀態(tài)就結(jié)束,然后給服務(wù)器端的FIN包給以一個確認包,客戶端這時進入TIME_WAIT,當(dāng)服務(wù)器收到確認包后,CLOSE_WAIT狀態(tài)結(jié)束了,這時

4、候服務(wù)器端真正的關(guān)閉了連接.但是客戶端還在TIME_WAIT狀態(tài)下,什么時候結(jié)束呢.我在這里再講到一個新名詞:2MSL等待狀態(tài),其實TIME_WAIT就是2MSL等待狀態(tài),為什么要設(shè)置這個狀態(tài),原因是有足夠的時間讓ACK包到達服務(wù)器端,如果服務(wù)器端沒收到ACK包，超時了，然后重新發(fā)一個FIN包，直到服務(wù)器收到ACK 包.TIME_WAIT狀態(tài)等待時間是在TCP重新啟動后不連接任何請求的兩倍.大家有沒有發(fā)現(xiàn)一個問題:如果對方在第三次握手的時候出問題,如發(fā)FIN包的時候,不知道什么原因丟了這個包,然而這邊一直處在FIN_WAIT_2狀 態(tài),而且TCP/IP并沒有設(shè)置這個狀態(tài)的過期時間,那他一直會保

5、留這個狀態(tài)下去,越來越多的FIN_WAIT_2狀態(tài)會導(dǎo)致系統(tǒng)崩潰.上面我碰到的這個問題主要因為TCP的結(jié)束流程未走完，造成連接未釋放。現(xiàn)設(shè)客戶端主動斷開連接，流程如下 如上圖所示，Client                            消息                            

6、       Server         close()- FIN ->FIN_WAIT1                                                         CLOSE_WAI

7、T<- ACK -FIN_WAIT2 close()<- FIN -                     TIME_WAIT                                                 &

8、#160;     LAST_ACK                                            - ACK -> CLOSEDCLOSED由于Server的Socket在客戶端已經(jīng)關(guān)閉時而沒有調(diào)用關(guān)閉，造成服務(wù)器端的連接處在“掛起”狀態(tài)，而客戶端則處在等待應(yīng)答的狀態(tài)上。此問題的典型特征是：一端處于FIN_WAIT2

9、 ，而另一端處于CLOSE_WAIT.不過，根本問題還是程序?qū)懙牟缓茫写岣?CLOSE_WAIT，TCP的癌癥，TCP的朋友。CLOSE_WAIT狀態(tài)的生成原因首先我們知道，如果我們的服務(wù)器程序APACHE處于CLOSE_WAIT狀態(tài)的話，說明套接字是被動關(guān)閉的！因為如果是CLIENT端主動斷掉當(dāng)前連接的話，那么雙方關(guān)閉這個TCP連接共需要四個packet：Client -> FIN -> ServerClient <- ACK <- Server這時候Client端處于FIN_WAIT_2狀態(tài)；而Server 程序處于CLOSE_WAIT狀態(tài)。Client <

10、;- FIN <- Server這時Server 發(fā)送FIN給Client，Server 就置為LAST_ACK狀態(tài)。Client -> ACK -> ServerClient回應(yīng)了ACK，那么Server 的套接字才會真正置為CLOSED狀態(tài)。Server 程序處于CLOSE_WAIT狀態(tài)，而不是LAST_ACK狀態(tài)，說明還沒有發(fā)FIN給Client，那么可能是在關(guān)閉連接之前還有許多數(shù)據(jù)要發(fā)送或者其 他事要做，導(dǎo)致沒有發(fā)這個FIN packet。解決方法：修改/etc/sysctl.conf添加net.ipv4.tcp_keepalive_time = 3600establ

11、ished狀態(tài)保持時間為3600秒net.ipv4.tcp_keepalive_probes = 6established狀態(tài)保持時間到期后請求次數(shù)net.ipv4.tcp_keepalive_intvl = 25每次請求的間隔時間為25秒然后保存文件sysctl p 使修改的文件立即生效解決半開攻擊的方法TIMEWAIT狀態(tài)本身 和應(yīng)用層的客戶端或者服務(wù)器是沒有關(guān)系的。僅僅是主動關(guān)閉的一方，在使用FIN|ACK|FIN|ACK四分組正常關(guān)閉TCP連接的時候 會出現(xiàn)這個TIMEWAIT。服務(wù)器在處理客戶端請求的時候，如果你的程序設(shè)計為服務(wù)器主動關(guān)閉，那么你才有可能需要關(guān)注這

12、個TIMEWAIT狀態(tài)過多的問題。如果你的服務(wù)器設(shè)計為被動關(guān)閉，那么你首先要關(guān)注的是CLOSE_WAIT。 原則TIMEWAIT并不是多余的 。 在TCP協(xié)議被創(chuàng)造， 經(jīng)歷了大量的實際場景實踐之后 ，TIMEWAIT 出現(xiàn)了，因為TCP主 動關(guān)閉連接的一方需要TIMEWAIT狀態(tài)，它是我們的朋友。這是  UNIX網(wǎng)絡(luò)編程 的作者-Steven對TIMEWAIT的態(tài)度。 TIMEWAIT是友好的      TCP 要保證在所有可

13、能的情況下使得所有的數(shù)據(jù)都能夠被正確送達。當(dāng)你關(guān)閉一個 socket 時，主動關(guān)閉一端的 socket 將進入 TIME_WAIT 狀態(tài)，而被動關(guān)閉一方則轉(zhuǎn)入CLOSED狀態(tài)，這的確能夠保證所有的數(shù)據(jù)都被傳輸。當(dāng)一個socket關(guān)閉的時候，是通過兩端四次握手完成的，當(dāng)一端調(diào)用close()時，就說明本端沒有數(shù)據(jù)要發(fā)送了。這好似看來在握手完成以后，socket就都可以處于初始的CLOSED狀態(tài)了，其實不然。原因是這樣安排狀態(tài)有兩個問題， 首先，我們沒有任何機制保證最后的一個ACK能夠正常傳輸，第二，網(wǎng)絡(luò)上仍然有可能有殘余的數(shù)據(jù)包(wan

14、dering duplicates)，我們也必須能夠正常處理。 TIMEWAIT就是為了解決這兩個問題而生的。 1.假設(shè)最后一個 ACK 丟失了，被動關(guān)閉一方會重發(fā)它的 FIN。 主動關(guān)閉一方必須維持一個有效狀態(tài)信息（TIMEWAIT狀態(tài)下維持），以便能夠重發(fā) ACK。 如果主動關(guān)閉的socket不維持這種狀態(tài)而進入CLOSED狀態(tài)，那么主動關(guān)閉的socket在處于CLOSED狀態(tài)時， 接收到FIN后將會響應(yīng)一個RST。被動關(guān)閉一方接收到RST后會認為出錯了。如果TCP協(xié)議想要正常完成必要的操作而終止雙方

15、的數(shù)據(jù)流傳輸，就必須完全正確的傳輸四次握手的四個節(jié)，不能有任何的丟失。這就是為什么socket在關(guān)閉后，仍然處于TIME_WAIT狀態(tài)的第一個原因，因為他要等待以便重發(fā)ACK。2.假設(shè) 目前連接的通信雙方都已經(jīng)調(diào)用了 close() ，雙方同時進入 CLOSED的終結(jié)狀態(tài)，而沒有走 TIME_WAIT 狀態(tài)。會出現(xiàn)如下問題，現(xiàn)在有一個新的連接被建立起來，使用的IP地址與端口與先前的完全相同，后建立的連接是原先連接的一個完全復(fù)用。還假定原先的連接中有數(shù)據(jù)報殘存于網(wǎng)絡(luò)之中，這樣新的連接收到的數(shù)據(jù)報中有可能是先前連接的數(shù)據(jù)報。為了防止這一點

16、，TCP不允許新連接復(fù)用TIME_WAIT狀態(tài)下的socket。處于TIME_WAIT狀態(tài)的socket在等待兩倍的MSL時間以后（之所以是兩倍的MSL，是由于MSL是一個數(shù)據(jù)報在網(wǎng)絡(luò)中單向發(fā)出到認定丟失的時間，一個數(shù)據(jù)報有可能在發(fā)送途中或是其響應(yīng)過程中成為殘余數(shù)據(jù)報，確認一個數(shù)據(jù)報及其響應(yīng)的丟棄的需要兩倍的MSL），將會轉(zhuǎn)變?yōu)镃LOSED狀態(tài)。這就意味著，一個成功建立的連接，必然使得先前網(wǎng)絡(luò)中殘余的數(shù)據(jù)報都丟失了。大量TIMEWAIT在某些場景中導(dǎo)致的令人頭疼的業(yè)務(wù) 問題大量TIMEWAIT出現(xiàn)，并且需要解決 的場景      &#

17、160; 在高并發(fā)短連接的TCP服務(wù)器上，當(dāng)服務(wù)器處理完 請求后立刻按照主動正常 關(guān)閉連接。這個場景下， 會出現(xiàn)大量socket處于 TIMEWAI T 狀態(tài)。如果客戶端的并發(fā)量持續(xù)很高， 此時部分客戶端就會顯示 連接不上。 我來解釋下這個場景。 主動正常關(guān)閉TCP連接，都會出 現(xiàn)TIMEWAIT。為什么我們要關(guān)注這個高并發(fā)短連接呢？有兩個方面需要注意 ： 1. 高并發(fā)可以讓服務(wù)器在短時間范圍內(nèi)同時 占用大量端口，而端口有個065535的范圍，并

18、不是很多，刨除系統(tǒng)和其他服務(wù)要用的，剩下的就更少了 。 2. 在這個場景中，短連接表示“業(yè)務(wù)處理+傳輸數(shù)據(jù)的時間 遠遠小于 TIMEWAIT超時的時間”的連接。這里有個相對長短 的概念，比如，取一個web頁面，1秒鐘的http 短連接處理完業(yè)務(wù)， 在關(guān)閉連接之后，這個業(yè)務(wù)用過的端口 會停留在TIMEWAIT狀態(tài)幾分鐘，而這幾分鐘，其他HTTP請求來臨的時候是無法占用此端口的 。單用這個業(yè)務(wù)計算服務(wù)器的利用率會發(fā)現(xiàn)，服務(wù)器干正經(jīng)事的時間和端口（資源） 被掛著無法被使用的時間的比例是 1：幾百，服務(wù)器資源嚴重浪費。（說

19、個題外話，從這個意義出發(fā)來考慮服務(wù)器性能調(diào)優(yōu)的話， 長連接業(yè)務(wù)的服務(wù) 就不需要考慮TIMEWAIT狀態(tài)。同時，假如你對服務(wù)器業(yè)務(wù)場景非常熟悉，你會發(fā)現(xiàn)，在實際業(yè)務(wù)場景中， 一般長連接對應(yīng)的業(yè)務(wù)的并發(fā)量并不會很高 ） 綜合這兩個方面，持續(xù)的到達一定量的 高并發(fā)短連接，會使服務(wù)器因端口資源不足而拒絕為一 部分客戶服務(wù)。同時，這些端口都是服務(wù)器臨時分配，無法用SO_ REUSEADDR選項解決這個問題:( 一對矛盾TIMEWAIT既友好，又令人頭疼。 但是我們還是要抱著一個友好的態(tài)度來看待它，因為它盡

20、它的能力保證了服務(wù)器的健壯性。 可行而且必須存在， 但是不符合原則的解決方式1. linux沒有在sysctl或者proc文件系統(tǒng)暴露修改 這個TIMEWAIT超時時間的接口 ，可以修改內(nèi)核協(xié)議棧代碼中關(guān)于這個TIMEWAIT的超時時間參數(shù)，重編內(nèi)核，讓它縮短超時時間，加快回收； 2. 利用SO_LINGER選項的強制關(guān)閉方式，發(fā)RST而不是FIN，來越過TIMEWAIT狀態(tài)，直接進入CLOSED狀態(tài)。詳見我的博 文 TCP之選項 SO_LINGER  。 我如何看待這個問題為什么說上述兩種解決方式我覺得可行，但是不符合原則？ 我首先認為，我要依靠TIMEWAIT狀態(tài)來保證