首先我們來看實際生活中這樣乙個例項，大人喂小孩子吃飯，如果孩子嘴裡還有飯，孩子表示不想吃了，但大人還是繼續喂。喂多了。這樣就會給孩子留下乙個完整的不愉快童年。
那麼在使用tcp協議的雙方端系統中，傳送方就像餵飯的大人，而接收方就是孩子，傳送方傳送的量應該由接收方來決定或者說來調節。
二—tcp流量控制（flow control）的產生原因以及控制手段
讓傳送方不要太快，以免接收方接收不過來。滑動視窗就是控制手段。
上圖即為滑動視窗，圖示滑動視窗大小為400，滑動視窗由接收方調節。
三—例項說明
在看下圖之前，我們首先必須搞清楚這樣幾個專有名詞的含義
1—seq(順序;序號;初始序號;序列號;排列機)：是tcp報文段首部中的序號字段，取值為1則表示tcp報文段資料載荷的第乙個位元組的序號為1，取值為101表示tcp報文段資料載荷的第乙個位元組的序號為101；
2—data：表示tcp報文段；
3—ack(acknowledge character 接收字元)：表示tcp報文段首部中的標識位，取值為1表示是乙個確認報文段，為0表示報文中不包含確認資訊，忽略確認號字段。
4—ack:表示tcp報文段中的確認號字段，取值為x表示傳送方傳送的x部分的位元組已經確認收到；
5—rwnd(receive window):滑動視窗的英文名；滑動視窗也可理解為接收視窗。
四—死鎖的產生和解決
思考這樣乙個問題，當接收方傳送給傳送方的確認報文段丟失，而它一直傻傻的以為報文段成功被接收方接收，滿懷期待的等著接收方傳送新的報文段給它。然而另一邊，傳送方一直等待著接收方傳送的確認報文段，好繼續傳送新的報文段給接收方，然而確認報文段在路上的時候就走丟了。於是雙方陷入千年的等待。這就是死鎖（死鎖在計算機作業系統中也出現了這個概念，思想和計算機網路的大致相同）。這個時候就需要乙個來解決問題的調節員。持續計時器就是這樣乙個調解員，若超時了，傳送方傳送乙個大小為1位元組的0視窗探測報文段。如果接收方回答為當前的接收視窗為0，則傳送方繼續等待，等待一會後，如果接收方的接收快取有了空閒，則傳送能接受多大的接收視窗（rwnd）給傳送方，傳送方按照接收方回答的值調整滑動視窗繼續去傳送報文段。
朋友們可能會有這樣乙個疑問，既然接收方的接收視窗都為0了，那就應該什麼都收不到才對，為什麼能收到傳送傳送的0視窗探測報文段並且返回確認呢？ 這是因為tcp規定，即使接收視窗為0，接收方必須無條件的接收0視窗探測報文段，攜帶緊急資料的報文段，確認報文段。
繼續思考這樣乙個問題：如果0視窗檢測報文段丟失了，會出現什麼問題？還能打破死鎖的局面嗎？回答是肯定的，因為0視窗探測報文段本身帶有重傳計時器，如果重傳計時器超時，則重新傳送0視窗探測報文段
TCP流量控制
一般來說，我們總是希望資料傳輸的更快一些，但如果傳送方把資料傳送的很快，而接收方來不及接收，這就可能造成資料的丟失。流量控制就是讓傳送方的傳送速率不要太快，讓接收方來得及接收。對於成塊資料流，tcp利用滑動視窗機制來實現流量的控制，對於互動資料流，tcp利用捎帶ack和nagle演算法來實現流量的控...
TCP流量控制
如果傳送端傳送的速度較快，接收端接收到資料後處理的速度較慢，而接收緩衝區的大小是固定的，就會丟失資料。tcp協議通過 滑動視窗 sliding window 機制解決這一問題。滑動視窗 傳送端發起連線，宣告最大段尺寸是1460，初始序號是0，視窗大小是4k，表示 我的接收緩衝區還有4k位元組空閒，你...
TCP流量控制
流量控制 一般來說，我們總是希望資料傳輸的更快一些，但如果傳送方把資料傳送的很快，而接收方來不及接收，這就可能造成資料的丟失。流量控制就是讓傳送方的傳送速率不要太快，讓接收方來得及接收。對於成塊資料流，tcp利用滑動視窗機制來實現流量的控制，對於互動資料流，tcp利用捎帶ack和nagle演算法 來...