在tcp連線上實現對傳送方的流量控制：使用滑動視窗機制
假設每乙個報文段為100位元組長，而資料報文段序號的初始值設為1。初始時接收方b的接收視窗為400，即rwnd=400;大寫ack表示首部中的確認位ack，小寫ack表示確認欄位的值ack；
如圖所示：b進行了三次流量控制（第一次把視窗減少到 rwnd = 300 ，第二次又減到了 rwnd = 100 ，最後減到 rwnd = 0 ，即不允許傳送方再傳送資料了）;直到主機b重新發出乙個新的視窗值給a,a才能重新傳送資料給b;
注：b向a傳送的三個報文段都設定了 ack = 1 ，只有在ack=1時確認號字段才有意義。
具體過程：設a向b傳送資料。在建立tcp連線時，ab雙方會進行視窗協商； 相當於b告訴了a：「我的接收視窗( receiver window)是 rwnd = 400 」 , 因此，a的傳送視窗不能超過接收方給出的接收視窗的數值。在接收資料的過程中接收方b會動態向傳送方a更新rwnd的數值，以此實現對流量的控制；
注：tcp的視窗單位是位元組，不是報文段；這裡是為了講解方便，所以採用報文段說明；
為了防止死鎖情況（b傳送給a非零視窗通知在傳送中丟失，而a一直等待收到b傳送的非零視窗的通知）的發生：
tcp為每個連線設有乙個持續計時器。只要tcp連線的一方收到對方的零視窗通知，就啟動持續計時器，若持續計時器設定的時間到期，就傳送乙個零視窗探測報文段（僅攜帶1位元組的資料），而對方就在確認這個探測報文段時給出了現在的視窗值。
糊塗視窗綜合證：
tcp接收方的快取已滿，而互動式的應用程序一次只從接收快取中讀取1位元組（這樣就使接收快取空間僅騰出1位元組），然後向傳送方傳送確認，並把視窗設定為1個位元組（但傳送的資料報為40位元組的的話）。
傳送方接收，又發來1個位元組的資料（傳送方的ip資料報是40位元組）。接收方發回確認，仍然將視窗設定為1個位元組。迴圈往復，這樣網路的效率很低。
解決方案：可讓接收方等待一段時間，使得接收快取已有足夠空間容納乙個最長的報文段，或者等到接收方快取已有一半空閒的空間；再向傳送方發確認報文並通知當前的視窗大小。
此外，傳送方也不要傳送太小的報文段，而是把資料報積累成足夠大的報文段，或達到接收方快取的空間的一半大小。
tcp報文段什麼時候會傳送出去？（4種機制）
1）tcp維持乙個變數，它等於最大報文段長度mss，只要快取中存放的資料達到mss位元組就組裝成乙個tcp報文段傳送出去。
2）由傳送方的應用程序指明要求傳送報文段，即tcp支援的推送( push )操作；
3）傳送方的乙個計時器期限到了，這時就把已有的快取資料裝入報文段(但長度不能超過mss)傳送出去。
①.當傳送應用程序把傳送資料（逐個位元組地）傳輸到tcp的傳送快取中;
②傳送方先把第乙個資料位元組傳送出去，將後續的資料位元組都快取起來;
③.當傳送方接收對第乙個資料字元的確認後，再把傳送快取中的所有資料組裝成乙個報文段再 傳送出去，然後繼續對隨後到達的資料進行快取。
適用場景：當資料到達較快而網路速率較慢時，用這樣的方法可明顯地減少所用的網路頻寬。
nagle演算法規定：當到達的資料已達到傳送視窗大小的一半或已達到報文段的最大長度時，就立 即傳送乙個報文段。
從控制理論的角度來看擁塞控制這個問題，可以分為開環控制和閉環控制兩種方法。
開環控制就是在設計網路時事先將有關擁塞發生的所有因素考慮周到，一旦系統執行起來就不能在中途改正。
閉環控制是基於反饋環路的概念，包括如下措施：
1）監測網路系統以便檢測擁塞在何時何地發生
2）把擁塞發生的資訊傳送到可採取行動的地方
3）調整網路系統的行動以解決出現的問題。
假定前提條件：
1）資料是單方向傳送，而另外乙個方向只傳送確認
2）接收方總是有足夠大的快取空間，因為傳送視窗的大小由網路的擁塞程度來決定。
基本傳送方維持乙個叫做擁塞視窗cwnd（congestion window）的狀態變數。
注：擁塞視窗的大小取決於網路的擁塞程度，並且動態地在變化。 一般傳送方讓自己的傳送視窗等於擁塞視窗，但考慮到接受方的接收能力，傳送視窗可能小於擁塞視窗。
慢開始演算法的思路就是，不要一開始就傳送大量的資料，先探測一下網路的擁塞程度，由小到大逐漸增加擁塞視窗的大小；慢開始演算法只是在tcp建立時才使用
為了防止cwnd增長過大引起網路擁塞，還需設定乙個慢開始門限ssthresh狀態變數。ssthresh的用法如下：
當cwnd當cwnd>ssthresh時，改用擁塞避免演算法。
當cwnd=ssthresh時，慢開始與擁塞避免演算法任意。
擁塞控制具體過程為：
1）tcp連線初始化，將擁塞視窗設定為1
2）執行慢開始演算法，cwind按指數規律增長，直到cwind == ssthress開始執行擁塞避免演算法，cwnd按線性規律增長
3）傳送方判斷網路出現擁塞（其根據就是沒有收到確認，雖然沒有收到確認可能是其他原因的分組丟失，但是因為無法判定，所以都當做擁塞來處理），把ssthresh值更新為出現擁塞時的傳送視窗大小的一半，cwnd重新設定為1，按照步驟（2）執行。
如下圖：
一條tcp連線有時會因等待重傳計時器的超時而空閒較長的時間，慢開始和擁塞避免無法很好的解決這類問題，因此提出了快重傳和快恢復的擁塞控制方法。
快重傳要求接收方在收到乙個失序的報文段後就立即發出重複確認而不要等到自己傳送資料時捎帶確認。
快重傳演算法規定：傳送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待設定的重傳計時器時間到期。
如下圖：
快重傳配合使用的還有快恢復演算法，它有以下兩個要點:
①當傳送方連續收到三個重複確認時，就執行「乘法減小」演算法，把ssthresh門限減半；
②考慮到如果網路出現擁塞的話就不會收到好幾個重複的確認，所以傳送方現在認為網路可能沒有出現擁塞。所以此時不執行慢開始演算法，而是將cwnd設定為ssthresh的大小，然後執行擁塞避免演算法。如下圖：
慢開始演算法只是在tcp建立時才使用
「擁塞避免」並非指完全能夠避免了擁塞。 而是說 將擁塞視窗控制為按線性規律增長，使網路比較不容易出現擁塞。
快重傳演算法並非取消了重傳機制，只是在某些情況下更早的重傳丟失的報文段（如果當傳送端接收到三個重複的確認ack時，則斷定分組丟失，立即重傳丟失的報文段，而不必等待重傳計時器超時）。
以上的擁塞控制演算法並沒有和網路層聯絡起來，實際上網路層的策略對擁塞避免演算法影響最大的就是路由器的尾部丟棄策略（路由器通常按照先進先出的策略處理到來的分組，當路由器的快取裝不下分組的時候就丟棄到來的分組）；
這樣就會導致分組丟失，傳送方認為網路產生擁塞。更為嚴重的是網路中存在很多的tcp連線，這些連線中的報文段通常是復用路由路徑。若發生路由器的尾部丟棄，可能影響到很多條tcp連線；
最終導致的結果就是這許多的tcp連線在同一時間進入慢開始狀態。這在術語中稱為全域性同步。全域性同步會使得網路的通訊量突然下降很多，而在網路恢復正常之後，其通訊量又突然增大很多。
使路由器的佇列維持兩個引數，即佇列長度的最小門限min和最大門限max，每當乙個分組到達的時候，red通過計算平均佇列長度。然後分情況對待到來的分組：
①平均佇列長度小於最小門限——把新到達的分組放入佇列排隊。
②平均佇列長度在最小門限與最大門限之間——則按照某一概率將分組丟棄。
③平均佇列長度大於最大門限——丟棄新到達的分組。
red的關鍵點：
最小門限、最大門限、丟棄概率三個引數的選擇
計算平均佇列長度。
注：平均佇列長度採用加權平均的方法計算平均佇列長度，這和往返時間（rtt）的計算策略是一樣的。
流量控制和擁塞控制
就是讓傳送方的傳送速率不要太快，要讓接受方有時間接收。利用滑動視窗機制可以很方便的在tcp連線上實現對傳送方的流量控制。tcp接收方利用自己的接受視窗的大小來限制傳送方的視窗大小。tcp傳送方收到接受方的0視窗通知後，應啟動持續計時器，持續計時器超時後，向接收方傳送0視窗探測報文。概念 在某段時間，...
TCP流量控制和擁塞控制
1 利用滑動視窗實現流量控制 如果傳送方把資料傳送得過快，接收方可能會來不及接收，這就會造成資料的丟失。所謂流量控制就是讓傳送方的傳送速率不要太快，要讓接收方來得及接收。利用滑動視窗機制可以很方便地在tcp連線上實現對傳送方的流量控制。2 設a向b傳送資料。在連線建立時，b告訴了a 我的接收視窗是 ...
TCP擁塞控制和流量控制
tcp作為面向連線的提供全雙工可靠服務協議，具有差錯控制 擁塞控制和流量控制等功能。此處所謂的擁塞控制和流量控制，就是將傳送端傳送能力 接收端接收資訊的能力以及當前的網路環境參與考慮，在網路擁塞情況嚴重或者接收端接收能力有限的情況下，減緩或暫停訊息傳送，當情況改善時，增強訊息傳送能力，加上超時 丟失...