CN105207944B - 基于fast tcp的传输控制方法 - Google Patents

Abstract

本发明公开了一种基于FAST TCP的传输控制方法，包括：数据控制模块、窗口控制模块和估计模块，估计模块用于计算拥塞避免阈值；所述方法包括以下步骤：S1：获取所述拥塞避免阈值和所述客户端当前数据包的传输数量；S2：将所述客户端所述当前数据包的传输数量和所述拥塞避免阈值进行比较，如果所述客户端当前数据包的传输数量不小于所述拥塞避免阈值，所述估计模块向所述窗口控制模块发送拥塞反馈信息，所述窗口控制模块根据所述拥塞反馈信息减少数据包的传输数量以避免丢包。本发明具有如下优点：可以通过监控网络传输规模，针对不同的规模进行参数调整，达到在不同规模下的自适应，始终保证高吞吐量和稳定的传输性能。

Description

基于FAST TCP的传输控制方法

技术领域

本技术属于云计算及网络传输技术领域，具体涉及一种基于FAST TCP的传输控制方法。

背景技术

数据中心的拓扑结构经过多年的探索，有了很大的变化。图1示出了常规的数据中心网络的拓扑结构。在这种拓扑结构中，架顶式的范围(ToR)交换机接入层为安装在机架上的服务器提供连接。在每个聚集层(有时也被称为分布层)的聚集交换(AggregationSwitch)将从多个接入层(TOR)发来的流量转发到核心层。每一个ToR交换机连接到多个聚集交换机的冗余。核心层将交换机通过核心路由Core Routers)连接到互联网。一个特例是平坦的两层拓扑，仅使用两层交换机。

Clos拓扑是基于多级交换机的一种拓扑结构，每个交换机层次都和下一个交换机层次的所有交换机相连，这样大大增加了路径的多样性。图2展示了一种典型的三层Clos拓扑

胖树是一种特殊的Clos拓扑结构。它是一种类树结构，如图3所示，这种拓扑结构由k个端口的交换机组成，他们有k个连接点，每个连接点处有两层(聚合层和边缘层)k/2个交换机，而每(k/2)²个核心交换机有1个端口和这k个连接点链接。核心层交换机和聚合层交换机连接，而边缘曾交换机与Tor交换机连接。这一策略折衷了复杂度和路由多样性。

近年来兴起了虚拟数据中心网络，虚拟数据中心网络是在若干虚拟资源(虚拟机，虚拟交换机，虚拟路由器等)之间构成的虚拟连接，如所示，一个物理数据中心上可以假设多个虚拟数据中心。虽然引入了虚拟化概念，资源利用可以更灵活有图4架设在物理数据中心上的虚拟数据中心及数据中心网络效，用户也可以屏蔽物理层的事宜，但是数据中心网络问题仍然客观存在，必须加以解决。

TCP协议给数据中心带来的问题之一就是TCP Incast现象，这里我们首先要对数据中心网络环境进行定义。数据中心网络环境一般满足如下条件：

a)服务器具有高性能CPU和较大的内存；

b)具备高性能网卡，以及适当的操作***；

c)千兆以太网(或10Gb/sec)，由一台交换机或者其他拓扑结构构成数据中心网路，更多交换机可能会带来好处，但是定义上没有特别的限制。

d)存在大量一对一，多对一及一对多通信模式。此类传输模式存在于集群存储以及Hadoop等其他许多数据密集型分布式应用中。

在简单的带宽环境下，比如使用scp将五台机器上的数据复制到一个目的主机，每个源机器能够输出900Mbps以上。如果每个发送者都以900Mbps的速度向接收端发送数据，1G以太网交换机不久将只能丢弃部分数据包。

但这种情形很容易理解：所有的机器不能同时发送900Mbps以上的数据，因为接收端有带宽上限，交换机必将丢弃一些数据包，然后每个TCP连接将降低发包速率。最终，每个发送者将达到大约发送200Mbps的稳态从而填满瓶颈链接。

事实上我们会遇到更困难的带宽问题，如果有较大的群集，会出现大量服务器同时向一个服务器传输数据的情况，则可能有发送到单个集群成员的流量“微爆”。交换机不能缓冲所有的“微爆帧”，故有部分帧会被丢掉，下面的数据展示了“微爆”所导致的短时隙内的吞吐量崩溃。然后，TCP的拥塞控制机制开始干预，处理丢包和超时事件，减缓窗口增长甚至减少窗口。

