Пять лучших открытых веб-серверов. W3Tech: доля nginx в мире выросла до трети, Apache упал ниже половины Наиболее распространенные веб серверы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прежде чем выложить сайт или блог в интернет, его следует протестировать, насколько правильно будет выглядеть дизайн сайта, как будут работать скрипты, форма обратной связи, плагины и так далее.
Вот по этой причине многие Веб-разработчики (блогеры, веб-дизайнеры или веб-программисты ) используют тестовые площадки, на которых они проводят проверки, пробы, эксперименты, в общем, любую тестовую работу над будущим проектом.
Существуют два способа по созданию тестовых площадок .
1. Тестовая площадка на хостинге
Некоторые новички используют для тестирования проектов платные хостинги, размещая при этом два сайта – один основной (рабочий) и второй дополнительный, тестовый.
Минусы такого способа :
- нехватка места на хостинге;
- низкая скорость интернета;
- не всегда есть деньги, чтобы купить платный хостинг для тестирования проектов.
2. Тестовая площадка на вашем компьютере
Этот способ, на мой взгляд, лучший. Его я хочу рассмотреть с вами более подробней. Вначале скажу о плюсах:
- не нуждается в подключении интернета;
- не нужны финансовые затраты
Что это за тестовая площадка на компьютере? Речь идет о локальном сервере , который устанавливается на ваш компьютер. С помощью локального сервера вы сможете легко и быстро протестировать проект.

Кто-то может сказать: а зачем вообще проводить тестирование своего проекта через локальный сервер? Ведь достаточно открыть файл «index.html » и мы увидим, как будет выглядеть сайт в интернете. Да, это правда, достаточно и этого, но если вы используете на сайте , чаты, форумы, различные (WordPress, Joomla, drupal), то здесь без локального сервера никак . Тем более, если вы используете для своего проекта CMS движок (WordPress, Joomla, drupal), то там нужна не только поддержка php, но еще и база данных MySQL.

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

Подготовил для вас список популярных локальных серверов для сайта. Читайте, оценивайте, качайте и пользуйтесь.

Список популярных локальных серверов для сайта.

Denwer – это бесплатный локальный сервер для тестирования сайтов, веб-приложений или Интернет страниц. В Denwer входит: веб-сервер Apache, панель phpMyAdmin и MySQL для работы с БД (базами данных) и другие программы.
Локальный сервер Denwer работает только на операционную систему Windows.

Скачать можно с официального сайта denwer.ru

XAMPP – это бесплатный локальный сервер для тестирования сайтов, веб-приложений или Интернет страниц с простым пользовательским интерфейсом. Поддерживает работу в системе Windows, Solaris, Mac OS X и Linux.

Скачать можно с официального сайта www.apachefriends.org/en/xampp.html

AppServ - еще один бесплатный локальный сервер. Быстрая и легкая установка.

Скачать можно с официального сайта www.appservnetwork.com

VertigoServ - простенький по установке локальный сервер.
Работает только в операционной системе Windows.

Скачать можно с официального сайта vertrigo.sourceforge.net

Zend Server Community Edition - бесплатный локальный сервер.

Скачать можно с официального сайта www.zend.com

Open Server - это бесплатный локальный сервер с высоким функционалом по разработке и созданию сайтов. Работает в операционной системе Windows.

Скачать можно с официального сайта open-server.ru

Лично я пользуюсь бесплатным локальным сервером . Почему Denwer, а не какой-то другой? Скорей всего привычка. Я начинал с локального сервера Denwer, потому только им и пользуюсь. А вам нужно самим выбрать, с каким локальным сервером будете работать.

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

Согласно статистическим данным проекта W3techs, более 80% веб-приложений и сайтов работают на серверах с открытым исходным кодом. Не зря именно о «доминировании в сети» чаще всего говорят сторонники Open Source, когда заходит речь о доле Linux на рынке.

На какие проекты следует обратить внимание в первую очередь? Какие открытые серверы лучше всего подойдут для решения пользовательских задач?

Эксперт в области e-Government Робин Мульвижк на страницах сайта OpenSource.com предлагает пять наиболее популярных открытых веб-серверов.

Apache HTTP Server

