Verification: a143cc29221c9be0

Php cgi что это такое

Php cgi что это такое

История языка

Изначально PHP расшифровывался как Personal Home Page Tools — инструменты для создания персональных страниц. Дело в том, что раньше, чтобы сделать функциональный сайт, чаще всего использовали C, Perl и CGI-скрипты. Звучит сложно, на деле — тоже сложно. Единственным способом сделать что-то своё и не изучать при этом три тома по программированию был PHP.

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

Например, можно сделать так:

Привет! А вы знаете, что

 

В результате на странице получится строчка: «Привет! А вы знаете, что этот код написан на PHP?»

Ещё можно создавать целые PHP-файлы и писать весь код там, а потом просто подключать эти файлы в нужный момент. Получается, что с PHP можно работать в двух режимах: писать код прямо в коде страницы или выносить всё в отдельные файлы.

PHP — это просто

Именно простота этого языка принесла ему дурную славу: слишком много появилось плохого кода, который на первый взгляд работал хорошо. Посмотрите сами: начать писать на PHP действительно просто.

Комментарии и точка с запятой. Комментарии можно ставить в любом месте — достаточно написать два слеша подряд. А точка с запятой ставится после каждой команды — точно так же, как в С, Pascal, JavaScript и ещё в сотнях других языков.

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

$x = 5; $y = $x+2;

Вывод на экран. В HTML-коде достаточно вставить команду echo, которая помещает текст в то место, откуда вызвали команду. Например, этот код покажет заголовок первого уровня с текстом «Заголовок, собранный на PHP»:

$h1_text = "Заголовок, собранный на PHP"; ?>

echo $h1_text; ?>

И этот код сделает то же самое:

echo "

";

$h1_text = "Заголовок, собранный на PHP"; echo $h1_text; echo ""; ?>

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

Для чего нужен PHP

Собирать страницы из модулей. Если помните, PHP-код можно встраивать в HTML-страницы, а можно сохранять как отдельные файлы. В этом случае мы получаем мини-модули, каждый из которых отвечает за что-то одно. Например, в одном мы пишем, как будет выглядеть шапка сайта, в другом — меню, третий файл будет отвечать за подвал, четвёртый — за блок с отзывами о товарах.

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


header.php"); ?>
Тут можно вставить ссылку на модуль карточки товара
или заполнить раздел информацией вручную.
Но лучше модулем, как выше и ниже.
include("/includes/footer.php"); ?>

PHP возьмёт файл header.php, в котором мы написали, как должна выглядеть шапка сайта, и поставит её в начало страницы. То же самое сделает и с подвалом — файлом footer.php, и так будет на каждой странице товара. Получается, что нам не нужно писать один и тот же код шапки и подвала на каждой странице, достаточно сделать это в одном месте, а потом подключать одной строчкой.

Создавать CMS и движки для сайтов. Такие модульные возможности PHP привели к тому, что большинство современных систем управления контентом на сайтах написаны на PHP. Смотрите сами:

  • WordPress;
  • Drupal;
  • Joomla;
  • MediaWiki — для создания вики-сайтов;
  • OpenCart — инструмент для интернет-магазинов;
  • phpMyAdmin — работа с базами данных.

Если вы на бесплатном хостинге используете какой-то инструмент для создания или поддержки сайта, скорее всего, он тоже будет написан на PHP.

Работать с формами и данными на странице. HTML плохо умеет работать с формами и отправлять куда-то данные, которые вы вводите в поля регистрации. PHP справляется с этим гораздо лучше: вы говорите, из какого поля что нужно взять и по какому адресу отправить, а всё остальное интерпретатор делает за вас.

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

Почему все ненавидят PHP

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

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

Смешанный код. Писать в одном файле на PHP и HTML можно, если у вас всего одна форма обратной связи. Но когда весь сложный код на PHP расползается по всей странице, то это сильно мешает разобраться, что же там происходит на самом деле.

Любые переменные в любом месте. Понадобилась новая переменная? Объявите её на любом участке кода и сразу берите в работу. Это удобно для первоначальной разработки, когда ты просто берёшь новую переменную там, где она понадобилась, и делаешь с ней что хочешь. Но когда проходит время или кто-то другой хочет разобраться в коде, то такой подход сильно затрудняет работу.

Например, можно написать так:

$a = 5+3; $b = "Строка"; … много строк кода … $a = 17 + $b; $b = 21;

Когда новый программист захочет понять, за что отвечают переменные а и b, он найдёт место, где они объявляются, и посмотрит, какого они типа и для чего использовались вначале. Но разработчик мог в процессе передумать и начать использовать эти переменные для других целей с новыми типами данных. Чтобы это понять, нужно просмотреть весь код и разобраться в логике, а это долго и трудно.

