Принципы функционирования веб-сервера. Что такое веб сервер? Для чего нужен веб сервер

Со временем любой веб-разработчик (блогер, веб-дизайнер или веб-программист ) будет нуждаться в специальной тестовой площадке, где можно без особых проблем заниматься разработкой сайта или тестированием другого веб проекта. Некоторые новички используют ресурсы своего платного хостинга и размещают туда минимум два сайта. Один рабочий (основной ), а другой (дополнительный ) для тестирования. Тестовый сайт подвергается различным испытаниям (установка и проверка многих плагинов, тем, скриптов и так далее ).

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

Почему нельзя?

Вы уже, наверное знаете, чтобы поместить свой сайт в Интернет, нужно зарегистрировать доменное имя, купить хостинг, то есть дисковое пространство на каком-то компьютере с высокоскоростным подключением, на котором могут работать PHP скрипты. Чтобы сайты полноценно работали, должен быть установлен PHP и MySQL. Все это не доступно на обычном компьютере. Как могут запускаться файлы HTML и PHP на вашем компьютере?

Обычный файл можно открыть с помощью Notepade++ или даже с блокнота. Там внутри что-то написать, сохранить и потом без особых проблем открыть данный файл на своем браузере и посмотреть, как бы этот файл выглядел на хостинге в Интернете. То есть мы уже видим рабочую HTML страницу. В ней мы можем создавать определенный дизайн, контент и наблюдать за проектом без подключения к Интернету. Все, по сути, у нас уже есть. Если мы захотим запустить PHP файл с помощью браузера, то у нас ничего не получится, так как PHP скрипты в операционной системе Windows без дополнительного программного обеспечения работать не будут.

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

Что такое сервер?

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

Для этого нам понадобятся специальные программы. Но какие лучше подойдут и какие трудности они могут вызывать при дальнейшей работе? Для ознакомления, ниже я привожу самые лучшие веб сервера по популярности во всем мире. Однако это не значит, что их нужно сразу устанавливать. Я потом объясню почему!

Список лучших веб серверов

В настоящее время на рынке присутствуют несколько решений от самых разных производителей:

• (сайт — apache.org ) — это самый распространенный и популярный бесплатный сервер в сети. Он является более надежным и гибким. Сервер не требователен к ресурсам процессора и способен обслуживать множество сайтов. Приложение доступно для широкого спектра операционных систем, включая Unix, Linux, Solaris, Mac OS X, Microsoft Windows и другие. На данный момент использование Apache составляет 71 %. Однако, это сложная программа, с которой не каждый новичок сможет справится.

• (сайт — www.iis.net ) — еще один надежный сервер от компании Microsoft. Он жестко укрепился на втором месте с 14 % использования в сети. После установки программы, будут поддерживаться только два языка программирования (VBScript и JScript ). Однако, можно открыть дополнительные возможности, установив для этого нужные расширения. С установкой таких модулей, функциональность данного сервера значительно повышается.

• NGINX (сайт — nginx.org/ru/ ) — это наиболее популярный веб-сервер в российском Интернете. По сравнению с двумя первыми, он является наиболее простым и не обладает лишними функциями. Также его хвалят за надежность и высокую скорость работы. Разработчиком данного продукта является наш соотечественник — Игорь Сысоев. В 2004 году он выпустил первую версию nginx. Сейчас этот программный продукт замыкает тройку самых популярных веб серверов в мире. Его использование составляет около 6,5 %.

• (сайт — litespeedtech.com ) — этот веб сервер не обладает широкими возможностями, но зато у него очень большая скорость работы. По быстродействию он сильнее популярного Apache в 9 раз. Немало внимания уделено и безопасности (своя защита от перегрузки системы, строгая проверка http-запросов, анти-ddos и многое другое ). LiteSpeed доступен для Solaris, Linux, FreeBSD и Mac OS X. Доля использования этой программы составляет 1,5 %.

Конечно же, есть много и других подобных программ, но доля их использования и доверия среди пользователей не так высока как у этих. К сожалению, одной такой программой вам не обойтись. Мало того, что их целесообразно использовать для работы с крупными проектами, так еще может возникнуть сложность в установке и настройке. К тому же помимо таких серверов требуется еще отдельная установка и настройка некоторых программ (например, для работы с базой данных ). Все это вызывает существенные трудности у многих пользователей. Как быть в таком случае?

Особенности локального сервера

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

То есть локальный сервер — это не одна программа (не один конкретный веб сервер ), а специальный сборник, куда входят облегченные варианты сложных серверных программ. Обычно в сборку входят: сам сервер (в основном Apache, но могут быть и другие ), компилятор PHP (с его помощью браузер может прочитать коды и собрать страницу ), компоненты для работы с базами данных, различные установщики и многие другие программы. Все это значительно упрощает дело, нежели если бы мы устанавливали и настраивали каждую программу в отдельности.

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

