Использование только Node.js против использования Node.js с Apache / Nginx

224

В каких случаях следует использовать Node.js только в качестве сервера в реальном развертывании?

Когда кто-то не хочет использовать только Node.js, что лучше работает с Node.js? Apache или Nginx?

node.js

— 7cows
источник

207

Есть несколько веских причин для размещения другого веб-сервера перед Node.js:

Не нужно беспокоиться о привилегиях / setuid для процесса Node.js. Только root может связываться с портом 80 обычно. Если вы позволите nginx / Apache начать работу с правами root, связываться с портом 80, а затем отказаться от своих привилегий root, это означает, что приложению Node не нужно об этом беспокоиться.
Обслуживание статических файлов, таких как изображения, CSS, JS и HTML. Узел может быть менее эффективным по сравнению с использованием надлежащего статического файлового веб-сервера (узел также может быть быстрее в некоторых сценариях, но это вряд ли будет нормой). Помимо файлов, обслуживающих более эффективно, вам не придется беспокоиться об обработке электронных тегов или заголовков элементов управления кэшем, как если бы вы обслуживали вещи из Node. Некоторые рамки могут справиться с этим для вас, но вы хотели бы быть уверены. Несмотря на это, все еще, вероятно, медленнее.
Как отметил Мэтт Сержант в своем ответе, вы можете легче отображать значимые страницы с ошибками или вернуться к статическому сайту, если ваша служба узла выйдет из строя. В противном случае пользователи могут просто получить тайм-аут соединения.
Запуск другого веб-сервера перед Node может помочь устранить недостатки безопасности и DoS-атаки на Node. Для реального мира , например, CVE-2013-4450 это предотвратить, запустив что - то вроде Nginx перед Node .

Я хочу напомнить второй пункт, сказав, что вы, вероятно, должны обслуживать свои статические файлы через CDN или из-за сервера кэширования, такого как Varnish. Если вы делаете это, на самом деле не имеет значения, является ли источник Node, Nginx или Apache.

Будьте осторожны с nginx: если вы используете веб-сокеты, обязательно используйте последнюю версию nginx (> = 1.3.13), так как она только добавила поддержку обновления соединения для использования веб-сокетов.

— pauljz
источник

11

express.staticбудет отлично работать с ETag и заголовками контроля кэша.

— Робертклеп

18

Узел не так хорошо, а? centminmod.com/siegebenchmarks/2013/020313/index.html , zgadzaj.com/…l

— el vis

4

pauljz, у вас есть тесты, чтобы делать резервные копии медленнее? статьи @pawlakpp указывают, что Node.js намного быстрее под нагрузкой.

— Сэмюэль Нефф

3

Здесь есть некоторые связанные обсуждения: stackoverflow.com/questions/9967887/… с некоторыми дополнительными перспективами. В тестах (поскольку вы запрашивали дополнительные тесты) показывается, что node.js / express, даже кластеризованный, заметно хуже. Мне кажется, что лучше не допускать статической обработки файлов и обработки запросов из цикла событий узла, сохранять эти циклы для работы, которая должна происходить в Node. Но, если честно, если вы подаете статические вещи из Node, у вас тоже все будет хорошо. Это не имеет большого значения.

— pauljz

4

Следует отметить, что если вы используете только узел напрямую, вы все равно можете привязать к зарезервированным портам, таким как :80без запуска узла как root, просто используя authbind: thomashunter.name/blog/using-authbind-with-node-js

— wyqydsyq

70

Просто чтобы добавить еще одну причину к ответу pauljz, я использую сервер переднего плана, чтобы он мог обслуживать 502 страницы ошибок при перезапуске внутреннего сервера или по какой-то причине зависает. Это позволяет вашим пользователям никогда не получать ошибку о невозможности установить соединение.

— Мэтт сержант
источник

28

Я считаю, что использовать Node для обслуживания статических файлов можно при любых обстоятельствах, если вы знаете, что делаете . Безусловно, это новая парадигма использования сервера приложений для обслуживания статических файлов, так как многие (каждая?) Конкурирующие технологии (PHP, Ruby, Python и т. Д.) Требуют наличия веб-сервера, такого как HTTPD или Nginx, перед серверами приложений. ,

Любая объективная причина, по которой я когда-либо сталкивался с отказом от использования статических файлов в Node, связана с идеей использования того, что вы знаете лучше всего, или использования того, что воспринимается как более проверенное / более стабильное. На самом деле это очень веские причины, но они имеют мало чисто технического значения.

Если вы не найдете функцию, которая возможна на классическом веб-сервере, которая невозможна с Node (и я сомневаюсь, что вы это сделаете), выберите то, что вы знаете лучше всего, или то, с чем вы предпочитаете работать, так как любой из этих подходов подходит.

Что касается Nginx против Apache - они будут «играть» с Node одинаково. Вы должны сравнить их безотносительно к узлу.

2

Хороший взгляд на технические сравнения в целом: «Каждая объективная причина, по которой я когда-либо сталкивался с тем, чтобы не использовать статические файлы с Node, вращается вокруг идеи использования того, что вы знаете лучше всего, или использования того, что воспринимается как более проверенное / более стабильное. практически говоря, но имеют мало чисто технического значения. " Слишком много сравнений в наши дни являются предвзятыми и основаны на богатстве опыта и уровне комфорта на низших, но проверенных временем технологиях.

— Солнечный

Да, но они действительно / субъективны / причины. Отличным примером объективной причины может служить тест - большинство из которых я обнаружил, указывают nginx> nodejs (хотя я действительно должен сделать свой собственный ....)

— Ник

@ Ник Ты абсолютно прав. И есть несколько таких, хотя я не эксперт в области научных эталонных тестов, поэтому я позволю людям искать это в Интернете. Что я скажу, хотя я думаю, что есть преимущество в простоте использования одного сервера вместо двух. Там просто меньше возможностей, чтобы что-то пошло не так. С другой стороны, Nginx , как правило , имеет пакет на каждый Unix-подобная система с хорошей конфигурацией , тогда как с узлом вы должны выяснить интеграции с systemd, pm2и т.д. Таким образом , есть свои плюсы и минусы , и пользователь должен выбрать свой яд, так сказать ,

Я подумал, что все наоборот - узел будет работать лучше под нагрузкой (возможно, не с чистой скоростью без нагрузки), потому что он не должен обрабатывать процесс, обслуживающий файл за запрос, а может выдавать данные, когда либо локальный диск, либо удаленный клиент готов в том же потоке, что и все остальные тысячи клиентов. Это, конечно, ломается, когда у вас есть несколько процессоров. Если только узел не знает, как их использовать сейчас. Или веб-серверы могут теперь использовать совместную многозадачность для управления статическими страницами ..

— Gerard ONeill

1

Дополнительно: важно также, если вам нужен обратный прокси-сервер, например, для запуска Websocket Server на том же порту, или, возможно, смешать некоторые технологии (ответьте на некоторые запросы NodeJS и некоторые другие на PHP или другие)

— Энрике
источник