А ещё:

  • нет нормальной многопоточности;
  • мало фреймворков;
  • странная работа с объектами и классами;
  • нет контроля и отладки ошибок.

Стоит ли учить PHP?

Зависит от задачи. Дело в том, что не менее 80% сайтов уже сейчас работают на PHP: это значит, что их нужно будет еще какое-то время поддерживать. Ещё лет 5–10 спрос на PHP точно будет.

Однозначно стоит учить PHP, если хотите работать с Вордпрессом, Друпалом, Джумлой и другими известными системами управления сайтами. Они написаны на PHP, и все надстройки и дополнения — тоже. Хороший разработчик WordPress сейчас на вес золота.

Будут ли веб-разработчики массово переходить на другие технологии — вопрос открытый. Сейчас, если вы покупаете виртуальный хостинг, вам сразу включают интерпретатор PHP, потому что все его используют. А другие технологии типа Python или Node.js — не включают, их нужно устанавливать отдельно.

Но ведь и веб — это не навсегда. Ещё лет 20, и понятие веб-сайта может безнадёжно устареть, потому что люди будут в приложениях, соцсетях или ещё где похуже.

Наверное, ответ на вопрос такой: если вам до 20 лет, то уже не надо учить PHP. А если ближе к 40–50 и вы хотите заниматься вебом — то определённо да.

Содержание

PHP как модуль Apache (mod_php)

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

Преимущества:

  • Доступны настройки кэширования, за счет чего можно увеличить производительность.
  • Быстрое исполнение скриптов.

Недостатки:

  • Конфигурирование можно выполнять только через основной файл php.ini и некоторые параметры можно объявить через файл htaccess.
  • По умолчанию скрипты запускаются с правами пользователя apache. Однако это можно изменить путем использования mod_ruid, который позволяет запускать скрипты от разных пользователей.
  • Подгрузка модуля происходит во все процессы apache даже при отсутствии запросов на тип скрипта, обрабатываемый этим модулем. За счет этого создается бесполезная нагрузка на сервер.
  • Скрипт, имеющий ошибки, может привести к сбою работы веб-сервера.
  • Нет простого способа узнать, каким пользователем было запущено стороннее приложение.
  • Некоторые модули имеют проблемы в совместимости с многопоточным запуском веб-сервера (MPM Worker).

PHP в режиме CGI

В этом режиме запускается интерпретатор php-cgi для всех скриптов, для которых установлен CGI в качестве обработчика. Если большая часть сайта состоит из статического содержимого, то CGI будет хорошим выбором, т.к. будет обеспечено экономичное использование оперативной памяти за счет того, что интерпретатор будет вызываться в случае необходимости. Но и в то же время такой метод замедляет исполнение, т.к. при каждом запросе понадобится загрузка интерпретатора в память.

Преимущества:

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

Недостатки:

  • Не высокая производительность.
  • Разработка PHP-авторизации с командой Header имеет ограничения по причине того, что скрипт будет получать не все необходимые серверные переменные.

SuPHP

SuPHP является частным случаем CGI, в котором каждый php скрипт может выполняться с привилегиями разных пользователей.

Преимущества:

  • Можно отследить, от имени какого пользователя запускался скрипт.
  • Пользователь не сможет запустить скрипты, если он не является их владельцем.
  • Для всех файлов, которые будут загружены на сервер через сайт, будет установлен владельцем тот пользователь, от имени которого эти файлы загружались.

Недостатки:

  • Сравнительно с CGI более высокая нагрузка на CPU.
  • Недоступны функции кэширования, например, XCache, APC и др.

PHP в режиме FastCGI (mod_fastcgi)

По своим свойствам FastCGI является золотой серединой между mod_php и CGI режимами. В нём исключены недостатки CGI и присутствуют его достоинства. При включенном FastCGI, в ОЗУ сервера располагается постоянно запущенный процесс-обработчик. Это избавляет от необходимости при каждом запросе запускать новый процесс, как в случае использования CGI. По быстродействию FastCGI аналогичен mod_php.

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

Преимущества:

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

Недостатки:

  • Постоянно запущенный процесс интерпретатора создает нагрузку на оперативную память, хотя её объем меньше, чем при использовании PHP как модуля Apache. Это достигается за счет отсутствия необходимости обращения к интерпретатору PHP при выдаче статического содержимого.

LSPHP

LiteSpeed PHP (LSPHP) — реализован в виде модуля mod_lsapi на веб-сервере Apache и является наиболее производительным вариантом запуска PHP на серверах под управлением сPanel.

  • Увеличение скорости обработки PHP-скриптов, что ускоряет работу всего сайта.
  • Отсутствие 500-ой ошибки при наличии php_flag и подобных директив в .htaccess. Актуально при переезде с хостинга, который по умолчанию работал с mod_php.
  • Уменьшится потребление ресурсов в вашем виртуальном контейнере.
  • Улучшится эффективность работы Opcode Cache

