* Apache. Этот продукт поставляется в составе каждого дистрибутивного пакета Linux. Как правило, процедура установки системы запрашивает пользователя, следует ли инсталлировать сервер Apache. По данным Netcraft (http: / /www. netcraft. com), в марте 2002 г. 65% всех работающий в Internet Web-серверов составляли серверы Apache. По этой причине основное, внимание в данной главе уделяется данному продукту. Apache представляет собой полнофункциональный Web-сервер и реализует расширенные возможности, например поддерживает сценарии CGI и SSL-взаимодействие. Web-узел Apache расположен по адресу http://httpd.apache.org.

* Roxen. Этот продукт также представляет собой полнофункциональный Web-сервер; во многом он напоминает Apache. Его настройка осуществляется посредством Web-интерфейса, что привлекает некоторых начинающих администраторов. Дополнительную информацию о Roxen можно получить, обратившись по адресу http://www.roxen.com/products/webserver/.

* thttpd. Данный сервер отличается небольшим размером кода. Если объем Apache составляет около 300 Кбайт (в зависимости от набора используемых компонентов эта цифра может изменяться), то объем thttpd - всего 50 Кбайт. Данный сервер работает быстро и эффективно. Несмотря на размер, он поддерживает сценарии CGI, но не обеспечивает SSL-взаимодействие. Более подробные сведения об этом сервере можно получить по адресу http://www.acme.com/software/ thttpd/thttpd.html.

