(с) Игорь Сысоев, создатель nginx.

Я постараюсь в кратце рассказать о том, как я сам использую этот сервер. В моём описании будут только краткие примеры и небольшие советы по части HTTP-сервера. За более подробной информацией и по поводу особенностией почтового прокси-сервера лучше обратиться на сайт разработчика и постовляемую с nginx документацию.

nginx vs apache vs lighthttpd vs ещё какой-нибудь http-сервер.

Часто попадаются восторженные отзывы программеров/начинающих админов о том, что nginx быстрее, выше, сильнее чем %servername%. Сразу же скажу, что здесь таких сравнений вы не найдёте. Я не буду сравнивать красное с тёплым. Более-менее плотно мне приходилось работать с apache и nginx, так вот это два разных по задачам сервера. И если кому-то удалось у себя на локалхосте запустить nginx, который, например, оказался быстрее, чем апач - это говорит лишь о том, что на данном конкретном локалхосте для данной конкретной задачи и при данном положении луны в созвездии козерога оно быстрее. К реальности такие тесты отношения не имеют: apache и nginx - разные продукты, предназанченные для разных вещей.

Немного теории.

nginx очень хорошо справляется с отдачей статики(изображения, статический html, таблицы стилей и т.п.). Если точнее, сам по себе nginx в принципе не умеет обрабатывать динамический контент - он может либо проксировать запросы кому-нибудь другому(web-серверу, который умеет; FastCGI-серверу). Т.е. можно "подключить к nginx php". Но для этого надо будет запустить php, как fastcgi и проксировать все запросы. Казалось бы, ничего плохого, но на деле при большой нагрузке те ресурсы, что вы таким образом сэкономите на отказе от апача, вы потеряете на этом самом fastcgi. Да ещё и работает оно не очень стабильно. Поэтому обычно используют решение FrontEnd-сервер + BackEnd-сервер. Я использую связку nginx+apache2, но никто не мешает вам проксировать запросы на любой дургой web-сервер - nginx'у совершенно всё-равно, что стоит за ним - главное, чтобы оно отдавало http. Суть разделения такова - каждый сервер занимается своим делом - один генерирует контент, другой отдаёт его конечному пользователю. Причём, чем особенно хорош nginx, он может ещё и определять по запросам пользователя, какие из них нужно проксировать для генерации ответа, а на какие можно ответить уже сейчас, вытащив из кеша или взяв из настроек нужный контент. А если учесть, что nginx'у можно задавать пути с использованием regexp'ов, то даже представить сложно, насколько гибко можно управлять отдачей содержимого сайта.

И немного практики.

Пример первый: FrontEnd + BackEnd.

Ставим апач, как обычно. Полностью все настройки на ваше усмотрение. Все модули, все особенности - всё делаете так, как привыкли. Только вот слушать апачу нужно будет не 80-ый порт, а любой незанятый. Ну и в целях безопасности не помешает перевести его на 127.0.0.1, чтобы наружу вообще не выглядывал. BackEnd готов.
Устанавливаем nginx и в создаём там виртульный сервер. Примерно так:

1 2 3 4 5 6 7 8 9 10 11 12

