Incast现象和解决方案概述

摘要

当前云计算带动了数据中心的跨越式发展。云计算环境下的数据中心具有高带宽、低延迟的特点，传统TCP 协议由于历史原因而造成无法适应新一代的数据中心工作模式，由此带来的Incast 现象会造成基于TCP的上层应用吞吐率急剧下降。本文介绍了Incast现象的起因和常见的解决方案，并对这些方案进行总结分析并指出其各自的利弊。

前言

TCP作为已经运行了无数年的相当成熟的协议，基本上已经完全占据了包括互联网在内的绝大多数的数据通信网络环境。近年出现的基于云计算的数据中心在业务量负荷，网络接口速率和整体规模等方面均已远远超出了TCP在最早开发时的网络应用环境，很多最初设计的默认值都已经不太实用了。例如Linux中RTO定时器的最小值缺省设置为200ms，该数值对于传统广域网来说是合适的，但对于数据中心却不适用了，原因是数据中心的平均往返延时要比此数值低2～3个数量级。因此，传统TCP协议在云计算环境下的数据中心里直接使用会带来一些缺陷，一个常见的情况就是“Incast”现象。Incast现象的表现就是TCP的上层应用吞吐率会急剧下降。

Incast会发生在多打一通信模式下。在这种模式下，多个发送方同时向单个接收方发送数据流，并且任何一个发送方都将发送完当前所有的数据流后，才开始发送后续的数据流。由于同时发送过多的数据流，会造成接收方的交换机缓冲区过载，使得接收方无法正常接收数据，这就是Incast现象。Incast现象与以太网交换机较小的缓存大小，TCP丢包恢复机制和数据中心应用的业务模式等都有密切关系。当来自多台服务器的并发数据占满交换机的缓冲区时，将会导致丢包或TCP超时，TCP超时会使网络上微秒级的往返延时变成几百毫秒级的延迟，因此接收方应用层的吞吐率会比链路容量低几个数量级，即TCP吞吐率急剧下降。这种Incast现象在当前基于云计算的数据中心，或者是大型企业的数据中心里发生的概率很大，常见的场景有互联网企业的Hadoop应用，大型金融企业的TeraData应用等。本文介绍了TCP Incast现象的产生原因及其造成严重后果，并对当前的一些常见的解决方案进行了总结分析并指出其各自的利弊。

Incast问题的产生

多打一的工作模式在当前云计算环境下的数据中心已变得越来越常见，如互联网企业广泛采用基于DFS分布式文件系统，采用MapReduce 技术处理搜索应用。这些应用的特点分别是，DFS是需要等到所有的发送方都传送完他们自己部分的数据后，才会进行对下一个区块的操作。MapReduce是需要从所有节点都提取到计算结果后，才能完成shuffle阶段的操作。搜索是需要将所有分布节点的反馈都汇集后，query操作才算完成。

在集群文件系统内，客户端应用请求某个逻辑数据块（常见的一个读数据块大小是1MB），该数据块是以条带化方式分别存放在若干台服务器上，并采用更小的数据片存储（如32kB，256kB等），这种小数据片被称做为服务器请求单元（SRU）。只有当客户端接收到所有的服务器返回的其所请求数据块的SRU后才会继续发出下一个数据块请求，即客户端同时向多台服务器发起并发TCP请求，并且所有服务器同时向客户端发送SRU。这种多打一的服务器向客户端传入并发数据传输的场景，很容易造成与客户端相连接的交换机端口的缓冲区溢出，继而导致丢包以及TCP重传。在丢包严重的情况下，TCP将经历一个最少时间为200ms的超时期，这由TCP最小重传超时计数器（RTOmin）决定。在并发传输过程中，当某台服务器发生了传送超时而其他服务器已经完成了传输，则客户端在接收到剩余SRU之前，必须等待至少RTOmin时间，并且在等待期间，客户端的链路有可能会处于完全空闲状态，这就导致应用层吞吐量与链路容量相比急剧下降，而且总请求延迟将高于RTOmin，这就是TCPIncast现象。

以下以搜索应用为例，进行举例说明：

搜索业务后台流程：

