funcionalidades de Gateway de Aplicação do Azure

Gateway de Aplicação do Azure é um balanceador de carga de tráfego Web que lhe permite gerir o tráfego para as suas aplicações Web.

Gateway de Aplicação conceptual

Gateway de Aplicação inclui as seguintes funcionalidades:

Terminação de Secure Sockets Layer (SSL/TLS)

O gateway de aplicação suporta a terminação SSL/TLS no gateway, após o qual o tráfego normalmente flui sem encriptação para os servidores de back-end. Esta funcionalidade permite que os servidores Web estejam livres de sobrecarga de encriptação e desencriptação dispendiosa. No entanto, por vezes, a comunicação não encriptada para os servidores não é uma opção aceitável. Isto pode dever-se a requisitos de segurança, requisitos de conformidade ou a aplicação só pode aceitar uma ligação segura. Para estas aplicações, o gateway de aplicação suporta encriptação SSL/TLS ponto a ponto.

Para obter mais informações, veja Descrição geral da terminação SSL e SSL ponto a ponto com Gateway de Aplicação

Dimensionamento automático

Gateway de Aplicação Standard_v2 suporta o dimensionamento automático e pode aumentar ou reduzir verticalmente com base na alteração dos padrões de carga de tráfego. O dimensionamento automático também elimina o requisito de escolher um tamanho de implementação ou uma contagem de instâncias ou durante o aprovisionamento.

Para obter mais informações sobre as funcionalidades de Gateway de Aplicação Standard_v2, consulte O que é Gateway de Aplicação do Azure v2?.

Redundância entre zonas

Uma Standard_v2 Gateway de Aplicação pode abranger vários Zonas de Disponibilidade, oferecendo uma melhor resiliência de falhas e removendo a necessidade de aprovisionar Gateways de Aplicação separados em cada zona.

VIP Estático

O gateway de aplicação Standard_v2 SKU suporta exclusivamente o tipo VIP estático. Isto garante que o VIP associado ao gateway de aplicação não muda mesmo ao longo da duração do Gateway de Aplicação.

Firewall de Aplicações Web

Firewall de Aplicações Web (WAF) é um serviço que fornece proteção centralizada das suas aplicações Web contra exploits e vulnerabilidades comuns. A WAF baseia-se em regras dos conjuntos de regras principais OWASP (Open Web Application Security Project) 3.1 (apenas WAF_v2), 3.0 e 2.2.9.

Cada vez mais, as aplicações Web são alvo de ataques maliciosos que exploram vulnerabilidades conhecidas comuns. Destas vulnerabilidades, são frequentes os ataques de injeção de SQL, scripting entre sites, entre muitas outras. Impedir este tipo de ataques ao código das aplicações constitui um desafio e exige uma manutenção, correção e monitorização rigorosas em muitas camadas da topologia da aplicação. Uma firewall de aplicações Web centralizada ajuda a simplificar em muito a gestão da segurança e confere aos administradores de aplicações uma maior garantia de proteção contra as ameaças ou intrusões. Uma solução WAF também pode reagir mais rapidamente a uma ameaça de segurança ao corrigir uma vulnerabilidade conhecida numa localização central, em vez de proteger cada uma das aplicações Web individualmente. Os gateways de aplicação existentes podem ser convertidos num gateway de aplicação Firewall de Aplicações Web facilmente ativado.

Para obter mais informações, consulte O que é o Azure Firewall de Aplicações Web?.

Controlador de Entrada para AKS

Gateway de Aplicação Controlador de Entrada (AGIC) permite-lhe utilizar Gateway de Aplicação como entrada de um cluster de Azure Kubernetes Service (AKS).

O controlador de entrada é executado como um pod no cluster do AKS e consome Recursos de Entrada do Kubernetes e converte-os numa configuração de Gateway de Aplicação, o que permite que o gateway balancee o tráfego para os pods do Kubernetes. O controlador de entrada só suporta SKUs Gateway de Aplicação Standard_v2 e WAF_v2.

Para obter mais informações, veja Gateway de Aplicação Controlador de Entrada (AGIC).

Encaminhamento com base no URL

O Encaminhamento Baseado no Caminho do URL permite-lhe encaminhar o tráfego para conjuntos de servidores de back-end com base nos Caminhos de URL do pedido. Um dos cenários consiste em encaminhar pedidos de diferentes tipos de conteúdo para diferentes agrupamentos.

Por exemplo, os pedidos de http://contoso.com/video/* são encaminhados para VideoServerPool e os pedidos de http://contoso.com/images/* são encaminhados para ImageServerPool. É selecionado o DefaultServerPool se nenhum dos padrões de caminho corresponder.

