У истоков Apache. Часть 4: История и обзор архитектуры (часть 2)

Apache имеет многозадачную архитектуру, что достаточно стабильно, но имеет определенные ограничения. По умолчанию в Apache принята модель, в которой главный процесс создает дочерние на основе fork(). Для распределения запросов между дочерними процессами используются мьютексы. Multi Processing Modules (MPM), которые появились во втором Apache, позволяют эффективно использовать возможности конкретной операционной системы. Ключевым программным циклом является цикл обработки клиентского запроса. Управление памятью построено на основе пулов. Во второй версии Apache появились новые возможности, такие как фильтры, многопоточность и т. д.

Сергей Яковлев, Консультант, независимый специалист

Яковлев Сергей — независимый разработчик с многолетним опытом прикладного и системного программирования; вносит вклад в развитие open-source на своем персональном сайте www.iakovlev.org. Консультант.



27.01.2011

1. Исходные дистрибутивы

Дистрибутив исходных текстов первого Apache включает 780 файлов в 44 каталогах, 235 файлов состоят из кода на C. Следующий рисунок показывает структуру директорий этого дистрибутива. Каталог src включает исходники большинства модулей. Главные каталоги в этом дереве — main и modules.

Структура директорий второго Apache 1

Кликните, чтобы увидеть увеличенное изображение

Следующий рисунок показывает структуру директорий второго Apache. Дерево исходников становится еще больше по сравнению с первым Apache. Это дерево включает 2165 файлов в 183 каталогах. 704 файла состоят из кода на C (280 000 строк). Ядро расположено в каталоге server, появился каталог mpm, модули по-прежнему расположены в каталоге modules.

Структура директорий второго Apache 2

2. Многозадачная архитектура

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

Главный процесс веб-сервера, который ожидает входящие запросы, называется master server process. Когда приходит запрос от клиента, основной процесс устанавливает коннект и порождает (fork) т. н. child server process, после чего отдает управление процессом обработки этого запроса вновь созданному дочернему процессу.

Архитектура Apache основана на пуле задач. Во время старта порождается пул задач, каждому пришедшему клиентскому запросу присваивается задача из этого пула. Контролирует этот пул процесс master server. Это классический для unix-систем вариант preforking architecture. Причем пул может состоять не только из процессов, но и из потоков (thread). После установки коннекта запрос передается в пул, все права на коннект передаются дочернему процессу, который после завершения обработки запроса закрывает этот коннект. После этого дочерний процесс засыпает на время в очереди себе подобных, становится idle до тех пор, пока не получит новый запрос.

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

На следующем рисунке показана Preforking-архитектура второго Apache, которая аналогична архитектуре первого Apache. Существенным отличием второй версии от первой является механизм управления дочерним процессом, а точнее его перезапуском — теперь это делается на основе пайпов (вместо сигнала в первой версии).

Preforking-архитектура Apache 2

В этой архитектуре можно выделить несколько основных рабочих циклов:

  1. Начальная инициализация: происходит выделение ресурсов, читается конфигурация, запускается демон.
  2. Рестартовый цикл: перечитывается конфигурация, создается пул задач, передача управления master-server циклу.
  3. master-server цикл: контроль дочерних процессов.
  4. request-response цикл: ожидание места в очереди, получение коннекта, переход в рабочий статус и keep-alive цикл.
  5. keep-alive цикл: обработка запроса.
  6. Очистка и деактивация дочернего процесса.

3. Инициализация и рестарт

Второй Apache стартует в главной процедуре main(). После входа в Restart-цикл выполняется конфигурация MPM с помощью ap_mpm_run(). На следующем рисунке выполняется последовательность действий:

  1. Создание статических пулов.
  2. Регистрируется информация о модулях.
  3. Читаются командные параметры. Например, параметр -X блокирует создание дочерних процессов.
  4. Читается конфигурация, которой существует два вида — per-server и per-request, вторая лежит в .htaccess.
  5. detach process: после чтения конфигов и инициализации модулей сервер переходит в режим демона, при этом происходят стандартные вещи: создается копия главного серверного процесса, родитель при этом завершает работу, консоль отключается и т. д.
