Альтернатива cgi-bin

Question

В этом вопросе задается вопрос о недостатках услуг, основанных на cgi-bin.Насколько я могу убедиться, кроме, возможно, соглашения об именах, ничего особенного не изменилось за эти годы, когда речь идет о веб-клиент-серверном взаимодействии.Конечно, теперь есть возможность использовать AJAX-клиенты, но в конечном итоге они по-прежнему не сохраняют состояния и кодируют на сервере, на каком бы языке он ни был написан, все еще ожидает отправки ввода с помощью методов «GET» или «POST».

После того, как веб-программирование уже давно не в курсе, я что-то упускаю из виду?

Чтобы прояснить мой вопрос: вопрос, на который я ссылался, предполагает, что 'cgiСистемы, основанные на bin, больше не используются. Какая новая альтернатива?

@ sarnold.Спасибо за ваш ответ.Точно так же я на 100% уверен в этом, даже если система разрабатывается с использованием «новейшей и самой лучшей» серверной платформы (я думаю, это будет система на основе .net или эквивалент Linux), она все равно, в конечном счете, всего лишь программа,или программы, работающие (если используются быстрые cgi) или ожидающие запуска на сервере, так что действительно никаких изменений за эти годы не произошло.Если это так, на какую альтернативу Брайан ссылается в своем вопросе?

Answer 1

Наибольшие изменения были внесены в такие инструменты, как mod_php , которые исполняют код непосредственно в адресном пространстве веб-сервера, и FastCGI , которые реализуют нечто, почти идентичное протоколу CGI, но с несколькими долгоживущими процессами, а не с fork(2) + execve(2) новым интерпретатором для каждого отдельного запроса.

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

Подход FastCGI почти сохраняет ту же скорость; он жертвует некоторой скоростью для копирования данных между процессами, но это не такая уж большая проблема для всех, кроме огромных сайтов с объемом. Но вы можете запустить несколько систем FastCGI как разные учетные записи пользователей, подключенные к разным местоположениям единого «веб-сервера» (например, http://example.com/public/ работает под учетной записью www-public и http://example.com/private/ работает под учетной записью www-private), а FastCGI системы не должны работать с теми же привилегиями, что и веб-сервер.

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