• Главная
  •  > 
  • Questions
  •  > 
  • Что такое web сервер. Выбор режима работы web-сервера на личном опыте

Что такое web сервер. Выбор режима работы 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.

Заключение

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

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

Помню, давно я думал, что Интернет сосредоточен в одном месте, представлял что-то типа лаборатории, где расположено большое количество аппаратуры, поддерживающей работу всего этого. Тогда я не мог оценить масштабы Глобальной сети и сложности ее структуры. В действительности же, Интернет - это абстрактное понятие, ресурсы Интернета разбросаны по оборудованию на всем земном шаре. Для связи этого оборудования между собой на огромных расстояниях придумали специальные алгоритмы и стандарты, в частности, протокол 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. А в первом уроке мы научимся сами устанавливать и настраивать веб-сервер.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

WAMP тест!

Привет!

"; ?>

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

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

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

Order Allow,Deny

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

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

Хотя термины 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. Это платформа, предназначенная для установки, работы и размещения приложений и сервисов для конечных пользователей. Хотя оба они необходимы для правильного функционирования веб-сайта, они сильно отличаются друг от друга.

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

Введение

Понятие « веб-сервер» может относиться как к аппаратной начинке, так и к программному обеспечению. Или даже к обеим частям, работающим совместно.

  1. С точки зрения "железа", « веб-сервер» - это компьютер, который хранит файлы сайта (HTML-документы, CSS-стили, JavaScript-файлы, картинки и другие) и доставляет их на устройство конечного пользователя (веб-браузер и т.д.). Он подключен к сети Интернет и может быть доступен через доменное имя, подобное mozilla.org .
  2. С точки зрения ПО, веб-сервер включает в себя несколько компонентов, которые контролируют доступ веб-пользователей к размещенным на сервере файлам, как минимум - это HTTP-сервер . HTTP-сервер - это часть ПО, которая понимает (веб-адреса) и HTTP (протокол, который ваш браузер использует для просмотра веб-страниц).

На самом базовом уровне, когда браузеру нужен файл, размещенный на веб-сервере, браузер запрашивает его через HTTP-протокол. Когда запрос достигает нужного веб-сервера ("железо"), сервер HTTP (ПО) принимает запрос, находит запрашиваемый документ (если нет, то сообщает об ошибке ) и отправляет обратно, также через HTTP.

Статический веб-сервер , или стек, состоит из компьютера ("железо") с сервером HTTP (ПО). Мы называем это « статикой» , потому что сервер посылает размещенные файлы в браузер « как есть» .

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

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

Активное изучение

Активное изучение пока не доступно. .

Погружаемся глубже

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

Хостинг файлов

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

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

  • всегда запущен и работает
  • всегда подключен к Интернету
  • имеет неизменный IP адрес (не все провайдеры предоставляют статический IP-адрес для домашнего подключения)
  • обслуживается третьей, сторонней компанией

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

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

Связь по HTTP

Во-вторых, веб-сервер обеспечивает поддержку HTTP (англ. H ypert ext T ransfer P rotocol - гипертекстовый транспортный протокол ). Как следует из названия, HTTP указывает, как передавать гипертекст (т.е. связанные веб-документы) между двумя компьютерами.

Протокол представляет собой набор правил для связи между двумя компьютерами. HTTP является текстовым протоколом без сохранения состояния.

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

HTTP задает строгие правила взаимодействия клиента и сервера. Мы рассмотрим сам протокол HTTP в технической статье немного позднее. Пока достаточно знать об этих правилах:

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

На веб-сервере HTTP-сервер отвечает за обработку входящих запросов и ответ на них.

  1. При получении запроса, HTTP-сервер сначала проверяет, существует ли ресурс по данному URL.
  2. Если это так, веб-сервер отправляет содержимое файла обратно в браузер. Если нет, сервер приложения генерирует необходимый ресурс.
  3. Если ничто из этого не возможно, веб-сервер возвращает сообщение об ошибке в браузер, чаще всего “404 Not Found”. (Это ошибка настолько распространена, что многие веб-дизайнеры тратят большое количество времени на разработку 404 страниц об ошибках .)

Статический и Динамический контент

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

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

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

Существует так много серверов приложений, что довольно трудно предложить какой-то один. Некоторые серверы приложений заточены под определенные категории веб-сайтов, такие как блоги, вики-страницы или интернет-магазины; другие, называемые CMSs (системы управления контентом), более универсальны. Если вы создаете динамический сайт, потратьте немного времени на выбор инструмента, который соответствует вашим потребностям. Если вы не хотите изучать веб-программирование (хотя это увлекательно само по себе!), то вам не нужно создавать свой собственный сервер приложения. Это будет изобретением очередного велосипеда.

Следующие шаги

Теперь, когда вы познакомились с веб-серверами, вы можете:

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