Componentes do gateway de aplicação

2025-05-21

Um gateway de aplicativo serve como o único ponto de contato para os clientes. Ele distribui o tráfego de entrada de aplicativos em vários pools de back-end, que incluem VMs do Azure, conjuntos de dimensionamento de máquinas virtuais, Serviço de Aplicativo do Azure e servidores locais/externos. Para distribuir o tráfego, um gateway de aplicativo usa vários componentes descritos neste artigo.

Os componentes usados em um gateway de aplicativo

Endereços IP-frontend

Um endereço IP frontend é o endereço IP associado a um gateway de aplicativo. Você pode configurar um gateway de aplicativo para ter um endereço IP público, um endereço IP privado ou ambos. Um gateway de aplicativo suporta um endereço IP público ou privado. A rede virtual e o endereço IP público devem estar no mesmo local que o gateway de aplicativo. Depois de criado, um endereço IP frontend é associado a um ouvinte.

Endereço IP público estático versus dinâmico

O SKU do Gateway de Aplicativo do Azure V2 pode ser configurado para dar suporte ao endereço IP interno estático e ao endereço IP público estático ou apenas ao endereço IP público estático. Não pode ser configurado para suportar apenas o endereço IP interno estático.

O SKU V1 pode ser configurado para suportar endereço IP interno estático ou dinâmico e endereço IP público dinâmico. O endereço IP dinâmico do Application Gateway não é alterado em um gateway em execução. Pode mudar apenas quando parares ou começares o Gateway. Ele não muda em falhas do sistema, atualizações, atualizações de host do Azure, etc.

O nome DNS associado a um gateway de aplicativo não é alterado ao longo do ciclo de vida do gateway. Como resultado, você deve usar um alias CNAME e apontá-lo para o endereço DNS do gateway de aplicativo.

Ouvintes

Um ouvinte é uma entidade lógica que verifica solicitações de ligação entrantes. Um ouvinte aceita uma solicitação se o protocolo, a porta, o nome do host e o endereço IP associados à solicitação corresponderem aos mesmos elementos associados à configuração do ouvinte.

Antes de usar um gateway de aplicativo, você deve adicionar pelo menos um ouvinte. Pode haver vários ouvintes conectados a um gateway de aplicativo e eles podem ser usados para o mesmo protocolo.

Depois que um ouvinte deteta solicitações de entrada de clientes, o gateway de aplicativo roteia essas solicitações para membros no pool de back-end configurado na regra.

Os ouvintes suportam as seguintes portas e protocolos.

Portos

Uma porta é onde um ouvinte escuta a solicitação do cliente. Você pode configurar portas para SKUs v1 e v2 conforme abaixo.

Referência de Produto	Intervalo de portas suportado	Exceção(ões)
V2	1 a 64999	22, 53
V1	1 a 65502	3389

Protocolos

O Application Gateway fornece suporte para protocolos da Web HTTP, HTTPS, HTTP/2 e WebSocket por meio de seu proxy de Camada 7. Além disso, suporta protocolos TLS e TCP através do seu proxy de Camada 4 na Pré-visualização, que pode ser configurado no mesmo recurso.

Escolha entre os protocolos HTTP, HTTPS, TLS ou TCP na configuração do ouvinte.
Você pode usar um ouvinte HTTPS ou TLS para terminação TLS. Um ouvinte HTTPS/TLS descarrega o trabalho de criptografia e descriptografia para o seu gateway de aplicações, evitando que os seus servidores fiquem sobrecarregados pela sobrecarga de computação TLS.
O suporte para WebSockets e protocolos HTTP/2 é fornecido nativamente, e o suporte a WebSocket é habilitado por padrão. Não existe qualquer definição configurável pelo utilizador para ativar ou desativar seletivamente o suporte de WebSocket. Utilize WebSockets com ouvintes HTTP e HTTPS.

Observação

O suporte ao protocolo HTTP/2 está disponível apenas para clientes que se conectam a escutadores do gateway de aplicação. A comunicação com pools de servidores back-end é sempre via HTTP/1.1. Por padrão, o suporte a HTTP/2 está desativado. Você pode optar por ativá-lo.

Páginas de erro personalizadas

