TCP可靠傳輸&流量控制&擁塞控制

TCP可靠傳輸

TCP可靠傳輸的工做原理

1.無差錯

1>:無差錯: A發送分組M1,發送就暫停發送,等待B的確認,B收到M1就向A發送確認,A收到對M1的確認後再發送下一個分組。(若A收到連續的M1分組的確認信息,則證實M2缺失)
2>:出現差錯:
        A只要超過一段時間仍然沒有收到確認,就認爲剛纔發送的分組丟失了,就重傳前面發過的分組,叫超時重傳。由重傳計時器實現。
        並且:
git

                (1)A每次發送分組必須暫時保留分組副本;github

                (2)分組和確認分組必須進行編號‘算法

                (3)超時計時器的重傳時間應當比數據在分組的平均往返時間更多一些。緩存

3>:若是B收到重複的分組M1,不向上一層交付;並且,向A發送確認。網絡

2.超時重傳

        其原理是在發送某一個數據之後就開啓一個計時器,在必定時間內若是沒有獲得發送的數據報的ACK報文,那麼就從新發送數據,直到發送成功爲止。第一次發送後所設置的超時時間實際上爲1.5秒,此後該時間在每次重傳時增長一倍,一直到64秒,採用的是指數退避算法。一共重傳12次,大約9分鐘才放棄重傳,該時間在目前的TCP實現中是不可變的,Solaris2.2容許管理者改變這個時間,tcp_ip_abort_interval變量。且其默認值爲兩分鐘,而不是最經常使用的9分鐘。tcp

 

3.中止等待協

   優勢是簡單,可是信道利用率過低了。解決方法是採用連續ARQ協議,發送方維持發送窗口,每次連續發送幾個分組,接收方採用累積確認,對按序到達的最後一個分組發送確認。性能

   缺點是不能向發送方反映出接收方已經正確收到的全部分組信息,例如丟失中間的分組。spa

 

4.TCP可靠傳輸的實現

TCP 鏈接的每一端都必須設有兩個窗口——一個發送窗口和一個接收窗口。TCP 的可靠傳輸機制用字節的序號進行控制。TCP 全部的確認都是基於序號而不是基於報文段。
發送過的數據未收到確認以前必須保留,以便超時重傳時使用。發送窗口不動(沒收到確認)和前移(收到新的確認)
發送緩存用來暫時存放: 發送應用程序傳送給發送方 TCP 準備發送的數據;TCP 已發送出但還沒有收到確認的數據。接收緩存用來暫時存放:按序到達的、但還沒有被接收應用程序讀取的數據; 不按序到達的數據。
必須強調三點:
    1>   A 的發送窗口並不老是和 B 的接收窗口同樣大(由於有必定的時間滯後)。
設計

    2>   TCP 標準沒有規定對不按序到達的數據應如何處理。一般是先臨時存放在接收窗口中,等到字節流中所缺乏的字節收到後,再按序交付上層的應用進程。
    3>   TCP 要求接收方必須有累積確認的功能,這樣能夠減少傳輸開銷
隊列

5.滑動窗口圖解

   

    

 

 

TCP擁塞控制和流量控制的差異

     擁塞控制就是防止過多的數據注入到網絡中,這樣可使網絡中的路由器或鏈路不致過載。擁塞控制所要作的都有一個前提,就是網絡能承受現有的網絡負荷。

       流量控制每每指的是點對點通訊量的控制,是個端到端的問題。流量控制所要作的就是控制發送端發送數據的速率,以便使接收端來得及接受。

 

TCP流量控制

     所謂的流量控制就是讓發送方的發送速率不要太快,讓接收方來得及接受。利用滑動窗口機制能夠很方便的在TCP鏈接上實現對發送方的流量控制。

      TCP的窗口單位是字節,不是報文段,發送方的發送窗口不能超過接收方給出的接收窗口的數值。

      只要TCP鏈接的一方收到對方的零窗口通知,就啓動持續計時器,若持續計時器設置的時間到期,就發送一個零窗口探測報文段(僅攜帶1字節的數據),而對方就在確認這個探測報文段時給出瞭如今的窗口值。

 

TCP流量控制原理

   所謂流量控制就是讓發送發送速率不要過快,讓接收方來得及接收。利用滑動窗口機制就能夠實施流量控制。

         原理這就是運用TCP報文段中的窗口大小字段來控制,發送方的發送窗口不能夠大於接收方發回的窗口大小。

         考慮一種特殊的狀況,就是接收方若沒有緩存足夠使用,就會發送零窗口大小的報文,此時發送放將發送窗口設置爲0,中止發送數據。以後接收方有足夠的緩存,發送了非零窗口大小的報文,可是這個報文在中途丟失的,那麼發送方的發送窗口就一直爲零致使死鎖。

         解決這個問題,TCP爲每個鏈接設置一個持續計時器(persistence timer)。只要TCP的一方收到對方的零窗口通知,就啓動該計時器,週期性的發送一個零窗口探測報文段。對方就在確認這個報文的時候給出如今的窗口大小(注意:TCP規定,即便設置爲零窗口,也必須接收如下幾種報文段:零窗口探測報文段、確認報文段和攜帶緊急數據的報文段)。

 

TCP擁塞控制

 在某段時間,若對網絡中的某一資源的需求超過了該資源所能提供的可用部分,網絡的性能就要變化,這種狀況叫作擁塞。