Обзор популярных локальных серверов

Вот некоторые сборки, которые могут пригодиться вам:

• (сайт — denwer.ru ) — это бесплатный отечественный сервер, который предназначен для работы с сайтами, веб-приложениями или Интернет страницами. Его разработчиками являются Дмитрий Котеров и Антон Сущев. Данный продукт содержит необходимые дистрибутивы для упрощенной работы. Например, сюда входит веб-сервер Apache с различной поддержкой, панель phpMyAdmin и MySQL для работы с базами данных и другие программы. Также можно работать со съемной флешки. К сожалению Denwer поддерживает только операционную систему Windows.

• XAMPP (сайт — www.apachefriends.org/en/xampp.html ) — специальная сборка сервера от друзей Apache. Необходимые дистрибутивы позволяют запустить на нем полноценный веб сервер. Данная программа распространяется бесплатно и поддерживает работу в системе Windows, Solaris, Mac OS X и Linux. Также есть следующие преимущества: сервер популярен своим очень простым пользовательским интерфейсом, что делает его любимым для многих начинающих; наблюдается многократные появления обновленных версий; процесс обновления проходит очень просто и удобно для пользователя; присутствуют дополнительные модули. Скачать нужную версию вы также можете с другого официального сайта — sourceforge.net/projects/xampp/files .

• (сайт — www.appservnetwork.com ) — отличный сервер от тайского производителя, концепцией которого является легкая установка и настройка всех дистрибутивов за 1 минуту. Первый релиз сборки состоялся в 2001 году и с тех пор количество пользователей все время растет. AppServ очень прост в установке, он работает стабильно и не хуже официальных и отдельных релизов, а его надежная производительность дает возможность создать полноценный веб сервер на вашем компьютере.

• (сайт — vertrigo.sourceforge.net ) — еще один неплохой и простенький в установке локальный сервер. Сборка очень гибкая, имеет хорошую производительность и занимает мало места на диске. К сожалению, пока работает только на ОС Windows.

• Zend Server Community Edition (сайт — www.zend.com ) — бесплатный сервер от компании Zend, предназначен для работы с веб-приложениями. Содержит все необходимые компоненты для быстрого развертывания локального сервера на своем компьютере.

• (сайт — open-server.ru ) — это отечественный портативный локальный сервер, который обладает высоким функционалом по разработке и созданию сайтов и других веб проектов. Имеет мультиязычный интерфейс (в том числе и русский ) и предназначен для работы в ОС Windows. Поддерживается работа со съемного носителя. Данный сервер очень хорош и служит неплохой альтернативой Денверу.

• (сайт — wampserver.com ) — еще одна неплохая сборка с русским интерфейсом (есть также и другие языки ). Имеется простое и понятное меню, а удобная установка и настройка сборки не вызывает особых трудностей. Настройку можно производить не затрагивая файлы конфигураций, что очень полезно начинающим веб-мастерам. Сервер распространяется бесплатно и работает только на платформе Windows. К сожалению, портативной версии пока нет.

• (сайт — easyphp.org ) — очень простенькая сборка с поддержкой русского языка. Сборка ни чем не примечательна, не имеет огромного функционала и в основном предназначена для тестирования небольших проектов. Есть поддержка работы с портативных носителей. Данный сервер послужит неплохой заменой Денверу.

Итак, это были наиболее популярные веб серверы, которые заслуживают внимания среди веб-мастеров. Как видите, здесь есть что выбрать. Скачать понравившийся сервер и подробно узнать состав его сборки вы можете на официальных сайтах, которые были указаны в описании. Скачивать данные сборки я вам рекомендую только с официальных сайтов, так как на других площадках могут выкладывать нерабочие дистрибутивы или с какими-нибудь вирусами. Теперь у многих отпадет желание «насиловать» свой хостинг, так как с таким ПО процесс создания сайтов и веб приложений станет более интересным и увлекательным! В общем, изучайте и внедряйте!

(521 оценок, среднее: 5,00 из 5)

Как правило, у рядового пользователя такие понятия, как «веб-сервер» или «хостинг», ассоциируются с чем-то абсолютно непонятным. Между тем, ничего сложного в этом вопросе нет. Попытаемся объяснить, что собой представляет web server, зачем он нужен и как работает, особо не вдаваясь в технические подробности, а, так сказать, на пальцах. Отдельно остановимся на вопросе о том, как создать и настроить такой сервер на домашнем компьютерном терминале или ноутбуке.

Что такое веб-сервер?

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

Но это абсолютно не значит, что в домашних условиях нельзя создать собственную конфигурацию. Поскольку у нас более распространенными являются операционные системы Windows, вопросы о том, как создать веб-сервер на Ubuntu (Linux), рассматриваться не будут.

