0 引言

数据中心已经成为大数据、云计算和移动计算必不可少的基础设施。现代数据中心基本上是基于Internet模型建立的，因此大部分现有数据中心都直接使用经典的TCP/IP模型。然而经典的传输控制协议(Transmission Control Protocol, TCP)在数据中心环境中却往往显得力不从心，在笔者所在实验数据中心当中部署和测试应用时，发现应用的性能显得极其低下。经过大量的收集、统计和分析工作，我们发现了TCP连接建立过程中存在的潜在问题：TCP握手数据包“SYN”一旦丢失，则会造成较大的连接时延，从而严重影响整个计算任务的性能、降低计算结果的准确性甚至使得整个计算任务错过规定的计算时间。为了解决这个问题，提出了一种基于加权随机早期检测(Weighted Random Early Detection, WRED)的主动队列管理方法来避免SYN包的丢失，从而优化数据中心中TCP连接的建立过程。这种方法不需要更新现有数据中心的任何设备，也不需要更改现有的TCP，可以在任何数据中心当中有效地部署。

1 TCP连接建立问题

数据中心是大量的计算节点通过网络相互连接而组成的高性能计算设施，这些计算节点之间相互协作，最终完成一个计算任务。这些计算任务的完成一般都有一定的时间限制，这个限制一般被称为服务水平约定(Service-Level Agreement, SLA)。为了使计算节点获得更多的处理时间，数据中心内部都采用高速网络连接。由于计算量庞大，数据中心中的计算任务一般都使用大量的计算节点并行运行，最后将这些计算结果汇总到同一个计算节点再作统一的处理，这种计算模型一般被称为Map/Reduce^[1]。

为了处理某个计算任务，建立了一个基于FatTree结构^[2]的数据中心。FatTree结构(如图 1所示)的优点是在数据中心的任意层次都不需要使用更高性能的交换机/路由器的前提下对整个数据中心提供全二分带宽(bisection bandwidth)，从而提高数据中心的性价比。在这个实验数据中心中，使用Map/Reduce模型在不同的服务器上部署计算任务来收集和处理数据，然后在特定的时间点把这些分别处理的数据汇总到某个服务器集中处理。从收集、处理到汇总计算的时间必须被限制在某个预定的SLA之内完成，但在实际实验时发现，大量的计算任务远远地错过了预定的SLA。

起初笔者认为这是由于TCP传输效率引起的，因此根据已有数据中心TCP优化的相关文献资料，更换了TCP的不同版本(例如DCTCP等^[3-5])，但还是出现大部分的计算任务错过了SLA。为了进一步分析其原因，我们收集了网络运行过程中的信息，并对网络的运行情况进行了分析。最终发现了数据中心中关于TCP的一个潜在问题：TCP连接建立过程中，一旦SYN包丢失，则连接建立过程被延迟，而由于缺少一些数据，使得计算精度被降低甚至整个计算任务超过时间限制而无效。

为了隐藏实验数据中心应用的部署细节，同时也为了能更清楚地阐述在分析中发现的问题，使用一个简化版本的实验来说明连接延迟问题。如图 2所示，有21个服务器由一个端口速率均为1 Gb/s的48口交换机相互连接。其中20个服务器运行计算任务，而每个服务器处理10个单独的计算任务。当每个服务器中相应的任务处理完成后，各个服务器将自己的处理结果汇总给一个特定的服务器。这20个服务器称为工作节点(worker)，而这个特定的服务器被称为汇总节点(aggregator)。当汇总节点接收到所有工作节点的计算结果后，整理这些结果，最后整个计算任务完成。交换机共有8 MB主存空间，这些主存平均分配给48个端口。由于交换机运行需要占用一定的主存，但手册上并未给出具体数值，我们通过实验提前估算了在平均分配策略下每个端口可以分配100 KB左右的队列空间。此外，根据实验统计，所有数据处理任务完成时间相差在500 ms以内。为了便于理解和估计，将每个处理任务发送的数据量限制为1 MB, 可以简单计算需要传输的总数据量为20×10×1 MB=200 MB。由于瓶颈带宽为1 Gb/s，在理想情况下，整个传输完成时间应该为1.6 s左右。然而在实际网络中远远达不到全速率的传输，加上TCP握手时间、传输时间、TCP窗口调整速率损失以及TCP丢包重传时间等因素，预计流完成时间应该在3 s以内较为合理, 但实际的实验结果却远远超出了3 s。

