Web серверы. Веб-сервер (Web Server): для чего он нужен, как устроен и как работает. Самые распространенные сервера

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

Даже те, кто пока только мечтают о тысячах пользователей на своём сайте, наверняка задавались вопросом: “А сколько же пользователей мой сайт выдержит, если они зайдут одновременно?” Сразу вспоминается известное выражение “Хабраэффект” – явление отказа сайта, который оказался не готов к многочисленным переходам на него после появления в интернете ссылки.

Предположим, что сайт уже есть (или скоро будет): где же его разместить? Это должен быть классический хостинг или vps-сервер? Если vps, то какой и как его лучше настроить? А может быть вообще нет никакой разницы и проще выбрать то, что подешевле? В этой статье мы рассмотрим несколько вариантов и на практике убедимся, какой из них подойдёт лучше для нашего сайта.

Будем экспериментировать: ставить разные режимы работы сервера и замерять производительность. Нагрузку на сайт будем имитировать с помощью сервиса Loaddy.com. Там можно задать количество пользователей, нарастающий тип нагрузки и по графику будет видно, как сервер реагирует на них. Считается, что один пользователь генерирует примерно один запрос к сайту в течение 10 секунд. В качестве испытуемого сайта возьмем демонстрационный интернет-магазин на cms moguta. Он будет заполнен тестовыми «товарами», которые выводятся на главную страницу по нескольким критериям (то есть при формировании страницы идет работа с базой данных и т.п.). Так или иначе, это позволит сравнивать режимы между собой.

В качестве тестовой площадки создадим впс-сервер на ос Ubuntu. Конфигурация его будет . Будем считать, что именно такие серверы начального уровня создают в большинстве случаев для новых проектов. Тестовая версия интернет-магазина будет доступна по ip адресу http://130.193.44.219/

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

Так как в большинстве случаев вместе с vps предлагается панель управления, основные изменения настроек будем производить в ней. На vps сервере нам доступно 3 режима его работы:

• Apache;
• Apache в режиме CGI;
• Nginx + php-fpm (без Апача).

Но сначала проведем испытания на хостинге:

Классический недорогой хостинг

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

Ваш сайт подвергался ограничениям в течение последних 24 часов. Ресурсы процессора ограничивались для Вашего сайта. Вы достигали пределов по входным процессам (количеству одновременно запущенных PHP и CGI скриптов, заданий по расписанию и консольных сессий) 126 раз.

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

VPS: Apache

Следующий на очереди – наш тестовый впс с режимом апач, который кстати предлагается по умолчанию, при установке панели управления ISP.

Проблемы начинаются, когда число пользователей переваливает за 90. Если мы зайдем на наш сервер по ssh и посмотрим в этот момент на список процессов по команде top, отсортированный с помощью Shift+M (по количеству потребляемой памяти), то увидим примерно такую картину:

Мы видим, что процесс apache2 разросся на много дочерних и они съели всю оперативку нашего vps сервера.

Здесь нужно сделать небольшую ремарку. Дело в том, что для сервера апач теоретически существует режим, который позволяет вместо этого большого числа дочерних процессов для каждого соединения создать несколько так называемых мультитредовых, каждый из которых обслуживал бы по нескольку соединений. Называется этот режим worker , в отличие от дефолтного prefork . Но установить его непросто, в панелях типа ISP это сделать невозможно, а если озадачиться и попытаться это осуществить через ssh, то выяснится, что для этого мало выключить prefork и включить worker, еще нужна тредобезопасная версия php. А если используются модули типа Zend или IonCube, то они тоже должны быть тредобезопасными. Да и вообще, официальный сайт PHP не рекомендует устанавливать этот режим.

VPS: CGI

Давайте посмотрим, что будет при использовании режима CGI. Для этого нужно в панели управления ISP разрешить использовать PHP в режиме CGI, это делается в разделе «Учетные записи – пользователи – настройки для пользователя».

Безрадостная картина получилась. Сервер отказывается выдавать контент уже при 55+ посетителях, оперативная память вся съедена процессами “php”. Далее идёт попытка восстановления работоспособности, но всё равно всё оканчивается практически 100% отказами.

