От CGI к PHP и серверам приложений

CGI — способ, при котором веб-сервер запускает новую программу на каждый запрос. PHP встроил код прямо в HTML, а сервер приложений держит программу запущенной.

Как сервер научился думать

Мы остановились на том, что динамической странице нужен код, который собирает её в момент запроса. Но код на сервере можно запускать по-разному, и от выбора зависит почти всё: скорость, цена хостинга, то, что можно построить. Три способа появились один за другим, и все три живы до сих пор.

CGI: новая программа на каждый запрос

Первые сайты были статичными. Чтобы страница могла зависеть от запроса, в 1993 году придумали CGI (Common Gateway Interface, «общий шлюз»). Идея простая: веб-сервер, получив запрос на определённый адрес, не ищет файл, а запускает программу, передаёт ей запрос (адрес, параметры, заголовки) и отправляет посетителю то, что она напечатает. Программа может быть на чём угодно: на Perl (так было чаще всего), C, shell. Правила разговора записаны в стандарте RFC 3875.

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

PHP: код внутри страницы

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

<h1>Здравствуйте, <?php echo $name; ?></h1>

Сервер выполняет вставки и отдаёт готовую страницу. Для новичка это было раем: пишешь страницу как обычно, а там, где нужно, вставляешь код. PHP быстро стал языком «сайтов из базы данных», а его хостинг стоил копейки и был у любого провайдера. На нём построены WordPress, Drupal, Joomla, 1С-Битрикс, а значит, огромная доля сайтов в мире и в России.

Модель PHP очень проста: каждый запрос начинается с чистого листа. Скрипт выполняется от начала до конца, страница отдана, все переменные забыты. Следующий запрос ничего не знает о предыдущем. Это ограничение, но оно же и защита: нечему накапливаться, ошибки не копятся в памяти, один запрос не может испортить другой. Всё, что нужно помнить между запросами (кто вошёл, что в корзине), хранят снаружи: в базе, в файле сессии, в кэше.

Чтобы не запускать PHP заново на каждый запрос, как в CGI, придумали FastCGI, а для PHP его реализацию PHP-FPM (FastCGI Process Manager). Это пул готовых процессов: nginx передаёт запрос свободному, тот выполняет скрипт, отдаёт ответ, забывает переменные и ждёт следующего. Запуск интерпретатора больше не нужен, а «чистый лист» сохранился.

Серверы приложений: программа, которая не умирает

Для многих задач чистый лист мешает. Чат держит открытое соединение с каждым посетителем и должен рассылать сообщения всем сразу. Онлайн-игра помнит положение игроков. Панель с живыми графиками следит за потоком событий. Для этого нужна программа, которая работает всё время, хранит общее состояние в памяти и сама принимает запросы.

Так устроены серверы приложений: Node.js на JavaScript (с 2009 года), Python-приложения за интерфейсами WSGI и ASGI (на них стоит Django), Java и C#, Go, Elixir с фреймворком Phoenix, Ruby on Rails. Запускается приложение один раз и принимает запросы тысячами, а перед ним ставят уже знакомый вам nginx как обратный прокси.

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

Посмотрите на три устройства рядом. Отправьте несколько запросов и обратите внимание на счётчик:

Отправить запрос Отправить сразу пять Сначала Запросов: 0

CGI

Каждый запрос: запускается новая программа.

После ответа: программа завершается, память освобождена.

Счётчик в коде ($visits++): 0

Время на 0 запр.: ≈ 0 мс

PHP-FPM

Каждый запрос: берётся готовый рабочий процесс из пула.

После ответа: переменные скрипта забыты после ответа.

Счётчик в коде ($visits++): 0

Время на 0 запр.: ≈ 0 мс

Сервер приложений

Каждый запрос: программа уже работает.

После ответа: переменные живут между запросами.

Счётчик в коде ($visits++): 0

Время на 0 запр.: ≈ 0 мс

Отправьте несколько запросов и следите за счётчиком.

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

Проверьте себя: почему в PHP счётчик начинается с нуля на каждом запросе?

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

Почему именно так всё сложилось

Выбор языка редко делается по достоинствам. В 2000-е на дешёвый хостинг клали PHP, поэтому появились WordPress и Битрикс, поэтому появились тысячи специалистов и плагинов, поэтому на PHP выгодно писать следующий сайт. Такая цепочка называется эффектом экосистемы, и её не отменить заявлением «Python лучше».

Верно и обратное: язык с живым приложением выбирают, когда задача этого требует. Об этом в следующем уроке.

Практика

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

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

Что было не так раньше

CGI-скрипты писали прямо в папке cgi-bin, и любая их ошибка превращалась в дыру на сервере: параметры запроса попадали прямо в команды, а скрипты запускались с правами сервера. Первый PHP страдал тем же: смешанный код и разметка в одном файле, пароль от базы прямо в странице, а register_globals позволял подставить любую переменную через адрес. Поколение сайтов 2000-х писали так, и вот почему о PHP тогда осталась репутация небезопасного языка.

Сегодняшний PHP совсем другой: у него есть типы, фреймворки (Laravel, Symfony) и строгие правила. А модель «запрос — процесс», которая тогда казалась недостатком, сегодня считается достоинством: она проста, надёжна и хорошо масштабируется простым добавлением серверов.