Una configuración típica para implementar una aplicación WSGI incluye un servidor WSGI (como uWSGI o Gunicorn) detrás de un servidor web de propósito general (como nginx) que actúa como un proxy inverso. Una razón importante que conozco para tener un proxy inverso es servir archivos estáticos de manera eficiente. ¿Hay otras razones?
Supongamos que mi aplicación solo incluye código Python y no le importa el contenido estático. ¿Por qué querría el proxy inverso en este caso? uWSGI y Gunicorn ya proporcionan un servidor HTTP asincrónico capaz de interactuar con los clientes.
¿Existe algún caso práctico en el que sería mejor exponer el servidor HTTP WSGI directamente al mundo exterior?
Respuesta1
tienes más opciones de configuración con un proxy inverso completo como
- volver a escribir
- ubicaciones
- servidor
- https
- limpieza de encabezado
- expira
- zip
- ....
puedes hacer equilibrio de carga
- puedes usar proxy_cache
- Puedes implementar páginas de error personalizadas, incluso cuando tus servidores de aplicaciones no funcionan.
- puedes tener un WAF implementado
- puedes (a veces) aplicar parches contra vulnerabilidades
PUNTO DE BONIFICACIÓN
- Puede impresionar a los clientes con 100.000 solicitudes/segundo (en promedio de hardware) con la siguiente configuración (nginx):
.
location /perftest/ {
return 200;
}
Respuesta2
Ventajas adicionales de utilizar un proxy inverso.
Se pueden obtener otros beneficios que PUEDEN serle beneficiosos.
- Puede ocultar información de Internet (versión del servidor web, servidor de aplicaciones, servidor de bases de datos, API)
- Puede implementar múltiples tecnologías de servidor web detrás de un dominio (Linux tomcat + Windows IIS, etc.)
- Puede finalizar las conexiones https/SSL y asignarlas a servicios http internos.
- Puede centralizar todos los registros.
- Podrás centralizar toda la prevención DDOS
- Puede implementar la gestión de identidades desde el nivel del servidor web.
Ventajas de seguridad
- Servidor interno oculto como se indica arriba.
- Puede enrutador/cortafuegos sus servidores de servidores de aplicaciones internos y servidores de bases de datos de Internet sin recurrir a cortafuegos de software en el host (llamado DMZ).
- Puede proteger un servidor que no se puede reparar inmediatamente contra problemas conocidos (firewall de aplicaciones web) o patrones de ataque conocidos.