1.流量控制

 所謂的流量控制就是讓傳送方的傳送速率不要太快，讓接收方來得及接受。利用滑動視窗機制可以很方便的在TCP連線上實現對傳送方的流量控制。TCP的視窗單位是位元組，不是報文段，傳送方的傳送視窗不能超過接收方給出的接收視窗的數值。

如圖所示，說明了利用可變視窗大小進行流量控制。設主機A向主機B傳送資料。雙方確定的視窗值是400.再設每一個報文段為100位元組長，序號的初始值為seq=1,圖中的箭頭上面大寫ACK，表示首部中的確認為ACK，小寫ack表示確認欄位的值。

接收方的主機B進行了三次流量控制。第一次把視窗設定為rwind=300，第二次減小到rwind=100最後減到rwind=0

，即不允許傳送方再發送過資料了。這種使傳送方暫停傳送的狀態將持續到主機B重新發出一個新的視窗值為止。

假如，B向A傳送了零視窗的報文段後不久，B的接收快取又有了一些儲存空間。於是B向A傳送了rwind=400的報文段，然而這個報文段在傳送中丟失了。A一直等待收到B傳送的非零視窗的通知，而B也一直等待A傳送的資料。這樣就死鎖了。為了解決這種死鎖狀態，TCP為每個連線設有一個持續計時器。只要TCP連線的一方收到對方的零視窗通知，就啟動持續計時器，若持續計時器設定的時間到期，就傳送一個零視窗探測報文段（僅攜帶1位元組的資料），而對方就在確認這個探測報文段時給出了現在的視窗值。

2.擁塞

2.1 擁塞控制的原理

在某段時間，若對網路中的某一資源的需求超過了該資源所能提供的可用部分，網路的效能就要變化，這種情況叫做擁塞。網路擁塞往往是由許多因素引起的，簡單的提高節點處理機的速度或者擴大結點快取的儲存空間並不能解決擁塞問題。例如 當某個結點快取容量擴充套件到非常大，於是凡到達該結點的分組均可在結點的快取佇列中排隊，不受任何限制。由於輸出鏈路的容量和處理機的速度並未提高，因此在這佇列中的絕大多數的分組在排隊等待時間會大大增加，結果上層軟體只好把他們進行重傳。

因此，問題指的往往是整個系統的各個部分不匹配，只有各個部分平衡了，問題才會得到解決。

2.2.擁塞控制和流量控制的差別

擁塞控制

就是防止過多的資料注入到網路中，這樣可以使網路中的路由器或鏈路不致過載。擁塞控制所要做的都有一個前提，就是網路能承受現有的網路負荷。

流量控制往往指的是點對點通訊量的控制，是個端到端的問題。流量控制所要做的就是控制傳送端傳送資料的速率，以便使接收端來得及接受。

2.3.擁塞控制設計

擁塞控制是很難設計的，因為它是一個動態的問題，許多情況下，甚至正式擁塞控制機制本身成為引起網路效能惡化甚至死鎖的原因。從控制理論的角度來看擁塞控制這個問題，可以分為開環控制和閉環控制兩種方法。開環控制就是在設計網路時事先將有關擁塞發生的所有因素考慮周到，一旦系統執行起來就不能在中途改正。

閉環控制是基於反饋環路的概念，包括如下措施：

1）監測網路系統以便檢測擁塞在何時何地發生

2）把擁塞發生的資訊傳送到可採取行動的地方

3）調整網路系統的行動以解決出現的問題。

2.4.擁塞控制方法

因特網建議標準RFC2581定義了進行擁塞控制的四種演算法，即慢開始（Slow-start)，擁塞避免（Congestion Avoidance)快重傳（Fast Restrangsmit)和快回復（Fast Recovery）。我們假定

1）資料是單方向傳送，而另外一個方向只傳送確認

2）接收方總是有足夠大的快取空間，因為傳送視窗的大小由網路的擁塞程度來決定。

2.5 慢開始和擁塞避免

傳送報文段速率的確定，既要根據接收端的接收能力，又要從全域性考慮不要使網路發生擁塞，這由接收視窗和擁塞視窗兩個狀態量確定。接收端視窗（Reciver Window)又稱通知視窗（Advertised Window),是接收端根據目前的接收快取大小所許諾的最新視窗值，是來自接收端的流量控制。擁塞視窗cwnd（Congestion Window)是傳送端根據自己估計的網路擁塞程度而設定的視窗值，是來自傳送端的流量控制。

傳送方維持一個擁塞視窗 cwnd ( congestion window )的狀態變數。擁塞視窗的大小取決於網路的擁塞程度，並且動態地在變化。傳送方讓自己的傳送視窗等於擁塞視窗。

傳送方控制擁塞視窗的原則是：只要網路沒有出現擁塞，擁塞視窗就再增大一些，以便把更多的分組傳送出去。但只要網路出現擁塞，擁塞視窗就減小一些，以減少注入到網路中的分組數。

