解決連接數(shù)過多和半開攻擊_第1頁
解決連接數(shù)過多和半開攻擊_第2頁
解決連接數(shù)過多和半開攻擊_第3頁
解決連接數(shù)過多和半開攻擊_第4頁
解決連接數(shù)過多和半開攻擊_第5頁
已閱讀5頁,還剩3頁未讀 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

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)來保證

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論