Возможна ли работа web-приложения без CGI?

Question

[Дмитрий]

Насколько понял WEB-приложение работая где-либо на WEB-сервере должно как-то общаться с ним и эту роль «коммуникационного протокола» играет CGI. Почитав про CGI, FastCGI и немного про Django мой вопрос, который в сабже не был исчерпан.

Мне хочется знать, а возможна ли работа WEB-приложения без использования CGI?
Вероятно существуют другие способы общения с WEB-сервером, которые пока не знаю.

P.S.:
Сильно не пинайте за такой вопрос. Для кого-то этот вопрос из разряда «капитанских», а для меня вэб-разработка новое направление, в котором я пока даже на уровень «новичка» не тяну ) Я только только приступил к постижению основ разработки WEB-приложений.

Answer 1

[SleepingLion]

Существует достаточно большое количество технологий решающих задачу коммуникации веб-приложения и клиента (связка веб-сервер+CGI только одна из них). Я могу выделить три класса таких технологий (кто-то может по другому их разделить, это не для спора):
— CGI-like, когда сервер перенаправляет запросы в экземпляр приложения, которое запускается как отдельный процесс в системе, и использует результат выполнения для отдачи клиенту;
— Fast-CGI-like, когда приложение работает как демон и обслуживает запросы веб-сервера;
— Сервера приложений, которые в собственном контексте выполняют код и обслуживают запросы.
Отдельно можно поставить комплексные сервера-приложения, которые сами выполняют все функции, как приложения, так и сервера.
Выбор технологии зависит от языка и уровня навыков.
CGI прост, но почти по всем параметрам уступает FCGI. Обе технологии используются, в основном, при работе с скриптовыми языками (Perl, PHP).
Сервера приложений — это преимущественно Java мир. Много специфики.

Comments

[Дмитрий]

Прошу проверить мое понимание web-приложений.

1) Когда человек отрывает web-браузер(далее по тексту клиент), к примеру Safari
2) И набирает ссылку, то клиент узнав где находится web-сервер, разрезолвив его dns-имя шлет ему запрос
3) web-сервер(для меня это магия связанная со словом Apache) соглассно своим настройкам посылает их web-приложению
4) Web-приложение написанное к примеру на Php или Python формирует страничку и пишет ее в STDOUT
5) Полученную от web-приложения по stdout сервер(apache) шлет страничку клиенту(компу где стоит safari запросивший)

Как видно из моих слов для меня web-приложение это то что формирует конечный html, отправляемый пользователям. Это Web-приложение я могу написать на Python используя Django.

все верно?

[TheHorse]

верно

[VBart]

3. Очень условно. Если под веб-сервером понимать HTTP-сервер, то во-первых он сам по себе может являться тем самым приложением, во-вторых посылать по тому или иному протоколу запрос на другой сервер приложений или самому приложению, если оно реализовано в виде отдельного демона, или самим выступить в роли сервера приложений, передав запрос по внутреннему интерфейсу.
4. В случае оригинального CGI да, а так в STDOUT уже давно никто не пишет, ибо не эффективно. Данные отдают либо по внутреннему интерфейсу в сервер приложений (он же может быть и тем самым HTTP-сервером), либо пишут сразу в сокет, реализуя тот или иной протокол (он же может быть сразу HTTP).

[VBart]

И то, кстати, это только если рассматривать наиболее классические и распространенные схемы. А так ведь веб-приложение на стороне сервера может просто выгружать данные куда-то в базу, или, как вариант базы — файловая система, складывать в обычные файлы, которые уже будет обрабатывать классический HTTP(S)/SPDY-сервер. =)

Answer 2

[Андрей]

Да запросто. Существует множество web-приложений, работающих на стороне клиента без использования CGI. Как правило, они работают на Javascript.
Для общения с web-сервером приложению также cgi не является обязательным. Обмен данными может осуществляться через XML, REST etc. Некоторым приложениям вообще свой сервер не нужен, если данные получаются со сторонних API-сервисов.

Answer 3

[VBart]

Такие вопросы на хабре задавать бесполезно. =)

Большинство ответивших написали местами полную чушь. Основная масса веб-программистов дальше своих фреймворков не вылезают, и у них в итоге полная каша в голове. Например, кто-то путает интерфейс (WSGI, Pump, WEB3, PSGI, Rack, CGI и т.д.), сервер приложений (uWSGI, php-fpm, Rack, Gunicorn, unicorn, flup, Apache в данной роли, и ещё тысячи их) и протокол (HTTP, uwsgi, FastCGI, SCGI, CGI, AJP, WebSocket, да много их). Кто-то путает протокол, способ его реализации и способ запуска интерпретатора.