O Application Gateway permite criar páginas de erro personalizadas em vez de exibir páginas de erro padrão. Você pode usar sua própria marca e layout usando uma página de erro personalizada. O Application Gateway exibe uma página de erro personalizada quando uma solicitação não consegue chegar ao back-end.

Para obter mais informações, consulte Páginas de erro personalizadas para seu gateway de aplicativo.

Tipos de ouvintes

Existem dois tipos de ouvintes:

Básico. Esse tipo de ouvinte escuta um único site de domínio, onde tem um único mapeamento DNS para o endereço IP do gateway de aplicativo. Esta configuração de escuta é necessária quando se hospeda um único site atrás de um gateway de aplicação.
Multi-site. Essa configuração de ouvinte é necessária quando pretendas configurar o roteamento com base no nome do host ou nome de domínio para mais de uma aplicação web no mesmo gateway de aplicações. 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 pool de servidores. Por exemplo, três domínios, contoso.com, fabrikam.com e adatum.com, apontam para o endereço IP do gateway de aplicação. Você criaria três ouvintes multissite e configuraria cada ouvinte para a respetiva configuração de porta e protocolo.

Além disso, pode definir nomes de anfitrião coringa num ouvinte multi-site e até cinco nomes de anfitrião por ouvinte. Para saber mais, consulte Nomes de host coringa no escutador.

Para obter mais informações sobre como configurar uma escuta multissítio, consulte Hospedagem de múltiplos sites no Gateway de Aplicações usando o portal do Azure.

Depois de criar um ouvinte, associe-o a uma regra de roteamento de solicitação. Esta regra determina como a solicitação recebida no escutador deve ser encaminhada para o back-end. A regra de roteamento de solicitação também contém o pool de back-end, para onde ser roteado, e a configuração HTTP onde são mencionados a porta de back-end, o protocolo, etc.

Pedir regras de encaminhamento

Uma regra de roteamento de solicitação é um componente fundamental de um gateway de aplicativo porque determina como rotear o tráfego no ouvinte. A regra vincula o ouvinte, o pool de servidores de back-end e as configurações HTTP de back-end.

Quando um ouvinte aceita uma solicitação, a regra de roteamento de solicitação encaminha a solicitação para o back-end ou a redireciona para outro lugar. Se a solicitação for encaminhada para o back-end, a regra de roteamento de solicitação definirá para qual pool de servidores back-end encaminhá-la. A regra de roteamento de solicitação também determina se os cabeçalhos na solicitação devem ser reescritos. Um ouvinte pode ser ligado a uma regra.

Há dois tipos de regras de roteamento de solicitação:

