TCP三次握手與四次揮手詳解

目錄

• TCP三次握手與四次揮手詳解
  • 1.TCP報文格式
  • 2.TCP三次握手
  • 3.TCP四次揮手
  • 4.爲何創建鏈接須要三次握手？
  • 5.爲何斷開鏈接須要四次揮手？
  • 6.爲何TIME_WAIT狀態還須要等2MSL後才能返回到CLOSED狀態？
  • 7.SYN攻擊原理
  • 參考文檔

TCP三次握手與四次揮手詳解

@(TCP/IP)

1.TCP報文格式

TCP(Transmission Control Protocol)　傳輸控制協議。TCP是主機對主機層的傳輸控制協議，提供可靠的鏈接服務，採用三次握手確認創建一個鏈接。

咱們須要知道TCP在網絡OSI的七層模型中的第四層（Transport層），IP在第三層（Network層），第二層（Data Link層），在第二層上的數據，咱們叫Frame，在第三層上的數據叫Packet，第四層的數據叫Segment。

TCP傳輸控制協議是面向鏈接的可靠的傳輸層協議，在進行數據傳輸以前，須要在傳輸數據的兩端（客戶端和服務器端）建立一個鏈接，這個鏈接由一對插口地址惟一標識，便是在IP報文首部的源IP地址、目的IP地址，以及TCP數據報首部的源端口地址和目的端口地址

上圖中有幾個字段須要重點介紹下：

（1）Sequence Number序號：Seq序號，佔32位，用來標識從TCP源端向目的端發送的字節流，發起方發送數據時對此進行標記。是包的序號，用來解決網絡包亂序（reordering）問題。

（2）Acknowledgement Number確認序號：Ack序號，佔32位，只有ACK標誌位爲1時，確認序號字段纔有效，Ack=Seq+1。

（3）標誌位：共6個，即URG、ACK、PSH、RST、SYN、FIN等，具體含義以下：

a. URG(urgent緊急)：緊急指針（urgent pointer）有效。

b.ACK(acknowledgement 確認)：確認序號有效。

c.PSH(push傳送)：接收方應該儘快將這個報文交給應用層。

d.RST(reset重置)：重置鏈接。

e.SYN (synchronous創建聯機)：發起一個新鏈接。

f.FIN(finish結束)：釋放一個鏈接。

須要注意的是：

（A）不要將確認序號Ack與標誌位中的ACK搞混了。

（B）確認方Ack=發起方Seq+1，兩端配對。

2.TCP三次握手

TCP是主機對主機層的傳輸控制協議，提供可靠的鏈接服務，採用三次握手確認創建一個鏈接。
所謂三次握手（Three-Way Handshake）即創建TCP鏈接，是指創建一個TCP鏈接時，須要客戶端和服務端總共發送3個包以確認鏈接的創建。
使用wireshark抓包工具分析以下：

能夠得出下圖：

解釋以下：
第一次握手：Client將標誌位SYN置爲1，隨機產生一個值seq=x，並將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。

第二次握手：Server收到數據包後由標誌位SYN=1知道Client請求創建鏈接，Server將標誌位SYN和ACK都置爲1，ack (number )=x+1，隨機產生一個值seq=y，並將該數據包發送給Client以確認鏈接請求，Server進入SYN_RCVD狀態。

第三次握手：Client收到確認後，檢查ack是否爲y+1，標誌位ACK是否爲1，若是正確則將標誌位ACK置爲1，ack=y+1，並將該數據包發送給Server，Server檢查ack是否爲y+1，ACK是否爲1，若是正確則鏈接創建成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間能夠開始傳輸數據了。

3.TCP四次揮手

所謂四次揮手（Four-Way Wavehand）即終止TCP鏈接，就是指斷開一個TCP鏈接時，須要客戶端和服務端總共發送4個包以確認鏈接的斷開。

鏈接雙方在完成數據傳輸以後就須要斷開鏈接。因爲TCP鏈接是屬於全雙工的，即鏈接雙方能夠在一條TCP鏈接上互相傳輸數據，所以在斷開時存在一個半關閉狀態，即有有一方失去發送數據的能力，卻還能接收數據。所以，斷開鏈接須要分爲四次
使用wireshark抓包工具分析以下：

流程以下：

因爲TCP鏈接時全雙工的，所以，每一個方向都必需要單獨進行關閉，這一原則是當一方完成數據發送任務後，發送一個FIN來終止這一方向的鏈接，收到一個FIN只是意味着這一方向上沒有數據流動了，即不會再收到數據了，可是在這個TCP鏈接上仍然可以發送數據，直到這一方向也發送了FIN。首先進行關閉的一方將執行主動關閉，而另外一方則執行被動關閉。

第一次揮手：Client將標誌位FIN和ACK置爲1而且發送發送一個FIN和ACK，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。

第二次揮手：Server收到FIN後，發送一個ACK給Client，確認序號Ack爲收到Seq+1（與SYN相同，一個FIN佔用一個序號），序號Seq=1，Server進入CLOSE_WAIT狀態。

