滑動視窗與流量控制 擁塞控制

2021-10-12 09:37:12 字數 1617 閱讀 2680

每個tcp連線的兩端都維護一組視窗:傳送視窗結構(send window structure)和接收視窗結構(receive window structure)。tcp以位元組為單位維護其視窗結構。tcp頭部中的視窗大小字段相對ack號有乙個位元組的偏移量。傳送端計算其可用視窗,即它可以立即傳送的資料量。可用視窗(允許傳送但還未傳送)計算值為提供視窗(即由接收端通告的視窗)大小減去在傳(已傳送但未得到確認)的資料量。圖中p1、p2、p3分別記錄了視窗的左邊界、下次傳送的序列號、右邊界。

如上圖所示, 隨著傳送端接收到返回的資料ack,滑動視窗也隨之右移。傳送端根據接收端返回的ack可以得到兩個重要的資訊:一是接收端期望收到的下乙個位元組序號;二是當前的視窗大小(再結合傳送端已有的其他資訊可以得出還能傳送多少位元組資料)。

擁塞控制:防止過多的資料注入到網路中,這樣可以使網路中的路由器或鏈路過載。

擁塞控制是乙個全域性性的過程,涉及到所有的主機、路由器,以及與降低網路傳輸效能有關的所有因素。

註解:通過「傳送方的擁塞視窗cwnd」、「慢開始門限值ssthresh」實現擁塞控制

慢開始— cwnd從1開始,按照2的指數倍增大

擁塞避免— 網路擁塞時:將門限值減半,cwnd設為1,再執行慢開始演算法

快重傳(返回的是同一序列化的三次確認,就認為下乙個序列包丟失了)

1.如果包m丟失:接收方重**送前乙個包(m-1)的ack;

2.傳送方收到3個重複的ack後(說明包丟失),無需等待超時定時器到時就直接重發丟失的包

詳細過程:接收方收到了m1和m2後,都分別發出了確認。現在假定接收方沒有收到m3但接著收到了m4。顯然,接收方不能確認m4,因為m4是收到的失序報文段。根據可靠傳輸原理,接收方可以什麼都不做,也可以在適當時機傳送一次對m2的確認。但按照快重傳演算法的規定,接收方應及時傳送對m2的重複確認,這樣做可以讓傳送方盡早知道報文段m3沒有到達接收方。傳送方接著傳送了m5和m6。接收方收到這兩個報文後,也還要再次發出對m2的重複確認。這樣,傳送方共收到了接收方的四個對m2的確認,其中後三個都是重複確認。快重傳演算法還規定,傳送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段m3,而不必繼續等待m3設定的重傳計時器到期。⇒ ⇒ ⇒ 由於傳送方盡早重傳未被確認的報文段,因此採用快重傳後可以使整個網路吞吐量提高約20%。

快恢復(重傳完成後,擁塞視窗線性增長)

與快重傳配合使用的還有快恢復演算法,其過程有以下兩個要點:

<1>. 當傳送方連續收到三個重複確認,就執行「乘法減小」演算法,先把慢開始門限ssthresh減半

<2>. 再把cwnd值設定為慢開始門限ssthresh減半後的數值,然後開始執行擁塞避免演算法(「加法增大」),使擁塞視窗cwnd緩慢地線性增大。

TCP之滑動視窗,流量控制和擁塞控制

是在可靠性的前提下,讓我們進一步提高傳輸效率。所謂視窗 就是不等待ack的情況下,批量傳送的最大資料量,就叫 視窗大小。上面的視窗大小就是4000。滑動 視窗範圍表示哪些資料在等待ack,隨著乙個ack的到達,就立刻傳送下乙個資料,等待範圍就逐漸向後滑動。視窗越大,傳輸效率越高,但也不能無限大。在這...

TCP視窗控制 流量控制 擁塞控制

tcp以1個段為單位,每發乙個資料段進行一次ack確認應答的處理,這樣的傳輸方式由乙個缺點,就是包的往返時間越長通訊的效能越差。解決這個問題,提高速度,tcp引入了視窗控制這個概念。具體做法就是連續傳送上限為視窗大小的資料,然後再乙個乙個ack確認。即使在往返時間較長的情況下,它也能控制網路效能的下...

流量控制 滑動視窗

1.流量控制 我們都知道當網路上資料流量超過網路硬體負荷時就會出現網路擁塞,就是我們平常遇到的網路緩慢的現象。對應影響網路速度的原因主要有網路傳輸裝置的效能和傳輸的資料多少,網路傳輸裝置包含傳送接收主機 路由器 傳輸線路等。為了解決這個問題,tcp引入了流量控制,顧名思義,就是採用某種方法,控制收發...