Является ли cgi мертвым?
Хорошо, пусть это будет мягче: есть ли cgi (общий интерфейс шлюза)?
да? нет?
В каких обстоятельствах проект, начинающийся сегодня (тот, который не требует взаимодействия с устаревшими системами или библиотеками), использует cgi?
Ответы
Ответ 1
Это далеко не мертвый. Несмотря на накладные расходы, многие виртуальные хостинговые компании теперь используют PHP как CGI для соображений безопасности, потому что его можно использовать с suEXEC. suEXEC означает, что ваши скрипты выполняются под вашими действительными привилегиями пользователя Unix и, таким образом, ограничены разделением привилегий операционной системы. Это гораздо более надежная модель безопасности, чем альтернатива open_basedir для PHP.
Кроме того, CGI - очень простой и довольно универсальный интерфейс, поддержка которого никогда не выходит из веб-серверов. Многие новые интерфейсы, такие как FastCGI и SCGI, наследуют то, как CGI передает HTTP-заголовки и другие переменные в веб-приложение и обратно. Даже PHP SAPI имитирует эту переменную $_SERVER
. Так что CGI не уходит, он просто строится.
Ответ 2
Наследство? Абсолютно. Мертв? Ну, это на жизненной поддержке. Я сомневаюсь, что он действительно "умрет" в обозримом будущем. Вы все еще можете использовать CGI для написания очень маленького типа script, если у вас есть сервер без каких-либо других средств для запуска webapp, и вы слишком ленивы, чтобы его настроить.
Какая еще причина? Возможно, у вас есть программа, которая утечки памяти или ресурсов, таких как сито, но вам все равно нужно запустить его, поэтому вы убедитесь, что все очищено, завершая процесс каждый отдельный запрос...
Но если серьезно, для вещей, которые действительно имеют значение, я думаю, что преимущества перехода к какой-либо системе с постоянными процессами значительно перевешивают затраты. И, по моему опыту, он поощряет также писать хорошо организованный код, потому что тип инициализации, который вам нужен, чтобы иметь хорошо модульное приложение, переводится как "неприемлемое время запуска" в среде CGI.
Ответ 3
Как насчет того, который требует экстремальной вычислительной производительности?
Ответ 4
Это не совсем мертво. Но fcgi выглядит намного лучше. Хотя официально не поддерживается, скажем, Apache. Вам нужно использовать боковые моды, чтобы заставить его работать.
Ответ 5
Я бы тоже не подумал о CGI. В конце концов, он поддерживается всеми основными веб-серверами.
Одна из причин, не упомянутых для начала проекта CGI, может быть защитой интеллектуальной собственности. Например, вы можете решить написать CGI-программу на С++ и разрешить клиенту устанавливать приложение на сервере, который не контролируется вами.
Возможно, у вашего старого продукта есть тонны бизнеса, реализованные как библиотеки. (.dll,.so..lib..a и т.д.). В этом случае на самом деле может быть быстрее выйти на рынок с помощью c/С++ при реализации веб-интерфейса.
Возможно, вы работаете в магазине Delphi? Если 10 из 10 инженеров в вашем магазине пишут Delphi, писать новое приложение на PHP не может быть вашим самым быстрым путем выхода на рынок.
Итак, короче говоря, многие переменные вступают в игру при принятии решения о том, какие технологии использовать для вас новый продукт, включая:
- Кто ваш клиент?
- Какова ваша начальная точка?
- Каковы ваши активы и ресурсы?
- Что вам больше всего нравится?
- С чем нужно работать с вашим программным обеспечением?
- Как будет развернуто приложение?
Ответ 6
CGI не очень хорошо подходит для высокой производительности.
Но мой совет - игнорировать это, писать для языка или библиотеки, которая поддерживает несколько SAPI, а затем использовать то, что подходит для каждой ситуации.