本文通過兩個圖來梳理TCP-IP協(xié)議相關(guān)知識。TCP通信過程包括三個步驟：建立TCP連接通道，傳輸數(shù)據(jù)，斷開TCP連接通道。如圖1所示，給出了TCP通信過程的示意圖。

 

 

圖1 TCP 三次握手四次揮手

圖1主要包括三部分：建立連接、傳輸數(shù)據(jù)、斷開連接。

1)建立TCP連接很簡單，通過三次握手便可建立連接。

2)建立好連接后，開始傳輸數(shù)據(jù)。TCP數(shù)據(jù)傳輸牽涉到的概念很多：超時重傳、快速重傳、流量控制、擁塞控制等等。

3)斷開連接的過程也很簡單，通過四次握手完成斷開連接的過程。

三次握手建立連接：

***次握手：客戶端發(fā)送syn包(seq=x)到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn);

第二次握手：服務(wù)器收到syn包，必須確認(rèn)客戶的SYN(ack=x+1)，同時自己也發(fā)送一個SYN包(seq=y)，即SYN+ACK包，此時服務(wù)器進(jìn)入SYN_RECV狀態(tài);

第三次握手：客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=y+1)，此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)，完成三次握手。

握手過程中傳送的包里不包含數(shù)據(jù)，三次握手完畢后，客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)。理想狀態(tài)下，TCP連接一旦建立，在通信雙方中的任何一方主動關(guān)閉連接之前，TCP 連接都將被一直保持下去。

傳輸數(shù)據(jù)過程：

a.超時重傳

超時重傳機(jī)制用來保證TCP傳輸?shù)目煽啃浴Ｃ看伟l(fā)送數(shù)據(jù)包時，發(fā)送的數(shù)據(jù)報(bào)都有seq號，接收端收到數(shù)據(jù)后，會回復(fù)ack進(jìn)行確認(rèn)，表示某一seq號數(shù)據(jù)已經(jīng)收到。發(fā)送方在發(fā)送了某個seq包后，等待一段時間，如果沒有收到對應(yīng)的ack回復(fù)，就會認(rèn)為報(bào)文丟失，會重傳這個數(shù)據(jù)包。

b.快速重傳

接受數(shù)據(jù)一方發(fā)現(xiàn)有數(shù)據(jù)包丟掉了。就會發(fā)送ack報(bào)文告訴發(fā)送端重傳丟失的報(bào)文。如果發(fā)送端連續(xù)收到標(biāo)號相同的ack包，則會觸發(fā)客戶端的快速重傳。比較超時重傳和快速重傳，可以發(fā)現(xiàn)超時重傳是發(fā)送端在傻等超時，然后觸發(fā)重傳;而快速重傳則是接收端主動告訴發(fā)送端數(shù)據(jù)沒收到，然后觸發(fā)發(fā)送端重傳。

c.流量控制

這里主要說TCP滑動窗流量控制。TCP頭里有一個字段叫Window，又叫Advertised-Window，這個字段是接收端告訴發(fā)送端自己還有多少緩沖區(qū)可以接收數(shù)據(jù)。于是發(fā)送端就可以根據(jù)這個接收端的處理能力來發(fā)送數(shù)據(jù)，而不會導(dǎo)致接收端處理不過來。 滑動窗可以是提高TCP傳輸效率的一種機(jī)制。

d.擁塞控制

滑動窗用來做流量控制。流量控制只關(guān)注發(fā)送端和接受端自身的狀況，而沒有考慮整個網(wǎng)絡(luò)的通信情況。擁塞控制，則是基于整個網(wǎng)絡(luò)來考慮的?？紤]一下這樣的場景：某一時刻網(wǎng)絡(luò)上的延時突然增加，那么，TCP對這個事做出的應(yīng)對只有重傳數(shù)據(jù)，但是，重傳會導(dǎo)致網(wǎng)絡(luò)的負(fù)擔(dān)更重，于是會導(dǎo)致更大的延遲以及更多的丟包，于是，這個情況就會進(jìn)入惡性循環(huán)被不斷地放大。試想一下，如果一個網(wǎng)絡(luò)內(nèi)有成千上萬的TCP連接都這么行事，那么馬上就會形成“網(wǎng)絡(luò)風(fēng)暴”，TCP這個協(xié)議就會拖垮整個網(wǎng)絡(luò)。為此，TCP引入了擁塞控制策略。擁塞策略算法主要包括：慢啟動，擁塞避免，擁塞發(fā)生，快速恢復(fù)。

