2、全部11種狀態(tài)

????2.1、客戶端獨(dú)有的：（1）SYN_SENT?（2）FIN_WAIT1?（3）FIN_WAIT2?（4）CLOSING?（5）TIME_WAIT?。

????2.2、服務(wù)器獨(dú)有的：（1）LISTEN?（2）SYN_RCVD?（3）CLOSE_WAIT?（4）LAST_ACK?。

????2.3、共有的：（1）CLOSED?（2）ESTABLISHED?。

TCP狀態(tài)遷移

大家對(duì)netstat -a命令很熟悉，但是，你有沒有注意到STATE一欄呢，基本上顯示著established,time_wait,close_wait等，這些到底是 什么意思呢，在這篇文章，我將會(huì)詳細(xì)的闡述。

大家很明白TCP初始化連接三次握手吧：發(fā)SYN包，然后返回SYN/ACK包，再發(fā)ACK包，連接正式建立。但是這里有點(diǎn)出入，當(dāng)請(qǐng)求者收到SYS /ACK包后，就開始建立連接了，而被請(qǐng)求者第三次握手結(jié)束后才建立連接。但是大家明白關(guān)閉連接的工作原理嗎？關(guān)閉連接要四次握手：發(fā)FIN包，ACK?包，FIN包，ACK包，四次握手！！為什么呢，因?yàn)?/span>TCP連接是全雙工，我關(guān)了你的連接，并不等于你關(guān)了我的連接。

客戶端TCP狀態(tài)遷移：

CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED

服務(wù)器TCP狀態(tài)遷移：

CLOSED->LISTEN->SYN收到?->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED

當(dāng)客戶端開始連接時(shí)，服務(wù)器還處于LISTENING，

客戶端發(fā)一個(gè)SYN包后，他就處于SYN_SENT狀態(tài),服務(wù)器就處于SYS收到狀態(tài),

然后互相確認(rèn)進(jìn)入連接狀態(tài)ESTABLISHED.

當(dāng)客戶端請(qǐng)求關(guān)閉連接時(shí),客戶端發(fā)送一個(gè)FIN包后,客戶端就進(jìn)入FIN_WAIT_1狀態(tài),等待對(duì)方的確認(rèn)包,

服務(wù)器發(fā)送一個(gè)ACK包給客戶,客戶端收到ACK包后結(jié)束FIN_WAIT_1狀態(tài),進(jìn)入FIN_WAIT_2狀態(tài),等待服務(wù)器發(fā)過來的關(guān)閉請(qǐng)求,

服務(wù)器發(fā)一個(gè)FIN包后,進(jìn)入CLOSE_WAIT狀態(tài),

當(dāng)客戶端收到服務(wù)器的FIN包,FIN_WAIT_2狀態(tài)就結(jié)束,然后給服務(wù)器端的FIN包給以一個(gè)確認(rèn)包,客戶端這時(shí)進(jìn)入TIME_WAIT,

當(dāng)服務(wù)器收到確認(rèn)包后,CLOSE_WAIT狀態(tài)結(jié)束了,

這時(shí)候服務(wù)器端真正的關(guān)閉了連接.但是客戶端還在TIME_WAIT狀態(tài)下,

什么時(shí)候結(jié)束呢.我在這里再講到一個(gè)新名詞:2MSL等待狀態(tài),其實(shí)TIME_WAIT就是2MSL等待狀態(tài),

為什么要設(shè)置這個(gè)狀態(tài),原因是有足夠的時(shí)間讓ACK包到達(dá)服務(wù)器端,如果服務(wù)器端沒收到ACK包，超時(shí)了，然后重新發(fā)一個(gè)FIN包，直到服務(wù)器收到ACK?包.

TIME_WAIT狀態(tài)等待時(shí)間是在TCP重新啟動(dòng)后不連接任何請(qǐng)求的兩倍.

大家有沒有發(fā)現(xiàn)一個(gè)問題:如果對(duì)方在第三次握手的時(shí)候出問題,如發(fā)FIN包的時(shí)候,不知道什么原因丟了這個(gè)包,然而這邊一直處在FIN_WAIT_2狀 態(tài),而且TCP/IP并沒有設(shè)置這個(gè)狀態(tài)的過期時(shí)間,那他一直會(huì)保留這個(gè)狀態(tài)下去,越來越多的FIN_WAIT_2狀態(tài)會(huì)導(dǎo)致系統(tǒng)崩潰.