第三次揮手：Server發送一個FIN，標誌位FIN和ACK置爲1，用來關閉Server到Client的數據傳送，Seq=y，Ack=上次的Seq+1，Server進入LAST_ACK狀態。

第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接着發送一個ACK給Server，確認序號Ack爲收到序號Seq+1，Server進入CLOSED狀態，完成四次揮手。

4.爲何創建鏈接須要三次握手？

TCP是主機對主機層的傳輸控制協議，提供可靠的鏈接服務，採用三次握手確認創建一個鏈接。確保數據可以完整傳輸。
這是由於服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求後，它能夠把ACK和SYN（ACK起應答做用，而SYN起同步做用）放在一個報文裏來發
送。

5.爲何斷開鏈接須要四次揮手？

當被動方收到主動方的FIN報文通知時，它僅僅表示主動方沒有數據再發送給被動方了。
但未必被動方全部的數據都完整的發送給了主動方，因此被動方不會立刻關閉SOCKET,它可能還須要發送一些數據給主動方後，再發送FIN報文給主動方，告訴主動方贊成關閉鏈接，因此這裏的ACK報文和FIN報文多數狀況下都是分開發送的。

6.爲何TIME_WAIT狀態還須要等2MSL後才能返回到CLOSED狀態？

這是由於雖然雙方都贊成關閉鏈接了，並且握手的4個報文也都協調和發送完畢，按理能夠直接回到CLOSED狀態（就比如從SYN_SEND狀態到ESTABLISH狀態那樣）；可是由於咱們必需要假想網絡是不可靠的，你沒法保證你最後發送的ACK報文會必定被對方收到，所以對方處於LAST_ACK狀態下的SOCKET可能會由於超時未收到ACK報文，而重發FIN報文，因此這個TIME_WAIT狀態的做用就是用來重發可能丟失的ACK報文。

7.SYN攻擊原理

在三次握手過程當中，Server發送SYN-ACK以後，收到Client的ACK以前的TCP鏈接稱爲半鏈接（half-open connect），此時Server處於SYN_RCVD狀態，當收到ACK後，Server轉入ESTABLISHED狀態。

SYN攻擊就是Client在短期內僞造大量不存在的IP地址，並向Server不斷地發送SYN包，Server回覆確認包，並等待Client的確認，因爲源地址是不存在的，所以，Server須要不斷重發直至超時，這些僞造的SYN包將長時間佔用未鏈接隊列，致使正常的SYN請求由於隊列滿而被丟棄，從而引發網絡堵塞甚至系統癱瘓。

SYN攻擊時一種典型的DDOS攻擊，檢測SYN攻擊的方式很是簡單，即當Server上有大量半鏈接狀態且源IP地址是隨機的，則能夠判定遭到SYN攻擊了，使用以下命令能夠能夠查看SYN_RECV狀態：

# netstat -nap | grep SYN_RECV

關於建鏈接時SYN超時：試想一下，若是server端接到了clien發的SYN後回了SYN-ACK後client掉線了，server端沒有收到client回來的ACK，那麼，這個鏈接處於一箇中間狀態，即沒成功，也沒失敗。因而，server端若是在必定時間內沒有收到的TCP會重發SYN-ACK。在Linux下，默認重試次數爲5次，重試的間隔時間從1s開始每次都翻售，5次的重試時間間隔爲1s, 2s, 4s, 8s, 16s，總共31s，第5次發出後還要等32s都知道第5次也超時了，因此，總共須要 1s + 2s + 4s+ 8s+ 16s + 32s = 2^6 -1 = 63s，TCP纔會把斷開這個鏈接。

關於SYN Flood攻擊：一些惡意的人就爲此製造了SYN Flood攻擊——給服務器發了一個SYN後，就下線了，因而服務器須要默認等63s纔會斷開鏈接，這樣，攻擊者就能夠把服務器的syn鏈接的隊列耗盡，讓正常的鏈接請求不能處理。因而，Linux下給了一個叫tcp_syncookies的參數來應對這個事——當SYN隊列滿了後，TCP會經過源地址端口、目標地址端口和時間戳打造出一個特別的Sequence Number發回去（又叫cookie），若是是攻擊者則不會有響應，若是是正常鏈接，則會把這個 SYN Cookie發回來，而後服務端能夠經過cookie建鏈接（即便你不在SYN隊列中）。請注意，請先千萬別用tcp_syncookies來處理正常的大負載的鏈接的狀況。由於，synccookies是妥協版的TCP協議，並不嚴謹。對於正常的請求，你應該調整三個TCP參數可供你選擇，第一個是：tcp_synack_retries 能夠用他來減小重試次數；第二個是：tcp_max_syn_backlog，能夠增大SYN鏈接數；第三個是：tcp_abort_on_overflow 處理不過來乾脆就直接拒絕鏈接了。

參考文檔

http://blog.csdn.net/hulifangjiayou/article/details/47283387
http://blog.csdn.net/yanxi252515237/article/details/51955675

《TCP那些事兒》雲頭條做者 陳皓