問題描述
在使用阿里雲CDN加速後，網站訪問速度比較慢。由於造成訪問慢的影響因素很多，如何去分析定位問題、最佳化網站速度、解決問題是一個十分重要的課題，本文對此進行詳細介紹。
解決方案
阿里雲提醒您：
如果您對執行個體或資料有修改、變更等風險操作，務必注意執行個體的容災、容錯能力，確保資料安全。
如果您對執行個體（包括但不限於ECS、RDS）等進行配置與資料修改，建議提前建立快照或開啟RDS記錄備份等功能。
如果您在阿里雲平台授權或者提交過登入帳號、密碼等安全資訊，建議您及時修改。
當您使用阿里雲CDN加速後，出現網站訪問速度比較慢的問題時，請參考以下內容解決問題。
分析思路
在排查分析問題前，需要瞭解CDN的加速原理，請參見什麼是阿里雲CDN，它將有助於協助您如何去思考和分析問題存在的可能原因。簡單來說，CDN主要是通過在現有網路中增加一層新的緩衝節點，將網站伺服器的資源發布到最接近使用者的網路節點，使得使用者側用戶端在請求時直接存取到就近的CDN節點並命中該資源，減少回源情況，提高網站訪問速度。因此，造成訪問慢的可能原因可以簡單歸納為以下幾個類型：
用戶端本網因素，例如用戶端下行頻寬不足、DNS配置錯誤等。
用戶端到CDN節點之間的網路不佳，網路延遲較高。
CDN節點異常，響應速度慢。
資源內容比較大，導致下載比較耗時。
CDN回源到來源站點時，回源網路不佳。
來源站點本身響應速度慢。
通過搜集一些問題現象和資訊，我們可以進一步分析，初步確定排查方向，這也是一個非常重要的環節。
可以先確認是否是全網都存在訪問慢的問題，還是個別使用者訪問慢，亦或是某一個地區、某一個電訊廠商的使用者訪問慢。阿里雲為您提供了應用即時監控服務ARMS、CloudMonitor等產品，您可以通過這些產品設定某一地區、某一電訊廠商網路的探測機器去探測，精準性更高：
如果只是極個別使用者訪問不佳，那麼可能跟使用者側的網路有強相關性，很可能就是使用者側的網路問題。
判斷異常使用者是否有集中性，比如：某市大量移動使用者訪問異常，而該市聯通和電信使用者訪問正常。這種情況就有可能跟該地區的電訊廠商網路有一定關聯，可以使用一些基調工具，用該地區的探測機器進行探測。
如果全網使用者都存在訪問慢的問題，那就可能是來源站點響應問題或者是配置方面的問題，因為幾乎不可能同時所有的CDN節點或者所有地區的網路都出現問題。例如：排查是否是加速地區選取項目的錯誤，是否是動態請求或者無法緩衝的請求，來源站點響應慢，需要重點往這方面考慮。
確認訪問慢或者異常的請求是否被CDN緩衝：
如果是命中CDN緩衝的請求，那麼就不存在CDN回源，因此CDN會直接把節點上的快取資料返回給用戶端，這種情況就和來源站點沒有關係。
如果是沒有命中緩衝，那麼需要重點查看是用戶端到CDN的鏈路慢，還是來源站點響應慢。
衡量指標
使用CDN加速，除了通用的資料觀測指標外，不同的情境下也有更具體的指標。觀測這些指標，不僅可以協助您體驗CDN加速的效果，也能觀測自身業務使用CDN的情況，協助您更好地做出調整和決策。阿里雲CDN官方協助文檔中心提供了CDN的衡量指標的介紹文檔，請參見CDN的衡量指標。
資訊搜集
我們知道一次完整的HTTP請求需要經過DNS解析>TCP建連>SSL握手（HTTPS需要SSL握手）>用戶端發送請求>服務端響應請求的過程，瞭解HTTP請求的過程將有助於我們更深層次的去分析問題，因此在用戶端側搜集一些資訊很有必要，通常可以搜集以下的幾點資訊。
搜集用戶端網路情況和CDN節點IP
使用ping命令串連加速網域名稱，確認是否正確解析到CDN，以及用戶端到CDN節點之間網路是否是通暢，網路延遲如何。如果無法ping通，則需要進行一些鏈路診斷，具體資訊請參見鏈路診斷方法。
搜集用戶端IP和LocalDNS
CDN的節點調度策略是根據用戶端的LocalDNS來分配調度，因此確認用戶端的LocalDNS是否設定正確非常重要。可訪問阿里崑崙使用者診斷工具，擷取用戶端IP以及用戶端DNS。
尋找訪問慢的URL
可以開啟瀏覽器開發人員模式，切換到Network標籤頁，輸入URL之後，在Network標籤頁中查看瀏覽器發出的所有HTTP請求。單擊Time選項，按照時間來排序，查看具體是哪些資源請求慢，在Domain列找到CDN加速網域名稱下訪問慢的URL。
通常情況下，一個網站載入的資源比較多，可能存在一些非CDN加速的URL，這時一些非CDN的資源訪問慢，而CDN加速的資源都訪問快，但是就是這些非CDN加速的資源載入慢導致整個網站響應速度變慢。因此根據Time排序，確認到底是哪些URL訪問慢。
搜集HTTP請求的要求標頭和回應標頭
單擊Network標籤頁訪問慢的HTTP請求Name值，在Headers標籤下可以看到這次請求的General、Response Headers和Request Headers資訊。通過要求標頭和回應標頭，我們可以瞭解這次請求是否是一個靜態請求，且是否命中緩衝等資訊。
如果是手機4G慢，則需要在手機側抓包擷取資訊，該操作對一般使用者可能會有一些困難。可以考慮開啟手機熱點，PC端串連熱點，在PC端搜集資訊。
搜集HTTP請求的Timing資訊
在Timing標籤中可以顯示資源在整個請求生命週期過程中各部分時間花費資訊。
常見案例
在瞭解CDN的加速原理和HTTP請求過程的基礎下，結合問題現象進行初步分析，然後根據搜集到用戶端側的資訊一起判斷，基本已經可以發現或定位一些問題。下面介紹一些典型的問題案例。
案例一：用戶端到CDN節點網路品質不佳
用戶端使用ping命令測試加速網域名稱，發現網路延遲較大，甚至出現丟包。這種情況下需要搜集用戶端的IP、用戶端的DNS以及ping的資訊截圖、MTR的資訊截圖。因為CDN調度節點是通過用戶端的DNS來分配調度，根據用戶端IP、DNS以及CDN節點可以判斷調度是否異常，通過ping以及mtr的資訊截圖可以看到網路延遲以及具體延遲在哪個網路鏈路節點。本節通過兩個案例進行介紹。
加速地區設定錯誤
中國內地的使用者被解析到海外的節點，或者海外使用者被解析到中國內地，具體情境如下所示：
這種情況建議將加速地區設定為“全球”。
CDN的加速地區選取項目的是“僅中國內地”，那麼該網域名稱的調度域就只有中國內地的CDN節點，海外使用者訪問該網域名稱時，都會調度到中國內地的CDN節點。
加速地區選取項目的是“全球（不包含中國內地）”，那麼該網域名稱的調度域裡就只有除中國內地之外的CDN節點，中國內地使用者都會調度到海外的CDN節點。
用戶端DNS設定錯誤
用戶端DNS設定錯誤需要使用者側修改使用對應所在地對應電訊廠商的DNS：
一個廣東移動的使用者，使用了聯通的DNS伺服器，則會導致該使用者請求到聯通的CDN節點，遠距離調度會延長網路鏈路。
一個廣東移動的使用者，使用了哈爾濱移動的DNS伺服器，則會導致該使用者請求到哈爾濱移動的CDN節點，遠距離調度延長網路鏈路。
如果加速地區和DNS設定正確，在CDN正確分配調度的情況下，網路品質還是差，則需要搜集traceroute和mtr資訊進一步診斷。
案例二：快取命中率低或頻繁回源
CDN在靜態資源加速情境的應用，將靜態資源緩衝在距離用戶端最近的CDN節點。使用者訪問該資源時，直接從緩衝中擷取資源，避免通過較長的鏈路回源。如果CDN快取命中率低，則會導致來源站點壓力大，靜態資源訪問效率低。因此，CDN快取命中率的高低直接影響使用者體驗，而保證較高的快取命中率也成為CDN的核心課題。可以針對導致CDN快取命中率低的具體原因，選擇對應的最佳化策略，最佳化CDN的快取命中率，請參見提高CDN快取命中率。我們可以通過CDN返回Response Header中的X-Cache欄位來判斷是否命中緩衝。
X-Cache：欄位為MISS，則表示未命中緩衝，需要進行回源處理；X-Cache欄位為HIT，則表示命中了CDN緩衝，會直接讀取的快取資料。
X-Swift-CacheTime：欄位值表示CDN節點上的允許緩衝時間，即該檔案可以在CDN節點上緩衝多久。如果是0，則表示該請求無法緩衝。
快取命中率低或頻繁回源的現象和最佳化方案如下所示：
首次訪問會比直接存取來源站點還慢，因為第一次CDN節點沒有緩衝，需要先回源取資料。這種情況推薦使用預熱URL功能，請參見重新整理和預熱資源，將來源站點的內容主動預熱到CDN節點，使用者首次訪問可直接命中緩衝，提高載入速度。
資源訪問量較低，檔案熱度不夠，CDN收到請求較少，且無法有效命中緩衝。CDN節點作為所有使用CDN的使用者共用的節點資源，因此CDN配置的緩衝規則表示該資源在CDN上的最長緩衝時間。如果您的CDN加速網域名稱流量較低，則可能提前從CDN節點的緩衝中清除，即緩衝按照熱度屬性採取末尾淘汰制。熱度是指檔案在節點上被訪問的頻率，當檔案熱度不夠，則會被提前剔除。
緩衝配置不合理，緩衝時間過短，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緩衝策略。
URL攜帶了可變參數 訪問資源的URL攜帶了參數，並且參數不斷變化。當使用不同的URL去訪問CDN的時候，CDN會認為這是一個新請求（即便這兩個不同的URL其實是訪問同一個檔案，並且該檔案已經緩衝在節點上），還是會回源拉取所請求的內容。這種情況下，建議開啟過濾參數功能，請參見忽略參數。
大檔案Range回源 對於一些大檔案需要緩衝的情況，建議開啟Range回源功能最佳化回源，請參見配置Range回源。
案例三：動態請求訪問慢
如果訪問慢的請求是一個動態請求，當用戶端訪問這些動態內容時，每次都需要訪問使用者的伺服器，由伺服器動態產生即時的資料並返回給用戶端。這種情境下，CDN無法緩衝即時變化的動態內容，因此CDN的緩衝加速不適用於加速動態內容。對於動態內容請求，CDN節點只能轉寄回來源站點伺服器，沒有加速效果。如果使用者的網站或App應用有較多動態內容，例如：需要對各種API介面進行加速，可以考慮以下方案。
來源站點做動靜分離，靜態資源使用CDN網域名稱加速，動態請求使用另一個直接解析到來源站點的網域名稱來訪問。
考慮使用全站加速來加速動態請求，請參見全站加速。不過要注意的是，全站加速對於動態請求的加速是通過阿里雲的路由最佳化、傳輸最佳化等動態加速技術，以最快的速度訪問您的伺服器來源站點擷取資料，是一個四層鏈路的最佳化，如果來源站點伺服器本身響應速度就很慢，那這種情況下還是需要最佳化來源站點。
案例四：來源站點響應慢
當請求訪問慢時，若該請求是不緩衝資源的請求，或者是一個動態請求，都是需要回源處理。但是由於來源站點的響應速度非常慢，導致最終響應的速度慢。該情況下可以直接在本地繫結來源站網域名稱訪問來源站點，或者在來源站點伺服器中測試來源站點網域名稱的響應速度。導致該情況出現的原因如下所示：
來源站點效能限制，本身處理速度比較慢，例如來源站點的頻寬、CPU等達到瓶頸，或者來源站點程式處理速度慢等，需要考慮最佳化來源站點。如果效能不足，則需要對來源站點擴容。
來源站點的網路比較差，或者來源站點涉及跨境鏈路，比如使用者請求中國內地的CDN節點，而來源站點在中國內地外。由於CDN回源到來源站點的鏈路也是公網地址，如果涉及到跨境鏈路的話確實會受到一些影響，因為跨境鏈路涉及到不同的電訊廠商、境外電訊廠商，而且需要走國際互連網出口，這些情況CDN側和來源站點側都不可控，CDN單方面最佳化的空間很小，建議部署雙來源站點（境外和境內）調整架構進行最佳化。
案例五：網站首頁載入慢
當用戶端訪問http://www.example.com/網站時，瀏覽器會請求該首頁，請求成功以後，服務端返回HTML代碼給瀏覽器，然後瀏覽器再根據返回的HTML代碼來請求代碼中需要引入的一些資源，例如圖片、JS、CSS等這些URL。如果首頁是一個動態資源或者是不需要緩衝的資源，則會導致每次請求首頁時，CDN都會經過回源處理。如果來源站點響應慢就會最終導致首頁載入慢，該請求在Network中的Pending狀態期間比較久。具體是否命中緩衝可以參見案例二：快取命中率低或頻繁回源的介紹。
這種首頁不緩衝且請求訪問慢的情境，造成的現象就是首頁請求一直為Pending，等首頁請求到資料後，靜態資源很快都會載入出來。
案例六：網站載入的資源比較大
如果網站載入的資源比較大，可以通過設定加速網域名稱的效能最佳化功能，請參見效能最佳化，縮小訪問檔案的體積，提升加速效率和頁面可讀性。目前智能壓縮支援的內容格式：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即可。綁定節點測試前，可以先驗證該節點本身是否存在響應慢的情況。如果響應慢，再查看該請求是否命中緩衝、載入的資源是否過大，結合前面的案例進一步分析。如果無法定位問題，可以通過提交工單等方式聯絡阿里雲。
適用於
CDN
全站加速