消息传递

DDoS攻击素来以成本低廉（相比防御）、效果显著、影响深远为攻击者所青睐，经过长时间的发展，DDoS攻击方式有很多种，最基本的DoS攻击利用单个合理的服务请求来占用过多的服务资源，从而使合法用户无法得到服务的响应。DoS攻击通常采用一对一的方式，在目标系统带宽、内存、CPU等各项性能指标都不高时，具有明显的效果。随着网络技术的发展，计算机的处理能力迅速增长，内存大大增加，千兆级别的网络出现，目标系统的“消化能力”倍增，这时候，分布式的拒绝服务攻击手段——DDoS就出现了。

利用网络上已被攻陷的电脑作为“肉鸡”，通过一定方式组合形成数量庞大的“僵尸网络”，采用一对多的方式进行控制，向目标系统同时提出服务请求，杀伤力大幅度增加。DDoS攻、防对抗多年，从DoS到DDoS，从以流量取胜到以技巧取胜，从单一攻击到混合攻击，攻击手段正不断进化，本文将一一介绍最常见、最具代表性的攻击方式，企业运营者做到知己知彼，才能有备无患。

一、攻击带宽：以力取胜

如同城市堵车一样，当数据包超过带宽上限，就会出现网络拥堵、响应缓慢的情况。流量型DDoS攻击就是如此，发送海量数据包，顷刻占满目标系统的全部带宽，正常请求被堵在门外，拒绝服务的目的达成。

ICMPFlood

ICMP（Internet控制报文协议）用于在IP主机、路由器之间传递控制消息，控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息，虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。通过对目标系统发送海量数据包，就可以令目标主机瘫痪，如果大量发送就成了洪水攻击。

UDPFlood

UDP协议是一种无连接的服务，在UDPFlood中，攻击者通常发送大量伪造源IP地址的小UDP包冲击DNS服务器或Radius认证服务器、流媒体视频服务器。100kbps的UDPFlood经常将线路上的骨干设备例如防火墙打瘫，造成整个网段的瘫痪。

上述传统的流量型攻击方式技术含量较低，伤人一千自损八百，攻击效果通常依赖受控主机本身的网络性能，而且容易被查到攻击源头，单独使用的情况已不常见。于是，具有四两拔千斤效果的反射型放大攻击就出现了。

NTPFlood

NTP是标准的基于UDP协议传输的网络时间同步协议，由于UDP协议的无连接性，方便伪造源地址。攻击者使用特殊的数据包，也就是IP地址指向作为反射器的服务器，源IP地址被伪造成攻击目标的IP，反射器接收到数据包时就被骗了，会将响应数据发送给被攻击目标，耗尽目标网络的带宽资源。一般的NTP服务器都有很大的带宽，攻击者可能只需要1Mbps的上传带宽欺骗NTP服务器，就可给目标服务器带来几百上千Mbps的攻击流量。

因此，“问-答”方式的协议都可以被反射型攻击利用，将质询数据包的地址伪造为攻击目标地址，应答的数据包就会都被发送至目标，一旦协议具有递归效果，流量就被显著放大了，堪称一种“借刀杀人”的流量型攻击。

面对洪水般的流量，花高价进行抗D带宽扩容和多运营商链路冗余，虽一定程度可提升抗D能力，但面对大量攻击仍旧于事无补，而且浪费资源。知道创宇旗下抗DDoS云防御平台——抗D保，横跨全国的分布式数据中心，600G以上带宽抗DDoS，并可随时应急调用腾讯自有带宽1.5Tb，这使得抗D保拥有超过2个Tb的防御能力。 

二、攻击系统/应用：以巧取胜

这类型的DDoS攻击走的是巧劲，利用各种协议的行为特性、系统的缺陷、服务的脆弱性、软件的漏洞等等发起攻击，不断占用目标系统的资源以阻止它们处理正常事务和请求。

SYNFlood