“Incast”是一种通信模式，在数据中心网络环境下，它主要由TCP协议的拥塞控制算法的特点引起。图5所示为典型的TCP Incast传输模式场景。在这种模式中，客户端通过一交换机连接到数据中心的多台服务器。客户端发出请求，数据从一个或多个服务器通过交换机以many-to-one的方式通过瓶颈链路传输到客户端。客户端以较大的逻辑块(如1MB)请求数据，而实际的数据块则以较小的数据块(如32KB)形式存储在多服务器中，称为服务器的请求单元(SRU)。每一轮传输中，客户端向所有存储有被请求数据的服务器发送数据请求，当所有服务器的数据均成功接收(即被请求数据块成功传输)时，才进行下一次数据块请求。

严格地定义Incast现象需要满足如下三个条件：

1.网络环境：高带宽(千兆网)低延迟及较小的交换机缓存

2.同步块传输模式，即每轮传输一个数据块，所有数据块收到后才进入下一轮传输

3.较小的数据块；(最大256K，一块数据在千兆网环境下在2毫内秒可传输完毕)

随着并发发送者数量的增加，数据传输量可能超出交换机缓存大小，导致数据包丢失，以及随之而来的的超时重传。从而可能导致吞吐量崩溃(急剧降低)，如图6所示，我们称之为TCP Incast现象。

TCP Incast问题可能出现在许多典型的数据中心应用当中。例如，在集群存储***中，在存储节点对数据的请求作出回应时；在网络搜索过程中，许多工作机几乎同时响应搜索查询；或在MapReduce批量处理作业的过程中，“shuffle”阶段多个Mapper将中间数据传输给Reducer时。由于存在范围广泛，对网络效能影响恶劣，TCP Incast问题已经引起了许多研究人员的注意。研究人员在多层面提出了各种可能的解决方案，主要包括链路层，传输层和应用层解决方案。这些方案中，部分具有较高的效率，但成本亦高，部分方案代价低，但收效甚微。

发明内容

本发明旨在至少解决上述技术问题之一。

为此，本发明的一个目的在于提出一种基于FAST TCP的传输控制方法。

为了实现上述目的，本发明的第一方面的实施例公开了一种基于FAST TCP的传输控制方法，包括：数据控制模块，所述数据控制模块用于控制传输数据包；窗口控制模块，所述窗口控制模块用于控制发送端的数据包的传输数量；以及估计模块，所述估计模块用于根据发送端的数据包发送频率、传输链路的带宽、交换机的缓存容量、所述交换机的延时队列中数据包的平均延时计算拥塞避免阈值；所述方法包括以下步骤：S1：获取所述拥塞避免阈值和所述客户端当前数据包的传输数量；S2：将所述客户端所述当前数据包的传输数量和所述拥塞避免阈值进行比较，如果所述客户端当前数据包的传输数量不小于所述拥塞避免阈值，所述估计模块向所述窗口控制模块发送拥塞反馈信息，所述窗口控制模块根据所述拥塞反馈信息减少数据包的传输数量以避免丢包。

根据本发明实施例的基于FAST TCP的传输控制方法，可以通过监控网络传输规模，针对不同的规模进行参数调整，达到在不同规模下的自适应，始终保证高吞吐量和稳定的传输性能。

另外，根据本发明上述实施例的基于FAST TCP的传输控制方法，还可以具有如下附加的技术特征：

进一步地，所述拥塞避免阈值的计算公式如下：

其中，w为所述发送端的所述当前数据包的传输数量，γ∈(0,1]，baseRTT为所述交换机延时队列中数据包的最小RTT，qdelay是点对点的平均队列延迟，α为修正系数，

其中，q为队列延时，α₀、α₁、q^*均为常数。

本发明的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1是现有技术中交换机拓扑结构示意图；

图2是现有技术中的Clos拓扑结构示意图；

图3是现有技术中的胖树拓扑结构示意图；

图4是现有技术中的虚拟数据中心及数据中心网络示意图；

图5是现有技术中的TCP Incast传输模式示意图；

图6是现有技术中的TCP Incast的示意图；

图7是本发明一个实施例的流程图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能理解为对本发明的限制。

在本发明的描述中，需要理解的是，术语“中心”、“纵向”、“横向”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性。

在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