Конфигурация MPM с помощью ap_mpm_run()

Каждый раз, когда администратор перезапускает Apache, запускается restart-цикл в функции main(). В первом Apache restart-цикл лежит в процедуре standalone_main(). Этот цикл состоит из следующих частей:

  1. Инициализация и подготовка ресурсов для создания дочерних процессов, чтение конфигурации.
  2. Генерация дочерних процессов.
  3. Переход в master server цикл, затем в Request-Response цикл.

Конфигурация читается главным процессом. Дочерние процессы получают свою конфигурацию от главного процесса. Дочерний процесс сам изменяет свой статус в scoreboard.

Последовательность действий в restart-цикле:

  1. Чтение конфигурации — в этот момент существует только один главный процесс.
  2. Инициализация сокетов для прослушивания. Apache может слушать несколько портов.
  3. Инициализируется scoreboard.
  4. one_process_mode — может быть использован для дебага.
  5. Создаются дочерние процессы с помощью процедуры startup_children(), которые регистрируются в scoreboard. Используется системный вызов fork(). Они получают ссылки от главного процесса на конфигурацию, сокеты, лог-файлы и т.д. В scoreboard для каждого дочернего процесса пишется его не привилегированный пользовательский id.
  6. Главный процесс попадает в matser server цикл.
  7. matser server цикл: регулируется общее число дочерних процессов путем добавления/удаления.
  8. Каждый раз при попадании в restart-цикл увеличивается счетчик под названием generation ID. Каждому дочернему процессу присваивается этот id. Если generation ID дочернего процесса в scoreboard не совпадает с текущим generation ID, этот дочерний процесс удаляется из scoreboard.

4. Сигналы

Контроль в Apache построен на сигналах. Сигнал представляет собой прерывание, которое может произойти в любой момент. При этом программа приостанавливается, начинается обработка сигналов, после чего программе возвращается управление. Администратор может послать сигнал kill из командной строки.

Apache реагирует на 3 сигнала:

  1. SIGTERM — остановка сервера (shutdown_pending).
  2. SIGHUP — перезапуск сервера (restart_pending и graceful_mode).
  3. SIGUSR1 — gracefull рестарт, при котором работающие дочерние процессы не убиваются.

Обработчик сигнала для главного процесса регистрируется в процедурах set_signals(), sig_term() и restart(). Если администратор останавливает или перезапускает сервер, главный процесс посылает соответствующий сигнал группе дочерних процессов и получает от них уведомления.

gracefull рестарт различается в первой и второй версиях Apache. В первом случае дочерним процессам отсылается сигнал SIGUSR1, во втором используются именованные каналы — Pipe of Death. В обоих вариантах при этом будут закрыты дочерние процессы, которые стоят в очереди в ожидании клиентских запросов, а те дочерние процессы, которые окажутся заняты в данный момент обработкой, будут продолжать работать.


5. Цикл Master server

На следующем рисунке показано, как главный процесс контролирует дочерние процессы и что происходит при перезапуске сервера.

Цикл Master server

Restart-цикл находится в процедуре main(). Цикл Master server для Apache 2 находится в ap_mpm_run(), для первого — в процедуре standalone_main() (http_main.c). Верхняя часть картинки описывает graceful restart. В нижней части описано управление т. н. дочерними idle-процессами, которые ничем не заняты и стоят в ожидании. Их число хранится в переменной idle_count, ограничение задается в конфигурации переменными ap_daemons_max_free и ap_daemons_min_free. В случае превышения процесс уничтожается. Если их мало, idle-процесс создается.

