Funzionalità di gateway applicazione di Azure

Il gateway applicazione di Azure è un servizio di bilanciamento del carico del traffico Web che consente di gestire il traffico verso le applicazioni Web.

Concetti relativi al gateway applicazione

Il gateway applicazione include le funzionalità seguenti:

Terminazione Secure Sockets Layer (SSL/TLS)

Il gateway applicazione supporta la terminazione SSL/TLS nel gateway, dopo la quale il traffico scorre generalmente non crittografato verso i server back-end. Questa funzionalità consente ai server Web di non gestire il costoso carico di crittografia e decrittografia. Ma a volte la comunicazione non crittografata con i server non è un'opzione accettabile. Questo può dipendere dai requisiti di sicurezza e conformità o dal fatto che l'applicazione può accettare solo connessioni sicure. Per queste applicazioni, il gateway applicazione supporta la crittografia SSL/TLS end-to-end.

Per altre informazioni, vedere Panoramica della terminazione SSL e ssl end-to-end con gateway applicazione

Scalabilità automatica

gateway applicazione Standard_v2 supporta la scalabilità automatica e può aumentare o ridurre le prestazioni in base alla modifica dei modelli di carico del traffico. La scalabilità automatica elimina anche la necessità di scegliere un numero di istanze o le dimensioni della distribuzione durante il provisioning.

Per altre informazioni sulle funzionalità di gateway applicazione Standard_v2, vedere Che cos'è gateway applicazione di Azure v2?.

Ridondanza della zona

Un Standard_v2 gateway applicazione può estendersi su più zone di disponibilità, offrendo una migliore resilienza degli errori e rimuovendo la necessità di effettuare il provisioning di gateway applicazione separati in ogni zona.

Indirizzo VIP statico

Il gateway applicazione Standard_v2 SKU supporta esclusivamente il tipo di indirizzo VIP statico. Questa funzionalità garantisce che l'indirizzo VIP associato al gateway applicazione non cambi nel corso del ciclo di vita del gateway applicazione.

Web application firewall

Web application firewall (WAF) è un servizio che fornisce protezione centralizzata delle applicazioni Web da exploit e vulnerabilità comuni. WAF si basa sulle regole del core OWASP (Open Web Application Security Project) imposta 3.1 (solo WAF_v2), 3.0 e 2.2.9.

Le applicazioni Web sono sempre più vittime di attacchi che sfruttano le più comuni vulnerabilità note. Per citarne alcuni, tra i più comuni troviamo gli attacchi SQL injection e gli attacchi di scripting intersito. Impedire questo tipo di attacchi nel codice dell'applicazione può essere un'operazione complessa e potrebbe richiedere una manutenzione rigorosa, l'applicazione di patch e il monitoraggio a più livelli della topologia dell'applicazione. Un Web application firewall centralizzato semplifica notevolmente la gestione della sicurezza e offre agli amministratori delle applicazioni migliori garanzie contro le minacce o le intrusioni. Una soluzione WAF è anche in grado di reagire più velocemente a una minaccia alla sicurezza tramite l'applicazione di patch su una vulnerabilità nota in una posizione centrale, anziché proteggere ogni singola applicazione Web. I gateway applicazione esistenti possono essere convertiti in un gateway applicazione abilitato Web application firewall facilmente.

Per altre informazioni, vedere Che cos'è Azure Web Application Firewall?.

Controller di ingresso per il servizio Azure Kubernetes

Il controller di ingresso del gateway applicazione consente di usare il gateway applicazione come ingresso per un cluster del servizio Azure Kubernetes.

Il controller di ingresso viene eseguito come pod all'interno del cluster del servizio Azure Kubernetes e usa le risorse di ingresso kubernetes e le converte in una configurazione gateway applicazione, che consente al gateway di bilanciare il carico del traffico verso i pod Kubernetes. Il controller di ingresso supporta solo gli SKU gateway applicazione Standard_v2 e WAF_v2.

Per altre informazioni, vedere Controller di ingresso del gateway applicazione di Azure.

Routing basato su URL

Routing basato sul percorso URL consente di instradare il traffico ai pool di server back-end in base ai percorsi URL della richiesta. Uno degli scenari è il rounting delle richieste di tipi di contenuto diversi a pool diversi.

Ad esempio, per le richieste http://contoso.com/video/* viene eseguito il rounting verso VideoServerPool mentre per le richieste http://contoso.com/images/* viene eseguito il rounting verso ImageServerPool. In caso di mancata corrispondenza dei percorsi, viene selezionato DefaultServerPool.