参照下面的描述和附图，将清楚本发明的实施例的这些和其他方面。在这些描述和附图中，具体公开了本发明的实施例中的一些特定实施方式，来表示实施本发明的实施例的原理的一些方式，但是应当理解，本发明的实施例的范围不受此限制。相反，本发明的实施例包括落入所附加权利要求书的精神和内涵范围内的所有变化、修改和等同物。

以下结合附图描述根据本发明实施例的基于FAST TCP的传输控制方法。

C-FAST协议通过检测队列延迟调整拥塞窗口，以维持稳定队列长度；我们认为0队列长度是危险的，因为有队列存在证明瓶颈链接是被占满的，而0队列长度的情况下，我们无法判断瓶颈链接是否被充分使用；同时，在数据中心中，RTT的尺度已经很小，队列延迟则更小，我们选择直接基于队列延迟，并维持>0稳定队列长度的FAST协议的拥塞避免策略作为解决问题的基础。

本协议基于FAST协议设计。FAST协议在骨干网络中使用，而骨干网络与数据中心的首要区别如下：

RTT(往返时延)，骨干网络在200ms左右，而数据中心在10us～100us，从而qdelay的数量级也从ms级下降到us级；

缓冲区大小，骨干网络中路由器的缓冲区大小约为100Mb，而数据中心交换机缓冲区在1Mb以下。

由于我们的方案采用FAST协议的拥塞控制算法，然而FAST协议在数据中心中必然是不适用的，因此我们需要基于以上两点区别对算法进行调整以使得该方案在在数据中心中能够成功地应用，需要说明的是，我们当前的设计针对千兆网进行。

拥塞避免阈值是指窗口快速增长过程结束进入拥塞避免的阈值，不同的协议有不同的标准。TCP协议以窗口大小为标准，拥塞窗口大小超过该阈值时由慢启动进入拥塞避免过程。

在FAST协议中，以队列延迟为标准，当队列延迟大于该阈值时，进入拥塞避免。拥塞避免阈值的物理意义是认为链路接近饱和的点。由于路由器缓存普遍较大，从而等待队列较长，故在骨干网络中网络延迟较大，因此FAST协议的这一阈值也较大。在数据中心网络环境下，交换机缓存往往较小而队列延迟也相应较小，故这一阈值需要进行调整。由于我们要使缓冲区中有队列，以保证瓶颈链接满载，同时要保证在慢启动结束前不出现缓冲区溢出，故拥塞避免阈值Mi_threshold需满足如下条件：

SU/C<Mi_threshold<B/C

其中SU为包大小，B为缓冲区大小，C为链路带宽。以当前应用较广泛的千兆网为例，若buffer size(缓冲区大小)为64KB，SU为1KB，则

1us<Mi_threshold<64us

建议让该阈值远离buffer size，否则很容易由于偶然原因出现丢包。事实上一个较小的mi_threshold已经足以保证瓶颈链接被充分利用，这里我们取：

Mi_threshold＝20us

α是FAST协议中拥塞窗口控制的修正系数，是w和q-delay的函数。但是在目前的FAST协议应用中一般取为常数。它的物理意义是当前流期望在缓冲区中维持的队列长度，因此也是流拥塞窗口的下界。α较小时，链路收敛即进入均衡状态较慢，发送端窗口大小也收到限制。α较大时，又会增大排队延迟。

在骨干网络中，由于路由器缓冲区较大，α取值也较大，默认为200，而在数据中心中，200的窗口大小必然是不现实的。因此我们必须采用新的α。

为对方案设计给出参考，我们首先设计了仿真实验以估计α的可能取值范围，我们使用NS2进行仿真平台搭建，在仿真平台上实现了Incast的网络传输拓扑结构并且基于FAST TCP实现了初步解决方案以测试参数。具体的仿真平台会在后文中介绍。我们进行了参数α的测试，我们有两条结论：

发送端数目较小时，较小的α会限制吞吐量。尤其是在点对点做数据传输时，这样的限制更加明显。我们采用新的方案解决Incast问题的前提是不限制正常数据传输，而α＝0,1的情形显然违背了这一点；

较大的α会使得发送端数目大时总队列长度的最小值大于交换机缓存，从而导致incast现象。由于α是每个流在交换机处维持的队列长度，因此若α较大，在服务器数量增大时有可能出现总队列长度超出交换机缓存的情况。

因此常数取值的α无法满足点对点的传输需求和Incast传输模式的需求，鉴于以上两个特点，我们考虑用阶梯函数决定α的取值:

其中α₀和α₁分别为不同发送端数量时α的取值，N^*为发送端数目的阈值。