Если администратор выполняет Graceful Restart, при этом происходят следующие события:

  1. Переменная remaining_children_to_start хранит число дочерних процессов, которые должны быть запущены после рестарта. Делая системный вызов wait(), главный процесс контролирует удаление idle-процессов. Он используется для остановки процессов, созданных с помощью fork(). Вызов wait() длится в течение фиксированного тайм-аута, после чего управление возвращается в matser server независимо от того, получено сообщение от дочернего процесса или нет.
  2. Если wait() возвращает pid, то:
    • проверяется process_child_status;
    • в scoreboard ищется дочерний процесс с помощью find_child_by_pid;
    • статус найденного процесса устанавливается в SERVER DEAD;
    • если remaining_children_to_start>0, генерируется новый дочерний процесс.
  3. Если после остановки дочерних процессов remaining_children_to_start !=0, в процедуре startup_children() создаются недостающие дочерние процессы.

В нижней части рисунка описано действие процедуры perform_idle_server_maintenance(), которая может быть вызвана во время работы master server цикла в произвольный момент, например, когда в этом цикле случается тайм-аут. Главный процесс подсчитывает число незанятых — idle — дочерних процессов, контролируя их число на основе трех параметров, полученных из конфигурации:

  • ap_daemons_limit — максимальное число дочерних процессов. Scoreboard состоит из занятых дочерних процессов, свободных дочерних процессов и пустых слотов – slot. В сумме эти три величины должны быть равны ap_daemons_limit;
  • ap_daemons_max_free — максимум свободных дочерних процессов. Если число таких процессов начнет превышать данный максимум, они начнут удаляться по одному за цикл;
  • ap_daemons_min_free — минимум свободных дочерних процессов.

Дочерние процессы создаются с помощью процедуры make_child(). Master server цикл создает один дочерний процесс в первом цикле, во втором цикле создает два дочерних процесса, в третьем — три, и т. д. Это число создаваемых процессов в каждом цикле хранится в переменной idle_spawn_rate.

Пример: Допустим, переменная ap_daemons_min_free = 5. В какой-то момент выясняется, что остался один idle-процесс. Мастер сервер сразу же начинает их создавать и в первом цикле создает один дочерний процесс. В следующем цикле он создает еще два idle-процесса. После этого приходит запрос от клиента, после чего остается 3 idle-процесса. Главный процесс обнаруживает этот факт и в следующем цикле создает еще 4 idle-процесса. После чего выясняется, что число idle стало равно 7, и тогда переменная idle_spawn_rate опять становится равной 1.


6. Child server

Главный процесс создает дочерние на основе fork(). У каждого такого процесса своя собственная память, куда никто не имеет доступа. Поэтому конфигурация читается главным процессом, и потом под нее выделяется глобальная область памяти, которая доступна всем дочерним процессам. Поскольку каждый дочерний процесс представляет собой клон главного процесса, у них у всех есть общая память с единой конфигурацией.

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

Инициализация дочернего процесса происходит в процедуре child_main():

  1. Устанавливается доступ к ресурсам. Поскольку в момент создания дочерний процесс имеет те же привилегии, что и главный процесс, он получает доступ к ресурсам:
    • локальная память — ap_make_sub_pool();
    • scoreboard;
    • accept mutex.
  2. Инициализация модулей — процедура ap_init_child_modules().
  3. Инициализируются таймауты. Таймаут необходим для того, чтобы дочерний процесс не блокировал главный процесс. Apache использует т.н. alarm — аналог сигнала. С помощью этого сигнала устанавливается таймаут, в течение которого главный процесс ждет отклика от дочернего процесса, по истечении которого происходит т.н. long jump обратно.
  4. Дочерний процесс имеет свой главный цикл, внутри которого происходит обнуление таймаутов, очистка пула запросов.
  5. Дочерний процесс выставляет для себя статус «готов» в соответствующем лоте scoreboard, и на этом инициализация заканчивается.

Apache использует accept mutex для распределения поступающих клиентских запросов между дочерними процессами. Этот мьютекс делает активным в текущий момент на прослушке коннектов только один дочерний процесс с помощью системного вызова accept() и представляет собой контроль доступа к TCP/IP. Для его инициализации сначала вызывается процедура accept_mutex_on() / accept_mutex_off(). После того, как дочерний процесс получает коннект, он начинает обрабатывать клиентский запрос, а на прослушуку становится другой дочерний процесс — в теории это называется Leader-Follower pattern. Кроссплатформенная обработка, зависящая от специфики конкретной операционной системы, реализована на основе MPM.


