阿里雲雲盾抗下全球最大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
技術如何秒懂你？阿里百萬級QPS資源調度系統揭秘
阿里妹導讀：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使用了大量臨時表）
系統吞吐量、TPS（QPS）、用戶並發量、性能測試概念和公式
PS：下面是性能測試的主要概念和計算公式，記錄下：
一．系統吞度量要素：
一個系統的吞度量（承壓能力）與request對CPU的消耗、外部接口、IO等等緊密關聯。單個reqeust 對CPU消耗越高，外部系統接口、IO影響速度越慢，系統吞吐能力越低，反之越高。
系統吞吐量幾個重要參數：QPS（TPS）、並發數、響應時間
QPS（TPS）：每秒鍾request/事務 數量
並發數： 系統同時處理的request/事務數
響應時間： 一般取平均響應時間
（很多人經常會把並發數和TPS理解混淆）
理解了上面三個要素的意義之后，就能推算出它們之間的關系：
QPS（TPS）= 並發數/平均響應時間 或者 並發數 = QPS*平均響應時間
一個典型的上班簽到系統，早上8點上班，7點半到8點的30分鍾的時間里用戶會登錄簽到系統進行簽到。公司員工為1000人，平均每個員上登錄簽到系統的時長為5分鍾。可以用下面的方法計算。
QPS = 1000/(30*60) 事務/秒
平均響應時間為 = 5*60 秒
並發數= QPS*平均響應時間 = 1000/(30*60) *(5*60)=166.7
一個系統吞吐量通常由QPS（TPS）、並發數兩個因素決定，每套系統這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、內存等等其它消耗導致系統性能下降。
決定系統響應時間要素
我們做項目要排計划，可以多人同時並發做多項任務，也可以一個人或者多個人串行工作，始終會有一條關鍵路徑，這條路徑就是項目的工期。
系統一次調用的響應時間跟項目計划一樣，也有一條關鍵路徑，這個關鍵路徑是就是系統影響時間；
關鍵路徑是有CPU運算、IO、外部系統響應等等組成。
二．系統吞吐量評估：
我們在做系統設計的時候就需要考慮CPU運算、IO、外部系統響應因素造成的影響以及對系統性能的初步預估。
而通常境況下，我們面對需求，我們評估出來的出來QPS、並發數之外，還有另外一個維度：日PV。
通過觀察系統的訪問日志發現，在用戶量很大的情況下，各個時間周期內的同一時間段的訪問流量幾乎一樣。比如工作日的每天早上。只要能拿到日流量圖和QPS我們就可以推算日流量。
通常的技術方法：
1. 找出系統的最高TPS和日PV，這兩個要素有相對比較穩定的關系（除了放假、季節性因素影響之外）
2. 通過壓力測試或者經驗預估，得出最高TPS，然后跟進1的關系，計算出系統最高的日吞吐量。B2B中文和淘寶面對的客戶群不一樣，這兩個客戶群的網絡行為不應用，他們之間的TPS和PV關系比例也不一樣。
A)淘寶
淘寶流量圖：
淘寶的TPS和PV之間的關系通常為 最高TPS：PV大約為 1 : 11*3600 （相當於按最高TPS訪問11個小時，這個是商品詳情的場景，不同的應用場景會有一些不同）
B) B2B中文站
B2B的TPS和PV之間的關系不同的系統不同的應用場景比例變化比較大，粗略估計在1 : 8個小時左右的關系（09年對offerdetail的流量分析數據）。旺鋪和offerdetail這兩個比例相差很大，可能是因為爬蟲暫的比例較高的原因導致。
在淘寶環境下，假設我們壓力測試出的TPS為100，那么這個系統的日吞吐量=100*11*3600=396萬
這個是在簡單（單一url）的情況下，有些頁面，一個頁面有多個request，系統的實際吞吐量還要小。
無論有無思考時間（T_think），測試所得的TPS值和並發虛擬用戶數(U_concurrent)、Loadrunner讀取的交易響應時間（T_response）之間有以下關系（穩定運行情況下）：
TPS=U_concurrent / (T_response+T_think)。
並發數、QPS、平均響應時間三者之間關系
上圖橫坐標是並發用戶數。綠線是CPU使用率；紫線是吞吐量，即QPS；藍線是時延。
開始，系統只有一個用戶，CPU工作肯定是不飽合的。一方面該服務器可能有多個cpu，但是只處理單個進程，另一方面，在處理一個進程中，有些階段可能是IO階段，這個時候會造成CPU等待，但是有沒有其他請 求進程可以被處理）。隨着並發用戶數的增加，CPU利用率上升，QPS相應也增加（公式為QPS=並發用戶數/平均響應時間。）隨着並發用戶數的增加，平均響應時間也在增加，而且平均響應時間的增加是一個指數增加曲線。而當並發數增加到很大時，每秒鍾都會有很多請求需要處理，會造成進程（線程）頻繁切換，反正真正用於處理請求的時間變少，每秒能夠處 理的請求數反而變少，同時用戶的請求等待時間也會變大，甚至超過用戶的心理底線。
來源：http://www.cnblogs.com/jackei/
軟件性能測試的基本概念和計算公式
一、軟件性能的關注點
對一個軟件做性能測試時需要關注那些性能呢？
我們想想在軟件設計、部署、使用、維護中一共有哪些角色的參與，然后再考慮這些角色各自關注的性能點是什么，作為一個軟件性能測試工程師，我們又該關注什么？
首先，開發軟件的目的是為了讓用戶使用，我們先站在用戶的角度分析一下，用戶需要關注哪些性能。
對於用戶來說，當點擊一個按鈕、鏈接或發出一條指令開始，到系統把結果已用戶感知的形式展現出來為止，這個過程所消耗的時間是用戶對這個軟件性能的直觀印象。也就是我們所說的響應時間，當相應時間較小時，用戶體驗是很好的，當然用戶體驗的響應時間包括個人主觀因素和客觀響應時間，在設計軟件時，我們就需要考慮到如何更好地結合這兩部分達到用戶最佳的體驗。如：用戶在大數據量查詢時，我們可以將先提取出來的數據展示給用戶，在用戶看的過程中繼續進行數據檢索，這時用戶並不知道我們后台在做什么。
用戶關注的是用戶操作的相應時間。
其次，我們站在管理員的角度考慮需要關注的性能點。
1、 相應時間
2、 服務器資源使用情況是否合理
3、 應用服務器和數據庫資源使用是否合理
4、 系統能否實現擴展
5、 系統最多支持多少用戶訪問、系統最大業務處理量是多少
6、 系統性能可能存在的瓶頸在哪里
7、 更換那些設備可以提高性能
8、 系統能否支持7×24小時的業務訪問
再次，站在開發（設計）人員角度去考慮。
1、 架構設計是否合理
2、 數據庫設計是否合理
3、 代碼是否存在性能方面的問題
4、 系統中是否有不合理的內存使用方式
5、 系統中是否存在不合理的線程同步方式
6、 系統中是否存在不合理的資源競爭
那么站在性能測試工程師的角度，我們要關注什么呢？
一句話，我們要關注以上所有的性能點。
二、軟件性能的幾個主要術語
1、響應時間：對請求作出響應所需要的時間
網絡傳輸時間：N1+N2+N3+N4
應用服務器處理時間：A1+A3
數據庫服務器處理時間：A2
響應時間=N1+N2+N3+N4+A1+A3+A2
2、並發用戶數的計算公式
系統用戶數：系統額定的用戶數量，如一個OA系統，可能使用該系統的用戶總數是5000個，那么這個數量，就是系統用戶數。
同時在線用戶數：在一定的時間范圍內，最大的同時在線用戶數量。
同時在線用戶數=每秒請求數RPS（吞吐量）+並發連接數+平均用戶思考時間
平均並發用戶數的計算：C=nL / T
其中C是平均的並發用戶數，n是平均每天訪問用戶數（login session），L是一天內用戶從登錄到退出的平均時間（login session的平均時間），T是考察時間長度（一天內多長時間有用戶使用系統）
並發用戶數峰值計算：C^約等於C + 3*根號C
其中C^是並發用戶峰值，C是平均並發用戶數，該公式遵循泊松分布理論。
3、吞吐量的計算公式
指單位時間內系統處理用戶的請求數
從業務角度看，吞吐量可以用：請求數/秒、頁面數/秒、人數/天或處理業務數/小時等單位來衡量
從網絡角度看，吞吐量可以用：字節/秒來衡量
對於交互式應用來說，吞吐量指標反映的是服務器承受的壓力，他能夠說明系統的負載能力
以不同方式表達的吞吐量可以說明不同層次的問題，例如，以字節數/秒方式可以表示數要受網絡基礎設施、服務器架構、應用服務器制約等方面的瓶頸；已請求數/秒的方式表示主要是受應用服務器和應用代碼的制約體現出的瓶頸。
當沒有遇到性能瓶頸的時候，吞吐量與虛擬用戶數之間存在一定的聯系，可以采用以下公式計算：F=VU * R /
其中F為吞吐量，VU表示虛擬用戶個數，R表示每個虛擬用戶發出的請求數，T表示性能測試所用的時間
4、性能計數器
是描述服務器或操作系統性能的一些數據指標，如使用內存數、進程時間，在性能測試中發揮着“監控和分析”的作用，尤其是在分析統統可擴展性、進行新能瓶頸定位時有着非常關鍵的作用。
資源利用率：指系統各種資源的使用情況，如cpu占用率為68%，內存占用率為55%，一般使用“資源實際使用/總的資源可用量”形成資源利用率。
5、思考時間的計算公式
Think Time，從業務角度來看，這個時間指用戶進行操作時每個請求之間的時間間隔，而在做新能測試時，為了模擬這樣的時間間隔，引入了思考時間這個概念，來更加真實的模擬用戶的操作。
在吞吐量這個公式中F=VU * R / T說明吞吐量F是VU數量、每個用戶發出的請求數R和時間T的函數，而其中的R又可以用時間T和用戶思考時間TS來計算：R = T / TS
下面給出一個計算思考時間的一般步驟：
A、首先計算出系統的並發用戶數
C=nL / T F=R×C
B、統計出系統平均的吞吐量
F=VU * R / T R×C = VU * R / T
C、統計出平均每個用戶發出的請求數量
R=u*C*T/VU
D、根據公式計算出思考時間
TS=T/R
原理：每天80%的訪問集中在20%的時間里，這20%時間叫做峰值時間。
公式：( 總PV數 * 80% ) / ( 每天秒數 * 20% ) = 峰值時間每秒請求數(QPS) 。
機器：峰值時間每秒QPS / 單台機器的QPS = 需要的機器 。
每天300w PV 的在單台機器上，這台機器需要多少QPS？
( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)。
一般需要達到139QPS，因為是峰值。
聊聊QPS/TPS/並發量/系統吞吐量的概念
我們在日常工作中經常會聽到QPS/TPS這些名詞，也會經常被別人問起說你的系統吞吐量有多大。這個問題從業務上來講，可以理解為應用系統每秒鍾最大能接受的用戶訪問量。或者每秒鍾最大能處理的請求數；
QPS: 每秒鍾處理完請求的次數；注意這里是處理完。具體是指發出請求到服務器處理完成功返回結果。可以理解在server中有個counter，每處理一個請求加1，1秒后counter=QPS。
TPS：每秒鍾處理完的事務次數，一般TPS是對整個系統來講的。一個應用系統1s能完成多少事務處理，一個事務在分布式處理中，可能會對應多個請求，對於衡量單個接口服務的處理能力，用QPS比較多。
並發量：系統能同時處理的請求數
RT：響應時間，處理一次請求所需要的平均處理時間
計算關系：
QPS = 並發量 / 平均響應時間
並發量 = QPS * 平均響應時間