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穩...