問題背景
運維技術人員使用CDN加速以後發現還是有用戶反饋訪問慢的情況，而實際造成訪問慢的影響因素很多，如何去分析定位問題、優化網站速度、解決用戶問題是一個十分重要的課題。
分析思路
正所謂「工欲善其事，必先利其器」，在排查分析問題前，了解CDN的加速原理十分重要，它將有助於幫助你如何去思考和分析問題存在的可能原因。簡單來說，CDN主要是通過在現有網絡中增加一層新的緩存節點，將網站伺服器的資源發布到最接近用戶的網絡節點，使得用戶側客戶端在請求時直接訪問到就近的CDN節點並命中該資源，減少回源情況，提高網站訪問速度。因此，造成訪問慢的可能原因可以簡單歸納為以下幾個方向：
- 客戶端本地網絡因素，比如客戶端下行帶寬不足、DNS配置錯誤等
- 客戶端到CDN節點之間的網絡不佳，網絡延遲高
- CDN節點異常，響應速度慢
- 資源內容比較大，導致下載比較耗時
- CDN回源到源站時，回源網絡不佳
- 源站本身響應速度慢
通過搜集一些問題現象和信息，我們可以進一步再繼續往下分析，確定一下初步的排查方向，這也是一個非常重要的環節。（1）可以先確認下是全網都存在訪問慢的問題，還是只是個別用戶訪問慢，亦或是某一個地區、某一個運營商的用戶訪問慢。可以藉助一些基調探測平台去探測，免費平台推薦17測。付費平台可以考慮「聽雲」、「博睿」等探測平台去探測，這些平台可以設定某一地區、某一運營商網絡的探測機器去探測，精準性更高。
- 如果只是極個別用戶訪問不佳，那麼可能跟用戶側的網絡有強相關性，很可能就是用戶側的網絡問題
- 異常用戶是否有集中性，比如某市大量移動用戶訪問異常，而該市聯通和電信用戶訪問正常。這種情況就有可能跟該地區的運營商網絡有一定關聯，可以使用一些基調工具，用該地區的一些探測機器去探測一下
- 如果全網用戶都存在訪問慢的問題，那就很有可能是源站響應問題或者是一些配置方面的問題了，因為幾乎不可能同時所有的CDN節點或者所有地區的網絡都處問題了。比如是不是加速區域選擇的不對，是不是動態請求或者無法緩存的請求，源站響應慢，需要重點往這方面考慮了
（2）確認下訪問慢或者異常的請求是否被CDN緩存了
- 如果是命中CDN緩存的請求，那麼就不存在CDN回源了，因此CDN會直接把節點上的緩存數據返回給客戶端，這種情況就和源站沒什麼關係了
- 如果是沒有命中緩存，那麼需要重點看是客戶端到CDN慢了，還是源站響應慢了
衡量指標
使用CDN加速，除了通用的數據觀測指標外，不同的場景下也有更具體的指標。觀測這些指標，不僅可以幫助用戶體驗CDN加速的效果，也能觀測自身業務使用CDN的情況，幫助您更好地做出調整和決策。阿里雲CDN官方幫助文檔中心提供了CDN的衡量指標的介紹文檔。
信息搜集
我們知道一次完整的HTTP請求需要經過 DNS解析-->TCP建連-->SSL握手（HTTPS需要SSL握手）-->客戶端發送請求-->服務端響應請求 的過程，了解HTTP請求的過程將有助於我們更深層次的去分析問題，因此在客戶端側搜集一些信息很有必要，通常可以搜集以下的幾點信息
(1) 搜集客戶端網絡情況和CDN節點IP在客戶端側ping加速域名，確認是否正確解析到CDN，以及客戶端到CDN節點之間網絡是否是通的，網絡延遲如何。如果無法ping通，則還需要做一些鏈路診斷，具體可以參考這裡的鏈路診斷方法。如果是手機側，則需要藉助一些第三方的應用來協助診斷，例如Android手機可以用「網絡萬用表」，iOS可以用iNetTools。
(2) 搜集客戶端IP和LocalDNSCDN的節點調度策略是根據客戶端的LocalDNS來分配調度的，因此確認客戶端的LocalDNS是否設置正確非常重要。可以通過客戶端訪問這個地址來獲取客戶端IP以及客戶端DNS：https://cdn.dns-detect.alicdn.com/https/doc.html
(3) 找到訪問慢的URL可以打開瀏覽器開發者模式，切換到Network標籤頁，輸入URL以後可以在Network標籤頁下看到瀏覽器發出的所有的HTTP請求。點擊「Time」選項按照時間來排序，看具體是哪些請求慢了，找到這個訪問慢的URL
特別注意⚠️：通常情況下一個網站加載的資源比較多，當然這裡可能還有一些非CDN加速的一些URL，有時候可能存在一些非CDN的資源訪問慢，而CDN加速的資源都訪問快，但是就是這些非CDN加速的資源加載慢導致整個網站響應速度變慢。因此根據Time排序來確認到底是哪些URL訪問慢了很重要。
(4) 搜集HTTP請求的請求頭和響應頭單擊訪問慢的HTTP請求 Name 值，在Headers標籤下可以看到這次請求的General、Response Headers和Request Headers信息。通過請求頭和響應頭，我們可以了解這次請求是否是一個靜態請求，是否命中了緩存等信息。
如果是手機4G慢，則需要在手機側抓包來獲取信息了，這個一般用戶可能會有一些困難。可以考慮手機開熱點，PC連接熱點，這樣就可以在PC上搜集信息了。
(5) 搜集HTTP請求的Timing信息Timing標籤中可以顯示資源在整個請求生命周期過程中各部分時間花費信息。對於Timing里的信息介紹可以參考下這個介紹。
常見案例
在了解CDN的加速原理、HTTP請求過程的基礎下，結合問題現象做一個初步分析，然後根據搜集到的客戶端側的信息一起判斷，基本已經可以大致的發現或定位一些問題了。下面我們來介紹一些典型的問題案例。
案例一. 客戶端到CDN節點網絡質量不佳
客戶端 ping 加速域名網絡延遲大，甚至丟包，這種情況需要搜集客戶端的IP、客戶端的DNS以及ping截圖、mtr截圖信息。因為CDN調度節點是通過客戶端的DNS來分配調度的，根據客戶端IP、DNS以及CDN節點可以判斷調度是否異常，通過ping以及mtr截圖可以看到網絡延遲以及具體延遲在哪個網絡鏈路節點。通常這類情況可能有以下幾種情況：(1) 加速區域設置錯誤比如中國大陸的用戶被解析到了海外的節點，或者海外用戶被解析到國內。這種情況建議將加速區域設置為「全球加速」。
- 如果CDN的加速區域選擇的是「僅中國大陸」，那麼該域名的調度域就只有中國大陸的CDN節點，海外用戶訪問的時候也會調度到中國大陸的CDN節點
- 如果加速區域選擇的是「全球（不包含中國大陸）」，那麼該域名的調度域裡就只有海外的CDN節點，中國大陸用戶也會請求到海外的CDN節點
(2) 客戶端DNS設置錯誤
- 例如一個廣東移動的用戶，用了聯通的DNS，則會導致該用戶被調度到聯通CDN節點上，存在跨運營商的情況
- 例如一個廣東移動的用戶，用了哈爾濱移動的DNS，則會導致該用戶被調度到哈爾濱移動的CDN節點上，遠距離調度拉長了網絡鏈路。
這種場景需要用戶側修改使用對應所在地對應運營商的DNS。
說明：如果加速區域和DNS設置正確，在CDN正確分配調度的情況下，網絡質量還是差，那就需要搜集traceroute和mtr信息來進一步診斷了
案例二. 緩存命中率低,頻繁回源
CDN在靜態資源加速場景的應用，是將靜態資源緩存在距離客戶端最近的CDN節點上。用戶訪問該資源時，直接從緩存中獲取資源，避免通過較長的鏈路回源。如果CDN緩存命中率低，則會導致源站壓力大，靜態資源訪問效率低。因此，CDN緩存命中率的高低直接影響用戶體驗，而保證較高的緩存命中率也成為了CDN的核心課題。可以針對導致CDN緩存命中率低的具體原因，選擇對應的優化策略，來優化CDN的緩存命中率。我們可以通過CDN返回的Response Header里的X-Cache欄位來判斷是否命中緩存
X-Cache欄位：MISS表示未命中緩存，是回源處理的；HIT表示命中了CDN的緩存，直接讀取的緩存數據。X-Swift-CacheTime欄位：表示CDN節點上的允許緩存時間，即該文件可以在CDN節點上緩存多久，如果是0表示該請求無法緩存。
通常的一些現象和優化方案如下(1) 首次訪問資源慢，第二次訪問正常首次訪問會比直接訪問源站相對還慢些，因為第一次CDN節點沒有緩存，要回源取數據。此情況推薦使用【預熱】功能，將源站的內容主動預熱到CDN節點上，用戶首次訪問可直接命中緩存，提高加載速度。
(2) 資源訪問量較低，文件熱度不夠，CDN收到請求較少無法有效命中緩存CDN節點作為所有使用CDN的用戶公用的節點資源，因此CDN配置的緩存規則表示了該資源在CDN上的緩存最長時間，如果您的CDN加速域名流量較低，則可能提前從CDN節點的緩存中清除。即緩存按照熱度屬性採取末尾淘汰制。熱度是指文件在節點上被訪問的頻率，文件熱度不夠，被提前剔除。
(3) 緩存配置不合理，緩存時間過短，CDN節點頻繁回源。
- 當CDN未配置緩存規則時，如果靜態文件未返迴響應頭Etag和Last-modified，則該靜態文件不能緩存在CDN節點上。優化方案是需要源站配置這兩個響應頭，或者考慮在CDN側配置緩存規則。
- 當CDN未配置緩存規則時，CDN用的是默認緩存策略，緩存時間很短，最長不超過3600秒，因此容易造成頻繁過期回源的情況，建議可以根據業務情況到CDN側設置合理的緩存時間。
- 當源站配置了一些強制不緩存的Cache-Control的響應頭時，即使您配置了緩存規則，CDN也不會對該資源進行緩存，因為這些響應頭在CDN緩存規則中的優先級較高。以下有"s-maxage=0"、"max-age=0"、"no-cache"、"no-store"、"private"、"Pragma: no-cache"中的任一種，都會導致CDN無法緩存，需要源站側去修改這些響應頭，比如修改成Public等可以被緩存的響應頭。參考文檔：設置Nginx緩存策略、Apache緩存策略的設置
（4）URL帶可變參數訪問資源的URL帶參，並且參數不斷變化，當用不同的URL去訪問CDN的時候，CDN會認為這是一個新請求（即便這兩個不同的URL其實是訪問到了同一個文件，並且該文件已經緩存在節點上），還是會回源去拉取所請求的內容，建議開啟【過濾參數】功能。
（5）大文件Range回源對於一些大文件，建議開啟Range回源來優化回源
案例三.動態請求訪問慢
如果訪問慢的請求是一個動態請求，當客戶端訪問這些動態內容時，每次都需要訪問用戶的伺服器，由伺服器動態生成實時的數據並返回給客戶端。這種場景下，CDN無法緩存實時變化的動態內容，因此CDN的緩存加速不適用於加速動態內容。對於動態內容請求，CDN節點只能轉發回源站伺服器，沒有加速效果。如果用戶的網站或App應用有較多動態內容，例如需要對各種API接口進行加速，可以考慮如下方案(1) 做動靜分離,靜態資源用CDN域名來加速，動態請求用另一個直接解析到源站的域名來訪問(2) 考慮使用全站加速來加速動態請求。不過要注意的是，全站加速對於動態請求的加速是通過阿里雲的路由優化、傳輸優化等動態加速技術以最快的速度訪問您的伺服器源站獲取數據，是一個四層鏈路的優化，如果源站伺服器本身響應速度就很慢，那這種情況還是需要優化源站。
案例四.源站響應慢
訪問慢的請求是一個不緩存的請求，或者是一個動態請求，CDN都是回源處理的，如果源站的響應速度非常慢，則會導致最終響應的速度慢。這種情況可以直接本地綁定Host到源站去測試源站的響應速度。這種情況一般可能有以下情況：(1) 源站性能限制，本身處理速度比較慢,比如源站的帶寬、CPU等達到瓶頸，或者源站程序處理速度慢等，需要考慮優化源站。如果是性能不足則需要對源站擴容。(2) 源站側網絡比較差，或者源站涉及到跨境鏈路，比如中國大陸用戶請求CDN，而源站在境外。由於CDN回源到源站也是走的公網，如果涉及到跨境鏈路的話確實可能會受到一些影響，因為跨境鏈路涉及到不同的運營商、境外運營商，而且需要走國際網際網路出口，這些CDN側和源站側都不可控，CDN單方面優化的空間很小，建議部署雙源站（境外+境內）調整架構來優化。
案例五.網站首頁加載慢我們知道打開一個網站，實際的過程是瀏覽器發起一個請求以後服務端返回一個html（也就是首頁的請求），瀏覽器拿到首頁請求以後解析html以後才會繼續去請求網頁里的圖片、css、Js等資源。如果首頁是一個動態請求或者是不緩存的請求，會導致每次請求首頁的時候，CDN都是回源處理的。如果源站響應慢就會導致最終首頁加載慢，該請求在Network下Pending狀態持續時間比較久。具體是否命中緩存可以參考本文案例二的介紹。
這種首頁不緩存的請求訪問慢的場景，造成的現象就是首頁請求一直Pending，等到首頁請求到了以後後續的靜態資源很快都加載出來了。
如果是首頁慢的情況，這種情況用「站長工具」、「17測」等平台去驗證CDN的加速效果結果可能不準確。因為探測地址如果填寫是http://{網站域名} ，那麼探測平台實際探測的就是首頁的地址，並沒有去探測網站裡的一些靜態文件的資源。如果探測URL輸入的是一個具體的靜態資源的URL，那才可以驗證加速效果。
案例六.網站加載的內容比較大
如果網站加載的資源比較大，可以通過設置加速域名的性能優化功能，縮小訪問文件的體積，提升加速效率和頁面可讀性。目前智能壓縮支持的內容格式：text/html、text/xml、text/plain、text/css、application/javascript、application/x-javascript、application/rss+xml、text/javascript、image/tiff、image/svg+xml、application/json、application/xmltext
案例七.某地區某運營商用戶訪問慢
有一些問題場景，客戶端有一些共性。比如某一個時間段，某市移動用戶有大量用戶反饋訪問慢或者異常，而聯通電信用戶都正常。這類問題就很有可能跟當地運營商網絡或者該地區請求到的CDN節點有關聯，通常的排查方法就是在用戶側去搜集ping信息，先確認客戶端和CDN節點之間的網絡延遲情況，另外根據用戶請求到的CDN節點IP可以綁定到該CDN節點去測試，測試方法跟綁定到源站去測試類似，把IP位址換成CDN節點的IP即可。綁定節點測試可以先驗證下這個節點本身是否確實存在響應慢的情況。如果響應慢，再查看該請求是否命中緩存、加載的資源是否過大等，結合前面的案例進一步分析。如果無法定位也可以通過提交工單等方式聯繫阿里雲。