前言：

擁塞控制和流量控制分別是什麼概念？流量控制的過程，分別解決什麼問題？

解答：

首先需要明確這兩個概念從手段上都是通過遏制傳送方，但使用它們其實是出於不同的目的。

流量控制應用在如下場景：

一條TCP連線的雙方主機都為該連線設定了接收快取。當該TCP連線收到正確按序的位元組後，它就將資料放入接收快取。相關聯的應用程序會從該快取中讀取資料，但不一定是立即去讀資料，可能現在接收方應用正在忙於其他的服務。那麼如果應用程式讀取資料時相當緩慢，而傳送方傳送的資料太多，太快，那就可能導致接收方的快取溢位。

由以上場景我們可知，其實TCP流量控制主要是一種速度匹配的機制，即為了匹配發送方的傳送速率和接收方應用程式讀取速率的，從而防止快取的溢位。

而TCP流量的控制主要是通過讓傳送方維護一個接收視窗的變數來提供的，也就是說接收視窗告訴傳送方，該接收方還有多少可用的快取空間。（滑動視窗協議）

下面我們可以通過一個例子來看這一過程，圖片取自《TCP/IP協議詳解》

這個圖的主要過程是bsdi主機執行伺服器程式，該伺服器程式設定接收視窗為6144，接著主機sun啟動客戶程式並向伺服器傳送8192個位元組的資料。下面分析這個過程：

1）首先從報文段1，2，3可以看出，雙方首先進行了三次握手，客戶機通告伺服器SYN序號，win視窗，和mss(最大報文段長度)的大小，同時伺服器也告知其提供的視窗為6144。

2）接著我們可以看到客戶機sun立即向bsdi伺服器傳送了6個報文（4~9），然後停止。此時報文段10確定了所有的資料，但是通告客戶端此時其視窗為2048，這是因為接收方應用程式現在只是讀取了前2048位元組的資料，而2049~6144位元組的資料都沒有讀取。

3）報文段11和12完成了客戶資料的最後傳輸，並在最後一個報文攜帶了FIN的標誌。

4）接下來的報文主要是接收方對報文的確認和最終完成TCP的關閉過程。

擁塞控制，一種通俗的說法是，太多主機發送了太多的資料或傳送速度太快以至於網路無法處理，其表現為分組丟失（路由器快取溢位），分組延遲過大（在路由器快取排隊）。

TCP對擁塞控制採用的方法是讓每一個傳送方根據所感知的網路擁塞程度，來限制其能向連線傳送流量的速率。首先，TCP擁塞控制機制讓連線的每一端都記錄一個額外的變數，叫擁塞視窗（Congwin），其限制了TCP傳送方能向網路中傳送流量的速率。而後TCP傳送方定義一種丟包事件：要麼出現超時，要麼收到來自接收方的3個冗餘ACK，來感知路徑上的擁塞。接著就是在感知擁塞時，採用的傳送速率的控制演算法。有如下兩種：

1）加性增，乘性減：在開始階段，如果沒有檢測到擁塞，就緩慢地增加擁塞視窗的長度，謹慎地探測端到端路徑上的可用頻寬。也就是說TCP傳送方在每次收到一個確認之後就將Congwin增加一個MSS（加性增）。而每發生一次丟包事件，就將當前的Congwin減半（乘性減）。曲線如下：

2）慢啟動：傳送方在初始階段以指數的速度增加速率，即每過一個RTT就將Congwin翻倍，直到達到某個閾值（Threshold）,就按照加性增線性增長。直到發生一個丟包事件為止，將Congwin降為一半或降為1個MSS。如下圖