為了提高通道的利用率tcp協議不使用停止等待協議，而是使用連續arq協議，意思就是可以連續發出若干個分組然後等待確認，而不是傳送乙個分組就停止並等待該分組的確認。
tcp的兩端都有傳送/接收快取和傳送/接收視窗。tcp的快取是乙個迴圈佇列，其中傳送視窗可以用3個指標表示。而傳送視窗的大小受tcp資料報中視窗大小的影響，tcp資料報中的視窗大小是接收端通知傳送端其還可以接收多少資料，所以傳送視窗根據接收的的視窗大小的值動態變化。
以下的幾張就幫助理解一下滑動視窗的機制：
注意上圖中的3個指標p1、p2、p3！此時接收視窗中接收的資料可能是失序的，但是也先儲存在接收快取之中。傳送確認號的時候依然傳送31，表示b期望接收的下乙個資料報的標示符是31。
當b收到31後連同之前接收到的資料報，傳送確認號34，此時a的滑動視窗可以向前移動了。
如果傳送視窗中的資料報都屬於已傳送但未被確認的話，那麼a就不能再繼續傳送資料，而需要進行等待。
所謂流量控制就是讓傳送傳送速率不要過快，讓接收方來得及接收。利用滑動視窗機制就可以實施流量控制。
原理這就是運用tcp報文段中的視窗大小欄位來控制，傳送方的傳送視窗不可以大於接收方發回的視窗大小。
考慮一種特殊的情況，就是接收方若沒有快取足夠使用，就會傳送零視窗大小的報文，此時傳送放將傳送視窗設定為0，停止傳送資料。之後接收方有足夠的快取，傳送了非零視窗大小的報文，但是這個報文在中途丟失的，那麼傳送方的傳送視窗就一直為零導致死鎖。
解決這個問題，tcp為每乙個連線設定乙個持續計時器（persistence timer）。只要tcp的一方收到對方的零視窗通知，就啟動該計時器，週期性的傳送乙個零視窗探測報文段。對方就在確認這個報文的時候給出現在的視窗大小（注意：tcp規定，即使設定為零視窗，也必須接收以下幾種報文段：零視窗探測報文段、確認報文段和攜帶緊急資料的報文段）。
tcp的資料傳輸分為互動資料流和成塊資料流，互動資料流一般是一些互動式應用程式的命令，所以這些資料很小，而考慮到tcp報頭和ip報頭的總和就有40位元組，如果資料量很小的話，那麼網路的利用效率就較低。
資料傳輸使用nagle演算法，nagle演算法很簡單，就是規定乙個tcp連線最多只能有乙個未被確認的未完成的小分組。在該分組的確認到達之前不能傳送其他的小分組。
但是也要考慮另乙個問題，叫做糊塗視窗綜合症。當接收方的快取已滿的時候，互動應用程式一次只從快取中讀取乙個位元組（這時候快取中騰出乙個位元組），然後向傳送方傳送確認資訊，此時傳送方再傳送乙個位元組（收到的視窗大小為1），這樣網路的效率很低。
素以要解決這個問題，可以讓接收方等待一段時間，使得接收快取已有最夠的空間容納乙個最長報文段，或者等到接收快取已有一半的空間。只要這兩種情況出現一種，就傳送確認報文，同時傳送方可以把資料積累成大的報文段傳送。
**：
TCP流量控制
一般來說，我們總是希望資料傳輸的更快一些，但如果傳送方把資料傳送的很快，而接收方來不及接收，這就可能造成資料的丟失。流量控制就是讓傳送方的傳送速率不要太快，讓接收方來得及接收。對於成塊資料流，tcp利用滑動視窗機制來實現流量的控制，對於互動資料流，tcp利用捎帶ack和nagle演算法來實現流量的控...
TCP流量控制
如果傳送端傳送的速度較快，接收端接收到資料後處理的速度較慢，而接收緩衝區的大小是固定的，就會丟失資料。tcp協議通過 滑動視窗 sliding window 機制解決這一問題。滑動視窗 傳送端發起連線，宣告最大段尺寸是1460，初始序號是0，視窗大小是4k，表示 我的接收緩衝區還有4k位元組空閒，你...
TCP流量控制
流量控制 一般來說，我們總是希望資料傳輸的更快一些，但如果傳送方把資料傳送的很快，而接收方來不及接收，這就可能造成資料的丟失。流量控制就是讓傳送方的傳送速率不要太快，讓接收方來得及接收。對於成塊資料流，tcp利用滑動視窗機制來實現流量的控制，對於互動資料流，tcp利用捎帶ack和nagle演算法 來...