可靠UDP傳輸協議總結

2021-09-24 06:01:57 字數 2816 閱讀 7689

tcp/ip協議棧中,tcp和udp屬於傳輸層,負責實現資料的傳輸。其中tcp是面向連線的和基於單個位元組流的、保證順序的可靠傳輸協議,udp是無連線的、不可靠的、面向報文的協議。

在實際應用中,tcp由於簡單可靠,被大部分應用層協議使用,特別是http,所以佔據了網際網路流量的主要部分。由於tcp的廣泛應用,並且是實現在作業系統中,在引數和演算法調整上比較受限,難以進行一些激進的改進和定製。另外tcp的nat穿越比較困難,一些p2p應用也只能使用udp,所以就有了各種各樣的可靠udp協議。

實現可靠傳輸一般有兩種途徑,一是基於arq(automatic repeat request)的確認和重傳機制,二是使用前向糾錯(fec)。

fec是糾刪碼在通訊中的應用,一般在鏈路層用的比較多,特別是無線通訊中(包括wifi,移動通訊、衛星通訊等)。可靠udp傳輸主要還是依靠重傳機制,個別協議會用fec作為輔助手段,所以本文中主要介紹重傳相關的技術。

arq包括停等式、回退n幀、選擇重傳等機制。由於停等式的效率太低,tcp和可靠udp協議一般使用的是基於回退n幀機制和滑動視窗協議的連續式arq,tcp後來也引入了sack,以提高效能。

滑動視窗是一種流量控制技術,接收方可以通過反饋來指示傳送方調節資料傳送的速度。tcp中使用滑動視窗協議來控制傳送的資料量,達到理想的傳輸速度。

擁塞演算法

tcp早期沒有擁塞控制,直到2023年由於擁塞導致網路癱瘓,所以擁塞控制被引入到tcp中。擁塞演算法主要是計算和調整接收視窗、傳送視窗、擁塞視窗的大小,從而控制傳輸速度,既充分利用頻寬,又避免網路出現擁塞。

最早的擁塞演算法是tahoe,後來的改進版有reno、newreno、bic、cubic等。linux在2.6.8之前使用的是reno/newreno,2.6.8到2.6.18之間使用bic,2.6.19開始使用cubic。

擁塞演算法的核心機制有:

在連線剛建立時接收視窗以指數方式增加,直到達到慢啟動的閥值,或者是遇到丟包,開始進入擁塞迴避階段。

在此階段會使用aimd(additive increase multiplicative decrease)方式調整視窗大小,通過線性增加和指數衰減,逐漸逼近和收斂到乙個理想值,從而達到充分利用頻寬但又不引起擁塞的狀態。

傳送方如果收到連續3次重複的ack確認,就認為出現了丟包,而不需要等到重傳計時器超時。這樣可以更早的檢測到丟包,提高演算法效率。

tahoe檢測到丟包後,會回到初始狀態,然後進入慢啟動階段,導致傳輸效率太低。reno對此作了改進,在檢測到丟包後,直接進入擁塞迴避階段,將視窗大小調整為原來的一半,避免了慢啟動的開銷。

擁塞演算法分類

tcp的擁塞演算法有很多種,按照擁塞檢測的機制,可以分為三類:

路由器和交換機在要**的報文超過負載時會丟棄部分報文,所以丟包可以作為網路出現擁塞的乙個標誌,這也是tcp中主流的擁塞檢測機制。從最早的tahoe和改進版的reno、newreno、hstcp、stcp、bic、cubic等,都是基於丟包的,也是主流的擁塞檢測機制。

現在的路由器和交換機的快取比較大,對於超出負載的報文會先快取起來,而不是立即丟棄。直到負載超過快取大小,才會丟棄報文。所以當網路出現擁塞時,並不是馬上丟包,而有報文丟失時,網路的擁塞已經比較嚴重。這樣,前面基於丟包的擁塞檢測機制就不夠準確,於是,就有了基於延時的檢測演算法。

雖然這類演算法可以更早的檢測出擁塞,使得整個網路更有效率,但在跟基於丟包的演算法競爭時,卻由於過早的避讓,導致效能較差,無法保證演算法的公平性,所以影響了它們的應用。

