iT邦幫忙

2023 iThome 鐵人賽
DAY 18
0
Cloud Native

2023 年了，一起來學 CDN - 你也可以瞭解的 CloudFront 系列 第 18 篇

Day 18 - 進一步比較 Policy 和 Legacy Settings

15th鐵人賽 aws cloudfront cdn
310 瀏覽

  • 分享至 

  • xImage
    •  

先前討論了　Policy，在文章最後面我們提到了 httpbin.org 可以作為進一步測試的 Origin。
有網友來信詢問希望進一步瞭解的差異 & 怎麼做，我們今天我們就以 httpbin 等來說明 CachePolicy & Legacy 時的一些微妙差異。

結論

先說結論，主要差異在於 Header 轉發的策略，以及是否會拿來作為緩存 Key 使用。

  • Legacy Settings:
    Headers: CloudFront 在收到請求時仍會儘可能轉發所有資訊到 Origin，但最終僅以有轉發的 Header 作為 Key
    QueryStrings: 僅有明確指定的資訊才會轉發到 Origin
    Coolies: 僅有明確指定的資訊才會轉發到 Origin
  • Cache Policy:
    Headers: 僅有明確指定的資訊才會轉發到 Origin
    QueryStrings: 僅有明確指定的資訊才會轉發到 Origin
    Coolies: 僅有明確指定的資訊才會轉發到 Origin

而這是 Feature/By Design，不是 Bug。

實際測試 & 驗證

  1. 我們需要設置兩組 CloudFront Distribution，分別對應 Cache Policy & Legacy Cache Settings.
  1. 此時我們可以看到兩者(上: Cache Policy; 下: Legacy settings)的呈現。咦? 怎麼好像印出的內容不太一樣?
    Cache Policy
    https://ithelp.ithome.com.tw/upload/images/20230920/20162502pmvKn5N22l.png

Legacy Settings
https://ithelp.ithome.com.tw/upload/images/20230920/20162502OuMt4jXJoO.png

  1. 那麼，為了方便測試，我們改使用 curl 來測試實際發送的東西
    Cache Policy 
[ec2-user@ip-172-17-0-128 ~]$ curl https://usingpolicy.kgg23.com/anything
{
  "args": {},
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Host": "httpbin.org",
    "User-Agent": "Amazon CloudFront",
    "X-Amz-Cf-Id": "uYD26bKdoure6SevaJIah1vN9w9Xaw_W65oeG0J8jGQ2flz4nibqFw==",
    "X-Amzn-Trace-Id": "Root=1-650b06b9-02ac271a08f263b16c4f9f1b"
  },
  "json": null,
  "method": "GET",
  "origin": "18.176.7.154, 64.252.110.129",
  "url": "https://httpbin.org/anything"
}

Legacy Settings

$ curl https://legacysettings.kgg23.com/anything
{
  "args": {},
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Host": "httpbin.org",
    "User-Agent": "Amazon CloudFront",
    "X-Amz-Cf-Id": "WLYB5EZ9825_QU-6QNbQV2iSL6aJRM8VUj1LHfwcHlnfSMg2JKRNwQ==",
    "X-Amzn-Trace-Id": "Root=1-650b06e0-017ed6fc509ea0897b56abba"
  },
  "json": null,
  "method": "GET",
  "origin": "18.176.7.154, 64.252.110.254",
  "url": "https://httpbin.org/anything"
}

好奇妙，怎麼看起來結果又好像一樣?

第 3 次測試: 添加特定標頭後，也是一樣的結果嗎?

那麼只好進一步再次測試。
我們添加一個標頭，叫做 x-kgg23，值是 ironman2023 來試試看。
Cache Policy

