本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
經過一些初步設定後，CloudFront 會與您的網站或應用程式合作，加速交付您的內容。本節說明 CloudFront 如何在收到瀏覽者請求後向其提供內容。
CloudFront 如何將內容交付給您的使用者
在您設定 CloudFront 以交付內容之後，以下是使用者請求物件時會發生的情況：
使用者存取您的網站或應用程式並傳送一或多個物件的請求，如影像檔案或 HTML 檔案。
DNS 會將請求路由到 CloudFront POP （節點），最適合處理請求，通常是在延遲方面最接近的 CloudFront POP。
CloudFront 會檢查快取中是否有所請求的物件。如果物件在快取中，CloudFront 會將物件傳回給使用者。如果物件不在快取中，CloudFront 會執行下列作業：
CloudFront 會比較請求與分佈中的規格，將請求轉送至原始伺服器以取得對應的物件類型，例如，轉送至 Amazon S3 儲存貯體或 HTTP 伺服器。
原始伺服器會將物件傳送回節點。
來自原始伺服器的第一個位元組一抵達，CloudFront 就會開始向使用者轉送物件。下次有人請求物件時，CloudFront 還會將物件新增到快取中。
CloudFront 使用區域節點快取的方法
CloudFront 連接點 (也稱為 POP 或節點) 確保能將熱門內容快速提供給瀏覽者。即使內容的熱門度不足以留在 POP，CloudFront 也有可將更多內容帶給瀏覽者的「區域節點快取」，有助於提升該內容的效能。
區域節點快取有助於處理所有內容類型，特別是隨著時間推移漸漸不熱門的內容。範例包含使用者產生的內容，例如影片、照片或圖案；電子商務資產，例如產品照片和影片；以及可能因新聞和事件而知名度突然暴增的相關內容。
區域快取的工作方式
區域節點快取是部署在全球各地接近瀏覽者的 CloudFront 位置。位於原始伺服器和 POP (直接向瀏覽者提供內容的全球節點) 之間。隨著物件變得較不熱門，個別 POP 可能會移除這些物件，為更熱門的內容騰出空間。區域節點快取擁有的快取比個別 POP 大，因此物件在最近的區域節點快取位置保留在快取中的時間會比較久。這有助於將更多內容放在距離瀏覽者更近的地方，降低 CloudFront 返回原始伺服器的需求，並提高整體的瀏覽者效能。
當瀏覽者在您的網站上或透過您的應用程式發出請求時，DNS 會將請求路由到最能滿足使用者請求的 POP。此位置通常是與延遲有關的最近 CloudFront 節點。在 POP 中，CloudFront 會檢查快取中是否有所請求的物件。如果物件在快取中，CloudFront 會將物件傳回給使用者。如果物件不在快取中，POP 通常將移至最近的區域節點快取，以擷取物件。如需 POP 何時略過區域節點快取，並直接進入原始伺服器的相關資訊，請參閱以下備註。
在區域節點快取位置中，CloudFront 會再次檢查其快取中是否有請求的物件。如果檔案在快取中，CloudFront 會將其轉送至提出請求的 POP。來自區域節點快取位置的第一個位元組一抵達，CloudFront 就會開始向使用者轉送物件。下次有人請求物件時，CloudFront 還會將物件新增到 POP 的快取中。
至於未在 POP 和區域節點快取位置中進行快取的物件，CloudFront 會比較請求和分佈規格，並將請求轉送到原始伺服器。在原始伺服器將物件傳送回區域節點快取位置後，會將其轉送到 POP，由 CloudFront 轉送給使用者。在這種情況下，CloudFront 除了將物件新增到 POP 之外，還會新增到區域節點快取位置的快取，以供瀏覽者下次請求物件時擷取。如此可確保某個區域中的所有 POP 都共用一份本機快取，不會向原始伺服器提出多個請求。CloudFront 也會與原始伺服器保持永久連線，以便儘快從原始伺服器擷取物件。
注意
-
區域節點快取具有與 POP 相同的功能。例如，快取失效請求在到期之前從 POP 快取和區域節點快取中移除物件。下次瀏覽者請求該物件時，CloudFront 會回到原始伺服器擷取物件的最新版本。
-
Proxy HTTP 方法 (
PUT、POST、PATCH、OPTIONS和DELETE) 直接從 POP 進入原始伺服器，而且不透過區域節點快取進行代理。 -
在請求時決定的動態請求不會流經區域邊緣快取，而是直接移至原始伺服器。
-
當原始伺服器是 Amazon S3 儲存貯體，且請求的最佳區域節點快取與 S3 儲存貯體位於相同位置 AWS 區域 時，POP 會略過區域節點快取並直接前往 S3 儲存貯體。
下列圖表說明請求和回應經 CloudFront 節點和區域節點快取的處理方式。
