Какова была эволюция парадигмы взаимодействия между программой веб-сервера и программой провайдера контента? - PullRequest
1 голос
/ 07 января 2011

По моему мнению, веб-сервер отвечает за доставку контента клиенту. Если это статический контент, такой как изображения и статический HTML-документ, веб-сервер просто доставит их как битовый поток напрямую. Если во время обработки запроса клиента генерируется какое-то динамическое содержимое, веб-сервер не сгенерирует саму conetnt, но вызовет некоторый внешний proram для создания содержимого.

AFAIK, этот вид технологий генерации контента Dynamic включает следующее:

  • CGI

  • ISAPI

  • ...

А с здесь я заметил, что:

... В IIS 7 модули заменяют ISAPI фильтры ...

Есть ли другие? Может ли кто-нибудь помочь мне заполнить приведенный выше список и добавить или показать некоторые ссылки на их evolution ? Я думаю, что было бы очень полезно понять такие приложения, как IIS, TomCat и Apache.

Однажды я написал небольшую CGI-программу, и, хотя она служит генератором контента , она по-прежнему является обычной автономной программой. Я называю это нормальным, потому что программа CGI имеет точку входа main (). Но с такой технологией, как ASP.NET, я пишу не полную программу, а только некоторую библиотеку классов. Почему происходит такое радикальное изменение?

Большое спасибо.

Ответы [ 2 ]

1 голос
/ 07 января 2011

Ну, самый большой недостаток в вашем вопросе - это то, что веб-сервер также может генерировать контент динамически. Это характерно для большинства платформ вне PHP и Perl. Вы часто устанавливаете этот веб-сайт как apache или nginx, используемый в качестве прокси-сервера, но он никоим образом не "вызывает внешнюю программу", а перенаправляет запрос http на проксируемый сервер. В основном это делается для того, чтобы вы могли иметь несколько сайтов на одном сервере, а также чтобы apache / nginx защищал вас от неправильных запросов.

Но, разумеется, мы можем, ради вопроса, сказать, что «проксирование» - это способ вызова внешней программы. : -)

Другим способом «вызова внешней программы» является Pythons WSGI, где вы вызываете постоянно работающий сервер. Итак, снова вы не запускаете внешнюю программу, это больше похоже на вызов модуля в ASP (хотя это отдельная программа, а не модуль, но вы не запускаете ее при каждом запросе, вы используете API).

Переход от вызова внешних программ, как в CGI, к вызову модулей, таких как в ASP.NET, к процессу с WGI или прокси к другому веб-серверу, произошел потому, что с CGI вы должны запускать новую prpogram для каждого запроса. Интерпретатор PERL / PHP должен быть загружен в память, а также во все модули, которые они используют. Это быстро становится очень тяжелым и интенсивным процессом / памятью.

Поэтому, чтобы иметь возможность использовать большие системы, которые постоянно работают, были разработаны другие методы. Большинство из них зависят от платформы / языка, и единственное, что не зависит от платформы, - это сделать полноценный веб-сервер и затем использовать apache / nginx в качестве прокси-сервера (в этом случае apache / nginx больше не нужен) ).

Надеюсь, это немного прояснилось.

0 голосов
/ 16 сентября 2011

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

OTOH, написать свой маленький генератор таким образом, чтобы он ничего не пропускал между вызовами, сложнее, чем иметь возможность просто выйти в конце (и полагаться на переменные окружения и аргументы командной строки, как на обычный исполняемый файл).

Это все из соображений производительности, но тогда у вас есть более сложные генераторы контента и управление процессами в веб-серверах.

...