$ curl https://usingpolicy.kgg23.com/anything  -H 'x-kgg23: ironman2023'
{
  "args": {},
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Host": "httpbin.org",
    "User-Agent": "Amazon CloudFront",
    "X-Amz-Cf-Id": "vDR3SmEpgheSxVDMl_X1Ix4OQ092Ut2YbCAtFZFaqDtdfu7hi1Zq2Q==",
    "X-Amzn-Trace-Id": "Root=1-650b0a10-55e2c6865f55315130fc243b"
  },
  "json": null,
  "method": "GET",
  "origin": "18.176.7.154, 64.252.113.19",
  "url": "https://httpbin.org/anything"
}

Legacy Settings

{
  "args": {},
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Host": "httpbin.org",
    "User-Agent": "Amazon CloudFront",
    "X-Amz-Cf-Id": "D7O-E_zbbPJSirQ9lgfn1vA86VrdSQeJQgRuC-VDnCo-6o9qmLwc5g==",
    "X-Amzn-Trace-Id": "Root=1-650b09c4-72b1a357602227407eff0386",
    "X-Kgg23": "ironman2023" <-----  手動添加的標頭出現了
  },
  "json": null,
  "method": "GET",
  "origin": "18.176.7.154, 64.252.111.138",
  "url": "https://httpbin.org/anything"
}

設定為 Legacy Cache Settings 的 CloudFront Distribution，似乎轉發了沒有需要轉發的標頭... ?!

第 4 次測試: Legacy Cache Setting 對應的「特性」.

如果使用 Legacy Settings時，會有這樣的「行為」，那麼，有什麼副作用嗎?
讓我們連續送出兩筆請求，第一筆沒帶額外 Header，第二筆有帶；

$ $ echo "第一輪，不帶額外標頭"; curl https://legacysettings.kgg23.com/anything ; sleep 2; echo "第二輪，帶上額外標頭";  curl https://legacysettings.kgg23.com/anything  -H 'x-kgg23: ironman2023'
第一輪，不帶額外標頭
{
  "args": {},
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Host": "httpbin.org",
    "User-Agent": "Amazon CloudFront",
    "X-Amz-Cf-Id": "gL4OEyIGoWn2Q0PjlNJMgnYz9f62WDGd08xYS9JSQblGUjvBTnoymg==",
    "X-Amzn-Trace-Id": "Root=1-650b1036-545311a41aa404e60aa3ed33"
  },
  "json": null,
  "method": "GET",
  "origin": "18.176.7.154, 64.252.112.139",
  "url": "https://httpbin.org/anything"
}
第二輪，帶上額外標頭
{
  "args": {},
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Host": "httpbin.org",
    "User-Agent": "Amazon CloudFront",
    "X-Amz-Cf-Id": "gL4OEyIGoWn2Q0PjlNJMgnYz9f62WDGd08xYS9JSQblGUjvBTnoymg==",
    "X-Amzn-Trace-Id": "Root=1-650b1036-545311a41aa404e60aa3ed33"
  },
  "json": null,
  "method": "GET",
  "origin": "18.176.7.154, 64.252.112.139",
  "url": "https://httpbin.org/anything"
}

咦*3，怎麼好像第二筆請求的結果跟第一筆(沒帶額外標頭時)完全相同?
如果你將指令都加上 -v 的參數，就可以看到兩筆請求在 x-cache 出現了差異，第二筆命中了快取。

$ echo "第一輪，不帶額外標頭"; curl -v  https://legacysettings.kgg23.com/anything ; sleep 2; echo "第二輪，帶上額外標頭";  curl -v https://legacysettings.kgg23.com/anything  -H 'x-kgg23: ironman2023'

- 第一筆請求: x-cache: Miss from cloudfront
- 第二筆請求: x-cache: Hit from cloudfront

第 5 次測試: 使用 Policy 也能產生同樣結果

上面的特性僅會出現在 Legacy Cache Settings 嗎? 當然不是，如果有搭配 Origin Request Policy 也是可能重現。 所以這是服務設計(Feature/By Design)，不是Bug
為了重現這個，我們拆分以下步驟。
(步驟1) 先新增一組 Origin Request Policy 到 usingpolicy 的 distribution。
https://ithelp.ithome.com.tw/upload/images/20230920/20162502da0IuR2dT1.png
(步驟2) 驗證是否有將對應的標頭發去 Origin.