四次握手?jǐn)嚅_連接：

***次揮手：主動關(guān)閉方發(fā)送一個FIN，用來關(guān)閉主動方到被動關(guān)閉方的數(shù)據(jù)傳送，也就是主動關(guān)閉方告訴被動關(guān)閉方：我已經(jīng)不會再給你發(fā)數(shù)據(jù)了(當(dāng)然，在fin包之前發(fā)送出去的數(shù)據(jù)，如果沒有收到對應(yīng)的ack確認(rèn)報(bào)文，主動關(guān)閉方依然會重發(fā)這些數(shù)據(jù))，但此時主動關(guān)閉方還可以接受數(shù)據(jù)。

第二次揮手：被動關(guān)閉方收到FIN包后，發(fā)送一個ACK給對方，確認(rèn)序號為收到序號+1(與SYN相同，一個FIN占用一個序號)。

第三次揮手：被動關(guān)閉方發(fā)送一個FIN，用來關(guān)閉被動關(guān)閉方到主動關(guān)閉方的數(shù)據(jù)傳送，也就是告訴主動關(guān)閉方，我的數(shù)據(jù)也發(fā)送完了，不會再給你發(fā)數(shù)據(jù)了。

第四次揮手：主動關(guān)閉方收到FIN后，發(fā)送一個ACK給被動關(guān)閉方，確認(rèn)序號為收到序號+1，至此，完成四次揮手。#p#

圖2給出了TCP通信過程中的狀態(tài)轉(zhuǎn)移圖，理解此圖是我們理解TCP-IP協(xié)議的關(guān)鍵。

圖2 TCP狀態(tài)轉(zhuǎn)移圖

狀態(tài)圖詳細(xì)解讀：

1.CLOSED：起始點(diǎn)，在超時或者連接關(guān)閉時候進(jìn)入此狀態(tài)。

2.LISTEN：服務(wù)端在等待連接過來時候的狀態(tài)，服務(wù)端為此要調(diào)用socket，bind,listen函數(shù)，就能進(jìn)入此狀態(tài)。此稱為應(yīng)用程序被動打開(等待客戶端來連接)。

3.SYN_SENT:客戶端發(fā)起連接，發(fā)送SYN給服務(wù)器端。如果服務(wù)器端不能連接，則直接進(jìn)入CLOSED狀態(tài)。

4.SYN_RCVD：跟3對應(yīng)，服務(wù)器端接受客戶端的SYN請求，服務(wù)器端由LISTEN狀態(tài)進(jìn)入SYN_RCVD狀態(tài)。同時服務(wù)器端要回應(yīng)一個ACK，同時發(fā)送一個SYN給客戶端;另外一種情況，客戶端在發(fā)起SYN的同時接收到服務(wù)器端得SYN請求，客戶端就會由SYN_SENT到SYN_RCVD狀態(tài)。

5.ESTABLISHED：服務(wù)器端和客戶端在完成3次握手進(jìn)入狀態(tài)，說明已經(jīng)可以開始傳輸數(shù)據(jù)了。

以上是建立連接時服務(wù)器端和客戶端產(chǎn)生的狀態(tài)轉(zhuǎn)移說明。相對來說比較簡單明了，如果你對三次握手比較熟悉，建立連接時的狀態(tài)轉(zhuǎn)移還是很容易理解。

下面，我們來看看連接關(guān)閉時候的狀態(tài)轉(zhuǎn)移說明，關(guān)閉需要進(jìn)行4次雙方的交互，還包括要處理一些善后工作(TIME_WAIT狀態(tài))，注意，這里主動關(guān)閉的一方或被動關(guān)閉的一方不是指特指服務(wù)器端或者客戶端，是相對于誰先發(fā)起關(guān)閉請求來說的：