Основное, что вам нужно знать, содержится в документации Django:
docs.djangoproject.com/en/dev/howto/deployment/

Ответом на ваш вопрос будет: да существует множество и каждый HTTP-сервер поддерживает целый набор протоколов для общения с сервером приложений. И сервера приложений могут поддерживать один или несколько протоколов, один или несколько интерфейсов. Некоторые HTTP-сервера умеют выполнять двойную роль, выступая и в роли сервера-приложения, предоставляя определенный интерфейс. А некоторые приложения сами содержат встроенный HTTP-сервер. Термин же «веб-сервер» слишком общий, и трактоваться может разными способами.

Comments

[Дмитрий]

Предложил бы Вам написать статью, чтобы эта «полная каша в голове» была решена. Не забываем, ведь мы все потенциальные коллеги в будущем. Кто знает, может именно Вам выпадет честь работать с теми про кого вы сказали «полная каша в голове»? ;)

[VBart]

Сорри, статью не могу обещать. Основная работа покрывает все ресурсы, как временные, так и морально-физические.

Answer 4

[TheHorse]

Браузер, отправляя запрос на сервер, отправляет запрос HTTP (протокол прикладного уровня основанный на TCP). На сервере его может принять любое приложение, которое работает с протоколом HTTP. В большинстве случаев это действительно веб-сервер в стандартном его понимании (apache, nginx, lIS...), который в зависимости от своих настроек и входящего запроса может либо передать запрос по CGI/FCGI на PHP/Python/любой другой язык, либо отработать запрос самостоятельно (выдать картинку, заблокировать...). Но это применимо в основном только для скриптовых языков и stateless приложений. Statefull веб-приложения (обычно С/С++/Java/Delphi/C#) часто используют встроенный веб-сервер, который обеспечивает коммуникацию по протоколу HTTP без стороннего внешнего веб-сервера (apache, nginx)… Более того, даже при использовании apache, nginx не обязательно использовать CGI/FCGI, насколько я знаю, можно использовать обычное прокси.

Answer 5

[mithraen]

Для того чтобы выполнять скрипты, web-серверу нужен некий протокол, чтобы взаимодействовать с этими скриптами. Таковых есть несколько:
— CGI
— FastCGI
— обычный HTTP
— встроенные в сервер API (для подключения модулей — как mod_perl и mod_php в апаче, или встроенная поддержка perl в nginx)

Comments

[Дмитрий]

Оо, спасибо. Т.е. mod_python может послужить заменой CGI. Но даже если стоит mod_python никто мне не мешает общаться с WEB-сервером по CGI все верно?

[mithraen]

Именно так.
Но для построения масштабируемых систем сейчас все-таки разумнее применять fastcgi и http в качестве протокола. Это позволяет легко отделить фронтенд и раздачу статики от application server'ов. Такая архитектура гораздо проще проще масштабируется (сегодня это дешевая виртуалка где-нибудь, завтра — будет кластер из десятка серверов).

[Дмитрий]

Извините вопрос все еще не исчерпан.

В виду того, что посматриваю в сторону Django у меня возникают вопросы:
1) При создании среды, где будет крутиться приложение. Сервер можно настроить так, чтобы он работа с Django по одному из протоколов Cgi или FastCgi все верно?
2) При этом после п.1 код написанный python не будет зависеть от того что применяется CGI или FastCGI, все верно?

[mithraen]

Я не знаком с Django, это лучше спрашивать у спецов по нему. Сам я предпочитаю перловку :)

[Константин Китманов]

ЕМНИП, джанго может работать и под CGI, и под uWSGI, и под FastCGI, и под mod_python. Наиболее «нативным» вариантом является uWSGI.

[VBart]

Django это прежде всего фреймворк, а как его запускать это другой вопрос. =) А что касается «нативности», то uWSGI тут вообще не в кассу. Он не более нативен для Django, чем какой-нибудь flup или Gunicorn.

Answer 6

[Eddy_Em]

Запросто (вебсокеты). В этом случае и без веб-сервера можно обойтись.

Comments

[Eddy_Em]

Интересное кино. А можно узнать у товарищей минусующих, в чем проблема?
CGI нет. Веб-сервера тоже нет. Есть лишь демон, слушающий определенный сокет…

[cy6erGn0m]