7. MPM

Во втором Apache появились новая отличительная архитектурная особенность — модули типа Multi Processing Modules (MPM). Структура такого модуля похожа на стандартную, в частности, он включает таблицу команд. MPM отвечает за запуск потоков или процессов — в зависимости от варианта. MPM также отвечает за прослушивание сокетов. Когда приходит несколько запросов, MPM распределяет их между потоками либо процессами. После чего в дело идут стандартные процедуры по обработке запросов.

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

Apache может более аккуратно и эффективно работать в самых разных операционных системах. В частности, версия Apache для Windows теперь работает намного более эффективно, благодаря тому, что МП-модуль mpm_winnt может использовать собственные сетевые функции Windows взамен сетевых функций уровня POSIX. Это касается и других операционных систем, для которых разработаны специальные МП-модули.

Сервер может быть настроен более оптимально для нужд конкретного сайта. Например, для сайтов, требующих значительной масштабируемости, может быть выбран многопоточный МП-модуль, такой как worker, а для сайтов, требующих большей стабильности или совместимости со старым ПО, может быть использован prefork. Кроме того, также предоставляются специальные возможности, такие как обслуживание различных хостов процессами с привилегиями различных пользователей (perchild).

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

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

Чтобы подключить желаемый МП-модуль к Apache, используйте аргумент --with-mpm=MPM скрипта configure, где MPM — это название желаемого МП-модуля. После того, как сервер скомпилирован, всегда можно определить, какой МП-модуль был выбран, используя команду ./httpd -l, которая выведет список всех модулей, собранных вместе с сервером, в том числе и название МП-модуля. Если вы на этапе компиляции явно не указали другой МП-модуль, то по умолчанию в unix будет установлен prefork МП-модуль, в windows — mpm_winnt.

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

Разные процессы могут общаться друг с другом с помощью глобальной памяти, сигналов или событий, семафоров, мьютексов, каналов, сокетов. MPM использует для этого пул задач — task pool. idle процессы спят до тех пор, пока не приходит новый клиентский запрос и из этой очереди не выдергивается один для обработки этого запроса.

Для этого, в зависимости от платформы, может быть использована условная переменная либо семафор.

Apache включает несколько вариантов многозадачности. Первый Apache имеет 2 варианта:

  1. Preforking Architecture для Unix.
  2. Job Queue Architecture для Windows.

Второй Apache включает 4 варианта MPM, при компиляции можно выбрать какой-то один конкретный вариант:

  1. Preforking / Netware — используется архитектура первого Apache.
  2. WinNT — виндовый вариант с использованием IOCP.
  3. Worker — новая комбинация из процессов и потоков.
  4. Leader / PerChild — линуксовый вариант, альтернатива для первого и третьего вариантов.

3-й вариант — Worker — использует комбинацию из процессов и потоков.

Процесс может включать несколько потоков (thread). Дочерний процесс теперь становится более сложно организован. Главный процесс создает один дочерний процесс. Этот дочерний процесс запускает стартовый поток. Этот стартовый поток запускает рабочие потоки и один слушающий поток. Общение между слушающим потоком и рабочими потоками сделано на основе двух очередей — job queue и idle queue. В зависимости от статуса поток может быть помещен в одну из этих очередей слушающим потоком. В этом варианте используется стабильность многопроцессной модели с производительностью многопоточной модели.


8. Обработка запроса

Рабочий цикл Request-Response является узловым во всем сервере. Каждый дочерний процесс имеет такой цикл, который заканчивается после завершения обработки клиентского запроса либо по просьбе главного процесса.

В зависимости от архитектуры право на обработку может получить свободный idle процесс либо тот, который находится в рабочей очереди. В первом случае он проснется по мьютексу, во втором его включит job queue. После того, как дочерний процесс получает запрос, он покидает пределы MPM, передав управление обработчикам (хукам — hook) pre_connection b process_connection. Модуль http_core.c регистрирует обработчик p_process_http_connection().