上面我碰到的這個(gè)問題主要因?yàn)?/span>TCP的結(jié)束流程未走完，造成連接未釋放。現(xiàn)設(shè)客戶端主動(dòng)斷開連接，流程如下:

Client 消息 Server ?close() ------?FIN?-------> FIN_WAIT1 CLOSE_WAIT <-----?ACK?------- FIN_WAIT2? close() <------?FIN?------? TIME_WAIT LAST_ACK? ?------?ACK?------->? CLOSED CLOSED

由于Server的Socket在客戶端已經(jīng)關(guān)閉時(shí)而沒有調(diào)用關(guān)閉，

造成服務(wù)器端的連接處在“掛起”狀態(tài)，而客戶端則處在等待應(yīng)答的狀態(tài)上。

此問題的典型特征是：

一端處于FIN_WAIT2?，而另一端處于CLOSE_WAIT.

不過，根本問題還是程序?qū)懙牟缓?#xff0c;有待提高

-------------------------------------------------------------------------

CLOSE_WAIT，TCP的癌癥，TCP的朋友。

CLOSE_WAIT狀態(tài)的生成原因

首先我們知道，如果我們的服務(wù)器程序APACHE處于CLOSE_WAIT狀態(tài)的話，說明套接字是被動(dòng)關(guān)閉的！

因?yàn)槿绻?/span>CLIENT端主動(dòng)斷掉當(dāng)前連接的話，那么雙方關(guān)閉這個(gè)TCP連接共需要四個(gè)packet：

Client ---> FIN ---> Server

Client <--- ACK <--- Server

這時(shí)候Client端處于FIN_WAIT_2狀態(tài)；而Server?程序處于CLOSE_WAIT狀態(tài)。

Client <--- FIN <--- Server

這時(shí)Server?發(fā)送FIN給Client，Server?就置為LAST_ACK狀態(tài)。

Client ---> ACK ---> Server

Client回應(yīng)了ACK，那么Server?的套接字才會(huì)真正置為CLOSED狀態(tài)。

Server?程序處于CLOSE_WAIT狀態(tài)，而不是LAST_ACK狀態(tài)，說明還沒有發(fā)FIN給Client，那么可能是在關(guān)閉連接之前還有許多數(shù)據(jù)要發(fā)送或者其 他事要做，導(dǎo)致沒有發(fā)這個(gè)FIN packet。

通常來說，一個(gè)CLOSE_WAIT會(huì)維持至少2個(gè)小時(shí)的時(shí)間。如果有個(gè)流氓特地寫了個(gè)程序，給你造成一堆的?CLOSE_WAIT，消耗你的資源，那么通常是等不到釋放那一刻，系統(tǒng)就已經(jīng)解決崩潰了。

只能通過修改一下TCP/IP的參數(shù)，來縮短這個(gè)時(shí)間：修改tcp_keepalive_*系列參數(shù)有助于解決這個(gè) 問題。

解決這個(gè)問題的方法是修改系統(tǒng)的參數(shù)，系統(tǒng)默認(rèn)超時(shí)時(shí)間的是7200秒，也就是2小時(shí)， 這個(gè)太大了，可以修改如下幾個(gè)參數(shù)：

sysctl?-w net.ipv4.tcp_keepalive_time=30 sysctl?-w net.ipv4.tcp_keepalive_probes=2 sysctl?-w net.ipv4.tcp_keepalive_intvl=2

然后，執(zhí)行sysctl命令使修改生效。

連接進(jìn)程是通過一系列狀態(tài)表示的，這些狀態(tài)有：

LISTEN，SYN-SENT，SYN-RECEIVED，ESTABLISHED，FIN-WAIT-1，FIN-WAIT-2，CLOSE-?WAIT，CLOSING，LAST-ACK，TIME-WAIT和CLOSED

各個(gè)狀態(tài)的意義如下：?

LISTEN -?偵聽來自遠(yuǎn)方TCP端口的連接請(qǐng)求；?

SYN-SENT -在發(fā)送連接請(qǐng)求后等待匹配的連接請(qǐng)求；?

SYN-RECEIVED -?在收到和發(fā)送一個(gè)連接請(qǐng)求后等待對(duì)連接請(qǐng)求的確認(rèn)；?

ESTABLISHED-?代表一個(gè)打開的連接，數(shù)據(jù)可以傳送給用戶；?