Для чего нужны web-серверы?

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

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

Как это все работает?

Все пользователи привыкли, что для входа на какой-то ресурс в интернете (веб-страницу), на котором располагается информация определенного типа, в адресной строке просто вводится префикс www (или http) и последующее имя. Но никто не задумывается о том, каким образом web server понимает запрос и выдает результат.

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

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

Самые популярные web-серверы

Из всего серверного программного обеспечения, как считается, самыми распространенными являются Apache и Microsoft IIS. Первый является более популярным и в большей степени используется в UNIX-подобных системах, хотя и может устанавливаться в среду Windows. Кроме того, сервер Apache является абсолютно бесплатным программрным обеспечением и совместим практически со всеми известными операционными системами. Однако, как отмечается, предназначено это ПО в основном для профессиональных программистов и разработчиков.

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

Тем не менее, если исходить из официальной статистики, программное обеспечение Apache использует порядка 60% всех существующих серверов, поэтому вопрос установки и настройки начальной конфигурации рассмотрим именно на его примере.

Веб-сервер на домашнем компьютере: установка

Для инсталляции потребуется скачать специальный серверный пакет, сокращенно обозначаемый как WAMP, в который входит три основных компонента:

• Apache - программная оболочка сервера, которая может работать самостоятельно, но только в случае отсутствия на размещаемых страницах динамического контента.
• PHP - язык программирования, используемый надстройками для управления серверами с динамическим содержимым вроде WordPress, Joomla, Drupal.
• MySQL - унифицированная система управления базами данных, используемая, опять же, при создании сайтов с динамическим контентом.

Инсталляцию можно произвести из пакета WampServer. Для этого достаточно следовать указаниям «Мастера», который на одной из стадий предложит выбрать интернет-браузер, который будет использоваться по умолчанию.

Для этого нужно будет перейти в папку с исполняемым файлом браузера (если это не Internet Explorer, обычно она располагается в директории Program Files). Попутно сам браузер следует добавить в список исключений брэндмауэра Windows. На финишной стадии ставится галочка напротив пункта немедленного запуска, после чего в системном трее появится соответствующий значок, на который нужно нажать и изменю выбрать запуск локального хоста (localhost).

Если все сделано правильно, появится домашняя страница сервера. Далее будет предложено инсталлировать дополнительные компоненты (если этого не сделать, система выдаст ошибку). В основном инсталляция касается дополнительных надстроек, элементов и компонентов, которые будут использоваться сервером в дальнейшем.

Пример настройки и тестирования сервера

Настройка веб-сервера несколько сложнее. Сначала в меню системного трея выбирается переход в папку WWW (место хранения надстроек или файлов HTML). После этого прописать следующий текст в «Блокноте»:

Привет!

Можете просто скопировать текст в «Блокнот» и сохранить файл под именем index.php в той самой папке WWW (хотя можно обойтись и без того, поскольку этот шаг применяется исключительно для проверки локального хоста). Вместо приветствия можете вставить любой другой текст или фразу.

Затем в браузере нужно обновить страницу (F5), после чего на экране отобразится содержимое. Но для других компьютеров страница будет недоступна.

Чтобы открыть доступ, нужно изменить файл httpd.conf, прописав в разделе, который начинается с следующие строки:

Order Allow,Deny

Вместо послесловия

Конечно, что касается понимания сути функционирования или настроек домашнего веб-сервера, здесь приведена только самая начальная и краткая информация, так сказать, для общего понимания. На самом же деле все процессы являются намного более сложными, особенно в части преобразования запросов и выдачи ответов, не говоря уже о настройках сервера в домашних условиях. Если у пользователя есть желание разобраться в этих вопросах, тут не обойтись хотя бы без начальных знаний той же надстройки WordPress и языка PHP. С другой стороны, для публикации примитивных страниц, содержащих в основном только текстовую информацию, можно использовать и эти начальные сведения.

Инструкция

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

Когда на веб-сервере создается сайт, то ему присваивается IP-адрес. IP – аббревиатура, «интернет-протокол». IP-адрес состоит из десяти цифр с точками (например, 127.21.61.137). Для того чтобы сделать запрос у веб-сервера о том или ином сайте, браузер на компьютере сначала должен узнать IP-адрес этого сайта. Если этой информации нет в кэше браузера, то он делает соответствующий запрос у DNS-сервера через интернет.

Затем DNS-сервер сообщает браузеру, по какому IP-адресу расположен данный сайт. После этого браузер запрашивает URL-адрес сайта у веб-сервера. Сервер откликается, отправляя запрашиваемую страницу. Если этой страницы не существует, сервер отправляет сообщение об ошибке. Браузер получает сообщение и отображает его.

