TCP四次揮手(圖解)-為何要四次揮手

當客戶端和服務器通過三次握手建立了TCP連接以后，當數(shù)據(jù)傳送完畢，肯定是要斷開TCP連接的啊。那 對于TCP的斷開連接，這里就有了神秘的“四次揮手”。

第一次揮手：主機1（可以使客戶端，也可以是服務器端），設置Sequence Number和 Acknowledgment Number，向主機2發(fā)送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態(tài)；這表示 主機1沒有數(shù)據(jù)要發(fā)送給主機2了；

第二次揮手：主機2收到了主機1發(fā)送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number為Sequence Number加1；主機1進入FIN_WAIT_2狀態(tài)；主機2告訴主機1，我“同意”你的關(guān)閉 請求；

第三次揮手：主機2向主機1發(fā)送FIN報文段，請求關(guān)閉連接，同時主機2進入LAST_ACK狀態(tài)；

第四次揮手：主機1收到主機2發(fā)送的FIN報文段，向主機2發(fā)送ACK報文段，然后主機1進入TIME_WAIT 狀態(tài)；主機2收到主機1的ACK報文段以后，就關(guān)閉連接；此時，主機1等待2MSL后依然沒有收到回復， 則證明Server端已正常關(guān)閉，那好，主機1也可以關(guān)閉連接了。

為何要四次分手呢？

那四次分手又是為何呢？TCP協(xié)議是一種面向連接的、可靠的、基于字節(jié)流的運輸層通信協(xié)議。TCP是全 雙工模式，這就意味著，當主機1發(fā)出FIN報文段時，只是表示主機1已經(jīng)沒有數(shù)據(jù)要發(fā)送了，主機1告訴 主機2，它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢了；但是，這個時候主機1還是可以接受來自主機2的數(shù)據(jù)；當主機2 返回ACK報文段時，表示它已經(jīng)知道主機1沒有數(shù)據(jù)發(fā)送了，但是主機2還是可以發(fā)送數(shù)據(jù)到主機1的；當 主機2也發(fā)送了FIN報文段時，這個時候就表示主機2也沒有數(shù)據(jù)要發(fā)送了，就會告訴主機1，我也沒有數(shù) 據(jù)要發(fā)送了，之后彼此就會愉快的中斷這次TCP連接。如果要正確的理解四次分手的原理，就需要了解 四次分手過程中的狀態(tài)變化。

FIN_WAIT_1: 這個狀態(tài)要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態(tài)的真正含義都是表示等待 對方的FIN報文。而這兩種狀態(tài)的區(qū)別是：FIN_WAIT_1狀態(tài)實際上是當SOCKET在ESTABLISHED狀態(tài) 時，它想主動關(guān)閉連接，向?qū)Ψ桨l(fā)送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態(tài)。而當對方 回應ACK報文后，則進入到FIN_WAIT_2狀態(tài)，當然在實際的正常情況下，無論對方何種情況下，都應該 馬上回應ACK報文，所以FIN_WAIT_1狀態(tài)一般是比較難見到的，而FIN_WAIT_2狀態(tài)還有時常常可以用 netstat看到。（主動方）

FIN_WAIT_2：上面已經(jīng)詳細解釋了這種狀態(tài)，實際上FIN_WAIT_2狀態(tài)下的SOCKET，表示半連接，也即 有一方要求close連接，但另外還告訴對方，我暫時還有點數(shù)據(jù)需要傳送給你(ACK信息)，稍后再關(guān)閉連 接。（主動方）

CLOSE_WAIT：這種狀態(tài)的含義其實是表示在等待關(guān)閉。怎么理解呢？當對方close一個SOCKET后發(fā)送 FIN報文給自己，你系統(tǒng)毫無疑問地會回應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態(tài)。接下 來呢，實際上你真正需要考慮的事情是察看你是否還有數(shù)據(jù)發(fā)送給對方，如果沒有的話，那么你也就可 以 close這個SOCKET，發(fā)送FIN報文給對方，也即關(guān)閉連接。所以你在CLOSE_WAIT狀態(tài)下，需要完成 的事情是等待你去關(guān)閉連接。（被動方）

