問題背景
運維技術人員使用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和LocalDNS
CDN的節點排程政策是根據用戶端的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即可。綁定節點測試可以先驗證下這個節點本身是否确實存在響應慢的情況。如果響應慢，再檢視該請求是否命中緩存、加載的資源是否過大等，結合前面的案例進一步分析。如果無法定位也可以通過送出工單等方式聯系阿裡雲。