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

Ответ 1

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

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

Я верю в факты и тесты По словам pauljz, nginx лучше обслуживает статические файлы, я боюсь, что его, конечно, не совсем верно, его полностью противоположно тому, что он сказал, пожалуйста, проверьте ссылку bechmarks. Как node js масштабируется в 2 раза лучше, чем nginx (4 250 транс/с против 2,118 транс/с) - особенно на более высоких уровнях concurrency. Также проверьте среднее время отклика (0,14 с против 0,23), длительное время транзакции (1.10s против 13.95s) и количество доступных транзакций в node.js. Для получения дополнительной информации перейдите по ссылке http://centminmod.com/siegebenchmarks/2013/020313/

Ответ 5

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