簡(jiǎn)介
傳輸控制協(xié)議TCP（Transmission Control Protocol）[RFC 768]澳窑、
TCP（Transmission Control Protocol）可靠的、面向連接的協(xié)議（eg:打電話）、傳輸效率低全雙工通信（發(fā)送緩存&接收緩存）绊袋、面向字節(jié)流能曾。使用TCP的應(yīng)用：Web瀏覽器氧枣；電子郵件、文件傳輸程序依沮。
TCP的連接與釋放
tcp狀態(tài)機(jī)
TCP 所謂的“連接”，只是通信雙方維護(hù)一個(gè)“連接狀態(tài)”枪狂，讓它看上去好像有連接一樣危喉，其實(shí) TCP 連接是虛擬的連接，不是電路連接州疾。首先看下 TCP 的狀態(tài)機(jī)辜限，狀態(tài)機(jī)是 TCP 連接與釋放的全過程。如下圖所示：
- CLOSED：表示初始狀態(tài)严蓖。對(duì)服務(wù)端和客戶端雙方都一樣薄嫡。
- LISTEN：表示監(jiān)聽狀態(tài)。服務(wù)端調(diào)用了 listen 函數(shù)使其處于監(jiān)聽狀態(tài)颗胡，此時(shí)可以開始 accept （接收）客戶端的連接毫深。
- SYN_SENT：表示客戶端已經(jīng)發(fā)送了 SYN 報(bào)文段，則會(huì)處于該狀態(tài)毒姨。當(dāng)客戶端調(diào)用 * connect 函數(shù)發(fā)起連接請(qǐng)求時(shí)哑蔫，首先發(fā) SYN 給服務(wù)端，然后自己進(jìn)入 SYN_SENT 狀態(tài)弧呐，并等待服務(wù)端發(fā)送 ACK+SYN 作為請(qǐng)求應(yīng)答闸迷。
- SYN_RCVD：表示服務(wù)端收到客戶端發(fā)送 SYN 報(bào)文段。服務(wù)端收到這個(gè)報(bào)文段后俘枫，進(jìn)入 SYN_RCVD 狀態(tài)腥沽，然后發(fā)送 ACK+SYN 給客戶端。
- ESTABLISHED：表示 TCP 連接已經(jīng)成功建立崩哩，通信雙方可以開始傳輸數(shù)據(jù)巡球。服務(wù)端發(fā)送完 ACK+SYN 并收到來自客戶端的 ACK 后進(jìn)入該狀態(tài)，客戶端收到來自服務(wù)器的 SYN+ACK 并發(fā)送 ACK 后也進(jìn)入該狀態(tài)邓嘹。
- FIN_WAIT_1：表示主動(dòng)關(guān)閉連接酣栈。無論哪方調(diào)用 close 函數(shù)發(fā)送 FIN 報(bào)文都會(huì)進(jìn)入這個(gè)這個(gè)狀態(tài)。
- FIN_WAIT_2：表示被動(dòng)關(guān)閉方同意關(guān)閉連接汹押。主動(dòng)關(guān)閉連接方收到被動(dòng)關(guān)閉方返回的 ACK 后矿筝，會(huì)進(jìn)入該狀態(tài)。
- TIME_WAIT：表示收到對(duì)方的 FIN 報(bào)文并發(fā)送了 ACK 報(bào)文棚贾，就等 2MSL 后即可回到 CLOSED 狀態(tài)了窖维。如果 FIN_WAIT_1 狀態(tài)下榆综，收到對(duì)方同時(shí)帶 FIN 標(biāo)志和 ACK 標(biāo)志的報(bào)文時(shí)，可以直接進(jìn)入 TIME_WAIT 狀態(tài)铸史，而無須經(jīng)過 FIN_WAIT_2 狀態(tài)鼻疮。
- CLOSING：表示雙方同時(shí)關(guān)閉連接。如果雙方幾乎同時(shí)調(diào)用 close 函數(shù)琳轿，那么會(huì)出現(xiàn)雙方同時(shí)發(fā)送 FIN 報(bào)文的情況判沟，就會(huì)出現(xiàn) CLOSING 狀態(tài)，表示雙方都在關(guān)閉連接崭篡。
- CLOSE_WAIT：表示被動(dòng)關(guān)閉方等待關(guān)閉挪哄。當(dāng)收到對(duì)方調(diào)用 close 函數(shù)發(fā)送的 FIN 報(bào)文時(shí)，回應(yīng)對(duì)方 ACK 報(bào)文琉闪，此時(shí)進(jìn)入 CLOSE_WAIT 狀態(tài)迹炼。
- LAST_ACK：表示被動(dòng)關(guān)閉方發(fā)送 FIN 報(bào)文后，等待對(duì)方的 ACK 報(bào)文狀態(tài)颠毙，當(dāng)收到 ACK 后進(jìn)入CLOSED狀態(tài)斯入。
tcp連接與釋放
TCP 是面向連接的、可靠的字節(jié)流協(xié)議吟秩。因此咱扣，在傳輸數(shù)據(jù)之前通信雙方必須建立一個(gè) TCP 連接，建立 TCP 連接需要在服務(wù)器和客戶端之間進(jìn)行三次握手涵防。通信雙方數(shù)據(jù)傳輸完畢之后進(jìn)行連接釋放闹伪，釋放連接需要在通信雙方之間進(jìn)行四次揮手。
三次握手
TCP 連接的正常建立過程通信雙方需要三次握手壮池，其過程如下圖所示：
TCP 協(xié)議提供可靠的連接服務(wù)偏瓤，采用有保障的三次握手方式來創(chuàng)建一個(gè) TCP 連接。三次握手的具體過程如下：
1椰憋、客戶端進(jìn)程向服務(wù)端發(fā)出連接請(qǐng)求厅克，請(qǐng)求報(bào)文的報(bào)文段首部中的控制位標(biāo)志 SYN=1（有關(guān) TCP 控制位信息參考《TCP 協(xié)議》），由于是首次請(qǐng)求建立連接橙依，因此证舟，控制位標(biāo)志 ACK=0，該報(bào)文段包含計(jì)算機(jī)隨機(jī)生成的初始序號(hào) seq=x窗骑。發(fā)送請(qǐng)求連接的 TCP 報(bào)文段女责，此時(shí)客戶端進(jìn)程進(jìn)入 SYN_SENT 狀態(tài)，這是 TCP 連接的第一次握手创译。
2抵知、服務(wù)端收到客戶端發(fā)來的請(qǐng)求報(bào)文后，若同意建立連接，則向客戶端發(fā)送確認(rèn)刷喜。確認(rèn)報(bào)文中的控制位 SYN=1残制，ACK=1，確認(rèn)應(yīng)答號(hào) ack=x+1（即在接收到序列號(hào)值基礎(chǔ)上加 1 ）掖疮，并且發(fā)送自己的一個(gè)初始序列號(hào) seq=y（即請(qǐng)求與客戶端連接）初茶。此時(shí)，服務(wù)端進(jìn)入SYN_RCVD狀態(tài)浊闪，這是TCP連接的第二次握手纺蛆。
3、客戶端進(jìn)程收到服務(wù)端進(jìn)程的確認(rèn)報(bào)文后规揪，還要向服務(wù)端發(fā)出確認(rèn)信息。確認(rèn)報(bào)文段的控制位 ACK=1温峭，確認(rèn)應(yīng)答號(hào) ack=y+1（即在接收到序列號(hào)值基礎(chǔ)上加 1 ）猛铅，此時(shí)，客戶端進(jìn)入 ESTABLISHED 狀態(tài)凤藏。服務(wù)器收到來自客戶端的確認(rèn)應(yīng)答信息也進(jìn)入 ESTABLISHED 狀態(tài)奸忽。這是TCP連接的第三次握手。此時(shí)揖庄，TCP 連接成功建立栗菜。
四次揮手
由于 TCP 連接是全雙工的，因此每個(gè)方向都必須單獨(dú)進(jìn)行關(guān)閉蹄梢。原則是主動(dòng)關(guān)閉的一方發(fā)送一個(gè) FIN 報(bào)文來表示終止這個(gè)方向的連接疙筹，收到一個(gè) FIN 意味著這個(gè)方向不再有數(shù)據(jù)流動(dòng)，但另一個(gè)方向仍能繼續(xù)發(fā)送數(shù)據(jù)禁炒，直到另一個(gè)方向也發(fā)送 FIN 報(bào)文而咆。TCP 連接釋放的過程如下圖所示：
以下是釋放連接的四次揮手過程：
1、客戶端進(jìn)程主動(dòng)向服務(wù)端發(fā)出連接釋放請(qǐng)求報(bào)文段幕袱，并停止發(fā)送數(shù)據(jù)暴备，主動(dòng)關(guān)閉 TCP 連接。釋放連接報(bào)文段中控制位 FIN=1们豌，序列號(hào)為 seq=i涯捻，發(fā)送該報(bào)文段之后客戶端進(jìn)入FIN_WAIT_1（終止等待1）狀態(tài)，等待服務(wù)器的確認(rèn)望迎。這是 TCP 連接釋放的第一次揮手障癌。
2、服務(wù)器收到連接釋放請(qǐng)求報(bào)文段后即發(fā)出確認(rèn)釋放連接的報(bào)文段擂煞，該報(bào)文段中控制位 ACK=1混弥，確認(rèn)應(yīng)答號(hào)為 ack=i+1，然后服務(wù)器進(jìn)入CLOSE_WAIT（關(guān)閉等待）狀態(tài)。此時(shí) TCP 處于半關(guān)閉狀態(tài)蝗拿，即客戶端已經(jīng)不向服務(wù)器發(fā)送數(shù)據(jù)晾捏，但服務(wù)器仍可向客戶端發(fā)送數(shù)據(jù)。這是TCP連接釋放的第二次揮手哀托。
3惦辛、客戶端收到服務(wù)器的確認(rèn)信息后，就進(jìn)入了FIN_WAIT_2（終止等待2）狀態(tài)仓手，等待服務(wù)器發(fā)出連接釋放請(qǐng)求報(bào)文段胖齐，若沒有數(shù)據(jù)需要傳輸，服務(wù)器被動(dòng)向客戶端發(fā)出鏈接釋放請(qǐng)求報(bào)文段中嗽冒，報(bào)文段中控制位 FIN=1呀伙，序列號(hào) seq=j，此時(shí)服務(wù)器進(jìn)入LAST_ACK（最后確認(rèn)）狀態(tài)添坊，等待客戶端的確認(rèn)應(yīng)答剿另。這是 TCP 連接釋放的第三次揮手。
4贬蛙、客戶端收到服務(wù)器的連接釋放請(qǐng)求后雨女，必須對(duì)此發(fā)出確認(rèn)。確認(rèn)報(bào)文段中控制位 ACK=1阳准，確認(rèn)應(yīng)答號(hào) ack=j+1氛堕，客戶端發(fā)出確認(rèn)應(yīng)答信息之后后進(jìn)入TIME_WAIT（時(shí)間等待）狀態(tài)。在這段時(shí)間內(nèi) TCP連接并沒有釋放野蝇，必須等待 2MSL 時(shí)間后讼稚，客戶端才進(jìn)入 CLOSED 狀態(tài)。服務(wù)器收到了客戶端的確認(rèn)應(yīng)答后浪耘，就進(jìn)入了 CLOSED 狀態(tài)乱灵。直到客戶端和服務(wù)器都進(jìn)入 CLOSED 狀態(tài)后，連接就完全釋放了七冲，這是TCP連接釋放的第四次揮手痛倚。
從上面可以知道，tcp的3次握手澜躺，4次揮手保證了數(shù)據(jù)的可靠性蝉稳。而udp為非面向連接協(xié)議并不能保證數(shù)據(jù)的可靠性。所以說tcp是安全可靠的掘鄙，而udp是不可靠的耘戚。當(dāng)然tcp保證數(shù)據(jù)可靠的原因不光是面向連接。
tcp報(bào)文結(jié)構(gòu)
TCP 報(bào)文 (Segment)操漠，包括首部和數(shù)據(jù)部分收津。
下圖是把 TCP 報(bào)文中的首部放大來看饿这。
源端口 source port
目的端口 destination port
序號(hào) sequence number
確認(rèn)號(hào) acknowledgment number
數(shù)據(jù)偏移 offset
保留 reserved
標(biāo)志位 tcp flags
窗口大小 window size
檢驗(yàn)和 checksum
緊急指針 urgent pointer
選項(xiàng) tcp options
確認(rèn)號(hào)
占 4 個(gè)字節(jié)。
表示期望收到對(duì)方下一個(gè)報(bào)文段的序號(hào)值撞秋。
TCP 的可靠性长捧，是建立在「每一個(gè)數(shù)據(jù)報(bào)文都需要確認(rèn)收到」的基礎(chǔ)之上的。
就是說吻贿，通訊的任何一方在收到對(duì)方的一個(gè)報(bào)文之后串结，都要發(fā)送一個(gè)相對(duì)應(yīng)的「確認(rèn)報(bào)文」，來表達(dá)確認(rèn)收到舅列。
那么肌割，確認(rèn)報(bào)文，就會(huì)包含確認(rèn)號(hào)帐要。
窗口大小 Window Size
該字段明確指出了現(xiàn)在允許對(duì)方發(fā)送的數(shù)據(jù)量把敞，它告訴對(duì)方本端的 TCP 接收緩沖區(qū)還能容納多少字節(jié)的數(shù)據(jù)，這樣對(duì)方就可以控制發(fā)送數(shù)據(jù)的速度榨惠。
窗口大小的值是指先巴，從本報(bào)文段首部中的確認(rèn)號(hào)算起，接收方目前允許對(duì)方發(fā)送的數(shù)據(jù)量冒冬。
例如，假如確認(rèn)號(hào)是 701 摩渺，窗口字段是 1000简烤。這就表明，從 701 號(hào)算起摇幻，發(fā)送此報(bào)文段的一方還有接收 1000 （字節(jié)序號(hào)是 701 ~ 1700） 個(gè)字節(jié)的數(shù)據(jù)的接收緩存空間横侦。
校驗(yàn)和
由發(fā)送端填充，接收端對(duì) TCP 報(bào)文段執(zhí)行 CRC 算法绰姻，以檢驗(yàn) TCP 報(bào)文段在傳輸過程中是否損壞枉侧，如果損壞這丟棄。
檢驗(yàn)范圍包括首部和數(shù)據(jù)兩部分狂芋，這也是 TCP 可靠傳輸?shù)囊粋€(gè)重要保障榨馁。
TCP可靠性實(shí)現(xiàn)
除了依靠連接過程的三次握手，tcp還有機(jī)制來保證傳輸?shù)臄?shù)據(jù)帜矾，無差錯(cuò)翼虫、不丟失、不重復(fù)屡萤、并且按序到達(dá)
1.超時(shí)重傳機(jī)制
TCP 報(bào)文段在傳輸?shù)倪^程中珍剑，下面的情況都是有可能發(fā)生的：
數(shù)據(jù)包中途丟失；
數(shù)據(jù)包順利到達(dá)死陆，但對(duì)方發(fā)送的 ACK 報(bào)文中途丟失招拙；
數(shù)據(jù)包順利到達(dá)，但對(duì)方異常未響應(yīng) ACK 或被對(duì)方丟棄；
當(dāng)出現(xiàn)這些異常情況時(shí)别凤，TCP 就會(huì)超時(shí)重傳饰序。
TCP 每發(fā)送一個(gè)報(bào)文段，就對(duì)這個(gè)報(bào)文段設(shè)置一次計(jì)時(shí)器闻妓。只要計(jì)時(shí)器設(shè)置的重傳時(shí)間到了菌羽，但還沒有收到確認(rèn)，就重傳這一報(bào)文段由缆，這個(gè)就叫做「超時(shí)重傳」注祖。
2.滑動(dòng)窗口 Sliding Window
TCP 頭里有一個(gè)字段叫 Window，叫 Advertised-Window均唉，這個(gè)字段是接收端告訴發(fā)送端自己還有多少緩沖區(qū)可以接收數(shù)據(jù)是晨。于是發(fā)送端就可以根據(jù)這個(gè)接收端的處理能力來發(fā)送數(shù)據(jù)，而不會(huì)導(dǎo)致接收端處理不過來舔箭。
滑動(dòng)窗口分為「接收窗口」和「發(fā)送窗口」
因?yàn)?TCP 協(xié)議是全雙工的罩缴，會(huì)話的雙方都可以同時(shí)接收和發(fā)送，那么就需要各自維護(hù)一個(gè)「發(fā)送窗口」和「接收窗口」层扶。
發(fā)送窗口
大小取決于對(duì)端通告的接受窗口箫章。
只有收到對(duì)端對(duì)于本端發(fā)送窗口內(nèi)字節(jié)的 ACK 確認(rèn)，才會(huì)移動(dòng)發(fā)送窗口的左邊界镜会。
對(duì)于發(fā)送窗口檬寂，在緩存內(nèi)的數(shù)據(jù)有四種狀態(tài)：
#1 已發(fā)送，并得到接收方 ACK 確認(rèn)戳表；
#2 已發(fā)送桶至，但還未收到接收方 ACK；
#3 未發(fā)送匾旭，但接收方允許發(fā)送镣屹，接收方還有空間
#4 未發(fā)送，且接收方不允許發(fā)送价涝，接收方?jīng)]有空間
如果下一刻女蜈，收到了接收方對(duì)于 32-36 字節(jié)序的數(shù)據(jù)包的 ACK 確認(rèn)，那么發(fā)送方的窗口就會(huì)發(fā)生「滑動(dòng)」色瘩。
并且發(fā)送下一個(gè) 46-51 字節(jié)序的數(shù)據(jù)包鞭光。
接收窗口
大小取決于應(yīng)用、系統(tǒng)泞遗、硬件的限制惰许。
相對(duì)于發(fā)送窗口，接受窗口在緩存內(nèi)的數(shù)據(jù)只有三種狀態(tài)：
- 已接收已確認(rèn)史辙；
- 未接收汹买，準(zhǔn)備接收佩伤；
- 未接收，并未準(zhǔn)備接收晦毙；
下一刻接收到來自發(fā)送端的 32-36 數(shù)據(jù)包生巡，然后回送 ACK 確認(rèn)報(bào)，并且移動(dòng)接收窗口见妒。
另外接收端相對(duì)于發(fā)送端還有不同的一點(diǎn)孤荣，只有前面所有的段都確認(rèn)的情況下才會(huì)移動(dòng)左邊界埋心，
在前面還有字節(jié)未接收但收到后面字節(jié)的情況下含长，窗口不會(huì)移動(dòng)，并不對(duì)后續(xù)字節(jié)確認(rèn)鲫寄，以此確保對(duì)端會(huì)對(duì)這些數(shù)據(jù)重傳耻卡。
假如 32-36 字節(jié)不是一個(gè)報(bào)文段的疯汁，而是每個(gè)字節(jié)一個(gè)報(bào)文段的話，那么就會(huì)分成了 5 個(gè)報(bào)文段卵酪。
在實(shí)際的網(wǎng)絡(luò)環(huán)境中幌蚊，不能確保是按序收到的，其中會(huì)有一些早達(dá)到溃卡，一些遲到達(dá)溢豆。
如圖中的 34、35 字節(jié)序瘸羡，先收到了沫换，接收窗口也不會(huì)移動(dòng)。
因?yàn)橛锌赡?32最铁、33 字節(jié)序會(huì)出現(xiàn)丟包或者超時(shí)，這時(shí)就需要發(fā)送端重發(fā)報(bào)文段了垮兑。
3.檢驗(yàn)和
TCP將保持它首部和數(shù)據(jù)的檢驗(yàn)和冷尉。這是一個(gè)端到端的檢驗(yàn)和，目的是檢測(cè)數(shù)據(jù)在傳輸 過程中的任何變化系枪。如果收到段的檢驗(yàn)和有差錯(cuò)雀哨， T P將丟棄這個(gè)報(bào)文段和不確認(rèn)收到此報(bào)文段（希望發(fā)端超時(shí)并重發(fā)）。
4.擁塞控制
擁塞控制：防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中私爷，這樣可以使網(wǎng)絡(luò)中的路由器或鏈路不致過載雾棺。擁塞控制所要做的都有一個(gè)前提：網(wǎng)絡(luò)能夠承受現(xiàn)有的網(wǎng)絡(luò)負(fù)荷。擁塞控制是一個(gè)全局性的過程衬浑，涉及到所有的主機(jī)捌浩、路由器，以及與降低網(wǎng)絡(luò)傳輸性能有關(guān)的所有因素
幾種擁塞控制方法
慢開始( slow-start )工秩、擁塞避免( congestion avoidance )尸饺、快重傳( fast retransmit )和快恢復(fù)( fast recovery )进统。
具體算法參考：這里
tcp相關(guān)疑問
問：為什么在 TCP 協(xié)議里，建立連接是三次握手浪听，而關(guān)閉連接卻是四次握手?
因?yàn)楫?dāng)處于 LISTEN 狀態(tài)的服務(wù)器端收到來自客戶端的 SYN 報(bào)文(客戶端希望新建一個(gè)TCP連接)時(shí)螟碎，它可以把 ACK (確認(rèn)應(yīng)答)和 SYN (同步序號(hào))放在同一個(gè)報(bào)文里來發(fā)送給客戶端。但在關(guān)閉 TCP 連接時(shí)迹栓，當(dāng)收到對(duì)方的 FIN 報(bào)文時(shí)掉分，對(duì)方僅僅表示對(duì)方已經(jīng)沒有數(shù)據(jù)發(fā)送給你了，但是你自己可能還有數(shù)據(jù)需要發(fā)送給對(duì)方克伊，則等你發(fā)送完剩余的數(shù)據(jù)給對(duì)方之后酥郭，再發(fā)送 FIN 報(bào)文給對(duì)方來表示你數(shù)據(jù)已經(jīng)發(fā)送完畢，并請(qǐng)求關(guān)閉連接答毫，所以通常情況下褥民，這里的 ACK 報(bào)文和 FIN 報(bào)文都是分開發(fā)送的。
問：為什么一定要進(jìn)行三次握手洗搂？
當(dāng)客戶端向服務(wù)器端發(fā)送一個(gè)連接請(qǐng)求時(shí)消返，由于某種原因長(zhǎng)時(shí)間駐留在網(wǎng)絡(luò)節(jié)點(diǎn)中，無法達(dá)到服務(wù)器端耘拇，由于 TCP 的超時(shí)重傳機(jī)制撵颊，當(dāng)客戶端在特定的時(shí)間內(nèi)沒有收到服務(wù)器端的確認(rèn)應(yīng)答信息，則會(huì)重新向服務(wù)器端發(fā)送連接請(qǐng)求惫叛，且該鏈接請(qǐng)求得到服務(wù)器端的響應(yīng)并正常建立連接倡勇，進(jìn)而傳輸數(shù)據(jù)，當(dāng)數(shù)據(jù)傳輸完畢嘉涌，并釋放了此次 TCP 連接妻熊。若此時(shí)第一次發(fā)送的連接請(qǐng)求報(bào)文段延遲了一段時(shí)間后，到達(dá)了服務(wù)器端仑最，本來這是一個(gè)早已失效的報(bào)文段扔役，但是服務(wù)器端收到該鏈接請(qǐng)求后誤以為客戶端又發(fā)出了一次新的連接請(qǐng)求，于是服務(wù)器端向客戶端發(fā)出確認(rèn)應(yīng)答報(bào)文段警医，并同意建立連接亿胸。如果沒有采用三次握手建立連接，由于服務(wù)器端發(fā)送了確認(rèn)應(yīng)答信息预皇，則表示新的連接已成功建立侈玄，但是客戶端此時(shí)并沒有向服務(wù)器端發(fā)出任何連接請(qǐng)求，因此客戶端忽略服務(wù)器端的確認(rèn)應(yīng)答報(bào)文吟温，更不會(huì)向服務(wù)器端傳輸數(shù)據(jù)序仙。而服務(wù)器端卻認(rèn)為新的連接已經(jīng)建立了，并在一直等待客戶端發(fā)送數(shù)據(jù)鲁豪，這樣服務(wù)器端一直處于等待接收數(shù)據(jù)诱桂，直到超出計(jì)數(shù)器的設(shè)定值洋丐，則認(rèn)為客戶端出現(xiàn)異常，并且關(guān)閉這個(gè)連接挥等。在這個(gè)等待的過程中友绝，浪費(fèi)服務(wù)器的資源。如果采用三次握手肝劲，客戶端就不會(huì)向服務(wù)端發(fā)出確認(rèn)應(yīng)答信息迁客，服務(wù)器端由于沒有收到客戶端的確認(rèn)應(yīng)答信息，從而判定客戶端并沒有請(qǐng)求建立連接辞槐，從而不建立該連接掷漱。
問：為什么需要在 TIME_WAIT 狀態(tài)必須等待 2MSL 時(shí)間，而不直接給進(jìn)入 CLOSED 狀態(tài)榄檬？
TIME_WAIT 確保有足夠的時(shí)間讓對(duì)端收到了ACK卜范，如果被動(dòng)關(guān)閉的那方?jīng)]有收到 ACK，就會(huì)觸發(fā)被動(dòng)端重發(fā) FIN鹿榜。因?yàn)樽詈笠淮未_認(rèn)應(yīng)答 ACK 報(bào)文段很有可能丟失海雪，因而使被動(dòng)關(guān)閉方處于在LAST_ACK 狀態(tài)的，此時(shí)被動(dòng)關(guān)閉方會(huì)重發(fā)這個(gè) FIN+ACK 報(bào)文段舱殿，在這等待的 2MSL 時(shí)間內(nèi)主動(dòng)關(guān)閉方重新收到這個(gè)被動(dòng)關(guān)閉方重發(fā)的 FIN+ACK 報(bào)文段奥裸，因此，主動(dòng)關(guān)閉方會(huì)重新發(fā)送確認(rèn)應(yīng)答信息沪袭，從而重新啟動(dòng) 2MSL 計(jì)時(shí)器湾宙，直到通信雙方都進(jìn)入 CLOSED 狀態(tài)。如果主動(dòng)關(guān)閉方在 TIME_WAIT 狀態(tài)不等待一段時(shí)間就直接釋放連接并進(jìn)入 CLOSED 狀態(tài)冈绊，那么主動(dòng)關(guān)閉方無法收到來自被動(dòng)關(guān)閉方重發(fā)的 FIN+ACK 報(bào)文段侠鳄，也就不會(huì)再發(fā)送一次確認(rèn) ACK 報(bào)文段，因此被動(dòng)關(guān)閉方就無法正常進(jìn)入CLOSED 狀態(tài)死宣。
有足夠的時(shí)間讓這個(gè)連接不會(huì)跟后面的連接混在一起伟恶。防止已失效的請(qǐng)求連接出現(xiàn)在本連接中。在連接處于 2MSL 等待時(shí)十电，任何遲到的報(bào)文段將被丟棄，因?yàn)樘幱?2MSL等待的叹螟、由該插口（插口是IP和端口對(duì)的意思鹃骂，socket）定義的連接在這段時(shí)間內(nèi)將不能被再用，這樣就可以使下一個(gè)新的連接中不會(huì)出現(xiàn)這種舊的連接之前延遲的報(bào)文段罢绽。
