Nginx 1.10 1 что делать. Способы применения Nginx. Почему так получается быстрее, чем блокирующаяся многопоточная архитектура

Более 50% трафика во всем мире обслуживает технология связки Apache и Nginx – веб сервера, которые имеют открытый исходный код. Nginx исполняет функцию фронтэнда, Apache – бэкэнда . Nginx первым принимает запросы пользователей и выдает по ним необходимый контент – изображения, файлы, скрипты. Тяжелый Apache в свою очередь не имеет с этим дело, а обрабатывает динамику. Nginx проксирует запросы и возвращает ответы . Данная связка отлично подходит для больших сайтов, которые посещают много пользователей. Для маленьких сайтов данная связка не даст роста производительности. Apache и Nginx снижает нагрузку на сервер в общем, благодаря тому, что Nginx обрабатывает статический контент, а Apache динамический.

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

Функциональный и быстрый Nginx был выпущен в 2004 году и после этого релиза начал набирать свою популярность. Благодаря своей легкости и масштабируемости хорошо работает на любом оборудовании. Nginx используют в двух направлениях: как веб сервер или как прокси.

Что делает Nginx в качестве веб сервера?

автоматически создает кэш дескрипторы и списки файлов, обслуживает индексные файлы и статические запросы;
ускоряет отказоустойчивость, проксирование и рапределение нагрузки;
кэширует при FastCGI и ускоряет проксирование;
поддерживает SSL;
поддерживает Perl;
имеет филтры и модульность;
аунтифецирует HTTP и фильтрирует SSL.

В качестве прокси Nginx:

полное обеспечение StartTLS и SSL;
легкость аутентификации (USER/PASS, LOGIN);
использует внешний HTTP-сервер для перенаправления на POP3/IMAP-бэкенд.

Как видим, Nginx выполняет множество функций, при этом не перегружая систему. По официальным данным, технологию используют более 56 млн. сайтов во всем мире (к примеру, Rambler, Yandex, Mail, Begun, WordPress.com, vk.com, Facebook, Rutracker.org), но по популярности Nginx уступает Apache. Почему же так популярен Apache?

Веб сервер Apache – кросплатформенное программное обеспечение, которое было создано в 1995 году. Благодаря большой документации и хорошей интеграции с сторонним ПО, Apache получил огромное распространение. Поддерживает следущие ОС – Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS. .

Преимущества веб сервера Apache:

поддержка языков программирования PHP, Python, Ruby, Perl, ASP, Tcl ;
легкость в подключении внешних модулей;
поддержка технологий CGI и FastCGI ;
наличие механизмов, которые обеспечивают безопасноть и разграничение к доступу данных;
возможность использовать СУБД для аутентификации пользователей;
гибкая и надежная конфигурация системы;
подходит для приложений, которым нужна мощная криптографическая защита данных ;
возможность создания пользовательских директорий для веб-сайта;
возможность настройки виртуальных хостов , с помощью которых на одном физическом сервере можно создать несколько виртуальных;
ведет протоколы того, что происходит на вашем сервере;
активная обратная связь с разработчиками и своевременное решения возникших ошибок в ПО.

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

Хотите обезопасить работу PHP на сервере? Об этом более подробно .

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

Обо всех технологиях, которые поддерживает хостинг HyperHost, более подробно по .

Данная статья была предоставлена для общего ознакомления с возможностями связки веб серверов Apache и Nginx. Еще больше информации в .

Если понадобится наша помощь, обращайтесь!

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

17247 раз(а) 8 Сегодня просмотрено раз(а)

Перевод

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

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

Устройство конечного автомата

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

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

Блокирующийся конечный автомат

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

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

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

NGINX, как настоящий Гроссмейстер

Вероятно вы слышали о сеансах одновременной игры, когда один гроссмейстер играет на множестве шахматных полей сразу с десятками противников?

Кирил Георгиев на турнире в Болгарии сыграл параллельно 360 партий. Его итоговый результат составил: 284 победы, 70 вничью и 6 поражений.

