背景
阿里雲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請求頭，因此源站應用不再響應壓縮的內容，響應變大，從而導致域名整體流量突增，帶寬上漲。