、引言
網絡編程中TCP協議的三次握手和四次揮手的問題，在面試中是最為常見的知識點之一。很多讀者都知道“三次”和“四次”，但是如果問深入一點，他們往往都無法作出準確回答。
本篇文章嘗試使用動畫圖片的方式，來對這個知識點進行“腦殘式”講解（哈哈），期望讀者們可以更加簡單、直觀地理解TCP網絡通信交互的本質。
另外，社區里的另兩篇文章《理論經典：TCP協議的3次握手與4次揮手過程詳解》、《理論聯系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》也是不錯的入門文章，有興趣可一并詳讀之。
友情提示：因本文gif動畫較多，如果您的網速較慢，請耐心等候圖片加載完成哦。
學習交流：
- 即時通訊開發交流3群：185926912[推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
（本文同步發布于：http://www.52im.net/thread-1729-1-1.html）
2、關于作者
錢文品（老錢）：畢業于華中科技大學計算機科學與技術專業，互聯網分布式高并發技術十年老兵，目前任掌閱科技資深后端工程師。熟練使用 Java、Python、Golang 等多種計算機語言，開發過游戲，制作過網站，寫過消息推送系統和MySQL 中間件，實現過開源的 ORM 框架、Web 框架、RPC 框架等。
作者的Github： https://github.com/pyloque
3、系列文章
本文是系列文章中的第1篇，本系列大綱如下：
《腦殘式網絡編程入門(一)：跟著動畫來學TCP三次握手和四次揮手》（本文）
《腦殘式網絡編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？》
4、TCP 三次握手：“Say hello !”
TCP 三次握手就好比兩個人在街上隔著50米看見了對方，但是因為霧霾等原因不能100%確認，所以要通過招手的方式相互確定對方是否認識自己。
張三首先向李四招手(syn)，李四看到張三向自己招手后，向對方點了點頭擠出了一個微笑(ack)。張三看到李四微笑后確認了李四成功辨認出了自己(進入estalished狀態)。
但是李四還有點狐疑，向四周看了一看，有沒有可能張三是在看別人呢，他也需要確認一下。所以李四也向張三招了招手(syn)，張三看到李四向自己招手后知道對方是在尋求自己的確認，于是也點了點頭擠出了微笑(ack)，李四看到對方的微笑后確認了張三就是在向自己打招呼(進入established狀態)。
于是兩人加快步伐，走到了一起，相互擁抱。
我們看到這個過程中一共是四個動作，張三招手--李四點頭微笑--李四招手--張三點頭微笑。其中李四連續進行了2個動作，先是點頭微笑(回復對方)，然后再次招手(尋求確認)，實際上可以將這兩個動作合一，招手的同時點頭和微笑(syn+ack)。于是四個動作就簡化成了三個動作，張三招手--李四點頭微笑并招手--張三點頭微笑。這就是三次握手的本質，中間的一次動作是兩個動作的合并。
我們看到有兩個中間狀態，syn_sent和syn_rcvd，這兩個狀態叫著「半打開」狀態，就是向對方招手了，但是還沒來得及看到對方的點頭微笑。syn_sent是主動打開方的「半打開」狀態，syn_rcvd是被動打開方的「半打開」狀態。客戶端是主動打開方，服務器是被動打開方。
syn_sent: syn package has been sent
syn_rcvd: syn package has been received
5、握手完成：開始TCP 數據傳輸
TCP 數據傳輸就是兩個人隔空對話，差了一點距離，所以需要對方反復確認聽見了自己的話。
張三喊了一句話(data)，李四聽見了之后要向張三回復自己聽見了(ack)。
如果張三喊了一句，半天沒聽到李四回復，張三就認為自己的話被大風吹走了，李四沒聽見，所以需要重新喊話，這就是tcp重傳。
也有可能是李四聽到了張三的話，但是李四向張三的回復被大風吹走了，以至于張三沒聽見李四的回復。張三并不能判斷究竟是自己的話被大風吹走了還是李四的回復被大風吹走了，張三也不用管，重傳一下就是。
既然會重傳，李四就有可能同一句話聽見了兩次，這就是「去重」。「重傳」和「去重」工作操作系統的網絡內核模塊都已經幫我們處理好了，用戶層是不用關心的。
張三可以向李四喊話，同樣李四也可以向張三喊話，因為tcp鏈接是「雙工的」，雙方都可以主動發起數據傳輸。不過無論是哪方喊話，都需要收到對方的確認才能認為對方收到了自己的喊話。
張三可能是個高射炮，一說連說了八句話，這時候李四可以不用一句一句回復，而是連續聽了這八句話之后，一起向對方回復說前面你說的八句話我都聽見了，這就是批量ack。但是張三也不能一次性說了太多話，李四的腦子短時間可能無法消化太多，兩人之間需要有協商好的合適的發送和接受速率，這個就是「TCP窗口大小」。
網絡環境的數據交互同人類之間的對話還要復雜一些，它存在數據包亂序的現象。同一個來源發出來的不同數據包在「網際路由」上可能會走過不同的路徑，最終達到同一個地方時，順序就不一樣了。操作系統的網絡內核模塊會負責對數據包進行排序，到用戶層時順序就已經完全一致了。
6、TCP 四次揮手：“Say goodbye!”
TCP斷開鏈接的過程和建立鏈接的過程比較類似，只不過中間的兩部并不總是會合成一步走，所以它分成了4個動作，張三揮手(fin)——李四傷感地微笑(ack)——李四揮手(fin)——張三傷感地微笑(ack)。
之所以中間的兩個動作沒有合并，是因為tcp存在「半關閉」狀態，也就是單向關閉。張三已經揮了手，可是人還沒有走，只是不再說話，但是耳朵還是可以繼續聽，李四呢繼續喊話。等待李四累了，也不再說話了，超張三揮了揮手，張三傷感地微笑了一下，才徹底結束了。
上面有一個非常特殊的狀態time_wait，它是主動關閉的一方在回復完對方的揮手后進入的一個長期狀態，這個狀態標準的持續時間是4分鐘，4分鐘后才會進入到closed狀態，釋放套接字資源。不過在具體實現上這個時間是可以調整的。
它就好比主動分手方要承擔的責任，是你提出的要分手，你得付出代價。這個后果就是持續4分鐘的time_wait狀態，不能釋放套接字資源(端口)，就好比守寡期，這段時間內套接字資源(端口)不得回收利用。
它的作用是重傳最后一個ack報文，確保對方可以收到。因為如果對方沒有收到ack的話，會重傳fin報文，處于time_wait狀態的套接字會立即向對方重發ack報文。
同時在這段時間內，該鏈接在對話期間于網際路由上產生的殘留報文(因為路徑過于崎嶇，數據報文走的時間太長，重傳的報文都收到了，原始報文還在路上)傳過來時，都會被立即丟棄掉。4分鐘的時間足以使得這些殘留報文徹底消逝。不然當新的端口被重復利用時，這些殘留報文可能會干擾新的鏈接。
4分鐘就是2個MSL，每個MSL是2分鐘。MSL就是maximium segment lifetime——最長報文壽命。這個時間是由官方RFC協議規定的。至于為什么是2個MSL而不是1個MSL，我還沒有看到一個非常滿意的解釋。
四次揮手也并不總是四次揮手，中間的兩個動作有時候是可以合并一起進行的，這個時候就成了三次揮手，主動關閉方就會從fin_wait_1狀態直接進入到time_wait狀態，跳過了fin_wait_2狀態。
7、本文小結
TCP狀態轉換是一個非常復雜的過程，本文僅對一些簡單的基礎知識點進行了類比講解。關于TCP的更多知識還需要讀者去搜尋相關技術文章進入深入學習。如果讀者對TCP的基礎知識掌握得比較牢固，高級的知識理解起來就不會太過于吃力。
附錄1：同類文章精選
如果您覺得本系列文章過于基礎，您可直接閱讀以下系列：
《網絡編程懶人入門(一)：快速理解網絡通信協議（上篇）》
《網絡編程懶人入門(二)：快速理解網絡通信協議（下篇）》
《網絡編程懶人入門(三)：快速理解TCP協議一篇就夠》
《網絡編程懶人入門(四)：快速理解TCP和UDP的差異》
《網絡編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優勢》
《網絡編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》
《網絡編程懶人入門(七)：深入淺出，全面理解HTTP協議》
《不為人知的網絡編程》系列文章為高階必讀，該系列目錄如下：
《不為人知的網絡編程(一)：淺析TCP協議中的疑難雜癥(上篇)》
《不為人知的網絡編程(二)：淺析TCP協議中的疑難雜癥(下篇)》
《不為人知的網絡編程(三)：關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》
《不為人知的網絡編程(四)：深入研究分析TCP的異常關閉》
《不為人知的網絡編程(五)：UDP的連接性和負載均衡》
《不為人知的網絡編程(六)：深入地理解UDP協議并用好它》
關于移動端網絡特性及優化手段的總結性文章請見：
《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
附錄2：參考資料
《TCP/IP詳解 - 第11章·UDP：用戶數據報協議》
《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》
《TCP/IP詳解 - 第18章·TCP連接的建立與終止》
《TCP/IP詳解 - 第21章·TCP的超時與重傳》
《通俗易懂-深入理解TCP協議（上）：理論基礎》
《通俗易懂-深入理解TCP協議（下）：RTT、滑動窗口、擁塞處理》
《理論經典：TCP協議的3次握手與4次揮手過程詳解》
《理論聯系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》
《計算機網絡通訊協議關系圖（中文珍藏版）》
《高性能網絡編程(一)：單臺服務器并發TCP連接數到底可以有多少》
《高性能網絡編程(二)：上一個10年，著名的C10K并發連接問題》
《高性能網絡編程(三)：下一個10年，是時候考慮C10M并發問題了》
《高性能網絡編程(四)：從C10K到C10M高性能網絡應用的理論探索》
《簡述傳輸層協議TCP和UDP的區別》
《為什么QQ用的是UDP協議而不是TCP協議？》
《移動端即時通訊協議選擇：UDP還是TCP？》
《技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）》
《UDP中一個包的大小最大能多大？》
《Java新一代網絡編程模型AIO原理及Linux系統AIO介紹》
《NIO框架入門(一)：服務端基于Netty4的UDP雙向通信Demo演示》
《NIO框架入門(二)：服務端基于MINA2的UDP雙向通信Demo演示》
《NIO框架入門(三)：iOS與MINA2、Netty4的跨平臺UDP雙向通信實戰》
《NIO框架入門(四)：Android與MINA2、Netty4的跨平臺UDP雙向通信實戰》
《P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介》
《P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解》
《P2P技術詳解(三)：P2P技術之STUN、TURN、ICE詳解》
《通俗易懂：快速理解P2P技術中的NAT穿透原理》
>> 更多同類文章 ……
（本文同步發布于：http://www.52im.net/thread-1729-1-1.html）