NGINX

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 как распределитель нагрузки (load balancer)

Функционал	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 как oперативный запасник содержимого (content cache)

Функционал	NGINX Open Source	Nginx Plus
Static and dynamic content caching	Yes	Yes
Cache‑purging API	No	Yes

Веб-сервер и обратный прокси

NGINX как веб-сервер (web server) и обратный прокси (reverse proxy)

Функционал	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 как проверяющий безопасность (security controls)

Функционал	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 как наблюдающий (monitoring)

Функционал	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 как инструмент высокой доступности (high availability или HA)

Функционал	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 к программированию (programmability)

Функционал	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 как инструмент трансляции видео и аудио (streaming media)

Функционал	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 в экосистемах третьих сторон (third-party ecosystem)

Функционал	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.