FIN-WAIT-1 -?等待遠(yuǎn)程TCP的連接中斷請(qǐng)求，或先前的連接中斷請(qǐng)求的確認(rèn)；

FIN-WAIT-2 -?從遠(yuǎn)程TCP等待連接中斷請(qǐng)求；?

CLOSE-WAIT -?等待從本地用戶發(fā)來的連接中斷請(qǐng)求；?

CLOSING -等待遠(yuǎn)程TCP對(duì)連接中斷的確認(rèn)；?

LAST-ACK -?等待原來發(fā)向遠(yuǎn)程TCP的連接中斷請(qǐng)求的確認(rèn)；?

TIME-WAIT -等待足夠的時(shí)間以確保遠(yuǎn)程TCP接收到連接中斷請(qǐng)求的確認(rèn)；?

CLOSED -?沒有任何連接狀態(tài)；

TCP連接過程是狀態(tài)的轉(zhuǎn)換，促使發(fā)生狀態(tài)轉(zhuǎn)換的是用戶調(diào)用：

OPEN，SEND，RECEIVE，CLOSE，ABORT和STATUS

傳送過來的數(shù)據(jù)段，特別那些包括以下標(biāo)記的數(shù)據(jù)段SYN，ACK，RST和FIN；

還有超時(shí)，上面所說的都會(huì)時(shí)TCP狀態(tài)發(fā)生變化。

這個(gè)圖n多人都 知道，它對(duì)排除和定 位網(wǎng)絡(luò)或系統(tǒng)故障時(shí)大有幫助，但是怎樣牢牢地將這張圖刻在腦中呢？那么你就一定要對(duì) 這張圖的每一個(gè)狀態(tài)，及轉(zhuǎn)換的過程有深刻地認(rèn)識(shí)，不能只停留在一知半解之中。下面對(duì)這張圖的11種狀 態(tài)詳細(xì)解釋一下，以便加強(qiáng)記憶！不過在這之前，先回顧一下TCP建立連接的三次握手過程，以及關(guān)閉連接的四次握手過程。

1、建立連接協(xié)議（三次握手）

（1）客戶 端發(fā)送一個(gè)帶SYN標(biāo)志的TCP報(bào)文到服務(wù)器。這是三次握手過程中的報(bào)文1。

（2） 服務(wù)器端回應(yīng)客戶端的，這是三次握手中的第2個(gè)報(bào)文，這個(gè)報(bào)文同時(shí)帶ACK標(biāo)志和SYN標(biāo) 志。因此它表示對(duì)剛才客戶端SYN報(bào)文的回應(yīng)；同時(shí)又標(biāo)志SYN給客戶端，詢問客戶端是否準(zhǔn)備好進(jìn)行數(shù)據(jù)通 訊。

（3） 客戶必須再次回應(yīng)服務(wù)段一個(gè)ACK報(bào)文，這是報(bào)文段3。

2、連接終止協(xié)議（四次握手）

　 　由于TCP連 接是全雙工的，因此每個(gè)方向都必須單獨(dú)進(jìn)行關(guān)閉。這原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個(gè)FIN來終 止這個(gè)方向的連接。收到一個(gè)?FIN只意味著這一方向上沒有數(shù)據(jù)流動(dòng)，一個(gè)TCP連接 在收到一個(gè)FIN后仍能發(fā)送數(shù)據(jù)。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉，而另一方執(zhí)行被動(dòng)關(guān)閉。

　（1）?TCP客 戶端發(fā)送一個(gè)FIN，用來關(guān)閉客戶到服務(wù)器的數(shù)據(jù)傳送（報(bào)文段4）。

　（2） 服務(wù)器收到這個(gè)FIN，它發(fā)回一個(gè)ACK，確認(rèn)序號(hào)為收到的序號(hào)加1（報(bào)文段5）。和SYN一 樣，一個(gè)FIN將占用一個(gè)序號(hào)。

　（3） 服務(wù)器關(guān)閉客戶端的連接，發(fā)送一個(gè)FIN給客戶端（報(bào)文段6）。

　（4） 客戶段發(fā)回ACK報(bào)文確認(rèn)，并將確認(rèn)序號(hào)設(shè)置為收到序號(hào)加1（報(bào)文段7）。

CLOSED:?這個(gè)沒什么好說的了，表示初始狀態(tài)。

LISTEN:?這個(gè)也是非常容易理解的一個(gè)狀態(tài)，表示服務(wù)器端的某個(gè)SOCKET處 于監(jiān)聽狀態(tài)，可以接受連接了。