VPS: Nginx + PHP-FPM

Настало время режима, в котором сервер Apache не используется вовсе, вместо него работает Nginx, а php обрабатывается модулем php-fpm. Если вы используете панель управления ISP, то необходимо разрешить этот режим для пользователя. Это также делается в разделе «Учетные записи – пользователи – настройки для пользователя». Также этот режим должен быть доступен в разделе «Настройки – Возможности – Веб-сервер(www)».

То, что нужно! 100% доступности, при этом скорость загрузки и время ответа сервера находятся на приемлемых уровнях, хоть и возрастают с ростом нагрузки. Тем не менее сервер справляется!

Посмотрим на таблицу процессов в момент максимальной нагрузки на сервер:

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

Что ж, похоже «режим-победитель» определен. Давайте выясним, сколько же одновременных посетителей сможет обслужить наш сервер в таком режиме. Но перед этим сделаем небольшой «тюнинг». Во-первых, так как apache не используется при такой работе сервера, его можно вовсе отключить. Это сделаем в панели управления ISP в разделе «Система – Службы». Во-вторых, изменим немного принцип запуска процессов php-fpm. По умолчанию он динамический. Это значит, что дочерние процессы будут висеть в памяти даже когда они не нужны. При этом память не освобождается и со временем эти процессы могут разрастись больше чем нам бы хотелось. Поэтому предлагается установить режим “ondemand” – по требованию. И задать количество дочерних процессов и время таймаута для них.

Для этого нужно будет зайти на сервер по ssh и прописать эти настройки в конфигурационный файл php. Это удобно сделать в файле для пользователя, для которого был создан домен в ISP.

Обычно он находится в /etc/php/7.0/fpm/pool.d

Итак: sudo nano /etc/php/7.0/fpm/pool.d/www-root.conf

Видим там по умолчанию такие настройки:

Pm = dynamic pm.start_servers = 1 pm.min_spare_servers = 1 pm.max_children = 5 pm.max_spare_servers = 5
Чтобы заработал режим ondemand, нужно заменить это на:
pm = ondemand pm.max_children = 5 pm.process_idle_timeout = 10s
И перезапустить php-fpm командой

Sudo service php7.0-fpm restart
После этого процессы php-fpm7.0 будут создаваться по требованию (при наличии нагрузки), максимальное их количество будет =5, а после 10 секунд простоя процесс будет убиваться, освобождая оперативную память.

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

Теперь давайте запустим Loaddy с большим количеством посетителей, чтобы понять, сколько соединений способен выдержать наш сервер:

Радует то, что все запросы были обработаны, пусть и с большой задержкой, при большом их количестве в секунду. Время ответа сервера приближается к 10 секундам при количестве обращений 190+ Но давайте вспомним график режима apache, где 4 секунды ответа сервера мы получили уже при 80+ пользователях, тогда как в режиме php-fpm аналогичные лаги наблюдаются при 130 запросах, которые мы специально выделили курсором на графике выше.
А ведь это тот же самый VPS.

Таблица процессов top в конце испытания (при 200 пользователях):

Заметим, что после окончания тестирования, память, используемая pfp-fpm освободилась:

А значит наш сервер готов к новым нагрузкам.

Необходимо помнить, что сайт работает в режиме nginx+php-fpm, это означает что в работе не используется apache2 и как следствие – не используется.htaccess. Это может казаться не удобным, но это самый быстрый из возможных вариантов, а поисковики лучше ранжируют сайты, которые работают быстро.

Заключение

В завершении еще один небольшой момент: Если вы настроили на сервере всё что хотели и решили отключить панель управления ISP, или у вас кончилась на неё лицензия, учтите, что процесс “core” от неё так и останется висеть у вас на сервере. По прошествии месяцев он может разрастись, так что лучше его “убить” и удалить из автозапуска и crona.

Если хотите самостоятельно протестировать сайт с помощью Loaddy или же другими методами, он доступен по адресу

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

Также веб-сервер выполняет функцию исполнения скриптов, например, таких как CGI, JSP, ASP и PHP, которые отвечают за организацию запросов к сетевым службам, базам данных, доступу к файлам, пересылке электронной почты и другим приложениям электронной коммерции.

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

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

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