這類的演算法有vegas和fast tcp,其中fast tcp是一種商業方案,有專利保護,在一些單邊加速的場景中有應用。vegas由於公平性的問題,沒有被廣泛使用。

google新推出的bbr演算法,雖然也可以歸為基於延時類的,但跟傳統演算法有較大區別。傳統演算法通過aimd來逼近理想傳輸速度,效率較低,而且受丟包和抖動的影響較大。bbr通過rtt和頻寬乘積(bdp)來作為調整傳送視窗的基礎,避免了這些問題,從而提高效能和避免擁塞。

通過ip頭中2個bit的ecn標識和tcp頭中的ecn-echo位,可以在各節點以及中間裝置之間顯式的傳遞擁塞訊號,從而達到避免擁塞的目的。不過由於一些終端和中間裝置(路由器、交換機、閘道器等)並不支援ecn,導致ecn並沒有廣泛應用。

udt的主要目的是支援高速廣域網上的海量資料傳輸,所以除了在udp之上實現類似tcp的協議和演算法之外,udt還對tcp的擁塞演算法做了一些細節上的調整,包括negative-ack(nak)、ack to ack(ack2)、基於對數的動態aimd等。不過udt的重傳效率較低,無效報文,實際效果並不理想。

kcp是乙個很簡單的arq的實現,包括選擇重傳和快重傳等機制,對上層提供乙個可靠的位元組流。應用層可以使用多流復用的框架來實現對多個流的支援。另外,kcp增加了可配置啟用的加密和fec選項,fec用的是reed-solomon糾刪碼,例如可以配置傳送10%的冗餘資料,來減少丟包時需要的重傳,從而降低資料傳輸的延時。

quic是google實現的一種可靠udp傳輸協議,並且已經被選擇作為http/3的基礎。它的特點有:

另外,早期的quic還使用了一種基於異或的fec演算法,不過在新版本中已經去掉。

fasp是aspera公司(已被ibm收購)的私有udp解決方案,提供加密的可靠傳輸,擁塞演算法估計是類似bbr,直接使用rtt和頻寬來作為調節速度的參考。但fasp主要用於高速的檔案傳輸,所以不需要保證報文的順序,避免亂序重組時占用的記憶體開銷,而且也避免了因為記憶體有限而丟棄的部分亂序報文,從而減少不必要的重傳,提高傳輸速度。也就是說,完全避免了head-of-line blocking問題。

準確的說,sctp不是一種可靠udp協議,而是一種跟tcp/udp平級的傳輸層協議,是ietf在2023年指定的標準協議。目前linux和部分unix已經整合,windows和mac需要使用第三方包來實現。sctp最初主要用於電信系統,此外,webrtc中的datachannel也用到這個協議。它的特點有:

可靠UDP傳輸協議總結

tcp ip協議棧中,tcp和udp屬於傳輸層,負責實現資料的傳輸。其中tcp是面向連線的和基於單個位元組流的 保證順序的可靠傳輸協議,udp是無連線的 不可靠的 面向報文的協議。在實際應用中,tcp由於簡單可靠,被大部分應用層協議使用,特別是http,所以佔據了網際網路流量的主要部分。由於tcp的...

UDP協議及UDP實現可靠傳輸

udp基於傳輸層 16位 2位元組 16位 2位元組 16位 2位元組 16位 2位元組 udp源埠號 udp目的埠號 udp長度 udp檢驗和資料 udp的傳輸過程類似於寄信 什麼時面向資料報 應用層交給udp多長的報文,udp原樣傳送,既不會拆分,也不會合併 老實巴交的 用udp傳輸100個位元...

論UDP可靠傳輸協議評判標準

標準 1。吞吐量 在較低包率下,達到90 以上的代寬利用率。2。低延遲。如果線路固有的ping值在100ms的話,當最大吞吐量的時候,ping值不應該大於200ms.3。流量穩定 通過流量工具軟體,比如一些帶ui的介面工具,可以看到,收發流量基本穩定在乙個水平,流量波形形成一條直線為佳。4。rtt穩...