SYN_RCVD:?這個(gè)狀態(tài)表示接受到了SYN報(bào) 文，在正常情況下，這個(gè)狀態(tài)是服務(wù)器端的SOCKET在建立TCP連接時(shí)的三次握手會(huì)話過程中的一個(gè)中間狀態(tài)，很短暫，基本上用netstat你是很難看到這種狀態(tài)的，除非你特意寫了一個(gè)客戶端測(cè)試程序，故意將三次TCP握手 過程中最后一個(gè)ACK報(bào)文不予發(fā)送。因此這種狀態(tài)時(shí)，當(dāng)收到客戶端的ACK報(bào)文 后，它會(huì)進(jìn)入到ESTABLISHED狀態(tài)。

SYN_SENT:?這個(gè)狀態(tài)與SYN_RCVD遙想呼應(yīng)，當(dāng)客戶端SOCKET執(zhí)行CONNECT連接時(shí)，它首先發(fā)送SYN報(bào)文，因此也隨即它會(huì)進(jìn)入到了SYN_SENT狀態(tài)，并等待服務(wù)端的發(fā)送三次握手中的第2個(gè)報(bào)文。SYN_SENT狀態(tài)表示客戶端已發(fā)送SYN報(bào)文。

ESTABLISHED：這個(gè)容易理解了，表示連接已經(jīng)建立了。

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

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

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:?這種狀態(tài)比較特殊，實(shí)際情況中應(yīng)該是很少見，屬于一種比較罕見的例外狀態(tài)。正常情況下，當(dāng)你發(fā) 送FIN報(bào)文后，按理來說是應(yīng)該先收到（或同時(shí)收到）對(duì)方的ACK報(bào) 文，再收到對(duì)方的FIN報(bào)文。但是CLOSING狀態(tài)表示你發(fā)送FIN報(bào)文后，并沒有收到對(duì)方的ACK報(bào) 文，反而卻也收到了對(duì)方的FIN報(bào)文。什么情況下會(huì)出現(xiàn)此種情況呢？其實(shí)細(xì)想一下，也不難得出結(jié)論：那就是如果雙方幾乎在同時(shí)close一 個(gè)SOCKET的話，那么就出現(xiàn)了雙方同時(shí)發(fā)送FIN報(bào)文的情況，也即會(huì)出現(xiàn)CLOSING狀態(tài)，表示雙方都正在關(guān)閉SOCKET連接。

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

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

最后有2個(gè)問題 的回答，我自己分析后的結(jié)論（不一定保證100%正確）

1、?為什么建立連接協(xié)議是三次握手，而關(guān)閉連接卻是四次握手呢？

這是因?yàn)榉?wù)端的LISTEN狀態(tài)下的SOCKET當(dāng)收到SYN報(bào)文的建連請(qǐng)求后，它可以把ACK和SYN（ACK起 應(yīng)答作用，而SYN起同步作用）放在一個(gè)報(bào)文里來發(fā)送。但關(guān)閉連接時(shí)，當(dāng)收到對(duì)方的FIN報(bào)文 通知時(shí)，它僅僅表示對(duì)方?jīng)]有數(shù)據(jù)發(fā)送給你了；但未必你所有的數(shù)據(jù)都全部發(fā)送給對(duì)方了，所以你可以未必會(huì)馬上會(huì)關(guān)閉SOCKET,也即你可能還需要發(fā)送一些數(shù)據(jù)給對(duì)方之后，再發(fā)送FIN報(bào)文給對(duì)方來表示你同意現(xiàn)在可以關(guān)閉連接了，所以它這里的ACK報(bào)文 和FIN報(bào)文多數(shù)情況下都是分開發(fā)送的。

2、?為什么TIME_WAIT狀態(tài)還需要等2MSL后才能返回到CLOSED狀 態(tài)？

這是因?yàn)?#xff1a;雖然雙方 都同意關(guān)閉連接了，而且握手的4個(gè)報(bào)文也都協(xié)調(diào)和發(fā)送完畢，按理可以直接回到CLOSED狀 態(tài)（就好比從SYN_SEND狀態(tài)到ESTABLISH狀態(tài)那樣）；但是因?yàn)槲覀儽仨氁傧刖W(wǎng)絡(luò)是不可靠的，你無法保證你最后發(fā)送的ACK報(bào) 文會(huì)一定被對(duì)方收到，因此對(duì)方處于LAST_ACK狀態(tài)下的SOCKET可能會(huì)因?yàn)槌瑫r(shí)未收到ACK報(bào)文，而重發(fā)FIN報(bào) 文，所以這個(gè)TIME_WAIT狀態(tài)的作用就是用來重發(fā)可能丟失的ACK報(bào) 文，并保證于此。