这是一种利用TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得被攻击方资源耗尽（CPU满负荷或内存不足）的攻击方式。建立TCP连接，需要三次握手——客户端发送SYN报文，服务端收到请求并返回报文表示接受，客户端也返回确认，完成连接。

SYNFlood就是用户向服务器发送报文后突然死机或掉线，那么服务器在发出应答报文后就无法收到客户端的确认报文（第三次握手无法完成），这时服务器端一般会重试并等待一段时间后再丢弃这个未完成的连接。一个用户出现异常导致服务器的一个线程等待一会儿并不是大问题，但恶意攻击者大量模拟这种情况，服务器端为了维护数以万计的半连接而消耗非常多的资源，结果往往是无暇理睬客户的正常请求，甚至崩溃。从正常客户的角度看来，网站失去了响应，无法访问。

CC 攻击

CC攻击是目前应用层攻击的主要手段之一，借助代理服务器生成指向目标系统的合法请求，实现伪装和DDoS。我们都有这样的体验，访问一个静态页面，即使人多也不需要太长时间，但如果在高峰期访问论坛、贴吧等，那就很慢了，因为服务器系统需要到数据库中判断访问者否有读帖、发言等权限。访问的人越多，论坛的页面越多，数据库压力就越大，被访问的频率也越高，占用的系统资源也就相当可观。

CC攻击就充分利用了这个特点，模拟多个正常用户不停地访问如论坛这些需要大量数据操作的页面，造成服务器资源的浪费，CPU长时间处于100%，永远都有处理不完的请求，网络拥塞，正常访问被中止。这种攻击技术性含量高，见不到真实源IP，见不到特别大的异常流量，但服务器就是无法进行正常连接。

之所以选择代理服务器是因为代理可以有效地隐藏自己的身份，也可以绕开防火墙，因为基本上所有的防火墙都会检测并发的TCP/IP连接数目，超过一定数目一定频率就会被认为是Connection-Flood。当然也可以使用肉鸡来发动CC攻击，攻击者使用CC攻击软件控制大量肉鸡发动攻击，肉鸡可以模拟正常用户访问网站的请求伪造成合法数据包，相比前者来说更难防御。

CC攻击是针对Web服务在第七层协议发起的攻击，在越上层协议上发动DDoS攻击越难以防御，上层协议与业务关联愈加紧密，防御系统面临的情况也会更复杂。比如CC攻击中最重要的方式之一HTTPFlood，不仅会直接导致被攻击的Web前端响应缓慢，对承载的业务造成致命的影响，还可能会引起连锁反应，间接攻击到后端的Java等业务层逻辑以及更后端的数据库服务。

由于CC攻击成本低、威力大，知道创宇安全专家组发现80%的DDoS攻击都是CC攻击。带宽资源严重被消耗，网站瘫痪；CPU、内存利用率飙升，主机瘫痪；瞬间快速打击，无法快速响应。知道创宇顶级安全研究团队为抗D保自主研发的Anti-CC防护引擎可以根据访问者的URL、频率、行为等访问特征，智能识别CC攻击，迅速识别CC攻击并进行拦截，在大规模CC攻击时可以避免源站资源耗尽，保证企业网站的正常访问。

抗D保-抗CC攻击数据（监控）

DNSQueryFlood

DNS作为互联网的核心服务之一，自然也是DDoS攻击的一大主要目标。DNSQueryFlood采用的方法是操纵大量傀儡机器，向目标服务器发送大量的域名解析请求。服务器在接收到域名解析请求时，首先会在服务器上查找是否有对应的缓存，若查找不到且该域名无法直接解析时，便向其上层DNS服务器递归查询域名信息。

通常，攻击者请求解析的域名是随机生成或者是网络上根本不存在的域名，由于在本地无法查到对应的结果，服务器必须使用递归查询向上层域名服务器提交解析请求，引起连锁反应。解析过程给服务器带来很大的负载，每秒钟域名解析请求超过一定的数量就会造成DNS服务器解析域名超时。