В феврале 2015 года этот проект отметил своё двадцатилетие. Это самый популярный веб-сервер в мире - по данным W3techs, на нём работает 52% всех сайтов в мире.

Чаще всего платформой для Apache HTTP Server является Linux. Но приложение мультиплатформенное - сервер можно развернуть на OS X или Windows. Решение построено по модульному принципу, поэтому при необходимости его функциональность расширяется. Например, при помощи модуля mod_proxy на сервере создаётся шлюз, модуль mod_proxy_balancer сбалансирует нагрузку для всех поддерживаемых протоколов, а модуль mod_http2 отвечает за поддержку HTTP/2.

Проект сопровождается прекрасной документацией и комплексной поддержкой со стороны других пользователей. Распространяется решение на условиях Apache License v. 2.

NGINX

Разработка этого сервера началась в 2002 году российским программистом Игорем Сысоевым. Первый публичный выпуск приложения состоялся в 2004 году и по сути являлся ответом на проблему C10K - задачи по построению высокопроизводительного сервера, способного одновременно обслуживать 10 тысяч соединений.

Согласно данным W3techs, этот сервер занимает второе место по популярности в мире среди решений с открытым исходным кодом. На нём работает чуть больше 30% всех сайтов.

Чаще всего системные администраторы выбирают NGINX из-за высокой производительности и способности к масштабированию. Решение прекрасно подходит для обработки множества параллельных сеансов.

Распространяется приложение на условиях очень короткой BSD-подобной лицензии.

Apache Tomcat

Apache Tomcat - открытое приложение, разрабатываемое Apache Software Foundation и представляющее собой контейнер сервлетов, который функционирует в качестве веб-сервера, расширяя таким образом его функциональность. Написан на языке Java. Изначально права на решение принадлежали компании Sun Microsystems, которая в 1999 году безвозмездно передала их фонду.

Как правило, Apache Tomcat используется либо как обслуживающий локальные файлы самостоятельный веб-сервер, либо как сервер приложений на Apache HTTP Server. По данным W3techs, он применяется на 1% всех сайтов Интернета.

Распространяется приложение на условиях Apache License v. 2.

Node.js

Разработка Node.js началась в 2009 году Райаном Далем. В настоящее время проектом управляет Node.js Foundation при поддержке Linux Foundation. Согласно данным W3techs, рыночная доля решения составляет 0,2%.

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

Распространяется приложение на условиях оригинальной лицензии.

Lighttpd

Первый выпуск этого приложения датирован мартом 2003 года. Как и NGINX, веб-сервер Lighttpd способен поддерживать 10 тыс. соединений одновременно, что стало возможно благодаря их асинхронной обработке. По данным W3techs, этот сервер обслуживает 0,1% всех сайтов.

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

Распространяется решение на условиях лицензии BSD.

Работа с Web-сервером Russian Apache. Русский Apache