α是FAST协议中拥塞窗口控制的修正系数，是w和q-delay的函数。但是在目前的FAST协议应用中一般取为常数。它的物理意义是当前流期望在缓冲区中维持的队列长度，因此也是流拥塞窗口的下界。α较小时，链路收敛即进入均衡状态较慢，发送端窗口大小也收到限制。α较大时，又会增大排队延迟。如发明内容中提到，其参数设置服从下式。

N^*是切换α值的阈值，但N^*的具体取值并不是一个确切的数值，实质上N^*具有一个安全范围，在此范围内取值均可保证发送端数目小时链路使用饱和并在发送端数目大时不出现Incast现象。

N^* _min需要使得最小窗口条件下瓶颈链接的容量被占满。因为当N>N^* _min时α取较小值，若N^*取值小于N^* _min则可能出现链路性能不被占满的情况。

发送端发包速率为Nw_min，链路的传输速率为CD＝12.5pkt，其中C＝1Gbps(千兆网)，D为网络往返延迟，D＝100us。故N^* _min满足下式：

N^* _max需使α取较大值时交换机缓存不溢出，故需满足：

其中B为交换机缓存(包数量)，通常情况下B的最小值为32个数据包。因此N^*的安全范围为：

N^*∈[7,B/α₀],B>32

我们仍需继续确定α₀才能确定N^*的安全范围。事实上，由后面的结果可以得知，N^*具有一个较宽的安全范围，实际应用的过程中我们可以对安全范围内的可能取值进行实验并选取性能较好的数值。下面我们分别确定

α₀应该足够大，使得流传输达到均衡，且应使瓶颈链接达到饱和。但这里我们建议取相对较小的α₀。因为前文提到，α₀涉及到N^*的安全范围大小，较小的α₀可以保证较大的安全范围，如α₀过大甚至使安全范围消失。这里我们取

α₀＝2

在发送端数量较大时，我们需要较小的α以保证发送端增大过程中不出现Incast现象。因此α₁需满足：

Nα₁<B

α₁＝0看上去是不错的选择，但是这可能会限制单个发送端的发送速率，是一个不太稳定的数值，如果所有发送端都致力于将交换机处的队列长度维持在0，我们无法判断链路是否已经被完全利用，因此这一数值是危险的。因此我们选择α₁＝1。

现在我们获得了发送端数与α的关系，但是发送端的传输层协议是无力知道当前有多少发送端正在向接收端发送数据的，因此我们需要将该阶梯函数的自变量转化为传输协议可以探知的参数。发送端的数量是可以由队列延迟估计出来的，由于N^*有较宽松的安全范围，因此用队列延迟估计发送端数量得出的判据是安全的。N与队列延迟qdelay的关系如下：

N＝qdelay·C/α

因此α的取值公式转化为：

其中，q为队列延时，我们可以得出q^*取值的安全范围：

q^*＝25μs

即α在实际应用中的取值公式为：

其中队列延迟q是每个RTT都会计算的，在原生FAST TCP的算法基础上，我们并没有要求***探知新的参数，而是利用已有的数据对关键参数α进行了适用于数据中心(包括Incast传输模式)的重新设计，这样做的好处是在实际***实施时更为便捷，更有利于日后的工程实现和广泛应用。

另外，本发明实施例的基于FAST TCP的传输控制方法的其它构成以及作用对于本领域的技术人员而言都是已知的，为了减少冗余，不做赘述。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管已经示出和描述了本发明的实施例，本领域的普通技术人员可以理解：在不脱离本发明的原理和宗旨的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由权利要求及其等同限定。

Claims (1)

1.一种基于FAST TCP的传输控制方法，其特征在于，包括：

S1：获取拥塞避免阈值和发送端当前数据包的传输数量；

S2：将所述发送端所述当前数据包的传输数量和所述拥塞避免阈值进行比较，

如果所述发送端当前数据包的传输数量不小于所述拥塞避免阈值，则生成拥塞反馈信息，以根据所述拥塞反馈信息减少数据包的传输数量以避免丢包；

其中，拥塞避免阈值的计算公式如下：

其中，w为所述发送端的所述当前数据包的传输数量，γ∈(0,1]，baseRTT为交换机延时队列中数据包的最小往返时延，RTT为所述往返时延，qdelay是点对点的平均队列延迟，α为修正系数，

其中，q为队列延时，α₀、α₁、q^*均为常数。