Статические сайты

Когда, стоя у истоков того, что стало Web'ом (некоторые даже говорят - Internet, потому что они думают, что web - это и есть Internet; в какой-то степени они правы, потому что именно web позволили развиться Internet'у до сегодняшнего масштаба), Тим Бернерс-Ли создавал первые технологии web - язык разметки HTML, протокол HTTP версии 0.9, - их первые реализации (серверы и клиенты) были сравнительно примитивными. Первый web-сервер получал HTTP-запрос и отдавал файлы HTML в HTTP-ответе. В сущности, такой сервер выполнял простое отображение URL на файловую систему. В конфигурации сервера прописывалась директория, внутри которой ищутся HTML-файлы (с тех по традиции называющаяся htdocs), и сервер по запросу http://example.net/path/to/file.html отдавал htdocs/path/to/file.html.

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

Но самая большая революция произошла ещё несколько позже.

Динамика

А затем кто-то сообразил, что браузеру всё равно, откуда сервер берёт HTML - так пусть при некоторых конфигурациях сервер создаёт HTML "на лету", прямо в момент запроса. Так родился протокол CGI и директория cgi-bin.

Протокол CGI - это протокол обмена информацией между сервером и программой, которую он запускает, называемой CGI-программой. Протокол довольно простой: в переменные окружения программы пишется большой список переменных, в каждой из которых кусочки информации из HTTP-запроса, например, в переменой QUERY_STRING - строка запроса из URL; в stdin программы подаются данные, присланные браузером по запросу POST; из stdout ожидается HTTP-ответ (заголовки и тело ответа), созданный программой для отправки в браузер; stderr пишется в лог сервера. Сервер перехватывает stdout, добавляет свои собственные заголовки, и всё отправляет в браузер. Если серверу не нравится, что вернула CGI-программа, сервер отправляет браузеру ошибку 500.

Скрипты по первости клались в выделенную область сервера - в директорию /cgi-bin. Увидев URL, начинающийся с /cgi-bin, сервер знал, что от него просят не статический файл, а результат запуска CGI-программы. В дальнейшем, конечно, конфигурация серверов была расширена, и современные сервера умеют запускать программы в ответ на любой запрос, поэтому по виду URL больше нельзя понять, статический ли это файл.

Поскольку генерация простого текста и HTML - это, в основном, манипуляция строками (конкатенация и подстановка), традиционные языки программирования, C и C++, не очень подходят для написания CGI-программ (в том числе и из-за проблем с безопасностью). CGI стали писать на скриптовых языках, отличительными особенностями которых были интерпретируемость, автоматическое управление памятью и строковые типы данных неограниченной длины. Это сильно увеличило популярность скриптовых языков. А CGI-программы даже начали называть CGI-скриптами.

Следующей революцией стала генерация изображений в дополнение к генерации HTML. Сгенерированное изображение не кладётся на диск, а, как любая информация, отдаётся из CGI сразу в браузер. Динамические картинки позволяют... да что угодно. Первое время после появления этой идеи все делали счётчики - при обращения к CGI для загрузки изображения программа делала сравнительно обоснованное предположение, что эту программу вызвали из HTML, программа увеличивала счётчик в БД, и создавала изображение с цифрами, или даже текстом типа "сегодня нас посетило 2.5 человека, а вообще со времён Большого Взрыва - аж целых 7".

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

Масштабирование

По мере роста популярности web, стали появляться сервера с высокой посещаемостью. На них запускалось большое количество CGI-скриптов, и начали проявляться проблемы с масштабируемостью. Ведь на каждый запуск CGI с диска запускается огромный толстый интерпретатор, потом CGI подгружает кучу библиотек. Динамические сервера стали поедать память и тормозить.

Решение нашлось довольно быстро - интерпретаторы стали помещать в сами сервера - путём простой компиляции, или модульной архитектуры сервера с динамической загрузкой модулей. Для наиболее популярного сервера Apache модули mod_perl и mod_php подгружают интерпретаторы языков Perl и PHP, соответственно. Это далеко не единственные языки программирования CGI, но самые известные и популярные.

Достоинства интерпретатора, загруженного в сервер - интерпретатор всегда находится в памяти, и он может кешировать CGI-скрипты и библиотечные модули. Недостаток - небезопасность: интерпретатор сидит в середине сервера, и, обнаружся в нём дыра, открываем злоумышленнику все внутренности сервера. Кроме того, при изменении скриптов и библиотек весь сервер надо перестартовать, чтобы очистить кеш интерпретатора.

Сервера web-приложений

И, наконец, web-сайты стали настолько сложными, что превратились в целые web-приложения, с системами аутентификации и авторизации, с большим количеством информации, хранящейся в БД, с возможностью настройки приложений под потребности и привычки зарегистрированных пользователей. Такие web-приложения продолжали делаться и с помощью CGI, и с помощью модулей сервера. Но также был найден ещё один способ.

Рядом с web-сервером, на том же хосте, или на соседнем, запускается ещё один сервер, получивший название "сервер web-приложений" (web application server). Web-сервер получает запрос от браузера, и передаёт его серверу web-приложений по какому-нибудь стандартному протоколу. Один из наиболее известных протоколов для этого - FastCGI; используют, однако, и HTTP, и другие протоколы. Сервер web-приложений обрабатывает запрос и отдаёт результат web-серверу, который отдаёт ответ браузеру.

Достоинствами сервера web-приложений являются: повышенная безопасность (не контактирует с пользователем непосредственно); постоянно находится в памяти; написан специально для создания web-приложений (web-сервер же - штука слишком универсальная); может открыть много соединений к серверу БД, и потом не закрывать их, а пользоваться открытыми, это хорошо для тех СУБД, у которых открытие соединения занимает заметное время.

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