理論經典：TCP協議的3次握手與4次揮手過程詳解

一、前言 
儘管TCP和UDP都使用相同的網絡層（IP），TCP卻嚮應用層提供與UDP徹底不一樣的服務。TCP提供一種面向鏈接的、可靠的字節流服務。 

面向鏈接意味着兩個使用TCP的應用（一般是一個客戶和一個服務器）在彼此交換數據以前必須先創建一個TCP鏈接。這一過程與打電話很類似，先撥號振鈴，等待對方摘機說「喂」，而後才說明是誰。 

本文將分別講解經典的TCP協議創建鏈接（所謂的「3次握手」）和斷開鏈接（所謂的「4次揮手」）的過程。有關TCP協議的權威理論介紹，請參見《TCP/IP詳解》這本書。（本文同步發佈於：http://www.52im.net/thread-258-1-1.html） 

二、學習交流 
- 即時通信開發交流羣： 215891622 [推薦] 

- 移動端IM開發推薦文章：《新手入門一篇就夠：從零開發移動端IM》 

三、相關資料 
《技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）》 
《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》 
《TCP/IP詳解 - 第18章·TCP鏈接的創建與終止》 
《TCP/IP詳解 - 第21章·TCP的超時與重傳》 
《通俗易懂-深刻理解TCP協議（上）：理論基礎》 
《通俗易懂-深刻理解TCP協議（下）：RTT、滑動窗口、擁塞處理》 
《理論經典：TCP協議的3次握手與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，兩端配對。 

五、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攻擊了，使用以下命令可讓之現行： 

1 
#netstat -nap | grep SYN_RECV 
六、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] 網絡編程基礎資料： 
《TCP/IP詳解 卷1：協議（http://www.52im.net/topic-tcpipvol1.html）》：第11章·UDP：用戶數據報協議（http://docs.52im.net/extend/docs/book/tcpip/vol1/11/）、第17章·TCP：傳輸控制協議（http://docs.52im.net/extend/docs/book/tcpip/vol1/17/）、第18章·TCP鏈接的創建與終止（http://docs.52im.net/extend/docs/book/tcpip/vol1/18/）、第21章·TCP的超時與重傳（http://docs.52im.net/extend/docs/book/tcpip/vol1/21/） 
《[通俗易懂]深刻理解TCP協議（上）：理論基礎》http://www.52im.net/thread-513-1-1.html 
《[通俗易懂]深刻理解TCP協議（下）：RTT、滑動窗口、擁塞處理》http://www.52im.net/thread-515-1-1.html 
《理論經典：TCP協議的3次握手與4次揮手過程詳解》http://www.52im.net/thread-258-1-1.html 
《理論聯繫實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》http://www.52im.net/thread-275-1-1.html 
《計算機網絡通信協議關係圖（中文珍藏版）》http://www.52im.net/thread-180-1-1.html 
《NAT詳解：基本原理、穿越技術(P2P打洞)、端口老化等》http://www.52im.net/thread-50-1-1.html 
《UDP中一個包的大小最大能多大？》http://www.52im.net/thread-29-1-1.html 
《Java新一代網絡編程模型AIO原理及Linux系統AIO介紹》http://www.52im.net/thread-306-1-1.html 
《NIO框架入門(三)：iOS與MINA二、Netty4的跨平臺UDP雙向通訊實戰》http://www.52im.net/thread-378-1-1.html 
《NIO框架入門(四)：Android與MINA二、Netty4的跨平臺UDP雙向通訊實戰》http://www.52im.net/thread-388-1-1.html 
>> 更多同類文章 …（http://www.52im.net/forum.php?mod=collection&action=view&ctid=9、http://www.52im.net/forum.php?mod=collection&action=view&ctid=8） 

