《電子技術應用》
您所在的位置:首頁 > 可編程邏輯 > 其他 > Linux教學——圖解TCP、UDP,流量控制,,擁塞控制,,一次看懂

Linux教學——圖解TCP,、UDP,,流量控制,擁塞控制,,一次看懂

2022-10-26
作者:土豆居士
來源:電子技術應用專欄作家 一口Linux
關鍵詞: Linux TCP UDP 流量控制

  

  微信截圖_20221026153711.png

  一,、TCP

  TCP首部

  流量控制

  擁塞控制

  三次握手,四次揮手

  tcp 怎樣保證數(shù)據(jù)正確性,?

  流量控制是為了讓接收方能來得及接收,,而擁塞控制是為了降低整個網絡的擁塞程度

  1、TCP首部

  源端口號

  目標端口號

  32位序列號

  32位確認號

  首部長度(單位為4字節(jié),,默認為5,,即20字節(jié))

  保留位(6位)

  6個控制位(SYN、ACK、FIN,、PUSH,、URG、RST) SYN:同步序號位,,TCP建立連接時要將這個值設為1 ACK:為1表示確認號 FIN:發(fā)送端完成位,,提出斷開連接的一方把FIN置為1表示要斷開連接 PUSH:急迫位,緩存區(qū)將滿,,立刻傳輸速度 RST:重置位,,連接斷了重新連接 URG:緊急信號

  16位窗口大小:接收窗口大小,,流量控制使用,如果窗口大小為0,,可以發(fā)送窗口探測

  16位校驗和:校驗和用來做差錯控制,,TCP校驗和的計算包括TCP首部、數(shù)據(jù)和其它填充字節(jié),。在發(fā)送TCP數(shù)據(jù)段時,,由發(fā)送端計算校驗和,當?shù)竭_目的地時又進行一次檢驗和計算,。如果兩次校驗和一致,,說明數(shù)據(jù)是正確的,否則將認為數(shù)據(jù)被破壞,,接收端將丟棄該數(shù)據(jù)

  16位緊急指針:僅在URG控制位為 1 時有效,。表示緊急數(shù)據(jù)的末尾在 TCP 數(shù)據(jù)部分中的位置。通常在暫時中斷通信時使用(比如輸入 Ctrl + C)

  2,、流量控制

  微信截圖_20221026153823.png

  流量控制,,就是讓發(fā)送方的發(fā)送速率不要太快,要讓接收方來得及接收

  利用滑動窗口機制可以很方便地在tcp連接上實現(xiàn)對發(fā)送方的流量控制

  TCP接收方利用自己的接收窗口的大小來限制發(fā)送方發(fā)送窗口的大小

  重傳計時器

  TCP發(fā)送方收到接收方的零窗口通知后,,應啟動持續(xù)計時器,。持續(xù)計時器超時后,向接收方發(fā)送零窗口探測報文

  即使接收窗口為0,,接收方也會接收:零窗口探測報文段,、確認報文段、攜帶緊急數(shù)據(jù)的報文段

  TCP發(fā)送方的發(fā)送窗口大小 = Math.min(自身擁塞窗口大小, TCP接收方的接收窗口大小)

  3,、擁塞控制

  什么是擁塞

  微信截圖_20221026153845.png

  假定條件

  數(shù)據(jù)是單方向發(fā)送,,而另一方向只傳送確認 接收方總是有足夠大的緩存空間,因而發(fā)送方發(fā)送窗口的大小由網絡的擁塞程度來決定 以最大報文段MSS的個數(shù)為討論問題的單位,,而不是以字節(jié)為單位

  慢開始 + 擁塞避免算法

  MSS:TCP最大報文段 ssthresh:慢開始門限 cwnd:擁塞窗口 swnd:發(fā)送窗口 rtt:每次往返時間

  微信截圖_20221026153907.png

  快重傳

  微信截圖_20221026153922.png

  慢開始 + 擁塞避免算法中,,發(fā)送方把擁塞窗口cwnd又設置為1,并錯誤地啟動慢開始算法,降低了傳輸效率

  微信截圖_20221026153935.png

  收到3個重復確認

  接收方收到失序的報文段,,立即發(fā)出重復確認

  發(fā)送方收到3個連續(xù)的重復確認,,立即重傳

  微信截圖_20221026153955.png

  快恢復

  微信截圖_20221026154011.png

  慢開始 + 擁塞避免+快重傳 + 快恢復結合

微信截圖_20221026154024.png

  4、三次握手,,四次揮手

  4.1 三次握手

  發(fā)送端:SYN=1,、seq=x

  接收端:ACK=1、ack=x+1,、SYN=1,、seq=y

  發(fā)送端:ACK=1、ack=y+1,、seq=x+1

  TCP規(guī)定:SYN被設置為1的報文段不能攜帶數(shù)據(jù),,但要消耗掉一個序號

  TCP規(guī)定:普通的確認報文段如果不攜帶數(shù)據(jù),則不消耗序號

微信截圖_20221026154043.png

  4.2 四次揮手

  發(fā)送端:FIN=1,,ACK=1,,seq=u,ack=v(u等于發(fā)送端已傳送過的數(shù)據(jù)的最后一個字節(jié)序號+1,,v等于發(fā)送端之前已收到的數(shù)據(jù)的最后一字節(jié)序號+1)

  接收端:ACK=1,,ack=u+1,seq=v

  接收端:FIN=1,,ACK=1,,ack=u+1,seq=w(w:半關閉情況下,,可能收到了數(shù)據(jù))

  發(fā)送端:ACK=1,,ack=w+1,seq=u+1

  TCP規(guī)定:終止位FIN等于1的報文段,,即使不攜帶數(shù)據(jù),,也要一個消耗掉一個序號

  MSL:最長報文段壽命,建議為2分鐘

  為什么要等待2MSL,?

  如果接收端發(fā)送FIN連接釋放,,發(fā)送端接收后發(fā)送ACK,如果丟失,,會導致接收端超時重傳,,而無法進入CLOSED狀態(tài)

