Принципы функционирования веб-сервера. Выбор режима работы web-сервера на личном опыте Что такое веб сервер и как он работает
Что такое веб-сервер? С точки зрения обывателя - это некий черный ящик, который обрабатывает запросы браузера и выдает в ответ веб-страницы. Технический специалист засыплет вас массой малопонятных терминов. В итоге начинающим администраторам веб-серверов бывает порой трудно разобраться во всем многообразии терминов и технологий. Действительно, область веб-разработки динамично развивается, но в основе многих современных решений лежат базовые технологии и принципы, о которых мы сегодня и поговорим.
Если не знаешь с чего начать, то начинать надо сначала. Чтобы не запутаться во всем многообразии современных веб-технологий нужно обратиться к истории, чтобы понять, с чего начинался современный интернет и как развивались и совершенствовались технологии.
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.
Заключение
Охватить в одной статье весь спектр современных технологий невозможно, поэтому мы сосредоточились только на основных из них, некоторые вещи умышленно оставив за кадром, а также прибегли к существенным упрощениям. Несомненно, начав работать в этой области вам потребуется более глубокое изучение темы, но для того, чтобы воспринимать новые знания нужен определенный теоретический фундамент, который мы постарались заложить данным материалом.
Веб-хостинговая индустрия,требует,по крайней мере,некоторых базовых знаний для работы.Есть несколько терминов веб-хостинга,и каждый веб-мастер должен быть в курсе.Одним из самых основных из них является: веб-сервер .На самом деле,веб-хостинг построен из web-серверов, предоставляющих место для вашего веб-сайта. Сервер HP Micro AMD N40L - это универсальный сервер, который может обеспечить платформу для организации и защиты бизнес-информации, обеспечить эффективное общение с клиентами и сделать большую часть для вашего существующего офисного оборудования и ресурсов. HP MicroServer является экономически эффективным стартовым сервером для предприятий с менее 10 клиентами, и это может вывести ваш бизнес на новый уровень производительности и эффективности.Чтобы узнать больше о сервере HP Micro AMD N40L,пройдите по этой ссылке http://vint.com.ua/product/computers/dir_3010558/dir_3010559 .
Веб-сервер может означать две вещи - компьютер ,на котором размещается веб-сайт и программа ,которая работает на таком компьютере.Поэтому термин относящийся к веб-серверу как оборудование, так и программное обеспечение . Мы рассмотрим эти два вида по одному.
Оборудование веб-сервера
Веб-сайт-это коллекция веб-страниц которые представляют собой цифровые файлы, которые обычно написаны с использованием языка разметки гипертекста HTML. Веб-сайт будет доступен всему миру всё время,для этого он должен быть сохранён или на хостинге или на компьютере, подключенном к Интернету в режиме 24/7/365. Такой компьютер называется Веб-Сервер (обратите внимание на первые буквы в верхнем регистре).
Вы можете потенциально размещать веб-сайт на вашем домашнем компьютере,но это требует огромного труда и постоянного мониторинга.Проще купить веб-хостинг от компании, потому что их есть тысячи,которые предлагают эту услугу по разумным ценам. Кратко об одной из лучших компаний в конце статьи вы можете не только получить веб-хостинг,но также имя домена и веб-сайт и это действительно дёшево!
Существует ряд требований для сервера компьютера - он должен быть достаточно быстрым, иметь большой объём оперативной памяти и жесткий диск с большим объёмом.Но наиболее важно иметь постоянный адрес в Интернет, также известный как IP - адрес Интернет-протокола. Если IP адрес веб-сайта не будет найден и он будет работать в автономном режиме - браузер будет отображать ошибку не удается найти веб-сайт .
Программы и программное обеспечение web-сервера
Программы веб-сервера это программное обеспечение, которое работает для веб-сайта на хостинг-сервер компьютере. Его основная цель: выдавать веб-страницы; это означает, что он ожидает запросы от web-браузеров (также известных как клиенты ) и отвечает, посылая необходимые данные обратно. Это взаимодействие клиента и сервера отличительная часть работы веб-сервера .
Есть много веб-серверных программ. Самой известной и популярной из них является Apache ,разработанная Apache Foundation.Apache не только бесплатная,но она также доступна для нескольких операционных систем,включая Windows,Macintosh и Linux/Unix.
Инструкция
Слово «сервер» - англоязычного происхождения, оно буквально означает «обслуживающий прибор». В сфере информатики сервер отвечает за предоставление информации к сетевым ресурсам.
Когда на веб-сервере создается сайт, то ему присваивается 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-скрипты – специальные команды, позволяющие видоизменить веб-страницу.
Эта статья будет полезна тем людям, у которых уже есть свой сайт, или которые планируют его открыть. Особенно интересна статья будет амбициозно настроенным вебмастерам, которые чувствуют, что звездный час их проекта не за горами и хотят подготовиться к наплыву посетителей страницы.
Даже те, кто пока только мечтают о тысячах пользователей на своём сайте, наверняка задавались вопросом: “А сколько же пользователей мой сайт выдержит, если они зайдут одновременно?” Сразу вспоминается известное выражение “Хабраэффект” – явление отказа сайта, который оказался не готов к многочисленным переходам на него после появления в интернете ссылки.
Предположим, что сайт уже есть (или скоро будет): где же его разместить? Это должен быть классический хостинг или 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-сервер и сервер приложений часто используются взаимозаменяемо, чтобы относиться к одной и той же вещи, то есть для обеспечения надлежащего функционирования веб-сайта, но это не одно и то же. Скорее, они работают вместе, чтобы доставлять контент с веб-сайтов конечным пользователям. Веб-сервер может ссылаться на программу, которая принимает и выполняет входящие запросы от клиентов для веб-ресурсов по всему миру. Он обслуживает эти запросы вместе с необязательным содержимым, которое обычно представляет собой HTML-страницы, файлы изображений, видеофайлы и т. Д. Сервер приложений обслуживает динамический контент для конечных пользователей, используя разные протоколы, включая HTTP. В этой статье объясняется разница между ними.
Что такое веб-сервер?
Веб-сервер - это не что иное, как программная программа, предназначенная для обработки веб-запросов. Он принимает входящие запросы в виде статического контента, который в основном является компонентами веб-сайта, включая HTML-страницы, графические и видеофайлы и т. Д. Затем он отвечает на запросы по протоколу HTTP вместе с дополнительным содержимым данных. Основная задача веб-сервера - предоставлять контент в World Wide Web, чтобы сделать их доступными для конечных пользователей. Он может относиться к системе, состоящей из оборудования или программного обеспечения, или к тому, где хранятся веб-содержимое. Говоря простыми словами, веб-сервер - это компьютер, который доставляет веб-страницы по мере их запроса. Apache - самый популярный и широко используемый веб-сервер с открытым исходным кодом, разработанный и поддерживаемый Apache Software Foundation.
Что такое сервер приложений?
Сервер приложений - это термин, который часто смешивается с веб-сервером, за исключением того, что он может использовать различные стратегии для обработки запросов, инициированных веб-сервером. Это облегчает хостинг и доставку высококачественных бизнес-приложений. Он часто рассматривается как трехуровневое приложение, состоящее из графического интерфейса пользователя (GUI), сервера приложений и базы данных и сервера транзакций. Он служит бизнес-логике для прикладных программ через различные протоколы, в том числе, но не ограничиваясь, HTTP. Это программная среда, которая предоставляет все возможности, необходимые для создания и запуска приложений на базе Интернета и на предприятиях. Вместо того, чтобы обслуживать статический контент, он лучше всего подходит для обслуживания динамического контента и передачи приложений с одного устройства на другое.
Разница между веб-сервером и сервером приложений
Основы веб-сервера и сервера приложений
Веб-сервер относится к оборудованию или программному обеспечению или к обоим, которые доставляют контент или услуги конечным пользователям через World Wide Web. Это больше похоже на программу, которая отвечает на входящие сетевые запросы на веб-ресурсы по протоколу HTTP. Он также известен как интернет-сервер. С другой стороны, сервер приложений - это программная среда на основе компонентов, которая облегчает разработку и запуск веб-приложений. По сути, это серверная программа среднего уровня, предназначенная для обеспечения бизнес-логики для прикладных программ.
Веб-сервер ограничен только HTTP-контентом, то есть он использует протокол HTT для хранения, обработки и доставки контента клиентам. Это мощный компьютер, который делает сайты доступными через Интернет, а связь между клиентом и сервером выполняется с использованием HTTP. Сервер приложений не ограничивается отправкой статического содержимого HTML; Фактически, он передает бизнес-логику клиентским приложениям с использованием нескольких протоколов.
Функция веб-сервера и сервера приложений
Задача веб-сервера - принимать и отвечать на запросы пользователей, которые перенаправляются HTTP-клиентами своих компьютеров, которые могут быть либо из веб-браузера, либо из мобильного приложения. Основная цель веб-сервера - сделать статический контент доступным для пользователей для просмотра в веб-браузерах. Задача сервера приложений - размещать и публиковать приложения и процессы бизнес-логики с использованием нескольких разных протоколов. Он работает совместно с веб-сервером.
Многопоточность
Веб-сервер реагирует на запросы, поступающие из нескольких соединений одновременно, но не может обрабатывать несколько одновременных запросов параллельно. Идея использования потоков для повышения вычислительной скорости просто не работает с веб-серверами. С другой стороны, серверы приложений поддерживают многопоточность, а также ряд других функций, таких как объединение изоляции, объединение пулов, балансировка нагрузки, кластеризация и т. Д.
Объем веб-сервера и сервера приложений
Веб-сервер основан на программах, связанных с интернетом и интрасети, для обслуживания электронной почты, запросов на загрузку файлов FTP, а также для создания и публикации веб-страниц для клиентов с использованием протокола HTTP. Он может использоваться отдельно или как компонент на сервере приложений. С другой стороны, серверы приложений могут делать все, на что способны серверы приложений и многое другое. Они более способны создавать динамический контент для обслуживания как веб-приложений, так и корпоративных приложений.
Веб-сервер и сервер приложений: сравнительная таблица
Резюме веб-сервера Vs. Сервер приложений
Веб-серверы играют фундаментальную роль в том, как работает Интернет, без которого Интернет перестает существовать. Говоря простыми словами, веб-серверы выступают в качестве шлюза между пользователем и Всемирной паутиной. Это система, предназначенная для статического контента для конечных пользователей через Интернет. Он ограничен запросом обслуживающих клиентов только через протокол HTTP.Напротив, серверы приложений более ресурсоемкие, которые предоставляют услуги промежуточного программного обеспечения клиентским приложениям через различные протоколы, включая HTTP. Это платформа, предназначенная для установки, работы и размещения приложений и сервисов для конечных пользователей. Хотя оба они необходимы для правильного функционирования веб-сайта, они сильно отличаются друг от друга.