Назад | Перейти на главную страницу

Зачем ставить обратный прокси перед сервером WSGI?

Типичная конфигурация для развертывания приложения WSGI включает сервер WSGI (например, uWSGI или Gunicorn) за веб-сервером общего назначения (например, nginx), который действует как обратный прокси. Одна из основных причин, по которой я знаю обратный прокси, - это эффективное обслуживание статических файлов. Есть ли другие причины?

Предположим, мое приложение включает только код Python и не заботится о статическом содержимом. Зачем мне в этом случае нужен обратный прокси? uWSGI и Gunicorn уже предоставляют асинхронный HTTP-сервер, способный взаимодействовать с клиентами.

Существуют ли какие-либо практические случаи, когда мне было бы лучше открыть доступ к серверу HTTP WSGI напрямую внешнему миру?

  • у вас больше вариантов конфигурации с полноценным реверсом - прокси вроде

    • переписать
    • локации
    • сервер
    • https
    • очистка заголовка
    • истекает
    • gzip
    • ....

  • вы можете сделать балансировку нагрузки

  • вы можете использовать proxy_cache
  • вы можете реализовать настраиваемые страницы ошибок, даже когда ваши серверы приложений не работают
  • вы можете реализовать WAF
  • вы можете (иногда) исправлять уязвимости

БОНУС-ПУНКТ

  • вы можете произвести впечатление на клиентов с помощью 100000 запросов в секунду (в среднем на оборудовании) со следующей настройкой (nginx):

.

location /perftest/ {
    return 200;
}

Дополнительные преимущества использования обратного прокси.

Вы можете получить другие преимущества, которые МОГУТ быть полезны для вас.

  • Вы можете скрыть информацию из Интернета (версия веб-сервера, сервер приложений, сервер базы данных, api)
  • Вы можете реализовать несколько технологий веб-серверов за одним доменом (Linux tomcat + Windows IIS и т. Д.)
  • Вы можете разорвать https / SSL-соединения и сопоставить их с внутренними http-сервисами.
  • Вы можете централизовать все ведение журнала.
  • Вы можете централизовать всю защиту от DDOS
  • Вы можете реализовать управление идентификацией на уровне веб-сервера.

Преимущества безопасности

  • Скрытие внутреннего сервера, как указано выше.
  • Вы можете маршрутизировать / брандмауэр свои внутренние серверы серверов приложений и серверы баз данных из Интернета, не прибегая к программным брандмауэрам на узле (называемом DMZ).
  • Вы можете защитить сервер, который нельзя исправить немедленно, от известных проблем (брандмауэр веб-приложений) или известных шаблонов атак.