nginx что это такое
Руководство для начинающих
В этом руководстве даётся начальное введение в nginx и описываются некоторые простые задачи, которые могут быть решены с его помощью. Предполагается, что nginx уже установлен на компьютере читателя. Если нет, см. Установка nginx. В этом руководстве описывается, как запустить и остановить nginx и перезагрузить его конфигурацию, объясняется, как устроен конфигурационный файл, и описывается, как настроить nginx для раздачи статического содержимого, как настроить прокси-сервер на nginx, и как связать nginx с приложением FastCGI.
У nginx есть один главный и несколько рабочих процессов. Основная задача главного процесса — чтение и проверка конфигурации и управление рабочими процессами. Рабочие процессы выполняют фактическую обработку запросов. nginx использует модель, основанную на событиях, и зависящие от операционной системы механизмы для эффективного распределения запросов между рабочими процессами. Количество рабочих процессов задаётся в конфигурационном файле и может быть фиксированным для данной конфигурации или автоматически устанавливаться равным числу доступных процессорных ядер (см. worker_processes).
Запуск, остановка, перезагрузка конфигурации
Где сигнал может быть одним из нижеследующих:
Например, чтобы остановить процессы nginx с ожиданием окончания обслуживания текущих запросов рабочими процессами, можно выполнить следующую команду:
Команда должна быть выполнена под тем же пользователем, под которым был запущен nginx.
Изменения, сделанные в конфигурационном файле, не будут применены, пока команда перезагрузить конфигурацию не будет вручную отправлена nginx’у или он не будет перезапущен. Для перезагрузки конфигурации выполните:
Получив сигнал, главный процесс проверяет правильность синтаксиса нового конфигурационного файла и пытается применить конфигурацию, содержащуюся в нём. Если это ему удаётся, главный процесс запускает новые рабочие процессы и отправляет сообщения старым рабочим процессам с требованием завершиться. В противном случае, главный процесс откатывает изменения и продолжает работать со старой конфигурацией. Старые рабочие процессы, получив команду завершиться, прекращают принимать новые запросы и продолжают обслуживать текущие запросы до тех пор, пока все такие запросы не будут обслужены. После этого старые рабочие процессы завершаются.
Дополнительную информацию об отправке сигналов процессам nginx можно найти в Управление nginx.
Структура конфигурационного файла
nginx состоит из модулей, которые настраиваются директивами, указанными в конфигурационном файле. Директивы делятся на простые и блочные. Простая директива состоит из имени и параметров, разделённых пробелами, и оканчивается точкой с запятой ( ; ). Блочная директива устроена так же, как и простая директива, но вместо точки с запятой после имени и параметров следует набор дополнительных инструкций, помещённых внутри фигурных скобок ( < и >). Если у блочной директивы внутри фигурных скобок можно задавать другие директивы, то она называется контекстом (примеры: events, http, server и location).
Часть строки после символа # считается комментарием.
Раздача статического содержимого
Во-первых, создайте каталог /data/www и положите в него файл index.html с любым текстовым содержанием, а также создайте каталог /data/images и положите в него несколько файлов с изображениями.
В блок server добавьте блок location следующего вида:
Далее, добавьте второй блок location :
Он будет давать совпадение с запросами, начинающимися с /images/ ( location / для них тоже подходит, но указанный там префикс короче).
Итоговая конфигурация блока server должна выглядеть следующим образом:
Чтобы применить новую конфигурацию, запустите nginx, если он ещё не запущен, или отправьте сигнал reload главному процессу nginx, выполнив:
Настройка простого прокси-сервера
Одним из частых применений nginx является использование его в качестве прокси-сервера, то есть сервера, который принимает запросы, перенаправляет их на проксируемые сервера, получает ответы от них и отправляет их клиенту.
Мы настроим базовый прокси-сервер, который будет обслуживать запросы изображений из локального каталога и отправлять все остальные запросы на проксируемый сервер. В этом примере оба сервера будут работать в рамках одного экземпляра nginx.
Во-первых, создайте проксируемый сервер, добавив ещё один блок server в конфигурационный файл nginx со следующим содержимым:
Далее, используйте конфигурацию сервера из предыдущего раздела и видоизмените её, превратив в конфигурацию прокси-сервера. В первый блок location добавьте директиву proxy_pass, указав протокол, имя и порт проксируемого сервера в качестве параметра (в нашем случае это http://localhost:8080 ):
Итоговая конфигурация прокси-сервера выглядит следующим образом:
Чтобы применить новую конфигурацию, отправьте сигнал reload nginx’у, как описывалось в предыдущих разделах.
Существует множество других директив для дальнейшей настройки прокси-соединения.
Настройка проксирования FastCGI
nginx можно использовать для перенаправления запросов на FastCGI-серверы. На них могут исполняться приложения, созданные с использованием разнообразных фреймворков и языков программирования, например, PHP.
Что Такое NGINX? И Как Оно Работает?
Что таоке NGINX? NGINX (англ), произносится как «енджин-екс», является известным программным обеспечением с открытым исходным кодом для веб-сервера. В своём первоначальном выпуске оно функционировало для веб-обслуживания HTTP. Однако сегодня оно также служит обратным прокси-сервером, балансировщиком нагрузки HTTP и почтовым прокси-сервером для IMAP, POP3 и SMTP.
Официальный выпуск NGINX состоялся в октябре 2004 года. Создатель программного обеспечения, Игорь Сысоев, начал свой проект в 2002 году, пытаясь ответить на проблему C10k. C10k — это задача одновременного управления десятью тысячами соединений. Сегодня существует ещё больше подключений, которые должны обрабатывать веб-серверы. По этой причине NGINX предлагает управляемую событиями и асинхронную архитектуру. Эта функция делает NGINX одним из самых надёжных ПО для серверов по скорости и масштабируемости.
Благодаря превосходной способности обрабатывать большое количество соединений и скорости, многие сайты с высоким трафиком используют сервис NGINX. Некоторые из этих онлайн-гигантов — Google, Netflix, Adobe, Cloudflare, WordPress.com и многие другие.
Как работает NGINX?
Прежде чем узнать больше о NGINX, давайте посмотрим, как работает веб-сервер. Когда кто-то делает запрос на открытие веб-страницы, браузер связывается с сервером этого веб-сайта. Затем сервер ищет запрошенные файлы для страницы и отправляет их в браузер. Это только самый простой вид запроса.
Приведённый выше пример также рассматривается как один поток. Традиционные веб-серверы создают отдельный поток для каждого запроса, но NGINX не работает таким образом. Как указано выше, NGINX работает с асинхронной архитектурой, управляемой событиями. Это означает, что аналогичные потоки управляются одним рабочим процессом, и каждый рабочий процесс содержит меньшие блоки, называемые рабочими соединениями. Весь этот блок отвечает за обработку потоков запросов. Рабочие соединения доставляют запросы к рабочему процессу, который также отправляет его в главный процесс. Наконец, основной процесс предоставляет результат этих запросов.
Это может показаться простым, но одно рабочее соединение может обрабатывать до 1024 похожих запросов. Благодаря этому NGINX может без проблем обрабатывать тысячи запросов. Это также причина, по которой NGINX отлично подходит для загруженных веб-сайтов, таких как интернет-магазины, поисковые системы и облачное хранилище.
Прежде чем читать дальше, подумайте о самой инновационной структуре хостинга, которая может понадобиться для вашего сайта. Hostinger предлагает общий, VPS и облачный хостинг для небольших и готовых к росту веб-сайтов.
NGINX или Apache
Среди популярных веб-серверов Apache является одним из главных конкурентов NGINX. Он существует с 90-х годов и имеет большое сообщество пользователей. Если вам интересно, какой веб-сервер лучше всего подходит для ваших нужд, взгляните на это краткое и информативное сравнение между NGINX и Apache.
Поддержка ОС
Совместимость — это одна из маленьких деталей, которую следует учитывать при выборе программного обеспечения. И NGINX, и Apache могут работать во многих операционных системах, поддерживающих систему Unix. К сожалению, производительность NGINX в Windows не так велика, как на других платформах.
Поддержка пользователей
Пользователям, от новичков до профессионалов, всегда нужно хорошее сообщество, которое может помочь, когда они сталкиваются с проблемами. Хотя и NGINX, и Apache имеют поддержку по почте и форум по переполнению стека, Apache не хватает поддержки со стороны его компании, Apache Foundation.
Производительность
NGINX может одновременно выполнять 1000 подключений статического контента в два раза быстрее, чем Apache, и использует немного меньше памяти. Однако при сравнении их производительности при работе с динамическим контентом обе имеют одинаковую скорость. NGINX это лучший выбор для тех, у кого более статичный сайт.
Заключение
Что таоке NGINX? NGINX это веб-сервер, который также выступает в качестве прокси-сервера электронной почты, обратного прокси-сервера и балансировщика нагрузки. Структура программного обеспечения является асинхронной и управляемой событиями, что позволяет обрабатывать много запросов одновременно. NGINX также хорошо масштабируется, а это означает, что его сервис растёт вместе с трафиком клиентов. NGINX и Apache действительно являются двумя лучшими веб-серверами на рынке.
Анна долгое время работала в сфере социальных сетей и меседжеров, но сейчас активно увлеклась созданием и сопровождением сайтов. Она любит узнавать что-то новое и постоянно находится в поиске новинок и обновлений, чтобы делиться ими с миром. Ещё Анна увлекается изучением иностранных языков. Сейчас её увлёк язык программирования!
NGINX изнутри: рожден для производительности и масштабирования
NGINX вполне заслуженно является одним из лучших по производительности серверов, и всё это благодаря его внутреннему устройству. В то время, как многие веб-серверы и серверы приложений используют простую многопоточную модель, NGINX выделяется из общей массы своей нетривиальной событийной архитектурой, которая позволяет ему с легкостью масштабироваться до сотен тысяч параллельных соединений.
Инфографика Inside NGINX сверху вниз проведет вас по азам устройства процессов к иллюстрации того, как NGINX обрабатывает множество соединений в одном процессе. Данная статья рассмотрит всё это чуть более детально.
Подготавливаем сцену: модель NGINX процессов
Чтобы лучше представлять устройство, сперва необходимо понять как NGINX запускается. У NGINX есть один мастер-процесс (который от имени суперпользователя выполняет такие операции, как чтение конфигурации и открытие портов), а также некоторое количество рабочих и вспомогательных процессов.
На 4-х ядерном сервере мастер-процесс NGINX создает 4 рабочих процесса и пару вспомогательных кэш-процессов, которые управляют содержимым кэша на жестком диске.
Почему архитектура всё же важна?
Одна из фундаментальных основ любого Unix-приложения — это процесс или поток (с точки зрения ядра Linux процессы и потоки практически одно и то же — вся разница в разделении адресного пространства). Процесс или поток — это самодостаточный набор инструкций, который операционная система может запланировать для выполнения на ядре процессора. Большинство сложных приложений параллельно запускают множество процессов или потоков по двум причинам:
Наиболее типичный подход к построению сетевого приложения — это выделять для каждого соединения отдельный процесс или поток. Такая архитектура проста для понимания и легка в реализации, но при этом плохо масштабируется когда приложению приходится работать с тысячами соединений одновременно.
Как же работает NGINX?
NGINX использует модель с фиксированным числом процессов, которая наиболее эффективно задействует доступные ресурсы системы:
Когда NGINX находится под нагрузкой, то в основном заняты рабочие процессы. Каждый из них обрабатывает множество соединений в неблокирующемся режиме, минимизируя количество переключений контекста.
Каждый рабочий процесс однопоточен и работает независимо, принимая новые соединения и обрабатывая их. Процессы взаимодействуют друг с другом используя разделяемую память для данных кэша, сессий и других общих ресурсов.
Внутри рабочего процесса
Каждый рабочий процесс NGINX инициализируется с заданной конфигурацией и набором слушающих сокетов, унаследованных от мастер-процесса.
Рабочие процессы начинают с ожидания событий на слушающих сокетах (см. также accept_mutex и разделяемые сокеты). События извещают о новых соединениях. Эти соединения попадают в конечный автомат — наиболее часто используемый предназначен для обработки HTTP, но NGINX также содержит конечные автоматы для обработки потоков TCP трафика (модуль stream) и целого ряда протоколов электронной почты (SMTP, IMAP и POP3).
Конечный автомат в NGINX по своей сути является набором инструкций для обработки запроса. Большинство веб-серверов выполняют такую же функцию, но разница кроется в реализации.
Устройство конечного автомата
Конечный автомат можно представить себе в виде правил для игры в шахматы. Каждая HTTP транзакция — это шахматная партия. С одной стороны шахматной доски веб-сервер — гроссмейстер, который принимает решения очень быстро. На другой стороне — удаленный клиент, браузер, который запрашивает сайт или приложение по относительно медленной сети.
Как бы то ни было, правила игры могут быть очень сложными. Например, веб-серверу может потребоваться взаимодействовать с другими ресурсами (проксировать запросы на бэкенд) или обращаться к серверу аутентификации. Сторонние модули способны ещё сильнее усложнить обработку.
Блокирующийся конечный автомат
Вспомните наше определение процесса или потока, как самодостаточного набора инструкций, выполнение которых операционная система может назначать на конкретное ядро процессора. Большинство веб-серверов и веб-приложений используют модель, в которой для «игры в шахматы» приходится по одному процессу или потоку на соединение. Каждый процесс или поток содержит инструкции, чтобы сыграть одну партию до конца. Все это время процесс, выполняясь на сервере, проводит большую часть времени заблокированным в ожидании следующего хода от клиента.
NGINX, как настоящий Гроссмейстер
Вероятно вы слышали о сеансах одновременной игры, когда один гроссмейстер играет на множестве шахматных полей сразу с десятками противников?
Кирил Георгиев на турнире в Болгарии сыграл параллельно 360 партий. Его итоговый результат составил: 284 победы, 70 вничью и 6 поражений.
Таким же образом рабочий процесс NGINX «играет в шахматы». Каждый рабочий процесс (помните — обычно всего один на вычислительное ядро) является гроссмейстером, способным играть сотни (а на самом деле сотни тысяч) партий одновременно.
Почему так получается быстрее, чем блокирующаяся многопоточная архитектура?
Каждое новое соединение создает файловый дескриптор и потребляет небольшой объем памяти в рабочем процессе. Это очень малые накладные расходы на соединение. Процессы NGINX могут оставаться привязанными к конкретным ядрам процессора. Переключения контекста происходят достаточно редко и в основном когда не осталось больше работы.
В блокирующемся подходе, с отдельным процессом на каждое соединение, требуется сравнительно большой объем дополнительных ресурсов, и переключения контекста с одного процесса на другой происходят гораздо чаще.
Дополнительную информацию по теме можно также узнать из статьи об архитектуре NGINX от Андрея Алексеева, вице-президента по развитию и сооснователя компании NGINX, Inc.
С адекватной настройкой системы, NGINX прекрасно масштабируется до многих сотен тысяч параллельных HTTP cоединений на каждый рабочий процесс и уверенно поглощает всплески трафика (толпы новых игроков).
Обновление конфигурации и исполняемого кода
Архитектура NGINX с малым количеством рабочих процессов позволяет достаточно эффективно обновлять конфигурацию и даже его собственный исполняемый код на лету.
Обновление конфигурации NGINX — очень простая, легковесная и надежная процедура. Она заключается в простой отправке мастер-процессу сигнала SIGHUP.
Обновление исполняемого кода NGINX — это Святой Грааль высокой доступности сервисов. Вы можете обновлять сервер на лету, без потери соединений, простоя ресурсов и каких-либо перерывов в обслуживании клиентов.
Процесс обновления исполняемого кода использует схожий с перезагрузкой конфигурации подход. Новый мастер-процесс NGINX запускается параллельно со старым и получает от него дескрипторы слушающих сокетов. Оба процесса загружены и их рабочие процессы обрабатывают трафик. Затем вы можете отдать команду старому мастер-процессу на плавное завершение.
Вся процедура подробно описана в документации.
Подведем итоги
Мы дали поверхностный обзор того, как функционирует NGINX. Под этими простыми описаниями скрывается более чем десятилетний опыт разработки и оптимизации, который позволяет NGINX демонстрировать выдающуюся производительность на широком спектре оборудования и реальных задачах, оставаясь надежным и безопасным, как того требуют современные веб-приложения.
Если вы хотите узнать больше по данной теме, то рекомендуем для ознакомления:
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
nginx
| 64px | |
| Создатели: | Игорь Сысоев |
|---|---|
| Разработчики: | NGINX, Inc и Игорь Сысоев |
| Выпущена: | 4 October 2004 года ; 17 years ago ( 2004-10-04 ) |
| Постоянный выпуск: | 1.11.0 / 24 May 2016 года ; 5 years ago ( 2016-05-24 ) |
| Состояние разработки: | активное |
| Написана на: | C |
| Операционная система: | |