Azure 應用程式閘道功能
Azure 應用程式閘道是網路流量負載平衡器，可讓您管理 Web 應用程式的流量。
注意
針對 Web 工作負載，強烈建議使用 Azure DDoS 保護和 Web 應用程式防火牆來防範新興的 DDoS 攻擊。 另一個選項是運用 Azure Front Door 和 Web 應用程式防火牆。 Azure Front Door 提供平台層級保護來防範網路層級 DDoS 攻擊。 如需詳細資訊，請參閱 Azure 服務的安全性基準。
應用程式閘道包括下列功能：
安全通訊端層 (SSL/TLS) 終止
應用程式閘道支援在閘道上終止 SSL/TLS，之後流量通常會以未加密狀態流至後端伺服器。 這項功能可讓網頁伺服器不受成本高昂的加密和解密額外負荷的負擔。 不過，有時候無法對伺服器進行未加密的通訊。 這可能是因為安全性需求、合規性需求，或應用程式可能只接受安全連線。 對於這些應用程式，應用程式閘道可支援端對端 SSL/TLS 加密。
如需詳細資訊，請參閱應用程式閘道的 SSL 終止和端對端 SSL 概觀
自動調整規模
應用程式閘道 Standard_v2 支援自動調整，並且可根據變動的流量負載模式來擴大或縮小。 自動調整規模也可讓您在佈建時，無須選擇部署大小或執行個體計數。
如需 應用程式閘道 Standard_v2 功能的詳細資訊，請參閱什麼是 Azure 應用程式閘道 v2。
區域備援
Standard_v2 應用程式閘道可以跨多個可用性區域、提供更好的錯誤復原能力，且讓您無須在每個區域中佈建個別的應用程式閘道。
靜態 VIP
應用程式閘道 Standard_v2 SKU 專門支援靜態 VIP 類型。 這可確保與應用程式閘道相關聯的 VIP 即使在應用程式閘道的存留期內也不會變更。
Web 應用程式防火牆
Web 應用程式防火牆 (WAF) 是可集中保護 Web 應用程式的服務，使其免於遭遇常見的攻擊和弱點。 WAF 會根據 OWASP (Open Web Application Security Project) 核心規則集 3.1 (僅限 WAF_v2)、3.0 或 2.2.9 中的規則提供保護。
Web 應用程式已逐漸成為惡意探索常見已知弱點的惡意攻擊的目標。 這些惡意探索中常見的是 SQL 插入式攻擊、跨網站指令碼攻擊等等。 在應用程式程式碼中防止這類攻擊可能具有挑戰性，而且可能需要在應用程式拓撲的許多層級進行嚴格的維護、修補和監視。 集中式 Web 應用程式防火牆可協助讓安全性管理更簡單，並為應用程式系統管理員提供更完善的威脅或入侵防禦保證。 對比於保護個別的 Web 應用程式，WAF 解決方案也可透過在中央位置修補已知弱點，更快地回應安全性威脅。 現有的應用程式閘道可以輕易地轉換成已啟用 Web 應用程式防火牆的應用程式閘道。
如需如何搭配應用程式閘道使用 Azure WAF 防範 DDoS 攻擊的指引，請參閱應用程式 DDoS 保護。 如需詳細資訊，請參閱什麼是 Azure Web 應用程式防火牆。
AKS 的輸入控制器
應用程式閘道輸入控制器 (AGIC) 可讓您使用應用程式閘道作為 Azure Kubernetes Service (AKS) 叢集的輸入。
輸入控制器會在 AKS 叢集中以 Pod 的形式執行，並取用 Kubernetes 輸入資源，然後將其轉換成應用程式閘道設定，讓閘道能夠對 Kubernetes Pod 的流量進行負載平衡。 輸入控制器僅支援應用程式閘道 Standard_v2 和 WAF_v2 SKU。
如需詳細資訊，請參閱應用程式閘道輸入控制器 (AGIC)。
URL 型路由
URL 路徑型路由可讓您根據要求的 URL 路徑，將流量路由傳送至後端伺服器集區。 有一個案例是將對於不同內容類型的要求路由傳送至不同的集區。
例如，對 http://contoso.com/video/* 的要求會路由傳送至 VideoServerPool，而對 http://contoso.com/images/* 的要求則會路由傳送至 ImageServerPool。 如果沒有任何路徑模式相符，則會選取 DefaultServerPool。
如需詳細資訊，請參閱 URL 路徑型路由概觀。
多網站裝載
透過應用程式閘道，您可以根據主機名稱或網域名稱，為同一個應用程式閘道上的多個 Web 應用程式設定路由。 此功能可讓您將 100 多個網站新增到一個應用程式閘道，為您的部署設定更有效率的拓撲。 每個網站都可以導向到自己的後端集區。 例如，contoso.com、fabrikam.com 和 adatum.com 三個網域都指向應用程式閘道的 IP 位址。 您會建立三個多網站接聽程式，並針對個別的連接埠和通訊協定設定來設定每個接聽程式。
對 http://contoso.com 的要求會路由至 ContosoServerPool，而對 http://fabrikam.com 的要求則會路由至 FabrikamServerPool，以此類推。
同樣地，相同父系網域的兩個子網域也可以裝載在相同的應用程式閘道部署上。 使用子網域的範例可能包括單一應用程式閘道部署上裝載的 http://blog.contoso.com 和 http://app.contoso.com。 如需詳細資訊，請參閱應用程式閘道的多網站裝載。
您也可以在多網站接聽程式中定義萬用字元主機名稱，並為每個接聽程式定義最多 5 個主機名稱。 若要深入瞭解，請參閱接聽程式中的萬用字元主機名稱。
重新導向
許多 Web 應用程式的常見案例是支援自動 HTTP 至 HTTPS 的重新導向，以確保應用程式與其使用者之間的通訊會透過加密的路徑進行。
在過去，您會使用一些技巧 (例如建立專屬集區)，其唯一目的是要將其在 HTTP 上接收的要求重新導向至 HTTPS。 應用程式閘道支援在應用程式閘道上重新導向流量的功能。 這可簡化應用程式組態、將資源使用量最佳化，並支援新的重新導向案例，包括全域和路徑式重新導向。 應用程式閘道重新導向支援不僅止於 HTTP 至 HTTPS 的重新導向。 這是一般重新導向機制，因此您可以從使用規則定義的任何連接埠重新導向，或是重新導向至使用規則定義的任何連接埠。 它也支援重新導向至外部網站。
應用程式閘道重新導向支援提供下列功能：
- 從閘道上的一個連接埠到另一個連接埠的全域重新導向。 這允許在網站上進行 HTTP 至 HTTPS 重新導向。
- 路徑式重新導向。 這類型的重新導向只允許在特定網站區域上進行 HTTP 至 HTTPS 重新導向，例如以
/cart/*表示的購物車區域。 - 重新導向至外部網站。
如需詳細資訊，請參閱應用程式閘道重新導向概觀。
工作階段親和性
當您想要在同一個後端保留使用者工作階段時，以 Cookie 為基礎的工作階段親和性非常有用。 使用閘道管理的 Cookie，應用程式閘道即可將後續來自使用者工作階段的流量導向同一部伺服器進行處理。 當使用者工作階段的工作階段狀態儲存在伺服器本機時，這項功能很重要。
如需詳細資訊，請參閱應用程式閘道的運作方式。
Websocket 和 HTTP/2 流量
應用程式閘道可對 WebSocket 和 HTTP/2 通訊協定提供原生支援。 沒有使用者可設定的設定可選擇性地啟用或停用 WebSocket 支援。
WebSocket 和 HTTP/2 通訊協定都可透過長時間執行的 TCP 連線，讓伺服器與用戶端之間能進行全雙工通訊。 此功能可讓網頁伺服器和用戶端之間進行互動性更高的通訊，此通訊可以是雙向的，而不需要像 HTTP 型實作所要求的進行輪詢。 不同於 HTTP，這些通訊協定的負荷很低，而且可以對多個要求/回應重複使用相同的 TCP 連線，進而提升資源使用效率。 這些通訊協定設計為透過傳統 HTTP 連接埠 80 和 443 進行運作。
如需詳細資訊，請參閱 WebSocket 支援 \(機器翻譯\) 與 HTTP/2 支援 \(機器翻譯\)。
清空連線
連線清空可協助您在計劃性服務更新期間，或後端健康情況出現問題時，順利移除後端集區成員。 此設定會透過後端設定啟用，而且可以在規則建立期間套用至所有後端集區成員。 啟用之後，應用程式閘道可確保所有取消註冊的後端集區執行個體不會接收任何新的要求，但允許在已設定的時間限制內完成現有要求。 其適用於後端執行個體符合下列情況的案例：
- 在用戶變更組態之後，明確從後端集區移除，或
- 健康情況探查回報為狀況不良
唯一的例外狀況是，由於閘道管理的工作階段親和性，因而會繼續將要求 Proxy 處理到取消註冊的執行個體。
WebSocket 連線也會接受連線清空。 每次更新閘道時，都會叫用連線清空。 若要防止遺失與後端集區現有成員的連線，請務必啟用連線清空。
如需時間限制的相關資訊，請參閱後端設定組態。
自訂錯誤頁面
應用程式閘道可讓您建立自訂的錯誤頁面，而不是顯示預設的錯誤頁面。 您可以使用自訂錯誤頁面來搭配您自己的商標和版面配置。
如需相關資訊，請參閱自訂錯誤。
重寫 HTTP 標頭和 URL
HTTP 標頭允許用戶端和伺服器透過要求或回應傳遞其他資訊。 重寫這些 HTTP 標頭可協助您完成幾個重要的案例，例如：
- 新增安全性相關的標頭欄位，例如 HSTS/ X-XSS-Protection。
- 移除可能會顯示機密資訊的回應標頭欄位。
- 從 X-Forwarded-For 標頭中移除連接埠資訊。
Application Gateway 和 WAF v2 SKU 支援在要求及回應封包於用戶端與後端應用程式之間移動時，新增、移除或更新 HTTP 要求及回應標頭的功能。 您也可以重寫 URL、查詢字串參數和主機名稱。 使用 URL 重寫和 URL 路徑型路由時，您可以使用 [重新評估路徑對應] 選項，選擇要根據原始路徑還是重寫路徑將要求路由傳送至其中一個後端集區。
其還為您提供了新增條件的功能，以確保僅在符合特定條件時才重新寫入指定的標頭或 URL。 這些條件所根據的是要求和回應資訊。
如需詳細資訊，請參閱重新撰寫 HTTP 標頭和 URL。
調整大小
可為自動調整或固定大小的部署設定應用程式閘道 Standard_v2。 v2 SKU 不提供不同執行個體大小。 如需 v2 效能和定價的詳細資訊，請參閱自動調整 V2 和了解定價。
應用程式閘道標準 (v1) 目前提供三種大小：小型、中型和大型。 小型執行個體大小是針對開發和測試案例。
如需應用程式閘道限制的完整清單，請瀏覽應用程式閘道服務限制。
下表顯示每個應用程式閘道 v1 執行個體，在啟用 SSL 卸載時的平均效能輸送量：
| 平均後端頁面回應大小 | Small | 中 | 大型 |
|---|---|---|---|
| 6 KB | 7.5 Mbps | 13 Mbps | 50 Mbps |
| 100 KB | 35 Mbps | 100 Mbps | 200 Mbps |
注意
這些值是應用程式閘道輸送量的近似值。 實際的輸送量會依據不同的環境詳細資料而有所不同，例如平均頁面大小、後端執行個體位置，以及提供一個頁面所需的處理時間。 如需實際效能數字，您需自行執行測試。 這些值僅供容量規劃指引使用。
版本功能比較
如需 v1-v2 功能比較 應用程式閘道，請參閱什麼是 Azure 應用程式閘道 v2。