1. Принимает входящее TCP-соединение от клиента (браузера).
2. Получает путь к странице, являющийся именем запрашиваемого файла.
3. Получает файл (с диска).
4. Высылает содержимое файла клиенту.
5. Разрывает TCP-соединение.
Современные веб-серверы обладают более широкими возможностями, однако существенными в их работе являются именно перечисленные шаги, предпринимаемые в случае запроса контента, содержащегося в файле. В том случае, если контент является динамическим, третий шаг может быть заменен запуском программы (определенной по пути), возвращающей контент.
Однако веб-серверы реализуются иным способом, для того чтобы они отвечали на множество запросов за одну секунду. Одна из проблем, связанных с простым способом реализации, заключается в том, что доступ к файлам часто затруднен. Считывание с диска идет слишком медленно по сравнению с работой программы, и одни и те же файлы могут считываться с диска несколько раз из-за вызовов операционной системы. Другая проблема заключается в том, что одновременно не могут обрабатываться несколько запросов. Файл может быть большим, и пока он передается, другие запросы блокируются.
Очевидным способом решения проблемы является кэширование в памяти n последних запрошенных файлов или определенного количества гигабайт контента. Прежде чем обратиться за файлом к диску, сервер проверяет содержимое кэша. Если файл обнаруживается в кэше, его можно сразу выдать клиенту, не обращаясь к диску. Несмотря на то что для эффективного кэширования требуются большие объемы памяти и некоторое дополнительное время на проверку кэша и управление его содержимым, суммарный выигрыш во времени почти всегда оправдывает эти накладные расходы и стоимость.
Одним из способов решения проблемы последовательной обработки запросов является создание многопоточных (multithreaded) серверов. Одна из реализаций подразумевает, что сервер состоит из входного модуля, принимающего все входящие запросы, и k обрабатывающих модулей, как показано на рис. 7.9. Все k + 1 потоков принадлежат одному и тому же процессу, поэтому у обрабатывающих модулей есть доступ к кэшу в адресном пространстве процесса. Когда приходит запрос, входящий модуль принимает его и создает краткую запись с его описанием. Затем запись передается одному из обрабатывающих модулей.
Рис. 7.9. Многопоточный веб-сервер с входным и обрабатывающими модулями
Обрабатывающий модуль вначале проверяет кэш на предмет нахождения там нужных файлов. Если они там действительно есть, он обновляет запись, включая в нее указатель на файл. Если искомого файла в кэше нет, обрабатывающий модуль обращается к диску и считывает файл в кэш (при этом, возможно, затирая некоторые хранящиеся там файлы, чтобы освободить место). Считанный с диска файл попадает в кэш и отсылается клиенту.
Преимущество такой схемы заключается в том, что пока один или несколько обрабатывающих модулей заблокированы в ожидании окончания дисковой или сетевой операции (при этом такие модули не потребляют мощности центрального процессора), другие модули могут активно обрабатывать другие запросы. Имея k обрабатывающих модулей, производительность можно повысить в k раз по сравнению с однопоточным сервером. Конечно, когда диск или сеть являются ограничивающим фактором, необходимо наличие нескольких дисков или более быстрой сети, чтобы действительно улучшить однопоточную модель.
Современные веб-серверы выполняют гораздо больше функций, чем просто прием имен путей и отправка файлов. На самом деле, реальная обработка каждого запроса может оказаться достаточно сложной. По этой причине на многих серверах каждый обрабатывающий модуль выполняет последовательности действий. Входной модуль передает каждый входящий запрос первому доступному модулю, который обрабатывает его путем выполнения некоторого подмножества указанных ниже шагов, в зависимости от того, что именно требуется для данного запроса. Эти шаги появляются после того, как было создано TCP-соединение и какой-либо защищенный транспортный механизм (как SSL/TLS, который будет описан в главе 8).
1. Вычисление имени запрашиваемой веб-страницы.
2. Осуществление контроля доступа для веб-страницы.
3. Проверка кэша.
4. Получение запрошенной страницы с диска или запуск программы, создающей ее.
5. Определение оставшейся части ответа (например, типа MIME).
6. Возвращение ответа клиенту.
7. Добавление записи в журнал активности сервера.
Шаг 1 необходим, потому что входящий запрос может и не содержать реального имени файла или программы в виде строкового литерала. Он может содержать встроенные ярлыки, которые необходимо передать. Например, URL может быть вот таким: http://www.cs.vu.nl/. Здесь имя файла отсутствует. Этот URL необходимо дополнить неким именем файла по умолчанию. Обычно это index.html. Другое общее правило — отображать ~user/ в веб-каталог пользователя. Эти правила могут быть использованы вместе. Таким образом, домашняя страница одного из авторов (AST) будет доступна по адресу:
http://www.sc.vu.nl/~ast/
несмотря на то что реальным именем файла является index.html в определенном каталоге. К тому же современные браузеры могут указывать информацию о конфигурации, такую как язык пользователя и ПО браузера по умолчанию (например, итальянский или английский), что позволяет серверу выбирать веб-страницу с маленькими картинками для мобильного устройства на соответствующем языке, если таковая существует. Вообще говоря, расширение имени — задача не такая уж тривиальная, как может показаться, поскольку существует множество соглашений о том, как отображать пути в файловые каталоги и программы.
Шаг 2 состоит в проверке наличия ограничений доступа, ассоциированных со страницей. Не все страницы доступны широкой публике. Определение того, имеет ли право клиент просматривать страницу, может зависеть от личности клиента (например, заданной при помощи имени пользователя и пароля) или расположения клиента в пространстве DNS или IP. Например, право просмотра страницы могут иметь только сотрудники какой-либо компании. То, как это достигается, зависит от устройства сервера. Так, на популярном сервере Apache в каталоге, в котором расположены файлы с ограничением доступа, существует файл под названием .htaccess, перечисляющий эти ограничения.
Шаги 3 и 4 подразумевают получение страницы. Правила обработки определяют, можно ли ее получить из кэша. Например, страницы, созданные работающими программами, не всегда могут сохраняться в кэше, так как при каждом запуске они могут выдавать различные результаты. Время от времени должны проверяться даже файлы, чтобы выяснить, не изменилось ли их содержимое (тогда старые версии можно будет удалить из кэша). Если страница требует запуска программы, также возникает проблема с определением параметров программы или входных данных. Эти данные извлекаются из пути или других частей запроса.
На шаге 5 определяются другие части ответа, связанные с содержимым страницы. Например, MIME-тип. Он может следовать из расширения файла, файла конфигурации и, возможно, других источников.
Шаг 6 возвращает страницу по сети. Чтобы повысить производительность, одно и то же TCP-соединение может быть использовано клиентом и сервером для многократного получения различных страниц. Такой тип использования предполагает создание некоторой логики для отображения запроса на совместно используемое соединение и возвращения каждого ответа таким образом, чтобы он ассоциировался с нужным запросом.
Шаг 7 создает для административных целей запись в системном журнале и сохраняет другую важную статистику. Такие журналы могут быть исследованы на наличие полезной информации о поведении пользователей, например о том, в каком порядке люди посещают страницы на сайте.