根据微软的统计数据，一台DNS服务器所能承受的动态域名查询的上限是每秒钟9000个请求。而一台P3的PC机上可以轻易地构造出每秒钟几万个域名解析请求，足以使一台硬件配置极高的DNS服务器瘫痪，由此可见DNS服务器的脆弱性。

抗D保在全国多个城市采用分布式集群方式部署了上千台高效DNS服务器，从而保证各个地区的查询响应速度。抗D保的高防DNS服务，可有效解决突发的上亿级别的随机HOSTA记录查询攻击、递归DNS穿透攻击、DNS流量攻击等多种针对域名解析的攻击请求。

抗D保防御DNS攻击效果示意

三、混合攻击：流量与技巧并用

在实际情况中，攻击者只求达到打垮对方的目的，发展到现在，高级攻击者已经不倾向使用单一的攻击手段作战了，而是根据目标系统的具体环境灵动组合，发动多种攻击手段，既具备了海量的流量，又利用了协议、系统的缺陷，尽其所能地展开攻势。

对于被攻击目标来说，需要面对不同协议、不同资源的分布式的攻击，分析、响应和处理的成本就会大大增加。

抗D保拥有国内最大的抗D集群，使用腾讯宙斯盾流量清洗设备并结合由知道创宇研发的Anti-DDoS引擎，5秒发现恶意攻击，10秒快速阻断，2T带宽储备，通过多种防御手段，防御各种类型、形态的DDoS攻击，包括基于网络层的攻击，如TCPFlood、UDPFlood、ICMPFlood，以及应用层攻击，类似HTTPFlood这种试图耗尽服务器资源的攻击，同时可以有效防御各种反射攻击和僵尸网络攻击。

面对一次次攻击，即使是去年10月让美国半个互联网瘫痪的DDoS攻击事件，也只是让很多人小心脏稍微颤抖了几下，在大家的印象中，DDoS只是一阵海啸，很快就能恢复了往日的平静。但是，DDoS在互联网发展进程中已经留下了太多不可磨灭的破坏，许多企业就此一蹶不振。而且随着互联网+的不断推进，商业竞争的愈演愈烈，它的危害越来越大，任何企业组织都应该考虑自己的DDoS防护方案，而不是成为攻击的炮灰，也尽量避免遭受攻击后再亡羊补牢。

相关新闻

2016-12-20

2017-03-06

2017-07-28

2017-08-17

2017-09-04

近日，2017云栖大会·深圳峰会如期举行，多项阿里云新产品对外发布。在企业级互联网架构分会场，来自阿里中间件（Aliware）的技术专家及合作伙伴，为现场参会嘉宾带来最新的传统IT架构到企业级互联网架构跨越式升级、实现互联网转型的产品及解决方案。其中高级技术专家姜宇在分享中带来的Aliware新产品—全局事务服务（GlobalTransactionService，简称GTS），在分布式事务处理上带来的高性能和技术创新令到场参会的各路技术专家眼前一亮。

Aliware新成员—全局事务服务GTS技术分享现场

分布式事务背景

OLTP领域中很多业务场景都会面临事务一致性的需求，传统业务系统常以单体应用形式存在，只需借助特有数据访问技术和框架，结合关系型数据库自带的事务管理机制来实现事务一致性的要求。而目前大型互联网应用和平台往往是由一系列分布式系统构建而成，平台和技术架构也是流派纷呈。

尤其是微服务架构盛行的今天，一个看似简单的功能，内部可能需要调用多个“服务”并操作多个数据库或分片来实现，单一技术手段和解决方案已无法满足这些复杂应用场景。因此，分布式系统架构中分布式事务是一个绕不过去的挑战。什么是分布式事务？简单的说，就是一次大操作由不同小操作组成，这些小操作分布在不同服务器上，分布式事务需要保证这些小操作要么全部成功，要么全部失败。

本质上来说，分布式事务就是为了保证不同数据库或消息系统的数据一致性。