LAST_ACK: 這個狀態(tài)還是比較容易好理解的，它是被動關(guān)閉一方在發(fā)送FIN報文后，最后等待對方的ACK 報文。當收到ACK報文后，也即可以進入到CLOSED可用狀態(tài)了。（被動方）

TIME_WAIT: 表示收到了對方的FIN報文，并發(fā)送出了ACK報文，就等2MSL后即可回到CLOSED可用狀態(tài) 了。如果FINWAIT1狀態(tài)下，收到了對方同時帶FIN標志和ACK標志的報文時，可以直接進入到 TIME_WAIT狀態(tài)，而無須經(jīng)過FIN_WAIT_2狀態(tài)。（主動方）

為什么連接的時候是三次握手，關(guān)閉的時候卻是四次握手？

因為當Server端收到Client端的SYN連接請求報文后，可以直接發(fā)送SYN+ACK報文。其中ACK報文 是用來應答的，SYN報文是用來同步的。但是關(guān)閉連接時，當Server端收到FIN報文時，很可能并不會立 即關(guān)閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，"你發(fā)的FIN報文我收到了"。只有等到我 Server端所有的報文都發(fā)送完了，我才能發(fā)送FIN報文，因此不能一起發(fā)送。故需要四步握手。

為什么TIME_WAIT狀態(tài)需要經(jīng)過2MSL(最大報文段生存時間)才能返回到CLOSE狀態(tài)？

雖然按道理，四個報文都發(fā)送完畢，我們可以直接進入CLOSE狀態(tài)了，但是我們必須假象網(wǎng)絡是不 可靠的，有可以最后一個ACK丟失。所以TIME_WAIT狀態(tài)就是用來重發(fā)可能丟失的ACK報文。在Client發(fā) 送出最后的ACK回復，但該ACK可能丟失。Server如果沒有收到ACK，將不斷重復發(fā)送FIN片段。所以 Client不能立即關(guān)閉，它必須確認Server接收到了該ACK。Client會在發(fā)送出ACK之后進入到TIME_WAIT 狀態(tài)。Client會設置一個計時器，等待2MSL的時間。如果在該時間內(nèi)再次收到FIN，那么Client會重發(fā) ACK并再次等待2MSL。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個片段在網(wǎng) 絡中最大的存活時間，2MSL就是一個發(fā)送和一個回復所需的最大時間。如果直到2MSL，Client都沒有 再次收到FIN，那么Client推斷ACK已經(jīng)被成功接收，則結(jié)束TCP連接。

為什么不能用兩次握手進行連接？

3次握手完成兩個重要的功能，既要雙方做好發(fā)送數(shù)據(jù)的準備工作(雙方都知道彼此已準備好)，也要 允許雙方就初始序列號進行協(xié)商，這個序列號在握手過程中被發(fā)送和確認。

現(xiàn)在把三次握手改成僅需要兩次握手，死鎖是可能發(fā)生的。作為例子，考慮計算機S和C之間的通信，假 定C給S發(fā)送一個連接請求分組，S收到了這個分組，并發(fā) 送了確認應答分組。按照兩次握手的協(xié)定，S認 為連接已經(jīng)成功地建立了，可以開始發(fā)送數(shù)據(jù)分組?？墒?#xff0c;C在S的應答分組在傳輸中被丟失的情況下， 將不知道S 是否已準備好，不知道S建立什么樣的序列號，C甚至懷疑S是否收到自己的連接請求分組。在 這種情況下，C認為連接還未建立成功，將忽略S發(fā)來的任何數(shù)據(jù)分 組，只等待連接確認應答分組。而S 在發(fā)出的分組超時后，重復發(fā)送同樣的分組。這樣就形成了死鎖。

如果已經(jīng)建立了連接，但是客戶端突然出現(xiàn)故障了怎么辦？