为了进一步分析原因，将这200个传输任务进行编号，分别记为0~200条流。在实验中没有任何其他背景流量的情况下，200条流的完成时间如图 3(a)所示，其中横坐标表示流的编号，纵坐标则表示流从开始建立TCP连接到完成1 MB数据传输所经历的时间。从图 3(a)中可以看出，有少量的流用了9 s左右的时间才完成传输, 这影响了整个数据的完整传输，降低了计算结果的质量。

将图 3(a)中的流完成时间进一步分解为图 3(b)所示的连接建立时间和图 3(c)所示的流传输时间。连接建立时间是指从开始建立TCP连接到连接建立完成的时间，而流传输时间是指从TCP连接建立完成到1 MB数据传输完成所用的时间。从图 3(b)中可以清楚地看到，某些连接在创建时所消耗的时间就已经超过了3 s，少量的连接甚至消耗了9 s左右；而图 3(c)所显示的传输数据所占的时间仅为很少的一部分，用于传输的最大时间仅为2.02 s。因此整个任务的完成时间主要由连接建立时间所决定。

Map/Reduce流量表现出极大的突发和汇聚特性，也被称为高扇入(high fan-in)特性^[6]。当大量的流申请和汇总节点建立连接时，由于交换机出口队列中存在大量的分组，从而导致队列拥塞。现有的工作多集中在研究数据包丢失之后如何快速重传该数据包以避免200 ms的最小重传超时时间(Retransmission TimeOut，RTO)^{[5, 7-8]}。而实验表明，队列拥塞也可能造成TCP握手数据包“SYN”丢失，此时发送端和接收端均无法发现SYN包的丢失，因此只能等待超时。通过实验发现，超时时间大概是3 s左右(不同操作系统中超时时间略有不同)。笔者试图减少这个延迟时间，但并没有找到可以控制这个时延行为的环境变量。要减少这个超时时间，必须修改TCP，这和我们不修改当前运行环境的出发点相冲突。

SYN包被丢弃到超时的过程如图 4所示，当发送端发送的SYN包丢失之后，发送端和接收端都无法得知SYN包的丢失信息，因此发送端必须等待超时之后才会再次发送SYN包。接收端接收到SYN包之后回复SYN+ACK包，最后发送端回复ACK包后连接建立完成，发送端和接收端之间开始数据传输。如果重传的SYN包再次因为拥塞而丢失，延迟时间将会呈指数增长，这个行为被称为TCP的指数性回退(exponential backoff)。这就是实验中为什么有的连接建立时间为9 s的原因。

需要说明的是，在实际网络中一般都会部署主动队列管理(Active Queue Management，AQM)，例如随机早期检测(Random Early Detection, RED)协议^[9]，来优化TCP性能。主动队列管理是在队列还未达到最大值之前就开始主动丢弃一些数据包，从而提前使得TCP降低其拥塞窗口而降低网络拥塞的有效方法。然而RED等协议无法区分普通数据包或者SYN包，因此即便在队列未满的情况下也会引起SYN包丢失。

在传统Internet当中也存在SYN包丢失的问题，然而由于Internet网络当中的往返时间较长(一般为500 ms以上)，同时用户对网络延迟的容忍度相对较高，因此问题并不严重。但是在数据中心中，往返时间较短(一般仅为100 μs左右^[6-7])，且计算任务对网络延迟的容忍度较低，因此SYN包丢失所带来的影响更为突出。

2 基于WRED的连接建立优化 2.1 SYN包丢失和队列长度关系

连接延迟问题的关键在于交换机端口拥塞之后，SYN包丢失会造成超时。本节试图从根源上解决SYN包丢失所带来的问题。

首先，SYN包丢失是由于队列溢出引起的，因此试图通过增加队列长度来降低SYN包丢失的概率。由于实验中使用的交换机是共享内存的，可以控制给特定端口所分配的主存空间比例。为此改变汇总节点所连接的交换机端口的队列大小，从100 KB增加到300 KB，然后收集不同队列大小所对应的所有流的平均和最大完成时间，结果如图 5所示。从图 5可以看出，随着分配的队列空间的增加，所有流完成的平均时间变化不大，但是最大流完成时间总在3 s以上。这意味着，随着队列空间的增大，始终有SYN包丢失，并且存在丢失2次的可能。其原因在于只要不发生队列溢出，发送端的TCP拥塞窗口就会一直扩大，直到发生拥塞而丢包，拥塞窗口才会减小。因此，无论给队列分配多大空间，总会被填满并引起SYN包丢失。此外，为了降低数据中心建立的成本，一般也不会在数据中心的接入层使用大主存的高端交换机^[3]。因此，通过更换高端交换机来避免SYN包丢失是行不通的。

