В первой статье мне бы хотелось немного затронуть именно эту тему, так как очень важно знать механизмы работы инструмента (в нашем случае - веб-сервера), реализовывающего работу нашего сайта. Мы немного идеализируем веб-сервер, упустим некоторые тонкие технические нюансы, чтобы было проще понять суть. Постараюсь расписать как можно проще и доступнее:)
Помню, давно я думал, что Интернет сосредоточен в одном месте, представлял что-то типа лаборатории, где расположено большое количество аппаратуры, поддерживающей работу всего этого. Тогда я не мог оценить масштабы Глобальной сети и сложности ее структуры. В действительности же, Интернет - это абстрактное понятие, ресурсы Интернета разбросаны по оборудованию на всем земном шаре. Для связи этого оборудования между собой на огромных расстояниях придумали специальные алгоритмы и стандарты, в частности, протокол TCP/IP , на котором в настоящее время функционирует наш Интернет. Согласно этому стандарту, каждый компьютер, находящийся в Глобальной сети, имеет свой уникальный адрес - IP-адрес . IP-адрес представляет собой последовательность четырех чисел в диапазоне от 0 до 255, разделенных между собой точками (например, 92.166.31.18). Один компьютер может связаться с другим компьютером в сети, зная его IP-адрес. Но сказать "компьютер связался с компьютером" не совсем верно, так как связываются не сами компьютеры, а сетевые службы (программы, если хотите), выполняющиеся на них. Допустим, вы отправляете электронную почту дедушке, при этом ваша почтовая программа связывается с почтовым сервером для отправки письма.
На компьютере одновременно может работать несколько сетевых программ, поэтому помимо IP-адреса для связи протоколом TCP/IP предусмотрено дополнительно такое понятие как порт . Порт - это число в диапазоне от 1 до 65536. Таким образом, минимальным условием для связи одной сетевой программы с другой является наличие у первой IP-адреса и номера порта второй. Совокупность IP-адреса и порта принято записывать через двоеточие (например, 192.168.35.2:443).
Для установления связи первой программе задается номер порта и она начинает "ожидать" подключение второй. Второй программе указывается тот же самый номер порта и IP-адрес компьютера, на котором запущена первая программа. Связь двух программ напоминает звонок по сотовому телефону: Вася звонит Пете, Петя берет трубку и начинается разговор. При этом номер телефона - это совокупность IP-адреса и номера порта в нашем случае.
Программа, ожидающая подключение, называется сервером . Серверу при запуске указывается номер порта, часто говорят: "сервер слушает порт". На компьютере не может быть запущено более одного сервера с одинаковым номером порта (иначе невозможно определить, к какому из серверов подключаться). Программа, устанавливающая соединение с сервером, называется клиентом . На клиентов не распространяется подобное ограничение (например, можно запустить два джаббер-клиента). Также к серверу могут подключаться несколько клиентов с разных компьютеров, если это поддерживает сам сервер.
Теперь давайте на основе этих поверхностных знаний определим, что такое веб-сервер . Во-первых, судя по названию, это сетевая программа, ожидающая и принимающая соединения (сервер). По умолчанию, веб-сервер "слушает" порт под номером 80. Веб-сервер поддерживает работу одновременно с несколькими клиентами (несколько человек одновременно могут просматривать сайт). Клиентом для веб-сервера выступает веб-браузер (Internet Explorer, Opera и так далее).
Таким образом, сайт функционирует за счет веб-сервера, который отправляет странички этого сайта клиентам, запрашивающих их у него. Для того, чтобы запросить страницу необходимо знать IP-адрес компьютера, на котором запущен веб-сервер с нужным нам сайтом. Но запоминать IP-адреса неудобно, поэтому придумали доменные имена, представляющие собой некую текстовую сущность (например, yandex.ru). Очевидно, что доменные имена более понятны и более легки в запоминании. Однако, протокол TCP/IP не в состоянии найти требуемый компьютер по доменному имени, поэтому его необходимо преобразовать в IP-адрес. Для этого служат DNS-сервера, на которых расположены таблицы соответствий доменных имен и IP-адресов. Допустим, когда мы вводим в адресной строке браузера домен yandex.ru, в первую очередь посылается запрос в DNS-сервер для определения IP-адреса данного домена. Когда адрес определен, браузер пытается связаться с веб-сервером по этому адресу и по стандартному порту под номером 80. Если соединение с веб-сервером установлено, браузер запрашивает у веб-сервера требуемую страницу сайта.
В принципе, веб-сервер можно настроить на работу и на другом порту, в таком случае в браузере при запросе страницы необходимо его указывать через двоеточие после доменного имени (например, site.ru:3182).
Каким же образом происходит запрос страницы сайта у веб-сервера браузером? Понятное дело, что для взаимодействия веб-сервера и браузера необходим "общий язык", то есть некий стандарт, по которому формируются запросы и ответы. Этим стандартом служит протокол HTTP (HyperText Transfer Protocol). Этот протокол довольно прост, так как соответствует схеме "запрос-ответ". Говоря другими словами, на каждый HTTP-запрос веб-браузера веб-сервер отвечает HTTP-ответом. По своей инициативе веб-сервер HTTP-пакеты не шлет (к тому же, зачастую, после завершения операции "запрос-ответ" сервер разрывает соединение с клиентом).
Давайте рассмотрим структуру HTTP-пакета. HTTP-запрос и HTTP-ответ состоят из двух блоков - блока заголовков (headers) и блока тела пакета. Эти блоки отделены друг от друга двумя символами перевода строк (то есть между заголовками и телом расположена пустая строка). В блоке заголовков расположены различные параметры пакета, блок тела содержит какие-либо данные. Второй блок может отсутствовать, то есть HTTP-пакет может состоять только из блока заголовков. Для примера выполним запрос главной страницы сайта ya.ru и рассмотрим HTTP-пакеты, участвовавшие в нем. При запросе главной страницы браузер Firefox отправил веб-серверу следующий HTTP-запрос:
GET / HTTP/1.1 Host: ya.ru User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2) Gecko/20100115 Firefox/3.6 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive
В HTTP-запросе отсутствует блок данных (так как отсутствует пустая строка, которая бы отделяла заголовки от данных). Давайте рассмотрим представляющие для нас в данный момент интерес строки этого запроса. Во-первых, самая первая строка:
GET / HTTP/1.1
"GET" - тип запроса. Два наиболее распространенных типа запросов - это GET и POST. О них мы поговорим в одной из следующих статей или уроков. "/" указывает на то, что запрашивается главная страница сайта. В противном случае здесь указывается путь и имя запрашиваемой страницы или файла. "HTTP/1.1" - версия протокола HTTP.
Host: ya.ru
Параметр Host содержит домен сайта, к которому происходит обращение.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2) Gecko/20100115 Firefox/3.6
User-Agent содержит информацию о клиенте: тип браузера, операционной системы и так далее. Остальные параметры в данный момент нас особо не интересуют.
На данный HTTP-запрос веб-сервер ответил следующим HTTP-ответом:
HTTP/1.1 200 OK Server: nginx Date: Thu, 25 Feb 2010 12:31:25 GMT Content-Type: text/html; charset=utf-8 Last-Modified: Tue, 12 Jan 2010 15:29:06 GMT Transfer-Encoding: chunked Connection: keep-alive Content-Encoding: gzip
Пустая строка указывает на наличие блока данных (тела пакета). Как и в случае с HTTP-запросом рассмотрим наиболее важные строки полученного ответа. В первой строке указывается версия протокола HTTP (HTTP/1.1) и код результата. Код результата 200 означает, что запрос выполнен успешно. В описании протокола HTTP расписаны все коды результатов. С некоторыми из них, например, 403 и 404, мы познакомимся в будущем.
Server: nginx
Параметр Server содержит название веб-сервера. В нашем случае мы имеем дело с веб-сервером nginx. Данный параметр может отсутствовать в HTTP-ответе, если администратор данного сервера по каким-либо причинам не желает оглашать эту информацию.
Content-Type: text/html; charset=utf-8
Content-Type содержит тип переданных данных и, если необходимо, их кодировку (charset). Также в заголовках часто содержится параметр Content-Length, содержащий размер переданных сервером данных в байтах. В блоке тела пакета содержится код запрошенной страницы.
Таким образом, мы познакомились с основными принципами функционирования веб-сервера, рассмотрели схему "запрос-ответ". Очень полезно для веб-мастера как можно лучше знать протокол HTTP, ведь это основа функционирования сайта. В последующих статьях и уроках мы будем знакомиться с различными возможностями веб-сервера, не затронутыми в данной статье, и рассматривать, как они реализованы протоколом HTTP. А в первом уроке мы научимся сами устанавливать и настраивать веб-сервер.
Эта статья будет полезна тем людям, у которых уже есть свой сайт, или которые планируют его открыть. Особенно интересна статья будет амбициозно настроенным вебмастерам, которые чувствуют, что звездный час их проекта не за горами и хотят подготовиться к наплыву посетителей страницы.
Даже те, кто пока только мечтают о тысячах пользователей на своём сайте, наверняка задавались вопросом: “А сколько же пользователей мой сайт выдержит, если они зайдут одновременно?” Сразу вспоминается известное выражение “Хабраэффект” – явление отказа сайта, который оказался не готов к многочисленным переходам на него после появления в интернете ссылки.
Предположим, что сайт уже есть (или скоро будет): где же его разместить? Это должен быть классический хостинг или 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 или же другими методами, он доступен по адресу
Что такое веб-сервер? С точки зрения обывателя - это некий черный ящик, который обрабатывает запросы браузера и выдает в ответ веб-страницы. Технический специалист засыплет вас массой малопонятных терминов. В итоге начинающим администраторам веб-серверов бывает порой трудно разобраться во всем многообразии терминов и технологий. Действительно, область веб-разработки динамично развивается, но в основе многих современных решений лежат базовые технологии и принципы, о которых мы сегодня и поговорим.
Если не знаешь с чего начать, то начинать надо сначала. Чтобы не запутаться во всем многообразии современных веб-технологий нужно обратиться к истории, чтобы понять, с чего начинался современный интернет и как развивались и совершенствовались технологии.
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.
Заключение
Охватить в одной статье весь спектр современных технологий невозможно, поэтому мы сосредоточились только на основных из них, некоторые вещи умышленно оставив за кадром, а также прибегли к существенным упрощениям. Несомненно, начав работать в этой области вам потребуется более глубокое изучение темы, но для того, чтобы воспринимать новые знания нужен определенный теоретический фундамент, который мы постарались заложить данным материалом.
Инструкция
Слово «сервер» - англоязычного происхождения, оно буквально означает «обслуживающий прибор». В сфере информатики сервер отвечает за предоставление информации к сетевым ресурсам.
Когда на веб-сервере создается сайт, то ему присваивается 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-скрипты – специальные команды, позволяющие видоизменить веб-страницу.
Если вам интересно, как осуществляется этот процесс или вы хотите узнать о специальных механизмах, которые позволяют путешествовать по Интернету, советуем прочесть эту статью. Из нее можно узнать, каким образом WEB серверы доставляют WEB страницы в дома пользователей, школы и офисы. Итак, начнем!
Допустим, пользователь сидит за компьютером, просматривает WEB страницы, и тут ему звонит друг и говорит:
«Знаешь, я только что прочел классную статью! Введи этот URL и прочти сам. Это страница ».
Пользователь вводит продиктованный URL в и нажимает кнопку «Перейти». И о чудо, независимо от того, где находится этот URL, страница появляется на экране монитора.
Следующая схема на самом простом уровне дает представление о последовательности событий, в результате которых выбранная страница попадает на экран монитора:
Браузер пользователя осуществил соединение с WEB сервером, запросил нужную страницу и получил ее.
Что происходит незаметно для пользователя
- Браузер разделил URL на три части:
- Протокол («http»).
- Имя сервера («сайт»).
- Имя файла («web server.htm»).
Итак, что же такое «Интернет»? - это миллионы компьютеров, соединенных в огромную компьютерную сеть. Благодаря сети, компьютеры могут поддерживать связь между собой. Домашний компьютер можно подключать к Интернету, используя модем телефонной линии, устройства, работающие по технологии DSL либо кабельный модем. Эти устройства устанавливают связь с поставщиком услуг Интернета (ISP). Компьютеры компании или университета обычно снабжаются платами сетевого интерфейса (network interface card, NIC), которые подключают их непосредственно к соответствующей локальной сети (LAN). Компания может подключить свою локальную сеть к оборудованию поставщика интернет-услуг, используя высокоскоростную телефонную линию, например, линию T1. По линии T1 можно передавать приблизительно 1.5 миллиона бит в секунду, в то время как по обычной линии с использованием модема можно передавать всего от 30 000 до 50 000 бит в секунду.
Поставщик интернет-услуг осуществляет связь с более крупными поставщиками интернет-услуг, а самые крупные поставщики имеют в своем распоряжении волоконно-оптические магистрали в масштабах страны или региона. Магистрали мирового масштаба формируются с помощью волоконно-оптических линий связи, подводных кабелей и спутниковых каналов (некоторые интересные карты магистральных линий Интернета можно найти в Атласе киберпространства). Таким образом, каждый компьютер, подключенный к Интернету, получает возможность связываться с любым другим компьютером в Интернете.
Клиенты и серверы
В общем случае все машины в Интернете можно разделить на два типа: серверы и клиенты. Машины, предоставляющие услуги другим машинам, называют серверами (это, например, WEB серверы или FTP серверы). Машины, используемые для связи с серверами с целью получения услуг, называют клиентами. Когда пользователь подключается к Yahoo! по адресу yahoo.com , чтобы просмотреть страницу, Yahoo! выделяет машину (а возможно, кластер очень больших машин), для использования в Интернете с целью обслуживания запроса этого пользователя. Таким образом, Yahoo! предоставляет пользователю услуги своего сервера. Машина пользователя, с другой стороны, скорее всего, никому другому в Интернете услуги не оказывает. Поэтому ее называют пользовательской машиной, или клиентом. Может так быть, и это обычная практика, что одна машина в то же время является и сервером, и клиентом, однако в нашем случае будем считать, что большинство машин выполняют функции либо сервера, либо клиента.
Серверная машина предоставляет один или несколько видов услуг в Интернете. На серверной машине могут работать специализированные программы, благодаря которым она может выполнять функции WEB сервера, сервера электронной почты и FTP сервера. Связывающиеся с серверной машиной клиенты преследуют определенную цель, поэтому они направляют свои запросы на сервер с соответствующей специализированной программой, работающий на общей серверной машине. Например, если пользователь на своей машине запустит WEB браузер, тот, скорей всего, свяжется с WEB сервером на серверной машине. Пользовательское приложение, работающее по протоколу Telnet, стремится установить связь с сервером Telnet, приложение для работы с электронной почтой вступает в контакт с сервером электронной почты и так далее…
Доменные имена и их покупка
В связи с тем, что людям тяжело запоминать набор цифр, из которых состоит IP адрес, и с необходимостью иногда менять адреса, всем серверам Интернета присваивают также удобные для восприятия имена, которые называются доменными именами.. Большинству людей запомнить имя сайт легче, чем адрес 209.116.69.66.
Имя сайт состоит из трех частей:
- Имя хоста (www).
- Имя домена (sd-company).
- Имя домена верхнего уровня (ru).
Регистраторы
Доменными именами внутри домена .com занимается регистратор VeriSign. VeriSign также контролирует доменные имена .net . Другими доменами (такими как PRO, BIZ и ORG) управляют другие регистраторы (а именно RegistryPro, NeuLevel и Public Interest Registry). VeriSign создает имена верхнего уровня и обеспечивает уникальность всех имен в пределах домена верхнего уровня. Кроме того, VeriSign содержит контактную информацию каждого сайта и располагает базой данных о пользователях. Имя хоста создается компанией, предоставляющей для домена. Очень распространено имя хоста «www», однако в настоящее время во многих местах его либо не указывают, либо заменяют другим именем хоста, указывающим на определенное место на сайте. Например, в доменном имени энциклопедии Encarta компании Microsoft, encarta.msn.com, «encarta» обозначает имя хоста вместо www.
Чтобы все эти машины правильно работали, каждая машина в Интернете получает уникальный адрес, который называется IP адресом. IP поддерживает интернет протокол, а адреса являются 32-битными числами, которые, как правило, представляются в виде четырех «октетов» в «десятичном формате с разделительными точками». Типичный IP адрес имеет приблизительно такой вид: 216.27.61.137
Четыре числа в IP адресе называются октетами, поскольку они могут иметь значения от 0 до 255, что составляет 2 в восьмой степени возможностей на каждый октет.
Уникальный IP адрес
Каждой машине в Интернете присваивается уникальный IP адрес. Серверам присваиваются статические IP адреса, которые меняют редко. Домашним компьютерам, осуществляющим связь с Интернетом, IP адрес часто присваивается поставщиком услуги Интернета во время соединения. Этот IP адрес в течение данной сессии является уникальным - при следующем соединении машины ей может быть присвоен другой адрес. Таким образом, поставщику услуги Интернета требуется выделять только по одному IP адресу для каждого модема на время его работы в Интернете, а не отдельные адреса для каждого клиента.
Пользователь, машина которого работает под управлением ОС Windows, может получить большое количество информации об Интернет-соединении своего компьютера, включая текущий IP адрес и имя хоста, если воспользуется командой WINIPCFG.EXE (IPCONFIG.EXE для Windows 2000/XP). В машине под UNIX, чтобы узнать IP адрес машины, нужно напечатать в командной строке nslookup, а также имя этой машины, например, SD 1 - то есть, все вместе это будет выглядеть так: «nslookup sd1.su». Имя своей машины можно определить с помощью команды hostname. (Более подробные сведения о IP адресах можно получить из информации Комитета по цифровым адресам в Интернете).
Машине, работающей в Интернете, для связи с сервером обычно нужен только IP адрес. Например, можно набрать в браузере URL 209.116.69.66 и связаться с машиной, на которой располагается WEB сервер сайта PCWork. Для связи с некоторыми серверами одного только IP адреса недостаточно, однако для большинства больших серверов этого вполне хватает - далее этот вопрос будет освещен более подробно.
Дополнительно
