TCP的流量控制
一—導讀
首先我們來看實際生活中這樣一個實例，大人喂小孩子吃飯，如果孩子嘴裏還有飯，孩子表示不想吃了，但大人還是繼續喂。喂多了。這樣就會給孩子留下一個完整的不愉快童年。
那麼在使用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窗口探測報文段