На данный момент недостатков не было обнаружено.

Более подробно о работе LSPHP можно прочитать в нашем блоге в статье «Ускорьте работу своего сайта, перейдя на LSPHP».

Для того чтобы перейти на LSPHP, можно воспользоваться инструкцией из нашей вики.

Каким образом узнать текущий режим PHP?

Способ 1. С помощью функции phpinfo()

  • Создаем на хостинге php-файл c произвольным именем (например, info.php), после чего открываем его для редактирования и копируем в него следующие строки:
  • Сохраняем внесенные изменения, после чего открываем файл в браузере.
  • Если все данные были указаны верно, то в браузере будет выведена страница с развернутой информацией об установленном PHP. В перечне выведенных параметров будет присутствовать параметр Server API, в значении которого и отображается текущий режим PHP.
  • На изображении ниже показано значение параметра Server API в случае использования режима FastCGI.

Способ 2. С помощью функции функции php_sapi_name()

  • По аналогии первого способа, создаем на хостинге файл, например, info.php, затем открываем для редактирования и затем копируем следующий код:
  • После сохранения изменений открываем этот файл в браузере. В итоге должна быть отображена страница в теле которой будет выведено название используемого режима PHP. На изображении ниже представлен пример вывода при использовании режима FastCGI.

Уже знаете, какое доменное имя хотите получить для вашего веб-сайта? У нас вы можете купить домен дешево. Нужен хостинг? HOSTiQ предлагает интересные планы виртуального хостинга, а также вы сможете заказать VPS-сервер или арендовать сервер в Европе или США.

Та не, не сломаешь, в принципе. Но и DLE не будет работать нормально.

На всякий случай просто сохрани текущий конфиг, до переключения.

Просто ISP бывает глючит, когда слишком сильно модифицируешь дефолтный конфиг. А в случае с DLE его нужно модифицировать очень сильно, либо подключать инклюдом (самый верный вариант).

А если не будешь руками лазить в конфиг, и уверен, что DLE работает с дефолтным конфигом Apache — то можно и туда-обратно тыкать, ничего не сломаешь.

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

Что касается CGI — не совсем так, CGI точно так же через апач работает.

Годный пост. На сервере держу пока старую сборку с апачем, а вот на локалке поставил без него. Пока еще не юзал толком. Как я понял .htaceess в этой связке не работает? ЧПУ как здесь делать или все там так же работает?

Точно, .htaccess не пашет, ибо этот костыль умеет только апач. ЧПУ, соответственно, тоже не пашет. В этом обычно и заключается загвоздка при переключении на эту связку.
Если какая-то сложная CMS, то нужно рисовать и отлаживать конфиг под неё в Nginx.
Если обычный wordpress, то там решается довольно просто. Добавляется в конфиг такая строчка:
try_files $uri $uri/ /index.php?$args;
В блок location / <.>
Для некоторых других CMS тоже подходит этот вариант. А для того же DLE, например, надо рисовать большую портянку правил.

«Чтобы иметь преимущества php 7 его нужно обновить общесистемный. Тогда и высокопроизводительный сервис PHP-fpm станет работать на этой же версии. Но чего делать пока не рекомендуется, да и нету его еще в стабильных репозиториях большинства OS.»

Спасибо за эту статью и видео! Видео кстати также будет полезно тем, кто интересуется темой «как надо работать в терминале» )

Вопросики:
1. Если хочется php7, то на чистую ОС (как я понял сейчас мейнстрим CentOS для обычных сайтиков) сначала ставим из репозитариев php 5.5 (актуально на 06.2017) и потом еще ставим из не официальных репозитариев php7 ?
2. Или все-же на продакшн 5-ый ставят? )
3. Если Ставим Nginx то получается что apache можно вовсе не ставить…

P.S. Php7 сам по себе должен быть быстрее 5-го, т.к. в нем обновлен движок Zend и выброшено много устаревшего

Ну на самом деле тут в этой статье инфа немного уже устарела, ибо писалась на форуме более чем полгода назад. По крайней мере применительно к использованию php 7 в режиме php-fpm, особенно на сервере под управлением панельки ISPmanager 5. В нем можно в любом режиме удобно юзать любую версию PHP. И 7, и даже 7.1. Это я как раз и показывал на видео. И в другой статье http://vpsadm.ru/php-7-ispmanager-5-kak-ustanovit/

Что касается работы без панели — то сложности могут быть только при запуске в режиме апач-модуля.