慢開始演算法：

當主機開始傳送資料時，如果立即所大量資料位元組注入到網路，那麼就有可能引起網路擁塞，因為現在並不清楚網路的負荷情況。因此，較好的方法是 先探測一下，即由小到大逐漸增大發送視窗，也就是說，由小到大逐漸增大擁塞視窗數值。通常在剛剛開始傳送報文段時，先把擁塞視窗 cwnd 設定為一個最大報文段MSS的數值。而在每收到一個對新的報文段的確認後，把擁塞視窗增加至多一個MSS的數值。用這樣的方法逐步增大發送方的擁塞視窗 cwnd ，可以使分組注入到網路的速率更加合理。

每經過一個傳輸輪次，擁塞視窗 cwnd 就加倍。一個傳輸輪次所經歷的時間其實就是往返時間RTT。不過“傳輸輪次”更加強調：把擁塞視窗cwnd所允許傳送的報文段都連續傳送出去，並收到了對已傳送的最後一個位元組的確認。

另，慢開始的“慢”並不是指cwnd的增長速率慢，而是指在TCP開始傳送報文段時先設定cwnd=1，使得傳送方在開始時只發送一個報文段（目的是試探一下網路的擁塞情況），然後再逐漸增大cwnd。

為了防止擁塞視窗cwnd增長過大引起網路擁塞，還需要設定一個慢開始門限ssthresh狀態變數。慢開始門限ssthresh的用法如下：

• 當 cwnd < ssthresh 時，使用上述的慢開始演算法。
• 當 cwnd > ssthresh 時，停止使用慢開始演算法而改用擁塞避免演算法。
• 當 cwnd = ssthresh 時，既可使用慢開始演算法，也可使用擁塞控制避免演算法。

擁塞避免：

讓擁塞視窗cwnd緩慢地增大，即每經過一個往返時間RTT就把傳送方的擁塞視窗cwnd加1，而不是加倍。這樣擁塞視窗cwnd按線性規律緩慢增長，比慢開始演算法的擁塞視窗增長速率緩慢得多。

無論在慢開始階段還是在擁塞避免階段，只要傳送方判斷網路出現擁塞（其根據就是沒有收到確認），就要把慢開始門限ssthresh設定為出現擁塞時的傳送 方視窗值的一半（但不能小於2）。然後把擁塞視窗cwnd重新設定為1，執行慢開始演算法。

這樣做的目的就是要迅速減少主機發送到網路中的分組數，使得發生擁塞的路由器有足夠時間把佇列中積壓的分組處理完畢。

如下圖，用具體數值說明了上述擁塞控制的過程。現在傳送視窗的大小和擁塞視窗一樣大。

2.6 快重傳和快恢復 

一條TCP連線有時會因等待重傳計時器的超時而空閒較長的時間，慢開始和擁塞避免無法很好的解決這類問題，因此提出了快重傳和快恢復的擁塞控制方法。

快重傳

快重傳演算法首先要求接收方每收到一個失序的報文段後就立即發出重複確認（為的是使傳送方及早知道有報文段沒有到達對方）而不要等到自己傳送資料時才進行捎帶確認。

快重傳演算法並非取消了重傳機制，只是在某些情況下更早的重傳丟失的報文段（如果當傳送端接收到三個重複的確認ACK時，則斷定分組丟失，立即重傳丟失的報文段，而不必等待重傳計時器超時）。慢開始演算法只是在TCP建立時才使用

接收方收到了M1和M2後都分別發出了確認。現在假定接收方沒有收到M3但接著收到了M4。

顯然，接收方不能確認M4，因為M4是收到的失序報文段。根據 可靠傳輸原理，接收方可以什麼都不做，也可以在適當時機發送一次對M2的確認。

但按照快重傳演算法的規定，接收方應及時傳送對M2的重複確認，這樣做可以讓 傳送方及早知道報文段M3沒有到達接收方。傳送方接著傳送了M5和M6。接收方收到這兩個報文後，也還要再次發出對M2的重複確認。這樣，傳送方共收到了 接收方的四個對M2的確認，其中後三個都是重複確認。

快重傳演算法還規定，傳送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段M3，而不必 繼續等待M3設定的重傳計時器到期。

由於傳送方儘早重傳未被確認的報文段，因此採用快重傳後可以使整個網路吞吐量提高約20%。

快恢復

快恢復演算法有以下兩個要點：

1.當傳送方連續收到三個重複確認時，就執行“乘法減小”演算法，把慢開始門限減半，這是為了預防網路發生擁塞。

2.由於傳送方現在認為網路很可能沒有發生擁塞，因此現在不執行慢開始演算法，而是把cwnd值設定為慢開始門限減半後的值，然後開始執行擁塞避免演算法，是擁塞視窗的線性增大。