Создание Web-серверов

• Общие замечания.
• Постановка задачи
• Анализ HTTP—заголовков, получаемых от клиента
• Обзор структуры сервера
• Реализация Web-сервера

Общие замечания

Многие вопросы создания Интернет-систем были изложены в предыдущих главах. Настало время познакомиться с процессом создания собственно Web-серверов.

Серверы различного назначения могут быть реализованы на базе сведений о сокетах, описанных в гл. 13. В этой главе рассматривается процесс создания сервера, взаимодействующего с универсальным клиентом — браузером. Поскольку очень часто нет смысла вторгаться на сторону этого клиента и каким-либо образом модернизировать его, то для обмена данными будет использоваться распространенный протокол HTTP. Задача сервера состоит в получении клиентских сведений и, затем, отправке браузеру предварительно сгенерированного ответа. В отличие от базирующихся на технологии CGI серверных модулей, где вся ответственность за разбор клиентских данных ложилась на Web-сервер, эту работу должна проводить создаваемая программа. Данная программа будет также генерировать ответ.

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

• Возможность прямого обмена данными между клиентскими задачами. Использование запуска отдельного экземпляра модуля-обработчика для каждого запроса рождает следующую проблему: как обмениваться данными между экземплярами модулей. Как правило, она решается путем сохранения данных в файл. Этот способ вынуждает предусматривать обработку конфликтов совместного доступа к файлам, когда один экземпляр модуля еще не завершил транзакцию, а второй уже пытается открыть этот общий файл для чтения или записи. При большом количестве одновременных попыток доступа возникает очередь и, как следствие, потеря возможности одновременного (или почти одновременного) обслуживания клиентов. Эта конфликтная ситуация может быть решена путем использования глобальных переменных в одной программе. Поскольку время обработки дисковых операций значительно больше времени работы с памятью, даже если данные находятся в дисковом кэше, то распараллеливание операций (даже не совсем полноценное) становится более простым. Если же используется способ сохранения данных в БД, настроенной на обработку параллельных запросов, то все равно SQL-сервер требует достаточно много времени на проведение транзакции, что может существенно сказаться на быстродействии системы.
• Экономия памяти сервера. Действительно, при работе с Web-сервером и CGI-модулями каждый запрос приводит к запуску своего экземпляра модуля, что неэффективно с точки зрения распределения памяти.
• Увеличение общего быстродействия системы. Поскольку каждый запускаемый экземпляр модуля требует для загрузки определенного времени, состоящего из чтения ЕХЕ-файла с диска, регистрации процесса в системе и т. д., то единожды запущенная программа — комплексный сервер сильно сэкономит рабочее время процессора сервера и сократит время обработки клиентских запросов. Кроме того, каждый процесс, естественно, требует вычислительных ресурсов, что при большом их количестве приводит к задержкам в обработке клиентских запросов.
• Централизованное решение вопросов безопасности. При написании серверных модулей нужно распределять задачи контроля безопасности общей системы между собственно CGI-модулем, Web-сервером, операционной системой, сервером базы данных. На самом деле, отследить все "узкие места", которыми может воспользоваться хакер в каждом компоненте системы — трудная задача. Кроме того, и операционная система, и Web-сервер разрабатываются с позиций универсальности, предполагая решение разнотипных задач, о которых конечный разработчик CGI-модуля может и не подозревать. Эта универсальность является либо мощным фундаментом для выведения всей системы из строя, либо работы с непредусмотренной программистом логикой, что еще хуже. Создавая собственный сервер, программист предусматривает только тот алгоритм, который обеспечивает выполнение- его, и только его задач. При этом, разумеется, разграничение прав доступа к диску и реализация сетевых операций на низком уровне находятся в компетенции операционной системы, но они, как правило, являются достаточно защищенными участками в общей структуре безопасности ОС.
• Статичность объектов системы. При создании служб, предполагающих обмен данными между клиентом и сервером, состоящий из нескольких последовательных фаз, трудно применять обычные подходы к проектированию. Каждый раз, когда модуль выполнил определенный, пусть даже очень небольшой, блок задач, сгенерировав ответ клиенту, его работа должна быть завершена. При этом, естественно, все объекты, на базе которых были созданы программы, уничтожаются. Для последующего восстановления состояния их полей (свойств), последние нужно сохранять, например, в скрытых (hidden) элементах Web-страницы, отправленной клиенту. Такая ситуация порою очень неудобна и CGI-программисты прибегают к технологии так называемых "долгоживущих" модулей, один запущенный экземпляр которого может обслуживать несколько последовательных запросов одного клиента. Вместе с тем, программируя сам сервер, можно использовать более гибкие средства как для работы с каждым клиентом, так и для менеджмента всех соединений в комплексе.

