Устройство динамического сайта

Для того, чтобы ближе познакомиться с принципами работы динамических сайтов, построенных на базе технологий стороны сервера, предлагаю в общих чертах рассмотреть процессы, происходящие на сервере в промежутке между получением HTTP-запроса от клиента и отправкой последнему HTTP-ответа с содержащимся в теле сообщения запрошенным объектом.
(Ограничимся в рамках нашего экскурса только запросами, использующими методы GET и POST, и ответами, характеризующимися кодом статуса 200 — OK. Случаи перенаправлений, ошибок и т. д. будут при необходимости затрагиваться в дальнейших главах.)
В самом простейшем случае сервер отправляет клиенту содержимое дискового файла, идентифицируемого запрошенным URI, никак не обрабатывая эти данные. (Динамическое сжатие при помощи алгоритмов gzip или deflate, автоматическую перекодировку текста в зависимости от предпочтений, указанных в поле Accept-Charset клиентского запроса, и прочие возможные преобразования общего характера, применяемые к любым отправляемым объектам того или иного типа, не принимаем во внимание. Тем более что многие реальные серверы и не настроены на использование подобных возможностей.)
Эта ситуация описывает работу статических сайтов. Обработка запросов, заключающаяся в отправке клиенту содержимого готовых файлов, происходит весьма быстро. Статические страницы не представляют никаких угроз безопасности сервера. Но для нас все это уже малоинтересно; наш разговор — о «динамике».
Несмотря на великое многообразие динамических серверных веб-технологий, можно выделить две ключевых концепции динамического формирования документов на стороне сервера.
Первый подход состоит в том, что сервер (сообразно своим настройкам) рассматривает некоторые файлы как исполняемые программные модули. Получив запрос клиента с указанием URI такого файла, сервер запускает этот модуль на исполнение, при необходимости передавая ему данные, полученные от клиента. Клиенту же возвращается результат работы (вывод) данного исполняемого модуля, например, сгенерированная «на лету» веб-страница, содержимое которой так или иначе зависит от переданных клиентом параметров.
Необходимо подчеркнуть, что в данном случае сервер ни при каких условиях не должен возвращать клиенту содержимое (код) самого программного модуля.
Примечание. Программные модули, о которых шла речь выше, могут быть как автономными (скомпилированными в исполняемый бинарный код), так и созданными с использованием интерпретируемых языков программирования. Разумеется, в последнем случае для работы того или иного программного модуля необходим интерпретатор соответствующего языка.
Интерпретируемые программные модули в веб-разработке чаще называют сценариями или скриптами (а интерпретируемые языки программирования — языками сценариев или скриптовыми языками). Хотя, скажем, и автономные CGI-приложения, написанные на языках C или C++, нередко именуют CGI-скриптами.
Другой подход основан на том, что некоторые категории файлов веб-страниц сервер (опять же, руководствуясь собственными настройками) не отправляет клиенту сразу же, а подвергает их определенной предварительной обработке.
Сервер исследует такие файлы на наличие в них специально оформленных директив или фрагментов кода, написанных с использованием интерпретируемых языков программирования.
Подобные элементы обрабатываются (самим сервером или дополнительными модулями к нему — на данном этапе обсуждения этот вопрос не столь принципиален), и в конечный документ, отправляемый клиенту, включаются уже не сами директивы или код скриптов, а результаты их выполнения.
Классическим примером технологии, эксплуатирующей эту концепцию, является SSI (см. главу 3).
Примечание
Приложения, написанные на языках Perl или PHP, могут использовать обе описанные идеологии. Работа подобных скриптов в рамках первого подхода обеспечивается благодаря использованию интерфейса CGI и внешнего интерпретатора того или иного языка сценариев. Функционирование Perl- и PHP-скриптов в рамках второго подхода реализуется обычно при помощи модулей mod_perl и mod_php (здесь имеются в виду модули для веб-сервера Apache).
Достоинствам, недостаткам и особенностям каждой из концепций мы уделим внимание уже в последующих главах.
Большинство серверных веб-приложений активно использует возможности систем управления базами данных.
СУБД обеспечивают структурированное хранение весьма существенных объемов информации, позволяя быстро и удобно находить, просматривать (в т. ч. в отсортированном виде), модифицировать, удалять или добавлять те или иные порции данных.
Веб- и интранет-решения используют, в основном, СУБД архитектуры клиент/сервер. Сервер баз данных никак не связан с веб-сервером — он работает совершенно независимо и при необходимости может выполняться даже на другой физической машине.
Сервер баз данных предоставляет возможность взаимодействия с ним самым разнообразным клиентам при помощи некоторого API (Application Program Interface, интерфейс прикладной программы).
Веб-приложения, взаимодействующие с базами данных, как нетрудно догадаться, как раз и выполняют роль таких клиентов.
Пока же, полагаю, общетеоретических рассуждений достаточно. Переходим к практическому знакомству с веб-сервером.


© 2008-2018 ОптимизацияВебСайтов.ру


Любое использование текстового и графического контента сайта без активной ссылки на источник не доскается.