TCP還設有一個保活計時器，顯然，客戶端如果出現(xiàn)故障，服務器不能一直等下去，白白浪費資源。服 務器每收到一次客戶端的請求后都會重新復位這個計時器，時間通常是設置為2小時，若兩小時還沒有收 到客戶端的任何數(shù)據(jù)，服務器就會發(fā)送一個探測報文段，以后每隔75秒鐘發(fā)送一次。若一連發(fā)送10個探 測報文仍然沒反應，服務器就認為客戶端出了故障，接著就關(guān)閉連接。

http協(xié)議版本區(qū)別

HTTP 是基于 TCP/IP 協(xié)議的一個應用層協(xié)議，是現(xiàn)代互聯(lián)網(wǎng)的一個基礎協(xié)議。規(guī)定了客戶端與服務端之 間的通信格式以及所占用的服務端口80(HTTPS是443)。

版本

HTTP 協(xié)議從開始立項到現(xiàn)在一共經(jīng)歷了 4 個版本:

HTTP 0.9 -> HTTP 1.0 -> HTTP 1.1 -> HTTP 2

HTTP 0.9

HTTP 0.9 是一個最古老的版本

只支持GET請求方式：由于不支持其他請求方式，因此客戶端是沒辦法向服務端傳輸太多的信息

沒有請求頭概念：所以不能在請求中指定版本號，服務端也只具有返回 HTML字符串的能力

服務端相響應之后，立即關(guān)閉TCP連接

HTTP 1.0

隨著 HTTP 1.0 的發(fā)布，這個版本:

請求方式新增了POST，DELETE，PUT，HEADER等方式

增添了請求頭和響應頭的概念，在通信中指定了 HTTP 協(xié)議版本號，以及其他的一些元信息 (比如: 狀態(tài)碼、權(quán)限、緩存、內(nèi)容編碼)

擴充了傳輸內(nèi)容格式，圖片、音視頻資源、二進制等都可以進行傳輸

在這個版本主要的就是對請求和響應的元信息進行了擴展，客戶端和服務端有更多的獲取當前請求的所 有信息，進而更好更快的處理請求相關(guān)內(nèi)容。

請求頭

一個簡單請求的頭信息

GET / HTTP/1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) Accept: / 可以看到在請求方法之后有 請求資源的位置 + 請求協(xié)議版本，之后是一些客戶端的信息配置

響應頭

一個簡單響應的頭信息(v1.0)

HTTP/1.0 200 OK Content-Type: text/plain Content-Length: 137582 Expires: Thu, 05 Dec 1997 16:00:00 GMT Last-Modified: Wed, 5 August 1996 15:55:28 GMT // 這是一個空行 ...數(shù)據(jù)內(nèi)容服務端的響應頭第一個就是 請求協(xié)議版本，后面緊跟著是這次請求的狀態(tài)碼、以及狀態(tài)碼的描述，之后 的內(nèi)容是一些關(guān)于返回內(nèi)容的描述。

Content-Type

在 HTTP 1.0 的時候，任何的資源都可以被傳輸，傳輸?shù)母袷侥匾彩嵌喾N多樣的，客戶端在收到響應體 的內(nèi)容的時候就是根據(jù)這個 Content-Type 去進行解析的。所以服務端返回時候必須帶著這個字段。

這些 Content-Type 有一個總稱叫做MIME type。

關(guān)于MIME type，這里想播插一個小插曲:

在 chrome 瀏覽器中，當跨域請求回來的數(shù)據(jù) MIME type 同跨域標簽應有的 MIME type 不匹配時，瀏 覽器會啟動 CORB 保護數(shù)據(jù)不被泄漏。被保護的數(shù)據(jù)有: html、xml、json。(eg: script、img 標簽所支 持的 MIME type和他們都不一致)，所以服務端在返回資源的時候一定要對應返回正確的 Content Type，以免瀏覽器屏蔽返回結(jié)果。

筆者遇到的問題是在 chrome v76 版本之后，跨域圖片資源當請求回來的數(shù)據(jù) Content-Type 不是 image/*，圖片會被攔截，頁面不展示圖片。

特性

無狀態(tài)：服務器不跟蹤不記錄請求過的狀態(tài)

無連接：瀏覽器每次請求都需要建立tcp連接

無狀態(tài)

對于無狀態(tài)的特性可以借助cookie/session機制來做身份認證和狀態(tài)記錄

無連接

無連接導致的性能缺陷有兩種：

無法復用連接

每次發(fā)送請求，都需要進行一次tcp連接（即3次握手4次揮手），使得網(wǎng)絡的利用率非常低

隊頭阻塞

HTTP 1.0 規(guī)定在前一個請求響應到達之后下一個請求才能發(fā)送，如果前一個阻塞，后面的請求也 給阻塞的

HTTP 1.1

HTTP 1.1 是在 1.0 發(fā)布之后的半年就推出了，完善了 1.0 版本。目前也還有很多的互聯(lián)網(wǎng)項目基于 HTTP 1.1 在向外提供服務。

特性

長連接：新增Connection字段，可以設置keep-alive值保持連接不斷開

管道化：基于上面長連接的基礎，管道化可以不等第一個請求響應繼續(xù)發(fā)送后面的請求，但響應的 順序還是按照請求的順序返回

緩存處理：新增字段cache-control

斷點傳輸

長連接

HTTP 1.1默認保持長連接，數(shù)據(jù)傳輸完成保持tcp連接不斷開,繼續(xù)用這個通道傳輸數(shù)據(jù)

管道化

基于長連接的基礎，我們先看沒有管道化請求響應：

tcp沒有斷開，用的同一個通道

請求1 > 響應1 --> 請求2 > 響應2 --> 請求3 > 響應3

管道化的請求響應： 請求1 --> 請求2 --> 請求3 > 響應1 --> 響應2 --> 響應3

即使服務器先準備好響應2,也是按照請求順序先返回響應1

雖然管道化，可以一次發(fā)送多個請求，但是響應仍是順序返回，仍然無法解決隊頭阻塞的問題

緩存處理

當瀏覽器請求資源時，先看是否有緩存的資源，如果有緩存，直接取，不會再發(fā)請求，如果沒有緩存， 則發(fā)送請求。

通過設置字段cache-control來控制緩存。

斷點傳輸

在上傳/下載資源時，如果資源過大，將其分割為多個部分，分別上傳/下載，如果遇到網(wǎng)絡故障，可以 從已經(jīng)上傳/下載好的地方繼續(xù)請求，不用從頭開始，提高效率

HTTP 2

特性:

二進制分幀

多路復用： 在共享TCP鏈接的基礎上同時發(fā)送請求和響應

頭部壓縮

服務器推送：服務器可以額外的向客戶端推送資源，而無需客戶端明確的請求

二進制分幀

HTTP 1.x 的解析是基于文本，HTTP 2之后將所有傳輸?shù)男畔⒎指顬楦〉南⒑蛶?#xff0c;并對它們采用二進 制格式的編碼，提高傳輸效率

多路復用

在共享TCP鏈接的基礎上同時發(fā)送請求和響應，基于二進制分幀，在同一域名下所有訪問都是從同一個 tcp連接中走，http消息被分解為獨立的幀，亂序發(fā)送，服務端根據(jù)標識符和首部將消息重新組裝起來。

頭部壓縮

由于 HTTP 是無狀態(tài)的，每一個請求都需要頭部信息標識這次請求相關(guān)信息，所以會造成傳輸很多重復 的信息，當請求數(shù)量增大的時候，消耗的資源就會慢慢積累上去。所以 HTTP 2 可以維護一個頭部信息 字典，差量進行更新頭信息，減少頭部信息傳輸占用的資源，詳見 HTTP/2 頭部壓縮技術(shù)介紹。

HTTPS 和 HTTP

HTTPS 協(xié)議需要申請證書

HTTP 和 HTTPS 使用端口不一樣，前者是80，后者是443

HTTP 協(xié)議運行在 TCP 之上，所有傳輸?shù)膬?nèi)容都是明文，HTTPS 運行在 SSL/TLS 之上，SSL/TLS運行在TCP之上，所有傳輸?shù)膬?nèi)容都經(jīng)過加密的

HTTPS 可以有效的防止運營商劫持