В профессиональной сфере в такой ситуации браузер называют «клиент», а веб-сервер - «сервер». Также эти понятия относятся к компьютерам. Те компьютеры, которые выступают в качестве веб-серверов, называются серверы, а те, которые подключаются к интернету, чтобы получить информацию – клиенты.

Веб-сервер обычно содержит информацию о более чем одном сайте. Многие хостинговые компании предоставляют место сотням и даже тысячам веб-сайтам на одном веб-сервере. Каждому веб-сайту обычно приписывается свой уникальный IP-адрес. Этот адрес расшифровывается DNS-сервером с целью получения доменного имени.

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

Каждый компьютер-сервер предоставляет доступ к хранящейся на нем информации, используя пронумерованные порты. У каждой предоставляемой сервером услуги (электронная почта, хостинг) имеется свой отдельный порт. Клиенты подключаются к услуге через IP-адрес и через порт.

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

Каждый веб-сервер согласуется с протоколом HTTP. Самая элементарная форма взаимодействия, понимаемая сервером HTTP, содержит всего одну команду: «Получить». Первоначально протокол ограничивался тем, что сервер отправлял клиенту запрашиваемый файл и отключался. Позднее протокол был усовершенствован, и клиенту стал отсылаться весь URL.

Когда пользователь печатает в строке браузера название ссылки URL, то браузер разбивает название на три части: протокол, название сервера, название файла. Браузер получает информацию об IP-адресе сайта через название сервера, и с его помощью подключается к компьютеру-серверу. Затем браузер соединяется с веб-сервером по этому IP-адресу через порт. Следуя протоколу, браузер посылает серверу команду «Получить». Сервер отправляет текст в формате HTML на веб-страницу. Браузер считывает HTML- тэги и форматирует страницу для экрана компьютера-клиента.

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

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

Цель лекции: дать определение понятию "веб-сервер" и сформировать представление о работе этого механизма.

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

После того, как пользователь обратился к определенному ресурсу по протоколу HTTP, клиент (обычно браузер) формирует HTTP-запрос к веб-серверу. Обычно указывается символическое имя сервера (например, "http://www.microsoft.com ") – в этом случае браузер предварительно преобразует это имя в IP-адрес при помощи сервисов DNS. После этого по протоколу HTTP на веб-сервер отправляется сформированное HTTP-сообщение. В этом сообщении браузер указывает какой ресурс необходимо загрузить и всю дополнительную информацию. Задача веб-сервера – прослушивать определенный TCP-порт (обычно порт 80) и принимать все входящие HTTP-сообщения. Если входящие данные не соответствуют формату сообщения HTTP, то такой запрос игнорируется, а клиенту возвращается сообщение об ошибке.

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

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

Нередко на одном и том же веб-сервере располагается множество независимых веб-сайтов. Более того, все эти веб-сайты используют один и тот же IP-адрес. Т.е. веб-сервер, имеющий только один IP-адрес может размещать внутри себя несколько веб-сайтов и при этом каждый такой веб-сайт будет ассоциирован с собственным адресом (например, на одном веб-сервере могут располагаться веб-сайты: "microsoft.com", "gotdotnet.ru", "techdays.ru" и т.д.). Каким образом это становится возможным? Такое явление называется виртуальным хостингом . Для того чтобы понять как это работает, давайте еще раз обратимся к процессу взаимодействия клиента и сервера. Браузер отправляет HTTP-запрос на IP-адрес веб-сервера, который ассоциирован с доменным именем. Разрешение IP-адреса происходит с помощью служб DNS. Однако, несмотря на то, что запрос отправляется, используя полученный IP-адрес, клиент указывает дополнительный HTTP-заголовок "Host ", в котором определяется оригинальное имя веб-сайта. Благодаря этой информации веб-сервер может разграничить доступ к нескольким веб-сайтам и при этом использовать один и тот же IP-адрес. Это очень важный момент, поскольку если бы для каждого доменного имени приходилось бы регистрировать отдельный IP-адрес, то адресное пространство протокола IP (v.4) очень быстро бы закончилось, а стоимость размещения веб-сайта в глобальной сети Интернет была бы намного выше. Для того, чтобы было более понятно давайте рассмотрим работу виртуального хостинга на примере. Предположим, имеется веб-сервер с IP-адресом 85.51.210.22. На этом сервере размещено несколько веб-сайтов: mysite1.com, mysite2.com, mysite3.com. Сервера DNS настроены таким образом, что каждое из этих доменных имен указывает на единственный IP-адрес 85.51.219.22. Давайте посмотрим, какие HTTP-запросы браузер будет генерировать при обращении к каждому из сайтов. При обращении к сайту "mysite1.com" HTTP-запрос может выглядеть следующим образом.

При обращении к сайту "mysite2.com" HTTP-запрос будет выглядеть иначе.

