TCP擁塞算法瓶頸及TCP加速器解決方案

TCP擁塞算法詳解

 ps:詳解TCP擁塞算法就是為了說明瓶頸所在。

先解釋一下概念：

擁塞：對網絡中某一資源的需求超出了該資源所能提供的可用部分

擁塞視窗：以位元組為機關，表示能通過的資料報的個數

TCP傳統擁塞控制算法（參考TCP/IP詳解一卷）

傳統擁塞控制算法有四個階段

------------------------------------------------------------------

慢開始

    由小到大逐漸增大擁塞視窗數量（注意！慢開始隻是起點低，增加速度并不慢 指數增加）

階段轉變：當封包數目達到擁塞視窗的初始門限時，由慢開始變為擁塞避免階段

------------------------------------------------------------------

擁塞避免

     擁塞視窗緩慢增大，線性增大

     特點：擁塞避免其實就是為了避免封包數增長過快導緻丢包

     說明：丢包是無法避免的，TCP是可靠的并不是說他不丢包而是有重傳機制可以保證封包丢失後的再次傳輸

階段轉變：當出現第一個丢包時，觸發快重傳機制，重傳完成後進入快恢複階段

------------------------------------------------------------------

這個階段涉及兩個操作

1、快重傳

       接收方收到失序封包段口發出重複确認，發送方收到三個重複确認立即進行重傳

       分析一下：1、為什麼叫快重傳，其實就是差別去逾時重傳，逾時重傳是在發包是設定定時器，超過時間沒收到傳回的ACK就進行重傳；而快重傳是接收端發現收到的封包段失序後，了解發送三條相同封包告知發送端你該重傳了，别再等定時器了！

       通俗的描述一下快重傳機制：收端收的封包是有順序的，例如收端收到了1,2,4收端發現3不見了，就會連續像發端發送3個2告訴發送端我沒收到3，你先把3發給我。

如果重傳還是沒有傳輸成功是如何處理的？

　　此處有兩個标準一個是時間一個是次數，如果在指定時間或次數内沒有重傳成功會終結該連結。

2、快恢複

     發送方收到三個重複确認後慢開始門限減半

     新的擁塞視窗大小=新的慢開始門限（丢包時擁塞視窗的一半）+3 （3代表3個重傳的封包段）

階段轉變：重新确認擁塞視窗大小後，将狀态變更到擁塞避免階段

--------------

傳統算法瓶頸

根據上述基礎知識就可以知道TCP傳統擁塞算法對丢包、時間都非常敏感！！！

以同步軌道衛星通信為例分析瓶頸：

1、衛星鍊路實測往返時延達到500ms以上，傳統擁塞算法的定時器、傳輸機制都不适用

2、衛星鍊路不穩定會受到天氣、太陽等的影響，相比較地面網絡丢包和誤碼率都大很多

綜上所述：就會導緻TCP業務傳輸吞吐量始終在30%左右，浪費資源。（丢包折半丢包折半的死循環）

--------------

解決方案

TCP加速器是如何解決上述問題的呢？

前人做過很多探索，如 修改本地TCP協定、調整緩沖區等

經過很多探索之後，現在主流的就有兩種：單邊加速和雙邊加速

之前的文章提到過，單邊就是優化算法，雙邊更傾向于變更協定

單邊方面來說使用廣算法多

BBR：谷歌的算法，現在買外國伺服器搭BBR加速已經成為很普遍了，但使用是要注意核心版本BBR對核心版本要求較高

Zeta：我國的一款算法，具體沒有使用過，看宣傳是基于傳輸曆史學習的，可以通過學習傳輸曆史調整發送節奏降低丢包率

當然也可以自定義，隻要透明代理做的好，算法完全可以在加速器中自行選擇優化方向

雙邊加速 （現階段基本都是星空鍊路使用UDP，由加速器來進行封包發送、确認）

主要采用的就是RFC 3135中的隧道機制

       性能增強代理可以封裝消息以跨特定鍊路傳送消息或強制消息周遊特定路徑。封裝隧道另一端的PEP在最終傳送到接收端系統之前移除隧道封裝器。分布式分離連接配接TCP實作可以使用隧道作為用于在分布式PEP之間進行連接配接的裝置。 隧道也可用于支援強制TCP連接配接，該連接配接使用非對稱路由來周遊分布式PEP實作的端點。

雙邊加速可以最大限速的利用壓縮機制，現階段網絡安全問題越來越突出，壓縮不僅僅能提升傳輸速率還能提高安全性，何樂而不為呢？

總而言之，TCP協定的優化點就是變更算法變更協定，前者資源多開發難度小，後者開發難度大但優化空間高；總之适合的才是最好的~~~沒有必要一味追求單邊雙邊。

 轉發請注明出處，謝謝~