主頁 > 軟體設計 > 你知道TCP的重傳機制、滑動視窗、流量控制、擁塞控制嗎?

你知道TCP的重傳機制、滑動視窗、流量控制、擁塞控制嗎?

2021-10-22 07:35:31 軟體設計

TCP的四大機制

  • 一、重傳機制
    • 超時重傳
      • TCP以下兩種情況會發生超時重傳
      • 超時時間的設定
      • 連續發生超時重傳
    • 快速重傳
      • SACK
      • Duplicate SACK
        • D-SACK的好處
  • 二、滑動視窗
    • 累計應答模式
    • 視窗大小決定方
    • 發送方的視窗
    • 接收方的視窗
  • 三、流量控制
    • 作業系統緩沖區與滑動視窗的關系
    • 視窗關閉
      • 視窗關閉存在的問題
        • 死鎖
          • 視窗探測
        • 糊涂視窗綜合癥
          • 避免小視窗通知
            • 接收方策略
            • 發送方策略
  • 四、擁塞控制
    • 擁塞視窗
    • 擁塞控制演算法
      • 慢啟動
    • 擁塞避免演算法
    • 擁塞發生演算法
      • 發生超時重傳的擁塞發生演算法
      • 發生快速重傳的擁塞發生演算法
      • 快速恢復
  • 五、TCP延遲確認

一、重傳機制

TCP針對資料包丟失的情況,會用重傳機制解決,

超時重傳

超時重傳:就是在發送資料時,設定?個定時器,當超過指定的時間后,沒有收到對方的ACK確認應答報文,就會重發該資料,
在這里插入圖片描述

TCP以下兩種情況會發生超時重傳

  • 資料包丟失
  • ACK應答報文丟失

超時時間的設定

RTT:包的往返時間,
超時重傳時間是以RTO (Retransmission Timeout 超時重傳時間)表示,

  • 當超時時間 RTO 較大時,重發就慢,丟了老半天才重發,沒有效率,性能差
  • 當超時時間RTO較小時,會導致可能并沒有丟就重發,于是重發的就快,會增加網路擁塞,導致更多的超時,更多的超時導致更多的重發,

超時重傳時間RTO的值應該略大于報文往返RTT的值,
但是實際上,網路是波動的,所以RTT也是在變化的,那么也意味著RTO也應該是動態變化的,為此TCP通過采用資料進行處理

  • 采樣RTT的時間,加權平均,算出一個平滑的RTT的值,這個值也在不斷變化
  • 采樣RTT的波動范圍,

連續發生超時重傳

如果超時重發的資料,再次超時的時候,?需要重傳的時候,TCP的策略是超時間隔加倍, 也就是每當遇到?次超時重傳的時候,都會將下?次超時時間間隔設為先前值的兩倍,兩次超時,就說明網路環境差,不宜頻繁反復發送,

快速重傳

快速重傳的作業方式是當收到三個相同的ACK報文時,會在定時器過期之前,重傳丟失的報文段,
在這里插入圖片描述

SACK

在TCP頭部選項欄位里加?個SACK的東西,它可以將快取的地圖發送給發送方,這樣發送方就可以知道哪些資料收到了,哪些資料沒收到,知道了這些資訊,就可以只重傳丟失的資料,
在這里插入圖片描述
如果要支持SACK ,必須雙?都要支持,在 Linux 下,可以通過 net.ipv4.tcp_sack引數打開這個功能(Linux 2.4 后默認打開),

Duplicate SACK

Duplicate SACK稱D-SACK ,其主要使用了SACK來告訴發送方有哪些資料被重復接收了,
在這里插入圖片描述

D-SACK的好處

  • 可以方發送方知道,是發出的包丟了,還是接受方回應的ACK的包丟了
  • 可以知道發送方的資料包被網路延遲了
  • 可以知道網路中是不是把發送方的資料包給復制了

在 Linux 下可以通過 net.ipv4.tcp_dsack 引數開啟/關閉這個功能(Linux 2.4 后默認打開)

二、滑動視窗

資料包的往返時間越長,通信的效率就越低,那么有了視窗,就可以指定視窗大小,視窗大小就是指無需等待確認應答,而可以繼續發送資料的最?值,

累計應答模式

假設視窗大小為3個TCP 段,那么發送方就可以連續發送3個TCP段,并且中途若有ACK丟失,可以通過下?個確認應答進行確認,
在這里插入圖片描述
圖中即使ACK 600丟失了也沒關系,因為可以通過下?個確認應答進行確認,只要發送方收到了ACK 700 確認應答,就意味著 700 之前的所有資料接收方都收到了,這個模式就叫累計確認或者累計應答,

