Веб сервер Nginx, обзор функциональных возможностей

Nginx - небольшой по размерам, очень быстрый, достаточно функциональный веб сервер и почтовый прокси-сервер, разработчик ]]>Игорь Сысоев]]> ( rambler.ru ). Из-за очень маленького потребления ресурсов системы и скорости работы, а так-же гибкости конфигурирования, веб сервер Nginx часто используется в качестве фронтэнда к более тяжеловесным серверам, такими как Apache, в проектах с высокой нагрузкой. Классическим вариантом является связка, Nginx - Apache - FastCGI. Работая в такой схеме, сервер Nginx, принимает все запросы приходящие по HTTP, и в зависимости от конфигурации и собственно самого запроса, решает, обработать-ли запрос самому и отдать клиенту готовый ответ или отправить запрос на обработку, одному из бакэндов ( Apache или FastCGI ).

Как известно, сервер Apache, каждый запрос обрабатывает в отдельном процессе ( потоке ), которые надо сказать, отжирают довольно НЕмаленькое количество системных ресурсов, если таких процессов 10-20, ерунда, а если их 100-500 и больше, системе становится не весело.

Попробуем представить подобную ситуацию. Предположим, на Apache приходит 300 HTTP запросов от клиентов, 150 клиентов сидят на быстрых выделенных линиях, а другие 150, на сравнительно медленных интернет каналах, пусть даже не на модемах. Что происходит в данной ситуации? А происходит следующее, веб сервер Apache, что-бы обработать эти 300 соединений, создает на каждое по процессу ( потоку ), контент он сгенерит быстро, и 150 быстрых клиентов тут-же заберут результат своих запросов, процессы их обслуживавшие будут убиты а ресурсы высвобождены, а 150 медленных, и забирать результаты своих запросов будут медленно, в силу неширокого интернет канала, в результате чего в системе будет висеть 150 процессов Apache, ожидающих, когда-же клиенты заберут сгенерированный веб сервером контент, пожирая массу системных ресурсов. Естественно ситуация гипотетическая, но суть думаю понятна. Исправить вышеописанную ситуацию и помогает связка Nginx + Apache + FastCGI. Прочитав весь запрос от клиента, он передает его на обработку Apache, который в свою очередь генерирует контент и максимально быстро возвращает готовый ответ в Nginx, после чего может со спокойной совестью прибить процесс и освободить занимаемые им системные ресурсы. веб сервер Nginx, получив результат запроса от Apache, записывает его в буфер или вообще в файл на диске и может сколь угодно долго отдавать его медленным клиентам, при этом его рабочие процессы едят так мало ресурсов что.. "об этом даже смешно говорить" ©. :) Такая схема, существенно экономит системные ресурсы, повторюсь, но рабочие процессы Nginx потребляют мизерное количество ресурсов, это тем-более актуально для больших проектов.

И это только малая часть того, что умеет сервер Nginx, не стоит забывать про возможности кэширования данных и работу с memcached. Приведу список основных функциональных возможностей веб сервера Nginx.

Функционал сервера Nginx в качестве HTTP сервера

• Обработка статического контента, индексные файлы, листинг директорий, кэш дескрипторов открытых файлов;
• Акселерированное проксирование с кэширование, распределение нагрузки и отказоустойчивостью;
• Акселерированная поддержка FastCGI серверов с кэшированием, распределением нагрузки и отказоустойчивостью;
• Модульная структура, поддержка различных фильтров ( SSI, XSLT, GZIP, докачка, chunked ответы );
• Поддержка SSL и расширения TLS SNI;
• Ip-based или Name-based виртуальные сервера;
• Работа с KeepAlive и pipelined соединениями;
• Возможность конфигурирования любых таймаутов а так-же количества и размеров буферов, на уровне сервера Apache;
• Выполнение различных действий в зависимости от адреса клиента;
• Изменение URI с помощью регулярных выражений;
• Специальные страницы ошибок для 4хх и 5хх;
• Ограничение доступа на основе адреса клиента или по паролю;
• Настройка форматов лог-файлов, ротация логов;
• Ограничение скорости ответа клиенту;
• Ограничение количества одновременных подключений и запросов;
• Поддержка методов PUT, DELETE, MKCOL, COPY и MOVE;
• Изменение настроек и обновление сервера без остановки работы;
• Встроенный Perl;