Per altre informazioni, vedere Panoramica del routing basato sul percorso URL.

Hosting di più siti

Con gateway applicazione, è possibile configurare il routing in base al nome host o al nome di dominio per più applicazioni Web nello stesso gateway applicazione. Consente di configurare una topologia più efficiente per le distribuzioni aggiungendo fino a più di 100 siti Web a un unico gateway applicazione. Ogni sito Web può essere indirizzato al proprio pool back-end. Ad esempio, tre domini, contoso.com, fabrikam.com e adatum.com, puntano all'indirizzo IP del gateway applicazione. Si creeranno tre listener multisito e si configurerà ogni listener per la rispettiva impostazione della porta e del protocollo.

Le richieste per http://contoso.com vengono instradate a ContosoServerPool, http://fabrikam.com vengono instradate a FabrikamServerPool e così via.

Analogamente, la stessa distribuzione del gateway applicazione può ospitare due sottodomini dello stesso dominio padre. Gli esempi di uso di sottodomini possono includere http://blog.contoso.com e http://app.contoso.com ospitati in una singola distribuzione del gateway applicazione. Per altre informazioni, vedere gateway applicazione hosting di più siti.

È anche possibile definire nomi host con caratteri jolly in un listener multisito e fino a cinque nomi host per ogni listener. Per altre informazioni, vedere Nomi host con caratteri jolly nel listener.

Reindirizzamento

Uno scenario comune per molte applicazioni Web è il supporto del reindirizzamento automatico da HTTP a HTTPS per assicurare che tutte le comunicazioni tra l'applicazione e gli utenti avvengano tramite un percorso crittografato.

È possibile che in passato siano state usate tecniche come la creazione di un pool dedicato il cui unico scopo è quello di reindirizzare le richieste ricevute su HTTP ad HTTPS. Il gateway applicazione consente di reindirizzare il traffico sul gateway applicazione. Questo semplifica la configurazione delle applicazioni, ottimizza l'utilizzo delle risorse e supporta i nuovi scenari di reindirizzamento, tra cui il reindirizzamento globale e basato sul percorso. Il supporto del reindirizzamento nel gateway applicazione non è limitato al solo reindirizzamento da HTTP ad HTTPS. Si tratta di un meccanismo di reindirizzamento generico che consente di eseguire il reindirizzamento da e verso qualsiasi porta definita mediante regole. Supporta anche il reindirizzamento a un sito esterno.

