概述

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

【1】TCP三次握手

【2】SYN Flood

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

幾個概念：

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

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

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

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

1.1、3次握手過程

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

1.2、關(guān)于第三次握手的解釋

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

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

2、 缺陷引起的SYN Flood

2.1、SYN Flood 攻擊

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

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

2.2、SYN Flood 防護措施

主要通過以下3種方式

1． 無效連接監(jiān)視釋放

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

2． 延緩TCB分配方法

SYN Flood關(guān)鍵是利用了，SYN數(shù)據(jù)報文一到，系統(tǒng)立即分配TCB資源，從而占用了系統(tǒng)資源，因此有倆種技術(shù)來解決這一問題

Syn Cache技術(shù)

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

Syn Cookie技術(shù)

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

3． 使用SYN Proxy防火墻

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

轉(zhuǎn)載：http://blog.csdn.net/xsf50717/article/details/47280825

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。