Azure Application Gateway-funktioner

Azure Application Gateway är en lastbalanserare för webbtrafik som gör det möjligt för dig att hantera trafik till dina webbappar.

Application Gateway conceptual

Kommentar

För webbarbetsbelastningar rekommenderar vi starkt att du använder Azure DDoS-skydd och en brandvägg för webbprogram för att skydda mot nya DDoS-attacker. Ett annat alternativ är att använda Azure Front Door tillsammans med en brandvägg för webbprogram. Azure Front Door erbjuder skydd på plattformsnivå mot DDoS-attacker på nätverksnivå. Mer information finns i Säkerhetsbaslinje för Azure-tjänster.

Application Gateway innehåller följande funktioner:

SSL/TLS-avslutning (Secure Sockets Layer)

Application Gateway stöder SSL/TLS-avslutning vid gatewayen, varefter trafiken vanligtvis flödar okrypterad till serverdelsservrarna. Den här funktionen bidrar till att befria webbservrarna från kostsam kryptering och dekryptering. Men ibland är okrypterad kommunikation till servrarna inte ett acceptabelt alternativ. Detta kan bero på säkerhetskrav, efterlevnadskrav eller att programmet endast accepterar en säker anslutning. För dessa program stöder Application Gateway SSL/TLS-kryptering från slutpunkt till slutpunkt.

Mer information finns i Översikt över SSL-avslutning och SSL från slutpunkt till slutpunkt med Application Gateway

Automatisk skalning

Application Gateway Standard_v2 stöder automatisk skalning och kan skalas upp eller ned baserat på ändrade trafikbelastningsmönster. Automatisk skalning tar även bort behovet av att välja distributionsstorlek eller instansantal under etablering.

Mer information om funktionerna i Application Gateway Standard_v2 finns i Vad är Azure Application Gateway v2.

Zonredundans

En Standard_v2 Application Gateway kan sträcka sig över flera Tillgänglighetszoner, vilket ger bättre felåterhämtning och tar bort behovet av att etablera separata Application Gateways i varje zon.

Statisk VIP

Programgatewayen Standard_v2 SKU stöder endast statisk VIP-typ. Detta säkerställer att VIP:en som är associerad med programgatewayen inte ändras ens under Application Gateways livslängd.

Brandvägg för webbaserade program

Web Application Firewall (WAF) är en tjänst som ger ett centraliserat skydd av dina webbprogram mot vanliga sårbarheter och sårbarheter. WAF baseras på regler från OWASP-huvudregeluppsättningarna 3.1 (endast WAF_v2), 3.0 och 2.2.9.

Webbprogram blir i allt större utsträckning föremål för attacker där kända svagheter i programmen utnyttjas. Bland annat är SQL-inmatningsattacker och skriptangrepp mellan webbplatser vanliga. Det kan vara svårt att förhindra sådana attacker i programkoden och kräver ofta omfattande underhåll, korrigeringar och övervakning av många skikt i programtopologin. Med en centraliserad brandvägg för webbaserade program blir det enklare att hantera säkerheten och programadministratörer får bättre möjligheter skydda mot intrång. En brandväggslösning för webbaserade program kan även reagera snabbare på ett säkerhetshot genom att åtgärda en känd svaghet på en central plats jämfört med om korrigeringar ska utföras i varje enskilt webbprogram. Befintliga programgatewayer kan enkelt konverteras till en brandväggsaktiverad programgateway för webbaserade program.

Mer information om hur du använder Azure WAF med Application Gateway för att skydda mot DDoS-attacker finns i Application DDoS-skydd. Mer information finns i Vad är Azure Web Application Firewall.

Ingress-kontrollant för AKS

Med Application Gateway Ingress Controller (AGIC) kan du använda Application Gateway som ingress för ett AkS-kluster (Azure Kubernetes Service).

Ingresskontrollanten körs som en podd i AKS-klustret och använder Kubernetes-ingressresurser och konverterar dem till en Application Gateway-konfiguration, vilket gör att gatewayen kan belastningsutjämna trafik till Kubernetes-poddarna. Ingresskontrollanten stöder endast Application Gateway-Standard_v2 och WAF_v2 SKU:er.

Mer information finns i Application Gateway Ingress Controller (AGIC).

URL-baserad routning

Med url-sökvägsbaserad routning kan du dirigera trafik till serverdelsserverpooler baserat på URL-sökvägar för begäran. Ett av scenarierna är att dirigera begäranden för olika innehållstyper till olika pooler.