視窗大小決定方

TCP頭里有?個欄位叫Window ,也就是視窗大小,
這個欄位是接收端告訴發送端自己還有多少緩沖區可以接收資料,于是發送端就可以根據這個接收端的處理能力來發送資料,而不會導致接收端處理不過來,
所以,通常視窗的大小是由接收方的視窗大小來決定的, 發送方發送的資料大小不能超過接收方的視窗大小,否則接收方就無法正常接收到資料,

發送方的視窗

在這里插入圖片描述

接收方的視窗

在這里插入圖片描述

三、流量控制

流量控制主要是通過對視窗的大小的控制實作的,

作業系統緩沖區與滑動視窗的關系

假定了發送視窗和接收視窗是不變的,但是實際上,發送視窗和接收視窗中所存放的位元組數,都是放在作業系統記憶體緩沖區中的,而作業系統的緩沖區,會被作業系統調整,
TCP規定是不允許同時減少快取又收縮視窗的,而是采用先收縮視窗,過段時間再減少快取,這樣就可以避免了丟包情況,

視窗關閉

TCP 通過讓接收方指明希望從發送方接收的資料大小(視窗大小)來進行流量控制, 如果視窗大小為 0 時,就會阻止發送方給接收方傳遞資料,直到視窗變為非 0 為止,這就是視窗關閉,

視窗關閉存在的問題

死鎖

當發生視窗關閉時,接收方處理完資料后,會向發送方通告?個視窗非0的ACK報文,如果這個通告視窗的ACK報文在網路中丟失了,那麻煩就大了,這會導致發送方?直等待接收方的非0視窗通知,接收方也?直等待發送方的資料,如不采取措施,這種相互等待的程序,會造成了死鎖的現象,

視窗探測

為了解決這個問題,TCP為每個連接設有?個持續定時器,只要TCP連接一方收到對方的零視窗通知,就啟動持續計時器, 如果持續計時器超時,就會發送窗?探測 ( Window probe ) 報文,而對方在確認這個探測報文時,給出自己現在的接收視窗大小,

  • 如果接收視窗仍然為0,那么收到這個報文的一方就會重新啟動持續計時器
  • 如果接收視窗不是0,那么死鎖的局?就可以被打破了

視窗探測的次數?般為3次,每次大約 30-60 秒(不同的實作可能會不?樣),如果3次過后接收視窗還是0的話,有的 TCP 實作就會發 RST 報文來中斷連接,這些視窗探測報文以 3.4s、6.5s、13.5s 的間隔出現,說明超時時間會翻倍遞增,

糊涂視窗綜合癥

如果接收方太忙了,來不及取走接收視窗里的資料,那么就會導致發送方的發送視窗越來越小, 到最后,如果接收方騰出幾個位元組并告訴發送方現在有幾個位元組的視窗,而發送方會義無反顧地發送這幾個位元組, 這就是糊涂視窗綜合癥,
要知道,我們的TCP + IP頭有40個位元組,為了傳輸那幾個位元組的資料,要達上這么?的開銷,這太不經濟了,

避免小視窗通知
接收方策略

當視窗大小于min( MSS,快取空間/2 ) ,也就是小于MSS與1/2快取中的最小值時,就會向發送方通告視窗為0 ,也就阻止了發送方再發資料過來,等到接收方處理了?些資料后,視窗大小 >= MSS,或者接收方快取空間有?半可以使用,就可以把視窗打開讓發送方發送資料過來,

發送方策略

Nagle演算法:延時處理

  • 等到視窗大小 >= MSS 或者資料大小 >= MSS
  • 沒有已發送未確認報文時,立刻發送資料

只要沒滿足上面條件中的?條,發送方?直在囤積資料,直到滿足上面的發送條件,

四、擁塞控制

在網路出現擁堵時,如果繼續發送大量資料包,可能會導致資料包時延、丟失等,這時TCP就會重傳資料,但是?重傳就會導致網路的負擔更重,于是會導致更大的延遲以及更多的丟包,這個情況就會進?惡性回圈被不斷地放大…所以,TCP不能忽略網路上發生的事,它被設計成?個無私的協議,當網路發送擁塞時,TCP會自我犧牲,降低發送的資料量, 于是,就有了擁塞控制,控制的目的就是避免發送方的資料填滿整個網路,

擁塞視窗