$ curl https://usingpolicy.kgg23.com/anything  -H 'x-kgg23: ironman2023
{
  "args": {},
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Accept": "*/*",
    "Host": "usingpolicy.kgg23.com",
    "User-Agent": "curl/8.2.1",
    "X-Amz-Cf-Id": "7O3eupNsH3lQtyaKLyyHzwhN86oZy8wchjFLUkpt8WgAsrhokNwWJA==",
    "X-Amzn-Trace-Id": "Root=1-650b1334-6a24208d151c6843312fd31a",
    "X-Kgg23": "ironman2023" <---- 有了
  },
  "json": null,
  "method": "GET",
  "origin": "18.176.7.154, 64.252.110.129",
  "url": "https://usingpolicy.kgg23.com/anything"
}

(步驟3) 比照 legacy settings，進行驗證。

第一輪，不帶額外標頭
{
  "args": {},
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Accept": "*/*",
    "Host": "usingpolicy.kgg23.com",
    "User-Agent": "curl/8.2.1",
    "X-Amz-Cf-Id": "zfnCH0pt0dkZyCKqI-ouF_TcaOQbcghmvjYtKnMqHZbq5fWigqcbxg==",
    "X-Amzn-Trace-Id": "Root=1-650b13cd-47f25dba0a22b35720732358"
  },
  "json": null,
  "method": "GET",
  "origin": "18.176.7.154, 64.252.110.129",
  "url": "https://usingpolicy.kgg23.com/anything"
}
* Connection #0 to host usingpolicy.kgg23.com left intact
第二輪，帶上額外標頭
{
  "args": {},
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Accept": "*/*",
    "Host": "usingpolicy.kgg23.com",
    "User-Agent": "curl/8.2.1",
    "X-Amz-Cf-Id": "zfnCH0pt0dkZyCKqI-ouF_TcaOQbcghmvjYtKnMqHZbq5fWigqcbxg==",
    "X-Amzn-Trace-Id": "Root=1-650b13cd-47f25dba0a22b35720732358"
  },
  "json": null,
  "method": "GET",
  "origin": "18.176.7.154, 64.252.110.129",
  "url": "https://usingpolicy.kgg23.com/anything"
}

原因也一樣，第二筆請求命中了第一筆請求的緩存，符合預期。

Rule of Thumb: 如果沒有特別原因，基本上別用 Origin Request Policy，可以拯救不少腦細胞。

OK，以上是今天的介紹，Let's call it a day!
後續我們會在「排查問題的章節」舉例說明。

感謝收看，歡迎留言給我讓我知道你的看法。


上一篇
Day 17 - CloudFront 的 Staging 環境 ( Continuous Deployment )
下一篇
Day 19 我原本想要寫 lambda@edge 和 CFF
系列文
2023 年了，一起來學 CDN - 你也可以瞭解的 CloudFront 共 30 篇
  1. 26
    Day 26 - 與 AWS 服務整合 - Origin 篇(Part 2)
  2. 27
    Day 27 - 對 CloudFront 進行壓力測試，合適嗎?
  3. 28
    Day 28 - CloudFront 日誌的使用及分析
  4. 29
    Day 29 - 排查使用 CloudFront 時的錯誤
  5. 30
    Day 30 - 進入第 30 天 - 入門 CloudFront 階段的結束，或是新階段的開始?
完整目錄
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言
iThome鐵人賽
參賽組數
1064 組
團體組數
40 組
累計文章數
22200 篇
完賽人數
602 人
iT+看影片追技術 看影片追技術 看更多
熱門tag 看更多
15th鐵人賽 16th鐵人賽 13th鐵人賽 14th鐵人賽 12th鐵人賽 11th鐵人賽 鐵人賽 2019鐵人賽 javascript 2018鐵人賽 python 2017鐵人賽 windows php c# windows server linux css react vue.js
熱門問題
熱門回答
熱門文章
IT邦幫忙