Самый распространенный Web-сервер в мире - это Apache. По данным компании Netcraft (http://www.netcraft.com/ Survey/ ) общее число Web-узлов, работающих под его управлением, к концу 1998 г. достигло 2 млн. (55% общего числа узлов) и постоянно растет. Для сравнения: на долю серверов Microsoft приходится 25%, Netscape -7%. Будучи бесплатной открытой программой, предназначенной для бесплатных же Unix-систем (FreeBSD, Linux и др.), Apache по функциональным возможностям и надежности не уступает коммерческим серверам, а широкие возможности конфигурирования позволяют настроить его для работы практически с любой конкретной системой. Существуют локализации сервера для различных языков, в том числе и для русского.

Исторически сложилось так, что русские тексты в Internet могут быть представлены в разных кодировках, из которых наиболее распространены koi8-r (или просто koi8) и Windows-1251: с первой работает большинство серверов и рабочих станций под управлением Unix, вторая является стандартной для всех версий Windows. Поскольку кодировка Windows-1251, естественно, применяется на подавляющем большинстве клиентских машин, доля тех, кто путешествует по русской части WWW, используя koi8, не превышает сейчас 5%. Однако в этой кодировке хранятся документы на многих Unix-серверах, в ней чаще всего передаются почтовые сообщения и практически всегда - письма в телеконференции, с ней же работают многие русскоязычные каналы IRC (кстати, аббревиатура КОИ расшифровывается как "код обмена информацией"). Чтобы решить проблемы, возникающие при несовпадении кодировок текста на сервере и клиентской машине, и был создан русский модуль Apache-RUS для Web-сервера Apache.

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

Установка

Свежую версию Apache-RUS можно получить по адресу ftp://apache.lexa.ru/pub/apache-rus/ ("старшая" часть номера версии, например 1.3.3, соответствует версии оригинального Apache, "младшая", например PL27.3, - так называемому patch level, т. е. версии русского модуля). Рекомендуется устанавливать те версии, которые зарекомендовали себя как "стабильные". Здесь настройка сервера описывается на примере Apache_1.3.3rusPL27.3.

Итак, первым делом мы переписываем на свою машину архив (менее 1,5 Мбайт) и распаковываем его:

# ftp ftp://apache.lexa.ru/pub/apache-rus/ apache_1.3.3rusPL27.3.tar.gz

# tar xvzf apache_1.3.3rusPL27.3.tar.gz

После этого входим в созданный при распаковке каталог apache_1.3.3rusPL27.3 и запускаем сценарий configure:

# cd apache_1.3.3rusPL27.3

При необходимости сценарию можно в явной форме указать аргументы (их список выдается по команде configure -help). Так, если требуется установить сервер в иной каталог, нежели стандартный, нужно выполнить "configure -prefix=

Когда configure отработает, следует, как обычно, дать команды make и make install (эти действия выполняются пользователем root).

Теперь сервер установлен в каталоге /usr/local/apache, но запускать его пока нельзя - сначала мы должны отредактировать файлы настройки httpd.conf, access.conf и srm.conf в каталоге /usr/local/apache/etc/ (начиная с версии 27.4 - /usr/local/apache/conf).

Настройка

Настройка конфигурационных файлов Web-сервера - самый ответственный шаг при его установке. Здесь мы рассмотрим только наиболее распространенные директивы и их параметры, поскольку полный перечень с описанием займет не один десяток страниц. Сервер перечитывает конфигурационные файлы при запуске, а также при получении сигнала -HUP (жесткий рестарт) или -uSR1 (мягкий рестарт). Если сервер находится в рабочем состоянии, то при изменении конфигурации его рекомендуется перезапустить командой

# kill -USR1 `cat /usr/local/apache/logs/httpd.pid`

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

Файл access.conf

В access.conf содержатся директивы, описывающие права доступа к каталогам и файлам Web-сервера. Прежде всего решите, в каком каталоге будут храниться документы. По умолчанию это /usr/local/apache/share/htdocs, однако многие администраторы предпочитают размещать документы начиная с каталога /www/<имя_сервера>/, поскольку при такой организации проще ориентироваться в структуре файлов. Пусть, например, мы создали каталоги:

/www/radio-msu.net/

/www/people.radio-msu.net/

Они будут корневыми для соответствующих виртуальных серверов.

Файл access.conf может содержать секции Directory, Location и Files, которые ограничены одноименными директивами. В параметрах этих директив могут использоваться символы "?" и "*" , а также регулярные выражения, предваряемые тильдой, например . В секции Directory помещаются инструкции, относящиеся к определенному каталогу на диске, в секции Location - относящиеся к виртуальному пути, в секции Files - относящиеся к файлу или группе файлов.

# директивы, относящиеся ко всем документам, хранящимся в

каталоге /www/rmt.ru и вложенных в него

# директивы, относящиеся ко всем документам, доступным по адресу http://<имя_сервера>/cgi-bin/ <путь_к_файлу>

# директивы, относящиеся к файлу form.html из каталога

Различие между секциями Directory и Location состоит в том, что первая относится к каталогам на диске, вторая - к виртуальному пути (URL), который браузер запрашивает у Web-сервера. И в той, и в другой могут присутствовать директивы order, allow и deny, которые позволяют ограничить доступ к каталогу или URL с различных машин.

Следующие две директивы относятся к секции .

Options

Возможные значения параметров:

ExecCGI - разрешить выполнение CGI-сценариев в данном каталоге и его поддереве;

FollowSymLinks - разрешить переходы по символическим ссылкам (создаваемым командой ln);

Includes - разрешить SSI (Server Side Includes);

Indexes - разрешить выдачу листинга каталога, если в нем нет файла index.html (или файла индекса, заданного директивой DirectoryIndex);

MultiViews - разрешить поддержку многих языков; по умолчанию она отключена, и включать ее, как правило, не нужно; поддержка перекодирования "на лету" для русского языка устанавливается с помощью других директив, которые мы рассмотрим позже;

All - установить сразу все перечисленные режимы кроме MultiViews.

При отсутствии специальных требований к безопасности вполне допустимо указать "Options All" в секции ; в противном случае нужно описать параметры каждого каталога отдельно.

AllowOverride

Большинство директив могут задаваться не только в конфигурационных файлах сервера, но и в файлах.htaccess в каталогах сервера. Директива AllowOverride определяет набор директив, допустимых в файлах.htaccess. Параметры могут быть указаны следующие:

FileInfo - разрешить директивы, отвечающие за типы документов;

Indexes - разрешить директивы, связанные с листингом каталогов;

Limit - разрешить команды allow и deny, которые ограничивают доступ к файлам в зависимости от адреса клиентского компьютера;

Options - разрешить описанную выше директиву Options.

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

Однако во многих случаях (в частности, когда права на изменение содержимого сервера есть только у администратора) файл access.conf может выглядеть так, как в.

Файл srm.conf

Файл srm.conf содержит директивы, связанные с общими настройками структуры каталогов сервера. Как правило, в нем достаточно изменить лишь несколько строк.

DocumentRoot <первый каталог сервера>

Путь к каталогу по умолчанию, индексный файл которого пользователь получит при обращении к серверу (http://<имя_сервера>/). Эту директиву следует задать и для каждого из виртуальных серверов (в секции файла httpd.conf).

UserDir <имя пользовательского каталога>

Каталог, в котором пользователи должны размещать свои файлы, чтобы они были доступны по адресу http://<имя_сервера>/~<имя_пользователя>/. Стандартно public_html. Иногда, чтобы облегчить жизнь пользователям, администраторы дают директиву "UserDir www".

DirectoryIndex <список файлов индекса>

Файл индекса - это тот файл, который будет передан клиенту при обращении к каталогу. Если указать несколько имен, сервер будет искать подходящий файл "слева направо". По умолчанию список содержит всего одно имя - index.html, но принято добавлять в него и другие распространенные имена индексных файлов. Например, директива может иметь вид: DirectoryIndex .index.html index.html index.htm index.cgi index.shtml home.html home.htm default htm default html

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

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

ErrorDocument 404 /missing.html

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

Файл httpd.conf

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

Директива Port, помещенная в самом начале файла, определяет номер порта для http-сервера; по умолчанию это 80. При необходимости можно приписать серверу другой порт или несколько портов, для чего служит директива Listen.

Директива HostnameLookups с параметром on или off включает или, соответственно, отключает преобразование численных IP-адресов клиентов, получивших документы с сервера, в доменные имена. Такое преобразование несколько замедляет работу сервера, но при числе посещений менее 10 000 в сутки это, как правило, практически не заметно.

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

Директивы ServerRoot, ErrorLog, CustomLog определяют соответственно корневой каталог http-сервера, путь к журналу регистрации ошибок (error_log) и путь к общему журналу обращений к серверу (access_log).

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

Настройка виртуальных серверов в файле httpd.conf

В большинстве случаев один http-сервер способен обрабатывать запросы, поступающие на различные, так называемые виртуальные, Web-серверы. Виртуальные серверы могут иметь как один и тот же IP-адрес, но разные доменные имена, так и разные IP-адреса. С точки зрения пользователя второй вариант чуть более предпочтителен, поскольку запрос к серверу, отличающемуся от основного только доменным именем, должен содержать его имя, а некоторые старые браузеры, не поддерживающие протокол HTTP/1.1 (например, Microsoft Internet Explorer 2.0), не включают в запрос эту информацию. Однако такие браузеры выходят из употребления (сейчас их уже менее 0,5% общего числа); с другой стороны, выделение собственного IP-адреса каждому виртуальному серверу может быть неоправданной растратой адресного пространства компании.

Для описания адресов и доменных имен виртуальных серверов служат директивы ServerName, ServerAlias, NameVirtualHost и VirtualHost. Они необходимы, только если вам нужно установить более одного виртуального сервера.

http://www.apache.org/ - официальный сервер разработчиков Apache

http://apache.lexa.ru/ - сервер группы разработчиков русского модуля Apache

Привет, эта статья рассматривает 5 наиболее популярных вариантов настройки сервера для веб-приложения. Какие варианты бывают и какой из них выбрать?

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

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

1. Все на одном сервере

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

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

Плюсы:

• Простота

Минусы:

• Приложение и база данных используют одни и те же ресурсы сервера (CPU, память, I/O и т.д.), что, помимо потенциально низкой производительности, затрудняет определение источника (приложение или база данных) этой самой низкой производительности.
• Затруднительно осуществлять горизонтальное масштабирование.

2. Выделенный сервер баз данных

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

Пример использования: Хорошо подходит для быстрого развертывания приложения, но при этом устраняет проблему конкуренции приложения и базы данных за одни системные ресурсы.

Плюсы:

• Приложение и база данных не конкурируют за одни и те же ресурсы сервера (CPU, память, I/O и т.д.).
• Вы можете вертикально масштабировать каждый компонент (приложение и базу данных) независимо друг от друга, добавляя дополнительные ресурсы к нужному серверу.
• При определенных настройках это может повысить безопасность, убрав базу данных из DMZ.

Минусы:

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

3. Балансировщик нагрузки (обратный прокси)

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

Примеры программного обеспечения, поддерживающего обратный прокси: HAProxy, и Varnish.

Пример использования: Полезен для окружения, которое требует масштабирования путем добавления дополнительных серверов, так же известное как горизонтальное масштабирование.

Плюсы:

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

Минусы:

• Балансировщик нагрузки может стать узким местом в производительности, если он испытывает нехватку ресурсов или плохо настроен.
• Может создать дополнительные сложности, требующие дополнительных усилий от администратора, например, работа с приложениями, которые требуют так называемых «липких сессий» (sticky session).

4. HTTP Accelerator (кэширующий обратный прокси)

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

Примеры программного обеспечения, поддерживающего HTTP acceleration: Varnish, Squid, Nginx.

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

Плюсы:

• Повышает производительность сайта путем снижения нагрузки на процессор веб-сервера за счет кэширования и сжатия, тем самым увеличивая количество обслуживаемый пользователей.
• Может быть использован как балансировщик нагрузки обратного прокси.
• Некоторое программное обеспечение для кэширования может защищать от DDOS атак.

Минусы:

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

5. Репликация базы данных по схеме ведущий-ведомый (Master-Slave)

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

Пример использования: Дает хорошее увеличение производительности приложения в части чтения из базы данных.

Вот пример репликации базы данных по схеме ведущий-ведомый с одним ведомым узлом:

Плюсы:

• Улучшает производительность чтения из базы данных путем распределения запросов на чтение между ведомыми узлами.
• Может улучшить производительность записи путем использования ведущего узла исключительно для записи (таким образом он не тратит время на обслуживание запросов на чтение)

Минусы:

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

Пример: комбинирование концепций

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

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

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

Вот что будет происходить, когда пользователь отправит запрос на динамический контент:

1. Пользователь запрашивает динамический контент с http://example.com/ (балансировщик нагрузки).
2. Балансировщик нагрузки посылает запрос на сервер приложения (app-backend).

Если пользователь запрашивает статический контент:

1. Балансировщик нагрузки проверяет кэш (cache-backend) на предмет того, закэширован ли запрашиваемый контент.
2. Если закэширован , то запрашиваемый контент возвращается балансирощику нагрузки, переходим в шагу 7. Если не закэширован , то сервер кэширование перенаправит запрос на сервер приложения через балансировщик нагрузки.
3. Балансировщик нагрузки перенаправит запрос на сервер приложения.
4. Сервер приложения (app-backend) читает из базы и возвращает запрашиваемый контент обратно балансировщику нагрузки.
5. Балансировщик нагрузки перенаправляет ответ к серверу кэширования (cache-backend).
6. Сервер кэширования кэширует полученный контент и возвращает его балансировщику нагрузки.
7. Балансировщик нагрузки возвращает запрашиваемый контент пользователю.

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

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