先來了解2個(gè)TCP的概念：

MSS：Maximum Segment Size，TCP一次傳輸發(fā)送的最大數(shù)據(jù)段長(zhǎng)度。

RTT：Round-Trip Time，往返時(shí)延，表示從發(fā)送端發(fā)送數(shù)據(jù)開始，到發(fā)送端收到來自接收端的確認(rèn)（接收端收到數(shù)據(jù)后便立即發(fā)送確認(rèn)），總共經(jīng)歷的時(shí)延。

TCP傳輸大塊數(shù)據(jù)時(shí)，肯定需要進(jìn)行數(shù)據(jù)分段，而每個(gè)分段所能攜帶的最大數(shù)據(jù)就是1個(gè)MSS，假設(shè)大塊數(shù)據(jù)為100個(gè)MSS，那么發(fā)送方發(fā)送的方式大概有如下兩種：

1、 每次發(fā)送1個(gè)，收到接收方確認(rèn)后，才發(fā)送下1個(gè)；

2、 一口氣發(fā)送100個(gè)，然后收到對(duì)方一起確認(rèn)；

顯然，方式1中，一個(gè)RTT只能處理一個(gè)包，這樣的傳輸效率太低了。而方式2看似很美好，實(shí)際會(huì)存在兩個(gè)問題，一個(gè)是接收方的接收窗口未必能一次性接收這么多數(shù)據(jù)，另外一個(gè)是網(wǎng)絡(luò)的帶寬也不一定足夠大，容易出現(xiàn)丟包事故。前一個(gè)問題就是標(biāo)題中的流量控制(Flow control)，TCP采用的是滑動(dòng)窗口機(jī)制(Sliding window)，后一個(gè)問題就是標(biāo)題中的擁塞控制(Congestion control)。發(fā)送方的發(fā)送窗口或者說網(wǎng)絡(luò)傳輸交互就取決于這兩個(gè)問題的控制，誰控制的更嚴(yán)格，誰就占據(jù)了決定性因素，這也是為什么兩者總是一起出現(xiàn)一起被討論。

流量控制(Flow control):

TCP uses an end-to-end flow control protocol to avoid having the sender send data too fast for the TCP receiver to receive and process it reliably. Having a mechanism for flow control is essential in an environment where machines of diverse network speeds communicate.

TCP使用端到端流量控制協(xié)議來避免發(fā)送方發(fā)送數(shù)據(jù)太快，以致TCP接收方不能可靠地接收和處理數(shù)據(jù)。在不同網(wǎng)絡(luò)速度的機(jī)器進(jìn)行通信的環(huán)境中，具有流量控制機(jī)制至關(guān)重要。

圖一

圖一為通過Wireshark抓包192.168.2.1和192.168.2.198的交互截圖，可以看到有個(gè)標(biāo)記Win，這個(gè)標(biāo)記的含義就是接收端告訴發(fā)送端自己還有多少緩沖區(qū)可以接收數(shù)據(jù)。于是發(fā)送端就可以根據(jù)這個(gè)接收端的處理能力來發(fā)送數(shù)據(jù)，而不會(huì)導(dǎo)致接收端處理不過來。

[TCP zerowindow]& [TCP window Full]

提到Win標(biāo)記，就順便談一下Wireshark的[TCP zerowindow]和[TCP window Full]，當(dāng)Win=0時(shí)，Wireshark就會(huì)打上TCP zerowindow，表示緩存區(qū)已滿，不能再接收數(shù)據(jù)了。當(dāng)Wireshark在一個(gè)包上打上TCP window Full，就表示這個(gè)包的發(fā)送方已經(jīng)把對(duì)方聲明的接收窗口耗盡了。兩者的共同特點(diǎn)都是傳輸暫停，前者的含義是發(fā)送方無法再接收數(shù)據(jù)，后者表示發(fā)送方無法再發(fā)送數(shù)據(jù)。

回過頭來再來說滑動(dòng)窗口。

圖二截取自《TCP/IP詳解》

圖三取自參考資料

圖四取自參考資料

圖二和圖三可以知道接收方會(huì)通知發(fā)送方當(dāng)前已接收到的信息和可用窗口信息。

圖三和圖四可以看出來窗口滑動(dòng)的過程。

總結(jié)：TCP的流量控制由滑動(dòng)窗口來實(shí)現(xiàn)的，滑動(dòng)窗口控制流量取決于接收方的窗口大小。

擁塞控制(Congestion control):