?? ??斷開連接的時(shí)候， 當(dāng)發(fā)起主動(dòng)關(guān)閉的左邊這方發(fā)送一個(gè)FIN過去后，

右邊被動(dòng)關(guān)閉的這方要回應(yīng)一個(gè)ACK，這個(gè)ACK是TCP回應(yīng)的，而不是應(yīng)用程序發(fā)送的，

此時(shí)，被動(dòng)關(guān)閉的一方就處于CLOSE_WAIT狀態(tài)了。

如果此時(shí)被動(dòng)關(guān)閉的這一方不再繼續(xù)調(diào)用closesocket,那么他就不會(huì)發(fā)送接下來的FIN，導(dǎo)致自己老是處于CLOSE_WAIT。

只有被動(dòng)關(guān)閉的這一方調(diào)用了?closesocket,才會(huì)發(fā)送一個(gè)FIN給主動(dòng)關(guān)閉的這一方，同時(shí)也使得自己的狀態(tài)變遷為LAST_ACK。?

比如被動(dòng)關(guān)閉的是客戶端

當(dāng)對(duì)方調(diào)用closesocket的時(shí)候，你的程序正在?

int?nRet?=?recv(s,....); if?(nRet?==?SOCKET_ERROR) { ?? ?// closesocket(s);  ?? ?return?FALSE; }

很多人就是忘記了那句closesocket，這種代碼太常見了。?

我的理解，

當(dāng)主動(dòng)關(guān)閉的一方發(fā)送FIN到被動(dòng)關(guān)閉這邊后，被動(dòng)關(guān)閉這邊的TCP馬上回應(yīng)一個(gè)ACK過去，同時(shí)向上面應(yīng)用程序提交一個(gè)ERROR，

導(dǎo)致上面的SOCKET的send或者recv返回SOCKET_ERROR.

正常情況下，如果上面在返回SOCKET_ERROR后調(diào)用了closesocket,?那么被動(dòng)關(guān)閉的者一方的TCP就會(huì)發(fā)送一個(gè)FIN過去，自己的狀態(tài)就變遷到LAST_ACK.

服務(wù)器上出現(xiàn)大量的close_wait的例子和解決方法（例子從網(wǎng)上找的，基本差不多）

$?/usr/sbin/lsof?-i?|?grep 6800 $ /usr/sbin/lsof -i | grep 6800 oracle??? 22725 oracle9i??? 3u IPv4 18621468?????? TCP RHEL3:6800 (LISTEN) oracle??? 22725 oracle9i??? 4u IPv4 18621469?????? TCP RHEL3:6800->RHEL3:2174 (CLOSE_WAIT) oracle??? 22725 oracle9i??? 8u IPv4 18621568?????? TCP RHEL3:6800->RHEL3:2175 (CLOSE_WAIT) oracle??? 22725 oracle9i??? 9u IPv4 18621578?????? TCP RHEL3:6800->RHEL3:2176 (CLOSE_WAIT) oracle??? 22726 oracle9i??? 3u IPv4 18621468?????? TCP RHEL3:6800 (LISTEN) oracle??? 22726 oracle9i??? 4u IPv4 18621469?????? TCP RHEL3:6800->RHEL3:2174 (CLOSE_WAIT) oracle??? 22726 oracle9i??? 8u IPv4 18621568?????? TCP RHEL3:6800->RHEL3:2175 (CLOSE_WAIT) oracle??? 22726 oracle9i??? 9u IPv4 18621578?????? TCP RHEL3:6800->RHEL3:2176 (CLOSE_WAIT) $?kill?-9 22725 #?22725,?22726就是使用該6800端口的進(jìn)程號(hào)(PID)。 $?/usr/sbin/lsof?-i?|?grep 6800

進(jìn)程被kill時(shí)，會(huì)釋放占用的所有鏈接句柄。?

該問題的出現(xiàn)原因網(wǎng)上到處都是，也就是Socket的Client端出現(xiàn)異常沒有Close就退出了。

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的TCP十一种状态的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。