【AWS徵文】如何利用 AWS CloudFront 給您的站點全站安全加速

如何給你的站點加速，如何作到靜態資源動態資源同時加速，本文將詳細爲你介紹 AWS CloudFront，而且如何利用 CloudFront 爲您的站點加速，以及使用 CloudFront 的注意事項。

CloudFront 是什麼

如今愈來愈多的產品開始走出國內，邁向全球。如今移動互聯網愈來愈火熱，你們都是經過官方網站去瀏覽產品的特性，那麼咱們就須要爲產品創建一個全球化的網站，把產品介紹推送給全球用戶。那麼如何纔可讓全球的用戶以最快的速度打開站點呢？咱們知道，全球的網絡傳輸依託於光纖，而光的速度是不變的，距離服務器越遠的用戶延遲註定會越高，通過的路由也會越多多，速度也會越慢。

如何克服困難，給用戶一個好的體驗，AWS 雲服務中哪一個產品能夠幫助咱們實現？咱們須要瞭解一下 AWS CloudFront，CloudFront 是什麼，擁有什麼功能，相比於其餘的 CDN 服務，又有什麼優點呢，咱們後面一一解答。

CloudFront 是 AWS 推出的 CDN 服務，能夠對網站資源進行緩存加速。咱們一般理解的 CDN 就是對靜態資源加速，靜態資源會分發到 AWS 全球的邊緣節點，用戶就近訪問所須要的資源。那麼針對動態資源怎麼辦？這個咱們也不用擔憂，AWS 擁有很是龐大的基礎設施，利用這些基礎設施，CloudFront 一樣能夠對動態資源加速，好比咱們的 PHP、ASP 等動態資源。這裏的加速並非把這些資源分發的全球，而是讓用戶的流量最快進入 AWS 的骨幹網。骨幹網依託於 AWS 的基礎設施，骨幹網由 AWS 本身維護，擁有高速帶寬，智能路由，AWS 會制定最優的路由策略，讓用戶的請求最快穩定的到達源站。

那麼廢話很少說，咱們下面看看如何設定，讓咱們的站點推向全球吧。

準備站點

我此次以一個 wordpress 站點作演示，咱們不須要破壞站點的任何結構，就能夠實現全站加速，靜態資源緩存到全球邊緣節點，請求動態資源經過 AWS 骨幹網動態路由到源站。

CloudFront 雖說能夠加速第三方站點，可是爲了最好的效果，很是推薦把站點放在 AWS 的服務中，此次咱們把站點放置在 EC2 上面進行測試。

我 EC2 的系統是 Amazon Linux 2，環境是用 LNMP 一鍵安裝包建立的，關於 LNMP 的使用方式我這裏再也不介紹，一臺 EC2 能夠部署多個虛擬主機網站，默認咱們的 EC2 只提供 HTTP 的服務，若是須要 HTTPS 的話，那咱們把證書掛載 ALB 或者 CloudFront。

咱們從最開始指導你們如何一步步操做，最終配置完成 CloudFront 實現全站加速。

查看默認站點

默認域名是直接解析到 EC2 的，使用的是 HTTP 請求訪問，咱們查看一下效果。

配置 ALB 啓用 HTTPS

雖說 CloudFront 能夠直接爲網站加速，可是那須要咱們準備兩個域名，一個加速域名，一個源站域名，弄起來比較複雜，咱們藉助 ALB 中間這個工具，只負責一個域名就能夠了，管理起來很是簡單，關於 ALB 的配置，我這裏也再也不介紹，你們看我配置好的效果吧。

當咱們使用 HTTPS 訪問的時候，發現不少鏈接都被瀏覽器 blocked 掉了，那麼這是爲何呢？

咱們首先就是要解決這個 HTTPS 的問題，否則使用 CloudFront 會有一樣的問題，咱們首先了解一下目前的架構狀況。

雖然用戶使用的 HTTPS 發起請求，可是在通過 ALB 以後，轉換成 HTTP 請求源站的 wordpress，wordpress 其實並不知道用戶使用的 HTTPS 請求的，發現過來的請求是 HTTP，因而 wordpress 構建的 document 裏面嵌入的是 HTTP 的資源連接，返回給瀏覽器以後，瀏覽器由於一些安全的設定，會 blocked 這些 HTTP 的資源請求，這也就致使了咱們的站點不能正常展現，順便說一下，我使用的是 Chrome 瀏覽器，其餘瀏覽器是否會 blocked 你們能夠去試一下。

那麼如何解決這個問題呢？打個不恰當的好比，咱們要「欺騙」 wordpress，讓它認爲咱們是用 HTTPS 請求的，其實也就是給 wordpress 作個設置，無論用戶使用什麼協議請求，都給客戶端返回 HTTPS，那麼咱們須要給 wordpress 的配置文件wp-config.php增長下面一段內容。

if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
    $_SERVER['HTTPS']='on';

而後咱們再次請求，看到 HTTPS 已經能夠正常訪問。

配置 CloudFront

建立 Distribution