[2] 有關IM/推送的通訊格式、協議的選擇： 
《爲何QQ用的是UDP協議而不是TCP協議？》http://www.52im.net/thread-279-1-1.html 
《移動端即時通信協議選擇：UDP仍是TCP？》http://www.52im.net/thread-33-1-1.html 
《如何選擇即時通信應用的數據傳輸格式》http://www.52im.net/thread-276-1-1.html 
《強列建議將Protobuf做爲你的即時通信應用數據傳輸格式》http://www.52im.net/thread-277-1-1.html 
《移動端IM開發須要面對的技術問題（含通訊協議選擇）》http://www.52im.net/thread-133-1-1.html 
《簡述移動端IM開發的那些坑：架構設計、通訊協議和客戶端》http://www.52im.net/thread-289-1-1.html 
《理論聯繫實際：一套典型的IM通訊協議設計詳解》http://www.52im.net/thread-283-1-1.html 
《58到家實時消息系統的協議設計等技術實踐分享》http://www.52im.net/thread-298-1-1.html 
>> 更多同類文章 … http://www.52im.net/forum.php?mod=collection&action=view&ctid=18

[3] 有關IM/推送的心跳保活處理： 
《Android進程保活詳解：一篇文章解決你的全部疑問》http://www.52im.net/thread-438-1-1.html 
《Android端消息推送總結：實現原理、心跳保活、遇到的問題等》http://www.52im.net/thread-341-1-1.html 
《爲什麼基於TCP協議的移動端IM仍然須要心跳保活機制？》http://www.52im.net/thread-281-1-1.html 
《微信團隊原創分享：Android版微信後臺保活實戰分享(進程保活篇)》http://www.52im.net/thread-210-1-1.html 
《微信團隊原創分享：Android版微信後臺保活實戰分享(網絡保活篇)》http://www.52im.net/thread-209-1-1.html 
《移動端IM實踐：實現Android版微信的智能心跳機制》http://www.52im.net/thread-120-1-1.html 
《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》http://www.52im.net/thread-121-1-1.html 
>> 更多同類文章 … http://www.52im.net/forum.php?mod=collection&action=view&ctid=17

[4] 有關WEB端即時通信開發： 
《新手入門貼：史上最全Web端即時通信技術原理詳解》http://www.52im.net/thread-338-1-1.html 
《Web端即時通信技術盤點：短輪詢、Comet、Websocket、SSE》http://www.52im.net/thread-336-1-1.html 
《SSE技術詳解：一種全新的HTML5服務器推送事件技術》http://www.52im.net/thread-335-1-1.html 
《Comet技術詳解：基於HTTP長鏈接的Web端實時通訊技術》http://www.52im.net/thread-334-1-1.html 
《WebSocket詳解（一）：初步認識WebSocket技術》http://www.52im.net/thread-331-1-1.html 
《socket.io實現消息推送的一點實踐及思路》http://www.52im.net/thread-188-1-1.html 
>> 更多同類文章 … http://www.52im.net/forum.php?mod=collection&action=view&ctid=15

[5] 有關IM架構設計： 
《淺談IM系統的架構設計》http://www.52im.net/thread-307-1-1.html 
《簡述移動端IM開發的那些坑：架構設計、通訊協議和客戶端》http://www.52im.net/thread-289-1-1.html 
《一套原創分佈式即時通信(IM)系統理論架構方案》http://www.52im.net/thread-151-1-1.html 
《從零到卓越：京東客服即時通信系統的技術架構演進歷程》http://www.52im.net/thread-152-1-1.html 
《蘑菇街即時通信/IM服務器開發之架構選擇》http://www.52im.net/thread-31-1-1.html 
《騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT》http://www.52im.net/thread-158-1-1.html 
《微信技術總監談架構：微信之道——大道至簡(演講全文)》http://www.52im.net/thread-200-1-1.html 
《如何解讀《微信技術總監談架構：微信之道——大道至簡》》http://www.52im.net/thread-201-1-1.html 
《快速裂變：見證微信強大後臺架構從0到1的演進歷程（一）》http://www.52im.net/thread-168-1-1.html 
《17年的實踐：騰訊海量產品的技術方法論》http://www.52im.net/thread-159-1-1.html 
>> 更多同類文章 … http://www.52im.net/forum.php?mod=collection&action=view&ctid=7 

