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/IP詳解 - 第17章·TCP:傳輸控制協議》
《TCP/IP詳解 - 第18章·TCP連接的建立與終止》
《TCP/IP詳解 - 第21章·TCP的超時與重傳》
《通俗易懂-深入理解TCP協議(上):理論基礎》
《通俗易懂-深入理解TCP協議(下):RTT、滑動窗口、擁塞處理》
《理論經典:TCP協議的3次握手與4次揮手過程詳解》
《計算機網絡通訊協議關係圖(中文珍藏版)》
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攻擊了,使用如下命令可以讓之現行:
1 |
|
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狀態,完成四次揮手。
上面是一方主動關閉,另一方被動關閉的情況,實際中還會出現同時發起主動關閉的情況,具體流程如下圖:
流程和狀態在上圖中已經很明瞭了,在此不再贅述,可以參考前面的四次揮手解析步驟。
7、結語
關於三次握手與四次揮手通常都會有典型的面試題,在此提出供有需求的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打洞)、端口老化等》
《UDP中一個包的大小最大能多大?》
《Java新一代網絡編程模型AIO原理及Linux系統AIO介紹》
《NIO框架入門(三):iOS與MINA2、Netty4的跨平臺UDP雙向通信實戰》
《NIO框架入門(四):Android與MINA2、Netty4的跨平臺UDP雙向通信實戰》
>> 更多同類文章 ……
[2] 有關IM/推送的通信格式、協議的選擇:
《爲什麼QQ用的是UDP協議而不是TCP協議?》
《移動端即時通訊協議選擇:UDP還是TCP?》
《如何選擇即時通訊應用的數據傳輸格式》
《強列建議將Protobuf作爲你的即時通訊應用數據傳輸格式》
《移動端IM開發需要面對的技術問題(含通信協議選擇)》
《簡述移動端IM開發的那些坑:架構設計、通信協議和客戶端》
《理論聯繫實際:一套典型的IM通信協議設計詳解》
《58到家實時消息系統的協議設計等技術實踐分享》
>> 更多同類文章 ……
[3] 有關IM/推送的心跳保活處理:
《Android進程保活詳解:一篇文章解決你的所有疑問》
《Android端消息推送總結:實現原理、心跳保活、遇到的問題等》
《爲何基於TCP協議的移動端IM仍然需要心跳保活機制?》
《微信團隊原創分享:Android版微信後臺保活實戰分享(進程保活篇)》
《微信團隊原創分享:Android版微信後臺保活實戰分享(網絡保活篇)》
《移動端IM實踐:實現Android版微信的智能心跳機制》
《移動端IM實踐:WhatsApp、Line、微信的心跳策略分析》
>> 更多同類文章 ……
[4] 有關WEB端即時通訊開發:
《新手入門貼:史上最全Web端即時通訊技術原理詳解》
《Web端即時通訊技術盤點:短輪詢、Comet、Websocket、SSE》
《SSE技術詳解:一種全新的HTML5服務器推送事件技術》
《Comet技術詳解:基於HTTP長連接的Web端實時通信技術》
《WebSocket詳解(一):初步認識WebSocket技術》
《socket.io實現消息推送的一點實踐及思路》
>> 更多同類文章 ……
[5] 有關IM架構設計:
《淺談IM系統的架構設計》
《簡述移動端IM開發的那些坑:架構設計、通信協議和客戶端》
《一套原創分佈式即時通訊(IM)系統理論架構方案》
《從零到卓越:京東客服即時通訊系統的技術架構演進歷程》
《蘑菇街即時通訊/IM服務器開發之架構選擇》
《騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT》
《微信技術總監談架構:微信之道——大道至簡(演講全文)》
《如何解讀《微信技術總監談架構:微信之道——大道至簡》》
《快速裂變:見證微信強大後臺架構從0到1的演進歷程(一)》
《17年的實踐:騰訊海量產品的技術方法論》
>> 更多同類文章 ……
[6] 有關IM安全的文章:
《即時通訊安全篇(一):正確地理解和使用Android端加密算法》
《即時通訊安全篇(二):探討組合加密算法在IM中的應用》
《即時通訊安全篇(三):常用加解密算法與通訊安全講解》
《即時通訊安全篇(四):實例分析Android中密鑰硬編碼的風險》
《傳輸層安全協議SSL/TLS的Java平臺實現簡介和Demo演示》
《理論聯繫實際:一套典型的IM通信協議設計詳解(含安全層設計)》
《微信新一代通信安全解決方案:基於TLS1.3的MMTLS詳解》
《來自阿里OpenIM:打造安全可靠即時通訊服務的技術實踐分享》
>> 更多同類文章 ……
[7] 有關實時音視頻開發:
《即時通訊音視頻開發(一):視頻編解碼之理論概述》
《即時通訊音視頻開發(二):視頻編解碼之數字視頻介紹》
《即時通訊音視頻開發(三):視頻編解碼之編碼基礎》
《即時通訊音視頻開發(四):視頻編解碼之預測技術介紹》
《即時通訊音視頻開發(五):認識主流視頻編碼技術H.264》
《即時通訊音視頻開發(六):如何開始音頻編解碼技術的學習》
《即時通訊音視頻開發(七):音頻基礎及編碼原理入門》
《即時通訊音視頻開發(八):常見的實時語音通訊編碼標準》
《即時通訊音視頻開發(九):實時語音通訊的迴音及迴音消除概述》
《即時通訊音視頻開發(十):實時語音通訊的迴音消除技術詳解》
《即時通訊音視頻開發(十一):實時語音通訊丟包補償技術詳解》
《即時通訊音視頻開發(十二):多人實時音視頻聊天架構探討》
《即時通訊音視頻開發(十三):實時視頻編碼H.264的特點與優勢》
《即時通訊音視頻開發(十四):實時音視頻數據傳輸協議介紹》
《即時通訊音視頻開發(十五):聊聊P2P與實時音視頻的應用情況》
《即時通訊音視頻開發(十六):移動端實時音視頻開發的幾個建議》
《即時通訊音視頻開發(十七):視頻編碼H.264、V8的前世今生》
《簡述開源實時音視頻技術WebRTC的優缺點》
《良心分享:WebRTC 零基礎開發者教程(中文)》
>> 更多同類文章 ……
[8] IM開發綜合文章:
《移動端IM開發需要面對的技術問題》
《開發IM是自己設計協議用字節流好還是字符流好?》
《請問有人知道語音留言聊天的主流實現方式嗎?》
《IM系統中如何保證消息的可靠投遞(即QoS機制)》
《談談移動端 IM 開發中登錄請求的優化》
《完全自已開發的IM該如何設計“失敗重試”機制?》
《微信對網絡影響的技術試驗及分析(論文全文)》
《即時通訊系統的原理、技術和應用(技術論文)》
《開源IM工程“蘑菇街TeamTalk”的現狀:一場有始無終的開源秀》
>> 更多同類文章 ……
[9] 開源移動端IM技術框架資料:
《開源移動端IM技術框架MobileIMSDK:快速入門》
《開源移動端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通信協議》
《一個基於MQTT通信協議的完整Android推送Demo》
《求教android消息推送:GCM、XMPP、MQTT三種方案的優劣》
《移動端實時消息推送技術淺析》
《掃盲貼:淺談iOS和Android後臺實時消息推送的原理和區別》
《絕對乾貨:基於Netty實現海量接入的推送服務技術要點》
《移動端IM實踐:谷歌消息推送服務(GCM)研究(來自微信)》
《爲何微信、QQ這樣的IM工具不使用GCM服務推送消息?》
>> 更多同類文章 ……
[11] 更多即時通訊技術好文分類:
http://www.52im.net/forum.php?mod=collection&op=all
作者:Jack Jiang (點擊作者姓名進入Github)
出處:http://www.52im.net/space-uid-1.html