本節課我們介紹 TCP 的流量控制：
- 一般來說我們總是希望資料傳輸的更快一些
- 但如果傳送方把資料傳送的過快，接收方就可能來不及接收，這就會造成資料的丟失
- 所謂流量控制就是讓傳送方的傳送速率不要太快，要讓接收方來得及接收
- 利用滑動視窗機制，可以很方便的在 TCP 連線上實現對傳送方的流量控制
我們來舉例說明，假設主機 A 和 B 是因特網上的兩臺主機，它們之間已經建立了 TCP 連線，A 給 B 傳送資料，B 對 A 進行流量控制，這是主機 A 中帶傳送資料的位元組序號，假設主機 A 傳送的每個 TCP 報文段可攜帶 100 位元組資料，因此圖中每個小格子表示 100 個位元組資料的序號，在主機 A 和 B 建立 TCP 連線時，B 告訴 A 我的接收視窗為 400，因此主機 A 將自己的傳送視窗也設定為 400，這意味著主機 A 在未收到主機 B 發來的確認時，可將序號落入傳送視窗中的全部資料傳送出去。。
接下來我們舉例說明主機 B 對 A 的流量控制，主機 A 將傳送視窗內序號 1~100 的資料，封中成一個 TCP 報文段傳送出去，傳送視窗內還有 300 位元組可以傳送。
這裡的 seq 是 TCP 報文段首部中的序號欄位，取值一，表示 TCP 報文段資料載荷的第一個位元組的序號是一。
這裡的 DATA 表示這是 TCP 資料包文段，主機 A 將傳送視窗內序號 101~200 的資料，封中成一個 TCP 報文段傳送出去，傳送視窗內還有 200 位元組可以傳送，主機 A 將傳送視窗內，序號 201~300 的資料，封中成一個 TCP 報文段傳送出去，但該報文段在傳輸過程中丟失了，主機 A 傳送視窗內還有 100 位元組可以傳送。
主機 B 對主機 A 所傳送的 201 號以前的資料進行累計確認，並在該累計確認中將視窗欄位的值調整為 300，也就是對主機 A 進行流量控制。這裡的大寫 ACK 是 TCP 報文段首部中的標誌位，取值一，表示這是一個 TCP 確認報文段，小寫 ack 是 TCP 報文段首部中的確認號欄位，取值 201，表示序號 201 之前的資料已全部正確接收，現在希望收到序號 201 及其後續資料。
RWND 是 TCP 報文段首部中的視窗欄位，取值 300，表示自己的接收視窗大小為 300。主機 A 收到該累計確認後，將傳送視窗向前滑動，使已傳送並收到確認的這些資料的序號，移出傳送視窗。
由於主機 B 在該累計確認中，將自己的接收視窗調整為了 300，因此主機 A 相應的將自己的傳送視窗調整為 300。目前主機 A 傳送視窗內的序號為 201~500，也就是主機 A 還可以傳送這 300 位元組，其中 201~300 號位元組是已傳送的資料，若重傳計時器超時，他們會被重傳。301 號到 400 號位元組，以及 401 號到 500 號位元組還未被髮送，可被分別封中在一個 TCP 報文段中傳送。主機 A 現在可將傳送快取中序號 1~200 的位元組資料全部刪除了，因為已經收到了主機 B 對他們的累計確認。
主機 A 將傳送視窗內序號 301~400 個資料，封中成一個 TCP 報文段傳送出去，傳送視窗內還有 100 位元組可以傳送，主機 A 將傳送視窗內序號 401~500 的資料，封中成一個 TCP 報文段傳送出去，至此序號落在傳送視窗內的資料已經全部傳送出去了，不能再傳送新資料了。
現在傳送視窗內序號 201~300，這 100 個位元組資料的重傳計時器超時了，主機 A 將它們重新封中成一個 TCP 報文段傳送出去，暫時不能傳送其他資料。
主機 B 收到該重傳的 TCP 報文段後，對主機 A 所傳送的 501 號以前的資料進行累計確認，並在該累計確認中將視窗欄位的值調整為 100。這是主機 B 對主機 A 進行的第二次流量控制。
主機 A 收到該累計確認後，將傳送視窗向前滑動，使已傳送並收到確認的這些資料的序號，移出傳送視窗。由於主機 B 在該累計確認中將自己的接收視窗調整為了 100，因此主機 A 相應的將自己的傳送視窗調整為 100。
目前主機 A 發動視窗內的序號為 501~600，也就是主機 A 還可以傳送這 100 位元組，主機 A 現在可將傳送快取中序號 201~500 的位元組資料全部刪除了，因為已經收到了主機 B 對他們的累積確認，主機 A 將傳送視窗內序號 501~600 的資料，封中成一個 TCP 報文段傳送出去，至此序號落在傳送視窗內的資料已經全部傳送出去了，不能再傳送新資料了。
主機 B 對主機 A 所傳送的 601 號以前的資料進行累計確認，並在該領域確認中將視窗欄位的值調整為 0。這是主機 B 對主機 A 進行的第三次流量控制。
主機 A 收到該累計確認後，將傳送視窗向前滑動，使已傳送並收到確認的這些資料的序號，移出傳送視窗。由於主機 B 在該累計確認中將自己的接收視窗調整為了 0，因此主機 A 相應的將自己的傳送視窗調整為 0。
目前主機 A 不能再傳送一般的 TCP 報文段了，主機 A 現在可將傳送快取中序號 501~600 的位元組資料全部刪除了，因為已經收到了主機幣被他們的累計確認，假設主機 B 向主機 A 傳送了 0 視窗的報文段後不久，主機 B 的接收快取又有了一些儲存空間，於是主機 B 向主機 A 傳送了接收視窗等於 300 的報文段，然而這個報文段在傳輸過程中丟失了，主機 A 一直等待主機 B 傳送的非 0 視窗的通知，而主機 B 也一直等待主機 A 傳送的資料，如果不採取措施，這種互相等待而形成的死鎖局面將一直持續下去。
為了解決這個問題，TCP 為每一個連線設有一個持續計時器，只要 TCP 連線的一方，收到對方的 0 視窗通知，就要起到持續計時器。若持續計時器超時，就要傳送一個 0 視窗探測報文，僅攜帶一位元組的資料，而對方在確認這個探測報文段時，給出自己現在的接收視窗值。如果接收視窗仍然是 0，那麼收到報文段的一方要重新啟動持續計時器，如果接收視窗不是 0，那麼死鎖的局面就可以被打破了。
在本例中，主機 A 收到零視窗通知時，就要啟動一個持續計時器，當持續計時器超時，主機 A 立刻傳送一個僅攜帶一位元組資料的零視窗探測保溫段，假設主機 B 此時的接收視窗又為 0 了，主機 B 就在確認零視窗探測報文段時，給出自己現在的接收視窗值為零。
主機 A 再次收到零視窗通知，就要再次啟動一個持續計時器，當持續計時器超時，主機 A 立刻傳送一個零視窗探測報文段，假設主機 B 此時的接收快取又有了一些儲存空間，於是將自己的接收視窗調整為了 300，主機 B 就在確認零視窗探測報文段時，給出自己現在的接收視窗值為 300，這樣就打破了死鎖的局面。
同學們可能會有這樣的疑問，主機 A 所傳送的零視窗探測報文段到達主機 B 時，如果主機 B 此時的接收視窗仍然為 0，那麼主機 B 根本就無法接受該報文段，又怎麼會針對該報文段給主機 A 發回確認呢？實際上 TCP 規定即使接收視窗為 0，也必須接受零視窗探測報文段，確認報文段，以及攜帶有緊急資料的報文段。
請大家再來思考一下這個問題。如果零視窗探測報文段丟失了，會出現怎樣的問題呢？還能否打破死鎖的局面呢？回答是肯定的，因為零視窗探測報文段也有重傳計時器，當重傳計時器超時後，零視窗探測報文段會被重傳。
接下來我們來做一個相關的練習題，這是計算機專業考研全國統考計算機網路部分 2010 年的題 39，由於該題涉及到了我們還未學習的擁塞控制的內容，因此我們需要先做一些說明，然後再請同學們來完成。
TCP 傳送方的傳送視窗，實際上是在自身的擁塞視窗和 TCP 接收方的接收視窗中取小者。而在我們本節課的舉例中，為了簡單起見，我們忽略了擁塞控制，也就是認為 TCP 傳送方的傳送視窗等於接收方的接收視窗。本題未給出 TCP 傳送方的傳送視窗的初始值，則我們取擁塞視窗值作為傳送視窗值。
答案是選項 A。我們來一起畫圖分析一下，這是主機假中帶傳送資料的序號。根據題意可知，主機甲的發動視窗為 4000 位元組，主機甲向主機乙連續傳送兩個最大段，共 2000 位元組，也就是將傳送視窗內，序號 0~1999 的位元組資料傳送出去，主機乙給主機甲傳送針對第一個段的確認，並在該確認中給出自己當前的接收視窗大小為 2000 位元組，主機甲收到該確認後，將傳送視窗向前滑動，使已傳送並收到確認的第一個段的序號移出傳送視窗。由於主機乙在確認中給出的自己的接收視窗大小為 2000 位元組，因此主機甲相應的將自己的傳送視窗調整為 2000 位元組，很顯然主機甲還可以向主機乙傳送 2000~2999 號位元組資料，共 1000 個位元組。
本節課的內容小結如下：