HUB服务器当收到来自用户的搜索请求后，向后端检索Spoke服务器发送搜索请求。后端集群内的检索服务器在收到请求后搜索本地数据库并响应给HUB服务器。HUB服务器接收到响应后作进一步处理返回给用户。如下图所示:

对于热门关键词搜索，每台检索服务器搜到的内容大概20KB-30KB，如果接口MTU为1500B，需要分成30KB/1500B=20个报文。在应用层，从收到第一个查询结果报文开始计时，等待200ms，如果没有全部到达，就认为丢包，从而认为该台检索服务器搜索失败。

当检索服务器比较闲的状况下，这120台很容易同时而且以千兆网卡线速发送检索到的30KB数据，造成网络burst流量，在发生burst流量时，对于每台接入交换机，40台服务器按千兆网卡线速发出流量，如果上行为20GE，需要在出方向缓存，如果上行40GE，可线速发出流量。在核心交换机上，30G流量汇聚到10G链路，需要在出方向对数据报文进行缓存。在接入交换机上，20G流量打向1G服务器，需要在出方向对数据报文进行缓存。根据应用要求，整条路径转发时延不能超过200ms。如下图所示：

假设前提：120台检索服务器发起burst到一台UI服务器，每台服务器产生30KB流量。每台接入交换机假设接入40台，上联带宽20GE，40台服务器产生流量为30KB*40=1.2MB，需要的缓存大小为1.2MB。

如果接入交换机采用4个万兆，全线速，则non-blocking。每台检索服务器产生30KB流量，120台检索服务器共产生流量为30KB*120=3.6MB=28.8Mb。

如果有2台核心交换机，每台核心交换机会以30Gbps的速率收到28.8/2=14.4Mb流量，但出口只有1个10GE链路，所以需要buffer来缓存，以保证不丢包。需要缓存的时间为：14.4Mb/10Gbps=1.44ms，需要的缓存大小为1.44ms*10Gbps/8=1.8MB，核心交换机每端口需要Buffer为1.8MB。

连UI服务器的接入交换机会以20Gbps的速率收到28.8Mb流量，但出口只有1个千兆链路，所以需要更大量的buffer来缓存，以保证不丢包。需要缓存的时间为28.8Mb/1Gbps=28.8ms，需要的缓存大小为：28.8ms*1Gbps/8=3.6MB。

解决方案

为了避免TCP Incast现象造成的性能恶化，国内外早已进行了这个领域的研究工作。由于超时是引起Incast的主要原因，现有的解决方案的出发点大多是为避免超时发生或减轻超时造成的负面效应，常见的TCP Incast 解决方案有如下几个方面：

链路层解决方案：增大交换机缓存

该方法的思路是减轻造成超时的根本原因，即报文丢失，通过增加交换机上每个端口所分配的缓存空间来解决这个问题。研究表明，如果将交换机的输出端口的缓存增大，那么在Incast现象发生前，可以支持的服务器数量也可以增加。因此，只要服务器的数量固定，采用足够大的缓存是可以防止Incast现象的。交换机的缓存增加会增加交换机的成本，造成交换机性价比下降。而且增加交换机的缓存大小，也会带来另外一个问题，即尽管吞吐率会增加了，但有时仍旧会看到TCP重传现象，这是因为心跳和TCPACK等信令报文会被积压在缓存中，没有及时传送，导致TCP重传。此外缓存增加，可能会带来一定程度的延迟，对于低延迟的应用来说，可能带来不利。所以如何选择交换机的缓存大小，如何做出平衡是门学问。

应用层解决方案

1.增加SRU大小

在采用大SRU传送数据时，某些数据流由于因故（如等待超时，SRU数据发送结束等）成为静止流，使用这些静止流的闲置链路带宽，在一定程度上会屏蔽了Incast问题。研究表明，如果增加SRU大小，会改善整体的吞吐率。举例来说，如果是7台服务器，1000KB大小的SRU的吞吐率是256KB SRU的吞吐率的100倍。但是1000KB的SRU在现实中是不可行的，大部分应用都是请求微小数据块，其所对应的SRU大小为1KB到256KB。存储系统是有数据预读取机制的，所以SRU越大，预读取的效果越好。而采用预取读机制，就需要存储系统在客户端的内存中分配固定大小的区间，这会增加客户端的内存压力，故而可能会导致内核故障，因而大尺寸的SRU往往不在集群存储系统上采用。