Para obter mais informações, veja Descrição geral do Encaminhamento Baseado no Caminho do URL.

Alojamento de vários sites

Com Gateway de Aplicação, pode configurar o encaminhamento com base no nome de anfitrião ou nome de domínio para mais do que uma aplicação Web no mesmo gateway de aplicação. Permite-lhe configurar uma topologia mais eficiente para as implementações ao adicionar até 100 sites a um gateway de aplicação. Cada site pode ser direcionado para o seu próprio agrupamento de back-end. Por exemplo, três domínios, contoso.com, fabrikam.com e adatum.com, apontam para o endereço IP do gateway de aplicação. Teria de criar três serviços de escuta com vários sites e configurar cada serviço de escuta para a respetiva definição de porta e protocolo.

Os pedidos para http://contoso.com são encaminhados para ContosoServerPool, http://fabrikam.com são encaminhados para FabrikamServerPool e assim sucessivamente.

Da mesma forma, dois subdomínios do mesmo domínio principal podem ser alojados na mesma implementação do gateway de aplicação. Exemplos de como utilizar subdomínios podem incluir http://blog.contoso.com e http://app.contoso.com alojados numa única implementação do gateway de aplicação. Para obter mais informações, veja Gateway de Aplicação alojamento de vários sites.

Além disso, pode definir nomes de anfitrião de caráter universal num serviço de escuta com vários sites e até cinco nomes de anfitrião por serviço de escuta. Para saber mais, veja nomes de anfitriões universais no serviço de escuta.

Redirecionamento

Um cenário comum para muitas aplicações Web consiste em suportar o redirecionamento automático de HTTP para HTTPS para garantir que toda a comunicações entre uma aplicação e os seus utilizadores ocorre através de um caminho encriptado.

No passado, pode ter utilizado técnicas como a criação de conjuntos dedicados cujo único objetivo é redirecionar os pedidos que recebe em HTTP para HTTPS. O gateway de aplicação suporta a capacidade de redirecionar o tráfego no Gateway de Aplicação. Isto simplifica a configuração da aplicação, otimiza a utilização de recursos e suporta novos cenários de redirecionamento, incluindo o redirecionamento global e com base no caminho. Gateway de Aplicação o suporte de redirecionamento não está limitado apenas ao redirecionamento HTTP para HTTPS. Trata-se de um mecanismo de redirecionamento genérico, para que possa redirecionar de e para qualquer porta que define através de regras. Também suporta o redirecionamento para um site externo.

