WSGI запускает интерпретатор Python при запуске веб-сервера, либо как часть процесса веб-сервера (встроенный режим), либо как отдельный процесс (режим демона), и загружает в него сценарий. Каждый запрос приводит к определенной функции в вызываемом сценарии, при этом среда запроса передается функции в качестве аргументов.
CGI запускает сценарий как отдельный процесс для каждого запроса и использует переменные среды, stdin и stdout для «взаимодействия» с ним.
WSGI! = Mod_wsgi. Ваш язык предполагает, что вы имеете в виду mod_wsgi, который является реализацией WSGI. Сам WSGI является просто спецификацией и может быть реализован множеством различных способов, в том числе поверх CGI.
Грэм Дамплтон
@Graham: Вы хотите сказать, что нет других контейнеров WSGI, поддерживающих запуск приложений WSGI в этих режимах?
Игнасио Васкес-Абрамс
3
Технически можно сказать, что есть более тонкие вариации, чем только эти два, по крайней мере, в том, как запускаются процессы или как активируется код во встроенной системе. Так что нужно просто быть осторожным, обобщая вещи только на эти две категории. На грубом уровне вы можете сказать то, что у вас есть, но есть нечто большее, чем это, если вы хотите вникнуть в это.
Грэм Дамплтон
1
@GrahamDumpleton, из любопытства, не могли бы вы объяснить, как можно реализовать WSGI поверх CGI?
С совершенно отстраненной точки зрения, Бланкман, вот моя «Вводная страница» для интерфейса шлюза веб-служб:
ЧАСТЬ ПЕРВАЯ: ВЕБ-СЕРВЕРЫ
Веб-серверы обслуживают ответы. Они сидят и терпеливо ждут, а затем без всякого предупреждения внезапно:
клиентский процесс отправляет запрос. Клиентский процесс может быть веб-сервером, ботом, мобильным приложением и т. Д. Это просто «клиент»
веб-сервер получает этот запрос
намеренно бормочут разные вещи (см. ниже)
Веб-сервер отправляет что-то клиенту
веб-сервер снова сидит без дела
Веб-серверы (по крайней мере, лучшие) очень хороши в этом. Они увеличивают и уменьшают обработку в зависимости от спроса, они надежно поддерживают разговоры с самыми ненадежными клиентами по действительно грубым сетям, и нам никогда не нужно об этом беспокоиться. Они просто продолжают служить.
Это моя точка зрения: веб-серверы - это всего лишь серверы. Они ничего не знают о контенте, ничего о пользователях, ничего, кроме того, как долго ждать и надежно отвечать.
Ваш выбор веб-сервера должен отражать ваши предпочтения по доставке, а не ваше программное обеспечение. Ваш веб-сервер должен отвечать за обслуживание, а не за обработку или логику.
ЧАСТЬ ВТОРАЯ: (PYTHON) ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
Софт без дела не сидит. Программное обеспечение существует только во время выполнения. Программное обеспечение не очень приспособлено, когда дело доходит до неожиданных изменений в его среде (файлы не там, где они ожидают, параметры переименовываются и т. Д.). Хотя оптимизация должна быть центральным принципом вашего дизайна (конечно), само программное обеспечение не оптимизирует. Разработчики оптимизируют. Программное обеспечение выполняется. Программное обеспечение делает все, что описано в разделе «Умышленное бормотание» выше. Может быть что угодно.
Ваш выбор или дизайн программного обеспечения должны отражать ваше приложение, ваш выбор функций, а не ваш выбор веб-сервера.
Вот где традиционный метод "компиляции" языков для веб-серверов становится болезненным. В конечном итоге вы вставляете код в свое приложение, чтобы справиться с физической средой сервера, или, по крайней мере, вам приходится выбирать подходящую библиотеку-оболочку для включения во время выполнения, чтобы создать иллюзию единообразия между веб-серверами.
ТАК ЧТО ТАКОЕ WSGI?
Итак, наконец, что такое WSGI? WSGI - это набор правил , состоящий из двух частей. Они написаны таким образом, что могут быть интегрированы в любую среду, приветствующую интеграцию.
В первой части, написанной для веб-сервера, говорится: «Хорошо, если вы хотите иметь дело с приложением WSGI, вот как программа будет думать при загрузке. Вот то, что вы должны сделать доступным для приложения, и вот это интерфейс (макет), который вы можете ожидать от каждого приложения. Более того, если что-то пойдет не так, вот как приложение будет думать и как вы можете ожидать от него поведения ».
Во второй части, написанной для прикладного программного обеспечения Python, говорится: «Хорошо, если вы хотите иметь дело с сервером WSGI, вот как сервер будет думать, когда свяжется с вами. Вот то, что вы должны сделать доступным для сервера, и вот интерфейс (макет), который вы можете ожидать от каждого сервера. Более того, если что-то пойдет не так, вот как вы должны себя вести, и вот что вы должны сообщить серверу ».
Итак, у вас есть это - серверы будут серверами, а программное обеспечение будет программным обеспечением, и вот способ, которым они могут прекрасно ужиться, без необходимости делать какие-либо поправки на особенности другого. Это WSGI.
mod_wsgi, с другой стороны, представляет собой плагин для Apache, который позволяет ему взаимодействовать с WSGI-совместимым программным обеспечением, другими словами, mod_wsgi - это реализация - в Apache - правил части первой из приведенной выше книги правил.
Вместо того, чтобы позволить этому ответу заканчиваться словами «спросите кого-нибудь еще», я бы хотел, чтобы кто-нибудь отредактировал этот ответ, включив CGI таким же образом.
Бруно Броноски
1
«серверы будут серверами, а программное обеспечение будет программным» - «серверы будут с Марса, а программное обеспечение - с Венеры» :)
Рахул
22
Если вам неясны все термины в этом пространстве, и давайте посмотрим правде в глаза, это сбивающий с толку термин, содержащий аббревиатуры, есть также хороший справочник в виде официального Python HOWTO, в котором обсуждается CGI, FastCGI, WSGI и т. на. Я хотел бы сначала прочитать это.
И CGI, и WSGI определяют стандартные интерфейсы, которые программы могут использовать для обработки веб-запросов. Интерфейс CGI находится на более низком уровне, чем WSGI, и включает в себя настройку сервером переменных среды, содержащих данные из HTTP-запроса, при этом программа возвращает что-то, отформатированное почти как простой ответ HTTP-сервера.
WSGI, с другой стороны, представляет собой специфичный для Python интерфейс немного более высокого уровня, который позволяет программистам писать приложения, не зависящие от сервера и которые могут быть заключены в другие приложения WSGI (промежуточное программное обеспечение).
Ответы:
WSGI запускает интерпретатор Python при запуске веб-сервера, либо как часть процесса веб-сервера (встроенный режим), либо как отдельный процесс (режим демона), и загружает в него сценарий. Каждый запрос приводит к определенной функции в вызываемом сценарии, при этом среда запроса передается функции в качестве аргументов.
CGI запускает сценарий как отдельный процесс для каждого запроса и использует переменные среды, stdin и stdout для «взаимодействия» с ним.
источник
С совершенно отстраненной точки зрения, Бланкман, вот моя «Вводная страница» для интерфейса шлюза веб-служб:
ЧАСТЬ ПЕРВАЯ: ВЕБ-СЕРВЕРЫ
Веб-серверы обслуживают ответы. Они сидят и терпеливо ждут, а затем без всякого предупреждения внезапно:
Веб-серверы (по крайней мере, лучшие) очень хороши в этом. Они увеличивают и уменьшают обработку в зависимости от спроса, они надежно поддерживают разговоры с самыми ненадежными клиентами по действительно грубым сетям, и нам никогда не нужно об этом беспокоиться. Они просто продолжают служить.
Это моя точка зрения: веб-серверы - это всего лишь серверы. Они ничего не знают о контенте, ничего о пользователях, ничего, кроме того, как долго ждать и надежно отвечать.
Ваш выбор веб-сервера должен отражать ваши предпочтения по доставке, а не ваше программное обеспечение. Ваш веб-сервер должен отвечать за обслуживание, а не за обработку или логику.
ЧАСТЬ ВТОРАЯ: (PYTHON) ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
Софт без дела не сидит. Программное обеспечение существует только во время выполнения. Программное обеспечение не очень приспособлено, когда дело доходит до неожиданных изменений в его среде (файлы не там, где они ожидают, параметры переименовываются и т. Д.). Хотя оптимизация должна быть центральным принципом вашего дизайна (конечно), само программное обеспечение не оптимизирует. Разработчики оптимизируют. Программное обеспечение выполняется. Программное обеспечение делает все, что описано в разделе «Умышленное бормотание» выше. Может быть что угодно.
Ваш выбор или дизайн программного обеспечения должны отражать ваше приложение, ваш выбор функций, а не ваш выбор веб-сервера.
Вот где традиционный метод "компиляции" языков для веб-серверов становится болезненным. В конечном итоге вы вставляете код в свое приложение, чтобы справиться с физической средой сервера, или, по крайней мере, вам приходится выбирать подходящую библиотеку-оболочку для включения во время выполнения, чтобы создать иллюзию единообразия между веб-серверами.
ТАК ЧТО ТАКОЕ WSGI?
Итак, наконец, что такое WSGI? WSGI - это набор правил , состоящий из двух частей. Они написаны таким образом, что могут быть интегрированы в любую среду, приветствующую интеграцию.
В первой части, написанной для веб-сервера, говорится: «Хорошо, если вы хотите иметь дело с приложением WSGI, вот как программа будет думать при загрузке. Вот то, что вы должны сделать доступным для приложения, и вот это интерфейс (макет), который вы можете ожидать от каждого приложения. Более того, если что-то пойдет не так, вот как приложение будет думать и как вы можете ожидать от него поведения ».
Во второй части, написанной для прикладного программного обеспечения Python, говорится: «Хорошо, если вы хотите иметь дело с сервером WSGI, вот как сервер будет думать, когда свяжется с вами. Вот то, что вы должны сделать доступным для сервера, и вот интерфейс (макет), который вы можете ожидать от каждого сервера. Более того, если что-то пойдет не так, вот как вы должны себя вести, и вот что вы должны сообщить серверу ».
Итак, у вас есть это - серверы будут серверами, а программное обеспечение будет программным обеспечением, и вот способ, которым они могут прекрасно ужиться, без необходимости делать какие-либо поправки на особенности другого. Это WSGI.
mod_wsgi, с другой стороны, представляет собой плагин для Apache, который позволяет ему взаимодействовать с WSGI-совместимым программным обеспечением, другими словами, mod_wsgi - это реализация - в Apache - правил части первой из приведенной выше книги правил.
Насчет CGI .... спросите у кого нибудь :-)
источник
Если вам неясны все термины в этом пространстве, и давайте посмотрим правде в глаза, это сбивающий с толку термин, содержащий аббревиатуры, есть также хороший справочник в виде официального Python HOWTO, в котором обсуждается CGI, FastCGI, WSGI и т. на. Я хотел бы сначала прочитать это.
источник
И CGI, и WSGI определяют стандартные интерфейсы, которые программы могут использовать для обработки веб-запросов. Интерфейс CGI находится на более низком уровне, чем WSGI, и включает в себя настройку сервером переменных среды, содержащих данные из HTTP-запроса, при этом программа возвращает что-то, отформатированное почти как простой ответ HTTP-сервера.
WSGI, с другой стороны, представляет собой специфичный для Python интерфейс немного более высокого уровня, который позволяет программистам писать приложения, не зависящие от сервера и которые могут быть заключены в другие приложения WSGI (промежуточное программное обеспечение).
источник