Till exempel dirigeras begäranden för http://contoso.com/video/* till VideoServerPool och http://contoso.com/images/* dirigeras till ImageServerPool. DefaultServerPool väljs om inget av sökvägsmönstren matchar.

Mer information finns i Översikt över url-sökvägsbaserad routning.

Värd för flera platser

Med Application Gateway kan du konfigurera routning baserat på värdnamn eller domännamn för mer än ett webbprogram på samma programgateway. Den här funktionen gör att du kan konfigurera en mer effektiv topologi för dina distributioner genom att lägga till fler än 100 webbplatser i samma appgateway. Varje webbplats kan dirigeras till en egen serverdelspool. Tänk dig till exempel att de tre domänerna contoso.com, fabrikam.com och adatum.com pekar på appgatewayens IP-adress. Du skapar tre lyssnare för flera platser och konfigurerar varje lyssnare enligt respektive inställningar för port och protokoll.

Begäranden för http://contoso.com dirigeras till ContosoServerPool, http://fabrikam.com dirigeras till FabrikamServerPool och så vidare.

På samma sätt kan två underdomäner i samma överordnade domän finnas på samma distribution av en programgateway. Exempel på användning av underdomäner kan vara http://blog.contoso.com och http://app.contoso.com på samma distribution av en programgateway. Mer information finns i Application Gateway för flera webbplatser.

Du kan också definiera värdnamn med jokertecken i lyssnare för flera platser och upp till 5 värdnamn per lyssnare. Mer information finns i värdnamn med jokertecken i lyssnaren.

Omdirigering

Ett vanligt scenario för många webbappar är att stödja automatisk HTTP till HTTPS-omdirigering för att säkerställa att all kommunikation mellan en app och dess användare sker via en krypterad sökväg.

Tidigare kan du ha använt tekniker som att skapa dedikerade pooler vars enda syfte är att omdirigera begäranden som den tar emot på HTTP till HTTPS. Application Gateway stöder möjligheten att omdirigera trafik på programgatewayen. Detta förenklar programkonfigurationen, optimerar resursanvändningen och stöder nya omdirigeringsscenarier, inklusive global och sökvägsbaserade omdirigering. Omdirigeringsstöd för Application Gateway är inte begränsat till HTTP till HTTPS-omdirigering ensamt. Det här är en allmän mekanism för omdirigering, så du kan omdirigera från och till valfri port som du anger med regler. Den har även stöd för omdirigering till en extern plats.