流量控制是端到端的交互，如果只是局域網(wǎng)內(nèi)的兩臺(tái)設(shè)備交互，我想通過滑動(dòng)窗口大概能控制得不差，但是實(shí)際網(wǎng)絡(luò)的情況非常復(fù)雜，發(fā)送方和接收方之間還有路由器和交換機(jī)，網(wǎng)絡(luò)傳輸線路又復(fù)雜，這個(gè)時(shí)候就需要擁塞控制。

擁塞控制主要有四個(gè)算法：慢啟動(dòng)、擁塞避免、快速重傳和快速恢復(fù)。

慢啟動(dòng)：

討論慢啟動(dòng)算法先來了解下?lián)砣翱诘母拍睿@是慢啟動(dòng)算法為TCP發(fā)送方新增的窗口，congestion window，簡(jiǎn)稱cwnd。對(duì)應(yīng)上文，發(fā)送方取擁塞窗口和滑動(dòng)窗口的最小值作為發(fā)送上限，即誰嚴(yán)格誰起決定因素。

1、 連接建立開始，發(fā)送方不了解網(wǎng)絡(luò)的情況，cwnd初始化比較小的值，RFC建議2-4個(gè)MSS，具體視MSS的大小而定；

If (MSS <= 1095 bytes)

then win <= 4 * MSS;

If (1095 bytes < MSS < 2190 bytes)

then win <= 4380;

If (2190 bytes <= MSS)

then win <= 2 * MSS; 摘自rfc3390.

2、 如果發(fā)送出去的包都被ACK，說明還未到達(dá)擁塞點(diǎn)，則增加擁塞窗口，RFC建議的是每收到n個(gè)ACK，則cwnd新增n個(gè)MSS，呈指數(shù)關(guān)系增長(zhǎng)，雖然這個(gè)過程看似比較快，但是基數(shù)比較低，所以被稱為“慢啟動(dòng)”。

擁塞避免：

其實(shí)慢啟動(dòng)除了維護(hù)了cwnd，還維護(hù)了慢啟動(dòng)臨界值ssthresh，一般將ssthresh設(shè)置為65535字節(jié)。在cwnd<=ssthresh時(shí)，還是處于慢啟動(dòng)環(huán)節(jié)，一旦>ssthresh，開始進(jìn)入擁塞避免。

RFC建議擁塞避免環(huán)節(jié)，無論一個(gè)RTT可以收到多少個(gè)ACK，每一次確認(rèn)都只新增1個(gè)MSS，呈線性關(guān)系增長(zhǎng)，避免快速的觸碰到網(wǎng)絡(luò)擁塞點(diǎn)。

圖五取自參考資料

快速重傳和快速恢復(fù)：

進(jìn)入擁塞避免之后，最終還是會(huì)碰到擁塞點(diǎn)，發(fā)送方此時(shí)遲遲得不到確認(rèn)，當(dāng)然得不到確認(rèn)也有可能是因?yàn)檠舆t確認(rèn)導(dǎo)致的。發(fā)送方此時(shí)決定等待一段時(shí)間，如果一段時(shí)間后還是得不到確認(rèn)，就發(fā)起重傳，這個(gè)過程叫做超時(shí)重傳。從發(fā)出原始包到重傳該包的時(shí)間叫做RTO(Retransmission TimeOut)。

進(jìn)入超時(shí)重傳后，RFC建議將cwnd設(shè)置為1個(gè)MSS，而對(duì)于ssthresh，RFC5681建議的是發(fā)生擁塞時(shí)未被ACK的數(shù)據(jù)量的1/2，但必須大于等于2個(gè)MSS。然后重新進(jìn)入慢啟動(dòng)環(huán)節(jié)。超時(shí)重傳因?yàn)樾枰却齊TO之后才能進(jìn)入新的恢復(fù)環(huán)節(jié)，所以對(duì)網(wǎng)絡(luò)性能的影響是比較大的。所以各路大神又想到了一個(gè)新的方式，看能否無需等待RTO，就發(fā)起重傳，這種方式叫做快速重傳?？焖僦貍饕?guī)定在收到3個(gè)及以上重復(fù)ACK時(shí)就觸發(fā)重傳，不再進(jìn)入慢啟動(dòng)環(huán)節(jié)，然后直接進(jìn)入擁塞避免，這個(gè)就是快速恢復(fù)算法。為什么是3個(gè)？因?yàn)?-2個(gè)重復(fù)ACK，很有可能是亂序，只有在3個(gè)及以上的時(shí)候才是有可能丟包了。
編輯：hfy