阿里云云盾抗下全球最大DDoS攻击(5亿次请求，95万QPS HTTPS CC攻击)
摘要： 本文讲的是阿里云云盾抗下全球最大DDoS攻击(5亿次请求，95万QPS HTTPS CC攻击)， 报告披露，去年11月，阿里云安全团队成功防御了黑客对阿里云平台上某互联网金融用户发起的超大规模HTTPS/SSL CC流量攻击，此次攻击也是迄今为止全球有统计数据最大的HTTPS SSL/CC攻击。 作为国内最大的公共云计算服务提
报告披露，去年11月，阿里云安全团队成功防御了黑客对阿里云平台上某互联网金融用户发起的超大规模HTTPS/SSL CC流量攻击，此次攻击也是迄今为止全球有统计数据最大的HTTPS SSL/CC攻击。
作为国内最大的公共云计算服务提供商，大量网站选择阿里云的安全防护，也因此为国内客户防御了当前互联网上主要的攻击行为。
攻击者从11月5日下午14点开始针对网站开始发起攻击，出现两次波峰分别在14点10和晚上7点30左右，总攻击量达到了5亿次请求。
攻击请求QPS变化
通过日志数据分析，攻击特征如下：
（1）攻击聚焦首页；
（2）攻击IP在攻击的过程中,为了接近真实主机，攻击者伪造了UA和Referer字段以及Cookie；
此次攻击者攻击的目标网站是HTTPS类型，其对资源的性能消耗原本就比HTTP要高出许多，攻击者希望通过CC这类资源消耗型攻击，达到击穿网站性能瓶颈，从而使网站服务瘫痪。目前如此巨大的峰值为95万QPS 的HTTPS/SSL CC攻击，已远远超过国内大部分防护厂商系统的性能瓶颈。
最终，阿里云云盾高防系统成功防御了黑客攻击，保存了大量有效的攻击证据，为用户事后溯源追踪提供了资料。阿里云安全团队预测，随着越来越多的网站追求数据的安全性采用HTTPS协议进行流量传输，网站遭受到HTTPS CC攻击的可能性随之上升。由于对HTTPS协议的处理相对HTTP会消耗更多的资源，因此无论是网站运营者还是安全服务商在面对HTTPS CC资源消耗型攻击时，防护能力会面临巨大挑战。
事实上，进入2016年后，包括HTTPS CC攻击在内的DDoS攻击事件层出不穷。2月份，国外黑客组织对全球最大在线游戏对战平台之一的XBOX发起了大流量DDoS攻击，对业务造成了长达24小时的影响。3月初，国内游戏厂商亦遭到大流量DDoS攻击。这似乎宣告着2016年注定是不平凡的一年。
XBOX团队在长达24小时的对抗后，宣布业务恢复正常
然而，这一切都只是已经过去的2015年不平凡的延续——2015年是DDoS攻击非常活跃的一年。根据阿里云安全团队发布的《2015下半年云盾互联网DDoS状态和趋势报告》，2015年共监测到近20万起DDoS攻击事件。对比上下半年的DDoS攻击事件数量，呈现下半年明显多于上半年的趋势（＋32％）。
从被DDoS攻击骚扰的行业来看，游戏行业遭受的威胁最大，占到被攻击行业的近一半。游戏行业已经成为DDoS攻击最严重的重灾区。
阿里云云盾产品（http://click.aliyun.com/m/4232/）负责人吴翰清称，“我们预测在2016年整个互联网可能会发生流量在800Gbps－1TGbps之间的攻击事件。以商业竞争或敲诈勒索为背景的DdoS攻击威胁形势仍将严峻。游戏仍旧是DDoS事件高发行业。来自移动终端APP的应用层的DDoS攻击将迅速崛起。”
阿里云云盾从2015年Q3开始发布互联网DDoS状态和趋势报告。据云盾负责人介绍，云盾Anti-DDoS服务具备的Tb级别的防御带宽和攻击检测能力，以及阿里云大数据分析系统带来的PB级日数据处理和万亿量级会话分析能力。当前，阿里云云盾在全国已经部署了几十个清洗集群，保护了中国30%的网站。
完整下载《2015下半年云盾互联网DDoS状态和趋势报告》，请访问：
http://yundunddos-help.oss-cn-hangzhou.aliyuncs.com/%E4%BA%91%E7%9B%BE%E4%BA%92%E8%81%94%E7%BD%91DDoS%E7%8A%B6%E6%80%81%E5%92%8C%E8%B6%8B%E5%8A%BF%E6%8A%A5%E5%91%8A-2015H2-Final%20Version.pdf
阿里妹导读：TPP(Taobao Personalization Platform, 也称阿里推荐平台 ) 平台承接了阿里集团300+重要个性化推荐场景，包括手淘首页猜你喜欢、首图个性化、购物链路等。除了提供应用层面的支持和封装，还肩负着机器分配和维护各场景运行稳定的重任。
理想情况下，TPP平台上的场景owner不需要关注底层的资源分配情况，平台尽可能的提高CPU利用率，同时保证平台上场景的稳定。QPS（每秒查询率）增加的时候扩容，QPS减少的时候缩容，未来这些在夜间被拿掉的机器可以用来混部离线任务等；另外，在2016年双11的时候，总的机器数目不足以维持所有的场景以最高性能运行，需要有经验的算法同学判断场景的优先级，从低优先级的场景上拿出来机器，补充到高优先级的场景中保证成交额。这些平台稳定性工作都是需要繁琐的人工调度，会有如下的缺点：
-
人力成本巨大：人肉无法监控和处理所有的场景；
-
反应时间较长：从发现场景出问题，找出可以匀出机器的不重要场景，到加到重要场景所需要的时间相对过长，而程序天然的有反应时间短的优势；
-
人力无法全局高效的调度资源， 而程序可以更敏感的发现场景的问题，更全面的搜索可以拿出来机器的场景，并可以准确计算拿出机器的数目，有更好的全局观。
基于如上的两点：日常的时候提高资源利用率，大促的时候解放人力，TPP智能调度系统就产生了。TPP智能调度系统以每个集群（一组机器，承载一个或多个场景）的CPU利用率，LOAD，降级QPS，当前场景QPS，压测所得的单机QPS为输入，综合判断每个集群是否需要增加或者减少机器，并计算每个场景需要增减机器的确切数目，输出到执行模块自动增减容器。 TPP智能调度系统有如下的贡献点：
-
日常运行期间，保证服务质量的情况下最大化资源利用率；
-
大促运行期间，能够更快速、更准确的完成集群之间的错峰资源调度；
-
支持定时活动事件的录入，如红包雨、手淘首页定时的Push，程序自动提前扩容，活动结束自动收回；
-
对重要场景提前预热，完成秒级扩容。
该系统由TPP工程团队和猜你喜欢算同学联合搭建而成，从2017年9月开始规划，到10月1日小批量场景上线，到10月13日三机房全量上线；经过一个月的磨合，参加了2017年双11当天从 00:15 %到 23:59的调度，峰值QPS达到百万级别。在日常运行中，集群平均CPU利用率提高3.37 倍， 从原来平均8%到27%；在大促期间，完成造势场景，导购场景和购后场景的错峰资源调度，重要服务资源利用率保持在 30% ，非重要服务资源利用率保持在50%, 99%的重要场景降级率低于2%。同时TPP智能调度系统的"时间录入"功能支持定时活动，如首页红包的提前录入，提前扩容，活动结束收回机器，改变了以前每天需要定时手动分机器的情况。
问题定义与挑战
TPP智能调度系统要解决的问题为： 如何在机器总数有限的前提下，根据每一个场景上核心服务指标KPI（异常QPS等）和场景所在集群物理层指标KPI(CPU,IO等)，最优化每一个场景机器数目，从而使得总体资源利用率最高。
更加直白一点，就是回答如下的问题：
-
怎么判断一个集群需要扩容？扩多少的机器
简单的CPU超过一定的水位并不能解决问题。不同的场景的瓶颈并不完全一致，有IO密集型的（如大量访问igraph），有CPU密集型的，一个场景可能在cpu不超过30%的情况下，就已经出现了大量的异常QPS，Load很高，需要增加机器。
-
如何给不同的场景自适应的判断水位？
有的场景30% CPU运行的很好，但是有的场景10%可能就出问题了。
-
如何防止某些实现有问题的场景，不停的出现异常，不断触发扩容，从而掏空整个集群，而实现效率较高的场景反而得不到机器，引发不公平。
-
如何用一套算法同时解决日常运行和大促运行的需求
当总的机器数目有限的情况下，如何分配不同场景之间的机器，最大化收益（有效pv）。如何用程序实现从某些场景拿机器去补充重要场景的运行。
-
对于运行JVM的容器，当一个新加容器在到达100%服务能力之前需要充分预热，预热过程会有异常QPS的产生。算法一方面要尽可能少的减少扩缩容的次数，另外一个方面，要尽可能快的发现扩容的需求，实现较高的扩容recall。如何在这两者之间做tradeoff？
系统架构
TPP智能调度涉及TPP的各方各面，其架构图如下所示，包括数据输入、算法决策和决策执行三个方面，但是为了更灵敏的、更及时的发现超载的场景并进行扩容，需要自动降级、秒级扩容、单机压测qps预估功能的保证。另外还有一些功能性的开发，如业务算法配置参数分离、调度大盘监控、烽火台规则运行平台等的支持。最底层的更加离不开容器化的全量部署 ，使得加减机器，快速部署环境成为了可能。
一般的服务器qps多少？
QPS
QPS即每秒查询率，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
每秒查询率
因特网上，经常用每秒查询率来衡量域名系统服务器的机器的性能，其即为QPS。
对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。
计算关系：
QPS = 并发量 / 平均响应时间
并发量 = QPS * 平均响应时间
原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间。
公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS) 。
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器 。
案例分析：
每天300w PV 的在单台机器上，这台机器需要多少QPS？
( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)。
一般需要达到139QPS，因为是峰值。
如果一台机器的QPS是58，需要几台机器来支持？
139 / 58 = 3
转载一、TPS：Transactions Per Second（每秒传输的事物处理个数），即服务器每秒处理的事务数。TPS包括一条消息入和一条消息出，加上一次用户数据库访问。（业务TPS = CAPS × 每个呼叫平均TPS）
TPS是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
一般的，评价系统性能均以每秒钟完成的技术交易的数量来衡量。系统整体处理能力取决于处理能力最低模块的TPS值。
二、QPS：每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。
对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。
三、在DBA界，TPS和QPS是衡量数据库性能的2个重要参数。计算方法如下：
TPS(每秒事务处理量） INNODB 引擎
(com_commit+com_rollback)/uptime
QPS（每秒查询处理量）MyISAM 引擎
Questions/uptime
附：
TPS(Transaction per second) （每秒事务量，如果是InnoDB会显示，没有InnoDB就不会显示）
Read/Writes Ratio（数据库读写比率，对是否使用MySQL Replication还是使用MySQL Cluster很有参考价值。）
MyISAM Key buffer read ratio
MyISAM Key buffer write ratio
Slow queries per minute （平均一分钟多少慢查询）
Slow full join queries per minute（慢查询的比率）
Temp tables to Disk ratio （写到硬盘的临时表与所有临时表的比率，对性能有较大影响，说明有SQL使用了大量临时表）
原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间。
公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS) 。
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器 。
每天300w PV 的在单台机器上，这台机器需要多少QPS？
( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)。
一般需要达到139QPS，因为是峰值。
