前言
本文將會(huì)首先介紹TCP的各個(gè)狀態(tài)，然后描述TCP三次握手和四次揮手時(shí)的狀態(tài)變化，最后重點(diǎn)介紹TIME_WAIT狀態(tài)。
TCP連接狀態(tài)
一個(gè)TCP連接在它的生命周期內(nèi)會(huì)有不同的狀態(tài)。
下圖說(shuō)明了TCP連接可能會(huì)有的狀態(tài)，以及基于事件的狀態(tài)轉(zhuǎn)換。事件中有的是應(yīng)用程序的操作，有的是接收到了網(wǎng)絡(luò)發(fā)過(guò)來(lái)的請(qǐng)求。
TCP狀態(tài)及其描述如下表。
| 狀態(tài) | 描述 |
|---|---|
| LISTEN | 等待來(lái)自遠(yuǎn)程TCP應(yīng)用程序的請(qǐng)求 |
| SYN_SENT | 發(fā)送連接請(qǐng)求后等待來(lái)自遠(yuǎn)程端點(diǎn)的確認(rèn)。TCP第一次握手后客戶端所處的狀態(tài) |
| SYN-RECEIVED | 該端點(diǎn)已經(jīng)接收到連接請(qǐng)求并發(fā)送確認(rèn)。 該端點(diǎn)正在等待最終確認(rèn)。TCP第二次握手后服務(wù)端所處的狀態(tài) |
| ESTABLISHED | 代表連接已經(jīng)建立起來(lái)了。這是連接數(shù)據(jù)傳輸階段的正常狀態(tài) |
| FIN_WAIT_1 | 等待來(lái)自遠(yuǎn)程TCP的終止連接請(qǐng)求或終止請(qǐng)求的確認(rèn) |
| FIN_WAIT_2 | 在此端點(diǎn)發(fā)送終止連接請(qǐng)求后，等待來(lái)自遠(yuǎn)程TCP的連接終止請(qǐng)求 |
| CLOSE_WAIT | 該端點(diǎn)已經(jīng)收到來(lái)自遠(yuǎn)程端點(diǎn)的關(guān)閉請(qǐng)求，此TCP正在等待本地應(yīng)用程序的連接終止請(qǐng)求 |
| CLOSING | 等待來(lái)自遠(yuǎn)程TCP的連接終止請(qǐng)求確認(rèn) |
| LAST_ACK | 等待先前發(fā)送到遠(yuǎn)程TCP的連接終止請(qǐng)求的確認(rèn) |
| TIME_WAIT | 等待足夠的時(shí)間來(lái)確保遠(yuǎn)程TCP接收到其連接終止請(qǐng)求的確認(rèn) |
TCP三次握手
當(dāng)一個(gè)TCP連接建立時(shí)，發(fā)生了以下事情：
- 服務(wù)端必須準(zhǔn)備接收傳入的連接。這通常通過(guò)調(diào)用
socket，bind和listen來(lái)完成，稱(chēng)為被動(dòng)打開(kāi)。 - 客戶端通過(guò)調(diào)用
connect方法來(lái)發(fā)起一個(gè)主動(dòng)的打開(kāi)?？蛻舳薚CP會(huì)發(fā)送一個(gè)“同步”(SYN)段，它告訴服務(wù)器客戶端在連接上發(fā)送的數(shù)據(jù)的初始序列號(hào)。通常情況下，SYN沒(méi)有發(fā)送數(shù)據(jù)，它只包含一個(gè)IP頭，TCP頭和可能的TCP選項(xiàng)。 - 服務(wù)器必須確認(rèn)（ACK）客戶端的SYN，并且服務(wù)器還必須發(fā)送自己的SYN，其中包含服務(wù)器將在連接上發(fā)送的數(shù)據(jù)的初始序列號(hào)。
- 客戶端必須確認(rèn)服務(wù)器的SYN。
下圖顯示了TCP三次握手的過(guò)程，以及客戶端和服務(wù)端狀態(tài)的變化。
TCP四次揮手
一個(gè)TCP連接需要四步斷開(kāi)：
- 一個(gè)應(yīng)用程序首先執(zhí)行
close，發(fā)送FIN段，這個(gè)操作被稱(chēng)為主動(dòng)關(guān)閉，這意味著這一端完成數(shù)據(jù)的發(fā)送。 - 執(zhí)行FIN的另一端執(zhí)行被動(dòng)關(guān)閉，該端發(fā)送ACK，確認(rèn)該FIN。
- 被動(dòng)關(guān)閉的一端執(zhí)行
close，向主動(dòng)關(guān)閉的一方發(fā)送FIN。 - 主動(dòng)關(guān)閉的一方確認(rèn)收到的FIN。
下圖顯示了一次典型的TCP四次揮手的過(guò)程，以及主動(dòng)關(guān)閉方和被動(dòng)關(guān)閉方的狀態(tài)變化。在圖中是客戶端主動(dòng)斷開(kāi)了連接，這里只是舉個(gè)例子，服務(wù)端一樣可以主動(dòng)斷開(kāi)連接。
TIME_WAIT狀態(tài)
TIME_WAIT狀態(tài)應(yīng)該是最讓人疑惑的一個(gè)狀態(tài)了。在上圖中可以看到，執(zhí)行主動(dòng)斷開(kāi)的節(jié)點(diǎn)最后會(huì)進(jìn)入這個(gè)狀態(tài)，該節(jié)點(diǎn)會(huì)在此狀態(tài)保存2倍的MSL（最大段生存期）。
TCP的每個(gè)實(shí)現(xiàn)都必須為MSL選擇一個(gè)值。RFC 1122推薦的值為兩分鐘，伯克利派的實(shí)現(xiàn)使用30秒。這也就是說(shuō)TIME_WAIT狀態(tài)會(huì)維持1到4分鐘。MSL是任何IP數(shù)據(jù)報(bào)可以在網(wǎng)絡(luò)中生存的最長(zhǎng)時(shí)間。這個(gè)時(shí)間是有限制的，因?yàn)槊總€(gè)數(shù)據(jù)報(bào)都包含一個(gè)8位的跳數(shù)限制，最大值是255.雖然這是一個(gè)跳數(shù)限制而不是一個(gè)真正的時(shí)間限制，但是根據(jù)這個(gè)限制來(lái)假設(shè)數(shù)據(jù)報(bào)的最長(zhǎng)生命周期依然是有意義的。
網(wǎng)絡(luò)中數(shù)據(jù)報(bào)丟失的原因通常是路由異常。一旦路由崩潰或者兩個(gè)路由之間的鏈路斷開(kāi)，路由協(xié)議需要幾秒或幾分鐘才能穩(wěn)定，并找到一條備用路徑。在這段時(shí)間內(nèi)，可能發(fā)生路由回路。同時(shí)假設(shè)丟失是一個(gè)TCP數(shù)據(jù)報(bào)，則發(fā)生TCP超時(shí)，并且重新發(fā)送分組，重傳的分組通過(guò)一些備用路徑達(dá)到最終目的地。但是一段時(shí)間后（該時(shí)間小于MSL），路由循環(huán)被更正，在循環(huán)中丟失的數(shù)據(jù)報(bào)被發(fā)送到最終目的地。這個(gè)原始的數(shù)據(jù)報(bào)被稱(chēng)為丟失的副本或漫游副本。TCP協(xié)議必須處理這些數(shù)據(jù)報(bào)。
維持TIME_WAIT有兩個(gè)原因：
- 可靠地實(shí)現(xiàn)TCP的全雙工連接終止。
- 允許舊的重復(fù)數(shù)據(jù)段在網(wǎng)絡(luò)中過(guò)期
在四次揮手中，假設(shè)最后的ACK丟失了，被動(dòng)關(guān)閉方會(huì)重發(fā)FIN。主動(dòng)關(guān)閉端必須維護(hù)狀態(tài)，來(lái)允許被動(dòng)關(guān)閉方重發(fā)最后的ACK；如果它沒(méi)有維護(hù)這個(gè)狀態(tài)，將會(huì)對(duì)重發(fā)FIN返回RST，被動(dòng)關(guān)閉方會(huì)認(rèn)為這是個(gè)錯(cuò)誤。如果TCP正在執(zhí)行徹底終止數(shù)據(jù)流的兩個(gè)方向所需的所有工作（即全雙工關(guān)閉），則必須正確處理這四個(gè)段中任何一個(gè)的丟失。所以執(zhí)行主動(dòng)關(guān)閉的一方必須在結(jié)束時(shí)保持TIME_WAIT狀態(tài)：因?yàn)樗赡鼙仨氈貍髯詈蟮腁CK。
現(xiàn)在來(lái)聊維持TIME_WAIT狀態(tài)的第二個(gè)原因。假設(shè)在主機(jī)12.106.32.254的1500端口和206.168.112.219的21端口之間有一個(gè)TCP連接。此連接關(guān)閉后，在相通的地址和端口建立了另外一個(gè)連接。由于IP地址和端口相同，所以后一種連接被稱(chēng)為先前連接的“化身”。TCP必須防止連接中的舊副本在稍后再次出現(xiàn)，并被誤解為屬于同一連接的新“化身”。為此，TCP將不會(huì)啟動(dòng)當(dāng)前處于TIME_WAIT狀態(tài)的連接的新“化身”。由于TIME_WAIT狀態(tài)的持續(xù)時(shí)間時(shí)兩倍的MSL，因此TCP允許一個(gè)方向的數(shù)據(jù)在MSL秒內(nèi)丟失，也允許回復(fù)在一個(gè)MSL秒內(nèi)丟失。通過(guò)強(qiáng)制執(zhí)行此規(guī)則，可以保證當(dāng)一個(gè)TCP連接成功建立時(shí)，來(lái)自先前連接的所有舊的副本在網(wǎng)絡(luò)中已過(guò)期。
