Как веб-фреймворки Python, WSGI и CGI сочетаются друг с другом

Как связаны WSGI, CGI и фреймворки?

Apache прослушивает порт 80. Он получает HTTP-запрос. Он анализирует запрос, чтобы найти способ ответить. У Apache есть МНОГО вариантов ответа. Один из способов ответить - использовать CGI для запуска сценария. Другой способ ответить - просто передать файл.

В случае CGI Apache подготавливает среду и вызывает сценарий через протокол CGI. Это стандартная ситуация Unix Fork / Exec - подпроцесс CGI наследует среду ОС, включая сокет и стандартный вывод. Подпроцесс CGI пишет ответ, который возвращается в Apache; Apache отправляет этот ответ браузеру.

CGI примитивен и раздражает. В основном потому, что он разветвляет подпроцесс для каждого запроса, а подпроцесс должен выйти или закрыть stdout и stderr, чтобы обозначить конец ответа.

WSGI - это интерфейс, основанный на шаблоне проектирования CGI. Это не обязательно CGI - ему не нужно создавать ответвление подпроцесса для каждого запроса. Это может быть CGI, но не обязательно.

WSGI добавляет к шаблону проектирования CGI несколько важных способов. Он анализирует заголовки HTTP-запроса и добавляет их в среду. Он предоставляет любой POST-ориентированный ввод как файловый объект в среде. Он также предоставляет вам функцию, которая формулирует ответ, избавляя вас от множества деталей форматирования.

Что мне нужно знать / установить / сделать, если я хочу запустить веб-фреймворк (например, web.py или cherrypy) в моей базовой конфигурации CGI?

Напомним, что разветвление подпроцесса обходится дорого. Есть два способа обойти это.

1. Встроенный mod_wsgi или mod_python встраивает Python в Apache; ни один процесс не разветвляется. Apache запускает приложение Django напрямую.

2. Демон mod_wsgi или mod_fastcgi позволяет Apache взаимодействовать с отдельным демоном (или «длительно выполняющимся процессом»), используя протокол WSGI. Вы запускаете свой длительный процесс Django, а затем настраиваете mod_fastcgi Apache для взаимодействия с этим процессом.

Обратите внимание, что mod_wsgi может работать в любом режиме: встроенный или демон.

Прочитав mod_fastcgi, вы увидите, что Django использует flup для создания WSGI- совместимый интерфейс из информации, предоставленной mod_fastcgi. Трубопровод работает так.

Apache -> mod_fastcgi -> FLUP (via FastCGI protocol) -> Django (via WSGI protocol)

В Django есть несколько «django.core.handler» для различных интерфейсов.

Для mod_fastcgi Django предоставляет manage.py runfcgi, который объединяет FLUP и обработчик.

Для mod_wsgi есть основной обработчик.

Как установить поддержку WSGI?

Следуйте этим инструкциям.

https://code.google.com/archive/p/modwsgi/wikis/IntegrationWithDjango.wiki

Для справки см. Это

http://docs.djangoproject.com/en/dev/howto/deployment/#howto-deployment-index

Я думаю, что ответ Флориана отвечает на часть вашего вопроса о том, «что такое WSGI», особенно если вы читаете PEP .

Что касается вопросов, которые вы задаете ближе к концу:

WSGI, CGI, FastCGI и т. Д. - это протоколы для веб-сервера для запуска кода и доставки создаваемого динамического содержимого. Сравните это со статической веб-службой, где простой HTML-файл в основном доставляется клиенту как есть.

CGI, FastCGI и SCGI не зависят от языка. Вы можете писать сценарии CGI на Perl, Python, C, bash и т. д. CGI определяет какой исполняемый файл будет вызываться на основе URL-адреса и как он будет вызываться: аргументы и окружение. Он также определяет, как возвращаемое значение должно быть передано обратно на веб-сервер после завершения вашего исполняемого файла. Вариации в основном являются оптимизацией, позволяющей обрабатывать больше запросов, уменьшать задержку и так далее; основная концепция такая же.

WSGI - это только Python. Вместо языкового независимого протокола определяется стандартная сигнатура функции:

def simple_app(environ, start_response):
    """Simplest possible application object"""
    status = '200 OK'
    response_headers = [('Content-type','text/plain')]
    start_response(status, response_headers)
    return ['Hello world!\n']

Это полное (если ограничено) приложение WSGI. Веб-сервер с поддержкой WSGI (например, Apache с mod_wsgi) может вызывать эту функцию всякий раз, когда приходит запрос.

Причина, по которой это так здорово, заключается в том, что мы можем избежать беспорядочного этапа преобразования из HTTP GET / POST в CGI в Python и обратно на выходе. Это гораздо более прямая, чистая и эффективная связь.

Это также значительно упрощает запуск долгосрочных фреймворков за веб-серверами, если все, что нужно сделать для запроса, - это вызов функции. Используя простой CGI, вам придется запускать всю структуру для каждого отдельного запроса.

Чтобы иметь поддержку WSGI, вам необходимо установить модуль WSGI (например, mod_wsgi), или используйте веб-сервер со встроенным WSGI (например, CherryPy). Если ни один из них не возможен, вы можете использовать мост CGI-WSGI, указанный в PEP.

Вы можете запустить WSGI поверх CGI, как это демонстрирует Pep333 как пример. Однако каждый раз, когда появляется запрос, запускается новый интерпретатор Python, и необходимо построить весь контекст (соединения с базой данных и т. Д.), Что требует времени.

Лучше всего, если вы хотите запустить WSGI, если бы ваш хост установил mod_wsgi и сделал соответствующий конфигурация, чтобы передать управление вашему приложению.

Flup - это еще один способ работы с WSGI для любого веб-сервера, который может говорить FCGI, SCGI или AJP. По моему опыту, действительно работает только FCGI, и его можно использовать в Apache через mod_fastcgi или если вы можете запустить отдельный демон Python с помощью mod_proxy_fcgi.

WSGI - это протокол, очень похожий на CGI, который определяет набор правил взаимодействия веб-сервера и кода Python, он определяется как Pep333. Это позволяет множеству разных веб-серверов использовать множество различных фреймворков и приложений, использующих один и тот же протокол приложения. Это очень полезно и очень полезно.

Если вам неясны все термины в этом пространстве, и давайте посмотрим правде в глаза, это сбивающий с толку термин, содержащий аббревиатуры, есть также хороший справочник в виде официального Python HOWTO, в котором обсуждается CGI, FastCGI, WSGI и т. Д. на: http://docs.python.org/howto/webservers.html

Это простой уровень абстракции для Python, похожий на спецификацию сервлетов для Java. В то время как CGI на самом деле низкоуровневый и просто сбрасывает данные в среду процесса и вводит / выводит стандарт, две вышеупомянутые спецификации моделируют HTTP-запрос и ответ как конструкции на языке. Однако у меня сложилось впечатление, что люди в Python еще не совсем остановились на фактических реализациях, поэтому у вас есть сочетание эталонных реализаций и других библиотек служебного типа, которые предоставляют другие вещи наряду с поддержкой WSGI (например, Paste). Конечно, я могу ошибаться, я новичок в Python. Сообщество "веб-сценариев" подходит к проблеме с другого направления (общий хостинг, наследие CGI, проблемы разделения привилегий), чем люди, занимающиеся Java, могли позволить себе роскошь начать (запуск одного корпоративного контейнера в выделенной среде вместо статически скомпилированной и развернутой). код).