擁塞控制設計

       擁塞控制是很難設計的,由於它是一個動態的問題,許多狀況下,甚至正式擁塞控制機制自己成爲引發網絡性能惡化甚至死鎖的緣由。從控制理論的角度來看擁塞控制這個問題,能夠分爲開環控制和閉環控制兩種方法。開環控制就是在設計網絡時事先將有關擁塞發生的全部因素考慮周到,一旦系統運行起來就不能在中途改正。

     閉環控制是基於反饋環路的概念,包括以下措施:

     1)監測網路系統以便檢測擁塞在什麼時候何地發生

     2)把擁塞發生的信息傳送到可採起行動的地方

     3)調整網絡系統的行動以解決出現的問題。

 

擁塞控制方法

特網建議標準RFC2581定義了進行擁塞控制的四種算法,即慢開始(Slow-start)擁塞避免(Congestion Avoidance),快重傳Fast Restrangsmit)快恢復Fast Recovery)。咱們假定

     1)數據是單方向傳送,而另一個方向只傳送確認。

     2)接收方老是有足夠大的緩存空間,由於發送窗口的大小由網絡的擁塞程度來決定。

 

下圖是慢啓動和擁塞避免的一個可視化描述。咱們以段爲單位來顯示cwndssthresh,但它們實際上都是以字節爲單位進行維護的。

        TCP Tahoe版本已經廢棄。

      擁塞窗口概念

       發送報文段速率的肯定,既要根據接收端的接收能力,又要從全局考慮不要使網絡發生擁塞,這由接收窗口和擁塞窗口兩個狀態量肯定。接收端窗Reciver Window)又稱通知窗口(Advertised Window),是接收端根據目前的接收緩存大小所許諾的最新窗口值,是來自接收端的流量控制。擁塞窗口cwndCongestion Window)發送端根據本身估計的網絡擁塞程度而設置的窗口值,是來自發送端的流量控制

   (1)慢啓動原理

     1)當主機開始發送數據時,若是當即將較大的發送窗口的所有數據字節都注入到網絡中,那麼因爲不清楚網絡的狀況,有可能引其網絡擁塞

     2)比較好的方法是試探一下,即從小到達逐漸增大發送端的擁塞控制窗口數值

     3)一般在剛剛開始發送報文段時可先將擁塞窗口cwnd(擁塞窗口)設置爲一個最大報文段的MSS的數值。在每收到一個對新報文段確認後,將擁塞窗口增長至多一個MSS的數值,當rwind(接收窗口)足夠大的時候,爲了防止擁塞窗口cwind的增加引發網絡擁塞,還須要另一個變量---慢開始門限ssthresh

 

    (2)擁塞控制

  具體過程爲:

      1TCP鏈接初始化,將擁塞窗口設置爲1

      2)執行 慢開始算法:cwind按指數規律增加,知道cwind == ssthress開始執行 擁塞避免算法:cwnd按線性規律增加

       3)當網絡發生擁塞,把ssthresh值更新爲擁塞前ssthresh值的一半,cwnd從新設置爲1,按照步驟(2)執行。

 

 

 

 

    (3)快重傳和快恢復

     一條TCP鏈接有時會因等待重傳計時器的超時而空閒較長的時間,慢開始和擁塞避免沒法很好的解決這類問題,所以提出了快重傳和快恢復的擁塞控制方法。

     快重傳算法並不是取消了重傳機制,只是在某些狀況下更早的重傳丟失的報文段(若是當發送端接收到三個重複的確認ACK時,則判定分組丟失,當即重傳丟失的報文段,而沒必要等待重傳計時器超時)。

    例如:M1,M2,M3 -----> M1,M3,缺失M2,則接收方向發送方持續發送M2重複確認,當發送方收到M2的三次重複確認,則認爲M2報文丟失,啓動快重傳機制,重傳數據,其餘數據發送數據放入隊列,待快重傳結束後再正常傳輸。

     快恢復算法有如下兩個要點:

     1)當發送方連續收到接收方發來的三個重複確認時,就執行乘法減少算法,把慢開始門限減半,這是爲了預防網絡發生擁塞。

     2)因爲發送方如今認爲網絡極可能沒有發生擁塞,所以如今不執行慢開始算法,而是把cwnd(擁塞窗口)值設置爲慢開始門限減半後的值,而後開始執行擁塞避免算法,使擁塞窗口的線性增大

 

備註:重傳機制

        超時重傳是TCP協議保證數據可靠性的另外一個重要機制,其原理是在發送某一個數據之後就開啓一個計時器,在必定時間內若是沒有獲得發送的數據報的ACK報文,那麼就從新發送數據,直到發送成功爲止。

 

 

‍‍報文丟失重複確認狀況‍‍

持續收到重複的ACK號,表明該報文丟失,觸發快速重傳機制

 

        Seq:就是告訴接收方:我發送的數據是從seq開始的。

        Ack:就是告訴接收方:我但願下次收到對端發過來的seq序號。

當重傳主機從發送端接收到3個重複ACK時,它會假設此報文確實在傳送中丟失,而且當即發送一個快速重傳。一旦觸發了快速重傳,全部正在傳輸的其餘報文都被放入隊列中暫停發送,直到快速重傳報文發送完爲止。

過程以下圖所示:

 

 

TCP三次握手,四次揮手

 

TCP標誌位,有6種標示:

SYN(synchronous創建聯機)

ACK(acknowledgement 確認)

PSH(push傳送)

FIN(finish結束)

RST(reset重置)

URG(urgent緊急)

 

推薦

最後推薦一個不錯的TCP/IP協議棧LwIP協議棧,可移植的協議棧

個人github上面有 源代碼 ,地址:https://github.com/manmao/lwip_contrib.git

LwIP官網在:https://savannah.nongnu.org/projects/lwip/

相關文章
相關標籤/搜索