В случае малой организации веб-сервер может быть целостной системой, которая будет состоять из: HTTP-сервера – служит для запросов к веб-страницам; FTP-сервера – применяется для загрузки файлов через Интернет; NNTP-сервера – выполняет доступ к группам новостей; SMTP-сервера – для электронной почты.

История

Изобретателем первого веб-сервера считается британский ученый Тим Бернерс-Ли. Работая с 1980 года в Европейской лаборатории ядерных исследований (фр. Conseil Européen pour la Recherche Nucléaire, CERN) консультантом по программному обеспечению, он приступил к своим разработкам. В Женеве он для своих собственных потребностей разработал программу «Энквайр» (англ. enquire – спрашивать), которая использовала случайные ассоциации для хранения данных и заложила концепцию для основы Всемирной паутины.

В 1989 году Тим Бернерс-Ли, работал над внутренней сетью организации CERN и предложил основать глобальный гипертекстовый проект, который заключался в публикации гипертекстовых документов, связанных между собой гиперссылками. Внедрение этого проекта, по его мнению, облегчило бы объединение, поиск и обмен информацией для ученых CERN. Для осуществления проекта Тим Бернерс-Ли вместе со своими помощниками изобрел идентификаторы URI и URL, протокол HTTP, а также язык HTML. Все эти технологии теперь широко применяются в современном Интернете и без них уже не обойтись.

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

Первый веб-браузер работал на платформе NeXTSTEP – объектно-ориентированной, многозадачной операционной системе, и был разработан с помощью Interface Builder. Интерфейс веб-браузера был очень простым, и почти вся информация отображалась в текстовом формате только лишь с несколькими изображениями. Помимо стандартного протокола FTP, Тим Бернерс-Ли использовал новый, изобретенный им, протокол HTTP. В период с 1991 по 1993 год Бернерс-Ли усовершенствовал технические свойства своих новых разработок: идентификаторов URI и URL, протокола HTTP и языка HTML и опубликовал их. Позже веб-браузер был переименован в "Nexus", чтобы не возникло путаницы с названием операционной системы, на которой был разработан браузер и его названием.

Первый в мире веб-сервер и первый веб-браузер работали на персональном компьютере NeXTSTEP; сейчас этот компьютер выставлен в музее CERN (Микрокосм).

Первый в мире веб-сайт Тим Бернерс-Ли разместил по адресу http://info.cern.ch ; сейчас этот сайт хранится в архиве. Первый сайт появился в Интернете 6 августа 1991 года. На этом веб-сайте было дано:

• описание Всемирной паутины;
• инструкция правильной установки веб-сервера;
• информация о том, как приобрести веб-браузер;
• прочая техническая информация.

Этот сайт также представлял собой первый в мире интернет-каталог. Бернерс-Ли разместил на нем список ссылок на другие сайты и регулярно обновлял его.

12 декабря 1991 года в Стэнфордском центре линейного ускорителя (SLAC) в США был установлен первый в мире веб-сервер.

Основные и дополнительные функции

Все основные и дополнительные функции веб-сервера:

• Прием запросов от веб-браузеров по протоколу стандарта HTTP с использованием сетевых протоколов TCP/IP;
• Выполнение поиска и отсылки файлов с гипертекстом или каких-либо документов в браузер по протоколу HTTP;
• Обслуживание и обработка запросов, типа: mailto, FTP, Telnet и т. п.;
• Запуск прикладных программ на веб-сервере с последующей передачей и возвратом параметров обработки через стандарт интерфейса CGI;
• Работа и обслуживание навигационных карт изображений (Image map);
• Администрация и оперативное управление сервером;
• Авторизация пользователей и их аутентификация;
• Ведение регистрационного журнала обращений пользователей к различным ресурсам;
• Автоматизированная работа веб-страниц;
• Поддержка страниц, которые генерируются динамически;
• Поддержка работы протокола HTTPS для защищенных соединений с клиентами.

Описание работы веб-сервера