Клиент может использовать повторно существующий коннект для повторных запросов. Например, HTML документ с 5 картинками может быть получен в серии из 6 отдельных запросов в одном и том же коннекте. TCP коннект обычно закрывается по таймауту, равному 15 секундам. Модуль http_core.c регистрирует обработчик ap_process_http_connection() с keep-alive циклом внутри. Пул запросов очищается каждый раз после завершения keep-alive цикла. Дочерний процесс читает заголовок запроса с помощью процедуры ap_read_request() (protocol.c.) и результат чтения сохраняет в структуре request_rec. После того, как заголовок прочитан, статус дочернего процесса меняется на busy_write — т.е. пришло время отправлять ответ клиенту. Второй Apache отличается от первого тем, что ответ клиенту могут формировать различные модули, в то время как в первом этим занимается только один обработчик контента. Процедура p_process_request (http_request.c ) вызывает другую процедуру — process_request_internal (request.c), в которой происходит следующее:

  1. Модифицируется url процедурами ap_unescape_URL, ap_getparents.
  2. Читается конфигурация — location_walk().
  3. URL переводится в локальный url — ap_translate_name().
  4. Вызываются ap_directory_walk и ap_file_walk.

Могут выполниться 2 независимые проверки авторизации — одна на основе клиентского IP, вторая на основе проверки авторизации пользователя. В файлах конфигурации можно выставить контроль доступа по пользователям, группам, ip и т.д. При этом могут сработать следующие обработчики:

  1. access_checker — проверка IP.
  2. ap_check_user_id — проверка аутентификации.
  3. auth_checker — проверка авторизации.
  4. type_checker — получение MIME type запрашиваемого ресурса.
  5. fixups — любой модуль может писать в заголовок ответа клиенту.
  6. insert_filter — любой модуль может добавить фильтр.
  7. handler — формируется заголовок и тело ответа. Может быть подключен CGI-модуль для генерации контента. Результирующий ответ пропускается через фильтры.
  8. ap_finalize_request_protocol() — отсылается ответ клиенту в требуемой кодировке.

9. Конфигурационный процессор

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

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

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

На следующем рисунке показаны конфигурационные структуры данных в подробностях.

Конфигурационные структуры Apache

Каждый виртуальный хост имеет подобную структуру данных, представленную в списке server_recs, в которой есть 2 указателя — module_config и lookup_defaults — на структуры данных, которые определяются в соответствующих модулях. Указатель sec (секция) указывает на конкретную секцию конкретной виртуальной директории в конфиг-файле. Каждый модуль имеет возможность построить свою структуру данных для такой секции. lookup_defaults указывает на файловую структуру секции.

Процедура process_command_config читает командную строку, process_resource_config — глобальные конфигурационные данные. Эти данные обрабатываются внутри ap_srm_command_loop, здесь происходит управление прочитанных директив, которое выполняется модульными обработчиками. ap_read_config() вызывает процедуры process_command_config() и ap_process_resource_config(). Процедура process_command_config() обрабатывает командную строку. Процедура ap_process_resource_config() обрабатывает главные конфигурационные файлы.

Когда дочерний процесс начинает обрабатывать клиентский запрос, вызывается процедура process_request_internal(), в которой происходит трансляция URL, после чего вызывается процедура directory_walk(). Они проверяют уже созданные структуры данных на предмет нужного файла. Схема работы directory_walk показана на следующем рисунке:

Схема работы directory_walk

Кликните, чтобы увидеть увеличенное изображение

Вся иерархическая структура директории просматривается сверху вниз. Вначале создается объект структуры per_dir_defaults. На рисунке показан разбор URL, имя которого может включать несколько подкаталогов, разделенных слешами. URL берется из request_rec, парсится структура sec_url.


10. Управление памятью

Механизм управления памятью в Apache построен на пулах (pool). В пуле ведется учет всех выделенных ресурсов, пул может управлять памятью, сокетами, процессами.

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

Когда пул программно удаляется, автоматически очищаются все ресурсы, выделенные под него. Пулы также улучшают производительность.