2.2 关键技术

目前大多数低端交换机都支持WRED主动队列管理协议或者类似协议(例如华为系列的交换机)。WRED协议^[10]在RED协议^[9]的基础上，通过IP数据包头当中所携带的不同的DSCP (Differentiated Services Code Point)值来区分不同的阈值和丢包概率，从而提供区分服务。RED协议为队列设置一个最小阈值(Th_min)和一个最大阈值(Th_max)。平均队列长度小于最小阈值时不丢包；在最小阈值和最大阈值之间时，交换机以一定的概率丢弃数据包(不超过设置的最大丢包概率Prob_max)；超过最大阈值时，丢弃所有的数据包。其具体过程如图 6所示。

通过WRED协议来避免SYN包的丢弃的基本原理是为普通数据包设置一个队列阈值，当达到阈值时，以一定的概率丢失数据包，从而为SYN包预留下队列空间。由于数据中心当中往返时延(Round-Trip Time, RTT)较小，可以通过TCP的机制快速重传丢失的数据包。但是通过TCP的现有机制无法快速重传SYN包，因此，可以考虑牺牲部分数据包的存储空间来换取更重要的SYN包的传输。

数据中心中一般不存在多媒体数据包，TCP包占95%以上，此外还有少量UDP广播包用于广播配置信息和少量ICMP包用于网络控制，但这些数据包的量不会造成网络拥塞，因此主要通过WRED协议控制TCP包的流量。如果数据中心中有其他数据包的流量较大，可以使用不同的DSCP参数和TCP进行隔离。

在具体实现过程中，需要解决以下三个关键问题。

1) 交换机如何识别SYN包。

SYN包的识别需要解析传输层包头，而交换机是二层设备，无法检测四层包头信息，因此考虑在端系统上进行识别。目前数据中心的应用几乎都部署在虚拟机上，而我们无法同时修改所有的客户端操作系统(Guest Operation System)，因此考虑在现有主操作系统中(或称为Hypervisor)增加一个TCP代理，所有虚拟机上的数据包要发送出去，都必须经过这个代理，如图 7所示。识别过程是通过匹配数据包包头的特定字段，如果字段全部匹配上，则这个数据包是一个SYN包，同时将这个数据包的IP包头中的DSCP字段进行标记，方便交换机识别。为了避免标记SYN包的DSCP值和网络中已经部署的DSCP值冲突，采用DSCP值当中专门为本地网络和实验网络预留的数值段，即DSCP值最末两位二进制位为11^[11]。

2) WRED协议限制的是平均队列长度，如何限制数据包的队列占用。

WRED协议限制队列长度是通过滑动平均(moving average)的方式来计算历史平均队列长度，因此设定阈值智能控制平均队长，实际队列长度还是有可能达到最大队长从而造成SYN包丢失。根据Cisco交换机的标准，WRED协议计算队列长度的方式为：

$ avg(t) = avg(t - 1) \cdot (1 - {0.5^{exp}}) + qlen \cdot {0.5^{exp}} $

其中:avg(t)为当前平均队列长度，avg(t-1) 为上一个周期的平均队列长度，而qlen为当前的实际队列长度。因此，当WRED参数exp取值为0时，则交换机将用实际队列长度来控制丢包。本文将普通数据包对应最大阈值设为低于最大队列长度的某个值，在队列长度超过阈值后，数据包将被丢弃，从而为SYN包预留一定的空间；对于SYN包，将对应的最小阈值和最大阈值都设置为最大队列长度，实际上就不会对SYN包进行丢弃，直到队列满为止。

3) 需要为SYN包预留多少空间。

在最大阈值之上的空间是为SYN包预留的，普通数据包不能占用。如果预留空间过多，则会影响数据包的传输效率；而如果预留空间过少，则SYN包会因为队列溢出而被丢弃。因此必须知道需要预留的空间大小。为此，统计了在0.4 ms内到达队列的SYN包数量(包括被丢弃的SYN包)。实际上，对于1 Gb/s的端口速率，在0.2 ms内，队列已经可以清空24 KB的空间来存储SYN包。考虑到实际网络的传输效率，我们认为在0.4 ms内同时到达的SYN包会因为空间不足而同时被丢弃。实验结果表明在大多数情况下，在0.4 ms内仅有1个SYN包同时到达，而同时到达2个SYN包的次数仅为10。因此在网络正常的情况下，不会出现大量的SYN包同时到达的情况。在SYN泛洪攻击的情况下，可能会出现网络中存在大量SYN包的情况，从而导致SYN包溢出。然而本文讨论的场景主要是在网络中已经有有效的防火墙的情况下，正常TCP流量的性能问题，因此此处假定防火墙已经拦截了大量SYN包泛洪的情况。