* Zeus. Большинство Web-серверов, предназначенных для работы в системе Linux, бесплатно распространяются в исходных кодах, но Zeus является исключением. Это коммерческий продукт; его цена составляет 1700долларов. Согласно информации, опубликованной на Web-узле Zeus (http://www.zeus. co.uk/products/ zws/), данный сервер обеспечивает лучшую масштабируемость по сравнению с другими серверами. Это проявляется при интенсивных обращениях клиентов к Web-серверу.

* Web-серверы на базе ядра. Существуют Web-серверы, которые выполняются как процессы ядра Linux. Дело в том, что действия по предоставлению Web-страниц пользователям в основном сводятся к обращению к дискам и обмену данными через сетевое соединение. Большинство подобных задач могут решаться непосредственно ядром системы, причем выполняются они гораздо эффективнее, чем это происходит при использовании внешних программ. Подобные серверы будут подробно рассмотрены ниже.

* Нетрадиционные серверы. Некоторые программы используют протокол HTTP для выполнения специальных действий, не поддерживаемых обычными Web-серверами. Например, инструменты удаленного администрирования, которые рассматривались в главе 16, формально могут считаться Web-серверами. Взаимодействие с ними можно организовать посредством обычных Web-броузеров, но они принимают обращения от клиентов через порт, отличный от порта 80. Подобные серверы в данной главе рассматриваться не будут.

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

Как правило, требованиям большинства администраторов вполне удовлетворяет сервер Apache, поставляемый в комплекте со всеми версиями Linux. Если по каким-то причинам вам необходимо минимизировать объем памяти, занимаемый сервером, рассмотрите возможность использования сервера thttpd. Если вам не нужны расширенные возможности, предоставляемые Apache, то имеет смысл выбрать тот сервер, для инсталляции, настройки и поддержки которого требуется меньше усилий. Однако благодаря популярности Apache процедура его настройки многократно проверена, и при этом обычно не возникает проблем, потому большинство администраторов выбирают данный сервер для решения своих задач. Если вам необходим максимально производительный сервер, это обеспечит сервер, использующий функции ядра, например kHTTPd. Этот продукт позволяет обработать больше запросов, не увеличивая объем ресурсов компьютера. Повысить эффективность обработки запросов позволяют также серверы thttpd и Zeus. Следует заметить, что в подавляющем большинстве случаев производительность сервера ограничивается не ресурсами компьютера, а пропускной способностью линии связи. Если число обращений к вашему серверу превышает возможности линии, установка более эффективно работающих программ не решит проблему. В этом случае вам надо искать способы уменьшения нагрузки на сеть (например, за счет сокращения объема графических материалов), увеличения пропускной способности линии либо рассмотреть возможность размещения Web-сервера в другой сети.

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

1.3 Настройка основных функций Apache

web сервер linux apache

Независимо от того, какие задачи должен решать ваш Web-сервер, конфигурирование его надо начать с настройки базовых функций Apache. Лишь после того, как сервер сможет предоставить клиентам статические документы (т. е. документы, не предполагающие использование сценариев), вы сможете приступить к созданию конфигурации, ориентированной на поддержку расширенных возможностей. Первоначальная настройка Apache сводится к установке значений нескольких основных опций конфигурационного файла. Кроме того, вам необходимо иметь хотя бы общее представление о модулях Apache, которые представляют собой расширения, предназначенные для решения специфических задач. В большинстве дистрибутивных пакетов сервер Apache по умолчанию настроен так, что для обеспечения его работы достаточно внести в конфигурационные файлы лишь незначительные изменения.

Конфигурационные файлы Apache

В большинстве пакетов основной конфигурационный файл Apache носит имя httpd. conf. В зависимости от версии системы этот файл может находиться в разных каталогах, но формат его остается неизменным. В системах Caldera и SuSE файл httpd. conf содержится в каталоге /etc/httpd; в Debmnи Slackware он размещается в /etc/apache (Slackware предоставляет файл-образец /etc/apache/httpd. conf .default; для обеспечения работы сервера надо лишь переименовать данный файл и внести в него необходимые изменения); в Red Hat и TurboLinux файл httpd. conf размещается в каталоге /etc/httpd/conf/.

Директива Значение

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

<Directory /home/httpd/html> Options FollowSymLinks

AllowOverride None </Directory>

В последней строке содержится имя той же директивы, которая указана в начале, но для нее не задается никакое значение. Имени директивы, завершающей блок, предшествует косая черта.

В некоторых случаях для настройки Apache используются дополнительные конфигурационные файлы, перечисленные ниже. Обычно они размещаются в том же каталоге, что и httpd.conf.

* access.conf. Ссылка на этот файл формируется с помощью директивы AccessConfig и содержится в файле httpd.conf. В файле access.conf чаще всего задаются директивы <Directory>, определяющие особенности доступа к указанным в них каталогам. В настоящее время этот файл обычно остается пустым, а иногда в качестве значения AccessConfig задается /dev/null, что запрещает использование access, conf.

* mime.types. Для того чтобы сообщить Web-броузеру о том, как должны обрабатываться данные, Web-сервер использует стандарт MIME (Multipurpose Internet Mail Extensions - многоцелевые почтовые расширений Internet). Например, MIME-тип text/plain означает, что данные представляют собой обычный текст, a image /j peg определяет графические данные в формате JPEG (Joint Photographic Experts Group - объединенная группа экспертов по обработке фотоснимков). Файл mime -types содержит информацию о соответствии между MIME-типами и расширениями файлов. Например, имена файлов, оканчивающиеся .txtи .asc, связываются с MIME-типом text/plain. Если такое соответствие задано неправильно, Web-броузер будет испытывать затруднения при обработке некоторых типов файлов. Файл, поставляемый в составе пакета, обеспечивает обработку практически любых типов данных, которые могут быть помещены на Web-страницу. Если же вам надо использовать редко встречающиеся типы, вам придется добавить в этот файл новые записи.

* magic. Этот файл также позволяет определять соответствие междуМ1МЕ-ТИШМИ и данными. При анализе информации можно обнаружить специфические признаки того или иного типа. Так, например, многие файлы содержат специальные ключи -"магические" байтовые последовательности. Эти последовательности, преобразованные в текстовый вид, указываются в файле magic. Если вы подробно не изучили формат этого файла, вносить изменения в него не рекомендуется. Структура файла magic в данной главе рассматриваться не будет.

Способы запуска сервера Apache

В главе 4 были описаны различные способы запуска серверов на выполнение. Apache может быть запущен любым из этих способов: с помощью суперсервера, сценария запуска SysV либо локального сценария. В большинстве дистрибутивных пакетов предусмотрен запуск сервера с помощью сценария SysV или локального сценария, так как эти способы обеспечивают постоянное присутствие сервера в памяти и, следовательно, уменьшают задержку при генерации ответа на запрос клиента. При необходимости вы можете также обеспечить запуск Apache посредством суперсервера; программа инсталляции системы Debian даже задает вопрос о том, каким способом должен запускаться сервер. Однако при использовании суперсервера скорость обработки запросов снизится, так как, получив запрос, суперсервер должен будет загрузить Apache.

Опции общего назначения

Конфигурация, устанавливаемая по умолчанию, во многих случаях обеспечивает работоспособность сервера. После инсталляции сервера и его запуска Apache готов предоставить пользователям файлы из каталога по умолчанию (обычно это каталог /home/ httpd/html). В этот каталог при установке Apache помещаются файлы, содержащие в основном информацию о том, что сервер инсталлирован, но настройка его еще не закончена. Впоследствии вы, вероятно, замените их теми файлами, которые и будут составлять содержимое Web-узла.Ниже описаны опции общего назначения, определяющие поведение Apache. Настройка сервера выполняется путем изменения их значений.

* ServerType. Эта директива уже рассматривалась ранее. Она может принимать значение standalone или inetd.

* User и Group. В системе Linux каждый сервер запускается от имени конкретного пользователя и группы. Эти директивы позволяют указать пользователя и группу, с полномочиями которых будет выполняться сервер Apache. В большинстве дистрибутивных пакетов Apache запускается от имени пользователя nobody либо с помощью учетной записи, специально созданной для данной цели и предусматривающей минимальные привилегии пользователя. Такой подход снижает вероятность того, что злоумышленник сможет воспользоваться недостатками в защите сервера для незаконного проникновения в систему. Рекомендуется принять значения этих опций, установленные при инсталляции системы.

В целях повышения безопасности системы большинство двоичных файлов HXV Apache скомпилированы так, чтобы их нельзя было запустить от имени пользователя root.

* ServerTokens. Сервер Apache предоставляет клиентской программе информацию о платформе, на которой он выполняется. В большинстве пакетов по умолчанию для этой опции задается значение ProductOnly, которое запрещает передавать клиенту сведения о системе. При желании вы можете задать значение Min, OS или Full (эти значения расположены в порядке возрастания объема информации, передаваемой клиенту), но в целях повышения безопасности рекомендуется принять значение ProductOnly, установленное при инсталляции.

ВНИМАНИЕ Не следует считать, что, установив значение ProductOnly опции | ServerTokens, вы лишите взломщика возможности получить данные о системе. Он по-прежнему может анализировать трафик и не только выяснить тот факт, что вы используете Linux, но и узнать версию системы. Кроме того, сведения о платформе могут предоставлять другие серверы.

* MinSpareServers и MaxSpareServers. Если Apache должен постоянно присутствовать в сети, для более эффективного обслуживания клиентских запросов в системе обычно запускается несколько экземпляров сервера. Каждый экземпляр обрабатывает отдельный запрос. Директивы MinSpareServers и MaxSpareServers позволяют задать минимальное и максимальное число экземпляров сервера, не участвующих в обработке запросов. Если число экземпляров сервера меньше, чем значение директивы MinSpareServers, то даже если они не выполняют обработку запросов, главный процесс Apache порождает новые процессы. Аналогично, если число неиспользуемых экземпляров сервера становится больше, чем значение директивы MaxSpareServers, лишние процессы завершаются. Если значения этих директив слишком малы, то в моменты интенсивных обращений к серверу время, необходимое для получения ответа на запрос, будет увеличиваться. Если же значения директив окажутся слишком большими, то памяти компьютера может оказаться недостаточно для размещения процессов сервера. При установке сервера по умолчанию задаются значения 5 и 10. Если нагрузка на сервер небольшая, вы можете уменьшить значения MinSpareServers и MaxSpareServers и проверить, как система отреагирует на это. Если же клиенты часто обращаются к серверу, вам, возможно, потребуются более высокие значения данных директив. Заметьте, что в некоторый момент времени общее число процессов Apache может превысить значение MaxSpareServers, так как некоторые из них заняты обработкой запросов клиентов и не рассматриваются как свободные. Если количество запросов к серверу велико, для поддержки всех экземпляров сервера может потребоваться большой объем области подкачки. При больших значениях MaxSpareServers требования к памяти, а следовательно, и к объему области подкачки еще более возрастают.

* MaxClients. Данная директива задает максимальное количество клиентов, которые могут одновременно поддерживать соединение с сервером. По умолчанию задается значение порядка 150. Учитывая трафик, связанный с обращением к вашему серверу, вы можете увеличить или уменьшить его. Если ваш Web-узел пользуется большой популярностью у клиентов и вы задали неоправданно большое значение MaxClients, это может привести к снижению производительности Apache. Если же значение этой директивы слишком мало, то некоторые клиенты не смогут установить соединение с сервером. Большие значения MaxClients приведут к тому, что при увеличении трафика требования к объему памяти и области подкачки возрастут.

Число соединений, заданное с помощью директивы MaxClients, не то же самое, что число Web-броузеров, поддерживаемых Apache. Каждый Web-броузер может устанавливать несколько соединении с сервером, и все они учитываются при сравнении с MaxClients.

* Listen. По умолчанию сервер Apache принимает обращения через все активные интерфейсы, используя порт с номером 80. Данная директива позволяет изменить номер порта или ограничить число интерфейсов, через которые можно обратиться к серверу. Например, выражение Listen 192 .168 . 34 . 98 : 8080 сообщает Apache, что обращения клиентов должны приниматься только через интерфейс, с которым связан адрес 192.168.34.98 с использованием порта 8080. Выражение Listen 8000 означает, что взаимодействие с клиентами может осуществляться через все интерфейсы посредством порта с номером 8000.

* BindAddress. Если компьютер, на котором выполняется сервер Apache, содержит несколько сетевых интерфейсов, то, используя данную директиву, вы можете связать Apache лишь с одним из интерфейсов. Например, если в конфигурационном файле задано выражение BindAddress 192 .168 . 34 . 98, сервер будет использовать лишь интерфейс 192.168.34.98. При установке Apache в конфигурационный файл включается выражение BindAddress *, посредством которого Apache связывается со всеми интерфейсами.

СОВЕТ Если вы хотите, чтобы сервер принимал обращения только с локального компьютера, вам надо задать опцию BindAddress 127 . 0 . 0 .1. При этом взаимодействие с другими компьютерами поддерживаться не будет. Для обращения к локальному серверу можно использовать URL http: //127 . 0 . 0 .1 или http://localhost.

* Port. Данная директива указывает Apache, какой порт должен использоваться для взаимодействия с клиентами. По умолчанию принимается номер порта 80.

* ServerAdmin. С помощью данной директивы вы можете указать свой почтовый адрес. По умолчанию в конфигурационном файле задается адрес webmaster. Создав соответствующий псевдоним в конфигурационном файле сервера SMTP, вы перенаправите письма, приходящие от пользователей на свой адрес. В обычных условиях адрес, указанный в качестве значения данной директивы, не предоставляется пользователям, но он возвращается в составе некоторых сообщений об ошибке.

* ServerName. Если значение данной директивы отличается от имени вашего компьютера, вы можете устранить это несоответствие, указав правильное значение.

* DefaultType. Если Apache не может определить MIME-тип данных ни на основании расширения файла, ни с помощью "магической" последовательности, он возвращает MIME-тип, указанный в качестве значения данной директивы. Обычно это text/plain, но при необходимости вы можете задать другое значение. Изменять Def aultType имеет смысл в том случае, если на Web-узле находится много файлов, содержащих данные определенного типа, и есть опасность, что MIME-тип некоторых файлов не будет распознан.

* HostnameLookups. Данная директива может принимать значение On или Off. Если задано значение On, Apache будет преобразовывать адреса клиентов, обращающихся к серверу, в доменные имена и записывать их в файл протокола. Это упрощает анализ информации, содержащейся в файле. Однако преобразование адреса занимает дополнительное время и сетевые ресурсы, поэтому системные администраторы часто отказываются от такой возможности.

* LogLevel. Сервер Apache записывает информацию о своих действиях в файл протокола. Объем этой информации вы можете указывать, задавая значение debug,

info, notice, warn, error, crit, alert или emergдирективы LogLevel.

(Здесь значения директивы перечислены в порядке убывания объема данных, записываемых в файл протокола.) По умолчанию используется значение warn.

* Customing. Для данной директивы задаются два значения: имя файла протокола и формат информации, записываемой в этот файл. В данном случае речь идет о файле протокола, в который помещаются сведения о клиентах, обращающихся к серверу за получением Web-страниц. Формат может быть задан с помощью ключевых слов common, agent, refere r и combined. Для обеспечения большей степени гибкости в конфигурационном файле httpd.conf предусмотрены средства, позволяющие администратору определить собственный формат записи данных. Чтобы создать несколько файлов протоколов, надо включить в конфигурационный файл несколько директив CustomLog.

Помимо опций общего назначения, описанных выше, в файле httpd.conf содержатся также дополнительные опции. Многие из них не будут рассматриваться в данной книге. Если вам потребуется более подробная информация о настройке сервера, обратитесь к документации по Apache или к книгам, посвященным данному продукту.

Описание каталогов

В состав URL входит от двух до четырех компонентов.

* Протокол. Первый компонент URL (например,http: // или!: tp: //) определяет протокол, используемый для взаимодействия. В данной главе в основном обсуждаются серверы, поддерживающие протокол HTTP (в этом случае URL начинается с символов http: //). Для обращения к защищенным узлам используются URL, начинающиеся с https : //.

* Имя узла. Имя узла, входящее в состав URL, представляет собой доменное имя компьютера, на котором выполняется Web-сервер. Например, в URL http:// www.threeroomco.com/thepage/index.html именем узла является www. threeroomco. com. (Одному компьютеру может соответствовать несколько доменных имен. Такая ситуация возникает в том случае, если в конфигурационном файле сервера DNS для этого компьютера задано несколько записей А или CNAME. (Настройка сервера DNS описывались в главе 18.)

* Имя файла. В большинстве случаев HTTP-запрос предполагает передачу файла. В составе URL за именем узла следует имя файла (с указанием имени каталога). Например, в URL http://www.threeroomco.com/thepage/index. html ссылкой на файл является компонент thepage/index. html. Несмотря на то что имя файла отделяется от имени узла косой чертой, этот символ не является обозначением корневого каталога системы Linux. Путь к файлу йачинается от корневого каталога документов, определенного для Web-узла. Если имя файла в составе URL не указано, сервер возвращает клиенту Web-страницу по умолчанию, заданную с помощью директивы Directorylndex.

* Дополнительная информация. Некоторые URL содержат дополнительную информацию. Например, позиции в составе Web-документа может быть присвоено имя. Это имя указывается в URL после имени файла и отделяется от него символом #.

URL, в начале которого указан протокол FTP, может содержать пользовательское имя и пароль.

В конфигурационном файле Apache содержится несколько опций, которые позволяют указывать каталоги для хранения файлов, предназначенных для обработки Web-сервером. Если вы некорректно зададите значения этих опций, некоторые из Web-страниц станут не доступны. Директивы, описывающие каталоги, перечислены ниже.

* ServerRoot. С помощью этой директивы задается корень поддерева файловой системы, используемого для хранения двоичных файлов Apache. В большинстве случаев при инсталляции сервера устанавливается значение "/usг" этой опции. Изменять его не следует.

* DocumentRoot. В каталоге, указанном с помощью этой директивы, хранятся .файлы, содержащие статические Web-страницы. По умолчанию для данной опции задается "/home/httpd/html" или другое подобное значение. (В файле httpd. conf имя каталога обычно помещается в кавычки.)

ВНИМАНИЕ Значение директивы DocumentRoot не следует завершать косой чертой. ¦ Несмотря на то что в системе Linux такая ссылка на каталог является корректной, для Apache она приведет к возникновению ошибки.

* UserDir. Если первый из каталогов, предшествующих имени файла в составе URL, начинается с символа , Apache интерпретирует его имя как имя пользователя и старается найти файл в рабочем каталоге соответствующего пользователя. Директива UserDir указывает имя подкаталога, в котором следует искать файл. Предположим, что для данной директивы задано значение public_html и удаленный пользователь ввел в поле адреса броузера URL http: //www. threeroomco. compilation/~abrown/photos. html. Тогда Apache попытается вернуть пользователю файл photos .html, расположенный в подкаталоге public_htraL рабочего каталога пользователя abrown. Если задано значение disabled данной директивы, обращение к файлам, находящимся в рабочих каталогах пользователей, запрещено. Если вы хотите запретить доступ лишь к части пользовательских каталогов, вам надо после ключевого слова disabled указать имена пользователей, рабочие каталоги которых закрыты для обращения. Данная директива часто помещается в состав директивы <IfModule>, которая проверяет, загружен ли модуль Apache, предназначенный для поддержки пользовательских каталогов. (Модули Apache будут рассматриваться в следующем разделе.)

* Directorylndex. Некоторые URL не содержат имя файла; в них указано лишь имя каталога (в некоторых случаях оно завершается косой чертой). Когда сервер Apache получает подобный URL, он сначала старается найти файл индекса, имя которого задается с помощью директивы Directorylndex. В большинстве случаев по умолчанию принимается имя index.html, установленное в качестве значения данной опции при инсталляции сервера. При необходимости вы можете задать другое имя файла. Если пользователь введет URL http: //www. threeroomco. com/public/, Apache вернет файл index.html, находящийся в подкаталоге

' public каталога, указанного с помощью директивы DocumentRoot. Если вы укажете несколько файлов индекса, Apache станет поочередно искать все файлы.

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

Загрузка модулей Apache

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

Просмотрев содержимое конфигурационного файла httpd. conf, вы найдете в нем ссылки на модули, формируемые посредством директивы LoadModule. Пример подобной ссылки приведен ниже.

LoadModule mime_module lib/apache/mod_mime. so

В качестве значения данной директивы задается внутреннее имя модуля (в данном примере mime_module) и имя файла, в котором содержится сам модуль (lib/apache/ mod_mime. so). В данном случае имя файла указывается относительно каталога, заданного посредством директивы ServerRoot, но при желании вы можете указать полный путь.

Модули, которые используются часто, можно непосредственно встраивать в двоичные файлы Apache. Чтобы определить, какие модули уже содержатся в исполняемых файлах, надо задать команду httpd -1 (или apache -1). В некоторых случаях модули, встроенные в состав Apache или загруженные посредством LoadModule, необходимо активизировать, включив для этого в конфигурационный файл директиву AddModule.

AddModule mod_mime.c

В качестве значения директивы AddModule задается имя файла с исходным кодом модуля. Для важных модулей в конфигурационном файле Apache содержится как директива LoadModule, так и директива AddModule.

Как правило, администраторам не приходится включать новые модули; стандартная конфигурация Apache позволяет решать большинство задач, связанных с организацией функционирования Web-узла. Более того, чтобы уменьшить риск незаконного проникновения в систему, иногда приходится исключать некоторые модули. Удаляя модули, следует соблюдать осторожность, так как, не зная структуры Apache, нельзя заранее сказать, как отсутствие некоторых из них повлияет на работоспособность сервера.

Если Apache не может выполнить необходимые вам действия, следует прочитать описания модулей и решить, какой из них пригоден для решения этой задачи. Дополнительную информацию о доступных модулях можно получить на Web-узле Apache Module Register по адресу http: //modules . apache. org. Выполнив поиск по ключевым словам, вы получите информацию о модулях, созданных сторонними организациями, и адреса Web-узлов этих организаций.

Настройка kHTTPd

В системах, подобных UNIX, и, в частности, в Linux, можно выделить два типа процессов: процессы ядра (kernel space processes) и пользовательские процессы (user space processes). Процесс ядра запускается очень быстро, а для запуска пользовательского процесса требуется относительно много времени, кроме того, пользовательский процесс часто должен осуществлять обмен важными данными с ядром. На практике такая особенность пользовательских процессов приводит к возникновению проблем, так как основная обработка информации осуществляется в пространстве пользовательского процесса. Задержка, связанная с запуском процесса, оправдывается повышением уровня безопасности и стабильности. Процессы ядра пользуются привилегиями при взаимодействии с аппаратными средствами, файловой системой и другими ресурсами, поэтому ошибка в программе или несанкционированное вмешательство извне могут привести к разрушению системы.

Пытаясь найти способы увеличения производительности, специалисты заметили, что, несмотря на то, что Web-сервер представляет собой пользовательский процесс, большая часть его функций выполняется процессами ядра, в результате работа сервера в основном представляет собой последовательность обращений к ядру. На рис. 20.1 условно показано взаимодействие Web-сервера (в качестве примера которого выбран сервер Apache) с ядром. Реально обмен с ядром происходит гораздо сложнее, чем показано на рисунке, например, для чтения файла и передачи данных по сети необходимо выполнить целый ряд операций. При этом расходуется время процессора, память и другие ресурсы.

Для того чтобы оптимизировать обслуживание HTTP-запросов, были созданы простые Web-серверы, выполняющиеся как процессы ядра. В результате исчезла необходимость постоянного взаимодействия ядра и пользовательского процесса, и скорость обработки запросов клиента существенно увеличилась. Начиная с версии 2.4.x в состав ядра входят компоненты, реализующие Web-сервер kHTTPd. Подробная информация о таких компонентах находится по адресу http://www.fenrus.demon.nl. Настройка сервера, выполняющегося в виде пользовательского процесса, осуществляется путем записи данных в конфигурационные файлы, находящиеся в каталоге /proc/sys/net/khttpd.

Для того чтобы обеспечить работу такого сервера, необходимо предпринять следующие действия.

1. Включите поддержку kHTTPd при конфигурации ядра Linux. Для этого используется опция Kernel HTTPd Acceleration, находящаяся в меню Networking Options. Вы можете сформировать требуемый компонент в виде модуля или непосредственно включить его в состав ядра.

2. Измените конфигурацию Apache так, чтобы этот сервер использовал для приема обращений клиентов порт 8080 или любой другой, отличный от порта 80.

3. Перезагрузите систему или загрузите модуль ядра kHTTPd. В зависимости от конфигурации он либо загрузится автоматически, либо вам придется использовать команду insmod khttpd.

4. Укажите серверу kHTTPd на то, что он должен принимать запросы клиентов через порт 80. Для этого надо выполнить команду echo 80 > /proc/sys/net/ khttpd/serverport.

5. Введите команду echo 8080 > /proc/sys/net/clientport. В результате ее выполнения kHTTPd будет передавать запросы, которые не может обработать самостоятельно, серверу Apache, используя порт 8080. (Если на шаге 2 вы указали порт, отличный от 8080, то должны задать тот же порт в составе данной команды.)

6. Сообщите kHTTPd,'в каком каталоге следует искать незакодированные статические файлы. Для этого выполните команду echo /home/httpd/html > /proc/sys/net/khttpd/documentroot. Вместо каталога /home/httpd/html вы можете указать другой каталог, следите лишь за тем, чтобы он совпадал с каталогом, который был задан в файле httpd.confв качестве значения директивы DocumentRoot.

7. Если на вашем Web-узле содержатся РНРЗ или защищенные HTML-документы, повторите предыдущее действие, но поместите имя каталога в файл /proc/sys/ net/khttpd/dynamic.

8. Введите команду echo 1 > /proc/sys/net/khttpd/start, в результате которой сервер kHTTPd начнет работу. Указанный здесь файл является своеобразным аналогом сценария запуска SysV.

При желании вы можете создать сценарий SysV или локальный сценарий, который автоматизировал бы выполнение этапов 4-8 описанной выше процедуры. Независимо от того, будет ли сервер запущен вручную или с помощью сценария, он будет поддерживать простые запросы, предполагающие передачу клиентам статических файлов, находящихся в указанном каталоге. Запрос который не может быть обработан средствами kHTTPd (например, запрос, предполагающий запуск CGI-сценария), будет передан Web-серверу, выполняющемуся как пользовательский процесс. При этом будет использован номер порта, указанный на этапах 2 и 5. Такая передача запроса связана с большими накладными расходами, поэтому если Web-узел предполагает в основном выполнение CGI-сценариев, использовать для его поддержки сервер kHTTPd нецелесообразно. Более того, применять kHTTPd имеет смысл только в том случае, если сервер Apache не справляется с нагрузкой.

Если же интенсивность обращений к серверу не велика, предпочтительнее использовать один из серверов, выполняющихся как пользовательский процесс. Следует также помнить, что kHTTPd официально считается экспериментальным продуктом, поэтому он не может обеспечить такой надежности, как Apache или другие подобные серверы. Поскольку kHTTPd выполняется как процесс ядра, ошибка в программе может нанести системе гораздо больше вреда, чем ошибка в сервере, выполняющемся как пользовательский процесс. Таким образом, если у вас нет веских оснований применять kHTTPd, лучше использовать вместо него хорошо отлаженный и зарекомендовавший себя в работе сервер Apache.

Сервер kHTTPd - не единственный продукт подобного типа, реализованный как процесс ядра. В системе Red Hat применяется сервер TUX, кроме того, в настоящее время ведется работа над созданием других серверов, предназначенных для выполнения в виде процессов ядра Linux.

Поддержка форм и сценариев

Несмотря на то что статические данные часто используются на Web-узлах, типы информации, с которыми может работать Web-сервер, не исчерпываются ими. Многие Web-серверы динамически генерируют Web-страницы. Например, поисковые серверы позволяют пользователю ввести данные в поле редактирования и передать их после щелчка на кнопке, а затем формируют Web-страницу, содержащую результаты поиска. Если вы хотите создать Web-узел, выполняющий подобные действия, вам надо уметь сконфигурировать его соответствующим образом. В этом разделе будут кратко рассмотрены принципы динамического создания Web-страниц и опции Apache, используемые для активизации соответствующих средств сервера. Чтобы получить более подробную информацию, обратитесь к документам, в которых описаны эти вопросы.

Статические данные, формы и CGI-сценарии

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

* HTML-файлы. В настоящее время основная часть данных в Internet представлена в формате HTML (Hypertext Markup Language - язык разметки гипертекста). HTML-файлы имеют расширение . htm либо . html и содержат текстовую информацию с элементами разметки. Элементы разметки выполняют форматирование текста. Например, элемент <Р> помечает начало абзаца, а </Р> - конец абзаца. В языке HTML также предусмотрена возможность связывания Web-страниц с другими документами, расположенными в Internet (в частности, в Web). Такое связывание осуществляется посредством гипертекстовых ссылок. После щелчка на гипертекстовой ссылке ресурс, на который она указывает, автоматически воспроизводится либо сохраняется на диске. Конкретные действия по обработке ресурса зависят от настройки Web-броузера.

* Текстовые файлы. Файлы такого типа чаще всего имеют расширение . txt. Текстовые файлы, которые Web-серверы предоставляют пользователям, отображаются броузерами, но элементы форматирования и гипертекстовые ссылки в них отсутствуют.

* Графические файлы. Почти все HTML-документы содержат ссылки на графические файлы, представленные в различных форматах. Эти файлы также являются статическими. Некоторые файлы содержат анимационные данные, но несмотря на это, они все же считаются статическими файлами. Термин статический относится к содержимому файла, а не к способу его отображения.

* Документы в различных форматах. Иногда на Web-страницах содержатся ссылки на файлы PDF, Microsoft Word, архивы . zip и . tar, а также данные, представленные в других форматах. Некоторые броузеры передают эти файлы для обработки соответствующим приложениям, другие сохраняют их на диске.

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

При обработке динамических данных информация передается как от сервера клиенту, так и от клиента серверу. Работая в Internet, вы наверняка встречались с динамическими данными. Соответствующие примеры приведены ниже.

* Поисковые серверы. Если вы укажете в поле адреса броузера URL поискового сервера, этот сервер предоставит Web-страницу, содержащую форму ввода. Форма позволяет вводить данные (в случае поискового сервера - ключевые слова). После щелчка на кнопке Search (или при активизации другого интерактивного элемента, запускающего процедуру поиска) введенные вами ключевые слова передаются Web-серверу, который осуществляет поиск и создает Web-страницу для представления результатов.

* Internet-магазин. При посещении узла электронной коммерции, или Internet-магазина, Web-сервер предоставляет вам возможность выбрать в интерактивном режиме товар и поместить его в "корзинку" покупателя. В процессе обмена данными между Web-сервером и Web-броузером сервер предоставляет броузеру информацию о товарах, а броузер передает серверу ваш адрес, номер платежной карточки и другие необходимые данные, а также подтверждает факт покупки. Особенности взаимодействия зависят от реализации конкретного Web-узла, но в любом случае Web-сервер динамически формирует Web-страницу, а Web-броузер передает серверу информацию, введенную пользователем.

* Web-узлы, настраиваемые с учетом интересов пользователей. Некоторые Web-узлы предоставляют пользователям специальные средства регистрации и передают данные, специально сформированные для этого пользователя. Например, обратившись на узел Slashdot (http://slashdot.org), вы можете зарегистрироваться и указать при регистрации тип и объем интересующих вас данных. При работе с подобными Web-узлами на стороне клиента создается запись cookie, которая иденти-фицирует клиент при последующих обращениях. (Записи cookie часто создаются и при взаимодействии с серверами электронной коммерции.)

Приведенные выше примеры представляют лишь частные случаи применения динамических Web-узлов. Возможности подобных узлов ограничены лишь воображением разработчиков и их готовностью реализовать свои планы. С точки зрения Web-сервера основное различие между динамическими и статическими Web-узлами состоит в том, что на динамическом узле HTML-документ (или документ в другом формате) создается в процессе работы сервера на основании данных, полученных от клиента. Для реализации динамических Web-узлов используются следующие средства.