理解 HTTP 協議以及 TCP 三次握手與四次分手的過程

理解 HTTP 協議

超文字傳輸 ​​ 協議（HTTP）是用於傳輸諸如 HTML 的超媒體文件的應用層協議，最頂層的協議。HTTP 是無狀態協議，意味著伺服器不會在兩個請求之間保留任何資料（狀態）。

關於無狀態的理解

可以理解為 HTTP 是沒有上下文的，HTTP 無法儲存連線雙方的狀態資訊。基於此，知乎上有看到一個很直觀的白話例子：

TCP 三次握手與四次分手

TCP 建立連線的時候需要三次握手，斷開連線需要四次分手，這個過程是比較抽象的。

整個過程簡單白話一下就是：

三次握手

1. 客戶端寫了一封情書： 我中意你啊（建立連線的請求）
2. 服務端收到了這封情書的回覆：哇，我也中意你啊，mua
3. 客戶端收到了服務端的 mua ：好啊，那我們就在一起吧（真正建立連線）

當然上面這是正常的情況，如果遇到情書發錯人（連接出錯）的情況，服務端就懶得理了，然後雙發就不可能在一起（建立連線）。

為什麼 TCP 連線需要三次握手

當然其實會有更多的人疑問，為什麼 TCP 連線需要三次握手而不是兩次，因為按照上面的意思，客戶端來一句：在一起， 服務端回一個：好， 就可以了啊，為什麼客戶端還要多此一舉回覆一個“我也好”呢。其實原因很簡單，跟 TCP 的特性有關，TCP 通道是不可靠的，而三次握手是滿足通道安全的最小握手次數。繼續用上面的例子來分析下：

先假設只有兩次握手的情況：

1. 客戶端寫了一封情書： 我中意你啊（建立連線的請求），但是因為某些原因，郵局放假啦，你的情書被擱置在路上了
2. 客戶端沒有收到回覆，於是又寫了一封情書：我真的好中意你啊（建立連線的請求）
3. 服務端收到了這封情書的回覆：哇，我也中意你啊，mua（建立連線）
4. 到這時，客戶端和服務端已經可以愉快的玩耍了。但是忽然，客戶端寫的第一封情書也到了，服務端看到了，依然回覆了句： 死鬼，我知道了
5. 因為 HTTP 是無狀態的，客戶端不知道服務端回覆的是啥，就沒理。
6. 服務端就在一直等待中：這個死鬼的情書到底是寫給誰，怎麼不回覆我。於是服務端憔悴至死（資源浪費）

然後是三次握手的情況：

1. 客戶端寫了一封情書： 我中意你啊（建立連線的請求），但是因為某些原因，有句放假啦，你的情書被擱置在路上了
2. 客戶端沒有收到回覆，於是又寫了一封情書：我真的好中意你啊（建立連線的請求）
3. 服務端收到了這封情書的回覆：哇，我也中意你啊，mua
4. 客戶端收到了服務端的 mua ：好啊，那我們就在一起吧（真正建立連線）
5. 到這時，客戶端和服務端已經可以愉快的玩耍了。但是忽然，客戶端寫的第一封情書也到了，服務端看到了，依然回覆了句： 死鬼，我知道了
6. 客戶端一看，這是錯了： 這是情書發錯了，別再等了

三次握手的基本情況都老實交代了了，就那樣。

四次分手

然後是四次分手，這個就簡單的多：

1. 客戶端和服務端膩歪了，就說要分手，客戶端：分手吧 （關閉連線的請求）
2. 服務端：分就分，但是還有你的一些破東西，還給你（傳遞向客戶端待發送的資料）
3. 客戶端收到回覆了，就原地待命
4. 服務端資料傳送完了：好了，都扔了（資料傳送完畢）
5. 客戶端接收到資料，然後給個回覆：好的，我知道了，拜拜。

以上都是抖機靈的理解。其實 TCP 的三次連線和四次分手要複雜的多，可以參考以下正經的部落格：