Как веб-фреймворки Python, WSGI и CGI сочетаются друг с другом
https://stackoverflow.com/questions/219110
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
У меня есть Bluehost учетная запись, где я могу запускать скрипты Python как CGI. Я думаю, это самый простой CGI, потому что для запуска мне нужно определить следующее в .htaccess :
Options +ExecCGI
AddType text/html py
AddHandler cgi-script .py
Теперь, когда я смотрю веб-программирование на Python, я много слышу о WSGI и о том, как его использует большинство фреймворков. Но я просто не понимаю, как все это сочетается друг с другом, особенно когда мой веб-сервер предоставляется (Apache работает на машине хоста), а не то, с чем я действительно могу играть (кроме определения команд .htaccess ) .
Как подключены WSGI , CGI и интегрированные среды? Что мне нужно знать, устанавливать и делать, если я хочу запустить веб-среду (например, web.py или < a href = "http://en.wikipedia.org/wiki/CherryPy" rel = "noreferrer"> CherryPy ) в моей базовой конфигурации CGI? Как установить поддержку WSGI?
Решение
Как связаны между собой WSGI, CGI и фреймворки?
Apache прослушивает порт 80. Получает HTTP-запрос. Он анализирует запрос, чтобы найти способ ответить. Апач имеет много вариантов ответа. Один из способов ответа - использовать 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?
Напомним, что разветвление подпроцесса стоит дорого. Есть два способа обойти это.
<Ол> Embedded mod_wsgi или mod_python встраивает Python в Apache; ни один процесс не разветвлен. Apache запускает приложение Django напрямую.
Демон 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.handlers» quot; для различных интерфейсов.
Для mod_fastcgi Django предоставляет manage.py runfcgi , который объединяет FLUP и обработчик.
Для mod_wsgi для этого есть основной обработчик.
Как установить поддержку WSGI?
Следуйте этим инструкциям.
https://code.google.com/archive/p/ modwsgi / вики / IntegrationWithDjango.wiki
Для справки смотрите это
http://docs.djangoproject.com/en / DEV / HOWTO / развертывание / # HOWTO развертывания индекс
Другие советы
Я думаю, что ответ Флориана отвечает на часть вашего вопроса о том, что такое 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 . Это позволяет многим различным веб-серверам использовать множество различных сред и приложений, использующих один и тот же протокол приложения. Это очень полезно и делает его таким полезным.
Если вам неясны все термины в этом пространстве, и давайте посмотрим правде в глаза, это вводит в заблуждение акроним, есть также хороший фоновый читатель в форме официального HOWTO на питоне, в котором обсуждается CGI vs. FastCGI vs. WSGI и т. Д .: http://docs.python.org/howto/webservers.html
Это простой уровень абстракции для Python, похожий на спецификацию Servlet для Java. Принимая во внимание, что CGI действительно низкоуровневый и просто сбрасывает содержимое в среду процесса и стандартный ввод / вывод, две вышеупомянутые спецификации моделируют запрос и ответ http как конструкции на языке. Однако у меня сложилось впечатление, что в Python люди не совсем остановились на фактических реализациях, поэтому у вас есть набор эталонных реализаций и другие библиотеки служебных типов, которые предоставляют другие функции наряду с поддержкой WSGI (например, Вставить). Конечно, я могу ошибаться, я новичок в Python. & Quot; веб-сценарии " Сообщество приходит к этой проблеме с другой стороны (общий хостинг, наследие CGI, проблемы разделения привилегий), чем люди Java могли позволить себе роскошь начать (запуск одного корпоративного контейнера в выделенной среде против статически скомпилированного и развернутого кода).