Таким же образом рабочий процесс NGINX «играет в шахматы». Каждый рабочий процесс (помните - обычно всего один на вычислительное ядро) является гроссмейстером, способным играть сотни (а на самом деле сотни тысяч) партий одновременно.

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

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

Почему так получается быстрее, чем блокирующаяся многопоточная архитектура?

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

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

Дополнительную информацию по теме можно также узнать из статьи об архитектуре NGINX от Андрея Алексеева, вице-президента по развитию и сооснователя компании NGINX, Inc.

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

Обновление конфигурации и исполняемого кода

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

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

Когда рабочий процесс получает SIGHUP, он производит несколько операций:

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

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

Обновление исполняемого кода NGINX - это Святой Грааль высокой доступности сервисов. Вы можете обновлять сервер на лету, без потери соединений, простоя ресурсов и каких-либо перерывов в обслуживании клиентов.

Nginx – это популярный и производительный веб-сервер и обратный прокси-сервер.

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

Примечание : Руководство выполнено на Ubuntu 12.04.

Иерархия каталогов Nginx

Nginx хранит конфигурационные файлы в каталоге /etc/nginx.

В этом каталоге находится ещё несколько каталогов и модульных конфигурационных файлов.

cd /etc/nginx
ls -F

conf.d/ koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-available/ win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled/

Пользователи Apache уже знакомы с каталогами sites-available и sites-enabled. Эти каталоги определяют конфигурации сайтов. Файлы обычно создаются и хранятся в sites-available; в sites-enabled хранятся только конфигурации включенных сайтов. Для этого нужно создать символическую ссылку из sites-available в sites-enabled.

Каталог conf.d тоже можно использовать для хранения конфигураций. Каждый файл с расширением.conf будет читаться при запуске Nginx. Синтаксис таких файлов не должен содержать ошибок.

Почти все оставшиеся файлы хранятся в /etc/nginx, который содержит сведения о конфигурации конкретных процессов или дополнительных компонентов.

Главным конфигурационным файлом Nginx является nginx.conf.

Файл nginx.conf

Файл nginx.conf читает соответствующие конфигурационные файлы и объединяет их в единый файл конфигурации при запуске сервера.

Откройте файл:

sudo nano /etc/nginx/nginx.conf

