Uma configuração típica para implantar um aplicativo WSGI inclui um servidor WSGI (como uWSGI ou Gunicorn) atrás de um servidor web de uso geral (como nginx) que atua como um proxy reverso. Um dos principais motivos que conheço para ter um proxy reverso é servir arquivos estáticos com eficiência. Existem outras razões?
Suponha que meu aplicativo envolva apenas código Python e não se importe com conteúdo estático. Por que eu iria querer o proxy reverso neste caso? uWSGI e Gunicorn já fornecem um servidor HTTP assíncrono capaz de fazer interface com os clientes.
Há algum caso prático em que seria melhor expor o servidor HTTP WSGI diretamente ao mundo exterior?
Responder1
você tem mais opções de configuração com um proxy reverso completo como
- reescrever
- Localizações
- servidor
- https
- limpeza de cabeçalho
- expira
- gzip
- ....
você pode fazer balanceamento de carga
- você pode usar proxy_cache
- você pode implementar páginas de erro personalizadas, mesmo quando seus servidores de aplicativos estão inativos
- você pode ter um WAF implementado
- você pode (às vezes) fazer hotpatch contra vulnerabilidades
PONTO DE BÔNUS
- você pode impressionar os clientes com 100.000 solicitações/segundo (em hardware médio) com a seguinte configuração (nginx):
.
location /perftest/ {
return 200;
}
Responder2
Vantagens adicionais de usar um proxy reverso.
Outros benefícios podem ser obtidos que PODEM ser benéficos para você.
- Você pode ocultar informações da internet (versão do servidor web, servidor de aplicativos, servidor de banco de dados, API)
- Você pode implementar várias tecnologias de servidor web atrás de um domínio (Linux Tomcat + Windows IIS etc.)
- Você pode encerrar conexões https/SSL e mapeá-las para serviços http internos.
- Você pode centralizar todos os registros.
- Você pode centralizar toda a prevenção DDOS
- Você pode implementar o gerenciamento de identidade na camada do servidor web.
Vantagens de segurança
- Servidor interno oculto como acima.
- Você pode rotear/firewall seus servidores de servidores de aplicativos internos e servidores de banco de dados da Internet sem recorrer a firewalls de software no host (chamados de DMZ).
- Você pode proteger um servidor que não pode ser corrigido imediatamente contra problemas conhecidos (firewall de aplicativos da web) ou padrões de ataque conhecidos.