При анализе HTTP-запросов хорошо видно, что HTTP-заголовок "Host " отличается в каждом из запросов. Таким образом, становится понятно, что веб-сервер анализирует этот заголовок и отправляет клиенту содержимое соответствующего сайта. Схематически этот процесс можно представить следующим образом.

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

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

• программный код, реализующий служебные функции по взаимодействию через протокол HTTP (программный код самого веб-сервера);
• программный код, реализующий логику конкретного веб-приложения (бизнес-логика, обращение к СУБД и т.д.).

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

Исторически сложилось так, что существует два главных типов интерфейс взаимодействия внешнего приложения и веб-сервера - CGI и ISAPI.

CGI (Common Gateway Interface) – наиболее ранний способ взаимодействия веб-сервера и веб-приложения. Основная идея, которая лежит в основе CGI заключается в том, что при поступлении очередного HTTP-запроса, веб-сервер инициирует создание нового процесса и передает ему все необходимые данные HTTP-запроса. После того, как этот процесс отработает, он завершается, передав при этом результат обратно веб-серверу. Поскольку веб-сервер и приложение – это разные процессы с точки зрения операционной системы, то для обмена информации между ними используются средства межпроцессного взаимодействия (IPC) – зачастую это переменные окружения, именованные каналы и т.д. Основным преимуществом CGI является то, что процесс веб-сервера и приложения изолированы друг от друга и в случае неполадок в веб-приложении, завершится с ошибкой именно процесс приложения, при этом процесс самого веб-сервера будет продолжать функционировать.

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

ISAPI (Internet Server API) – альтернативный способ взаимодействия веб-сервера и веб-приложения. В отличии от CGI, при взаимодействии в рамках интерфейса ISAPI, при поступлении очередного запроса, веб-сервер инициирует создание нового потока в рамках основного процесса, в котором работает веб-сервер. Поскольку с точки зрения операционной системы создание потока – это менее дорогостоящая операция, чем создание процесса, то такие приложения на практике оказываются более масштабируемыми. Кроме того, упрощается взаимодействие веб-сервера и веб-приложения, поскольку в этом случае используется единое адресное пространство в рамках операционной системы (поскольку весь код работает в одном и том же процессе). Однако, в случае серьезных неполадок в веб-приложении, которое взаимодействует с веб-сервером в рамках ISAPI, веб-сервер также потенциально подвергается риску быть завершенным. Поскольку веб-сервер и веб-приложение работают в одном и том же процессе, это действительно так. Поэтому разработчикам программного кода веб-сервера, поддерживающего ISAPI следует уделить этому вопросу особое внимание.

На сегодняшний день наиболее распространенным способом взаимодействия веб-сервера и веб-приложения является интерфейс ISAPI, поскольку обеспечивает наиболее оптимальные показатели по накладным расходам и масштабируемости. Однако, при работе нескольких веб-приложений на одном и том же веб-сервере, в этом случае существует потенциальная опасность влияния одного приложения на другое. Если говорить о компаниях, размещающих веб-приложения на своих серверах, то может случиться такая ситуация, что на одном и том же веб-сервере одновременно размещаются веб-сайты компаний-конкурентов. В этом случае теоретически одна из компаний может намеренно загрузить код, который будет завершать работу веб-сервера с ошибкой и, таким образом, все веб-сайты размещенные на этом веб-сервере окажутся недоступными. Для того, чтобы избежать подобной ситуации используется совмещенный подход – для каждого приложения может создаваться пул приложения (application pool), который представляет из себя отдельный процесс, в котором функционируют потоки для обработки входящих HTTP-запросов от пользователей. В этом случае, если какое-то из приложений будет содержать код, который завершает работу процесса с ошибкой, то будет завершаться процесс только этого приложения. Более того, каждый пул приложения содержит набор заранее созданных и подготовленных потоков. Это необходимо для того, чтобы не тратить время на создание потока в момент поступления входящего запроса. Такой набор заранее созданных потоков называется пулом потоков . Как правило, веб-сервер следит за каждым пулом приложения и если оно завершает свою работу с ошибкой, то веб-сервер перезапускает его процесс.

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

На сегодняшний день существует большое количество различных реализаций веб-серверов. Одним из наиболее популярных и универсальных веб-серверов является веб-сервер с открытым исходным кодом Apache. Он был создан для работе в среде Linux, также существует реализация для работы в рамках Windows. На его основе были построены другие различные вариации, например, Apache Tomcat для запуска веб-приложений на основе Java. Другим, наиболее серьезным продуктом в этой области является веб-сервер Microsoft Internet Information Services (IIS), который работает в рамках операционной системы Windows. Как правило, в рамках этого веб-сервера работают приложения на базе ASP.NET (и родственных технологий), а также приложения PHP и статические веб-сайты. При создании веб-приложений на базе ASP.NET мы будем использовать именно IIS 7. Наконец, существуют другие, менее масштабные проекты по разработке веб-серверов, например Nginx. Этот проект был разработан одним из разработчиков Rambler с целью оптимизации производительности этой поисковой системы. Впоследствии проект оказался настолько удачным, что нашел применение и для работы в других приложений. Обычно Nginx используют когда необходимо построить высоконагруженную инфраструктуру.