server {   listen 80;   server_name     sitename.com     www.sitename.com;   location / {     proxy_pass  http://127.0.0.1:8080/;     proxy_redirect      off;   } }

Собственно, этого уже достаточно. Теперь все запросы к nginx будут уходить на апач и там обрабатываться, а отдавать результаты пользователю будет nginx. При этом он уже будет запоминать статику и работать быстрее. Механизм работы таков: запрос, приходящий от пользователя(он идёт через интернеты, поэтому может двигаться долго и нудно), мгновенно передаётся апачу, обрабатывается и мгновенно отдаётся назад nginx'у уже в статическом виде. Ну и nginx, в свою очередь всё это скармливает пользователю. Скорость достигается за счёт того, что апач при обработке и генерации страницы создаёт отдельный процесс. И пока он страницу полностью не отдаст, процесс этот висит в памяти. А nginx эту страницу забирает мгновенно. И дальше уже не важно, как долго пользователь будет её забирать. Плюс к этому на крупных ресурсах запросы пользователей нередко дублируются. И тут тоже видим заметный профит - nginx отдаёт то, что уже сгенерировано даже не дёргая апач.
Едем дальше. У нас на сайте много картинок. Почему бы нам не снять нагрузку по отдаче картинок с апача вообще и переложить её полностью на nginx? Да без проблем. Предположим, все картинки находятся у нас в отдельной директории и доступны по адресы http://sitename.com/images/<имя картинки>
Добавляем в описание виртсервера такие строки:

1 2 3 4 5

location /media {     root /path/to/dir/with/images/;   }

Готово. Теперь nginx сам знает где искать изображения по запросам пользователей и отдаёт их сразу же после запроса.
Как я уже писал, помимо прочего nginx умеет regexp'ы. Например, мы решили разделить нагрузку и всякие media-файлы у нас на одном сервере(с быстрым и сильным каналом), а сам движок на другом, где скорсоти поменьше. Отлично, добавляем:

1 2 3 4 5

location /media/ {     rewrite ^(/media/.*)$ http://mediaserver.com$1;   }

Теперь все запросы идущие на наш сервер типа http://sitename/media/<файл> будут автоматически переписываться на http://mediaserver.com/media/<файл>. Таким образом конечный пользователь будет получать http-страницы и прочее с одного сервера, а картинки, видео и тому подобное с другого.
Ещё по поводу регекспов. Никто не мешает нам использовать их не только в описаниях rewrite, но и в location. Например:

1 2 3 4 5

location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|js|swf)$ {     root /path/to/media/files;   }

В этом примере мы любые запросы к любым изображениям, расположенным по любым путям нашего сайта, отдали в распоряжение nginx.
Ну и так далее. Возможностей куча. Плюс к этому, nginx довольно нехило конфигурится и можно без проблем управлять различными параметрами типа максимально возможного размера загружаемых файлов, ограничения таймаутов, access-листы по ip и т.д. и т.п. Это уже добро пожаловать в маны. Ну и очень хорошие описания директив nginx на сайте автора: http://sysoev.ru/nginx

Пример второй: Шлюзовый сервер.

Имеем сеть - один шлюзовый сервер, единственный из всей сети имеющий доступ в интернет и множество машин в локалке за ним, причём некоторые из них ещё и серверы. Или, другой вариант - разработчик web-проектов использует виртмашины(openvz) для отдельных web-серверов - в каждом контейнере отдельный web-сервер, доступ к которому имеет отдельный программист и делает там всё, что ему угодно. Удобно, когда ошибка одного программера, завесившая апач не мешает другим. Так вот надо всё это выпустить в инет. Чтобы любой человек мог попасть на любой из разрабатываемых сайтов и посмотреть, что там и как. А дать реальный ip каждому контейнеру и каждому компу в локалке возможности нет. Вот тут-то снова приходит на помощь nginx.
В принципе, всё так же, как и в предыдущем примере, только proxy_pass будет не на локалхост, а на серый ip конкретного сервера. Вроде бы ничего особенного. Но вы только представьте, как гибко и легко можно рулить любыми сайтам всей сети, выпуская/закрывая/добавляя/удаляя их. Несколько строк в конфиге nginx, добавляющие виртуальный хост и новый сайт доступен миру. Никаких заморочек с форвардами,пробросами портов, Border Gateway Protocol'ами и прочим.
Или другой вариант по похожей схеме. У вас большой и страшный проект, каждая секунда простоя которого стоит миллионы денег. И железо начинает подавать признаки умирания. Да, конечно, есть backup-сервер, точно копирующий действующий проект, но вот проблема - переключения и т.п. - перебой в работе. А если у нас есть такой вот шлюзовой nginx, мы просто меняем в нём ip директивы proxy_pass и рестартим nginx - проект переключен на другой физический сервер, пользователи даже не заметили.

Я уверен, что это далеко не все возможности http-сервера nginx. Мой пост - что-то типа ознакомительной статьи для тех, кто слышал, но не вкурсе, что же оно такое на самом деле.