iT邦幫忙

2023 iThome 鐵人賽

DAY 18
0
Cloud Native

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

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

  • 分享至 

  • 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
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言