分布式事务三大难题：一致性、高性能和易用性

分布式系统的事务一致性本身是一个技术难题，没有一种简单完美的方案能够应对所有场景，很难兼顾事务一致性，高性能与易用性。三者缺一，则适用场景大大受限，实用价值不高。

首先是一致性：要求在各种异常情况下保证数据是强一致的。目前最常见的一致性解决方案是最终一致性方案，通常是结合消息中间件实现，在互联网企业中广泛使用。最终一致性实现方案比较复杂，开发、运维成本高，并且与强一致相比，业务上是受很多限制的。

其次是高性能：目前基于XA协议的两阶段提交是最常见的分布式事务解决方案，但XA类产品的典型不足是性能低下，这对于互联网大并发需求下的多数企业是无法接受的。国外具有几十年历史和技术沉淀的基于XA模型的商用分布式事务产品，在相同软硬件条件下，开启分布式事务后吞吐经常有数量级的下降。

第三是易用性：为了满足一致性和高性能要求，出现了一些特定场景下的分布式事务方案，但通常会限制用户用法，对业务侵入性强，无法做到简单易用，带来更多开发成本。

世界级应用场景，催生世界级分布式事务解决方案

早期的阿里巴巴集团随着业务高速发展，内部不断涌现各种典型的分布式事务需求，比如阿里内部广泛使用的TDDL分库分表所带来的分库间数据不一致问题，HSF服务化后所带来的服务链路上数据不一致问题等。在这个过程中，各业务技术团队利用现有中间件技术手段实现分布式事务处理，但这些手段都较为复杂，工作量大，对应用侵入严重，有些适用场景还有限制。

2014年5月开始，阿里中间件（Aliware）内部命名为TXC的分布式事务中间件开始研发，同年10月1.0版本发布，分布式事务功能已经具备，但性能还有局限，只适合于吞吐量较小的场景；2015年12月，TXC2.0版本发布，相比1.0版本性能提升10倍以上，在阿里内部多条业务线得到部署。

通过部署TXC，应用只需极少的代码改造和配置，即可享受分布式事务带来的便利。TXC作为阿里内部为解决分布式数据强一致性问题而研发的分布式事务中间件，彻底解决了分布式事务数据一致性的问题，简单易用，先后在淘宝，菜鸟，淘票票和村淘等多个业务的核心系统上得到部署和验证。

顺应云时代潮流，GTS应运而生

从2016年年中开始，在阿里内部一直接受锤炼的分布式事务中间件TXC在2.0版本后，随着阿里中间件上云热潮，开始通过专有云输出，并得到了市场极大认可，适用场景得到进一步拓展，全面涵盖电商、物流、金融、零售、政企、游戏、文娱等领域。2017年2月，TXC2.0通过阿里云对外公测，外部改名为全局事务服务（GlobalTransactionService，简称GTS）。

GTS总体架构图

在整体架构方面，GTS由三个组件组成：客户端（GTS-Client），资源管理器（RM），事务协调器（GTS-Server）。客户端与事务协调器间，资源管理器与事务协调器间都是通过GTS分布式事务协议进行通信。客户端负责界定事务边界，开启/提交/回滚全局事务，资源管理器负责管理资源，支持的资源包括：DRDS，Oracle，MySQL，RDS，PostgreSQL，H2，MQ，后续计划根据实际业务需求支持更多类型资源。事务协调器，也就是GTS服务器，是分布式事务处理的大脑，负责协调整个事务过程。GTS事务通过RPC框架和消息中间件进行事务传递，把整个业务调用链路或者消息链路串成一个分布式事务，极大简化应用开发。

在高可用方面，GTS支持同城容灾与两地三中心容灾，可保证各种异常情况下的数据一致。在易用性方面，GTS对业务无侵入，真正做到业务与事务分离，开发者可以集中精力于业务本身。在技术创新方面，GTS也走在了行业前沿。项目负责人阿里高级技术专家姜宇（花名于皋）拥有13项分布式事务的核心技术专利，研发团队的技术专家张松树也有3篇专利。通过大量的专利技术，精妙的算法，与精巧的分布式事务私有协议，GTS取得了超强的性能。

