Зачем использовать HTTP-сервер перед веб-сервером?

Ответ 1

• Часть любого веб-приложения полностью стандартизирована и удобна для использования. Зрелые веб-серверы, такие как nginx или apache, могут выполнять следующие действия. Они могут делать следующие вещи таким образом, что это, скорее всего, более корректно, более эффективно, стабильнее, безопаснее, более знакомо для системных администраторов и более легко настраивается, чем все, что вы могли бы переписать на своем сервере приложений.
  • Подавать статические файлы, такие как HTML, изображения, CSS, javascript, шрифты и т.д.
  • Управление виртуальным хостингом (несколько доменов на одном IP-адресе)
  • Переписывание URL-адресов
  • переписывание/перенаправление имен хостов
  • Окончание TLS (спасибо @emt14)
  • сжатие (спасибо @JacobusR)
• Отдельный веб-сервер предоставляет возможность обслуживать страницу "вниз для обслуживания", когда ваш сервер приложений перезапускается или сбой
• Обратные прокси-серверы могут обеспечить балансировку нагрузки и отказоустойчивость для вашей инфраструктуры приложений.
• Веб-серверы имеют встроенные и протестированные механизмы для привязки к привилегированным портам (ниже 1024) как root, а затем выполняются как незащищенные пользователи. Большинство рамок для веб-приложений не делают этого по умолчанию.
• Зрелые веб-серверы жесткие и стабильные. Под конюшней я имею в виду, что они буквально почти никогда не падают. Ваше веб-приложение почти наверняка намного менее стабильно. Это дает вам возможность, по крайней мере, обслуживать страницу с хорошей ошибкой пользователю, говорящему, что ваше приложение отключено, а не веб-браузер, просто отображая общую ошибку "не удалось подключиться".
  • Анекдотический случай: nginx обрабатывает атаку, которая в противном случае DoS node.js: http://blog.nodejs.org/2013/10/22/cve-2013-4450-http-server-pipeline-flood-dos/

И на всякий случай, если вам понадобится полуофициальный ответ Айзека Шлютера на техническом обсуждении Airbnb 30 января 2013 года около 40 минут, в нем рассматривается вопрос о является ли node стабильным и безопасным, чтобы обслуживать соединения непосредственно в Интернете. Его ответ по существу "да", это прекрасно. Таким образом, вы можете это сделать, и вы, вероятно, будете в порядке с точки зрения стабильности и безопасности (при условии, что вы используете кластер для обработки неожиданного завершения процесса сервера приложений), но, как указано выше, реальность текущих операций заключается в том, что все еще почти все работают node за отдельным веб-сервером или обратным прокси-кешем.

Ответ 2

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

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

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

Ответ 3

Я бы добавил:

• Обработка ssl
• для некоторых серверов, таких как apache множество модулей (т. аутентификация ntml/kerberos)
• Веб-серверы намного лучше для некоторых вещей по сравнению с вашим приложением, например, службой static.

Ответ 4

С прокси-сервером HTTP фреймворк не должен поддерживать открытое http-соединение для предоставления вычисленного контента и затем может начать обслуживать другой запрос. Он действует как буфер.

Ответ 5

Это проблема изобретательства колеса. Большинство фреймворков предоставят вам среду разработки, но для производства обычно является хорошей практикой использовать коммерческий проект с открытым исходным кодом, который способен решать все проблемы, возникающие во время производства.

Ребята, создающие Framework, будут иметь структуру, на которой нужно сосредоточиться, в то время как ребята, строящие сервер, делают то же самое (совершенствование).