Веб-браузеры поддерживают связь с веб-серверами с помощью протокола передачи гипертекстовых сообщений (HypertextTransferProtocol, HTTP). Это простой протокол запросов и ответов для пересылки информации с использованием протокола TCP/IP. Веб-сервер получает запрос, обнаруживает файл, посылает его браузеру, а затем разрывает соединение. Графическая информация, которая имеется на странице, обрабатывается таким же образом. Далее настает очередь веб-браузера – вывести на монитор пользователя загруженный из сети HTML-документ.

Кроме HTML-страниц и графики, веб-серверы могут хранить любые файлы, в том числе текстовые документы, документы текстовых процессоров, видеофайлы и аудиоинформацию. На сегодняшний день, если не учитывать анкет, которые заполняют пользователи, основная часть веб-трафика передается в одном направлении – браузеры считывают файлы с веб-сервера. Но это положение изменится после общего принятия описанного в проекте HTTP 1.1 метода PUT, который позволяет записывать файлы на веб-сервер. Сегодня метод PUT используется в основном пользователями, создающими веб-страницы, но в перспективе он может пригодиться и остальным пользователям для обратной связи с информационными центрами. Запросы методом PUT намного проще, чем обыкновенная POST загрузка файлов на веб-сервер.

На веб-сервере также выполняют свою работу различные приложения, наибольшую популярность среди которых получили поисковики и средства связи с базами данных. Для разработки этих приложений применяются такие стандарты, как общий шлюзовой интерфейс (CommonGatewayInterface, CGI), языки сценариев JavaScript, а также языки программирования Java и VisualBasic. Кроме интерфейса стандарта CGI, некоторые фирмы-разработчики веб-серверов создали интерфейсы прикладного программирования (API) такие как, например, Netscape Server API и Internet Server API, которые созданы компаниями Microsoft и Process Software AG. Эти интерфейсы позволяют разработчикам непосредственно обращаться к конкретным функциям веб-сервера. Некоторые веб-серверы обладают связующим программным обеспечением (middleware) для подключения к базам данных, работа с которыми может потребовать профессиональных знаний в программировании.

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

Обзор веб-серверов

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

Большинство веб-серверов инсталлируется легко и быстро.

Самая сложная часть процесса инсталляции – это проведение конфигурации нескольких имен доменов на одном физическом устройстве или другими словами организация виртуальных серверов.

Веб-серверы имеют средства для управления информационным модулем, характеризующие общую организацию веб-узла, а также обладают инструментами для проверки правильности внутренних и внешних гипертекстовых связей. Пакет LiveWire фирмы Netscape Communications, который поставляется вместе с Novell Open Enterprise Server (OES) и дополнительно предлагаемый с сервером FastTrack, обладает утилитой управления узлом, которая формирует список всех связей выбранной страницы. Эта утилита также предоставляет общий перечень всех некорректных связей, которые обнаруживает. Программа WebView компании «O"Reilly & Associates» обладает такой же функцией и может выводить на экран подробное дерево файлов, в котором все некорректные связи выделяются красным цветом.

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

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

Для того чтобы организовать работу отдельных пользователей и их групп могут быть использованы внутренние приложения сервера или определенные функции операционной системы. Для того чтобы организовать работу отдельных пользователей и их групп могут быть использованы внутренние приложения сервера или определенные функции операционной системы. В пакетной службе Microsoft IIS предусмотрено применение средств базовой сетевой ОС Windows NT.

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

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

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

Для малых корпоративных интрасетей лучше всего подойдет пакет Internet Information Server (IIS), созданный и распространяемый компанией Microsoft. IIS отличается достаточно простой инсталляцией и простыми настройками конфигурации. Этот пакет веб-сервера отлично интегрирован со средствами управления доступом, инструментом контроля параметров системы Performance Monitor (Системный монитор), а также с программой просмотра журнала событий Event Viewer. Еще веб-сервером IIS представляется несколько инструментов для динамической передачи информации из баз данных. IIS отличается очень высоким быстродействием. Компоненты IIS поддерживают такие протоколы, как: HTTP, HTTPS, FTP, NNTP, SMTP, POP3.

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

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