Краткие итоги

Веб-сервер – это программа, которая обрабатывает входящие HTTP-запросы и генерирует HTTP-ответы. В простейшем случае веб-сервер передает клиенту содержимое файлов, которые размещены на жестком диске сервера. Когда необходимо генерировать HTTP-ответы на основе какой-то программной логики, подключается внешний программный код. Для подключения внешнего программного кода используются интерфейсы CGI и ISAPI. В настоящий момент наиболее перспективным считается использование интерфейса ISAPI в силу более высокой масштабируемости. В рамках веб-сервера создается пул приложения (для каждого веб-приложения отдельный процесс в рамках ОС, в составе которого работает несколько потоков для обработки запросов). Существует большое количество реализаций веб-серверов, для приложений ASP.NET обычно используется веб-сервер Microsoft Internet Information Services (IIS).

Контрольные вопросы

• Что такое веб-приложение?
• Что такое браузер?
• Опишите цикл обработки запроса к веб-приложению от клиента.
• Для чего необходимы технологии разработки веб-приложений (такие как ASP.NET, PHP, Ruby On Rails и др.).
• Как работает протокол HTTP и для чего он нужен?
• Что такое заголовки HTTP-сообщения и для чего они нужны?
• Что такое тело HTTP-сообщения?
• Каким образом в HTTP-сообщении заголовки отделяются от тела сообщения?
• Что такое метод HTTP-запроса?
• Что такое статусный код HTTP-ответа?
• Приведите примеры HTTP-заголовков HTTP-запроса и HTTP-ответа.
• Чем отличаются симметричные алгоритмы шифрования от асимметричных?
• Как работает защищенный протокол HTTPS?
• Что такое веб-сервер?
• На основе каких интерфейсов может взаимодействовать веб-сервер и веб-приложение?
• Чем CGI отличается от ISAPI?
• Что такое виртуальный хостинг?
• Что такое пул приложения?
• Назовите наиболее популярные реализации веб-серверов.
• В рамках какого веб-сервера работают приложения ASP.NET?

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

Если не знаешь с чего начать, то начинать надо сначала. Чтобы не запутаться во всем многообразии современных веб-технологий нужно обратиться к истории, чтобы понять, с чего начинался современный интернет и как развивались и совершенствовались технологии.

HTTP-сервер

На заре развития интернета сайты представляли собой простое хранилище специальным образом размеченных документов и некоторых связанных с ними данных: файлов, изображений и т.п. Для того, чтобы документы могли ссылаться друг на друга и связанные данные был предложен специальный язык гипертекстовой разметки HTML, а для доступа к таким документам посредством сети интернет протокол HTTP. И язык, и протокол, развиваясь и совершенствуясь, дожили до наших дней без существенных изменений. И только начавший приходить на смену принятому в 1999 году протоколу HTTP/1.1 протокол HTTP/2 несет кардинальные изменения с учетом требований современной сети.

Протокол HTTP реализован по клиент-серверной технологии и работает по принципу запрос-ответ без сохранения состояния. Целью запроса служит некий ресурс, который определяется единым идентификатором ресурса - URI (Uniform Resource Identifier ), HTTP использует одну из разновидностей URI - URL (Uniform Resource Locator ) - универсальный указатель ресурса , который помимо сведений о ресурсе определяет также его физическое местоположение.

Задача HTTP-сервера обработать запрос клиента и либо выдать ему требуемый ресурс, либо сообщить о невозможности это сделать. Рассмотрим следующую схему:

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

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

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

Сайты того времени вообще мало походили на современные, например, ниже показан вид одного из пионеров русскоязычного интернета, сайт компании Rambler:

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

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

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

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

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

CGI

Следующим шагом в развитии веб-технологии стало появление специальных программ (скриптов) выполняющих обработку запроса пользователей на стороне сервера. Чаще всего они пишутся на скриптовых языках, первоначально это был Perl, сегодня пальму лидерства удерживает PHP. Постепенно возник целый класс программ - системы управления контентом - CMS (Content management system ), которые представляют полноценные веб-приложения способные обеспечить динамическую обработку запросов пользователя.

Теперь важный момент: веб-сервера не умели и не умеют выполнять скрипты, их задача - отдача статического содержимого. Здесь на сцену выходит новая сущность - сервер приложений, который представляет собой интерпретатор скриптовых языков и с помощью которого работают написанные на них веб-приложения. Для хранения данных обычно используются СУБД, что обусловлено необходимостью доступа к большому количеству взаимосвязанной информации.