6.FIN_WAIT_1:主動關(guān)閉的一方，由狀態(tài)5進(jìn)入此狀態(tài)。具體的動作是發(fā)送FIN給對方。

7.FIN_WAIT_2:主動關(guān)閉的一方，接收到對方的FIN-ACK(即fin包的回應(yīng)包)，進(jìn)入此狀態(tài)。

8.CLOSE_WAIT：接收到FIN以后，被動關(guān)閉的一方進(jìn)入此狀態(tài)。具體動作是接收到FIN，同時發(fā)送ACK。(之所以叫close_wait可以理解為被動關(guān)閉方此時正在等待上層應(yīng)用發(fā)出關(guān)閉連接指令)

9.LAST_ACK：被動關(guān)閉的一方，發(fā)起關(guān)閉請求，由狀態(tài)8進(jìn)入此狀態(tài)。具體動作是發(fā)送FIN給對方，同時在接收到ACK時進(jìn)入CLOSED狀態(tài)。

10.CLOSING：兩邊同時發(fā)起關(guān)閉請求時，會由FIN_WAIT_1進(jìn)入此狀態(tài)。具體動作是接收到FIN請求，同時響應(yīng)一個ACK。

11.TIME_WAIT：最糾結(jié)的狀態(tài)來了。從狀態(tài)圖上可以看出，有3個狀態(tài)可以轉(zhuǎn)化成它，我們一一來分析：

a.由FIN_WAIT_2進(jìn)入此狀態(tài)：在雙方不同時發(fā)起FIN的情況下，主動關(guān)閉的一方在完成自身發(fā)起的關(guān)閉請求后，接收到被動關(guān)閉一方的FIN后進(jìn)入的狀態(tài)。

b.由CLOSING狀態(tài)進(jìn)入:雙方同時發(fā)起關(guān)閉，都做了發(fā)起FIN的請求，同時接收到了FIN并做了ACK的情況下，由CLOSING狀態(tài)進(jìn)入。

c.由FIN_WAIT_1狀態(tài)進(jìn)入：同時接受到FIN(對方發(fā)起)，ACK(本身發(fā)起的FIN回應(yīng))，與b的區(qū)別在于本身發(fā)起的FIN回應(yīng)的ACK先于對方的FIN請求到達(dá)，而b是FIN先到達(dá)。這種情況概率最小。

關(guān)閉的4次連接最難理解的狀態(tài)是TIME_WAIT，存在TIME_WAIT的2個理由：

1.可靠地實(shí)現(xiàn)TCP全雙工連接的終止。

2.允許老的重復(fù)分節(jié)在網(wǎng)絡(luò)中消逝。

附：

慢熱啟動算法 – Slow Start

首先，我們來看一下TCP的慢熱啟動。慢啟動的意思是，剛剛加入網(wǎng)絡(luò)的連接，一點(diǎn)一點(diǎn)地提速，不要一上來就像那些特權(quán)車一樣霸道地把路占滿。新同學(xué)上高速還是要慢一點(diǎn)，不要把已經(jīng)在高速上的秩序給搞亂了。

慢啟動的算法如下(cwnd全稱Congestion Window)：

1)連接建好的開始先初始化cwnd = 1，表明可以傳一個MSS大小的數(shù)據(jù)。

2)每當(dāng)收到一個ACK，cwnd++; 呈線性上升

3)每當(dāng)過了一個RTT，cwnd = cwnd*2; 呈指數(shù)讓升

4)還有一個ssthresh(slow start threshold)，是一個上限，當(dāng)cwnd >= ssthresh時，就會進(jìn)入“擁塞避免算法”(后面會說這個算法)

所以，我們可以看到，如果網(wǎng)速很快的話，ACK也會返回得快，RTT也會短，那么，這個慢啟動就一點(diǎn)也不慢。

擁塞避免算法 – Congestion Avoidance

前面說過，還有一個ssthresh(slow start threshold)，是一個上限，當(dāng)cwnd >= ssthresh時，就會進(jìn)入“擁塞避免算法”。一般來說ssthresh的值是65535，單位是字節(jié)，當(dāng)cwnd達(dá)到這個值時后，算法如下：

1)收到一個ACK時，cwnd = cwnd + 1/cwnd