Однако данный подход к созданию серверной части имеет ряд недостатков, главным из которых является повышенное требование устойчивости создаваемой программы к возникновению исключительных ситуаций. Дело в том, что если "зависнет" CGI-модуль, то это половина беды, т. к., скорее всего, работоспособность всего Web-сервера не будет нарушена, но если "зависнет" сам сервер, то "клиническая смерть" Web-узлу обеспечена.

Постановка задачи

Создаваемый сервер должен стать примером программы, которая, используя непосредственное сетевое подключение через сокеты, будет взаимодействовать с браузером на базе стандартного протокола HTTP. Использование обычных Интернет-средств, в отличие от предыдущего сокетного сервера, реализованного в гл. 13, позволяет создавать комплексные Web-узлы, рассчитанные на любого пользователя.

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

• Каждый пользователь входит в чат со специальной страницы, где он может указать свое имя, отображаемое затем для идентификации принадлежности сообщения.
• Контроль пользователей ведется посредством отслеживания их IP-адресов.
• Попытка двойного входа в чат должна быть запрещена. Это значит, что каждый клиент имеет определенное, указанное имя, и в случае, когда он производит попытку входа в чат с другим именем, доступ к чату этого клиента с новым именем должен быть заблокирован.
• Формирование графического отображения Web-страниц осуществляется на основании использования таблиц стилей.

Анализ HTTP-заголовков, получаемых от клиента

В гл. 9, посвященной CGI, были отдельно рассмотрены HTTP-заголовки. Этот материал касался только серверной части, что было обусловлено использованием Web-сервера. Он берет на себя весь процесс разбора клиентского запроса с передачей результата своей работы в переменные окружения. Мы использовали эти переменные для доступа к интересующей нас информации. Теперь, создавая сервер, необходимо самостоятельно получить и обработать эти данные.

Чтобы получить информацию о том, в каком виде она передается от клиента к серверу, создадим вспомогательную программу, роль которой будет заключаться лишь в возвращении заголовков, получаемых от клиента, ему же, но в теле Web-страницы. Для этого создадим новый проект в Delphi под названием httphead. Для этого на обычную форму нужно поместить компонент TServerSocket, находящийся на вкладке Internet Component Palette.

Из всех параметров, установленных у помещенного на форму компонента по умолчанию, нужно изменить лишь номер порта. Портом по умолчанию для Web-служб является 80. Обратите внимание, что одновременная работа нескольких приложений на одном порте вызывает конфликтную ситуацию, поэтому если на компьютере работает другой Web-сервер, то на время отладки этого приложения его нужно отключить, либо присвоить порту другой номер. Вслед за определением номера порта, свойству Active используемого объекта — экземпляра класса TServerSocket, присваивается значение true.

Следующим этапом в создании вспомогательного приложения является обработка событий OnClientRead И OnClientWrite. Определим глобальную переменную dheaders в секции Var строкового типа. Теперь осталось получить от клиента заголовки и переправить их в содержание ответа. Процедура получения данных от клиента приведена в листинге 15.1.

Листинг 15.1. Получение данных от клиента

procedure TForml.ServerSocketlClientRead(Sender: TObject;

Socket: TCustomWinSocket); begin

dheaders: = (Socket.ReceiveText);

end;

После того как содержимое HTTP-заголовка занесено в переменную dheaders, можно посылать ответ клиенту, как показано в листинге 15.2.

Листинг 15.2. Процедура отправки данных клиенту

procedure TForml.ServerSocketlClientWrite(Sender: TObject;

Socket: TCustomWinSocket); begin

Socket.SendTextCHTTP/1.1 200 Ok'fl3#10); Socket.SendText('Content-Type: text/html'#13110); Socket.SendText(''#13#10); Socket.SendText('<HTML>'); Socket.SendText(clheaders); Socket.SendText('</HTML>');

end;

Дата добавления: 2014-12-29