AWS企業實戰之CloudFront的配置
對於本文,開始並不打算寫出來,因為aws有非常詳細的官方文檔,但是對於我本人在使用過程中的體會來說,官網文檔並不好理解和閱讀,英文難啃,而中文翻譯往往又不是完全正確,往往給學習帶來誤解,有甄別能力的童鞋或許會提個case或者電話咨詢一下aws的工程師,而大部分人估計沒有這個甄別能力,因此,便有了寫此文的動力,拋磚引玉,把理解寫出來,希望對他們有些幫助;
註:本文省略了在dns解析服務商配置cname記錄的步驟,因為各個DNS解析服務商的配置有些差異,這點估計難不倒大家
1、 背景需求
Cdn的發明者是akamai,且到目前為止,其仍然是它的主營業務,跨國企業/外貿企業/電商企業對於CDN的首選自然是akamai,不例外,我們公司也是使用的akamai的產品,其效果也相當的不錯,售後非常專業;不過,本文今天要說的是cloudFront,除了成本的考慮,或許並沒有其他理由去選擇CloudFront,所以,本文純技術而談,
2、 Akamai和cloudfront比較
Akamai似乎並沒有太多說的,功能多而廣,全球覆蓋率廣,性能優越,更優的是有專門的售後技術負責支持,唯一的缺點可能是價格稍貴;
CloudFront使用範圍過於局限,僅僅使用於ELB和S3;其重心工作是在於緩存,因而其功能稍顯不足,具體的功能往往都是需要源站配合來實現;收費成本不高,但是隱性收費項目比較多,出於成本的考慮的話,估計需要再三衡量是否能節約成本;售後服務上,並沒有專門的技術提供支持,當然可以購買支持服務,但通常一般企業用不著;
註: 更多的情況,首推akamai; 成本考慮的話,可以考慮CloudFront,單純使用cdn,不要使用其route53,因為route53是需要額外收取請求費用的,另外對緩存清理要求較高的,也不建議使用,因為其只有1000次免費額度,超出部分,都是需要收取額外費用的;最重要的是,公司必須要有一定的技術實力,才可以駕馭它;
3、 CloudFront配置流程
Create Distribution---Origin Settings---Create behavior---Create Invalidation
中文翻譯:創建分布—源站設置—創建行為—創建無效(即清理緩存)
4、 Create Distribution
輸入賬號和密碼,登陸aws 控制臺,點擊 CloudFront;
點擊 create Distribution,
這裏選擇的轉發方式為web,討論的也是網站的CDN加速,對流媒體暫不討論;
看到如上界面,這個界面總共會設計到三個部分的設置:
第一, 源站設置,主要是指定ELB或者S3地址;
第二, 默認緩存行為設置,即默認緩存策略;
第三, 分發設置;
但是在這裏,不做具體配置,看下圖:
設置好origin Domain Name,其他保持默認,最後點擊 create Distribution;
狀態顯示為In Progress,預計等待15分鐘左右….
5、 Distribution Settings
完成以上動作,初步完成了分發的創建,繼續往下看:
這個是剛剛創建的,點擊,進去:
點 edit;-------------上圖中的Domain Name: dsnsbl39shfl3.cloudfront.net , 便是cname配置所指向的目標地址
Price class: Use All Edge Locations(Best Performance) 推薦使用默認值,也可以根據實際情況選擇區域;
AWS WAF Web ACL: WAF是web 應用防火墻,沒有使用,保持默認none;
Alternate Domain Names: 配置自定義的域名,比如www.cndirect.com,也就是配置你自己的域名;
SSL Certificate:這個簡單,選擇安全證書,如果沒有,可以先把證書導入到ACM;
這個頁面沒有太多的說明,其他都保持默認即可;
6、 Origin Settings
這個頁面,也沒有太多需要說明,紅色方框的部分註意填寫即可,下面方框如果需要支持Http/https,請選擇match viewer;
7、 Create behavior
本小節是整個CDN配置的關鍵和難點,需要認真理會後續邏輯
1 Path Pattern: 路徑模式,指定您希望此緩存行為所匹配的請求。CloudFront收到用戶請求時,會按照緩存行為在分配中的順序和路徑模式 與 請求路徑進行匹配,而決定緩存如何;
匹配原則:
A) 通常第一個匹配,就決定了此請求的緩存行為;
B) 指定的路徑模式適用於指定目錄以及該目錄下所有子目錄中所有文件的請求,比如images目錄下包括product1和product2子目錄,路徑模式:images/*.jpg,可以匹配images,images/product1和images/product2目錄下的所有jpg文件;
C) 其支持通配符*和 ?,
* matches 0 or more characters 匹配0個或者多個字符,即匹配任意多個字符;
? matches exactly 1 character 匹配單個字符,
2 Viewer Protocol Policy 關註第二項配置,Redirect Http to Https 80端口重定向到443;
3 Cache Based on Selected Request Headers
指定是否需要轉發請求的頭部回源站,並根據頭部信息進行緩存;
ALL 轉發所有的頭部回源站,但是CloudFront不會緩存任何信息,而是全部回源站;
Whitelist 僅僅轉發指定的頭部回源站,並緩存;
None CloudFront僅轉發默認頭部信息回源站,但是它不緩存對象基於頭部信息
舉例:
手機跳轉功能
增加Http頭cloudFront-Is-Mobile-Viewer(cloudfront默認已經創建),並轉發回源站,然後配置源站nginx,對頭部信息進行判斷,再實現跳轉
Cloudfront關註的重點是數據緩存,至於某些功能上的實現,必須在源站來協助實現,因此配置源站nginx如下:
location / {
index index.html index.htm;
}
if ($http_cloudFront_is_mobile_viewer = true) {
set $mobile_request true;
}
if ($mobile_request = true) {
return 302 http://test-m-t.dresslink.com$request_uri;
break;
}
if ($http_cloudFront_is_Tablet_viewer = true) {
set $Tablet_request true;
}
if ($Tablet_request = true) {
return 302 http://test-m-t.dresslink.com$request_uri;
break;
}
}
5 Object Caching
如果源站增加了cache-control頭,對對象設置了保存時長,並且不想改變cache-control所控制的時長,請選擇 Use Origin Cache Headers;否則請選擇customize.
6 Minimum TTL/Maximum TTL/Default TTL
這部分是控制緩存時長的重點,其匹配邏輯如下:
Origin Configuration | Minimum TTL = 0 Seconds | Minimum TTL > 0 Seconds |
增加 cache-control max-age | Cloudfront 緩存 取 cache-control max-age 和 Maximum TTL 兩者最小值 Browser caching 瀏覽器緩存時間為cache-control max-age | Cloudfront caching 與max age/ Minimum TTL/Maximum TTL 三者有關: 1. Minimum TTL< max-age < maximum TTL 緩存時間:control-control max age 2. max-age < minimum TTL 緩存時間:minimum TTL 3. max-age >maximum TTL 緩存時間:maximum TTL Browser caching: 緩存時間為:control-control max age |
不增加cache-control max age | CloudFront caching: 緩存時間:Default TTL Browser caching: 依賴於瀏覽器緩存策略 | Cloudfront caching: 緩存時間: Minimum TTL與Default TTL最大值; Browser caching: 依賴於瀏覽器緩存策略 |
增加cache-control max-age和cache-control s-maxage | CloudFront caching: 緩存時間: Cache-control s-maxage和Maximum TTL 之間最小值 Browser caching 緩存時間:cache-control max-age | Cloudfront caching Minimum TTL/Maximum TTL/s-maxage取決於這三者 1. MinimumTTL< s-maxage < maximum TTL 緩存時間:s-maxage 2. s-maxage < minimum TTL 緩存時間: minimum TTL 3. s-maxage > maximum TTL 緩存時間: maximum TTL Browser caching 緩存時間: Cache-Control max-age |
增加expires | Cloudfront caching 緩存時間 Expires和maximum TTL 取最早者 Browser caching 緩存時間:Expires | CloudFront caching 取決於minimum TTL and maximum TTL and the Expires三者 1. Minimum TTL < Expires < maximum TTL 緩存時間:expires 2. Expires < minimum TTL 緩存時間:minimum TTL 3. Expires > maximum TTL 緩存時間:maximum TTL Browser caching 緩存時間:expires |
加Cache-Control: no-cache, no-store, and/or private | CloudFront and browsers respect the headers | Cloudfront caching 緩存時間:minimum TTL Browser caching respect the headers |
7 Query String Forwarding and Caching
CloudFront可以根據字符串緩存不同版本的數據,
None (Improves Caching) 如果無論字符串如何,都返回相同版本的對象,請選擇此項;
Forward all, cache based on whitelist 如果源服務器根據一個或多個查詢字符串參數返回對象的不同版本,請選擇此項;
Query String Whitelist 只支持健,並不支持值,比如可以在方框中輸入language,但是並不能支持language=de或者language=en,這點跟akamai區別明顯要不同;比如如下鏈接:
http://d111111abcdef8.cloudfront.net/main.html?language=de
http://d111111abcdef8.cloudfront.net/main.html?language=en
這代表兩個不同的鏈接,會進行緩存;但是在Query String Whitelist中,輸入language即可;
Forward all, cache based on all 如果原始服務器的所有查血字符串參數返回不同版本的對象,請選擇此項;
8 Compress Objects Automatically
如果你想自動壓縮某些類型的文件,當viewer請求的頭部信息中包含Accept-Encoding: gzip的時候,請選擇yes,也就是說需要壓縮的文件請求,必須含有Accept-Encoding: gzip頭部信息;
如果您配置CloudFront來壓縮您的內容,CloudFront將壓縮在Content-Type頭文件中具有以下值的文件(即只能壓縮以下內容類型的頭文件):
application/eot
application/x-otf
application/font
application/x-perl
application/font-sfnt
application/x-ttf
application/javascript
font/eot
application/json
font/ttf
application/opentype
font/otf
application/otf
font/opentype
application/pkcs7-mime
image/svg+xml
application/truetype
text/css
application/ttf
text/csv
application/vnd.ms-fontobject
text/html
application/xhtml+xml
text/javascript
application/xml
text/js
application/xml+rss
text/plain
application/x-font-opentype
text/richtext
application/x-font-truetype
text/tab-separated-values
application/x-font-ttf
text/xml
application/x-httpd-cgi
text/x-script
application/x-javascript
text/x-component
application/x-mpegurl
text/x-java-source
application/x-opentype
如果要壓縮CloudFront不支持壓縮的文件類型,可以使用gzip將自定義源配置為壓縮這些類型的文件。 CloudFront不支持其他壓縮算法。當您的起始點將壓縮文件返回到CloudFront時,它將包含一個Content-Encoding:gzip標頭,它向CloudFront指示該文件已經被壓縮。
8、 Create Invalidation
可以指定單個對象的路徑或者以*通配符結尾的路徑,表示一個或多個對象;
記住:可以免費提交無效請求1000次,超出次數將收取費用
9、 緩存測試
在CloudFront處理完每一次請求後,該URL的文件會被緩存一定的時間並自動過期,後續的請求CloudFront返回的響應包頭中會包含一個叫做“Age”的包頭,單位為秒並代表已經緩存的時間,正常情況下“Age”的值會小於等於CloudFront節點緩存文件的時間。您可以通過使用一些訪問URL的命令行,例如“curl”訪問一些特定的URL並通過參考響應中“X-Cache”包頭以及“Age”包頭判斷請求是否被緩存,以及緩存時間。
註: 建議是在Linux下,用curl命令進行測試;windows,容易受緩存幹擾。
AWS企業實戰之CloudFront的配置