文章插圖
這張圖并不完全，明顯缺失了很大一塊，但是我相信你一定知道那缺失的部分有哪些內容 ， 也當作是留給你的作業吧~
其實到這里本篇就算是完事了，但是完事的有點突然，其實在描述上面的整個數據包流轉的過程中，越到底層我描述的就越少，其實我刻意省略了很多關于TCP、IP以及MAC的重要內容，但是這篇系列畢竟不是講互聯網絡的，大家知道它在空間上經歷了哪些部分即可，如果有興趣，大家可以自行查找資料學習，我猜你不會找，哈哈哈哈
補充：四次揮手數據傳輸完了之后，TCP還需要做一點事情，就是通道建立了 ， 但是當我不需要的時候，我想把通道關閉，不然一直監聽著有沒有消息給我實在是太累了 。
當TCP關閉通道的時候 ， 需要通過四次揮手來確認，它是這樣揮手的：
文章插圖
我們解釋完這張圖，本章就完事啦 。
我們簡單解釋下這張圖 ， 當客戶端發送一個“我不玩了”的消息后 ， 就會進入到FIN_WAIT_1的狀態，等待后續的服務器反?。?當服務器收到消息后，就會在之前的基礎上給包序號加+1返回給客戶端，那么此時服務器就進入到了CLOSED_WAIT的待關閉狀態 。
我們稍微跑題一下，在學習了三次握手，和上面四次揮手的圖示后，你發現一個問題沒有 ， 就是所有的應答都是在請求的基礎包序號上+1 。換種理解方式就是+1的序號都是作為應答出現的包 。我們繼續上面的話題 ， 當客戶端收到了服務器的第一次響應應答后，會進入到FIN_WAIT_2的狀態，為啥這里客戶端要等服務器再發送一個包呢？假如服務器還有未處理完的數據要給你咋整？你不是還得接收，所以要等服務器的數據都處理完畢了，告訴客戶端 ， 我這邊也可以不玩了才行 。
于是 ， 當服務器也結束了自己的任務的時候 ， 就把包發給客戶端，客戶端進入TIME_WAIT的狀態 。當服務器收到第二次客戶端的應答后，就直接關閉了 。
最后，TCP還要求客戶端還是要持續的監聽一段時間，這個時間就是報文最大生存時間，等了一段時間后，就進入關閉的狀態了 。
我們看哈，其實整個四次揮手，一次是由客戶端發起，一次服務器應答，一次是由服務器發起，客戶端應答 ， 最后，客戶端再等待一段時間 。才最終結束整個揮手過程 。
那他為什么不可以像三次握手那樣，請求 ， 響應 ， 響應響應，三個步驟就可以了呢 。這里有一個核心就是，建立連接時，雙方都處于空閑狀態，沒有正在運行的程序，而關閉時，需要確定雙方的程序都結束才可以 。所以再四次揮手的由服務器發起的請求的過程中，就是為了等待服務器的任務跑完 。
小結我們稍微回顧下我們本章都學習了什么 。
- DoD模型與OSI模型的異同 ， 你知道4 ， 7，5都是怎么來的么？
- 一個HTTP包在5層模型中的穿梭過程（特別簡易版），你知道發送一個HTTP請求要經歷哪些過程么？
- 三次握手和四次揮手，我想握手三百次，揮手四百次，是否可以呢？
最后，本人能力有限，若在閱讀過程中發現謬誤，還望不吝指教 。非常感謝~~
推薦閱讀
- 用 VS Code 搞 Qt6：信號、槽，以及QObject
- React動畫實現方案之 Framer Motion，讓你的頁面“自己”動起來
- “元芳，你怎么看”這句話當時是怎么火起來的
- 元芳你怎么看怎么幽默回復（神回復系列搞笑評論)
- “-”、“_”怎么打出來（怎么打出來的字有顏色)
- 一橫“_” 電腦上怎么打（電腦中橫杠怎么打)
- 用昇騰AI護航“井下安全”
- 兩種方法 我的世界怎么附魔（我的世界怎么搞附魔)
- 盤它！基于CANN的輔助駕駛AI實戰案例，輕松搞定車輛檢測和車距計算！
- MySQL 全局鎖、表級鎖、行級鎖，你搞清楚了嗎？