tcp三次握手

一：TCP建立過程

1.伺服器先建立TCB(傳輸控制塊),準備接受客戶端的連線請求，然後伺服器處於listen狀態
2.客戶端建立TCB，準備傳送請求連線報文段，此時首部的同步位syn=1(syn不攜帶資料，所以要消耗一個序列號)，選擇一個初始序號seq=x,然後這時候，客戶端從closed狀態->syn-sent(同步已傳送)狀態。
3.伺服器接收請求報文，同意連線之後，則向客戶端傳送確認報文，此時確認報文同部位syn=1,ACK=1,
確認號ack=x+1,但是syn=1，會消耗一個序號，所以要設定seq=y。此時伺服器的狀態是syn-rcvd(同步已接收)。
4.客戶端接收確認報文，還要向伺服器傳送確認報文，確認報文ACK=1,確認號為ack=y+1,因為ACK可以攜帶資料，不需要消耗序號。傳送完之後，這時候客戶端處於established狀態
5.伺服器收到確認報文，這時候也處於了established狀態。

PS：同步位syn=1，不攜帶資料段，所以需要消耗一個序列號，而ACK可以攜帶資料段。


二：為什麼客戶端最後一次還需要傳送一次確認。
這主要為了防止已失效的連線請求報文段突然傳到服務端，因而產生錯誤。


三：TCP三次握手的缺陷
    
    1.SYN FLOOD攻擊
    SYN-FLOOD是一種常見的DDos攻擊，拒絕服務攻擊。通過網路服務所在的埠傳送大量偽造原地址的攻擊報文，傳送到服務端，造成服務端上的半開連線佇列被佔滿，從而阻止其他使用者進行訪問。
    它的資料報特徵是大量syn包，並且缺少最後一步的ACK回覆。



    原理：攻擊者首先偽造地址，對伺服器發起syn請求，伺服器迴應syn+ACK，而真實的IP會認為我沒有傳送請求，不做迴應，而服務端沒有收到迴應，伺服器就不知道是否傳送成功，預設情況下重試5次 syn_retries，這樣的話，對於伺服器記憶體和頻寬有很大的消耗。


    2.解決SYN FLOOD方法
    (1).無效連線監控
    不停監視半開連線和不活動連線，當半開連線數和不活動連線數到達一定值時候，就釋放系統資源。
    傷敵1000，自損8000
    (2).延緩TCB方法
    SYN FLOOD的關鍵是利用了，syn資料報一到，系統就分配TCB資源。
    那麼我們有兩種方法資源問題
    Syn cache
    這種技術在收到Syn時不急著分配TCB，而是先回應一個ACK報文，並在一個專用的HASH表中儲存這種連線，直到收到正確的ACK，才分配TCB。
    (3).Syn Cookie
    用一種特殊的演算法生成sequence number，演算法考慮到對方的資訊和己方資訊，收到對方的ACK報文後，驗證之後才決定是否生成TCB