2)當(dāng)每過一個RTT時，cwnd = cwnd + 1

這樣就可以避免增長過快導(dǎo)致網(wǎng)絡(luò)擁塞，慢慢的增加調(diào)整到網(wǎng)絡(luò)的***值。很明顯，是一個線性上升的算法。

擁塞狀態(tài)時的算法

前面我們說過，當(dāng)丟包的時候，會有兩種情況：

1)等到RTO超時，重傳數(shù)據(jù)包。TCP認(rèn)為這種情況太糟糕，反應(yīng)也很強(qiáng)烈。

sshthresh = cwnd /2

cwnd 重置為 1

進(jìn)入慢啟動過程

2)Fast Retransmit算法，也就是在收到3個duplicate ACK時就開啟重傳，而不用等到RTO超時。

TCP Tahoe的實(shí)現(xiàn)和RTO超時一樣。

TCP Reno的實(shí)現(xiàn)是：

cwnd = cwnd /2

sshthresh = cwnd

進(jìn)入快速恢復(fù)算法——Fast Recovery

上面我們可以看到RTO超時后，sshthresh會變成cwnd的一半，這意味著，如果cwnd<=sshthresh時出現(xiàn)的丟包，那么TCP的sshthresh就會減了一半，然后等cwnd又很快地以指數(shù)級增漲爬到這個地方時，就會成慢慢的線性增漲。我們可以看到，TCP是怎么通過這種強(qiáng)烈地震蕩快速而小心得找到網(wǎng)站流量的平衡點(diǎn)的。

快速恢復(fù)算法 – Fast Recovery

TCP Reno

這個算法定義在RFC5681?？焖僦貍骱涂焖倩謴?fù)算法一般同時使用。快速恢復(fù)算法是認(rèn)為，你還有3個Duplicated Acks說明網(wǎng)絡(luò)也不那么糟糕，所以沒有必要像RTO超時那么強(qiáng)烈。 注意，正如前面所說，進(jìn)入Fast Recovery之前，cwnd 和 sshthresh已被更新：

cwnd = cwnd /2

sshthresh = cwnd

然后，真正的Fast Recovery算法如下：

cwnd = sshthresh + 3 * MSS (3的意思是確認(rèn)有3個數(shù)據(jù)包被收到了)

重傳Duplicated ACKs指定的數(shù)據(jù)包

如果再收到 duplicated Acks，那么cwnd = cwnd +1

如果收到了新的Ack，那么，cwnd = sshthresh ，然后就進(jìn)入了擁塞避免的算法了。

如果你仔細(xì)思考一下上面的這個算法，你就會知道，上面這個算法也有問題，那就是——它依賴于3個重復(fù)的Acks。注意，3個重復(fù)的Acks并不代表只丟了一個數(shù)據(jù)包，很有可能是丟了好多包。但這個算法只會重傳一個，而剩下的那些包只能等到RTO超時，于是，進(jìn)入了惡夢模式——超時一個窗口就減半一下，多個超時會超成TCP的傳輸速度呈級數(shù)下降，而且也不會觸發(fā)Fast Recovery算法了。

TCP New Reno

于是，1995年，TCP New Reno(參見 RFC 6582 )算法提出來，主要就是在沒有SACK的支持下改進(jìn)Fast Recovery算法的——

當(dāng)sender這邊收到了3個Duplicated Acks，進(jìn)入Fast Retransimit模式，開發(fā)重傳重復(fù)Acks指示的那個包。如果只有這一個包丟了，那么，重傳這個包后回來的Ack會把整個已經(jīng)被sender傳輸出去的數(shù)據(jù)ack回來。如果沒有的話，說明有多個包丟了。我們叫這個ACK為Partial ACK。

一旦Sender這邊發(fā)現(xiàn)了Partial ACK出現(xiàn)，那么，sender就可以推理出來有多個包被丟了，于是乎繼續(xù)重傳sliding window里未被ack的***個包。直到再也收不到了Partial Ack，才真正結(jié)束Fast Recovery這個過程

我們可以看到，這個“Fast Recovery的變更”是一個非常激進(jìn)的玩法，他同時延長了Fast Retransmit和Fast Recovery的過程。