Stöd för Application Gateway-stöd har följande funktioner:

  • Global omdirigering från en port till en annan port på gatewayen. Det möjliggör HTTP till HTTPS-omdirigering på en webbplats.
  • Sökvägsbaserad omdirigering. Den här typen av omdirigering möjliggör bara HTTP till HTTPS-omdirigering på ett specifikt webbplatsområde, till exempel en kundvagn som betecknas av /cart/*.
  • Omdirigera till en extern webbplats.

Mer information finns i Översikt över omdirigering av Application Gateway.

Sessionstillhörighet

Den cookie-baserade sessionstillhörighetsfunktionen är användbar när du vill behålla en användarsession på samma server. Med gatewayhanterade cookies kan Application Gateway dirigera efterföljande trafik från en användarsession till samma server för bearbetning. Det här är viktigt i de fall där sessionstillstånd har sparats lokalt på servern för en användarsession.

Mer information finns i Så här fungerar en programgateway.

Websocket- och HTTP/2-trafik

Application Gateway har inbyggt stöd för WebSocket- och HTTP/2-protokoll. Det finns inga inställningar som kan konfigureras av användaren för att selektivt aktivera eller inaktivera WebSocket-stöd.

WebSocket- och HTTP/2-protokollen aktiverar full duplex-kommunikation mellan en server och en klient över en tidskrävande TCP-anslutning. Det här tillåter en mer interaktiv kommunikation mellan webbservern och klienten, som kan vara dubbelriktad utan att behöva avsökning som krävs i HTTP-baserade implementeringar. Dessa protokoll har låga omkostnader, till skillnad från HTTP, och kan återanvända samma TCP-anslutning för flera begäranden/svar, vilket resulterar i en effektivare resursanvändning. Dessa protokoll är utformade att fungera via de traditionella HTTP-portarna 80 och 443.

Mer information finns i WebSocket-stöd och HTTP/2-stöd.

Anslutningstömning

Anslut jondränering hjälper dig att få en korrekt borttagning av medlemmar i serverdelspoolen under planerade tjänstuppdateringar eller problem med serverdelshälsan. Den här inställningen är aktiverad via serverdelsinställningen och tillämpas på alla medlemmar i serverdelspoolen när regeln skapas. När den är aktiverad ser programgatewayen till att alla avregistreringsinstanser av en serverdelspool inte tar emot några nya begäranden samtidigt som befintliga begäranden kan slutföras inom en konfigurerad tidsgräns. Det gäller för fall där serverdelsinstanser är:

  • tas uttryckligen bort från serverdelspoolen efter en konfigurationsändring av en användare
  • rapporteras som inte felfri av hälsoavsökningarna, eller
  • tas bort under en inskalningsåtgärd

Det enda undantaget är när begäranden fortsätter att vidarebefordras till avregistreringsinstanserna på grund av gatewayhanterad sessionstillhörighet.

Anslutningstömningen respekteras även för WebSocket-anslutningar. Anslut jondränering anropas för varje enskild uppdatering av gatewayen. Om du vill förhindra anslutningsförlust för befintliga medlemmar i serverdelspoolen måste du aktivera anslutningsdränering.

Information om tidsgränser finns i Serverdel Inställningar konfiguration.

Anpassade felsidor

Med Application Gateway kan du skapa anpassade felsidor i stället för att visa standardmässiga felsidor. Du kan använda din egen varumärkesanpassning och layout med hjälp av en anpassad felsida.

Mer information finns i Anpassade fel.

Skriva om HTTP-huvuden och URL

MED HTTP-huvuden kan klienten och servern skicka ytterligare information med begäran eller svaret. Om du skriver om dessa HTTP-huvuden kan du utföra flera viktiga scenarier, till exempel:

  • Lägga till säkerhetsrelaterade rubrikfält som HSTS/X-XSS-Protection.
  • Tar bort fält för svarshuvud som kan visa känslig information.
  • Ta bort portinformation från X-Forwarded-For-huvuden.

Application Gateway och WAF v2 SKU stöder möjligheten att lägga till, ta bort eller uppdatera HTTP-begärande- och svarshuvuden, medan begärande- och svarspaketen flyttas mellan klient- och serverdelspoolerna. Du kan också skriva om URL:er, frågesträngsparametrar och värdnamn. Med url-omskrivning och URL-sökvägsbaserad routning kan du välja att antingen dirigera begäranden till en av serverdelspoolerna baserat på den ursprungliga sökvägen eller den omskrivna sökvägen med alternativet omvärdera sökvägskarta.

Det ger dig också möjlighet att lägga till villkor så att de angivna huvudena eller URL bara skrivs om när vissa villkor uppfylls. Dessa villkor baseras på informationen för begäran och svar.

Mer information finns i Skriva om HTTP-huvuden och URL.

Beräkning

Application Gateway-Standard_v2 kan konfigureras för automatisk skalning eller distribution av fast storlek. V2 SKU erbjuder inte olika instansstorlekar. Mer information om prestanda och priser för v2 finns i Autoskalning V2 och Förstå priser.

Application Gateway Standard (v1) erbjuds i tre storlekar: Small, Medium och Large. Smål instansstorlekar är avsedda för utvecklings- och testningsscenarier.

En fullständig lista över gränserna för programgateways finns i avsnittet om gränser för Application Gateway-tjänsten.

I följande tabell visas ett genomsnittligt prestandadataflöde för varje application gateway v1-instans med SSL-avlastning aktiverat:

Genomsnittlig svarsstorlek för serverdelssidan Litet Medel Stort
6 kB 7.5 Mbit/s 13 Mbit/s 50 Mbit/s
100 kB 35 Mbit/s 100 Mbit/s 200 Mbit/s

Kommentar

De här värdena är genomsnittliga värden för ett Application Gateway-dataflöde. Det faktiska dataflödet beror på olika miljöinformation, till exempel genomsnittlig sidstorlek, plats för serverdelsinstanser och bearbetningstid för att hantera en sida. Du bör köra egna test för exakta prestandavärden. Dessa värden är bara för vägledning vid kapacitetsplanering.

Jämförelse av versionsfunktioner

En funktionsjämförelse för Application Gateway v1-v2 finns i Vad är Azure Application Gateway v2.

Nästa steg