1. Главная страница » Компьютеры » Nginx reuseport что это

Nginx reuseport что это

Автор: | 16.12.2019

« 403 Forbidden » — наиболее распространенная ошибка при работе с NGINX . В этой статье мы расскажем о причинах возникновения 403 forbidden NGINX , а также о том, как найти ее причину и исправить основную проблему.

Об ошибке

« 403 Forbidden » — это универсальная ошибка NGINX , которая указывает на то, что вы запросили что-то, а NGINX ( по ряду причин ) не может это предоставить. « 403 » является кодом состояния HTTP , который означает, что веб-сервер получил и понял ваш запрос, но не может предпринять никаких дальнейших действий.

Поиск файла конфигурации NGINX

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

Главный файл конфигурации — /etc/nginx/nginx.conf . Он содержит основные директивы для NGINX и является аналогом файла httpd.conf для Apache .

Чтобы отредактировать этот файл, используйте команду:

Некорректный индексный файл

Одна из наиболее распространенных причин ошибки 403 forbidden NGINX — некорректная настройка индексного файла.
nginx.conf указывает, какие индексные файлы должны загружаться, и в каком порядке. Например, приведенная ниже строка указывает NGINX искать index.html , затем index.htm , затем index.php :

Если ни один из этих трех файлов не будет найден в каталоге, NGINX вернет ошибку « 403 Forbidden ».

Примечание . Имена файлов чувствительны к регистру. Если nginx.conf указывает index.html , а файл называется Index.html , это приведет к ошибке « 403 Forbidden ».

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

Например, чтобы добавить index.py в список распознаваемых индексных файлов, отредактируйте эту строку следующим образом:

Сохраните изменения, а затем перезапустите NGINX командой:

Автоиндекс

Альтернативным решением является разрешение индекса директории. Индекс директории означает, что если индексный файл не найден, сервер отобразит все содержимое директории.

По соображениям безопасности индекс директории в NGINX по умолчанию отключен.

При « 403 forbidden NGINX », если вы хотите показать индекс директории в ситуациях, когда NGINX не может найти ( идентифицировать ) файл, отредактируйте nginx.conf , как описано выше, и добавьте в него две следующие директивы:

Эти директивы должны быть добавлены в блок location . Можно либо добавить их в существующий блок location/ , либо добавить новый. Окончательный результат должен выглядеть так:

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

Сохраните изменения в файле, затем перезапустите NGINX командой:

Права доступа к файлам

Некорректные права доступа к файлам являются еще одной причиной ошибки « 403 Forbidden NGINX ». Для использования с NGINX рекомендуется стандартная настройка: для каталогов — 755 и для файлов — 644 . Пользователь NGINX также должен быть владельцем файлов.

Идентификация пользователя NGINX

Для начала нужно определить, от имени какого пользователя запущен NGINX . Для этого используйте команду:

В этом примере рабочий процесс NGINX работает от имени пользователя nginx .

Установите права собственности на файл

Перейдите на уровень выше корневой директории документа сайта. Например, если корневая директория вашего сайта /usr/share/nginx/example.com , перейдите в /usr/share/nginx с помощью команды:

Измените права собственности на все файлы в директориях нижних уровней на пользователя nginx с помощью команды:

Установите права доступа

403 forbidden NGINX — как исправить: установите права доступа для каждой директории на 755 с помощью команды:

Например, чтобы установить права доступа для директории example.com , используется команда:

Затем перейдите в корневой каталог веб-документа:

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

Данная публикация представляет собой перевод статьи « Solve an NGINX 403 Forbidden Error » , подготовленной дружной командой проекта Интернет-технологии.ру

Основная функциональность

Пример конфигурации

Директивы

Синтаксис: accept_mutex on | off ;
Умолчание:
Контекст: events

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

Нет необходимости включать accept_mutex на системах, поддерживающих флаг EPOLLEXCLUSIVE (1.11.3), или при использовании reuseport.

До версии 1.11.3 по умолчанию использовалось значение on .

Синтаксис: accept_mutex_delay время ;
Умолчание:
Контекст: events
Читайте также:  Dir 300 настройка wan

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

Синтаксис: daemon on | off ;
Умолчание:
Контекст: main

Определяет, будет ли nginx запускаться в режиме демона. Используется в основном для разработки.

Синтаксис: debug_connection адрес | CIDR | unix: ;
Умолчание:
Контекст: events

Включает отладочный лог для отдельных клиентских соединений. Для остальных соединений используется уровень лога, заданный директивой error_log. Отлаживаемые соединения задаются IPv4 или IPv6 (1.3.0, 1.2.1) адресом или сетью. Соединение может быть также задано при помощи имени хоста. Отладочный лог для соединений через UNIX-сокеты (1.3.0, 1.2.1) включается параметром “ unix: ”.

Для работы директивы необходимо сконфигурировать nginx с параметром —with-debug , см. “Отладочный лог”.

Синтаксис: debug_points abort | stop ;
Умолчание:
Контекст: main

Эта директива используется для отладки.

