Используйте приложение ExpressJS через FastCGI

Question

Только что начал разбираться с веб-приложениями NodeJS и возник фундаментальный вопрос.

Поскольку я пришел из области PHP, я знаю, что в PHP есть встроенный HTTP-сервер, но никто на самом деле его не использует, и мы использовали nginx и в доисторических проектах Apache в качестве HTTP-сервера, когда я вошел в ExpressJS, я обнаружил, что все примеры говорят о прослушивание HTTP-сервера, который открывается ExpressJS (конечно, через модуль http NodeJS), но никто не говорит об использовании его через FastCGI (nginx -> FastCGI (например, node-fastcgi) -> мое приложение ExpressJS), как я раньше делал с PHP (nginx -> PHP-fpm -> мой PHP env) и мне интересно, почему?

Насколько я понял, приложение NodeJS очень быстрое, неблокирующее ввод-вывод и т. Д., Но приложение, как все показывают, имеет брешь в безопасности, поскольку у запущенной службы одни и те же общие ресурсы в среде JavaScript, один пользователь например, может по ошибке (или нет) делиться конфиденциальной информацией с другими. давайте предположим, что разработчик допустил такую ​​ошибку:

router.post('/set-user-cc', function(res){
    global.user = new User({
        creditCard: req.param('cc')
    });
});

А другой пользователь делает запрос так:

router.get('/get-user-cc', funciton(req, res){
    res.json(global.user);
});

В этот момент каждый пользователь получит информацию о CC пользователя.

Использование моего приложения ExpressJS через FastCGI откроет чистую среду JavaScript для каждого HTTP-запроса, и пользователи не будут вредить друг другу.

Было бы приятно услышать от опытных разработчиков NodeJS (веб) приложений, почему никто не предлагает использовать решение FastCGI (искал в Google и почти ничего не нашел), и если так, то почему это так плохо?

(ps пример - просто показать проблему, это не то, что кто-то на самом деле сделал, а, как мы знаем, во вселенной существует много глупых людей:)

Спасибо!

Answer 1

Вы не будете совершать подобные ошибки, если будете использовать свой код, работать в строгом режиме и не использовать такие глобальные переменные.

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

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

Если вы сделаете все это, а также проведете строгий процесс проверки кода, вам не придется об этом беспокоиться.

В основном с помощью fastCGI, хотя он имеет fast в его названии, сравнивая его с использованием http-сервера узла, это будет очень медленно.

В рамках решения fastCGI количество одновременных соединений, которые мы можем обработать, равно числу процессов nodejs. Из документов nodejs:

Предположим, по крайней мере, 30 мс запуска и 10 Мб памяти для каждого нового узла. То есть вы не можете создать много тысяч из них.

Таким образом, имея 1 ГБ ОЗУ, вы можете иметь только менее 100 соединений.

На узле обычным способом http-сервера у вас не будет этой проблемы, каждое соединение будет занимать менее 1 МБ.

Также я бы сказал, что дополнительная сложность асинхронного программирования в node.js только с одним соединением на процесс может не стоить этого, потому что

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

Единственное преимущество узла с fastCGI, это то, что он в javascript. Если вы знаете только javascript или любите его и хотите интегрировать его с существующим сервером fastCGI, то nodejs может быть жизнеспособным решением, в противном случае я не советую делать это.

И вы ошибаетесь по этому поводу:

Использование моего приложения ExpressJS через FastCGI откроет чистую среду JavaScript для каждого HTTP-запроса, и пользователи не будут вредить друг другу.

Как сказал vkurchatkin, как только процесс vkurchatkin с запросом, он получит следующий запрос для обработки. Эта ошибка может произойти с методом FastCGI. Я немного читал, и весь смысл FastCGI в том, что он быстр, в том, что он повторно использует процессы, а не создает их для каждого запроса.