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;

clip_image002

點擊 create Distribution,

clip_image004

這裏選擇的轉發方式爲web,討論的也是網站的CDN加速,對流媒體暫不討論;

clip_image006

看到如上界面,這個界面總共會設計到三個部分的設置:

第一, 源站設置,主要是指定ELB或者S3地址;

第二, 默認緩存行爲設置,即默認緩存策略;

第三, 分發設置;

但是在這裏,不做具體配置,看下圖:

clip_image008

設置好origin Domain Name,其他保持默認,最後點擊 create Distribution;

clip_image010

狀態顯示爲In Progress,預計等待15分鐘左右….

5、 Distribution Settings

完成以上動作,初步完成了分發的創建,繼續往下看:

clip_image012

這個是剛剛創建的,點擊,進去:

clip_image014

點 edit;-------------上圖中的Domain Name: dsnsbl39shfl3.cloudfront.net   , 便是cname配置所指向的目標地址

clip_image016

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

clip_image018

clip_image020

這個頁面,也沒有太多需要說明,紅色方框的部分注意填寫即可,下面方框如果需要支持Http/https,請選擇match viewer;

7、 Create behavior

本小節是整個CDN配置的關鍵和難點,需要認真理會後續邏輯

clip_image022

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 匹配單個字符,

clip_image024

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,對頭部信息進行判斷,再實現跳轉

clip_image026

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;

}

}

clip_image028

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 如果源服務器根據一個或多個查詢字符串參數返回對象的不同版本,請選擇此項;

clip_image030

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,容易受緩存干擾。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章