另外，在部分严苛的行业应用场景，比如金融用户的资管项目分布式事务场景下，GTS也经历了严格的测试，按照用户要求顺利完成功能性、稳定性和性能测试。下图是一个典型性能测试场景数据，从实测数据可以看出，开启GTS（TXC）分布式事务后性能下降不明显。目前GTS已经在资金业务上有实际应用，线上大量真实数据验证了GTS的高效可靠。

GTS典型性能测试场景数据

性能优异，业务场景广泛

作为新一代企业级分布式事务服务产品，全局事务服务GTS兼顾了事务一致性，高性能与易用性。在满足事务ACID的前提下，普通配置的单服务器就可以达到15000TPS以上的超强性能（两个小时内完成1亿多笔业务），3台8核16G内存虚机组成的服务器集群可以支撑1万TPS以上的分布式事务，与同类产品相比，性能优势明显。另外简单易用对业务无侵入，为广大企业大幅降低开发成本，业务场景非常广泛：

1、跨多分库的分布式数据库事务场景：关系型数据库普遍支持事务，能够满足事务内的SQL要么全部成功、要么全部失败。但客户从单机数据库往分布式数据库迁移的情况下，原有的一个事务往往会被拆分为多个分库上的事务。由于网络的不可靠性，容易出现部分分库上成功，部分分库上失败的情况。GTS结合DRDS可彻底解决了这一问题。

2、跨多数据库的事务场景：复杂的业务系统经常会使用多个数据库，甚至多种类型的数据库，比如企业中Oracle，MySQL和其他关系型数据库并存的情况时有发生。业务同时操作多个数据库的情况下，一旦发生先提交的事务成功、后提交的事务失败，就很难解决。GTS支持各种常见关系型数据库，并提供多数据库间的事务保证。

3、跨数据库系统、消息系统的事务场景：消息系统被广泛地用于系统间解耦，一般先执行一段业务逻辑，执行成功会向消息系统发送一条消息，用于通知或触发下游业务。这个场景下，如果业务逻辑执行成功、消息发送失败，则业务不完整；如果先发送消息，但执行业务逻辑失败，同样存在问题。GTS提供了针对消息系统以及常见关系型数据库的操作入口，保证数据库操作和发送消息要么同时成功、要么同时失败。

4、跨服务的事务场景：随着业务复杂度提升，大多企业会对业务进行服务化改造。可能存在服务一操作MySQL和DRDS，服务二操作Oracle，要求两个服务操作要么同时成功、要么同时失败，否则会造成业务数据的不一致。GTS可以很方便地进行跨多个服务的分布式事务。

依托阿里中间件(Aliware)，打造世界一流企业级互联网架构平台

据GTS项目负责人姜宇介绍，“GTS作为一款高性能、高可靠、接入简单的分布式事务中间件产品，可与DRDS、RDS、Oracle、MySQL、PostgreSQL、H2等数据源，EDAS、Dubbo及多种私有RPC框架，MQ消息队列等中间件产品配合使用，可轻松实现分布式数据库事务、多库事务、消息事务、服务链路级事务及各种组合。策略丰富，易用性和性能兼顾，将真正完善阿里云中间件产品线。”

GTS（TXC）的研发依托于阿里中间件(Aliware)团队，中间件技术部是阿里巴巴集团生态系统的技术基石，为集团各大业务群提供可靠、高效、易扩展的技术基础服务；并在此基础上打造世界一流的中间件产品、高可用架构基础设施和企业级互联网架构平台，为全球企业和客户提供服务。

更多AliwareGTS产品服务和技术细节，请访问官网：

相关新闻

2016-04-19

2016-06-13

2016-10-24

2016-11-04

2017-12-29