先前討論了 Policy,在文章最後面我們提到了 httpbin.org 可以作為進一步測試的 Origin。
有網友來信詢問希望進一步瞭解的差異 & 怎麼做,我們今天我們就以 httpbin 等來說明 CachePolicy & Legacy 時的一些微妙差異。
先說結論,主要差異在於 Header 轉發的策略,以及是否會拿來作為緩存 Key 使用。
而這是 Feature/By Design,不是 Bug。
Legacy Settings
[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"
}
好奇妙,怎麼看起來結果又好像一樣?
那麼只好進一步再次測試。
我們添加一個標頭,叫做 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,似乎轉發了沒有需要轉發的標頭... ?!
如果使用 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
上面的特性僅會出現在 Legacy Cache Settings 嗎? 當然不是,如果有搭配 Origin Request Policy 也是可能重現。 所以這是服務設計(Feature/By Design),不是Bug
為了重現這個,我們拆分以下步驟。
(步驟1) 先新增一組 Origin Request Policy 到 usingpolicy 的 distribution。
(步驟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!
後續我們會在「排查問題的章節」舉例說明。
感謝收看,歡迎留言給我讓我知道你的看法。