打開 CloudFront 控制檯，建立一個 WEB Distribution，由於不少小夥伴並不清楚站點的結構，不知道哪些目錄是靜態資源，哪些目錄是動態資源，若是默認直接都緩存的話，那會產生不少問題，好比沒法登錄，沒法提交信息等。因此咱們換個思路去操做，那就是咱們先全站動態加速，不進行任何緩存，而後再去檢查哪些目錄是靜態文件，在設置規則，對這些目錄的文件進行緩存，初次建立，那你們就按照我下面的參數設置吧。

注意：表格裏面沒有寫的，選擇默認便可。

Parameter	Value
Origin Domain Name	AuroraMigrationTask
Origin Protocol Policy	HTTP Only
Allowed HTTP Methods	GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
Cache Based on Selected Request Headers	All
Forward Cookies	All
Query String Forwarding and Caching	Forward all, cache based on all
Alternate Domain Names	wp.wzlinux.com
SSL Certificate	Custom SSL Certificate，域名證書在 us-east-1 區域申請

查看效果

而後咱們建立分發，在修改域名解析以前，咱們測試一下站點如今全球的延時狀況，目前網站所在區域爲愛爾蘭。

能夠看到除了歐洲區域，其餘地域延遲都比較高，如今咱們修改域名解析指向 CloudFront Domain Name，而後再測試一下延遲狀況。

使用 CDN 以後，咱們能夠看到海外的延遲明顯降了下來，由於大陸防火牆的緣由，降低沒有那麼明顯，不過也比以前好多了。

咱們繼續瀏覽器訪問一下，又發現了不少連接沒有返回 https，因此被 blocked 了，這是爲何，咱們繼續分析一下如今的架構圖。

前面用戶訪問 ALB 使用的 HTTPS，用戶的請求協議其實透過請求頭經過 ALB 傳遞到了後端服務器，如今訪問 ALB 變成了 HTTP，雖然用戶訪問 CDN 使用的 HTTPS，CloudFront 沒有把請求頭沒有傳到後端，因此後端一直覺得是用 HTTP 訪問的，致使返回的連接被瀏覽器 blocked。那這種狀況該怎麼辦呢？既然請求協議沒有傳遞到後端，那咱們能夠在 CloudFront 上面添加請求頭X-Forwarded-Proto。

打開咱們建立好的 distribute，選擇 Origins and Origin Groups，編輯添加 Origin Custom Headers。

等待生效，本覺得這樣就能夠了，可是仍是不行，後來瞭解到 ALB 會更換請求頭X-Forwarded-Proto，由於 ALB 看到 CloudFront 使用的 HTTP 請求的，因此即使咱們在 CloudFront 上面添加請求頭，也是會被 ALB 重置，那麼咱們只有從 wordpress 上面去下手解決問題了。

應該還記得咱們前面對 wordpress 添加的一個配置，裏面有一個 if 判斷條件，咱們能夠去掉這個條件，讓 wordpress 無論用戶使用什麼請求，都返回給用戶 HTTPS 的連接。那咱們就這樣作，把以前的配置修改以下：

$_SERVER['HTTPS']='on';

由於咱們是全站動態加速，因此看到緩存結果沒有命中，這是正常的，那下面咱們來針對站點進行緩存優化，畢竟不進行緩存，那 CDN 和鹹魚又有什麼區別呢？

優化緩存

咱們打開開發者模式，多訪問幾個頁面，查看一下靜態資源都在什麼路徑下面，好比我找到的幾個靜態資源URL 地址以下：

https://wp.wzlinux.com/wp-content/uploads/2020/07/mp53182456_1452216795463_2.jpeg
https://wp.wzlinux.com/wp-includes/css/dist/block-library/style.min.css?ver=5.4.2
https://wp.wzlinux.com/wp-includes/js/wp-embed.min.js?ver=5.4.2
https://wp.wzlinux.com/wp-content/themes/twentytwenty/style.css?ver=1.2
https://wp.wzlinux.com/wp-content/themes/twentytwenty/assets/js/index.js?ver=1.2

大家找到的 URL 可能比我多，不一樣的主題 URL 會有些不一樣，咱們就拿着幾個爲例子進行設置一下，能夠大膽一點，咱們對整個目錄進行緩存，咱們整理的路徑有以下幾個。

wp-content/uploads/*
wp-includes/css/*
wp-includes/js/*
wp-content/themes/twentytwenty/*

若是有什麼問題，咱們能夠再針對具體狀況調整，那下面咱們就開始優化緩存吧。

打開 Distribution，選擇建立 Behaviors，把上面的路徑填寫在 Path Pattern 裏面，由於咱們後端服務是虛擬主機，須要咱們把 Host 這個 Request Header 傳遞過去，加入白名單中，其餘選擇默認便可：

按照這樣的模式，咱們把其餘幾個路徑也填寫好。

而後咱們再去請求站點，查看咱們進行緩存的一些文件是否緩存命中。

目前看來一切正常了，你們能夠慢慢完善須要緩存的內容。還等什麼，給你的站點去作全站加速吧！

注意：由於咱們開啓了 HTTPS 訪問，因此遇到了一些問題，本文一一解釋了問題的緣由以及如何解決辦法，若是你不須要 HTTPS，那整個過程會更加簡單。

歡迎你們掃碼關注，獲取更多信息