В случае обнаружения внутренней ошибки, например, утечки сокетов в момент перезапуска рабочих процессов, включение debug_points приводит к созданию core-файла ( abort ) или остановке процесса ( stop ) с целью последующей диагностики с помощью системного отладчика.

Синтаксис: env переменная [= значение ];
Умолчание:
Контекст: main

По умолчанию nginx удаляет все переменные окружения, унаследованные от своего родительского процесса, кроме переменной TZ. Эта директива позволяет сохранить часть унаследованных переменных, поменять им значения или же создать новые переменные окружения. Эти переменные затем:

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

Если переменная TZ не описана явно, то она всегда наследуется и всегда доступна модулю ngx_http_perl_module.

Переменная окружения NGINX используется для внутренних целей nginx и не должна устанавливаться непосредственно самим пользователем.

Синтаксис: error_log файл [ уровень ];
Умолчание:
Контекст: main , http , mail , stream , server , location

Конфигурирует запись в лог. На одном уровне может использоваться несколько логов (1.5.2). Если на уровне конфигурации main запись лога в файл явно не задана, то используется файл по умолчанию.

Первый параметр задаёт файл , который будет хранить лог. Специальное значение stderr выбирает стандартный файл ошибок. Запись в syslog настраивается указанием префикса “ syslog: ”. Запись в кольцевой буфер в памяти настраивается указанием префикса “ memory: ” и размера буфера и как правило используется для отладки (1.7.11).

Второй параметр определяет уровень лога и может принимать одно из следующих значений: debug , info , notice , warn , error , crit , alert или emerg . Уровни лога, указанные выше, перечислены в порядке возрастания важности. При установке определённого уровня в лог попадают все сообщения указанного уровня и уровней большей важности. Например, при стандартном уровне error в лог попадают сообщения уровней error , crit , alert и emerg . Если этот параметр не задан, используется error .

Для работы уровня лога debug необходимо сконфигурировать nginx с —with-debug , см. “Отладочный лог”.

Директива может быть указана на уровне stream начиная с версии 1.7.11 и на уровне mail начиная с версии 1.9.0.

Синтаксис: events < . >
Умолчание:
Контекст: main

Предоставляет контекст конфигурационного файла, в котором указываются директивы, влияющие на обработку соединений.

Синтаксис: include файл | маска ;
Умолчание:
Контекст: любой

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

Синтаксис: load_module файл ;
Умолчание:
Контекст: main

Эта директива появилась в версии 1.9.11.

Загружает динамический модуль.

Синтаксис: lock_file файл ;
Умолчание:
Контекст: main

Для реализации accept_mutex и сериализации доступа к разделяемой памяти nginx использует механизм блокировок. На большинстве систем блокировки реализованы с помощью атомарных операций, и эта директива игнорируется. Для остальных систем применяется механизм файлов блокировок. Эта директива задаёт префикс имён файлов блокировок.

Синтаксис: master_process on | off ;
Умолчание:
Контекст: main

Определяет, будут ли запускаться рабочие процессы. Эта директива предназначена для разработчиков nginx.

Синтаксис: multi_accept on | off ;
Умолчание:
Контекст: events

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

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

Синтаксис: pcre_jit on | off ;
Умолчание:
Контекст: main
Читайте также:  Nullsoft scriptable install system

Эта директива появилась в версии 1.1.12.

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

Использование PCRE JIT способно существенно ускорить обработку регулярных выражений.

Для работы JIT необходима библиотека PCRE версии 8.20 или выше, собранная с параметром конфигурации —enable-jit . При сборке библиотеки PCRE вместе с nginx ( —with-pcre= ), для включения поддержки JIT необходимо использовать параметр конфигурации —with-pcre-jit .

Синтаксис: pid файл ;
Умолчание:
Контекст: main

Задаёт файл , в котором будет храниться номер (PID) главного процесса.

Синтаксис: ssl_engine устройство ;
Умолчание:
Контекст: main

Задаёт название аппаратного SSL-акселератора.

Синтаксис: thread_pool имя threads = число [ max_queue = число ];
Умолчание:
Контекст: main

Эта директива появилась в версии 1.7.11.

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

Параметр threads задаёт число потоков в пуле.

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

Синтаксис: timer_resolution интервал ;
Умолчание:
Контекст: main

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

Внутренняя реализация интервала зависит от используемого метода:

  • фильтр EVFILT_TIMER при использовании kqueue ;
  • timer_create() при использовании eventport ;
  • и setitimer() во всех остальных случаях.
Синтаксис: use метод ;
Умолчание:
Контекст: events

Задаёт метод , используемый для обработки соединений. Обычно нет необходимости задавать его явно, поскольку по умолчанию nginx сам выбирает наиболее эффективный метод.

Синтаксис: user пользователь [ группа ];
Умолчание:
Контекст: main

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

Синтаксис: worker_aio_requests число ;
Умолчание:
Контекст: events

Эта директива появилась в версиях 1.1.4 и 1.0.7.

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

Синтаксис: worker_connections число ;
Умолчание:
Контекст: events

Задаёт максимальное число соединений, которые одновременно может открыть рабочий процесс.

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