将每个服务器上运行的任务数从10增加到16(由于实验服务器CPU只有16核，如再增加任务数量会使每个任务无法以全速率运算，影响任务运行效率), 此时最大流数量为320。图 8显示了同时到达的SYN包的最大值与网络中流数量的关系。可以看出，在0.4 ms内，最大的SYN包并发数量为4，且出现次数仅为1。这种关系为预留队列空间提供了很好的参考。

2.3 最终方案

在解决了以上三个关键问题后，本文提出了一种优化TCP连接建立过程的简单方案。

首先，在端系统中部署TCP代理用于匹配SYN包并标记特定的DSCP值，此处选择DSCP值为111111表示SYN包；对于其他数据包则不作标记，如果边界路由器部署有区分服务，则边界路由器会标记数据包。

其次，更改网络中交换机的WRED配置，将DSCP值为111111的最大阈值和最小阈值都改为队列长度，因此SYN包永远不会主动丢弃。对于其他数据包对应的DSCP值，最小阈值需要设置得相对较高，以避免不必要的丢包影响网络利用率；最大阈值和最小阈值之间的差值也要足够大以避免不同的TCP实例同步减小拥塞窗口。因此将其他DSCP值的最小阈值改为队列长度的一半，最大阈值改为队列长度减8个包大小，从而预留8个包的空间给并发的SYN包。

3 实验与分析

网络配置和第一章配置相同。客户端的最大分段大小(Maximum Segment Size, MSS)设置为1 024，每个包的大小为1 KB，因此队列可以存储大约100个包。将111111对应的WRED的最大阈值和最小阈值都设置为100;对于普通数据包，设置最小阈值为50，最大阈值为92(即预留8个空间存储SYN包)，最大阈值和最小阈值之间的最大丢包概率为5%。通过实验统计这200条流的传输完成时间，结果如图 9(a)所示。可以看出，所有流都在3 s以内完成, 最大完成时间仅为2.03 s。同样将这个时间分解为连接建立时间和流传输时间，如图 9(b)和图 9(c)所示。可以清楚地看到，此时连接建立时间最大仅为1.4 ms；而流完成时间主要取决于传输时间，最大传输时间为约2.03 s。数据中心TCP传输效率的优化已经超出本文的主题范围，可以参考其他文献，如文献[3, 5, 12-14]等。

接着通过实验验证流数量变化对流完成时间的影响。将每个服务器运行的任务数量从10增加到16，然后统计所有流的平均完成时间和最大完成时间，结果如图 10所示。可以看出随着流数量的增加，平均完成时间呈线性增加，但是最大完成时间略有起伏，其原因在于对于不同情况所采用的WRED参数完全一致，并未调校，因此性能上会有所不同。此外，还考虑了理想情况下所有流均以最高速率传输时的流完成时间作为参考的预计完成时间。

最后一组实验考虑WRED参数对TCP性能的影响。WRED共有Th_min、Th_max和Prob_max三个参数，其中Th_max在本方案中用来控制预留的空间，不能调整。因此实验中先将Th_min的值从10增加到60，并统计所有TCP流的平均和最大完成时间，结果如图 11所示。可以看出，Th_min的大部分值对最大完成时间的影响都不明显，但在45时达到最小值。

接下来将Th_min的值固定为45，然后改变Prob_max的值从2%到50%，统计所有流的平均和最大完成时间，结果如图 12所示。可以看出，Prob_max值在12%~44%时TCP性能较好，并且在14%~22%时达到最佳性能。

4 结语

针对TCP连接建立过程中由于拥塞而出现的SYN包丢失所带来的数据中心任务失败问题，本文提出了一种基于WRED协议的方法来避免SYN包的丢失。这种方法无需更改任何设备和协议，可以在现有数据中心当中直接部署。实验证明，该方法有效地降低了TCP连接建立的时间，避免了任务超时的问题。然而TCP传输的性能和WRED协议的设置的参数相关，未来的实验中可以进一步设计一种自适应的方法来自动配置WRED参数。此外，本文提出的方法提高了TCP连接建立的成功率，同时也使得TCP之间竞争更加激烈。在未来的研究中如果可以考虑网络的拥塞情况，适当地控制一定时间段内TCP连接成功的数量，则效果会更好。