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