解決連接數(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包，連接正式建立。但是這里有點(diǎn)出入，當(dāng)請求者收到SYS /ACK包后，就開始建立連接了，而被請求者第三次握手結(jié)束后才建立連接。但是大家明白關(guān)閉連接的工作原理嗎？關(guān)閉連接要四

2、次握手：發(fā)FIN包，ACK 包，F(xiàn)IN包，ACK包，四次握手！為什么呢，因?yàn)門CP連接是全雙工，我關(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)客戶端開始連接時(shí)，服務(wù)器還處于LISTENING，客戶端發(fā)一個(gè)SYN包后

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

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

5、留這個(gè)狀態(tài)下去,越來越多的FIN_WAIT_2狀態(tài)會(huì)導(dǎo)致系統(tǒng)崩潰.上面我碰到的這個(gè)問題主要因?yàn)門CP的結(jié)束流程未走完，造成連接未釋放?，F(xiàn)設(shè)客戶端主動(dòng)斷開連接，流程如下 如上圖所示，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)閉時(shí)而沒有調(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)的話，說明套接字是被動(dòng)關(guān)閉的！因?yàn)槿绻荂LIENT端主動(dòng)斷掉當(dāng)前連接的話，那么雙方關(guān)閉這個(gè)TCP連接共需要四個(gè)packet：Client -> FIN -> ServerClient <- ACK <- Server這時(shí)候Client端處于FIN_WAIT_2狀態(tài)；而Server 程序處于CLOSE_WAIT狀態(tài)。Client <

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

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

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

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

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

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

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

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

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

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

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