Apache имеет несколько пулов на разные случаи жизни. Следующий рисунок показывает иерархию пулов.

Иерархия пулов Apache

Пул pglobal существует на протяжении всей жизни сервера. Пул pchild имеет время жизни одного дочернего процесса. Пул pconn привязан к коннекту, пул preq привязан к запросу. Разработчик может создать свой собственный пул, используя ap_make_sub_pool, передавая ей в качестве аргумента родительский пул.

В программе его можно использовать аналогично другим пулам: привязать к какому-то родительскому пулу, и он автоматически будет удален в свое время вместе с родителем. Пул коннектов вложен в пул дочернего процесса, пул запросов вложен в пул коннектов.

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

Т. е. одна и та же физическая память не выделяется дважды, она перераспределяется.

Выделение памяти происходит блоками, блок привязывается к пулу.

Освобождаемые блоки добавляются в список свободных блоков.

Размер этого блока можно настроить в конфигурации.

Pool API позволяет выделять и освобождать ресурсы в произвольный момент. Для выделения памяти используются ap_palloc и ap_pcalloc, обеим функциям в качестве параметра нужно указывать пул и размер выделяемой памяти.

Функция ap_strdup выделяет память под строку. Функция ap_strcat выделяет память для нескольких строк.


11. Новые возможности в Apache 2.0

Во второй версии появилось много возможностей, которых не было в первой. Их можно разделить на 2 категории:

  1. Улучшения в ядре сервера.
  2. Улучшения в модулях сервера.

К первому типу можно отнести следующие улучшения:

  1. Многопоточность в Unix: на unix-платформах Apache. Apache теперь может выполняться в гибридном многопроцессово-многопоточном режиме.
  2. Новая система сборки: сборка была полностью изменена и теперь основывается на autoconf и libtool.
  3. Поддержка различных протоколов: теперь имеется специальная инфраструктура, способная обслуживать различные протоколы.
  4. Появились мультипроцессные модули (MPM), в которых теперь сконцентрирована основная часть кода, отвечающего за обработку запросов.
  5. Поддержка отличных от Unix платформ: это, прежде всего, касается Windows. Введение MPM + APR позволяет в Windows прозрачно вызывать нативные системные вызовы.
  6. Новый API: переписанный API улучшил организацию работы модулей.
  7. Использование фильтров: модули Apache теперь можно написать так, что они будут исполнять роль фильтров, обрабатывающих потоки данных, которые приходят или уходят из сервера. Это позволяет, к примеру, данным, являющимся результатом работы CGI-скрипта, быть обработанными SSI фильтром INCLUDES.

Ко второму типу можно отнести следующие улучшения:

  1. Добавлены новые модули: mod_ssl, mod_dav, mod_deflate, mod_auth_ldap, mod_charset_lite,mod_file_cache.
  2. Переписаны модули: mod_proxy, mod_negotiation, mod_autoindex, mod_include.

Многие конфигурационные директивы изменены, многие удалены.

Модули сторонних разработчиков, написанные для первой версии, во второй работать не будут.


Заключение

Apache имеет многозадачную архитектуру, что достаточно стабильно, но имеет определенные ограничения. По умолчанию в Apache принята модель, в которой главный процесс создает дочерние на основе fork(). Для распределения запросов между дочерними процессами используются мьютексы. Multi Processing Modules (MPM), которые появились во втором Apache, позволяют эффективно использовать возможности конкретной операционной системы. Ключевым программным циклом является цикл обработки клиентского запроса. Управление памятью построено на основе пулов. Во второй версии Apache появились новые возможности, такие как фильтры, многопоточность и т. д.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


  • Bluemix

    Узнайте больше информации о платформе IBM Bluemix, создавайте приложения, используя готовые решения!

  • developerWorks Premium

    Эксклюзивные инструменты для построения вашего приложения. Узнать больше.

  • Библиотека документов

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Open source, Linux
ArticleID=620074
ArticleTitle=У истоков Apache. Часть 4: История и обзор архитектуры (часть 2)
publish-date=01272011