Самые распространенные веб-серверы: Apache (компания Apache Software Foundation), IIS (компания Microsoft) и iPlanet server (от компаний Sun Microsystems и Netscape Communications Corporation). Сейчас на рынке программного обеспечения для веб-серверов, существует огромный выбор продуктов, как коммерческих, так и бесплатных.

Одним из самых распространенных веб-серверов, является Apache от компании Apache Software Foundation. По ориентировочным подсчетам, он используется на 65% всех веб-серверов в мире. Одно из основных достоинств программного обеспечения Apache – бесплатное распространение. Разработчики регулярно устраняют найденные ошибки и предоставляют хорошую поддержку пользователей. Данный веб-сервер поддерживает большое количество модулей, утилит и дополнений. Поскольку с самого начала Apache разрабатывался как программное обеспечение для администраторов и опытных пользователей, то есть недостаток – сложность настройки и обслуживания для неопытных вебмастеров.

Далее по популярности идет веб-сервер IIS от компании Microsoft. По данным компании Netcraft веб-сервер IIS составляет 12,46% от общего числа веб-серверов. Этот продукт входит в состав серверного программного обеспечения семейства Windows NT. Его основные преимущества – стабильность, высокая скорость работы, возможность подключения дополнительных модулей. Компания Microsoft стремится к тому, чтобы любой пользователь смог пользоваться ее продуктами без помощи специалистов, если ему нужно решить стандартные задачи. Поэтому система IIS очень проста в установке, настройке и обслуживании. Веб-сервер поддерживает технологию.NET, набирающую, в последнее время, популярность в среде разработчиков и профессиональных пользователей. Эти достоинства выводят веб-сервер IIS на новый уровень и можно ожидать, что его использование возрастет.

Другие известные веб-серверы:

• nginx - свободный веб-сервер и почтовый прокси-сервер, разрабатываемый Игорем Сысоевым. Простой, быстрый и надежный сервер. Работает в Linux и других Unix-подобных операционных системах, а также в Windows. Пользуется популярностью на крупных веб-сайтах;
• lighttpd - свободный веб-сервер. Разработчик Ян Кнешке. Быстрый и безопасный веб-сервер. Работает в Linux и других Unix-подобных операционных системах, а также в Windows;
• Google Web Server - веб-сервер, который основан на Apache и используется компанией Google для организации своей веб-инфраструктуры;
• Resin - свободный веб-сервер и сервер приложений для Java. Разработчик – компания Caucho Technology Inc.;
• Cherokee - свободный веб-сервер, который управляется только через веб-интерфейс. Написан на языке программирования Си;
• Rootage - веб-сервер, который написан на языке программирования Java. Работает в Linux и Windows;
• THTTPD - простой, маленький, быстрый и безопасный веб-сервер. Разработчик компания ACME Labs Software.

Клиенты веб-сервера

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

• Веб-браузер, который установлен на стационарном персональном компьютере;
• Веб-браузер, который установлен на КПК или другом переносном устройстве;
• Мобильные телефоны и смартфоны, с помощью которых пользователь получает доступ к ресурсам веб-сервера по WAP-протоколу;
• Различные программы, которые могут обращаться к веб-серверу самостоятельно для обновления либо получения другой информации. Пример – различные антивирусы, которые периодически обращаются к веб-серверу, чтобы обновить базу данных;
• Разные цифровые устройства, а также некоторая бытовая техника.

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

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

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.

Заключение

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

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

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

Клиент, которым обычно является веб-браузер, передаёт веб-серверу запросы на получение ресурсов, обозначенных URL-адресами. Ресурсы - это HTML-страницы, изображения, файлы, медиа-потоки или другие данные, которые необходимы клиенту. В ответ веб-сервер передаёт клиенту запрошенные данные. Этот обмен происходит по протоколу HTTP.

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

Web-браузера, такого как Firefox или Internet Explorer, который показывает в удобной для человеческого восприятия форме запрашиваемую страницу, которую он получает от…

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

С браузерами имеют дело пользователи, которые подходят к их выбору и анализу с надлежащей тщательностью. Напротив, серверы видны только техническому персоналу сайтов. Более того, хотя существует множество различных Web-серверов, около 90% всех сайтов, согласно недавним исследованиям Netcraft, работают всего на двух из них - Apache и Internet Information Server (IIS). Оба эти сервера – тщательно проработанные продукты, обладающие не только очень длинным списком встроенных возможностей, но и процветающим "вторичным рынком" книг, дополнений, консультаций, провайдеров и т.д.