Однако сервер приложений не умеет работать с протоколом HTTP и обрабатывать пользовательские запросы, так как это задача веб-сервера. Чтобы обеспечить их взаимодействие был разработан общий интерфейс шлюза - CGI (Common Gateway Interface ).

Следует четко понимать, CGI - это не программа и не протокол, это именно интерфейс, т.е. совокупность способов взаимодействия между приложениями. Также не следует путать термин CGI с понятием CGI-приложения или CGI-скрипта, которыми обозначают программу (скрипт) поддерживающую работу через интерфейс CGI.

Для передачи данных используются стандартные потоки ввода-вывода, от веб-сервера к СGI-приложению данные передаются через stdin , принимаются назад через stdout , для передачи сообщений об ошибках используется stderr .

Рассмотрим процесс работы такой системы подробнее. Получив запрос от браузера пользователя веб-сервер определяет, что запрошено динамическое содержимое и формирует специальный запрос, которой через интерфейс CGI направляет веб-приложению. При его получении приложение запускается и выполняет запрос, результатом которого служит HTML-код динамически сформированной страницы, который передается назад веб-серверу, после чего приложение завершает свою работу.

Еще одно важное отличие динамического сайта - его страницы физически не существуют в том виде, который отдается пользователю. Фактически имеется веб-приложение, т.е. набор скриптов и шаблонов, и база данных, которая хранит материалы сайта и служебную информацию, отдельно располагается статическое содержимое: картинки, java-скрипты, файлы.

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

К достоинствам CGI можно отнести языковую и архитектурную независимость: CGI-приложение может быть написано на любом языке и одинаково хорошо работать с любым веб-сервером. Учитывая простоту и открытость стандарта это привело к бурному развитию веб-приложений.

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

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

FastCGI

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

FastCGI устраняет основную проблему CGI - повторный запуск процесса веб-приложения на каждый запрос, FastCGI процессы запущены постоянно, что позволяет существенно экономить время и ресурсы. Для передачи данных вместо стандартных потоков используются UNIX-сокеты или TCP/IP , что позволяет размещать веб-сервер и сервера приложений на разных хостах, таким образом обеспечивая масштабирование и/или высокую доступность системы.

Также мы можем запустить на одном компьютере несколько FastCGI процессов, которые могут обрабатывать запросы параллельно, либо иметь различные настройки или версии скриптового языка. Например, можно одновременно иметь несколько версий PHP для разных сайтов, направляя их запросы разным FastCGI процессам.

Для управления FastCGI процессами и распределением нагрузки служат менеджеры процессов, они могут быть как частью веб-сервера, так и отдельными приложениями. Популярные веб-сервера Apache и Lighttpd имеют встроенные менеджеры FastCGI процессов, в то время как Nginx требует для своей работы c FastCGI внешний менеджер.

PHP-FPM и spawn-fcgi

Из внешних менеджеров для FastCGI процессов применяются PHP-FPM и spawn-fcgi. PHP-FPM первоначально был набором патчей к PHP от Андрея Нигматулина, решавший ряд вопросов управления FastCGI процессами, начиная с версии 5.3 является частью проекта и входит в поставку PHP. PHP-FPM умеет динамически управлять количеством процессов PHP в зависимости от нагрузки, перезагружать пулы без потери запросов, аварийный перезапуск сбойных процессов и представляет собой достаточно продвинутый менеджер.

Spawn-fcgi является частью проекта Lighttpd, но в состав одноименного веб-сервера не входит, по умолчанию Lighttpd использует собственный, более простой, менеджер процессов. Разработчики рекомендуют использовать его в случаях, когда вам нужно управлять FastCGI процессами расположенными на другом хосте, либо требуются расширенные настройки безопасности.

Внешние менеджеры позволяют изолировать каждый FastCGI процесс в своем chroot (смена корневого каталога приложения без возможности доступа за его пределы), отличном как от chroot иных процессов, так и от chroot веб-сервера. И, как мы уже говорили, позволяют работать с FastCGI приложениями расположенными на других серверах через TCP/IP, в случае локального доступа следует выбирать доступ через UNIX-сокет, как быстрый тип соединения.

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

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

SCGI, PCGI, PSGI, WSGI и прочие

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

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

И раз уж мы перечислили в заголовке целую пачку аббревиатур, то пройдем по ним более подробно.

SCGI (Simple Common Gateway Interface ) - простой общий интерфейс шлюза - разработан как альтернатива CGI и во многом аналогичен FastCGI, но более прост в реализации. Все, о чем мы рассказывали применительно к FastGCI справедливо и для SCGI.

