Объяснение того, как осуществляется доступ к языкам программирования на стороне сервера

Насколько я понимаю, любой язык программирования общего назначения можно использовать для разработки веб-сайта на стороне сервера.

Правильно ли я считаю, что серверу просто необходим какой-то интерфейс, такой как CGI, чтобы сервер и язык программирования работали вместе? Если так, то почему некоторые языки программирования (такие как php) более популярны, чем другие?

В первые дни в Интернете CGI был действительно единственным (практичным) способом иметь динамический контент (вы могли делать именованные каналы файлов - и они использовались за несколько дней до cgi, но это было непрактично).

CGI работает, помещая кучу информации в среду процесса, которая разветвляется и затем исполняется (и, возможно, некоторая часть в stdin), а затем забирает то, что выходит из stdout, и выплевывает это обратно в запросчик.

Это не волнует, что это за язык реализации. Действительно, я написал свои ранние CGI в те времена на C или C ++. Это было отчасти больно. Позже я изучил некоторый Perl в начале 90-х, и это было гораздо менее болезненным.

Это работает, до определенного момента. Проблема в масштабе. Каждый запрос CGI является ответвлением процесса. Тысячи запросов означают тысячи процессов. Это действительно не работает хорошо.

Решением этой проблемы является удаление разветвления и исключения путем перемещения его в поток на самом веб-сервере или отправки запроса другому процессу, который обрабатывает запрос без необходимости в форке и выполнении. mod_perl является одним из таких инструментов для этого (плагин, перемещающий Perl в Apache). Php (конец 90-х) также сделал это, внедрив язык как плагин в самом веб-сервере, а не как нечто, что было разветвлено и превзойдено. Это стало довольно популярным, так как он был похож на Perl (который был ранним доминирующим языком веб-программирования) и мог превзойти Perl CGIS. Этот период времени в середине 90-х годов все еще имеет достаточный импульс - до того, как более крупные серверы приложений корпоративного уровня начали внедрять более формальные языки. Если ты копаешься вокруг,

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

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

Но вот в чем дело - все решения в некотором роде, форме или форме несовершенны. CGI, в то время как легко имеет серьезные проблемы с масштабом. Плагины на веб-серверах привязываются к самому веб-серверу (apache против nginx против IIS против ...) и теряют общую функциональность языка. У Microsoft есть свой собственный парад технологий, которые она хотела бы продвигать. И если вы знаете один язык, вы бы предпочли не программировать на нем, а не использовать разные языки в разных частях стека (javascript в клиенте и Node.js)?

Итак, у вас сегодня. Некоторые люди работают в стеке Java (при этом scala и clojure становятся не редкостью). Другие в стеке C #. Другие в стеке JavaScript. Там довольно много php-стеков. Много питона. Вы все еще можете найти некоторые Perl-стеки (и если вы посмотрите на сайты с небольшим объемом, вы все равно найдете CGI). Благодаря облачным вычислениям Google также продвигает Go как жизнеспособный веб-язык на стороне сервера.

У каждого есть свои преимущества, недостатки, свои фреймворки и свои серверы. Относительная популярность этих приливов и отливов по мере изменения технологий вокруг них. Они делают разные вещи хорошо.

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

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

Например, я считаю, что PHP стал популярным для веб-сайтов, потому что:

• Очень просто перейти со статического веб-сайта на динамический веб-сайт PHP - просто замените расширение вашего HTML-файла, разместите <?phpтег в начале, и, если PHP установлен, у вас есть динамический веб-сайт! Остальная часть рабочего процесса точно такая же, как для статического сайта;
• Из-за этой простоты развертывания веб-хосты, которые хотели предлагать динамические веб-сайты, выбрали PHP, что делает его довольно быстро наиболее широко развернутой серверной платформой;
• Он попал на этот рынок в нужное время;

И как только PHP получил широкое распространение, стало интересно писать более серьезные веб-приложения на PHP, чтобы извлечь выгоду из этой широты развертывания.

Чтобы сказать это в более общем виде: принятие языка часто об ответах на эти вопросы:

• Насколько легко делать то, что я хочу сделать?
• Насколько широко поддерживается язык для того, что я хочу сделать?

Правильно ли я считаю, что серверу просто необходим какой-то интерфейс, такой как CGI, чтобы сервер и язык программирования работали вместе?

Почти. Вам нужен веб-сервер, на котором есть какое-то программное обеспечение, которое позволяет ему также отвечать на запросы HTTP.

Подумайте, как подается статическая страница. Сервер извлекает HTTP-запрос, находит запрошенный документ из файловой системы на основе конфигурации HTTP-сервера и возвращает статическую страницу.

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

 If so then why are some programming languages (such as php) more popular than others?

Старая структура CGI плохо масштабируется при большом количестве запросов. Различные языки программирования и платформы для Интернета существуют по разным причинам, и каждый из них делает разные вещи хорошо. PHP так же популярен, как и по историческим причинам, поскольку он был одним из первых простых и дешевых решений для обслуживания динамических страниц без использования CGI и имел широкую поддержку хостинга. ASP был популярен в кругах Microsoft, потому что он позволял разработчикам VB перенести свои навыки в Интернет. ASP.NET (Web Forms) позволил разработчикам Windows Forms, многие из которых были VB-программистами, очень легко переключаться на Интернет.

Когда браузер делает HTTP-запрос, он выглядит так:

