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

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

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

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

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

  三次握手建立連接：

  第一次握手：客戶端發(fā)送syn包(seq=x)到服務(wù)器，并進入SYN_SEND狀態(tài)，等待服務(wù)器確認；

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

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

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

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

  超時重傳

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

  快速重傳

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

  流量控制

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

  擁塞控制

  滑動窗用來做流量控制。流量控制只關(guān)注發(fā)送端和接受端自身的狀況，而沒有考慮整個網(wǎng)絡(luò)的通信情況。擁塞控制，則是基于整個網(wǎng)絡(luò)來考慮的。考慮一下這樣的場景：某一時刻網(wǎng)絡(luò)上的延時突然增加，那么，TCP對這個事做出的應(yīng)對只有重傳數(shù)據(jù)，但是，重傳會導(dǎo)致網(wǎng)絡(luò)的負擔(dān)更重，于是會導(dǎo)致更大的延遲以及更多的丟包，于是，這個情況就會進入惡性循環(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確認報文，主動關(guān)閉方依然會重發(fā)這些數(shù)據(jù))，但此時主動關(guān)閉方還可以接受數(shù)據(jù)。

  第二次揮手：被動關(guān)閉方收到FIN包后，發(fā)送一個ACK給對方，確認序號為收到序號+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)閉方，確認序號為收到序號+1，至此，完成四次揮手。

  狀態(tài)轉(zhuǎn)換圖

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

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

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

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

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

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

  ESTABLISHED：服務(wù)器端和客戶端在完成3次握手進入狀態(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)閉需要進行4次雙方的交互，還包括要處理一些善后工作（TIME_WAIT狀態(tài)），注意，這里主動關(guān)閉的一方或被動關(guān)閉的一方不是指特指服務(wù)器端或者客戶端，是相對于誰先發(fā)起關(guān)閉請求來說的：

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

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

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

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

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

  TIME_WAIT：最糾結(jié)的狀態(tài)來了。從狀態(tài)圖上可以看出，有3個狀態(tài)可以轉(zhuǎn)化成它，我們一一來分析：?
  a. 由FIN_WAIT_2進入此狀態(tài)：在雙方不同時發(fā)起FIN的情況下，主動關(guān)閉的一方在完成自身發(fā)起的關(guān)閉請求后，接收到被動關(guān)閉一方的FIN后進入的狀態(tài)。?
  b. 由CLOSING狀態(tài)進入:雙方同時發(fā)起關(guān)閉，都做了發(fā)起FIN的請求，同時接收到了FIN并做了ACK的情況下，由CLOSING狀態(tài)進入。?
  c. 由FIN_WAIT_1狀態(tài)進入：同時接受到FIN（對方發(fā)起），ACK（本身發(fā)起的FIN回應(yīng)），與b的區(qū)別在于本身發(fā)起的FIN回應(yīng)的ACK先于對方的FIN請求到達，而b是FIN先到達。這種情況概率最小。

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

  可靠地實現(xiàn)TCP全雙工連接的終止。 允許老的重復(fù)分節(jié)在網(wǎng)絡(luò)中消逝。

  附：

  慢熱啟動算法 – Slow Start

  首先，我們來看一下TCP的慢熱啟動。慢啟動的意思是，剛剛加入網(wǎng)絡(luò)的連接，一點一點地提速，不要一上來就像那些特權(quán)車一樣霸道地把路占滿。新同學(xué)上高速還是要慢一點，不要把已經(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時，就會進入“擁塞避免算法”（后面會說這個算法）

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

  擁塞避免算法 – Congestion Avoidance

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

  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認為這種情況太糟糕，反應(yīng)也很強烈。

  view sourceprint?

  1.<code?class=" hljs fix">sshthresh =? cwnd /2

  2.cwnd 重置為?1

  3.進入慢啟動過程</code>

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

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

  view sourceprint?

  1.<code?class=" hljs makefile">TCP Reno的實現(xiàn)是：

  2.cwnd = cwnd /2

  3.sshthresh = cwnd

  4.進入快速恢復(fù)算法——Fast Recovery</code>

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

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

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

  view sourceprint?

  1.<code?class=" hljs ini">cwnd = cwnd /2

  2.sshthresh = cwnd</code>

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

  cwnd = sshthresh + 3 * MSS（3的意思是確認有3個數(shù)據(jù)包被收到了）?
  重傳Duplicated ACKs指定的數(shù)據(jù)包.如果再收到 duplicated Acks，那么cwnd = cwnd +1。如果收到了新的Ack，那么，cwnd = sshthresh ，然后就進入了擁塞避免的算法了。

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

  TCP New Reno

  于是，1995年，TCP New Reno（參見RFC 6582）算法提出來，主要就是在沒有SACK的支持下改進Fast Recovery算法的——?
  當(dāng)sender這邊收到了3個Duplicated Acks，進入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的變更”是一個非常激進的玩法，他同時延長了Fast Retransmit和Fast Recovery的過程。

術(shù)語：

SYN表示建立連接，

FIN表示關(guān)閉連接，

ACK表示響應(yīng)，

PSH表示有 DATA數(shù)據(jù)傳輸，

RST表示連接重置。

http://www.cnblogs.com/azraelly/archive/2012/12/25/2832393.html

轉(zhuǎn)載于:https://blog.51cto.com/danniea/1642489

總結(jié)

以上是生活随笔為你收集整理的图解TCPIP协议的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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