Типичная конфигурация для развертывания приложения WSGI включает сервер WSGI (например, uWSGI или Gunicorn) за веб-сервером общего назначения (например, nginx), который действует как обратный прокси-сервер. Одна из основных причин, по которой, как мне известно, нужен обратный прокси-сервер, — это эффективное обслуживание статических файлов. Есть ли другие причины?
Предположим, что мое приложение включает только код Python и не заботится о статическом контенте. Зачем мне обратный прокси в этом случае? uWSGI и Gunicorn уже предоставляют асинхронный HTTP-сервер, способный взаимодействовать с клиентами.
Существуют ли какие-либо практические случаи, когда было бы лучше предоставить внешнему миру прямой доступ к HTTP-серверу WSGI?
решение1
у вас больше опций конфигурации с полнофункциональным обратным прокси-сервером
- переписать
- локации
- сервер
- https
- очистка заголовка
- истекает
- gzip
- ....
вы можете сделать балансировку нагрузки
- вы можете использовать proxy_cache
- вы можете реализовать пользовательские страницы ошибок, даже если ваши серверы приложений не работают
- вы можете реализовать WAF
- вы можете (иногда) применять хот-патчи для устранения уязвимостей
БОНУСНЫЙ БАЛЛ
- Вы можете удивить клиентов 100 000 запросами в секунду (на среднем оборудовании) с помощью следующей настройки (nginx):
.
location /perftest/ {
return 200;
}
решение2
Дополнительные преимущества использования обратного прокси-сервера.
Вы можете получить и другие преимущества, которые МОГУТ быть вам полезны.
- Вы можете скрыть информацию из интернета (версию веб-сервера, сервера приложений, сервера базы данных, API)
- Вы можете реализовать несколько технологий веб-серверов в одном домене (Linux tomcat + Windows IIS и т. д.)
- Вы можете завершить https/SSL-соединения и сопоставить их с внутренними http-сервисами.
- Вы можете централизовать все протоколирование.
- Вы можете централизовать все меры по предотвращению DDOS-атак
- Вы можете реализовать управление идентификацией на уровне веб-сервера.
Преимущества безопасности
- Скрытие внутреннего сервера, как указано выше.
- Вы можете маршрутизатором/брандмауэром защитить внутренние серверы приложений и серверы баз данных от Интернета, не прибегая к программным брандмауэрам на хосте (так называемая DMZ).
- Вы можете защитить сервер, который невозможно устранить немедленно, от известных проблем (брандмауэр веб-приложений) или известных схем атак.