TCP三次握手及TCP鏈接狀態 TCP報文首部格式

創建TCP鏈接時的TCP三次握手和斷開TCP鏈接時的4次揮手總體過程以下圖：

 

 

 

開個玩笑

 

ACK: TCP協議規定，只有ACK=1時有效，鏈接創建後全部發送的報文ACK必須爲1

SYN（SYNchronization同步）:在鏈接創建用來同步序號。當SYN＝1而ACK=0時，代表這是一個鏈接請求報文。對方若贊成創建鏈接，則應在響應報文中使用SYN=1

ACK=1所以，SYN置1表示這是一個鏈接請求或鏈接接受報文

FIN（FINIS）即完，終結的意思，用來釋放一個鏈接。當FIN=1時，代表此報文段發送方的數據已經發送完畢，並要求釋放鏈接

 

TCP三次握手過程：

1. 首先由Client發出請求鏈接即SYN=1,聲明本身的序號seq=X

2. 而後Server進行回覆確認，即SYN=1 聲明本身的序號seq=y，並設置ack=x+1

3 .最後Client再進行一次確認，設置seq=x+1 ack+y+1

注：seq 序列號範圍：2^32-1 若是超過最大值，再從0開始

seq 序列號做用：依據這個序列號來組數據，若是發N個數據包，服務端會按序列號來從新組裝數據

使用tcpdump抓取TCP三次握手

tcpdump 經常使用參數：

－c 指定包個數

－n ip,端口用數字方式顯示

port 指定端口

Client:192.168.94.11

server:192.168.94.22

使用Client ssh Server

查看Server端

Flag[S]中的S表示爲SYN包爲1 。client主機返回ack=1 這個值爲相對序號，若是想查看完整序號能夠命令後面加－S

TCP鏈接狀態 : 

服務器端：LISTEN：偵聽來自遠方的TCP端口的鏈接請求

客戶端：SYN-SENT：再發送鏈接請求後等待匹配的鏈接請求

服務器端：SYN-RECEIVED：再收到和發送一個鏈接請求後等待對方對鏈接請求的確認

客戶端/服務器端：ESTABLISHED：表明一個打開的鏈接

客戶端：FIN-WAIT-1：等待遠程TCP鏈接中斷請求，或先前的鏈接中斷請求的確認

服務器端：CLOSE-WAIT：等待從本地用戶發來的鏈接中斷請求

客戶端：FIN-WAIT-2：從遠程TCP等待鏈接中斷請求

服務器端：LAST-ACK：等待原來的發向遠程TCP的鏈接中斷請求的確認

客戶端：TIME-WAIT：等待足夠的時間以確保遠程TCP接收到鏈接中斷請求的確認

服務器端：CLOSED：沒有任何鏈接狀態

 

在服務端返回一個確認的SYN-ACK包的時候有個潛在的弊端，若是發起的客戶是一個不存在的客戶端，那麼服務端就不會接到客戶端迴應的ACK包

這時服務端須要耗費必定的數量的系統內存來等待這個未決的鏈接，直到等待超關閉時間，才能施放內存

若是惡意者經過經過ip欺騙，發送大量SYN包給受害者系統，致使服務端存在大量未決的鏈接並佔用大量內存和tcp鏈接，從而致使正常客戶端沒法訪問服務端，這就是SYN洪水攻擊的過程