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协议的优化点就是变更算法变更协议，前者资源多开发难度小，后者开发难度大但优化空间高；总之适合的才是最好的~~~没有必要一味追求单边双边。

 

 转发请注明出处，谢谢~