В том же centos такую возможность не знаю как вкорячить. Технически это разумеется возможно, просто я пока не знаю как)

Далее по версиям OS. Это зависит исключительно от удобства администрирования, от привычки работы с ними. Для большинства задач и сайтов мне видится Centos удобней. В Debian 8 легко можно поставить обе версии параллельно. По-умолчанию там ставится из стабильных официальных репов 5.6 версия. Но можно установить дополнительно 7ю версию и переключаться между ними. В режиме php-fpm можно запускать сайты параллельно на разных версиях, в режиме модуля апача можно юзать либо ту либо другую, легко между ними переключаться. В режиме CGI тоже можно, но его вообще не стоит юзать. Если только для отладки.

На продакшн ставят то, что нормально работает) Поэтому перед продакшном надо погонять в тестах 🙂 Буквально на прошлой неделе переводил на php 7 как раз самый что ни на есть продакшн — огромную онлайн-библиотеку с трафом 200к в сутки, работающую на кластере из трёх серваков. В паре с разрабом, так задолбались, несколько дней по ночам. Оно работало на debian 7, в который вообще нет технической возможности поставить толком php 7 в режиме апача. Пришлось апгрейдить OS до debian 8, и потом только ставить php 7. Переключить у нас получилось только с третьей попытки, первые две была нестабильность, тормоза, глюки и отвалившийся функционал. Причем, это с учетом того, что до этого было протестировано на PHP 7.

По поводу Nginx — да, верно. Можно его использовать без апача в связке с php-fpm. Но обычно под него надо пилить и отлаживать конфиг, редко так сразу заработает. Особенно если какая-то неизвестная CMS или самопис. На основе htaccess пишется такой конфиг. Есть онлайн-конвертеры с .htaccess в правила nginx, но они в чистом редко выдают то что надо. Обычно их просто как подсобный инструмент можно использовать, брать какие-то куски, из них уже лепить и отлаживать свой конфиг.

Веб-серверы могут обрабатывать php-скрипты в разных режимах. Если выбрать подходящий вариант взаимодействия PHP и веб-сервера на сайте, это положительно отразится на его производительности.

Выбрать режим работы PHP можно на VPS с панелью управления ISPmanager и Plesk. На виртуальном хостинге REG.RU по умолчанию используется режим FastCGI.

Подробнее о том, какие режимы PHP поддерживаются на хостинге REG.RU, читайте в статье.

В этой статье мы рассмотрим основные режимы работы PHP.

PHP как модуль Apache (mod_php)

Модуль для веб-сервера Apache, который позволяет ему обрабатывать все запросы PHP, не используя сторонние модули.

Можно вводить переменные PHP в .htaccess.

отдельные пользователи на сервере с mod_php не могут вносить изменения, если у них нет прав доступа на все процессы, с которыми он работает. Иными словами, права веб-сервера должны выдаваться всем пользователям на сервере;

Низкий уровень безопасности, так как нельзя определить пользователя, который запустил конкретный процесс (все процессы выполняются анонимно под пользователем apache);

Ошибки в скриптах могут парализовать работу всего сервера;

Веб-серверы с mod_php медленно обрабатывают статические данные.

PHP в режиме CGI и FastCGI

PHP CGI — один из первых сценариев обработки php-скриптов сервером с помощью модуля mod_cgi. Сейчас он используется редко и считается устаревшим.

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

При создании сценария FastCGI учли медленную скорость обработки скриптов в CGI, поэтому в этом режиме используется циклическая обработка нескольких запросов одним процессом. Это экономит оперативную память за счет сокращения количества запущенных процессов.

Пользователь обладает правами на выполнение всех скриптов на своем www-домене;

Безопасность (каждый запрос выполняется под отдельным пользователем, запуск небезопасного php-скрипта не повлияет на файлы других пользователей, которые находятся на одном с ним сервере);

Каждый пользователь на сервере может выбрать персональную версию PHP;

Отсутствие сбоев сервера при наличии ошибок в скриптах;

Обработка правил конфигурационного файла .htaccess, который поддерживается популярными CMS (WordPress, Joomla, 1C-Битрикс и пр.).

Чуть меньшая производительность по сравнению с модулем Apache;

Медленная обработка статических данных без связки с веб-сервером Nginx.

PHP в режиме FPM

FPM (FastCGI Process Manager) — альтернативная реализация PHP FastCGI. Это единственный модуль, который подходит для чистого веб-сервера Nginx.

Быстрая обработка статических данных;

Отсутствует необходимость в веб-сервере Apache;

Меньшее потребление оперативной памяти.

  • Отсутствует поддержка конфигурационного файла .htaccess. Это требует самостоятельной настройки аналогичных правил на стороне веб-сервера Nginx.