我記得這個問題是大4同學在找工作的時候被問及的（我考研）。他當時也是一臉懵逼，回來之後還把這個跟我說了，我也不知道這個問題的答案（說白了就是知識串聯的不好）。不過後來從新整理一下思路就得到答案了，這裡我就不放三次握手的**過程了。完全可以從之前的知識以及常識推出這個問題的答案。
我們都知道三次握手的第一步是客戶端向伺服器傳送連線請求，第二步是伺服器回應客戶端的請求，第三步是客戶端確認連線。其實這個問題的答案就在第二步。在第二次握手時，伺服器的tcp收到連線請求報文段後,如若同意建立連線,就向客戶端傳送確認,並在os核心中為該tcp連線分配tcp快取和變數。在確認報文段中,syn和ack位都被置為1,確認號字段的值為x+1(表示希望收到的下乙個位元組的序號為x+1),並且伺服器隨機產生起始序號seq=y(確認報文不攜帶資料,但也要消耗掉乙個序號)。在計算機裡的資源就是兩個東西——時間和空間（時間是指處理機的時間，而空間就是硬碟，記憶體等空間）。這個分配資源的時間很好理解，如若是在第三次握手時才分配資源，那對客戶端請求響應肯定會變慢。了解了這個分配資源的問題後，假如，乙個黑客想攻擊一台伺服器，他可以怎麼做？首先他偽造位址對伺服器發起syn請求，伺服器回應(syn+ack)包，而真正的ip並沒有做出相應的請求，當然不會回應。伺服器沒有收到回應，這樣的話，伺服器會認為(syn+ack)丟了，預設情況下會重試5次。在這種狀態下，伺服器會一直維護剛才所分配的資源，可是這些資源並不能被真正的使用者所利用。在這個過程中，黑客只需要做到浪費伺服器的資源，使得伺服器無法響應多數客戶端的請求，就能達到攻擊伺服器的目的了。這就是三次握手存在的缺陷，也是syn flood攻擊的原理。
還有乙個問題就是accept函式是在那個階段呼叫的。之前我一直以為是第二次握手的時候就完成這項工作了。可是沒想到啊，最近檢視資料後發現自己是大錯特錯（要不然我也不會整理這兩個知識點）。因為伺服器在建立socket、bind、listen之後就要接收客戶端的連線請求。而且，伺服器就是用accept函式返回的socket檔案描述符與客戶端通訊。我自然而然的認為accept函式是在伺服器分配資源的時候完成的。現在再整理一遍思路，假如accept函式在第二次握手就被呼叫，這時有許多客戶端都和該服務端進行連線，傳送syn報文，伺服器收到之後，這些客戶端又不理會伺服器，但此時服務端的資源已經被accept函式分配了。是不是感覺又回到了第乙個問題？為了解決這個問題，accept函式被放在三次握手之後。雖然accept函式被放到了三次握手後，但是伺服器接收客戶端的請求是不會受到影響的。
（1）無效連線監視釋放：這種方法不停的監視系統中半開連線和不活動的連線，當達到一定閾值時就釋放這些連線，從而**系統的資源。這種絕對公平的方法往往也會將正常的連線的請求也會被釋放掉。
（2）延緩tcb分配方法：syn flood關鍵是利用了syn資料報文一到，伺服器立即分配tcb資源，從而占用了伺服器資源。可以用兩種技術來解決這一問題。syn cache技術：它的思想是在收到syn時不急著去分配tcb，而是先回應乙個ack報文，並在乙個專用的hash表中（cache）中儲存這種半開連線，直到收到正確的ack報文再去分配tcb。syn cookie技術：完全不使用任何儲存資源，它使用一種特殊的演算法生成sequence number，這種演算法考慮到了對方的ip、埠、己方ip、埠的固定資訊，以及對方無法知道而己方比較固定的一些資訊，如mss、時間等，在收到對方 的ack報文後，重新計算一遍，看其是否與對方回應報文中的（sequence number-1）相同，從而決定是否分配tcb資源。
**：
TCP三次握手及其背後的缺陷
概述 總結一下tcp中3次握手過程，以及其原生的缺陷 引起的syn flood的介紹 tcp三次握手 syn flood 幾個概念 seq 序號。佔4個位元組，範圍 0,4284967296 因為tcp是面向位元組流的。在乙個1個tcp連線中傳送位元組流中國的每個位元組都依照順序編號。此外序號是迴圈...
tcp三次握手 TCP 三次握手總結
tcp特點概述 tcp segment structure 段結構 step2 server host receives syn,replie with syn ack segment 答覆syn ack報文段 step3 client receives synack,replies with ac...
tcp的三次握手 傳輸層 TCP 三次握手
使用tcp協議進行通訊的雙方必須先建立連線，然後才能開始傳輸資料。為了確保連線雙方可靠性，在雙方建立連線時，tcp協議採用了三次握手策略。如圖 客戶端傳送帶有syn標誌的連線請求報文段，然後進入syn send狀態，等待服務端的確認。服務端接收到客戶端的syn報文段後，需要傳送ack資訊對這個syn...