Básico. Todas as solicitações no ouvinte associado (por exemplo, blog.contoso.com/*) são encaminhadas para o pool de back-end associado usando a configuração HTTP associada.
Baseado em percurso. Essa regra de roteamento permite rotear as solicitações no ouvinte associado para um pool de back-end específico, com base na URL da solicitação. Se o caminho da URL em uma solicitação corresponder ao padrão de caminho em uma regra baseada em caminho, a regra roteia essa solicitação. Ele aplica o padrão de caminho somente ao caminho da URL, não aos seus parâmetros de consulta. Se o caminho da URL em uma solicitação de ouvinte não corresponder a nenhuma das regras baseadas em caminho, ele roteia a solicitação para o pool de back-end padrão e as configurações HTTP.

Para obter mais informações, consulte Roteamento baseado em URL.

Suporte de redirecionamento

A regra de roteamento de solicitação também permite redirecionar o tráfego no gateway de aplicativo. Este é um mecanismo de redirecionamento genérico, para que você possa redirecionar de e para qualquer porta definida usando regras.

Você pode escolher o destino de redirecionamento para ser outro ouvinte (o que pode ajudar a habilitar o redirecionamento automático de HTTP para HTTPS) ou um site externo. Você também pode optar por fazer com que o redirecionamento seja temporário ou permanente, ou acrescentar o caminho do URI e a cadeia de caracteres de consulta à URL redirecionada.

Para obter mais informações, consulte Redirecionar o tráfego no gateway de aplicativo.

Rescrever cabeçalhos HTTP e URL

Usando regras de reescrita, você pode adicionar, remover ou atualizar cabeçalhos de solicitação e resposta HTTP(S), bem como parâmetros de caminho de URL e cadeia de caracteres de consulta à medida que os pacotes de solicitação e resposta se movem entre o cliente e os pools de back-end por meio do gateway de aplicativo.

Os cabeçalhos e parâmetros de URL podem ser definidos como valores estáticos ou para outros cabeçalhos e variáveis de servidor. Isso ajuda em casos de uso importantes, como extrair endereços IP de clientes, remover informações confidenciais sobre o back-end, adicionar mais segurança e assim por diante.

Para obter mais informações, consulte Reescrever cabeçalhos HTTP e URL no gateway de aplicativo.

Configurações HTTP

Um gateway de aplicativo roteia o tráfego para os servidores back-end (especificados na regra de roteamento de solicitação que incluem configurações HTTP) usando o número da porta, o protocolo e outras configurações detalhadas neste componente.

A porta e o protocolo usados nas configurações HTTP determinam se o tráfego entre o gateway de aplicativo e os servidores back-end é criptografado (fornecendo TLS de ponta a ponta) ou não criptografado.

Este componente também é usado para:

Determine se uma sessão de usuário deve ser mantida no mesmo servidor usando a afinidade de sessão baseada em cookie.
Remova elegantemente os membros do pool de back-end usando a drenagem de conexão.
Associe uma sonda personalizada para monitorar a integridade do back-end, defina o intervalo de tempo limite da solicitação, substitua o nome do host e o caminho na solicitação e forneça facilidade com um clique para especificar configurações para o back-end do Serviço de Aplicativo.

Conjuntos de back-end

Um pool de back-end roteia a solicitação para servidores back-end, que atendem à solicitação. Os pools de back-end podem conter:

NICs
Conjuntos de escala de máquinas virtuais
Endereços IP públicos
Endereços IP internos
Nome de Domínio Totalmente Qualificado (FQDN)
Back-ends multilocatários (como o App Service)

Os membros do pool de back-end do Application Gateway não estão vinculados a um conjunto de disponibilidade. Um gateway de aplicativo pode se comunicar com instâncias fora da rede virtual em que está. Como resultado, os membros dos pools de back-end podem estar entre clusters, datacenters ou fora do Azure, desde que haja conectividade IP.

Se utilizar IPs internos como membros do pool de back-end, deverá usar o emparelhamento de rede virtual ou um gateway VPN. O pareamento de rede virtual é suportado e beneficia o balanceamento de carga de tráfego em outras redes virtuais.

Um gateway de aplicativo também pode se comunicar com servidores locais quando eles estão conectados por túneis do Azure ExpressRoute ou VPN, se o tráfego for permitido.

Você pode criar diferentes pools de back-end para diferentes tipos de solicitações. Por exemplo, crie um pool de back-end para solicitações gerais e, em seguida, outro pool de back-end para solicitações aos microsserviços de seu aplicativo.

Depois de adicionar conjuntos de dimensionamento de máquina virtual como um membro do pool de back-end, você precisa atualizar instâncias de conjuntos de dimensionamento de máquina virtual. Até que atualize as instâncias dos conjuntos de escala, o backend não estará saudável.

Sondas de saúde

Por padrão, um gateway de aplicativo monitora a integridade de todos os recursos em seu pool de back-end e remove automaticamente os não íntegros. Em seguida, ele monitora instâncias não íntegras e as adiciona de volta ao pool de back-end íntegro quando elas ficam disponíveis e respondem a testes de integridade.

Além de usar o monitoramento de teste de integridade padrão, você também pode personalizar o teste de integridade para atender aos requisitos do seu aplicativo. As sondas personalizadas permitem um controle mais granular sobre o monitoramento de saúde. Ao utilizar sondas personalizadas, pode configurar um nome de host personalizado, caminho de URL, intervalo das sondas, e o número de respostas falhadas aceitáveis antes de marcar a instância do pool de back-end como não saudável, bem como códigos de status personalizados e correspondência do corpo da resposta, etc. Recomendamos que configure sondas personalizadas para monitorizar a saúde de cada pool de back-end.

Para obter mais informações, consulte Monitorar a integridade do gateway de aplicativo.

Próximos passos

Crie um gateway de aplicativo: