從 AWS Cloudfront 到後端 EC2 伺服器的迂迴流量
我正在使用 AWS 的“基本支持”計劃，因此無法詢問那裡的內部技術專家。我試圖設置雲端。我的後端在 AWS Hong Kong。但是，我注意到 Cloudfront HK 伺服器的“前端”流量不會直接進入我也在 AWS 香港的後端 EC2 伺服器。相反，請求來自 AWS 新加坡的我的 HK EC2。（換句話說，HK CloudFront 代理通過新加坡從我的 HK EC2 源伺服器獲取內容。）這種情況常見嗎？它為請求增加了不必要的延遲。直接請求可以在 100 毫秒內完成，但這需要 250 毫秒。我檢查了這是否僅適用於HK，結果並非如此。我從東京發出了一個請求，該請求被 CloudFront Tokyo 擷取。從那裡，而不是直接發送到香港，它把它送到新加坡，然後從那裡被重定向回香港。知道為什麼會這樣嗎？我想不出任何合乎邏輯的原因，為什麼 AWS 會通過第三國路由同一位置內另一台伺服器的流量，而不是直接在該位置內路由。
作為記錄，原始伺服器以 Cloudfront 中的經典 aws DNS 表示法 (ip-address-location-awz.amazon.com) 給出。CF 不會認為它是非 AWS IP 地址。
您所看到的原因已記錄在案，但文件中提供的含義並沒有太多細節或討論。
CloudFront 網路有兩層。
有外部“全球”層和內部“區域”層。大多數 AWS 區域都有區域 CloudFront 邊緣，但不是全部 - 香港目前是一個例外，這是一個沒有區域邊緣的 AWS 區域。
請求通常到達查看者附近的“全球邊緣”位置（例如，美國喬治亞州亞特蘭大），在該位置檢查邊緣記憶體並提供內容，或者將請求轉發到源。
但它不會直接轉發到原點。
相反，請求被轉發到最近的“區域記憶體”（例如，來自亞特蘭大，可能是美國俄亥俄州——us-east-2 區域），在那裡檢查該記憶體是否有響應。如果找到，則將其返回到處理原始請求的全域邊緣，將其儲存在記憶體中（如果可記憶體）並返回給查看器。
如果區域記憶體也沒有副本，則將請求從那裡轉發到源伺服器，並將響應記憶體在區域記憶體中，然後返回原始全域邊緣，如果可能也記憶體在那裡，並且返回給觀眾。
從統計上看，這一切都適用於記憶體命中，即使在這種情況下，它在記憶體未命中和不可記憶體內容方面引入了往返劣勢，因為香港邊緣必須諮詢新加坡區域邊緣，然後必鬚髮送請求回到香港的EC2。（亞特蘭大到俄亥俄州到香港無疑比香港到新加坡到香港更明智）。
如果 CloudFront 在香港部署區域邊緣，這種行為在未來幾乎肯定會發生變化。
單個請求的往返基準測試也不一定能說明整個性能故事，尤其是在低流量環境中。CloudFront 支持 http/2，因此可以在單個瀏覽器連接上並行處理多個請求，CloudFront 通過向源發出的一系列獨立 HTTP/1.1 請求在後端並行處理這些請求。CloudFront 在全球邊緣處理與瀏覽器的 TLS 協商，並重用從全球邊緣到區域記憶體以及從區域記憶體到源伺服器的連接，因此在主動處理流量的站點上，請求的可能性更大受益於這些優化，減少了可以單獨觀察到的實際往返時間。
請參閱CloudFront 如何使用區域邊緣記憶體以及全球和區域邊緣列表。
有關您可以對分配配置進行自定義以增加 CloudFront 保持打開的後端連接以供重用的時間量的討論，請參閱Origin Keep-Alive Timeout ；預設值只有 5 秒，但您可以將其增加到 60 秒，或者通過特殊安排可能更多。另請參閱自定義來源/持久連接。