[6] 有關IM安全的文章： 
《即時通信安全篇（一）：正確地理解和使用Android端加密算法》http://www.52im.net/thread-216-1-1.html 
《即時通信安全篇（二）：探討組合加密算法在IM中的應用》http://www.52im.net/thread-217-1-1.html 
《即時通信安全篇（三）：經常使用加解密算法與通信安全講解》http://www.52im.net/thread-219-1-1.html 
《即時通信安全篇（四）：實例分析Android中密鑰硬編碼的風險》http://www.52im.net/thread-312-1-1.html 
《傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示》http://www.52im.net/thread-327-1-1.html 
《理論聯繫實際：一套典型的IM通訊協議設計詳解（含安全層設計）》http://www.52im.net/thread-283-1-1.html 
《微信新一代通訊安全解決方案：基於TLS1.3的MMTLS詳解》http://www.52im.net/thread-310-1-1.html 
《來自阿里OpenIM：打造安全可靠即時通信服務的技術實踐分享》http://www.52im.net/thread-215-1-1.html 
>> 更多同類文章 … http://www.52im.net/forum.php?mod=collection&action=view&ctid=6 

[7] 有關實時音視頻開發： 
《即時通信音視頻開發（一）：視頻編解碼之理論概述》http://www.52im.net/thread-228-1-1.html 
《即時通信音視頻開發（二）：視頻編解碼之數字視頻介紹》http://www.52im.net/thread-229-1-1.html 
《即時通信音視頻開發（三）：視頻編解碼之編碼基礎》http://www.52im.net/thread-232-1-1.html 
《即時通信音視頻開發（四）：視頻編解碼之預測技術介紹》http://www.52im.net/thread-235-1-1.html 
《即時通信音視頻開發（五）：認識主流視頻編碼技術H.264》http://www.52im.net/thread-237-1-1.html 
《即時通信音視頻開發（六）：如何開始音頻編解碼技術的學習》http://www.52im.net/thread-241-1-1.html 
《即時通信音視頻開發（七）：音頻基礎及編碼原理入門》http://www.52im.net/thread-242-1-1.html 
《即時通信音視頻開發（八）：常見的實時語音通信編碼標準》http://www.52im.net/thread-243-1-1.html 
《即時通信音視頻開發（九）：實時語音通信的迴音及迴音消除概述》http://www.52im.net/thread-247-1-1.html 
《即時通信音視頻開發（十）：實時語音通信的迴音消除技術詳解》http://www.52im.net/thread-250-1-1.html 
《即時通信音視頻開發（十一）：實時語音通信丟包補償技術詳解》http://www.52im.net/thread-251-1-1.html 
《即時通信音視頻開發（十二）：多人實時音視頻聊天架構探討》http://www.52im.net/thread-253-1-1.html 
《即時通信音視頻開發（十三）：實時視頻編碼H.264的特色與優點》http://www.52im.net/thread-266-1-1.html 
《即時通信音視頻開發（十四）：實時音視頻數據傳輸協議介紹》http://www.52im.net/thread-267-1-1.html 
《即時通信音視頻開發（十五）：聊聊P2P與實時音視頻的應用狀況》http://www.52im.net/thread-269-1-1.html 
《即時通信音視頻開發（十六）：移動端實時音視頻開發的幾個建議》http://www.52im.net/thread-270-1-1.html 
《即時通信音視頻開發（十七）：視頻編碼H.26四、V8的前世此生》http://www.52im.net/thread-274-1-1.html 
《簡述開源實時音視頻技術WebRTC的優缺點》http://www.52im.net/thread-225-1-1.html 
《良心分享：WebRTC 零基礎開發者教程（中文）》http://www.52im.net/thread-265-1-1.html 
>> 更多同類文章 … http://www.52im.net/forum.php?mod=collection&action=view&ctid=4、http://www.52im.net/forum.php?mod=collection&action=view&ctid=5 

