設計和設定 Azure Front Door
Azure Front Door 是 Microsoft 提供的新式雲端內容傳遞網路 (CDN)，可以在您的使用者和世界各地應用程式的靜態和動態網路內容之間，提供快速、可靠且安全的存取。 Azure Front Door 使用 Microsoft 的全域周邊網路搭配上百個分散在世界各地的全球和區域 POP 傳遞您的內容，這些 POP 不只靠近您的企業，也靠近消費終端使用者。
許多組織都有應用程式需要提供給其客戶、供應商，且幾乎必然需要提供給其使用者。 棘手的部分是確保這些應用程序具有高可用性。 此外，其必須能夠快速回應，同時受到適當保護。 Azure Front Door 提供不同的 SKU (定價層) 來符合這些需求。 讓我們快速回顧這些 SKU 的功能和優點，讓您可以判斷哪一個選項最適合您的需求。
安全的新式雲端 CDN 會提供分散式的伺服器平台。 這有助於在使用者存取網頁時將延遲降至最低。 在過去，IT 人員可能已使用 CDN 和 Web 應用程式防火牆來控制進出目標應用程式的 HTTP 和 HTTPS 流量。
如果組織使用 Azure，則可能實作下表所述產品來達成這些目標
| 產品 | 說明 |
|---|---|
| Azure Front Door | 針對位於 Microsoft 全域邊緣網路的應用程式啟用進入點。 為您的 Web 應用程式提供更快速、更安全且可擴充的存取權。 |
| Azure 內容傳遞網路 | 藉由在策略性放置於世界各地的實體節點上快取使用者內容，將高頻寬內容傳遞給您的使用者。 |
| Azure Web 應用程式防火牆 | 協助集中加強保護 Web 應用程式，使其免於遭遇常見的攻擊和弱點。 |
Azure Front Door 階層比較
Azure Front Door 提供 2 個不同階層：Azure Front Door Standard 和 Azure Front Door Premium。 Azure Front Door Standard 和 Premium 階層將 Azure Front Door (傳統版)、Microsoft 的 Azure CDN 標準 (傳統版) 以及 Azure WAF 的功能結合為單一安全的雲端 CDN 平台，同時搭配智慧型威脅防護。 Azure Front Door 位於邊緣位置，並可管理對所裝載應用程式的使用者要求。 使用者透過 Microsoft 全球網路連線到您的應用程式。 然後，Azure Front Door 將使用者要求路由傳送至最快速且可用性最高的應用程式後端。
如需 Azure Front Door 中支援功能的比較，請檢閱功能比較表。
在 Azure 入口網站中建立 Front Door
請檢閱下列快速入門，了解如何使用 Azure 入口網站建立 Azure Front Door 設定檔。 您可以使用基本設定並透過 [快速建立]，或透過允許更多進階設定的 [自訂建立] 建立 Azure Front Door 設定檔。
路由架構概觀
Front Door 流量路由會分成多個階段進行。 首先，流量會從用戶端路由至 Front Door。 接著，Front Door 會用您的設定判斷要傳送流量的來源。 Front Door Web 應用程式防火牆、路由規則、規則引擎規則和快取設定都會影響路由流程。 下圖為路由結構示意圖：
在 Front Door 中設定重新導向規則
建立連線並完成 TLS 交握之後，當要求進入 Front Door 環境時，Front Door 首先會判斷要求符合哪個路由規則，然後執行設定中定義的動作。
Front Door 路由規則設定結構
Front Door 路由規則設定主要由兩個部分組成：「左邊」與「右邊」。 Front Door 在路由左側比對連入要求。 右邊會定義 Front Door 處理要求的方式。
傳入比對
下列屬性可判斷連入要求與路由規則 (或左邊) 是否相符：
- HTTP 通訊協定 (HTTP/HTTPS)
- 主機 (例如 www.foo.com、*.bar.com)
- 路徑 (例如 /、/users/、/file.gif)
這些屬性是從內部展開，因此通訊協定/主機/路徑的每個組合都是可能的相符項目集合。
路由資料
Front Door 使用快取來加快要求處理速度。 如果已針對特定路由啟用快取，則會使用快取的回應。 如果要求沒有快取的回應，Front Door 會將要求轉送至已設定的後端集區中適當的後端。
路由比對
Front Door 只查看路由左側，嘗試比對第一個最相符項。 其首先會比對 HTTP 通訊協定，然後是前端主機，最後是路徑。
前端主機比對：
- 尋找主機上完全相符的任何路由。
- 如果沒有完全相符的前端主機項目，則拒絕要求，並傳送「400 不正確的要求」錯誤。
路徑比對：
- 尋找路徑上完全相符的任何路由規則。
- 如果沒有完全相符的路徑，則尋找符合萬用字元路徑的路由規則。
- 如果找不到與路徑相符的任何路由規則，則拒絕要求並傳回「400：不正確的要求」HTTP 錯誤回應。
如果使用全面涵蓋路由路徑 (/*) 的完全相符前端主機找不到任何路由規則，則任何路由規則都不會有相符項目。
Azure Front Door 在下列各層級將流量重新導向：通訊協定、主機名稱、路徑、查詢字串。 因為重新導向以路徑為基礎，所以可以針對個別微服務來設定這些功能。 這樣可將資源使用量最佳化來簡化應用程式設定，而且支援新的重新導向情節，包括全域和路徑式重新導向。
重新導向類型
重新導向類型會設定回應狀態碼，讓用戶端了解重新導向的目的。 支援下列重新導向類型：
| 重新導向類型 | 動作 | 說明 |
|---|---|---|
| 301 | 已永久移動 | 指出已指派新的永久 URI 給目標資源。 未來參考此資源時都將使用其中一個含括的 URI。 針對 HTTP 至 HTTPS 重新導向使用 301 狀態碼。 |
| 302 | 已找到 | 指出目標資源暫時在不同的 URI 下。 由於重新導向有時會變更，對於未來的要求，用戶端應該繼續使用有效要求 URI。 |
| 307 | 暫時重新導向 | 指出目標資源暫時在不同的 URI 下。 如果使用者代理程式會自動重新導向該 URI，則「不可」變更要求方法。 由於重新導向可能隨著時間而改變，對於未來的要求，用戶端應該繼續使用原始的有效要求 URI。 |
| 308 | 永久重新導向 | 指出已指派新的永久 URI 給目標資源。 未來參考此資源時都應該使用其中一個含括的 URI。 |
重新導向通訊協定
您可以設定將用於重新導向的通訊協定。 重新導向功能最常見的使用案例是將 HTTP 設定為 HTTPS 重新導向。
- 僅限 HTTPS：如果您想要將流量從 HTTP 重新導向 HTTPS，請將通訊協定設定為「僅限 HTTPS」。 Azure Front Door 建議您一律將重新導向設定為 [僅限 HTTPS]。
- 僅限 HTTP：將連入要求重新導向 HTTP。 只有當您想要保持流量為 HTTP 時 (亦即非加密)，才使用此值。
- 比對要求：此選項會保留傳入要求所使用的通訊協定。 因此，在重新導向後，HTTP 要求仍是 HTTP，而 HTTPS 要求仍是 HTTPS。
目的地主機
在設定重新導向路由的過程中，您也可以變更重新導向要求的主機名稱或網域。 您可以設定此欄位以變更重新導向 URL 中的主機名稱，不然就保留連入要求中的主機名稱。 因此，您可以使用此欄位將 https://www.contoso.com/* 上傳送的所有要求重新導向 https://www.fabrikam.com/*。
目的地路徑
如果想要在重新導向時取代 URL 的路徑區段，您可以將此欄位設為新的路徑值。 否則，您可以選擇在重新導向時保留路徑值。 因此，您可以使用此欄位將傳送至 https://www.contoso.com/* 的所有要求重新導向 https://www.contoso.com/redirected-site。
目的地片段
目的地片段是 URL 中 '#' 後面的部分，供瀏覽器用來進入網頁的特定區段。 您可以設定此欄位將片段新增至重新導向 URL。
查詢字串參數
您也可以取代重新導向 URL 中的查詢字串參數。 若要取代連入要求 URL 中的任何現有的查詢字串，請將此欄位設定為 [取代]，然後設定適當的值。 否則，請將欄位設定為「保留」，以保留原始的查詢字串集。 例如，使用此欄位，您可以將傳送至 的所有流量重新導向至 https://www.contoso.com/foo/barhttps://www.contoso.com/foo/bar?&utm_referrer=https%3A%2F%2Fww.bing.com%2F。
設定重寫原則
Azure Front Door 支援 URL 重寫，可讓您設定選用的自訂轉送路徑，供建構要求來轉送至後端時使用。 如果未提供自訂轉送路徑，Front Door 預設會將傳入的 URL 路徑，複製到轉送的要求中使用的 URL。 用於轉送要求中的主機標頭，與針對所選後端設定的標頭相同。 請參閱《後端主機標頭》以了解其功用與設定方式。
URL 重寫的強大功能在於，自訂轉送路徑會將傳入路徑中符合萬用字元路徑的任何部分複製到轉送的路徑。
設定健全狀態探查，包括自訂 HTTP 回應碼
為了判斷特定 Front Door 環境每個後端的健康情況和鄰近性，每個 Front Door 環境會定期將綜合 HTTP/HTTPS 要求傳送至您設定的每個後端。 Front Door 接著會使用這些來自探查的回應，決定「最佳」後端資源來路由傳送用戶端要求。
由於 Front Door 在全球有許多邊緣環境，因此，後端的健全狀態探查量可能相當高，從每分鐘 25 個要求到每分鐘多達 1200 個要求，視已設定的健全狀態探查頻率而定。 預設探查頻率為 30 秒，後端的探查量大約為每分鐘 200 個要求。
健全狀態探查支援的 HTTP 方法
Front Door 支援透過 HTTP 或 HTTPS 通訊協定傳送探查。 這些探查透過設定用於路由傳送用戶端要求之相同的 TCP 連接埠傳送，並且無法覆寫。
Front Door 支援下列 HTTP 方法來傳送健全狀態探查：
GET：GET 方法表示取出由 Request-URI 識別的任何資訊 (實體形式)。
HEAD：HEAD 方法與 GET 相同，不同之處在於伺服器「不可」在回應中傳回訊息主體。 由於其對後端造成的負載和成本較低，就新的 Front Door 設定檔而言，探查方法預設為 HEAD。
健全狀態探查回應
下表說明對健全狀態探查的回應：
| 回應 | 說明 |
|---|---|
| 判斷健康情況 | 200 OK 狀態碼表示後端狀況良好。 所有其他項目會視為失敗。 如果探查出於任何原因 (包括網路失敗) 未收到有效的 HTTP 回應，則探查就算失敗。 |
| 測量延遲 | 延遲是時鐘時間，且測量是從傳送探查要求前的那一刻起，直到收到回應的最後一個位元組的那一刻為止。 每個要求都使用新的 TCP 連線，因此，該測量不會偏向既有連線熱絡的後端。 |
Azure Front Door 使用以下相同的三步驟程序來執行所有演算法，以判斷健康情況。
排除已停用後端。
排除健全狀態探查發生錯誤的後端：
- 此選取是透過查看最後 n 個健全狀況探查回應來完成的。 如果有至少 x 個回應狀況良好，便會將後端視為狀況良好。
- n 是透過變更負載平衡設定中的 SampleSize 屬性來設定。
- x 是透過變更負載平衡設定中的 SuccessfulSamplesRequired 屬性來設定。
對於後端集區中的良好後端集，Front Door 還會測量並維護每個後端的延遲 (往返時間)。
如果後端集區中有單一後端，您可以選擇停用健全狀態探查，以減少應用程式後端的負載。 即使後端集區中有多個後端，但其中只有一個處於已啟用狀態，您也可以停用健全狀態探查。
使用 SSL 保護 Front Door
在自訂網域上使用 HTTPS 通訊協定 (例如 https://www.contoso.com)，可確保在網際網路上傳送敏感性資料時，會透過 TLS/SSL 加密來安全地傳遞。 當網頁瀏覽器透過 HTTPS 來連線到網站時，將會驗證該網站的安全性憑證，並確認憑證由合法的憑證授權單位所核發。 此流程可提供安全性，並讓 Web 應用程式免於遭受攻擊。
自訂 HTTPS 功能的一些重要特色如下：
- 無額外成本：取得或更新憑證不需要成本，HTTPS 流量也不會產生額外成本。
- 容易啟用：從 Azure 入口網站按一下就能佈建。 您也可以使用 REST API 或其他開發工具來啟用此功能。
- 完整憑證管理：會為您處理所有憑證採購及管理。 憑證會自動佈建並在到期之前更新，消除因為憑證到期而中斷服務的風險。
您可以在 [前端主機] 區段下，針對與 Front Door 相關聯的自訂網域啟用 HTTPS 通訊協定。
如需有關如何在 Front Door 上設定 HTTPS 的詳細資訊，請參閱教學課程 - 在 Azure Front Door 的自訂網域上設定 HTTPS | Microsoft Docs。