微信截圖_20221026154102.png

  4.3 保活計時器

微信截圖_20221026154128.png

  4.4 半連接隊列

  服務器第一次收到客戶端的 SYN 之后,,就會處于 SYN_RCVD 狀態(tài),,此時雙方還沒有完全建立其連接,服務器會把此種狀態(tài)下請求連接放在一個隊列里,,我們把這種隊列稱之為半連接隊列,。

  4.5 三次握手能不能改成兩次握手?

  不能

  TCP發(fā)送連接請求,但長時間沒到達,,然后觸發(fā)了超時重傳

  又發(fā)送了一次,,后建立連接,數(shù)據(jù)傳輸,,并斷開了連接

  但此時之前沒達到的請求報文段突然又到了接收端服務器,,接收端服務器變成了ESTABLISHED狀態(tài)

  接收端一直在等發(fā)送端發(fā)送數(shù)據(jù),白白浪費了主機很多資源,,導致了錯誤

微信截圖_20221026154155.png

  4.6 四次揮手能不能改成三次揮手,?

  不能

  接收端可能還有數(shù)據(jù)沒有發(fā)送

  需要等待一段時間,發(fā)送完數(shù)據(jù),,才會發(fā)送FIN

  4.7 SYN攻擊

  服務器端的資源分配是在二次握手時分配的,,而客戶端的資源是在完成三次握手時分配的,所以服務器容易受到SYN洪泛攻擊,。SYN攻擊就是Client在短時間內偽造大量不存在的IP地址,,并向Server不斷地發(fā)送SYN包,Server則回復確認包,,并等待Client確認,由于源地址不存在,,因此Server需要不斷重發(fā)直至超時,,這些偽造的SYN包將長時間占用未連接隊列,導致正常的SYN請求因為隊列滿而被丟棄,,從而引起網絡擁塞甚至系統(tǒng)癱瘓,。SYN 攻擊是一種典型的 DoS/DDoS 攻擊。

  5,、tcp 怎樣保證數(shù)據(jù)正確性,?

  差錯控制 發(fā)送的數(shù)據(jù)包的二進制相加然后取反,檢測數(shù)據(jù)在傳輸過程中的任何變化,,如果收到段的檢驗和有差錯,,TCP 將丟棄這個報文段和不確認收到此報文段。編號 + 排序 TCP 給發(fā)送的每一個包進行編號,,接收方對數(shù)據(jù)包進行排序,,把有序數(shù)據(jù)傳送給應用層 確認 + 超時重傳的機制 當 TCP 發(fā)出一個段后,它啟動一個定時器,,等待目的端確認收到這個報文段,。如果不能及時收到一個確認,將重發(fā)這個報文段,。流量控制

  TCP 連接的每一方都有固定大小的緩沖空間,,TCP 的接收端只允許發(fā)送端發(fā)送接收端緩存區(qū)能接納的數(shù)據(jù)。當接收方來不及處理發(fā)送方的數(shù)據(jù),能提示發(fā)送方降低發(fā)送的速率,,防止包丟失,。TCP 使用的流量控制協(xié)議是可變大小的滑動窗口協(xié)議。

  擁塞控制

  當網絡擁塞時,,減少數(shù)據(jù)的發(fā)送,。發(fā)送方有擁塞窗口,發(fā)送數(shù)據(jù)前比對接收方發(fā)過來的接收窗口,,取兩者的最小值---慢啟動,、擁塞避免、擁塞發(fā)送,、快速恢復

  二,、UDP

微信截圖_20221026154232.png

  三、TCP/UDP對比

  TCP/IP協(xié)議架構

微信截圖_20221026154253.png

  對比

微信截圖_20221026154309.png

  1,、是否面向連接

  UDP:無連接

  TCP:面向連接(三次握手,,四次揮手)

微信截圖_20221026154328.png

  2、是否支持廣播和多播

  UDP:支持一對一,,一對多,,多對一和多對多交互通信

  TCP:只能一對一通信

微信截圖_20221026154344.png

  3、對應用層報文的處理

  UDP:面向報文(對應用層交付的報文直接打包)

  TCP:面向字節(jié)流(是tcp實現(xiàn)可靠傳輸,,流量控制,,擁塞控制的基礎)

微信截圖_20221026154402.png

  4、是否提供可靠傳輸

  UDP:向上提供無連接不可靠服務

  UDP:適用于實時應用(IP電話,、視頻會議等)

  TCP:向上提供面向連接的可靠服務

  TCP:適用于要求可靠傳輸?shù)膽?,例如文件傳?/p>

微信截圖_20221026154423.png

  5、首部開銷

  UDP:8個字節(jié)

  TCP:最小20字節(jié),,最大60字節(jié)

微信截圖_20221026154442.png

   更多信息可以來這里獲取==>>電子技術應用-AET<<

微信圖片_20210517164139.jpg

本站內容除特別聲明的原創(chuàng)文章之外,,轉載內容只為傳遞更多信息,并不代表本網站贊同其觀點,。轉載的所有的文章,、圖片、音/視頻文件等資料的版權歸版權所有權人所有,。本站采用的非本站原創(chuàng)文章及圖片等內容無法一一聯(lián)系確認版權者,。如涉及作品內容、版權和其它問題,,請及時通過電子郵件或電話通知我們,,以便迅速采取適當措施,避免給雙方造成不必要的經濟損失,。聯(lián)系電話:010-82306118,;郵箱:[email protected],。