Я думаю (я не минусовал), что они имеют в виду, что если нет веб-сервера, то откуда сама страница взялась? Веб-сервер нужен как минимум для раздачи статики.

[Дмитрий]

2 Eddy_Em:
В мире программного обеспечения возможно почти Все! Однако надо же оставаться в рамках вопроса. В данной теме, до появления вашего комментария, уже было понятно что я, автор темы, интересуюсь вопросом с CGI относительно точки зрения разработчика сайтов. Вот представьте себе сайт подобный хабру разработанный по вашему методу на вэб-сокетах, мне кажется это будет неуклюжая разработка, если вообще возможна без плясок с бубном и головной боли. Думаю именно то что вы приплели вэб-сокеты и не понравилось минусующим, которые в этом контексте не в тему.

[Eddy_Em]

> Веб-сервер нужен как минимум для раздачи статики.
Нет: страничку отдает демон при помощи вебсокета (это если нет веб-сервера и сам демон сидит на 80-м порту).

> представьте себе сайт подобный хабру разработанный по вашему методу на вэб-сокетах
Фразу «В этом случае и без веб-сервера можно обойтись» надо читать правильно: не обязательно сносить веб-сервер. Статику отдавайте обычным апачем (скажем), а динамику — вебсокетами. Все просто.

> представьте себе сайт подобный хабру разработанный по вашему методу на вэб-сокетах
Будет вполне приличный сайт. И, кстати, все свежие комментарии сразу же будут появляться. Вебсокеты лучше CGI, если вам нужно обеспечить асинхронное общение сервера и клиента с минимальными задержками и минимальной нагрузкой (т.к. слать XHR по 10 раз в секудну — чересчур).
> Думаю именно то что вы приплели вэб-сокеты и не понравилось минусующим
Думаю, минусующие просто ничего про вебсокеты не слышали.
Интересно, может для них и webGL — чудо? ☺

[Дмитрий]

>>Все просто.
Даже? Кому-то, кто уже давным давно в этой теме наверное действительно просто.

Еще раз читаем шапку темы:
" а для меня вэб-разработка новое направление, в котором я пока даже на уровень «новичка» не тяну "
Т.е. если Вы решили ответить на вопрос заданный новичком, то Вы должны учитывать все требования, а иначе это уже не попытка дать ответ, а попытка показать свою крутость!

>>И, кстати, все свежие комментарии сразу же будут появляться. Вебсокеты лучше CGI
Не думаю, что разработчики хабра об этом не знали. Хорошо, допустим, они не знают, то у Вас есть отличная возможность написать предложение по улучшению ресурса в виде статьи, которая думаю будет полезной и интересной многим, к примеру мне.

[Eddy_Em]

Скорее всего, ближе к весне будет такая статья: я ожидаю макетки на STM32 с ethernet на борту. Вот и расскажу, как сделать веб-морду для управления микроконтроллером (на основе вебсокетов).

[VBart]

Основной минус вам за фразу «без веб-сервера можно обойтись». Если нет сервера, то с чем общается браузер? =) «демон, слушающий определенный сокет» и есть сервер.

[Eddy_Em]

И действительно, что-то я об этом не подумал. Надо было сказать «без апача или nginx».

[TheHorse]

Так и на обычных HTTP GET / POST можно обойтись без апача или nginx

[VBart]

Eddy_Em
Картинки и прочий статический контент вы тоже будете при этом через веб-сокеты раздавать? Тогда я вас поздравляю, вы только что изобрели HTTP заново.

[Eddy_Em]

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

[Дмитрий]

Спасибо за Вашу перепалку! ;) Она помогла мне понять главное, что вызывает «кашу в голове». Я думал, что веб-сервер это приложение обязательно выдающее html на выходе. Но ошибался, его роль только лишь в общении по HTTP-трафику, куда и вставляется возможный html, однако это не единственный тип контента который может быть помещен в http-ответ.

Все верно?

[VBart]

Под веб-сервером чаще всего понимают сервер обслуживающий веб-клиентов (причем как непосредственно само серверное приложение, так и железку) по одному из веб-протоколов (это может быть HTTP в том или ином виде — over TLS, over SPDY, сейчас ещё WebSocket), а также в принципе программу, чьим основным назначением является раздача контента по веб-протоколам.

Eddy_Em Там, где нужны вебсокеты, статики обычно почти нет.
Будь оно так, то одним из основным feature request-ов за последнее время не была бы поддержка проксирования веб-сокетов nginx-ом.