在沒有使用滑動窗口之前，超時重發機制大概是這樣子的：

根據數據包的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.此時發送端會停止發包。在接收到發送窗口的更新通知之后通信才得以繼續。但是如果更新通知在途中丟失那通信豈不是中斷了？不然，發送端會時不時的發送一個窗口探測的數據包，來獲取接收端窗口大小的最新值。

---

如果網絡出現擁塞，分組將會丟失，此時發送方會繼續重傳，從而導致網絡擁塞程度更高。因此當出現擁塞時，應當控制發送方的速率。這一點和流量控制很像，但是出發點不同。流量控制是為了讓接收方能來得及接收，而擁塞控制是為了降低整個網絡的擁塞程度。

?

?

?

?

?

?

?

總結

以上是生活随笔為你收集整理的网络：窗口控制下的重发机制、流量控制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。