[8] IM開發綜合文章： 
《移動端IM開發須要面對的技術問題》http://www.52im.net/thread-133-1-1.html 
《開發IM是本身設計協議用字節流好仍是字符流好？》http://www.52im.net/thread-150-1-1.html 
《請問有人知道語音留言聊天的主流實現方式嗎？》http://www.52im.net/thread-175-1-1.html 
《IM系統中如何保證消息的可靠投遞（即QoS機制）》http://www.52im.net/thread-294-1-1.html 
《談談移動端 IM 開發中登陸請求的優化》http://www.52im.net/thread-282-1-1.html 
《徹底自已開發的IM該如何設計「失敗重試」機制？》http://www.52im.net/thread-280-1-1.html 
《微信對網絡影響的技術試驗及分析（論文全文）》http://www.52im.net/thread-195-1-1.html 
《即時通信系統的原理、技術和應用（技術論文）》http://www.52im.net/thread-218-1-1.html 
《開源IM工程「蘑菇街TeamTalk」的現狀：一場虎頭蛇尾的開源秀》http://www.52im.net/thread-447-1-1.html 
>> 更多同類文章 … http://www.52im.net/forum.php?mod=collection&action=view&ctid=10

[9] 開源移動端IM技術框架資料： 
《即時通信技術MobileIMSDK：快速入門》http://www.52im.net/thread-52-1-1.html 
《即時通信技術MobileIMSDK：常見問題解答》http://www.52im.net/thread-60-1-1.html 
《即時通信技術MobileIMSDK：壓力測試報告》http://www.52im.net/thread-57-1-1.html 
>> 更多同類文章 … http://www.52im.net/forum.php?mod=collection&action=view&ctid=1 

[x] 有關推送技術的文章： 
《iOS的推送服務APNs詳解：設計思路、技術原理及缺陷等》http://www.52im.net/thread-345-1-1.html 
《Android端消息推送總結：實現原理、心跳保活、遇到的問題等》http://www.52im.net/thread-341-1-1.html 
《掃盲貼：認識MQTT通訊協議》http://www.52im.net/thread-318-1-1.html 
《一個基於MQTT通訊協議的完整Android推送Demo》http://www.52im.net/thread-315-1-1.html 
《求教android消息推送：GCM、XMPP、MQTT三種方案的優劣》http://www.52im.net/thread-314-1-1.html 
《IBM技術經理訪談：MQTT協議的制定歷程、發展示狀等》url=http://www.52im.net/thread-525-1-1.html 
《移動端實時消息推送技術淺析》http://www.52im.net/thread-288-1-1.html 
《掃盲貼：淺談iOS和Android後臺實時消息推送的原理和區別》http://www.52im.net/thread-286-1-1.html 
《絕對乾貨：基於Netty實現海量接入的推送服務技術要點》http://www.52im.net/thread-166-1-1.html 
《移動端IM實踐：谷歌消息推送服務(GCM)研究（來自微信）》http://www.52im.net/thread-122-1-1.html 
《爲什麼微信、QQ這樣的IM工具不使用GCM服務推送消息？》http://www.52im.net/thread-117-1-1.html 
>> 更多同類文章 … http://www.52im.net/forum.php?mod=collection&action=view&ctid=11

[y] 更多即時通信技術好文分類： 
http://www.52im.net/forum.php?mod=collection&op=all 

做者：Jack Jiang (點擊做者姓名進入Github) 
出處：http://www.52im.net/space-uid-1.html 
交流：歡迎加入即時通信開發交流羣 215891622 
討論：http://www.52im.net/ 
Jack Jiang同時是【原創Java Swing外觀工程BeautyEye】和【輕量級移動端即時通信框架MobileIMSDK】的做者，可前往下載交流。 
本博文 歡迎轉載，轉載請註明出處（也可前往 個人52im.net 找到我）。

 

https://www.douban.com/group/topic/91255779/