概述

總結一下TCP中3次握手過程，以及其原生的缺陷 引起的SYN Flood的介紹

【1】TCP三次握手

【2】SYN Flood

1、TCP連接建立——三次握手

幾個概念：

【1】seq：序號，占4個字節，范圍[0,4284967296],由于TCP是面向字節流的，在一個1個TCP連接中傳送字節流中國的每一個字節都按照順序編號，此外序號是循環使用的

【2】ACK： 僅當ACK=1時確認字段才有效，當ACK=0時確認字段無效，并且TCP規定，在連接建立后所有的傳送報文段都必須要把ACK置為1

【3】SYN：同步序列號，用來發起一個連接。當SYN=1而ACK=0時表明這是一個請求報文段；若對方同意連接，則響應報文中SYN=1，ACK=1

【4】FIN ：用來釋放一個連接，當FIN=1表示此報文段的發送方已經發送完畢。并要求釋放鏈接

1.1、3次握手過程

服務端的TCP進程先創建傳輸控制塊TCB，準備接受客戶端進程的連接請求，然后服務端進程處于LISTEN狀態，等待客戶端的連接請求，如有，則作出響應。
??? 1、客戶端的TCP進程也首先創建傳輸控制模塊TCB，然后向服務端發出連接請求報文段，該報文段首部中的SYN=1，ACK=0，同時選擇一個初始序號 seq=i。TCP規定，SYN=1的報文段不能攜帶數據，但要消耗掉一個序號。這時，TCP客戶進程進入SYN—SENT（同步已發送）狀態，這是 TCP連接的第一次握手。
??? 2、服務端收到客戶端發來的請求報文后，如果同意建立連接，則向客戶端發送確認。確認報文中的SYN=1，ACK=1，確認號ack=i+1，同時為自己 選擇一個初始序號seq=j。同樣該報文段也是SYN=1的報文段，不能攜帶數據，但同樣要消耗掉一個序號。這時，TCP服務端進入SYN—RCVD（同 步收到）狀態，這是TCP連接的第二次握手。
??? 3、TCP客戶端進程收到服務端進程的確認后，還要向服務端給出確認。確認報文段的ACK=1，確認號ack=j+1，而自己的序號為seq=i+1。 TCP的標準規定，ACK報文段可以攜帶數據，但如果不攜帶數據則不消耗序號，因此，如果不攜帶數據，則下一個報文段的序號仍為seq=i+1。這 時，TCP連接已經建立，客戶端進入ESTABLISHED（已建立連接）狀態。這是TCP連接的第三次握手，可以看出第三次握手客戶端已經可以發送攜帶 數據的報文段了。
??? 當服務端收到確認后，也進入ESTABLISHED（已建立連接）狀態。

1.2、關于第三次握手的解釋

前倆比較容易理解，第三次握手看似多余其實不然，這主要是為了防止已失效的請求報文段突然又傳送到了服務端而產生連接的誤判

比如：客戶端發送了一個連接請求報文段A到服務端，但是在某些網絡節點上長時間滯留了，而后客戶端又超時重發了一個連接請求報文段B該服務端，而后 正常建立連接，數據傳輸完畢，并釋放了連接。但是請求報文段A延遲了一段時間后，又到了服務端，這本是一個早已失效的報文段，但是服務端收到后會誤以為客戶端又發出了一次連接請求，于是向客戶端發出確認報文段，并同意建立連接。那么問題來了，假如這里沒有三次握手，這時服務端只要發送了確認，新的 連接就建立了，但由于客戶端沒有發出建立連接的請求，因此不會理會服務端的確認，也不會向服務端發送數據，而服務端卻認為新的連接已經建立了，并在 一直等待客戶端發送數據，這樣服務端就會一直等待下去，直到超出保活計數器的設定值，而將客戶端判定為出了問題，才會關閉這個連接。這樣就浪費了很多服務 器的資源。而如果采用三次握手，客戶端就不會向服務端發出確認，服務端由于收不到確認，就知道客戶端沒有要求建立連接，從而不建立該連接。

2、 缺陷引起的SYN Flood

2.1、SYN Flood 攻擊

SYN- Flood攻擊是當前網絡上最為常見的DDoS攻擊，也是最為經典的拒絕服務攻擊，它就是利用了TCP協議實現上的一個缺陷，通過向網絡服務所在端口發送大量 的偽造源地址的攻擊報文，就可能造成目標服務器中的半開連接隊列被占滿，從而阻止其他合法用戶進行訪問。這種攻擊早在1996年就被發現，但至今仍然顯示 出強大的生命力。很多操作系統，甚至防火墻、路由器都無法有效地防御這種攻擊，而且由于它可以方便地偽造源地址，追查起來非常困難。它的數據包特征通常 是，源發送了大量的SYN包，并且缺少三次握手的最后一步握手ACK回復。

原理：攻擊者首先偽造地址對 服務器發起SYN請求，服務器回應(SYN+ACK)包，而真實的IP會認為，我沒有發送請求，不作回應。服務 器沒有收到回應，這樣的話，服務器不知 道(SYN+ACK)是否發送成功，默認情況下會重試5次（tcp_syn_retries）。這樣的話，對于服務器的內存，帶寬都有很大的消耗。攻擊者 如果處于公網，可以偽造IP的話，對于服務器就很難根據IP來判斷攻擊者，給防護帶來很大的困難。

2.2、SYN Flood 防護措施

主要通過以下3種方式

1． 無效連接監視釋放

這種方法不停的監視系統中半開連接和不活動連接，當達到一定閾值時拆除這些連接，釋放系統資源。這種絕對公平的方法往往也會將正常的連接的請求也會被釋放掉，”傷敵一千，自損八百“

2． 延緩TCB分配方法

SYN Flood關鍵是利用了，SYN數據報文一到，系統立即分配TCB資源，從而占用了系統資源，因此有倆種技術來解決這一問題

Syn Cache技術

這種技術在收到SYN時不急著去分配TCB，而是先回應一個ACK報文，并在一個專用的HASH表中（Cache）中保存這種半開連接，直到收到正確的ACK報文再去分配TCB

Syn Cookie技術

Syn Cookie技術則完全不使用任何存儲資源，它使用一種特殊的算法生成Sequence Number，這種算法考慮到了對方的IP、端口、己方IP、端口的固定信息，以及對方無法知道而己方比較固定的一些信息，如MSS、時間等，在收到對方 的ACK報文后，重新計算一遍，看其是否與對方回應報文中的（Sequence Number-1）相同，從而決定是否分配TCB資源

3． 使用SYN Proxy防火墻

原理：對試圖穿越的SYN請求進行驗證之后才放行、

轉載：http://blog.csdn.net/xsf50717/article/details/47280825

總結

以上是生活随笔為你收集整理的TCP三次握手及其背后的缺陷的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。