擁塞視窗(cwnd)是發送方維護的?個的狀態變數,它會根據網路的擁塞程度動態變化的, 我們在前面提到過發送視窗(swnd) 和接收視窗(rwnd) 是約等于的關系,那么由于加入了擁塞視窗的概念后,此 時發送視窗的值是swnd = min(cwnd, rwnd),也就是擁塞視窗和接收視窗中的最小值,
擁塞視窗cwnd變化的規則:

  • 只要網路中沒有出現擁塞, cwnd就會增大
  • 但網路中出現了擁塞, cwnd就減少

網路是否擁塞 :只要發送方沒有在規定時間內接收到 ACK 應答報文,也就是發生了超時重傳,就會認為網路出現了擁塞,

擁塞控制演算法

慢啟動

慢啟動的演算法記住?個規則就行:當發送方每收到?個ACK,擁塞視窗 cwnd的大下就會加1,
可以看出慢啟動演算法,發包的個數是指數性的增長
那慢啟動漲到什么時候是個頭呢?
有?個叫慢啟動門限 ssthresh (slow start threshold)狀態變數,

  • 當 cwnd < ssthresh 時,使用慢啟動演算法,
  • 當 cwnd >= ssthresh 時,就會使用擁塞避免演算法

?般來說 ssthresh 的大小是 65535 位元組,

擁塞避免演算法

進入擁塞避免演算法后,它的規則是:每當收到?個 ACK 時,cwnd 增加 1/cwnd,我們可以發現,擁塞避免演算法就是將原本慢啟動演算法的指數增堆疊變成了線性增堆疊,還是增長階段,但是增長速度緩慢了?些, 就這么?直增?著后,網路就會慢慢進?了擁塞的狀況了,于是就會出現丟包現象,這時就需要對丟失的資料包進行重傳, 當觸發了重傳機制,也就進入了擁塞發生演算法,

擁塞發生演算法

發生超時重傳的擁塞發生演算法

  • ssthresh設為cwnd/2
  • cwnd重置為1

發生快速重傳的擁塞發生演算法

  • cwnd = cwnd/2 ,也就是設定為原來的?半;
  • ssthresh = cwnd,進?快速恢復演算法

快速恢復

  • 擁塞視窗cwnd = ssthresh + 3 ( 3 的意思是確認有 3 個資料包被收到了)
  • 重傳丟失的資料包
  • 如果再收到重復的 ACK,那么 cwnd 增加 1
  • 如果收到新資料的 ACK 后,把 cwnd 設定為第?步中的 ssthresh 的值,原因是該 ACK 確認了新的資料,說明從 duplicated ACK 時的資料都已收到,該恢復程序已經結束,可以回到恢復之前的狀態了,也即再次進入擁塞避免狀態

五、TCP延遲確認

為了解決 ACK 傳輸效率低問題,所以就衍?出了 TCP 延遲確認
TCP延遲確認的策略

  • 當有回應資料要發送時,ACK 會隨著回應資料?起?刻發送給對方
  • 當沒有回應資料要發送時,ACK 將會延遲?段時間,以等待是否有回應資料可以?起發送
  • 如果在延遲等待發送 ACK期間,對方的第?個資料報文又到達了,這時就會立刻發送ACK
  • TCP延遲確認可以在 Socket 設定 TCP_QUICKACK 選項來關閉這個演算法

當TCP 延遲確認和Nagle演算法混合使用時,會導致時耗增長
要解決這個問題,只有兩個辦法

  • 要不發送方關閉Nagle演算法
  • 要不接收方關閉TCP延遲確認

轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/330258.html

標籤:其他

上一篇:Web測驗技術筆記(web基礎知識)

