TCP狀態以及關於內核調優的幾個參數

    不知道大家在面試時候是否會遇到tcp方面相關的面試題,比如幾個相關的內核調優,SYN_FLood***的原理和防禦,time_wait不回收對系統有什麼影響,等等還是很多的,前幾天有人問到,今天剛好細細學習一下:

    一個正常的TCP連接,都會有三個階段:1、TCP三次握手;2、數據傳送;3、TCP四次揮手:(如下)

   wKiom1c6dsrwHr_nAABi-_k8O-w156.png

TCP三次握手(創建 OPEN)

    客戶端發起一個和服務創建TCP鏈接的請求,這裏是SYN(J)
    服務端接受到客戶端的創建請求後,返回兩個信息: SYN(K) + ACK(J+1)
    客戶端在接受到服務端的ACK信息校驗成功後(J與J+1),返回一個信息:ACK(K+1)
    服務端這時接受到客戶端的ACK信息校驗成功後(K與K+1),不再返回信息,後面進入數據通訊階段

數據通訊

    客戶端/服務端 read/write數據包

TCP四次握手(關閉 finish)

    客戶端發起關閉請求,發送一個信息:FIN(M)
    服務端接受到信息後,首先返回ACK(M+1),表明自己已經收到消息。
    服務端在準備好關閉之前,最後發送給客戶端一個 FIN(N)消息,詢問客戶端是否準備好關閉了
    客戶端接受到服務端發送的消息後,返回一個確認信息: ACK(N+1)
    最後,服務端和客戶端在雙方都得到確認時,各自關閉或者回收對應的TCP鏈接。


狀態說明:

   SYN_SEND
        客戶端嘗試鏈接服務端,通過open方法。也就是TCP三次握手中的第1步之後,注意是客戶端狀態
        sysctl -w net.ipv4.tcp_syn_retries = 2 ,做爲客戶端可以設置SYN包的重試次數,默認5次(大約180s)

    SYN_RECEIVED
        服務接受創建請求的SYN後,也就是TCP三次握手中的第2步,發送ACK數據包之前
        注意是服務端狀態,一般15個左右正常,如果很大,懷疑遭受SYN_FLOOD***
        sysctl -w net.ipv4.tcp_max_syn_backlog=200000 , 設置該狀態的等待隊列數,默認1024,調大後可適當防止syn-flood,根據內存大小來定
        sysctl -w net.ipv4.tcp_syncookies=1 , 打開syncookie,在syn backlog隊列不足的時候,提供一種機制臨時將syn鏈接換出
        sysctl -w net.ipv4.tcp_synack_retries = 2 ,做爲服務端返回ACK包的重試次數,默認5次(大約180s),要是遇到網絡SYN_RECV比較多時臨時設置成0也是一個不錯的選擇,***過後改回來。
    ESTABLISHED
        客戶端接受到服務端的ACK包後的狀態,服務端在發出ACK在一定時間後即爲ESTABLISHED
        sysctl -w net.ipv4.tcp_keepalive_time = 1200 ,默認爲7200秒(2小時),系統針對空閒鏈接會進行心跳檢查,如果超過net.ipv4.tcp_keepalive_probes * net.ipv4.tcp_keepalive_intvl = 默認11分,終止對應的tcp鏈接,可適當調整心跳檢查頻率

     FIN_WAIT1
        主動關閉的一方,在發出FIN請求之後,也就是在TCP四次握手的第1步
    CLOSE_WAIT
        被動關閉的一方,在接受到客戶端的FIN後,也就是在TCP四次握手的第2步
    FIN_WAIT2
        主動關閉的一方,在接受到被動關閉一方的ACK後,也就是TCP四次握手的第2步
        sysctl -w net.ipv4.tcp_fin_timeout=30, 可以設定被動關閉方返回FIN後的超時時間,有效回收鏈接,避免syn-flood.
    LASK_ACK
        被動關閉的一方,在發送ACK後一段時間後(確保客戶端已收到),再發起一個FIN請求。也就是TCP四次握手的第3步
    TIME_WAIT
        主動關閉的一方,在收到被動關閉的FIN包後,發送ACK。也就是TCP四次握手的第4步
        sysctl -w net.ipv4.tcp_tw_recycle = 1 , 打開快速回收TIME_WAIT,Enabling this option is not recommended since this causes problems when working with NAT (Network Address Translation)
        sysctl -w net.ipv4.tcp_tw_reuse =1, 快速回收並重用TIME_WAIT的鏈接, 貌似和tw_recycle有衝突,不能重用就回收?
        net.ipv4.tcp_max_tw_buckets: 處於time_wait狀態的最多鏈接數,默認爲180000.


遇到syn_FLOOD***:

    1、查看對方IP:
    # netstat -na |grep SYN_RECV|more
    2、根據對方僞造的IP結合iptables DROP掉,當然誤殺有時候在所難免;
    3、調整內核參數tcp_synack_retries = 0,表示收不到第三次ACK包的時候不進行重試,加速tcp半連接狀態的回收。
    4、調整上面的幾個參數


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章