Il supporto del reindirizzamento nel gateway applicazione offre le funzionalità seguenti:

  • Reindirizzamento globale da una porta a un'altra porta nel gateway. che consente il reindirizzamento da HTTP a HTTPS in un sito.
  • Reindirizzamento basato sul percorso. Questo tipo di reindirizzamento consente il reindirizzamento da HTTP a HTTPS solo in un'area specifica del sito, ad esempio l'area del carrello acquisti indicata da /cart/*.
  • Reindirizzamento a un sito esterno.

Per altre informazioni, vedere gateway applicazione panoramica del reindirizzamento.

Affinità di sessione

L'affinità di sessione basata su cookie è utile quando si vuole mantenere una sessione utente nello stesso server. Usando cookie gestiti dal gateway, il gateway applicazione può indirizzare il traffico successivo proveniente da una sessione utente allo stesso server per l'elaborazione. Questo è importante nei casi in cui lo stato della sessione viene salvato in locale sul server per una sessione utente.

Per altre informazioni, vedere Funzionamento di un gateway applicazione.

Traffico Websocket e HTTP/2

Il gateway applicazione offre il supporto nativo per i protocolli WebSocket e HTTP/2. Non esistono impostazioni configurabili dall'utente per abilitare o disabilitare in modo selettivo il supporto di WebSocket.

I protocolli WebSocket HTTP/2 consentono una comunicazione full duplex tra un server e un client su una connessione TCP con esecuzione prolungata. Questo consente una comunicazione più interattiva tra il server Web e il client che può essere bidirezionale senza necessità di polling che invece è richiesto nelle implementazioni basate su HTTP. A differenza del protocollo HTTP, questi protocolli presentano un sovraccarico ridotto e possono riutilizzare la stessa connessione TCP per più richieste/risposte garantendo così un uso più efficiente delle risorse. Questi protocolli sono progettati per usare le porte HTTP 80 e 443 tradizionali.

Per altre informazioni, vedere Supporto per WebSocket e supporto per HTTP/2.

Esaurimento delle connessioni

Lo svuotamento delle connessioni aiuta a rimuovere in modo controllato i membri del pool back-end durante gli aggiornamenti pianificati del servizio. Questa modalità viene abilitata tramite l'impostazione http back-end e può essere applicata a tutti i membri di un pool back-end durante la creazione delle regole. Dopo l'abilitazione, gateway applicazione garantisce che tutte le istanze di un pool back-end non ricevano alcuna nuova richiesta, consentendo al contempo il completamento delle richieste esistenti entro un limite di tempo configurato. Questo vale sia per le istanze back-end che vengono rimosse dal pool back-end in modo esplicito mediante una modifica di configurazione dell'utente, sia per le istanze back-end che vengono segnalate come non integre, come determinato dai probe di integrità. L'unica eccezione a questa è costituita dalle richieste associate per la deregistrazione delle istanze, che sono state annullate in modo esplicito, a causa dell'affinità di sessione gestita dal gateway e continuano a essere inviate tramite proxy alle istanze di deregistrazione.

Per altre informazioni, vedere Panoramica della configurazione di gateway applicazione.

Pagine di errore personalizzate

Il gateway applicazione consente di creare pagine di errore personalizzate da visualizzare al posto delle pagine di errore predefinite. Con una pagina di errore personalizzata è possibile usare il layout e il marchio aziendali.

Per altre informazioni, vedere Errori personalizzati.

Riscrivere l'URL e le intestazioni HTTP

Le intestazioni HTTP consentono al client e al server di passare informazioni aggiuntive insieme alla richiesta o alla risposta. La riscrittura delle intestazioni HTTP consente di affrontare diversi scenari importanti, ad esempio:

  • Aggiunta di campi di intestazione relativi alla sicurezza come HSTS/X-XSS-Protection.
  • Rimozione di campi di intestazione della risposta che possono rivelare informazioni riservate.
  • Rimozione delle informazioni sulle porte dalle intestazioni X-Forwarded-For.

gateway applicazione e SKU WAF v2 supportano la possibilità di aggiungere, rimuovere o aggiornare intestazioni di richiesta e risposta HTTP, mentre i pacchetti di richiesta e risposta si spostano tra i pool client e back-end. È anche possibile riscrivere gli URL, i parametri della stringa di query e il nome host. Con la riscrittura dell'URL e il routing basato sul percorso URL, è possibile scegliere di indirizzare le richieste a uno dei pool back-end in base al percorso originale o al percorso riscritto, usando l'opzione Rivaluta mappa percorso.

Consente anche di aggiungere le condizioni necessarie per garantire che le intestazioni specificate o l'URL vengono riscritti solo in presenza di determinate condizioni. Queste condizioni sono basate sulle informazioni della richiesta e della risposta.

Per altre informazioni, vedere Riscrivere intestazioni HTTP e URL.

Ridimensionamento

gateway applicazione Standard_v2 possono essere configurati per la scalabilità automatica o le distribuzioni a dimensione fissa. Lo SKU v2 non offre dimensioni di istanza diverse. Per altre informazioni sulle prestazioni e sui prezzi v2, vedere Scalabilità automatica V2 e Informazioni sui prezzi.

Il gateway applicazione Standard (v1) è disponibile in tre dimensioni: Small, Medium e Large. Le dimensioni delle istanze piccole sono destinate a scenari di sviluppo e test.

Per un elenco completo dei limiti del gateway applicazione, vedere i limiti del servizio Gateway applicazione.

La tabella seguente illustra una velocità effettiva media delle prestazioni per ogni istanza del gateway applicazione v1 con offload SSL abilitato:

Dimensioni medie della risposta della pagina back-end Small Medio Grande
6 KB 7,5 Mbps 13 Mbps 50 Mbps
100 kB 35 Mbps 100 Mbps 200 Mbps

Nota

Questi valori sono indicazioni approssimative della velocità effettiva di un gateway applicazione. La velocità effettiva dipende da vari dettagli dell'ambiente, ad esempio le dimensioni medie delle pagine, la posizione delle istanze back-end e il tempo di elaborazione per gestire una pagina. Per dati esatti sulle prestazioni, è consigliabile eseguire propri test. Questi valori vengono forniti solo come indicazioni per la pianificazione della capacità.

Confronto delle funzionalità di versione

Per un confronto delle funzionalità gateway applicazione v1-v2, vedere Che cos'è gateway applicazione di Azure v2?.

Passaggi successivi