2. 减少超时

Incast中的等待超时会导致吞吐率大幅下降，而减少等待超时可以解决Incast现象。如果没有快速重传机制（依靠收到3个以上的重复ACK来判断），数据流在重传某个丢失的报文之前需要等待的时间，由TCP重传超时计数器（RTO）来确定，通过估算RTO值来提前结束超时可以及时响应报文丢失，但提前结束超时又会带来2个问题：

●容易导致欺骗性重传。

●对每次超时，TCP会将其慢启动门限值减少一半并进入慢启动状态，即便是在没有丢失报文的情况下也是这样。此时由于不存在拥塞，TCP将低估链路容量并且吞吐率将会降低。实践表明，大部分减少超时的解决方案都不太理想。

传输层解决方案

1. 降低RTOmin

标准的TCP协议的RTOmin值为200ms，这个值比数据中心的RTT值要高出几个数量级。通常数据中心的RTT值是100μs。由于数据中心网络链路带宽很高，而每个数据块的传输时间要远远小于RTOmin，这形成了带宽浪费。该RTOmin对吞吐率带来了很大的负面效应。

因此，减少RTOmin可以暂时地减轻TCP Incast现象，但无法从根本上解决问题。通常情况下，减少RTOmin可以使吞吐率得到数量级上的改善，但在具体操作上，如果将RTOmin设置为微秒级将会遇到很多现实上的挑战。如微秒级的TCP定时器需要硬件支持（目前尚无这种硬件）或高效软件定时器（目前大多数操作系统都无法提供）。

2.更改TCP版本

当前的TCP的版本，按照拥塞控制方法的不同，可以分成Tahoe，Reno，NewReno，SACK和Vegas供5个版本。Reno版本增加了快速恢复算法，New Reno版本改进了Reno版本的快速恢复算法，当受到一个部分的ACK时，发送方并不退出快速恢复，立刻传输下一个没有被确认的数据报文，避免了多次降低拥塞窗口，因而提高了吞吐率。这是目前比较实用的可以降低Incast问题的一个TCP版本，但当服务器的数量达到一个较大值时，仍然会引起吞吐率大幅下降。

3.DCTCP

数据中心TCP协议（DCTCP）可用来解决TCP在数据中心中使用时造成的问题，它是通过采用以太网交换机支持显式拥塞通知（ECN）来实现的。为了在同步数据传输过程中获得更高的突发性、低延迟和高吞吐量，DCTCP在网络中使用显式拥塞通知向终端主机提供更多的反馈信息。当缓存占用率到达了门限值时，DCTCP会在交换机上使用简单的标记方案，交换机将设置分组上的“经历拥塞”点。DCTCP发起端按照一定的衰减系数来减少发送窗口以响应这些拥塞通知，其选择的系统根据被标记的分组数量，数量越多，衰减系数越大。目前并不是所有的以太网交换机都支持显示拥塞通知的。如果没有显示拥塞通知，DCTCP 将面临与标准TCP 同样的问题。

结束语

尽管国内外工程界和学术界都早已对TCP Incast 现象进行了探讨，但Incast现象仍然是处于早期研究阶段，从实际工程角度看，许多现有的系统都通过各种方法尝试避免TCP吞吐率大幅下降，如限制参与数据块传输的服务器数量，人工限制服务器传输数据的速率，使用微秒级时钟来大幅度减少TCP最小重传超时值，或利用交换机提供并处理显式拥塞通知。这些解决方案都是针对某一特定场景（如服务器数量、数据块大小、链路容量、微秒级定时器、交换机支持ECN等）提出的，其自身都存在着各种限制，无法适应数据中心网络应用环境，也无法从根本上避免TCP Incast现象。TCPIncast现象也暴露出现有TCP协议在最初设计上存在的缺陷，无法适应当前数据中心的业务模式，对TCP协议进行改良并彻底解决Incast问题仍需不断地进行研究和探索，最终会是多种方案的一个平衡。就目前而言，最现实的方案，就是提高交换机缓存，鉴于成本不断下降，目前这个方案变得比较可行了。

<全文结束>

Related Posts