下一篇:k8s部署express web應用(最新驗證,手把手教學)

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 面試突擊第一季,第二季,第三季

    第一季必考 https://www.bilibili.com/video/BV1FE411y79Y?from=search&seid=15921726601957489746 第二季分布式 https://www.bilibili.com/video/BV13f4y127ee/?spm_id_fro ......

    uj5u.com 2020-09-10 05:35:24 more
  • 第三單元作業總結

    1.前言 這應該是本學期最后一次寫作業總結了吧。總體來說,對作業的節奏也差不多掌握了,作業做起來的效率也更高了。雖然和之前的作業一樣,作業中都要用到新的知識,但是相比之前,更加懂得了如何利用工具以及資料。雖然之間卡過殼,但總體而言,這幾次作業還算完成的比較好。 2.作業程序總結 相比前兩個單元,此單 ......

    uj5u.com 2020-09-10 05:35:41 more
  • 北航OO(2020)第四單元博客作業暨課程總結博客

    北航OO(2020)第四單元博客作業暨課程總結博客 本單元作業的架構設計 在本單元中,由于UML圖具有比較清晰的樹形結構,因此我對其中需要進行查詢操作的元素進行了包裝,在樹的父節點中存盤所有孩子的參考。考慮到性能問題,我采用了快取機制,一次查詢后盡可能快取已經遍歷過的資訊,以減少遍歷次數。 本單元我 ......

    uj5u.com 2020-09-10 05:35:48 more
  • BUAA_OO_第四單元

    一、UML決議器設計 ? 先看下題目:第四單元實作一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖,順序圖,狀態圖分析器 MyUmlInteraction,實際上我們要建立一個有向圖模型,UML中的物件(元素)可能與同級元素連接,也可與低級元素相連形成 ......

    uj5u.com 2020-09-10 05:35:54 more
  • 6.1邏輯運算子

    邏輯運算子 1. && 短路與 運算式1 && 運算式2 01.運算式1為true并且運算式2也為true 整體回傳為true 02.運算式1為false,將不會執行運算式2 整體回傳為false 03.只要有一個運算式為false 整體回傳為false 2. || 短路或 運算式1 || 運算式2 ......

    uj5u.com 2020-09-10 05:35:56 more
  • BUAAOO 第四單元 & 課程總結

    1. 第四單元:StarUml檔案決議 本單元采用了圖模型決議UML。 UML檔案可以抽象為圖、子圖、邊的邏輯結構。 在實作中,圖的節點包括類、介面、屬性,子圖包括狀態圖、順序圖等。 采用了三次遍歷UML元素的方法建圖,第一遍遍歷建點,第二、三次遍歷設定屬性、連邊,實作圖物件的初始化。這里借鑒了一些 ......

    uj5u.com 2020-09-10 05:36:06 more
  • 談談我對C# 多型的理解

    面向物件三要素:封裝、繼承、多型。 封裝和繼承,這兩個比較好理解,但要理解多型的話,可就稍微有點難度了。今天,我們就來講講多型的理解。 我們應該經常會看到面試題目:請談談對多型的理解。 其實呢,多型非常簡單,就一句話:呼叫同一種方法產生了不同的結果。 具體實作方式有三種。 一、多載 多載很簡單。 p ......

    uj5u.com 2020-09-10 05:36:09 more
  • Python 資料驅動工具:DDT

    背景 python 的unittest 沒有自帶資料驅動功能。 所以如果使用unittest,同時又想使用資料驅動,那么就可以使用DDT來完成。 DDT是 “Data-Driven Tests”的縮寫。 資料:http://ddt.readthedocs.io/en/latest/ 使用方法 dd. ......

    uj5u.com 2020-09-10 05:36:13 more
  • Python里面的xlrd模塊詳解

    那我就一下面積個問題對xlrd模塊進行學習一下: 1.什么是xlrd模塊? 2.為什么使用xlrd模塊? 3.怎樣使用xlrd模塊? 1.什么是xlrd模塊? ?python操作excel主要用到xlrd和xlwt這兩個庫,即xlrd是讀excel,xlwt是寫excel的庫。 今天就先來說一下xl ......

    uj5u.com 2020-09-10 05:36:28 more
  • 當我們創建HashMap時,底層到底做了什么?

    jdk1.7中的底層實作程序(底層基于陣列+鏈表) 在我們new HashMap()時,底層創建了默認長度為16的一維陣列Entry[ ] table。當我們呼叫map.put(key1,value1)方法向HashMap里添加資料的時候: 首先,呼叫key1所在類的hashCode()計算key1 ......

    uj5u.com 2020-09-10 05:36:38 more
最新发布
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:20:47 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:20:25 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:20:17 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:20:10 more
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:19:44 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:19:07 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:18:57 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:18:49 more
  • 05單件模式

    #經典的單件模式 public class Singleton { private static Singleton uniqueInstance; //一個靜態變數持有Singleton類的唯一實體。 // 其他有用的實體變數寫在這里 //構造器宣告為私有,只有Singleton可以實體化這個類! ......

    uj5u.com 2023-04-19 08:42:51 more
  • 【架構與設計】常見微服務分層架構的區別和落地實踐

    軟體工程的方方面面都遵循一個最基本的道理:沒有銀彈,架構分層模型更是如此,每一種都有各自優缺點,所以請根據不同的業務場景,并遵循簡單、可演進這兩個重要的架構原則選擇合適的架構分層模型即可。 ......

    uj5u.com 2023-04-19 08:42:41 more