GET /search?q=cats HTTP/1.0
Host: www.google.com
Connection: close

… На который сервер должен отправить ответ, который выглядит следующим образом:

HTTP/1.0 200 Success
Content-Type: text/html; charset=UTF-8
Content-Length: 1337

<!DOCTYPE html>
<html>
  <head><title>cats - Google Search</title>
  <body>
    <h1>About 415,000,000 results</h1>
    …
  </body>
</html>

Любой код, запущенный на сервере, который прослушивает запросы на сокете TCP, читает запрос и отвечает соответствующим ответом, будет достаточным. Один тупой способ - просто выдать постоянный ответ любому, кто подключается к TCP-порту 80, используя сценарий оболочки:

$ nc -l 8000 <<'RESPONSE'
HTTP/1.0 200 Success
Content-Type: text/html; charset=UTF-8
Content-Length: 1337

<!DOCTYPE html>
<html>
  <head><title>cats - Google Search</title>
  <body>
    <h1>About 415,000,000 results</h1>
    …
  </body>
</html>
RESPONSE

Конечно, этот метод только кажется, что соответствует протоколу HTTP .

На шаг впереди этого готового ответа - простая программа на Python, которая использует http.serverбиблиотеку в Python 3.

#!/usr/bin/python3

import http.server

class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        payload = '<!DOCTYPE html>... insert cats here ...'.encode('UTF-8')
        self.send_response(200)
        self.send_header('Content-Type', 'text/html; charset=UTF-8')
        self.send_header('Content-Length', len(payload))
        self.end_headers()
        self.wfile.write(payload)

http.server.HTTPServer(('', 80), Handler).serve_forever()

HTTP-сервер может быть написан на любом языке; это всего лишь пример. Очевидно, этот пример очень элементарный. Полезная нагрузка жестко запрограммирована - программа полностью игнорирует содержимое запроса - URL, строку запроса, заголовок Accept-Language и т. Д. Вы можете добавить код для генерации значимых ответов на основе запроса, но тогда код получится очень сложный. Кроме того, программисты скорее сосредоточатся на написании веб-приложения, не беспокоясь о деталях обработки HTTP-запроса.

Более подходящим решением будет использование веб-сервера, такого как Apache HTTPD , IIS или nginx . Веб-сервер - это просто программа, которая прослушивает соответствующие сокеты TCP, принимает несколько запросов (возможно, одновременно) и решает, как сгенерировать ответ, основываясь на URL-адресе запроса, заголовках и других правилах. В идеале многие детали, такие как SSL, контроль доступа и ограничения ресурсов, учитываются с помощью конфигурации, а не кода. В большинстве случаев веб-сервер формулирует ответ, который состоит только из содержимого файлов в файловой системе.

Однако для динамического содержимого веб-сервер может быть настроен на выполнение некоторого кода для генерации ответа. Один из механизмов для этого - CGI - сервер устанавливает некоторые переменные окружения на основе запроса, выполняет программу и копирует свои выходные данные в сокет TCP. Несколько более сложным решением было бы иметь модуль, который добавляет поддержку веб-сервера для вызова кода на другом языке программирования (например, mod_php для Apache ). Еще один вариант - написать веб-сервер на том же языке, что и веб-приложение, и в этом случае отправка запроса - это просто вызов функции. Это имеет место в случае с node.js и механизмами Java-сервлетов, такими как Apache Tomcat .

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

Веб-сервер - это программа, написанная на любом языке программирования, которая обрабатывает «веб-трафик» через сокеты, придерживаясь стандартов / протоколов уровня приложений (HTTP и т. Д.). Большинство языков программирования предлагают вам создать сокет.

Правильно ли я считаю, что серверу просто необходим какой-то интерфейс, такой как CGI, чтобы сервер и язык программирования работали вместе?

Нет необходимости иметь выделенную серверную программу и вашу прикладную программу - они могут быть одинаковыми (независимо от проблем, связанных с производительностью).

Вы можете использовать некоторую библиотеку HTTP- сервера, например, libonion , даже в вашей программе , написанной на C (или C ++, см. Также Wt ). Там также некоторая клиентская библиотека HTTP (например, libcurl )

Вы можете использовать другие библиотеки HTTP, например, ocsigen & ocamlnet для OCaml .

Существует несколько веб-выделенных языков (кроме PHP), например, Opa , HOP , Kaya и т. Д. (HOP и Opa могут легко смешивать вычисления на стороне сервера и на стороне браузера, но вам придется делать это болезненно и вручную, PHP, явно использующий методы AJAX и кодирующий вручную некоторые Javascript для браузера. Напротив, HOP, Opa, Ocsigen могут генерировать этот Javascript).

Вы также можете использовать технологию FASTCGI для добавления некоторого динамического сервиса на некоторый веб-сервер ... FASTCGI лучше, чем обычный CGI, который запускает новый процесс для каждого входящего HTTP-запроса, тогда как приложение FASTCGI может обслуживать множество HTTP-запросов в одном и том же процессе. Кстати, PHP может быть настроен для работы в качестве приложения FASTCGI.

C.Queinnec отметил, что просмотр веб-страниц и их продолжение существенно связаны.

PS. Я не люблю PHP, и я считаю, что его популярность имеет исторические и социальные причины (не в основном технические). Действительно, PHP был широко распространен задолго до того, как AJAX стал широко использоваться, и старше, чем HOP или Opa (или Ocsigen).