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

Функционирование nginx определяется конфигурационным файлом nginx.conf, находящимся в директории /etc/nginx. Nginx состоит из модулей, модули настраиваются директивами, директивы указываются в конфигурационном файле. Директивы в свою очередь, могут быть простыми или блочными.

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

Если в блочной директиве внутри фигурных скобок заданы другие директивы, то она называется контекстом, примерами могут служить: events, http, serv­er, loca­tion.

Директивы расположенные вне любого контекста считаются принадлежащими контексту main. Контексты events и http всегда должны находиться внутри контекста main. Контекст serv­er должен находиться внутри контекста http, а loca­tion внутри контекста serv­er.

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

Файл nginx.conf создаваемый по умолчанию, можно смело удалять, проще написать свой, чем править существующий.

Начинаем писать свою конфигурацию.

Контекст main

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

Определим число worker_processes или другими словами, рабочих процессов. Число процессов должно равняться числу процессорных ядер, хотя для последних версий nginx данный параметр рекомендуют устанавливать в значение auto. Поскольку на моем недорогом VPS/VDS сервере доступно одно ядро, то я устанавливаю значение равное единице.

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

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

Контекст events

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

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

Значение скорее всего будет равно 1024, это значение можно задать для worker_connections.

Директива use задает метод обработки соединений, в Lin­ux следует использовать метод epoll. Включение multi_accept позволяет принимать максимально возможное количество соединений.

Контекст http

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

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

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

Можно подключить только определенный вид файлов, например имеющих расширение ".conf", для этого нужно указать "*.conf".

Продолжаем писать конфигурацию и подключаем файл с MIME-типами данных. Данный файл содержит список MIME заголовков и расширений передающихся по сети в соответствии со стандартом MIME. По умолчанию файл mime.types находится в директории /etc/nginx, поэтому в include достаточно просто указать имя файла.

Задаем MIME-тип ответов по умолчанию.

Добавим системный вызов send­file. Системный вызов активирует передачу данных между файловыми дескрипторами посредством ядра, а не при помощи связки read + write. Send­file позволяет отправлять данные сразу в сеть, минуя процесс их копирования и тем самым повышая производительность.

Сразу добавим sendfile_max_chunk, для ограничения объема данных могущих передаваться за один вызов send­file. Если этого не сделать, то одно соединение может подмять под себя весь рабочий процесс.

Поскольку send­file активирована, то в таком случае нужно добавить tcp_nopush, директива позволяет передавать заголовок ответа и начало файла одним пакетом.

Отключаем буферизацию соединений перешедших в состояние keep-alive.

Установим временной промежуток в течении которого keep-alive соединение с клиентом не будет закрыто, если пользователь перестал отвечать. Поддерживая неактивное keep-alive соединение, мы тем самым занимаем соединение, которое может использоваться по другому.

Зададим максимальное число запросов для одного keep-alive соединения. После достижения максимального числа запросов соединение будет закрыто.

reset_timedout_connection закрывает подключения для переставших отвечать клиентов.

Установим таймаут чтения тела запроса для клиента. Если по истечении установленного времени клиент ничего не ответит, то ему будет возвращена ошибка 408 - Request Time-out.

Установим таймаут чтения заголовка запроса для клиента. Если по истечении установленного времени клиент не передаст заголовок полностью, то ему будет возвращена ошибка 408 - Request Time-out.

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

Зададим размер буфера для заголовка запроса от клиента.

При поступлении от клиентов больших запросов, можно выделять дополнительные буферы с помощью директивы large_client_header_buffers. Строка запроса не должна быть больше размера одного буфера, иначе клиенту будет возвращена ошибка 414 - Request URI Too Large. Поле заголовка запроса также не должно превышать размер одного буфера, иначе клиенту будет возвращена ошибка Bad Request.

Буферы выделяются по мере необходимости. Если по окончанию обработки запроса соединение переходит в состояние keep-alive буферы освобождаются. Может использоваться для защиты от различных ботов или DoS-атак.

Директивой client_body_buffer_size установим размер буфера для чтения тела запроса клиента.

client_max_body_size задает размер тела запроса клиента и ограничивает максимальный размер файла, который можно загрузить на сервер посредством PHP.

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

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

Укажем каталог в котором будут находиться конфигурационные файлы сайтов.

О конфигурационных файлах сайтов мы поговорим в следующей статье, в которой будет рассмотрена дальнейшая настройка Nginx под Word­Press-сайт.

Подводя итог статьи, привожу готовый файл nginx.conf.

До встречи.