發送方維持一個叫做擁塞窗口cwnd (congestion window)的狀態變量。擁塞窗口（佝大小取決于網絡的擁塞程度，并且動態地在變化。發送方讓自己的發送窗口等于擁塞窗口。 G4PH40UD-E以后我們就知道，如果再考慮到接收方的接收能力，那么發送窗口還可能小于擁塞窗口。

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

   發送方又是如何知道網絡發生了擁塞呢？我們知道，當網絡發生擁塞時，路由器就要丟棄分組。因此只要發送方沒有按時收到應當到達的確認報文，就可以猜想網絡可能出現了擁塞。現在通信線路的傳輸質量一般都很好，因傳輸出差錯而丟棄分組的概率是很小的（遠小于1%）。

   下面將討論擁塞窗口cwnd的大小是怎樣變化的。我們從“慢開始算法”講起。

   慢開始算法的思路是這樣的。當主機開始發送數據時，如果立即把大量數據字節注入到網絡，那么就有可能引起網絡擁塞，因為現在井不清楚網絡的負荷情況。經驗證明，較好的方法是先探測一下，即由小到大逐漸增大發送窗口，也就是說，由小到大逐漸增大擁塞窗口數值。通常在剛剛開始發送報文段時，先把擁塞窗口cwnd設置為一個最大報文段MSS的數值u一。而在每收到一個對新的報文段的確認后，把擁塞窗口增加至多一個MSS的數值。用這樣的方法逐步增大發送方的擁塞窗口cwnd，可以使分組注入到網絡的速率更加合理。

   下面用例子說明慢開始算法的原理。為方便起見，我們用報文段的個數作為窗口大小的單位（請注意，實際上TCP是用字節作為窗口的單位），這樣可以使用較小的數字來說明擁塞控制的原理。

   在一開始發送方先設置cwnd=1，發送第一個報文段Mi，接收方收到后確認Mi。發送方收到對M．的確認后，把cwnd從1增大到2，于是發送方接著發送M2和M3兩個報文段。接收方收到后發回對M2和M，的確認。發送方每收到一個對新報文段的確認（重傳的不算在內）就使發送方的擁塞窗口加1，因此發送方在收到兩個確認后，cwnd就從2增大到4，并可發送M4～M7共4個報文段（見圖5-24）。因此使用慢開始算法后，每經過一個傳輸輪次(transmission round)，擁寒窗口cwnd就加倍。