user www-data;
worker_processes 4;
pid /var/run/nginx.pid;
events {
worker_connections 768;
# multi_accept on;
}
http {
. . .

Первые строки задают общие сведения о Nginx. Строка user www-data указывает пользователя, с помощью которого запускается сервер.

Директива pid указывает, где будут храниться PID процессов для внутреннего использования. Строка worker_processes определяет количество процессов, которое может одновременно поддерживать Nginx.

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

За общими сведениями о сервере следует раздел events. Он управляет обработкой соединений Nginx. За ним идёт блок http. Прежде чем продолжить ознакомление с конфигурациями веб-сервера, нужно понять, как отформатирован конфигурационный файл Nginx.

Структура конфигурационного файла Nginx

Конфигурационный файл Nginx делится на блоки.

Первый блок – events, за ним идёт http и начинается главная иерархия конфигураций.

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

Во время настройки Nginx важно помнить следующее правило: чем выше уровень конфигурации, тем больше блоков наследует эту конфигурацию; чем ниже уровень конфигурации, тем она «индивидуальнее». То есть, если параметр Х должен применяться в каждом блоке server, то такой параметр нужно поместить в блок http.

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

Например, чтобы настроить сжатие файлов, нужно установить такие параметры:

gzip on;
gzip_disable "msie6";

Это включит поддержку gzip для сжатия отправляемых клиенту данных и отключит gzip для Internet Explorer 6 (поскольку этот браузер не поддерживает сжатия данных).

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

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

Блок http в файле nginx.conf заканчивается так:

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

Это говорит о том, что блоки server и location, которые определяют настройки конкретных сайтов и URL-адресов, будут храниться за пределами этого файла.

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

Закройте файл nginx.conf. Теперь нужно изучить настройки отдельных сайтов.

Виртуальные блоки Nginx

Блоки server в Nginx являются аналогом виртуальных хостов Apache (но для удобства их тоже принято называть виртуальными хостами). По сути, блоки server – это технические характеристики отдельных веб-сайтов, размещённых на одном сервере.

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

cd sites-available
sudo nano default

root /usr/share/nginx/www;
index index.html index.htm;
server_name localhost;
location / {

}
location /doc/ {

alias /usr/share/doc/;
autoindex on;
allow 127.0.0.1;
deny all;

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

Блок server включает в себя все настройки, помещённые между фигурными скобками:

server {
. . .
}

Этот блок размещён в файле nginx.conf ближе к концу блока http с помощью директивы include.

Директива root определяет каталог, в котором будет храниться контент сайта. В этом каталоге Nginx будет искать запрашиваемые пользователем файлы. По умолчанию это каталог /usr/share/nginx/www.

Обратите внимание: все строки заканчиваются точкой с запятой. Так Nginx отделяет одну директиву от другой. Если точки с запятой не будет, Nginx прочитает две директивы (или несколько директив) как одну директиву с дополнительными аргументами.

Директива index определяет файлы, которые будут использоваться в качестве индекса. Веб-сервер будет проверять файлы в порядке их перечисления. Если ни одна страница не была запрошена, блок server найдёт и вернёт файл index.html. Если он не сможет найти этот файл, он попытается обработать index.htm.

Директива server_name

Директива server_name содержит список доменных имен, которые будут обслуживаться этим блоком server. Количество доменов неограниченно; домены в списке следует разделять пробелами.

Символ звёздочки (*) в начале или конце домена задаёт имя с маской, где звёздочка соответствует части (или нескольким частям) имени. Например, имя *.example.com будет соответствовать именам forum.example.com и www.animals.example.com.

Если запрашиваемый url-адрес соответствует нескольким директивам server_name, он сначала ответит той, с которой совпадает полностью.

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

Имена сервера, которые используют регулярные выражения, начинаются с тильды (~). К сожалению, данная тема выходит за рамки данной статьи.

Блоки location

Строка location / указывает, что директивы в скобках будут применяться ко всем запрашиваемым ресурсам, которые не соответствуют никаким другим блокам location.

Такие блоки могут содержать uri путь (например /doc/). Чтобы установить полное соответствие между location и uri, используется символ =. Символ ~ устанавливает соответствие с регулярными выражениями.

Тильда включает чувствительный к регистру режим, а тильда со звёздочкой – регистронезависимый режим.

Если запрос полностью соответствует блоку location, то сервер останавливает поиск и использует такой блок. Если сервер не находит полностью подходящего блока location, он сравнивает URI с параметрами директив location. Nginx выберет блок, в котором используется сочетание символов ^~ и который совпадает с URI.

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

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

Директива try_files

Директива try_files – очень полезный инструмент, который проверяет наличие файлов в заданном порядке и использует первый найденный файл для обработки запроса.

Это позволяет вам с помощью дополнительных параметров определить, как Nginx будет обслуживать запросы.

В конфигурационном файле по умолчанию есть строка:

try_files $uri $uri/ /index.html;

Это значит, что при поступлении запроса, обслуживаемого блоком location, Nginx сначала попробует обслужить uri как файл (такое поведение задаёт переменная $uri).

Если сервер не обнаруживает соответствия переменной $uri, он попробует использовать uri как каталог.

С помощью слэша в конце сервер проверяет существование каталога, например, $uri/.

Если ни один файл или каталог не найден, Nginx выполняет файл по умолчанию (в данном случае это index.html в root-каталоге блока server). Каждая директива try_files использует последний параметр в качестве запасного варианта, потому этот файл должен существовать в системе.

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

Например, если блок location / не может найти запрашиваемый ресурс, вместо файла index.html он может вернуть ошибку 404:

try_files $uri $uri/ =404;

Для этого нужно поставить знак равно и задать код ошибки в качестве последнего параметра (=404).