Я хотел бы знать разницу между Nginx и Unicorn. Насколько я понимаю, Nginx — это веб-сервер, а Unicorn — HTTP-сервер Ruby.
Поскольку и Nginx, и Unicorn могут обрабатывать HTTP-запросы, зачем использовать комбинацию Nginx и Unicorn для приложений RoR?
Nginx 
Единорог 
См. unicorn на github для получения дополнительной информации.
Nginx — это чистый веб-сервер, предназначенный для обслуживания статического контента и/или перенаправления запроса в другой сокет для обработки запроса.
Unicorn — это стоечный веб-сервер, предназначенный только для размещения «стоечного приложения», которое обычно генерирует динамический контент. Стоечные приложения также могут обслуживать статический контент, но они менее эффективны, чем большинство других традиционных веб-серверов.
В большинстве установок RoR используется комбинация как традиционных веб-серверов, так и стоечных серверов, чтобы максимально использовать их возможности. Nginx невероятно быстро перенаправляет запросы за счет балансировки прокси и обслуживания статического контента. Unicorn вполне способен обрабатывать заголовки HTTP и балансировать входящие запросы к Ruby для обработки.
Этот ответ дополняет другие и объясняет, почему Unicorn нужен nginx перед ним.
TL;DR Причина, по которой Unicorn обычно развертывается вместе с обратным прокси-сервером, таким как nginx, заключается в том, что его создатели намеренно разработали его таким образом, пожертвовав простотой.
Прежде всего, ничто не мешает вам развернуть Unicorn без обратного прокси-сервера. Однако это было бы не очень хорошей идеей; давайте посмотрим, почему.
Unicorn следует философии Unix, которая заключается в том, чтобы делать что-то одно и делать это хорошо, а именно обслуживать быстрых клиентов с малой задержкой (позже мы увидим, что это означает). на). Тот факт, что Unicorn предназначен для быстрых клиентов с малой задержкой, также означает, что он не очень хорош с медленными клиентами с высокой задержкой, что действительно верно. Это одно из слабых мест Unicorn, и именно здесь в игру вступает обратный прокси-сервер: он сидит перед Unicorn и заботится об этих медленных клиентах (посмотрим, как позже).
К счастью, такой обратный прокси-сервер уже существует и называется nginx.
Решение работать только с быстрыми клиентами значительно упрощает дизайн Unicorn и позволяет использовать гораздо более простую и меньшую кодовую базу за счет некоторой дополнительной сложности в отделе развертывания (т. е. вам также необходимо развернуть nginx в дополнение к Unicorn).
Альтернативным решением может быть проектирование Unicorn таким образом, чтобы ему не требовался обратный прокси. Однако это означает, что ему придется реализовать дополнительные функции, чтобы делать все то, что сейчас делает nginx, что приводит к более сложной кодовой базе и большим инженерным усилиям.
Вместо этого его создатели приняли решение использовать существующее программное обеспечение, которое проверено в боевых условиях и очень хорошо спроектировано, и не тратить время и энергию на проблемы, уже решенные другим программным обеспечением.
Но давайте перейдем к техническим аспектам и ответим на ваш вопрос:
Почему Unicorn нужно разворачивать вместе с nginx?
Вот некоторые из основных причин:
Использование обратного прокси-сервера означает, что Unicorn не необходимо использовать неблокирующий ввод-вывод. Вместо этого он может использовать блокирующий ввод-вывод, который по своей сути проще и легче для программиста.
Кроме того, как указано в документе DESIGN:
[Использование блокирующего ввода-вывода] позволяет использовать более простой путь кода в интерпретаторе Ruby и меньше системных вызовов.
Однако это также имеет некоторые последствия:
(Для простоты мы предполагаем установку с 1 рабочим Unicorn)
Поскольку используется блокирующий ввод-вывод, воркер Unicorn может обслуживать только одного клиента за раз, поэтому медленный клиент (то есть клиент с медленным соединением) эффективно заставит воркер быть занятым в течение более длительного времени. (чем быстрый клиент). Тем временем другие клиенты будут просто ждать, пока работник снова освободится (т.е. запросы будут накапливаться в очереди).
Чтобы обойти эту проблему, перед Unicorn развертывается обратный прокси-сервер, который полностью буферизует входящие запросы и ответы приложения, а затем отправляет каждый из них в один раз (то есть кормит их с ложечки) Unicorn и клиентам соответственно. В связи с этим можно сказать, что обратный прокси-сервер «защищает» Unicorn от медленных сетевых клиентов.
К счастью, Nginx — отличный кандидат на эту роль, поскольку он предназначен для эффективной обработки тысяч сотен одновременных клиентов.
Крайне важно, чтобы обратный прокси-сервер находился в той же локальной сети, что и Unicorn (обычно на той же физической машине, которая взаимодействует с Unicorn через сокет домена Unix), чтобы свести задержку в сети к минимуму.
Таким образом, такой прокси-сервер эффективно играет роль быстрого клиента , для обслуживания которого в первую очередь предназначен Unicorn, поскольку он быстро проксирует запросы к Unicorn и сохраняет рабочие процессы быстрыми. em>за максимально короткое время (по сравнению с тем, сколько времени потребовался бы клиент с медленным соединением).
Поскольку Unicorn использует блокирующий ввод-вывод, это также означает, что он не может поддерживать функцию проверки активности HTTP/1.1, поскольку постоянные соединения медленных клиентов быстро займут все доступные рабочие процессы Unicorn.
Поэтому, чтобы использовать поддержку активности HTTP, угадайте, что: используется обратный прокси-сервер.
nginx, с другой стороны, может обрабатывать тысячи одновременных подключений, используя всего несколько потоков. Следовательно, у него нет ограничений на параллелизм, таких как сервер Unicorn (который по существу ограничен количеством рабочих процессов), что означает, что он может прекрасно обрабатывать постоянные соединения. Подробнее о том, как это работает, можно узнать здесь.
Вот почему nginx принимает поддерживающие соединения от клиентов и проксирует их в Unicorn по обычным соединениям, как правило, через сокет Unix.
Опять же, обслуживание статических файлов — это то, что Unicorn может делать, но не предназначено для эффективной работы.
С другой стороны, обратные прокси, такие как nginx, гораздо лучше справляются с этим (например, sendfile(2) и кэширование).
Есть и другие моменты, изложенные в документе ФИЛОСОФИЯ (см. "Улучшение производительности за счет обратного Прокси").
См. также некоторые из основных функций nginx.
Мы видим, что, используя существующее программное обеспечение (например, nginx) и следуя философии Unix «делать что-то одно и делать это хорошо», Unicorn может следовать более простому дизайну и реализации, сохраняя при этом эффективность обслуживания Rack-приложений (например, ваше приложение Rails).
Для получения дополнительной информации обратитесь к философии и design, которые более подробно объясняют варианты дизайна Unicorn и почему nginx считается хорошим обратным прокси-сервером для Unicorn.
Nginx можно использовать для обслуживания медленных клиентов на сервере единорога, поскольку медленные клиенты могут задушить сервер единорога. Nginx используется как своего рода прокси-сервер, буферизующий все запросы и ответы медленным клиентам.
См. http://unicorn.bogomips.org/.