Функционал сервера Nginx, в качестве почтового прокси-сервера

• Форвардинг на IMAP/POP3 бакэнд, используя внешний HTTP сервер аутентификации;
• Проверка SMTP пользователя на внешнем HTTP сервере аутентификации и форвардинг на внутренний SMTP сервер;
• Поддержка следующих способов аутентификации:
  • POP3 - USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
  • IMAP - LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
  • SMTP - AUTH LOGI/ PLAIN/CRAM-MD5;
• Поддержка SSL;
• поддержка STARTTLS и STLS;

Операционные системы и платформы, поддерживаемые веб сервером Nginx

• FreeBSD, с 3 по 8 - платформы, i386 и amd64;
• Linux, с 2.2 по 2.6 - платформа i386; Linux 2.6 - amd64;
• Solaris 9 - платформы i386 и sun4u; Solaris 10 - платформы i386, amd64 и sun4v;
• MacOS X платформы ppc, i386;
• Windows XP, Windows Server 2003; ( на данный момент в стадии бета-тестирования )

Архитектура и масштабируемость сервера Nginx

• Основной ( master ) процесс, несколько ( настраивается в файле конфигурации ) рабочих процессов, работающих под непривилегированным пользователем;
• Поддержка следующих методов обработки соединений:
  • select - стандартный метод. Соответствующий модуль Nginx собирается автоматически, если на данной платформе не найдено более эффективного метода. Можно принудительно включить или отключить сборку данного модуля с помощью параметров конфигурации --with-select_module или --without-select_module.
  • poll - стандартный метод. Соответствующий модуль Nginx собирается автоматически, если на данной платформе не найдено более эффективного метода. Можно принудительно включить или отключить сборку данного модуля с помощью параметров конфигурации --with-poll_module или --without-poll_module.
  • kqueue - эффективный метод, используемый в операционных системах FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 и MacOS X. При использовании на двухпроцессорных машинах с MacOS X может вызвать kernel panic.
  • epoll - эффективный метод, используемый в Linux 2.6+. В некоторых дистрибутивах, например SuSE 8.2, есть патчи для поддержки epoll ядром 2.4.
  • rtsig - real time signals, эффективный метод, используемый в Linux 2.2.19+. По-умолчанию в очереди для всей системы, не может находиться более 1024 сигналов. Этого мало для серверов с высокой нагрузкой, размер очереди нужно увеличить с помощью параметра ядра /proc/sys/kernel/rtsig-max. Однако, начиная с Linux 2.6.6-mm2, этот параметр отсутствует, вместо этого у каждого процесса существует отдельная очередь сигналов, размер которой определяется с помощью RLIMIT_SIGPENDING.
  • При переполнении очереди, сервер nginx сбрасывает её и обрабатывает соединения с помощью метода poll до тех пор, пока ситуация не придет в норму.
  • /dev/poll - эффективный метод, поддерживается в операционных системах Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ и Tru64 UNIX 5.1A+.
  • eventport - event ports, эффективный метод, используемый в Solaris 10. Перед использованием, необходимо установить патч, во избежания kernel panic.
• Использование возможностей метода kqueue, таких как EV_CLEAR, EV_DISABLE (для временного выключения события), NOTE_LOWAT, EV_EOF, число доступных данных, коды ошибок;
• Работа с sendfile (FreeBSD 3.1+, Linux 2.2.+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+) и sendfilev (Solaris 8 7/01+);
• Поддержка accept-фильтров (FreeBSD 4.1+) и TCP_DEFER_ACCEPT (Linux 2.4+);
• На 10 000 неактивных HTTP keep-alive соединений тратится примерно 2.5M памяти;
• Минимальное количество операций копирования данных;