背景
阿裡雲CDN結合WAF使用，WAF作為CDN的源站，是較為常見的使用方式，可以充分發揮CDN的分發加速以及WAF的安全防護能力，一般架構為CDN-->WAF-->SLB-->ECS
問題概述
某阿裡雲客戶回報2020年5月13日XX:XX分左右，部分CDN域名流量異常增長約400%；
客戶内部排查一天，基本排除内部操作影響，請求阿裡雲協助檢視問題原因。
業務架構：CDN-->WAF-->SLB-->ECS
排查過程
1、首先檢視CDN域名監控，确認使用者回報時間點，CDN域名帶寬出現突發式增長；
2、檢視CDN域名QPS名額，趨勢平滑無明顯增長，判斷不是由于請求量增多導緻的帶寬增長，進而判斷是由于平均請求大小變大，導緻帶寬增長；
3、通過檢視CDN回源帶寬，發現源站響應的帶寬明顯增長，進一步确認上面的結論：請求量沒有變化，源站響應内容變大；
4、基于上面的結論，做出判斷：CDN的帶寬突增，是由于源站(WAF)帶寬突增導緻的，進一步檢視了WAF、SLB的流量監控，也都在對應時間突增，是以該問題變成了——為什麼SLB在請求數量不變的情況下，帶寬突增？
SLB帶寬顯著增長：
5、首先懷疑的是，源站有調整，響應的檔案大小發生了變化，在和客戶确認問題期間無任何釋出後，暫時排除；
6、由于SLB帶寬的變大是因為後端應用響應大小變大導緻，是以着手和客戶分析應用日志；
通過客戶應用日志發現，同一個url，帶寬突增後，響應大小明顯變大，13k變為68k，響應内容無變化，進一步發現由響應内容由gzip壓縮變成非壓縮響應；
7、至此問題原因變得清晰：源站的http響應由gzip變成非壓縮響應，是以源站流出流量增長，引發SLB、WAF、CDN同步增長；
8、分析源站響應由gzip壓縮變為不壓縮的原因：
<1>用戶端更改邏輯，不再攜帶請求頭Accept_Encoding: gzip（由于客戶業務的用戶端都是浏覽器，排除該項）
<2>CDN丢了請求頭Accept_Encoding: gzip
<3>WAF丢了請求頭Accept_Encoding: gzip
<4>SLB丢了請求頭Accept_Encoding: gzip
<5>源站關閉Gzip壓縮（和客戶了解後端應用未做釋出，排除該項）
HTTP知識點：用戶端通過Accept_Encoding請求頭，聲明可以接受的壓縮方式，服務端收到請求後，如果支援的話，響應對應形式的壓縮内容，例如gzip壓縮；通過這種方式減小傳輸大小，節約流量同時提升傳輸速度；
9、下面要做的就是驗證原因<2><3><4>，究竟是誰丢了請求頭Accept_Encoding
通過攜帶'Accept-Encoding: gzip, deflate'直接指定WAF和SLB請求，發現:
• 直接請求CDN響應大小是68k
• 直接請求WAF，響應大小也是68k
• 直接請求SLB，響應大小是13k
CDN(68k)——>waf(68k)——>slb(13k)——>k8s(13k)
截止到這裡可以判斷問題出在了WAF ，即WAF丢了Accept_Encoding請求頭;
工具知識點：
curl是一個指令行工具，可以發起http請求，通過如下方式指定IP請求，相當于PC的綁host操作，其中-H 指定請求頭
❯ curl -voa "https://www.domain.com/xxx" -H 'Accept-Encoding: gzip, deflate' --resolve www.domain.com:443:1.1.1.1
10、問題定位到是WAF後，通過檢查WAF配置，發現是由于客戶自行開啟了資料風控功能導緻WAF回源過濾掉了Accept-Encoding頭，客戶評估關閉該功能後帶寬下降到原有水位，問題恢複；
關于WAF資料風控：
https://help.aliyun.com/document_detail/147834.html總結
通過以上排查分析，CDN流量突增的原因明朗：
CDN-->WAF-->SLB-->ECS
由于客戶開啟了WAF資料風控功能，導緻CDN經過WAF回源的時候，後者丢了Accept-Encoding請求頭，是以源站應用不再響應壓縮的内容，響應變大，進而導緻域名整體流量突增，帶寬上漲。