在沒有使用滑動視窗之前，超時重發機制大概是這樣子的：
根據資料報的rtt和時間偏差計算出粗略的rto，當乙個資料報傳送之後，在rto時間內還沒有返回確認ack時，傳送端就認為該資料報已經丟失，並進行重傳。
這裡有兩種情況：
1）資料報真真切切地沒有被接收端接收到。
2）資料報已經被接受但是ack在返回途中丟失。
不管哪種情況，此時傳送端都會進行重傳。按照2的指數時間間隔進行重發，指定重發次數。如果還沒有收到ack，那麼就認為該通訊主機異常，強制關閉連線，終止通訊。
如果是第二種情況，有人會說，傳送端一直重發相同的包。接收端怎麼辦，會一直接收到相同的包啊，因為是ack丟失啊
這裡就引入了序列號的概念了，也就是說，序列號的概念也解決了這個問題。通過序列號，可以判斷當前資料報是不是重複接收到的，是否需要接受！
目前tcp連線採用滑動視窗機制。使用滑動視窗下資料丟失又該怎麼辦呢？
首先明確為什麼使用滑動視窗機制？
試想一下，每個資料報的收發都要經過傳送----返回ack---再傳送這個流程的話。那麼就會出現包的往返時間越長，網路的吞吐量就會越差！而且網路環境都是時時刻刻在變化的，包的rtt都是在變化的，這會導致通訊很不可靠！
因此，引入滑動視窗機制.。也就是傳送方可以在未接受到乙個資料報的ack時繼續傳送下乙個資料報。在滑動視窗內的資料段都可以同時傳送。這樣一來就明顯的提高了效率，提公升了吞吐量。
在視窗機制下，也會出現超時重傳的問題。也有兩種情況：
1）資料報真真切切地沒有被接收端接收到。
2）資料報已經被接受但是ack在返回途中丟失。
在第一種情況下，假如第乙個包沒有接收到ack(第乙個包的為1~1000)，那麼傳送端再繼續傳送下乙個包的時候，接收端會一直傳送ack（1001），傳送端接收到超過3次ack（1001）就認為該報文丟失，進行重發！
第二種情況下，視窗在比較大的時候，即使有少量的ack沒有接收到也不會進行資料重發，因為可以通過下乙個確認應答進行確認。
引入了視窗機制之後，不免出現流量控制。
試想，當傳送端的視窗比較大的時候，接收端會出現會出現緩衝區溢位的問題，這樣一來接收端就會丟棄有用的資料報。這就有引發重傳機制，從而導致網路流量的無端浪費。
其實視窗機制就是傳送端和接收端在進行三次握手的時候交換自己的視窗大小。使得傳送端可以根據接收端的實際接受能力控制傳送的資料量。這個數值在資料報互動的過程中是動態變化的。
當接受端緩衝區滿的時候，傳送給傳送端的ack中通告視窗的值為0.此時傳送端會停止發包。在接收到傳送視窗的更新通知之後通訊才得以繼續。但是如果更新通知在途中丟失那通訊豈不是中斷了？不然，傳送端會時不時的傳送乙個視窗探測的資料報，來獲取接收端視窗大小的最新值。
如果網路出現擁塞，分組將會丟失，此時傳送方會繼續重傳，從而導致網路擁塞程度更高。因此當出現擁塞時，應當控制傳送方的速率。這一點和流量控制很像，但是出發點不同。流量控制是為了讓接收方能來得及接收，而擁塞控制是為了降低整個網路的擁塞程度。
流量控制 滑動視窗
1.流量控制 我們都知道當網路上資料流量超過網路硬體負荷時就會出現網路擁塞，就是我們平常遇到的網路緩慢的現象。對應影響網路速度的原因主要有網路傳輸裝置的效能和傳輸的資料多少，網路傳輸裝置包含傳送接收主機 路由器 傳輸線路等。為了解決這個問題，tcp引入了流量控制，顧名思義，就是採用某種方法，控制收發...
TCP的流量控制機制與滑動視窗
所謂的流量控制，就是告誡對方傳送速率不要太快，要讓接收來來得及接收資料。形容如下 甲向乙傳送資料。經過tcp三握手連線以後，當乙告訴甲 我的接受視窗rwnd 400 這裡rwnd表示receiver window的意思 所以，傳送方的傳送視窗不能超過接收方給出的接受視窗的數值。而tcp視窗的單位是位...
滑動視窗 TCP流量控制
問題 如果傳送端傳送的速度較快，接收端接收到資料後處理的速度較慢，而接收緩衝區的大小是固定的，就會丟失資料。tcp協議通過 滑動視窗 sliding window 機制解決這一問題。看下圖的通訊過程 1.傳送端發起連線，宣告最大段尺寸是 1460 初始序號是 0，視窗大小是 4k，表示 我的接收緩衝...