O suporte de redirecionamento do Gateway de Aplicação oferece as seguintes capacidades:

  • Redirecionamento global de uma porta para outra porta no Gateway. Isto permite o redirecionamento de HTTP para HTTPS num site.
  • Redirecionamento com base no caminho. Este tipo de redirecionamento permite o redirecionamento de HTTP para HTTPS apenas numa área específica de um site, por exemplo, uma área de carrinho de compras indicada por /cart/*.
  • Redirecionar para um site externo.

Para obter mais informações, veja Gateway de Aplicação descrição geral do redirecionamento.

Afinidade de sessão

A funcionalidade de afinidade de sessão com base em cookies é útil quando pretende manter uma sessão de utilizador no mesmo servidor. Com cookies geridos pelo gateway, o Gateway de Aplicação pode direcionar o tráfego subsequente de uma sessão de utilizador para o mesmo servidor para processamento. Isto é importante nos casos em que o estado da sessão é guardado localmente no servidor para uma sessão de utilizador.

Para obter mais informações, veja Como funciona um gateway de aplicação.

Tráfego de Websocket e HTTP/2

O Gateway de Aplicação fornece suporte nativo para os protocolos WebSocket e HTTP/2. Não existe qualquer definição configurável pelo utilizador para ativar ou desativar seletivamente o suporte de WebSocket.

Os protocolos WebSocket e HTTP/2 ativam a comunicação duplex completa entre um servidor e um cliente através de uma ligação TCP de execução longa. Isto permite uma comunicação mais interativa entre o servidor Web e o cliente, que pode ser bidirecional sem necessidade de consulta, que é necessária em implementações com base em HTTP. Estes protocolos têm uma sobrecarga baixa, ao contrário de HTTP, e podem reutilizar a mesma ligação TCP para vários pedidos/respostas, o que resulta numa utilização de recursos mais eficiente. Estes protocolos foram concebidos para funcionar através das portas HTTP tradicionais 80 e 443.

Para obter mais informações, consulte Suporte webSocket e suporte HTTP/2.

Drenagem de ligação

A drenagem de ligações ajuda-o a obter uma remoção correta dos membros do conjunto de back-end durante as atualizações planeadas do serviço ou problemas com o estado de funcionamento do back-end. Esta definição é ativada através da Definição de Back-end e é aplicada a todos os membros do conjunto de back-end durante a criação da regra. Depois de ativado, o gateway de aplicação garante que todas as instâncias de registo de um conjunto de back-end não recebem novos pedidos, permitindo que os pedidos existentes sejam concluídos dentro de um limite de tempo configurado. Aplica-se a casos em que as instâncias de back-end são:

  • removido explicitamente do conjunto de back-end após uma alteração de configuração por um utilizador
  • reportado como em mau estado de funcionamento pelas sondas de estado de funcionamento, ou
  • removido durante uma operação de dimensionamento

A única exceção é quando os pedidos continuam a ser proxiados para as instâncias de registo devido à afinidade de sessão gerida pelo gateway.

A drenagem da ligação também é honrada para ligações WebSocket. A drenagem de ligações é invocada para cada atualização ao gateway. Para evitar a perda de ligação para os membros existentes do conjunto de back-end, certifique-se de que ativa a drenagem da ligação.

Para obter informações sobre os limites de tempo, veja Configuração de Definições de Back-end.

Páginas de erro personalizadas

O Gateway de Aplicação permite-lhe criar páginas de erro personalizadas, em vez de apresentar as páginas de erro predefinidas. Pode utilizar a sua própria imagem e esquema corporativos através de uma página de erro personalizada.

Para obter mais informações, veja Erros Personalizados.

Rescrever cabeçalhos HTTP e URL

Os cabeçalhos HTTP permitem que o cliente e o servidor transmitam informações adicionais com o pedido ou a resposta. Reescrever estes cabeçalhos HTTP ajuda-o a realizar vários cenários importantes, tais como:

  • Adicionar campos de cabeçalho relacionados com segurança, como HSTS/ X-XSS-Protection.
  • Remover campos de cabeçalho de resposta que podem revelar informações confidenciais.
  • Despojando as informações de porta dos cabeçalhos X-Forwarded-For.

Gateway de Aplicação e o SKU WAF v2 suportam a capacidade de adicionar, remover ou atualizar cabeçalhos de pedido e resposta HTTP, enquanto os pacotes de pedidos e respostas se movem entre os conjuntos de cliente e back-end. Também pode reescrever os URLs, os parâmetros de cadeia de consulta e o nome do anfitrião. Com a reescrita de URL e o encaminhamento baseado no caminho do URL, pode optar por encaminhar pedidos para um dos conjuntos de back-end com base no caminho original ou no caminho reescrito, utilizando a opção reavaliar o mapa de caminho.

Além disso, permite-lhe adicionar condições para garantir que os cabeçalhos ou URLs especificados são reescritos apenas quando forem cumpridas determinadas condições. Estas condições baseiam-se nas informações do pedido e da resposta.

Para obter mais informações, veja Reescrever cabeçalhos HTTP e URL.

Dimensionamento

Gateway de Aplicação Standard_v2 pode ser configurado para implementações de dimensionamento automático ou de tamanho fixo. O SKU v2 não oferece tamanhos de instância diferentes. Para obter mais informações sobre o desempenho e os preços v2, veja Dimensionamento automático V2 e Compreender os preços.

O Gateway de Aplicação Standard (v1) é oferecido em três tamanhos: Pequeno, Médio e Grande. Os tamanhos de instâncias pequenas destinam-se a cenários de testes e desenvolvimento.

Para obter uma lista completa dos limites do gateway de aplicação, veja limites do serviço Gateway de Aplicação.

A tabela seguinte mostra um débito de desempenho médio para cada instância do gateway de aplicação v1 com a descarga de SSL ativada:

Tamanho médio da resposta da página de back-end Pequeno Médio Grande
6 KB 7.5 Mbps 13 Mbps 50 Mbps
100 KB 35 Mbps 100 Mbps 200 Mbps

Nota

Estes valores são valores aproximados para um débito de gateway de aplicação. O débito real depende de vários detalhes do ambiente, como o tamanho médio da página, a localização das instâncias de back-end e o tempo de processamento para servir uma página. Para números de desempenho exatos, deve executar o seus próprios testes. Estes valores são fornecidos apenas para a capacidade orientação de planeamento.

Comparação de funcionalidades de versão

Para obter um Gateway de Aplicação comparação de funcionalidades v1-v2, consulte O que é Gateway de Aplicação do Azure v2?.

Passos seguintes