理論經典：TCP協議的3次握手與4次揮手過程詳解
1、前言
儘管TCP和UDP都使用相同的網路層（IP），TCP卻嚮應用層提供與UDP完全不同的服務。TCP提供一種面向連線的、可靠的位元組流服務。
面向連線意味著兩個使用TCP的應用（通常是一個客戶和一個伺服器）在彼此交換資料之前必須先建立一個TCP連線。這一過程與打電話很相似，先撥號振鈴，等待對方摘機說“喂”，然後才說明是誰。
本文將分別講解經典的TCP協議建立連線（所謂的“3次握手”）和斷開連線（所謂的“4次揮手”）的過程。有關TCP協議的權威理論介紹，請參見《TCP/IP詳解》這本書。（本文同步釋出於：http://www.52im.net/thread-258-1-1.html）
2、學習交流
– 即時通訊開發交流群：215891622 [推薦]
– 移動端IM開發推薦文章：《新手入門一篇就夠：從零開發移動端IM》
3、相關資料
《技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）》
《通俗易懂-深入理解TCP協議（下）：RTT、滑動視窗、擁塞處理》
4、先來認識TCP報文格式
TCP/IP協議的詳細資訊參看《TCP/IP 協議詳解》中有關TCP格式的章節（點此檢視《TCP/IP詳解 線上版》）。
下面是TCP報文格式圖：
上圖中有幾個欄位需要重點介紹下：
（1）序號：Seq序號，佔32位，用來標識從TCP源端向目的端傳送的位元組流，發起方傳送資料時對此進行標記。
（2）確認序號：Ack序號，佔32位，只有ACK標誌位為1時，確認序號欄位才有效，Ack=Seq+1。
（3）標誌位：共6個，即URG、ACK、PSH、RST、SYN、FIN等，具體含義如下：
（A）URG：緊急指標（urgent pointer）有效。
（B）ACK：確認序號有效。
（C）PSH：接收方應該儘快將這個報文交給應用層。
（D）RST：重置連線。
（E）SYN：發起一個新連線。
（F）FIN：釋放一個連線。
需要注意的是：
（A）不要將確認序號Ack與標誌位中的ACK搞混了。
（B）確認方Ack=發起方Req+1，兩端配對。
5、3次握手過程詳解
所謂三次握手（Three-Way Handshake）即建立TCP連線，就是指建立一個TCP連線時，需要客戶端和服務端總共傳送3個包以確認連線的建立。在socket程式設計中，這一過程由客戶端執行connect來觸發，整個流程如下圖所示：
（1）第一次握手：
Client將標誌位SYN置為1，隨機產生一個值seq=J，並將該資料包傳送給Server，Client進入SYN_SENT狀態，等待Server確認。
（2）第二次握手：
Server收到資料包後由標誌位SYN=1知道Client請求建立連線，Server將標誌位SYN和ACK都置為1，ack=J+1，隨機產生一個值seq=K，並將該資料包傳送給Client以確認連線請求，Server進入SYN_RCVD狀態。
（3）第三次握手：
Client收到確認後，檢查ack是否為J+1，ACK是否為1，如果正確則將標誌位ACK置為1，ack=K+1，並將該資料包傳送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連線建立成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間可以開始傳輸資料了。
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攻擊了，使用如下命令可以讓之現行：
#netstat -nap | grep SYN_RECV
6、4次揮手過程詳解
三次握手耳熟能詳，四次揮手估計就少有人知道了。所謂四次揮手（Four-Way Wavehand）即終止TCP連線，就是指斷開一個TCP連線時，需要客戶端和服務端總共傳送4個包以確認連線的斷開。在socket程式設計中，這一過程由客戶端或服務端任一方執行close來觸發，整個流程如下圖所示：
由於TCP連線時全雙工的，因此，每個方向都必須要單獨進行關閉，這一原則是當一方完成資料傳送任務後，傳送一個FIN來終止這一方向的連線，收到一個FIN只是意味著這一方向上沒有資料流動了，即不會再收到資料了，但是在這個TCP連線上仍然能夠傳送資料，直到這一方向也傳送了FIN。首先進行關閉的一方將執行主動關閉，而另一方則執行被動關閉，上圖描述的即是如此。
第一次揮手：
Client傳送一個FIN，用來關閉Client到Server的資料傳送，Client進入FIN_WAIT_1狀態。
第二次揮手：
Server收到FIN後，傳送一個ACK給Client，確認序號為收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。
第三次揮手：
Server傳送一個FIN，用來關閉Server到Client的資料傳送，Server進入LAST_ACK狀態。
第四次揮手：
Client收到FIN後，Client進入TIME_WAIT狀態，接著傳送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態，完成四次揮手。
上面是一方主動關閉，另一方被動關閉的情況，實際中還會出現同時發起主動關閉的情況，具體流程如下圖：
流程和狀態在上圖中已經很明瞭了，在此不再贅述，可以參考前面的四次揮手解析步驟。
結語
關於三次握手與四次揮手通常都會有典型的面試題，在此提出供有需求的XDJM們參考：
(1) 三次握手是什麼或者流程？四次握手呢？答案前面分析就是。
(2) 為什麼建立連線是三次握手，而關閉連線卻是四次揮手呢？
這是因為服務端在LISTEN狀態下，收到建立連線請求的SYN報文後，把ACK和SYN放在一個報文裡傳送給客戶端。而關閉連線時，當收到對方的FIN報文時，僅僅表示對方不再傳送資料了但是還能接收資料，己方也未必全部資料都傳送給對方了，所以己方可以立即close，也可以傳送一些資料給對方後，再傳送FIN報文給對方來表示同意現在關閉連線，因此，己方ACK和FIN一般都會分開傳送。
（本文同步釋出於：http://www.52im.net/thread-258-1-1.html）
附錄：更多IM技術文章
[1] 網路程式設計基礎資料：
《Java新一代網路程式設計模型AIO原理及Linux系統AIO介紹》
《NIO框架入門(三)：iOS與MINA2、Netty4的跨平臺UDP雙向通訊實戰》
《NIO框架入門(四)：Android與MINA2、Netty4的跨平臺UDP雙向通訊實戰》
[2] 有關IM/推送的通訊格式、協議的選擇：
《強列建議將Protobuf作為你的即時通訊應用資料傳輸格式》
[3] 有關IM/推送的心跳保活處理：
《Android端訊息推送總結：實現原理、心跳保活、遇到的問題等》
《微信團隊原創分享：Android版微信後臺保活實戰分享(程式保活篇)》
《微信團隊原創分享：Android版微信後臺保活實戰分享(網路保活篇)》
《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》
[4] 有關WEB端即時通訊開發：
《Web端即時通訊技術盤點：短輪詢、Comet、Websocket、SSE》
《Comet技術詳解：基於HTTP長連線的Web端實時通訊技術》
《WebSocket詳解（一）：初步認識WebSocket技術》
[5] 有關IM架構設計：
《騰訊QQ1.4億線上使用者的技術挑戰和架構演進之路PPT》
[6] 有關IM安全的文章：
《即時通訊安全篇（一）：正確地理解和使用Android端加密演算法》
《即時通訊安全篇（四）：例項分析Android中金鑰硬編碼的風險》
《傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示》
《理論聯絡實際：一套典型的IM通訊協議設計詳解（含安全層設計）》
《微信新一代通訊安全解決方案：基於TLS1.3的MMTLS詳解》
《來自阿里OpenIM：打造安全可靠即時通訊服務的技術實踐分享》
[7] 有關實時音視訊開發：
《即時通訊音視訊開發（五）：認識主流視訊編碼技術H.264》
《即時通訊音視訊開發（九）：實時語音通訊的迴音及迴音消除�概述》
《即時通訊音視訊開發（十）：實時語音通訊的迴音消除�技術詳解》
《即時通訊音視訊開發（十一）：實時語音通訊丟包補償技術詳解》
《即時通訊音視訊開發（十三）：實時視訊編碼H.264的特點與優勢》
《即時通訊音視訊開發（十五）：聊聊P2P與實時音視訊的應用情況》
《即時通訊音視訊開發（十六）：移動端實時音視訊開發的幾個建議》
《即時通訊音視訊開發（十七）：視訊編碼H.264、V8的前世今生》
[8] IM開發綜合文章：
《開源IM工程“蘑菇街TeamTalk”的現狀：一場有始無終的開源秀》
[9] 開源移動端IM技術框架資料：
《開源移動端IM技術框架MobileIMSDK：常見問題解答》
《開源移動端IM技術框架MobileIMSDK：壓力測試報告》
《開源移動端IM技術框架MobileIMSDK：Android版Demo使用幫助》
《開源移動端IM技術框架MobileIMSDK：Java版Demo使用幫助》
《開源移動端IM技術框架MobileIMSDK：iOS版Demo使用幫助》
《開源移動端IM技術框架MobileIMSDK：Android客戶端開發指南》
《開源移動端IM技術框架MobileIMSDK：Java客戶端開發指南》
《開源移動端IM技術框架MobileIMSDK：iOS客戶端開發指南》
《開源移動端IM技術框架MobileIMSDK：Server端開發指南》
[10] 有關推送技術的文章：
《iOS的推送服務APNs詳解：設計思路、技術原理及缺陷等》
《Android端訊息推送總結：實現原理、心跳保活、遇到的問題等》
《一個基於MQTT通訊協議的完整Android推送Demo》
《求教android訊息推送：GCM、XMPP、MQTT三種方案的優劣》
《掃盲貼：淺談iOS和Android後臺實時訊息推送的原理和區別》
《移動端IM實踐：谷歌訊息推送服務(GCM)研究（來自微信）》
[11] 更多即時通訊技術好文分類：
作者：Jack Jiang(點選作者姓名進入Github)
出處：http://www.52im.net/space-uid-1.html
交流：�歡迎加入即時通訊開發交流群215891622
Jack Jiang同時是【原創Java Swing外觀工程BeautyEye】和【輕量級移動端即時通訊框架MobileIMSDK】的作者，可前往下載交流。
相關文章
- TCP協議的3次握手與4次揮手過程詳解TCP協議
- TCP協議的三次握手與四次揮手過程圖解TCP協議圖解
- 探究 tcp 協議中的三次握手與四次揮手TCP協議
- TCP協議的三次握手和四次揮手TCP協議
- TCP的三次握手與四次揮手詳解TCP
- TCP協議中的三次握手和四次揮手(圖解)TCP協議圖解
- TCP/IP的三次握手與四次揮手詳解TCP
- 理解TCP/IP協議三次握手四次揮手TCP協議
- 【轉】TCP協議三次握手過程分析TCP協議
- TCP協議三次握手過程分析【轉】TCP協議
- tcp三次握手、四次揮手過程解析TCP
- HTTPS協議詳解(四)：TLS/SSL握手過程HTTP協議TLS
- 談談TCP協議的三次握手和四次揮手TCP協議
- TCP協議特點和三次握手／四次揮手TCP協議
- 【網路】TCP協議中三次握手和四次揮手TCP協議
- 網路協議 - TCP/IP 三次握手和四次揮手協議TCP
- 詳解TCP一：三次握手、四次揮手TCP
- 面試必問之 TCP/IP協議的三次握手 四次揮手面試TCP協議
- TCP三次握手、四次揮手概念圖詳解TCP
- TCP協議三次握手、四次揮手以及TCP視窗滑動機制TCP協議
- TCP的三次握手與四次揮手TCP
- TCP的四次揮手過程TCP
- 正本清源：TCP協議之三次握手和四次揮手TCP協議
- TCP 三次握手 與 四次揮手TCP
- TCP三次握手與四次揮手TCP
- TCP 3次握手 4次揮手TCP
- TCP協議詳解TCP協議
- HTTP協議三次握手和四次揮手HTTP協議
- HTTP協議詳解（真的很經典）HTTP協議
- TCP的三次握手，四次揮手及常見面試題詳解TCP面試題
- 注意！是TCP不是HTTP的3次握手與4次揮手（#...#）TCPHTTP
- TCP/IP協議詳解TCP協議
- 圖解TCP的三次握手和四次揮手圖解TCP
- 一看就懂的TCP握手和揮手TCP
- TCP的三次握手四次揮手TCP
- TCP三次握手四次揮手TCP
- 複述 tcp 3次握手 4次揮手TCP
- TCP三次握手&四次揮手TCP