NGINX — различия между версиями
Gary (обсуждение | вклад) |
Gary (обсуждение | вклад) (→Мониторинг) |
||
Строка 75: | Строка 75: | ||
===Мониторинг=== | ===Мониторинг=== | ||
{|class="wikitable" width=100% | {|class="wikitable" width=100% | ||
− | |+ NGINX как | + | |+ NGINX как инструмент наблюдения ([[monitoring]]) |
|- | |- | ||
!Функционал!!NGINX Open Source!!Nginx Plus | !Функционал!!NGINX Open Source!!Nginx Plus |
Текущая версия на 14:14, 12 августа 2022
NGINX (часто пишется строчными буквами, nginx; читается engine x, по-русски произносится как энджи́нкс или э́нжин-и́кс; здесь и далее -- NGINX) -- одно из двух изделий, NGINX Open Source с открытым кодом или коммерческое NGINX Plus, каждое из которых представляет собою инструмент обработки входящих запросов протоколов IP, HTTP, HTTPS, TCP, UDP. NGINX изначально разрабатывался для работы на Unix-подобных операционных системах.
Содержание
Функциональность
Согласно https://www.nginx.com/products/nginx/compare-models.
Распределение нагрузки
Функционал | NGINX Open Source | Nginx Plus |
---|---|---|
HTTP and TCP/UDP support | Yes | Yes |
Layer 7 request routing | Yes | Yes |
Session persistence | Yes | Yes |
Active health checks | No | Yes |
DNS service‑discovery integration | No | Yes |
Оперативный запас содержимого
Функционал | NGINX Open Source | Nginx Plus |
---|---|---|
Static and dynamic content caching | Yes | Yes |
Cache‑purging API | No | Yes |
Веб-сервер и обратный прокси
Функционал | NGINX Open Source | Nginx Plus |
---|---|---|
Origin server for static content | Yes | Yes |
Reverse proxy: HTTP, FastCGI, memcached, SCGI, uwsgi | Yes | Yes |
HTTP/2 gateway | Yes | Yes |
gRPC proxy | Yes | Yes |
HTTP/2 server push | Yes | Yes |
Управление безопасностью
Функционал | NGINX Open Source | Nginx Plus |
---|---|---|
HTTP Basic Authentication | Yes | Yes |
HTTP authentication subrequests | Yes | Yes |
IP address‑based access control lists | Yes | Yes |
Rate limiting | Yes | Yes |
Dual‑stack RSA/ECC SSL/TLS offload | Yes | Yes |
TLS 1.3 support | Yes | Yes |
JWT authentication | No | Yes |
OpenID Connect single sign‑on (SSO) | No | Yes |
NGINX App Protect (additional cost) | No | Yes |
Мониторинг
Функционал | NGINX Open Source | Nginx Plus |
---|---|---|
Export to external monitoring tools | Yes | Yes |
Built-in dashboard | No | Yes |
Extended status with 100+ additional metrics | No | Yes |
Высокая доступность
Функционал | NGINX Open Source | Nginx Plus |
---|---|---|
Active‑active and active‑passive modes | No | Yes |
Configuration synchronization across cluster | No | Yes |
State sharing: sticky‑learn session persistence, rate limiting, key‑value stores | No | Yes |
Расположенность к программированию
Функционал | NGINX Open Source | Nginx Plus |
---|---|---|
NGINX JavaScript module | Yes | Yes |
NGINX Plus API for dynamic reconfiguration | No | Yes |
Key‑value store | No | Yes |
Dynamic reconfiguration without process reloads | No | Yes |
Трансляция видео и аудио
Функционал | NGINX Open Source | Nginx Plus |
---|---|---|
Live streaming: RTMP, HLS, DASH | Yes | Yes |
VOD: Flash (FLV), MP4 | Yes | Yes |
Adaptive bitrate VOD: HLS, HDS | No | Yes |
MP4 bandwidth controls | No | Yes |
Экосистемы третьих сторон
Функционал | NGINX Open Source | Nginx Plus |
---|---|---|
Ingress controller | Yes | Yes |
OpenShift Router | Yes | Yes |
Dynamic modules repository | No | Yes |
Особенности
В nginx рабочие процессы обслуживают одновременно множество соединений, мультиплексируя их вызовами операционной системы select, epoll (Linux) и kqueue (FreeBSD). Рабочие процессы выполняют цикл обработки событий от дескрипторов (см. Событийно-ориентированное программирование). Полученные от клиента данные разбираются с помощью конечного автомата. Разобранный запрос последовательно обрабатывается цепочкой модулей, задаваемой конфигурацией. Ответ клиенту формируется в буферах, которые хранят данные либо в памяти, либо указывают на отрезок файла. Буфера объединяются в цепочки, определяющие последовательность, в которой данные будут переданы клиенту. Если операционная система поддерживает эффективные операции ввода-вывода, такие, как writev и sendfile, то nginx применяет их по возможности.
Алгоритм работы HTTP-сервера выглядит следующим образом:
получить очередной дескриптор из kevent(2); прочитать данные из файла и записать в socket, используя либо write(2)/read(2), например, так while (
( cnt = read ( read_file_descriptor, buffer, block_size ), write ( socket_file_descriptor, buffer, count ) == cnt )
)
byte_count += count;
либо используя системный вызов sendfile(2), выполняющий те же действия, что приведённый выше код, но в пространстве ядра; перейти к шагу 1. Конфигурация HTTP-сервера nginx разделяется на виртуальные серверы (директива «server»). Виртуальные серверы разделяются на location’ы («location»). Для виртуального сервера возможно задать адреса и порты, на которых будут приниматься соединения, а также имена, которые могут включать «*» для обозначения произвольной последовательности в первой и последней части, либо задаваться регулярным выражением.
location’ы могут задаваться точным URI, частью URI либо регулярным выражением. location’ы могут быть сконфигурированы для обслуживания запросов из статического файла, проксирования на fastcgi/memcached сервер.
Для эффективного управления памятью nginx использует пулы. Пул — это последовательность предварительно выделенных блоков динамической памяти. Длина блока варьируется от 1 до 16 килобайт. Изначально под пул выделяется только один блок. Блок разделяется на занятую область и незанятую. Выделение мелких объектов выполняется путём продвижения указателя на незанятую область с учётом выравнивания. Если незанятой области во всех блоках не хватает для выделения нового объекта, то выделяется новый блок. Если размер выделяемого объекта превышает значение константы NGX_MAX_ALLOC_FROM_POOL либо длину блока, то он полностью выделяется из кучи.
Таким образом, мелкие объекты выделяются очень быстро и имеют накладные расходы только на выравнивание.
nginx содержит модуль географической классификации клиентов по IP-адресу. В его основу входит база данных соответствия IP-адресов географическому региону, представленная в виде radix tree (сжатое префиксное дерево или сжатый лес) в оперативной памяти. nginx предварительно распределяет первые несколько уровней дерева таким образом, чтобы они занимали ровно 1 страницу памяти. Это гарантирует, что при поиске IP-адреса для первых нескольких узлов при трансляции адреса всегда найдётся запись в TLB.