Web-сервер оценивается по целому ряду важнейших параметров:

Эффективность: как быстро он отвечает на запрос?

Масштабируемость: продолжает ли сервер работать надёжно, когда к нему одновременно обращаются много пользователей?

Безопасность: совершает ли сервер только те операции, которые должен? Какие возможности он предлагает для аутентификации пользователей и шифрования потока обмена информацией? Делает ли его использование более уязвимыми соседние приложения или хосты?

Работоспособность: какие у сервера режимы отказа и аварийные ситуации?

Соответствие стандартам.

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

Требования к платформе: на каких платформах возможно использование сервера? Предъявляет ли он особые требования к аппаратной платформе?

Управляемость: легко ли установить и обслуживать сервер? Совместим ли он с организационными стандартами по ведению журналов, аудиту, оценке затрат и т.д.?

Известные веб-серверы:

· Apache - свободный веб-сервер, наиболее часто используемый в UNIX-подобных операционных системах;

· IIS от компании Microsoft, распространяемый с серверными ОС семейства Windows

· nginx - свободный веб-сервер,

· lighttpd - свободный веб-сервер.

· Google Web Server - веб-сервер, основанный на Apache и доработанный компанией Google.

· Resin - свободный веб-сервер приложений.

· Cherokee - свободный веб-сервер, управляемый только через web-интерфейс.

· Rootage - веб-сервер, написанный на java.

· THTTPD - простой, маленький, быстрый и безопасный веб-сервер.

«Лёгкие» Web-сервера

Обычно «лёгкий» подразумевает простой, легко инсталлируемый, хорошо налаженный, нетребовательный и устойчивый – меньшего размера и менее сложный, чем Apache и IIS, которые в попытке удовлетворить свой большой рынок превратились в довольно громоздкие конструкции.

Достаточно лёгкие серверы открывают возможности, недоступные лидерам рынка и другим «тяжёлым» альтернативам. К примеру, весь сервер может поместиться в одном файле. Это удобно для разработчика, вы можете экспериментировать с новыми идеями, запуская их на лёгком сервере, инсталляция которого занимает секунды. Также из-за своей нетребовательности лёгкие серверы успешно функционируют на машинах, которые просто не могут выдержать тяжесть IIS.

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

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

· YouTube использует lighttpd для быстрой доставки архивированного контента, например, видео;

· cdServe работает на CD-дисках "German Woodworking Machinery and Tools";

· LiteSpeed «отметился» в twitter, www.funnyoride.com, www.airliners.com, WordPress.com, fanfiction.com, SlashGear, www.forumactif.com и в других заметных Web-сайтах;

· OpenSUSE, RubyOnRails, MarkaBoo и несколько других заметных сайтов опираются на Mongrel;

· thttpd работает на ht.com, mtv.com, The Drudge Report, garfield.com и др.

Лёгкие серверы играют свою роль даже в реальных вычислительных центрах, включая перечисленные выше солидные сайты и не только их. Особо высокопроизводительные сайты сегментируют свои операции, чтобы извлечь максимальную выгоду из кэширования, прокси-серверов и т.д. Сайт на основе Apache, к примеру, может иметь архитектуру, в которой медленно изменяющиеся изображения доставляются посредством «минималистского» Web-сервера из выделенной файловой системы. То, что видит в действительности конечный пользователь – это результат командной работы Apache и одного или нескольких дополнительных Web-серверов, каждый из которых играет роль, в которой он превосходит остальных. Такая конструкция может дать очень быстрые результаты с минимальными затратами на вычисления.

Хотя имеют много общего, внутри данной категории есть и различия. Большинство «лёгких» Web-серверов написаны на C, но есть и ряд успешных реализаций на других языках, в том числе на Erlang, Java, Lisp, Lua, Perl, Python и Tcl.

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

К числу очень маленьких Web-серверов относятся:

· Cheetah Server , содержащий менее тысячи строк на C.

· DustMote , очень маленький Web-сервер, реализованный в одном Tcl-исходнике размером примерно 3000 байт.

· fnord занимает менее 20K, в зависимости от платформы и конфигурации. Несмотря на маленький размер, он поддерживает виртуальный хостинг, CGI и keep-alive.

· ihttpd , имея менее 800 строчек C, умеет обслуживать страницы, включая CGI, посредством inetd.

· mattows поддерживает CGI, насчитывая при этом всего лишь 600 строк на C.

· Scrinchy , несмотря на маленький размер - около 30 KB - поддерживает примечательно много языков сценариев, включая специализированный стековый язык под названием Sy.

Маленький размер не препятствует серьёзному использованию этих серверов; fnord, например, обслуживает тысячи одновременных соединений.

· cghttpd – минимальный Web-сервер, который можно рассматривать как эксперимент по использованию асинхронных средств, доступных в ядрах Linux серии 2.6.

· darkhttpd – быстрый однопоточный сервер HTTP/1.1.

· Gatling специально разработан для высокой производительности. Поддерживает FTP, IPv6, виртуальный хостинг, CGI и т.п.

· Kernux – модуль ядра Linux, который обеспечивает выполнение HTTP-демона.

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

· LiteSpeed Web Server – коммерческий лёгкий Web-сервер, в котором особый упор сделан на производительность и безопасность. LiteSpeed Technologies Inc. заявляет об ускорении в шесть раз для статического контента и несколько более скромных показателях для интерпретируемых страниц.

· Miniature JWS , известный также как tjws - написанный на Java Web-сервер, который обрабатывает сервлеты, JSP и тысячи параллельных соединений, занимая 77 килобайт. Его автор характеризует его так: "на 10% быстрее, чем Apache 2.x."

· Yaws – высокопроизводительный сервер HTTP/1.1, написанный на Erlang.

Многие Web-серверы реализованы как классы или библиотеки, разработанные для встраивания в большие приложения. Среди них особенно интересны:

· EHS – "встраиваемый HTTP сервер," класс C++, разработанный для встраивания в большие C++ приложения; и

· Embedded TCL Web Server , простейший Web-сервер, поддерживающий SSL и Basic Authentication и при этом фантастически быстрый – по замерам автора, не менее быстрый, чем lighttpd и AOLserver. Содержит меньше сотни строк Tcl.

На языке Python реализованы несколько Web-серверов, которые заполняют необычные ниши, в том числе:

· cdServer - маленький простой http-сервер на Python, "разработанный для выдачи (статического) контента с CD-ROM". Имеет ограниченные возможности в обслуживании динамического контента. У нас есть несколько проектов, которые включают доставку непортящихся "live CD", и инструменты типа cdServer являются для них критическими.

· edna – остроумный MP3-сервер на Python, основанный на HTTP.

Есть и другие интересные лёгкие Web-серверы, реализованные на Perl и на других, не так хорошо известных, языках:

· Camlserv – полный Web-сервер, написанный на ocaml и нацеленный на "высокоинтерактивные Web-страницы". Умещается в нескольких тысячах строчек ocaml, большинство из которых посвящено специальным возможностям работы с MySQL и HTML.

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

· DNHTTPD написан на Perl для UNIX. Он поддерживает виртуальные хосты, SSL соединения, CGI и другое.

· Jellybean – написанный на Perl сервер Perl Object Server, основанный на HTTP.

· lns.http – общая Web-среда на LISP HTTP/1.1.

· Mongrel – библиотека и сервер для HTTP, написанные на Ruby.

· Nanoweb – быстрый, устойчивый Web-сервер, написанный на PHP. Имеет обширный список возможностей, включая полное соответствие HTTP/1.1, контроль обращений, аутентификацию, виртуальный хостинг, SSL совместимость и т.д.

· Naridesh – написанный на Perl Web-сервер.

· OpenAngel – написан на Perl. Безопасность.

· Xavante – HTTP/1.1 Web-сервер, написанный на Lua.

· XSP написан на C# и выполняет роль ведущего узла ASP.NET.

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

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

В предыдущей лекции мы разобрались с функционированием протокола 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?