流量控制與擁塞控制的區別。為什麼要把流量控制與擁塞控制分為兩個名詞？
擁塞控制難道不是控制發送方的發送速率嗎？為什麼說擁塞控制是全局的而流量控制是端到端的。明明都是防止擁塞，為什麼要分成兩個名詞分別說，分別處理。比如說丟了幾次包，就代表發生擁塞了，就減小發送速率。這樣不就可以了嗎？為什麼要分為流量控制和擁塞控制呢？
我推測大概是翻譯的問題誤導你了，TCP協議的流量控制不是你理解的那種traffic control，這個名字容易讓人聯想到交通上對於流量的管制，像是對於整個交通網路的調節。實際上你的這個理解確實更接近擁塞控制（congestion control），僅僅在對全局網路的控制上。
先從簡單的流量控制說起。
流量控制（flow control）所說的端到端（end to end）針對的是發送方和接收方速度不匹配的問題（比如經典的fast sender and slow receiver問題，接收方緩存大小與發送速率不匹配），提供一種速度匹配服務遏制發送速率使接收方應用程序的讀取速率與之相適應。主要的方法有：
- Stop-and-wait 這個也是最簡單粗暴的，發一個分組就等對方一個ACK回應然後再發，收不到ACK就不發了
- 滑動窗口（包括go back N和選擇重傳） 接收方在一個窗口都滿了以後才會發送ACK確認並要求發送下一個窗口。Go back N中接收方發送NAK表示接收前N-1個分組失敗然後由發送方退回N步繼續發送；選擇重傳雙方都維護窗口，引入序列號，發現超時未收到序列號則由發送方重傳。
所以你可以很明顯看到流量控制是由接收方控制的，發送方始終是被迫調整至與接收方同步。正如你所說發生了擁塞那麼減小發送方的發送速率也可以是一種擁塞控制的手段，但不是擁塞控制的唯一方式。
擁塞控制無論原因還是方法都複雜的多。有一個說法也就是Computer network: A top-down approach [1] 中提到的
a TCP sender can also be throttled due to congestion within the IP network; this form of sender control is referred to as congestion control.
Even though the actions taken by flow and congestion control are similar (the throttling of
the sender), they are obviously taken for very different reasons.
TCP發送方也可能因為IP層網路的原因被遏制，這種遏制就是一種擁塞控制的方法。流量控制和擁塞控制在手段上相似，比如都是遏制發送方，但是使用它們顯然是出於不同的原因。
流量控制解決的只是過快的發送方的問題，思路也很簡單，得到ACK確認來調整發送速率，對於未收到的包再重傳。這裡考慮的只是一組端到端的情況，所以有點理所當然，發送方發送速率過快，那就遏制一下這個發送方的發送速率。舉個非常不恰當的例子，這種思路就是「人的命運靠自我奮鬥就可以」，於是你覺得成績差那你好好學習名次一定會上升，事實上把你個人放到歷史的洪流中，你就會發現「自我奮鬥固然重要，但也要考慮歷史的行程。」，除了一組發送端和接收端，共享一個路由的其他發送端和接收端也會對該組網路通信造成影響，路由的決定權（緩存大小）也是很重要的，就像努力學習不一定就能考到好大學一樣，有可能你的對手比你更努力，也有可能你所在的省份的錄取率本來就低。這個時候，發送方的速率就需要根據整個網路的條件進行調整了，而不僅僅是接收方的接收速率問題了。
擁塞控制可以針對以下幾種典型的情景：
兩組通信共享一個無限緩存的路由器，那麼這裡的擁塞問題僅僅是由於鏈路容量，分組到達速率接近鏈路容量時會出現巨大的排隊時延。
當路由器的緩存有限時，還可能因為發送速率過快導致緩存溢出，這時會增加一個分組重傳開銷。
在路由器緩存容量有限的多跳網路中，如果一個分組沿著一條路徑被丟棄，那麼該路徑上其他參與轉發該分組的路由的緩存資源也被浪費了，這在一定程度上也引起了擁塞。
這三種情景非常有代表意義，這裡的三個代表分別說明了考慮網路層的各種原因引起的擁塞可能。即使slow receiver的問題不存在，也就是即使接收方的緩存無限大，依然會因為網路層的原因發生擁塞，接收窗口對於擁塞的影響可以忽略，所以我們要關注的只是擁塞窗口（CongWin）的大小，發送方未被確認的分組數量僅僅受限於CongWin的大小，發送方在感知擁塞時對發送速率的調整，即對CongWin大小調整，怎樣調整就是TCP擁塞控制依據的演算法，比如加性增、減性乘、慢啟動等，在此我就不再贅述了，你可以看看代碼，都包含對相應的擁塞窗口變數重新賦值。
舉個例子，談一下慢啟動，代碼來源於BSD4.4的tcp_input函數register u_int cw = tp-&>snd_cwnd;
register u_int incr = tp-&>t_maxseg;
if (cw &> tp-&>snd_ssthresh) 慢啟動的原則就是收到一個ACK窗口大小就續一個。但是如果當前的擁塞窗口大小小於慢啟動的閾值，增加值為1除以擁塞窗口大小並加上一個常量，而擁塞窗口的上限又等於連接發送窗口的最大值，所以使用這樣一個過程進行擁塞控制，更新擁塞窗口的大小。
incr = incr * incr / cw ;
tp-&>snd_cwnd = min(cw + incr, TCP_MAXWIN&<&
[1] Kurose, James F. Computer Networking: A Top-Down Approach Featuring the Internet, 3/E. Pearson Education India, 2005.
[2] Wright, Gary R., and W. Richard Stevens. TcP/IP Illustrated. Vol. 2. Addison-Wesley Professional, 1995.
阻塞控制：Congestion control
我們先來看看congestion control 想解決哪些問題？
當一個介面的帶寬利用率到達一個閥值，比如80%，而且還有繼續增加的趨勢，這些流量有UDP，TCP，但是TCP流量佔大多數，如果路由器有一種辦法可以告訴這些流量的發送方，減小發送速率，是不是很有可能預防這個介面帶寬得利用率到達100%？是，有這種可能，只要發送方聽話，那就沒有問題。那用什麼方法呢？大家知道TCP發送方對發送的packet丟棄很敏感，在timeout時間內沒有收到ACK，就會從重傳這個丟棄的packet，同時把發送速率減半，即1/2的發送速率，流量就會下來。
路由器正是利用了這一點，於是開始對流量隨機丟棄RED，或者按照流量分類加權丟棄WRED，即高優先順序丟的少，低優先順序的流量丟得多，然後如果被丟的是TCP流量，那麼被丟棄的packet所對應的TCP session流量就會下來，這樣就會使總體的流量降下來。
但是UDP流量呢？而UDP還是依然我行我素，該發多少還是多少，比如基於UDP語音流量，流量是固定的，比如64Kbp一個通話，丟了還是64K，語音流量care得是延遲，只要端對端延遲不要超過150ms，通話雙方就不會明顯感覺到有延遲；所以通過丟棄UDP packet 來減少流量的方法不是很有效。
所以congestion control 一般只對TCP 流量有立竿見影的效果。
流量控制：Traffic control
再來看看Traffic control 解決哪些問題？
還是拿哪個語音流量來說，公司希望在路由器出口提供100 條的語音通話能力，假如一路流量64 Kbps，那就需要6400Kbps，即6.4 Mbps的帶寬需求，同時希望延遲盡量小，語音通話質量就會很高。
假定公司出口帶寬是20M，如果沒有配置流量控制，所有的流量一視同仁，沒有高低貴賤之分，先來先服務，即使可能是一些不重要的瀏覽網頁流量（購物、聊天、打遊戲，電驢），也可能把帶寬把持著，佔用出口隊列，而語音流量很可能因為帶寬不足而被丟棄，這顯然是不合理的。於是就了需求，即流量控制。
首先流量分類classification ，也就是產生了階級，給它們IP包打上不同的優先順序marking，IP Precedence 5 給語音，IP Precedence 4 給視頻、IP Precedence 3給信令，IP Precedence 0 其它流量。
然後再給每類流量一個帶寬，比如語音6.4 M，讓優先順序大於0 的分類流量都有自己的保證帶寬，即使帶寬發生了擁塞，也能保證其流量的暢通。
對於語音，我們給它分配一個最高優先順序的隊列，稱之為 LLQ，low latency queue，什麼意思？飛機登機有VIP通道，這個隊列也是這個意思，允許其插隊，第一個從介面出去（登機），這樣它的等待時間就大大縮小，另外帶寬也給它預留了，萬一有6.4 M的流量照樣可以暢通無阻。
而對於優先順序&>0分類的流量，可以看作商務艙的旅客，有自己的保證帶寬，在預留帶寬以內的流量可以保證暢通，超過了就看運氣了。
而對於其它流量，可以看作經濟倉，不保證帶寬，丟還是不丟完全看運氣，帶寬充足時可以自由賓士，帶寬不足時第一個犧牲的就是它們。
以上就是關於兩者的區別，更詳細的內容看我的主頁，稍後更新。流量控制控制端到端的速率，而擁塞控制控制全局網路的速率。
舉個例子，
1.寬頻速率1Gb/s，網路只有兩台機器，從一台主機傳送數據到另一台，這需要流量控制，以保證接收方能正常接收數據。
2.寬頻速率1Gb/s，網路中有成千上萬台機器，幾萬台主機發送到另外幾萬台，這需要擁塞控制，不然網路會癱瘓。
所以折中一下，在連接數較少的情況下可能需要流量控制，配合擁塞控制。
正在複習計網，個人理解
流量控制主要針對的是端到端傳輸中控制流量大小並保證傳輸可靠性（未收到ack就不滑動）。
擁塞避免主要是全局網路的擁塞情況，如果有發生丟包則通過擁塞控制減小窗口，確定出合適(慢開始 擁塞避免 快重傳 快恢復)的擁塞窗口。
我理解的流量控制和擁塞控制的區別。
把帶寬理解成一種稀缺資源。
帶寬如果是總共可用的1000資源，
擁塞控制說的是作為發送方不知道我可以用多少資源的時候，我可能一開始拿1資源用，2資源用，4資源用，直到後來我發現我可以最多一次拿1000資源。拿了超過可用的資源，就會出現丟包現象，然後成為一個負反饋機制說我現在只拿500資源，然後再重新嘗試逐漸逐漸多拿一點，直到我最後反覆失敗幾次之後我確定了一共就1000資源。
流量控制則是，雖然有1000資源，但是1000資源不是你都可以拿的，一共有10個發送方，所以平分一下，每個人就限制最多100資源。當然擁塞控制也可以做到在一段時間之後在反覆的丟包中這10個發送方知道自己拿100資源是最保險的做法。但流量控制則是一開始就規定好每個發送方就允許用100資源，事先規定好，就避免了用反覆丟包這種情況去學習拿100資源你好我好大家好這種情況。
當你深入TCP傳輸協議可能有不同變種的時候，比如TCP Reno，TCP Vegas之類的時候，這兩種協議是經典的不兼容協議，只用擁塞控制的時候，Reno可以把1000資源的900資源都拿掉，而Vegas只能拿到100資源。原理在於Vegas會推測網路的擁塞情況而適度降低自己的傳輸速率，但Reno是通過丟包（認為丟包是達到最大資源量的運用）去調整自己的傳輸速率，所以Reno會壓制Vegas。如果有流量控制的話，通過明確規定一個發送方就只允許拿500資源，那麼Vegas和Reno就可以比較好的共存。
我個人理解的是
擁塞控制，是控制一個網路中的整體流量速率。高了丟包。降一半，增了不少就繼續指數漲。
而流量控制，不僅僅是對速率這個屬性。還控制了流向，控制了服務對象等其他屬性。
推薦閱讀：