Синтаксис: worker_cpu_affinity маска_CPU . ;
worker_cpu_affinity auto [ маска_CPU ];
Умолчание:
Контекст: main

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

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

привязывает первый рабочий процесс к CPU0/CPU2, а второй — к CPU1/CPU3. Второй пример пригоден для hyper-threading.

Специальное значение auto (1.9.10) позволяет автоматически привязать рабочие процессы к доступным процессорам:

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

Директива доступна только на FreeBSD и Linux.

Синтаксис: worker_priority число ;
Умолчание:
Контекст: main

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

Синтаксис: worker_processes число | auto ;
Умолчание:
Контекст: main

Задаёт число рабочих процессов.

Оптимальное значение зависит от множества факторов, включая (но не ограничиваясь ими) число процессорных ядер, число жёстких дисков с данными и картину нагрузок. Если затрудняетесь в выборе правильного значения, можно начать с установки его равным числу процессорных ядер (значение “ auto ” пытается определить его автоматически).

Параметр auto поддерживается только начиная с версий 1.3.8 и 1.2.5.

Синтаксис: worker_rlimit_core размер ;
Умолчание:
Контекст: main

Изменяет ограничение на наибольший размер core-файла ( RLIMIT_CORE ) для рабочих процессов. Используется для увеличения ограничения без перезапуска главного процесса.

Синтаксис: worker_rlimit_nofile число ;
Умолчание:
Контекст: main

Изменяет ограничение на максимальное число открытых файлов ( RLIMIT_NOFILE ) для рабочих процессов. Используется для увеличения ограничения без перезапуска главного процесса.

Читайте также:  Ati radeon 9000 pro
Синтаксис: worker_shutdown_timeout время ;
Умолчание:
Контекст: main

Эта директива появилась в версии 1.11.11.

Задаёт таймаут в секундах для плавного завершения рабочих процессов. По истечении указанного времени nginx попытается закрыть все открытые соединения для ускорения завершения.

Синтаксис: working_directory каталог ;
Умолчание:
Контекст: main

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

Увеличиваем производительность с помощью SO_REUSEPORT в NGINX 1.9.1

Автор: admin от 3-06-2015, 12:50, посмотрело: 754

В NGINX версии 1.9.1 появилась новая возможность, позволяющая использовать сокетную опцию SO_REUSEPORT, которая доступна в современных версиях операционных систем, таких как DragonFly BSD и Linux (ядра 3.9 и новее). Данная опция разрешает открывать сразу несколько слушающих сокетов на одних и тех же адресе и порту. При этом, ядро будет распределять входящие соединения между ними.

(В NGINX Plus эта функциональность появится в выпуске 7, который выйдет позже в этом году.)

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

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

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

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

Конфигурация

Для включения SO_REUSEPORT в модулях http или stream достаточно указать параметр reuseport директивы listen, как в показано в примере:

Указание reuseport при этом автоматически отключает accept_mutex для данного сокета, поскольку в данном режиме мьютекс не нужен.

Тестируем производительность с reuseport

Измерения производились с помощью wrk используя 4 рабочих процесса NGINX на 36 ядерном AWS инстансе. Чтобы свести к минимуму сетевые издержки клиент и сервер работали через loopback-интерфейс, а NGINX был сконфигурирован для отдачи строки OK. Сравнивались три конфигурации: с accept_mutex on (default), c accept_mutex off и с reuseport. Как видно на диаграмме, включение reuseport в 2-3 раза увеличивает количество запросов в секунду и уменьшает задержки, а также их флуктуацию.

Также были проведены замеры, когда клиент и сервер были запущены на разных машинах и запрашивался html-файл. Как видно из таблицы, с reuseport происходит снижение задержек, аналогичное предыдущему замеру, а их разброс снижается еще сильнее (почти на порядок). Другие тесты также показывали хорошие результаты от использования опции. С использованием reuseport нагрузка распределялась равномерно по рабочим процессам. С включенной директивой accept_mutex наблюдался дисбаланс в начале теста, а в случае отключения все рабочие процессы занимали больше процессорного времени.

Latency (ms) Latency stdev (ms) CPU Load
Default 15.65 26.59 0.3
accept_mutex off 15.59 26.48 10
reuseport 12.35 3.15 0.3

В данных тестах частота запросов была крайне высокой, при этом они не требовали какой-либо сложной обработки. Другие наблюдения также показывают, что наибольший эффект от опции reuseport достигается когда нагрузка отвечает данному паттерну. Таким образом, опция reuseport не доступна для модуля mail, поскольку почтовый трафик однозначно не удовлетворяет данным условиям. Мы рекомендуем всем производить собственные замеры, чтобы убедиться в наличии эффекта от reuseport, а не слепо включать опцию везде, где толко это возможно. Некоторые советы по тестированию производительности NGINX вы можете почерпнуть из выступления Константина Павлова на конференции nginx.conf 2014.

Благодарность

Спасибо Sepherosa Ziehau и Yingqi Lu, каждый из которых предложил собственное решение для работы SO_REUSEPORT в NGINX. Команда NGINX использовала их идеи для реализации, которую мы считаем идеальной.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *