理論經典：TCP協議的3次握手與4次揮手過程詳解
一、前言
儘管TCP和UDP都使用相同的網絡層（IP），TCP卻嚮應用層提供與UDP徹底不一樣的服務。TCP提供一種面向鏈接的、可靠的字節流服務。php
面向鏈接意味着兩個使用TCP的應用（一般是一個客戶和一個服務器）在彼此交換數據以前必須先創建一個TCP鏈接。這一過程與打電話很類似，先撥號振鈴，等待對方摘機說「喂」，而後才說明是誰。html
本文將分別講解經典的TCP協議創建鏈接（所謂的「3次握手」）和斷開鏈接（所謂的「4次揮手」）的過程。有關TCP協議的權威理論介紹，請參見《TCP/IP詳解》這本書。（本文同步發佈於：http://www.52im.net/thread-258-1-1.html）android
二、學習交流
- 即時通信開發交流羣：215891622 [推薦]面試
- 移動端IM開發推薦文章：《新手入門一篇就夠：從零開發移動端IM》算法
三、相關資料
《技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）》編程
《TCP/IP詳解-第18章·TCP鏈接的創建與終止》服務器
《通俗易懂-深刻理解TCP協議（下）：RTT、滑動窗口、擁塞處理》
四、先來認識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攻擊了，使用以下命令可讓之現行：
#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] 網絡編程基礎資料：
《NAT詳解：基本原理、穿越技術(P2P打洞)、端口老化等》
《Java新一代網絡編程模型AIO原理及Linux系統AIO介紹》
《NIO框架入門(三)：iOS與MINA二、Netty4的跨平臺UDP雙向通訊實戰》
《NIO框架入門(四)：Android與MINA二、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架構設計：
[6] 有關IM安全的文章：
《即時通信安全篇（一）：正確地理解和使用Android端加密算法》
《即時通信安全篇（四）：實例分析Android中密鑰硬編碼的風險》
《傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示》
《理論聯繫實際：一套典型的IM通訊協議設計詳解（含安全層設計）》
《微信新一代通訊安全解決方案：基於TLS1.3的MMTLS詳解》
《來自阿里OpenIM：打造安全可靠即時通信服務的技術實踐分享》
[7] 有關實時音視頻開發：
《即時通信音視頻開發（五）：認識主流視頻編碼技術H.264》
《即時通信音視頻開發（九）：實時語音通信的迴音及迴音消除�概述》
《即時通信音視頻開發（十）：實時語音通信的迴音消除�技術詳解》
《即時通信音視頻開發（十一）：實時語音通信丟包補償技術詳解》
《即時通信音視頻開發（十三）：實時視頻編碼H.264的特色與優點》
《即時通信音視頻開發（十五）：聊聊P2P與實時音視頻的應用狀況》
《即時通信音視頻開發（十六）：移動端實時音視頻開發的幾個建議》
《即時通信音視頻開發（十七）：視頻編碼H.26四、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)研究（來自微信）》
《爲什麼微信、QQ這樣的IM工具不使用GCM服務推送消息？》
[11] 更多即時通信技術好文分類：
做者：JackJiang2011
連接：https://www.jianshu.com/p/a1ebc61ce141
來源：簡書
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。
最近在複習計算機網絡，看到TCP這一章，總結一下。
創建TCP須要三次握手才能創建，而斷開鏈接則須要四次握手。整個過程以下圖所示：
先來看看如何創建鏈接的：
首先Client端發送鏈接請求報文，Server段接受鏈接後回覆ACK報文，併爲此次鏈接分配資源。Client端接收到ACK報文後也向Server段發送報文，並分配資源，這樣TCP鏈接就創建了。
如何斷開鏈接呢？簡單的過程以下：
注意中斷鏈接端能夠是Client端，也能夠是Server端
假設Client端發起中斷請求，也就是發送FIN報文。Server端接到FIN報文後，意思是說「我client端要發給你了」，可是若是你尚未數據要發送完成，則沒必要急着關閉Socket，能夠繼續發送數據。因此因此你先發送ACK，"告訴Client端，你的請求我收到了，可是我還沒準備好，請繼續你等個人消息"。這個時候Client端就進入FIN_WAIT狀態，繼續等待Server端的FIN報文。當Server端肯定數據已發送完成，則向Client端發送FIN報文，"告訴Client端，好了，我這邊數據發完了，準備好關閉鏈接了"。Client端收到FIN報文後，"就知道能夠關閉鏈接了，可是他仍是不相信網絡，怕Server端不知道要關閉，因此發送ACK後進入TIME_WAIT狀態，若是Server端沒有收到ACK則能夠重傳。「，Server端收到ACK後，"就知道能夠斷開鏈接了"。Client端等待了2MSL後依然沒有收到回覆，則證實Server端已正常關閉，那好，我Client端也能夠關閉鏈接了。Ok，TCP鏈接就這樣關閉了！
整個過程Client端所經歷的狀態以下：
而Server端所經歷的過程以下：
注意在TIME_WAIT狀態中，若是TCP client端最後一次發送的ACK丟失了，它將從新發送。TIME_WAIT狀態中所須要的時間是依賴於實現方法的。典型的值爲30秒、1分鐘和2分鐘。等待以後鏈接正式關閉，而且全部的資源(包括端口號)都被釋放。
-
爲何鏈接的時候是三次握手，關閉的時候倒是四次握手？
由於當Server端收到Client端的SYN鏈接請求報文後，能夠直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。可是關閉鏈接時，當Server端收到FIN報文時，極可能並不會當即關閉SOCKET，因此只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端全部的報文都發送完了，我才能發送FIN報文，所以不能一塊兒發送。故須要四步握手。
-
爲何TIME_WAIT狀態須要通過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？
- 爲了保證發送的最後一個ACK報文段可以到達B
- 防止「已失效的鏈接請求報文段」出如今本鏈接中。在發送完最後一個ACK報文段後，再通過實踐2MSL，就可使本鏈接持續的時間內所產生的全部報文段，都從網絡中消失。這樣就可使下一個新的鏈接中不會出現這種就得鏈接請求報文段。
TCP有限狀態機
TCP有限狀態機以下圖：
- 粗實箭頭表示客戶進程的正常遷移
- 粗虛線箭頭表示對服務器進程的正常遷移
- 細線箭頭表示異常變遷
做者：小球why
連接：https://www.jianshu.com/p/9968b16b607e
來源：簡書
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。
- 1. TCP協議的3次握手與4次揮手詳解
- 2. 理論經典：TCP協議的3次握手與4次揮手過程詳解
- 3. TCP協議的3次握手和4次揮手過程詳解
- 4. TCP協議的3次握手與4次揮手
- 5. Tcp協議中的3次握手與4次揮手過程分析
- 6. tcp的3次握手 4次揮手
- 7. java網絡編程基礎詳解三之TCP協議的3次握手與4次揮手過程詳解
- 8. 9.TCP協議3次握手4次揮手.docx
- 9. TCP 3次握手及4次揮手
- 10. TCP協議「三次握手」與「四次揮手」詳解（下）
- 更多相關文章...
- • TCP三次握手建立連接的過程 - TCP/IP教程
- • TCP四次揮手斷開連接的過程 - TCP/IP教程
- • 爲了進字節跳動，我精選了29道Java經典算法題，帶詳細講解
- • Flink 數據傳輸及反壓詳解
-
每一个你不满意的现在，都有一个你没有努力的曾经。