PCGI (Perl Common Gateway Interface ) - библиотека Perl для работы с интерфейсом CGI, долгое время являлась основным вариантом работы с Perl-приложениями через CGI, отличается хорошей производительностью (насколько это применимо к CGI) при скромных потребностях в ресурсах и неплохой защиты от перегрузки.

PSGI (Perl Web Server Gateway Interface ) - технология взаимодействия веб-сервера и сервера приложений для Perl. Если PCGI представляет собой инструмент для работы с классическим CGI интерфейсом, то PSGI более напоминает FastCGI. PSGI-сервер представляет среду для выполнения Perl-приложений которая постоянно запущена в качестве службы и может взаимодействовать с веб-сервером через TCP/IP или UNIХ-сокеты и предоставляет Perl-приложениям те же преимущества, что и FastCGI.

WSGI (Web Server Gateway Interface ) - еще один специфичный интерфейс шлюза, предназначенный для взаимодействия веб-сервера с сервером приложений для программ, написанных на языке Phyton.

Как несложно заметить, все перечисленные нами технологии являются в той или иной степени аналогами CGI/FastCGI, но для специфичных областей применения. Приведенных нами данных будет вполне достаточно для общего понимания принципа и механизмов их работы, а более глубокое их изучение имеет смысл только при серьезной работе с указанными технологиями и языками.

Сервер приложений как модуль Apache

Если раньше мы говорили о неком абстрактном веб-сервере, то теперь речь пойдет о конкретном решении и дело здесь не в наших предпочтениях. Среди веб-серверов Apache занимает особое место, в большинстве случаев, когда говорят о веб-сервере на платформе Linux, да и о веб-сервере вообще, то подразумеваться будет именно Apache.

Можно сказать, что это своего рода веб-сервер "по умолчанию". Возьмите любой массовый хостинг - там окажется Apache, возьмите любое веб-приложение - настройки по умолчанию выполнены под Apache.

Да, с технологической точки зрения Apache не является венцом технологий, но именно он представляет золотую середину, прост, понятен, гибок в настройках, универсален. Если вы делаете первые шаги в сайтостроении - то Apache ваш выбор.

Здесь нас могут упрекнуть, что Apache уже давно неактуален, все "реальные пацаны" уже поставили Nginx и т.д. и т.п., поэтому поясним данный момент более подробно. Все популярные CMS из коробки сконфигурированы для использования совместно с Apache, это позволяет сосредоточить все внимание на работу именно с веб-приложением, исключив из возможного источника проблем веб-сервер.

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

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

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

Какие преимущества это дает? Чем проще схема и меньше в ней элементов, тем проще и дешевле сопровождать ее и обслуживать, тем меньше в ней точек отказа. Если для единичного сервера это может быть не так важно, то в рамках хостинга это весьма значительный фактор.

Второе преимущество - производительность. Снова огорчим поклонников Nginx, благодаря работе в едином адресном пространстве, по производительности сервера приложений Apache + mod_php всегда будет на 10-20% быстрее любого иного веб-сервера + FastCGI (или иное CGI решение). Но также следует помнить, что скорость работы сайта обусловлена не только производительностью сервера приложений, но и рядом иных условий, в которых альтернативные веб-сервера могут показывать значительно лучший результат.

Но есть еще одно, достаточно серьезное преимущество, это возможность настройки сервера приложений на уровне отдельного сайта или пользователя. Давайте вернемся немного назад: в FastCGI/CGI схемах сервер приложений - это отдельная служба, со своими, отдельными, настройками, которая даже может работать от имени другого пользователя или на другом хосте. С точки зрения администратора одиночного сервера или какого-нибудь крупного проекта - это отлично, но для пользователей и администраторов хостинга - не очень.

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

Решение нашлось довольно просто. Так как сервер-приложений теперь часть веб-сервера, то можно поручить последнему управлять его настройками. Традиционно для управления настройками Apache помимо конфигурационных файлов применялись файлы httaccess, которые позволяли пользователям писать туда свои директивы и применять их к той директории, где расположен данный файл и ниже, если там настройки не перекрываются своим файлом httaccess. В режиме mod_php данные файлы позволяют также изменять многие опции PHP для отдельного сайта или директории.

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

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

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

Второй минус - более высокое потребление ресурсов. В схеме с CGI сервер приложений генерирует страницу и отдает ее веб-серверу, освобождая ресурсы, связка Apache + mod_php держит ресурсы сервера приложений занятыми до тех пор, пока веб-сервер не отдаст содержимое страницы клиенту. Если клиент медленный, то ресурсы будут заняты на все время его обслуживания. Именно поэтому перед Apache часто ставят Nginx, который играет роль быстрого клиента, это позволяет Apache быстро отдать страницу и освободить ресурсы, переложив взаимодействие с клиентом на более экономичный Nginx.

Заключение

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

• Теги: