一組圖帶你讀懂TCP連接的終止——四次揮手的原理~
TCP是一個面向連接的協(xié)議，無論哪一方向另一方發(fā)送數(shù)據(jù)之前，都必須先在雙方之間家里一條連接。
而建立一個TCP連接需要三次握手，這個我在昨天的文章中已詳細(xì)說明，這里就不提了。
還沒看過的同學(xué)看這里👇
《為什么TCP 要采用「3次握手」建立連接?1個例子教會你~》
今天講講TCP連接的終止，也就是我們平時說的四次揮手。
這是由于TCP的半關(guān)閉 ( half-close)造成的。
因?yàn)橐粋€TCP連接時全雙工(即數(shù)據(jù)在兩個方向上能同時傳遞)，因此每個方面必須單獨(dú)地進(jìn)行關(guān)閉。
需要注意的是，收到一個FIN 只意味著在這一方向上沒有數(shù)據(jù)流動，但一個TCP連接在收到一個FIN之后仍能發(fā)送數(shù)據(jù)。
TCP 連接終止過程，如圖1所示 ：
- TCP 客戶端發(fā)送一個FIN ，用來關(guān)閉從客戶端到服務(wù)器的數(shù)據(jù)傳送;
- 當(dāng)服務(wù)器收到這個FIN ，它發(fā)回一個ACK ，確認(rèn)序號為收到的序號加1 。一個FIN 也將占用一個序號;
- 服務(wù)器程序首先傳送一個文件結(jié)束符，然后服務(wù)器關(guān)閉它的連接，發(fā)送一個FIN 到客戶端;
- 客戶端回復(fù)一個確認(rèn)。
最大報文段長度(MSS)表示TCP 傳往另一端的最大塊數(shù)據(jù)塊的長度。當(dāng)建立一個TCP連接時，每一方都有用于通告它期望接收的MSS選項 ( MSS選項只能出現(xiàn)在SYN報文段中) 。
如果一方?jīng)]有接收到來自另一方的MSS值，則 MSS就定為默認(rèn)值536字節(jié)(這個默認(rèn)值允許20 字節(jié)的IP 首部和20字節(jié)的TCP首部以適合576 字節(jié)的IP數(shù)據(jù)報)。
MSS讓主機(jī)限制另一端發(fā)送數(shù)據(jù)報的長度，加上主機(jī)也能控制它發(fā)送數(shù)據(jù)報的長度，這將使以較小MTU接收到一個網(wǎng)絡(luò)上的主機(jī)避免分段。
圖1
半連接：TCP 連接的一端在結(jié)束它的發(fā)送之后還能接收到來自另一端數(shù)據(jù)的能力。
TCP 的狀態(tài)變遷圖(如圖所示)：
ESTABLISHED狀態(tài)是連接雙方能夠進(jìn)行雙向數(shù)據(jù)傳送的狀態(tài)。
當(dāng) SYN_RCVD(圖中SYN 收到)狀態(tài)是從LISTEN狀態(tài)(正常情況)進(jìn)入，而不是從SYN_SENT狀態(tài)(同時打開)進(jìn)入時，從SYN_RCVD回到 LISTEN狀態(tài)變遷才是有效的。
這意味著如果執(zhí)行被動打開(進(jìn)入LISTEN)，收到一個SYN，發(fā)送一個帶ACK的 SYN(進(jìn)入SYN_RCVD)，然后收到一個RST，而不是一個ACK，便又回到LISTEN狀態(tài)并等待另一個連接請求的到來。
TIME_WAIT狀態(tài)也成為2MSL等待狀態(tài)。
當(dāng) TCP 執(zhí)行一個主動關(guān)閉，并發(fā)回最后一個ACK ，該連接必須在TIME_WAIT狀態(tài)停留 的時間為2倍的MSL 。
這樣可讓TCP再次發(fā)送最后的ACK以防這個ACK丟失(另一端超時并重發(fā)組后的FIN )。
一個 socket對(即包含本地IP 地址、本地端口、遠(yuǎn)端IP 地址和遠(yuǎn)端端口的4 元組)在TCP連接處于2 MSL 等待期間，將不能再次被使用。
盡管許多具體的實(shí)現(xiàn)中允許一個進(jìn)程重新使用仍處于2 MSL 等待的端口(通常是設(shè)置選項SO_REUSEADDR)，但TCP 不能允許一個新的連接建立在相同的插口上。
無論何時一個報文段發(fā)往基準(zhǔn)的連接(即，由目的IP地址和目的端口號以及源IP地址和源端口號指明的連接)出現(xiàn)錯誤，TCP都會發(fā)回一個復(fù)位報文段。
異常終止(發(fā)送一個復(fù)位(RST )報文段而不是FIN 來中途釋放一個連接)一個連接對應(yīng)用程序來說有兩點(diǎn)好處：
- 丟棄任何待發(fā)數(shù)據(jù)并立即發(fā)送復(fù)位報文段;
- RST 的接收方會區(qū)分另一端執(zhí)行的是異常關(guān)閉還是正常關(guān)閉。在正常關(guān)閉的情況，需要在所有排隊數(shù)據(jù)都已發(fā)送之后才發(fā)送FIN 。因此，正常情況下沒有任何數(shù)據(jù)丟失。
Socket API通過“ linger to close選項”(SO_LINGER)提供這種異常關(guān)閉的能力。
如果一方已經(jīng)關(guān)閉或異常終止連接而另一方卻還不知道，這樣的TCP 連接成為半打開(Half-Open)的。
任何一端的主機(jī)異常都可能導(dǎo)致這種情況的發(fā)生。
只要不打算在半打開連接上傳輸數(shù)據(jù)，仍處于連接狀態(tài)的一方就不會檢測另一方已經(jīng)出現(xiàn)異常。
發(fā)生半打開連接的另一個常見原因是，當(dāng)客戶主機(jī)突然掉電而不是正常的結(jié)束客戶應(yīng)用程序后在關(guān)機(jī)。
TCP 連接在同時打開的情況下，僅建立一條連接而不是兩條連接。
下圖顯示了同時打開期間報文段的交換。
兩端幾乎在同時發(fā)送SYN ，并進(jìn)入SYN_SENT狀態(tài)。
當(dāng)每一端收到SYN時，狀態(tài)為SYN_RCVD，同時它們都再發(fā)送SYN并對收到的SYN進(jìn)行確認(rèn)。
當(dāng)雙方都收到SYN及相應(yīng)的ACK時，狀態(tài)都邊前衛(wèi)ESTABLISHED。
因此，一個同時打開的連接需要交換4個報文段。
同時關(guān)閉 ：當(dāng)應(yīng)用層發(fā)送關(guān)閉命令時，兩端均從ESTABLISHED變?yōu)?FIN_WAIT_1。
這將導(dǎo)致雙方各發(fā)送一個FIN，兩個FIN 經(jīng)過網(wǎng)絡(luò)傳送后分別到達(dá)另一端。
收到FIN后，狀態(tài)由FIN_WAIT_1變遷到CLOSING，并發(fā)送最后的ACK。
當(dāng)收到最后的ACK時，狀態(tài)變化為TIME_WAIT。
下圖總結(jié)了這些變化。
再如下圖，顯示了當(dāng)前TCP選項的格式，這些選項的定義來自于RFC 793和RFC1323 。
每個選項的開始是1字節(jié)kind字段，說明選項的類型。
好了，今天的分享就到這了。
