Apache модуль · 11 min read · Sep 14, 2025

mod_gzip - обслуживание сжатого контента веб-сервером Apache - Страница 5

Автор: Майкл Шрёпл

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

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

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

Основы

Введение

Веб-сервер Apache поддерживает два различных метода интеграции модуля в свой программный код:

  • статическая и
  • динамическая интеграция.

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

  1. один из этих двух методов работы для mod_gzip должен быть выбран и
  2. набор файлов, необходимых для этого метода, должен быть загружен.

Статическая интеграция модуля Apache

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

Для этого исходный код сервера Apache должен быть

  • расширен исходным кодом этого модуля, а затем
  • скомпилирован целиком с использованием компилятора C.

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

Динамическая интеграция модуля Apache

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

Для этого

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

Структура исходного кода модуля mod_gzip

Большинство модулей Apache состоят только из одного файла исходного кода. Этот файл можно скомпилировать, вызвав программу apxs (с соответствующими значениями параметров); для установки разделяемого объекта, созданного таким образом, потребуется еще один вызов apxs (с другими значениями параметров).

Начиная с версии 1.3.26.1a, исходный код mod_gzip разделен на три отдельных файла:

  • mod_gzip.c (около 8000 строк) содержит все функции, необходимые для реализации логики обработки модуля mod_gzip Apache.
    Этот файл сильно зависит от интерфейса модуля версии Apache 1.3 (который не изменялся в течение многих лет).
  • mod_gzip_debug.c (около 500 строк) содержит функции, которые необходимы только для отладочных задач для разработчика; часть этих функций даже не содержится в скомпилированном ‘нормальным образом’ mod_gzip (в зависимости от значений заданных директив компилятора типа -D для определения символических констант).
  • mod_gzip_compress.c (около 3000 строк) содержит реализацию функции gzip-сжатия Кевина Кайли, той, которая ‘на самом деле выполняет работу’.
    Эта часть не зависит от какой-либо конкретной версии Apache и (с чисто технической точки зрения) может быть использована и другими инструментами сжатия (такими как mod_deflate, который в настоящее время использует ‘zlib’ для сжатия).

Эта структура исходного кода делает обслуживание mod_gzip немного проще - и установку немного более сложной (так как теперь необходимо скомпилировать несколько файлов исходного кода вместо одного). Поэтому mod_gzip теперь предоставляет Makefile для упрощения этого процесса установки.

Загрузка

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

На момент написания следующие файлы доступны для каждой версии mod_gzip на странице загрузки проекта mod_gzip:

| mod_gzip- версия .tgz: | gzip-сжатый tar-архив продукта mod_gzip, включая - исходный код модуля (на языке программирования C),

  • несколько Makefile (для компиляции исходного кода),
  • Change-Log (как краткая документация о наиболее важных изменениях для всех версий программы) и
  • документацию, которую вы держите в руках. | | ApacheModuleGzip.dll.zip: | ZIP-архив, содержащий разделяемый объект файла mod_gzip для платформы Windows. | | mod_gzip- версия -FreeBSD-4.6-i386.so.gz: | gzip-сжатый файл, содержащий разделяемый объект файла mod_gzip для платформы FreeBSD-UNIX 4.6. | | mod_gzip.so.gz: | gzip-сжатый файл, содержащий разделяемый объект файла mod_gzip для платформы Solaris 2.7. |

Если mod_gzip должен быть запущен с динамической интеграцией на какой-либо другой платформе, то файл разделяемого модуля для этой платформы должен быть создан администратором.

Статическая интеграция mod_gzip

Обычная компиляция веб-сервера Apache

Процедура установки веб-сервера Apache на машине UNIX, задокументированная группой Apache, выглядит следующим образом (в краткой версии):

  1. загрузите архив с исходным кодом Apache с WWW
  2. распакуйте архив
  3. перейдите в каталог, созданный предыдущей операцией
  4. прочитайте и поймите файл INSTALL
  5. запустите оболочку скрипта ./configure с соответствующими значениями параметров (это приведет к созданию Makefile в большом количестве подкаталогов)
  6. make install (это приведет к компиляции и установке сервера Apache, включая его онлайн-документацию)

Если веб-сервер Apache был создан таким образом, то поставляемые модули обычно становятся статическими частями созданного программного файла httpd в каталоге программы Apache - если вы не указали что-то другое в параметрах вызова configure.

(Фактический вызов configure может стать очень обширным, в зависимости от степени отклонения от стандартных значений параметров. Я рекомендую сохранить этот вызов в небольшом скрипте оболочки, чтобы задокументировать тип обработанной установки, кстати.)

Интеграция mod_gzip в исходный код Apache

Исходный код официальных модулей Apache содержится в подкаталоге src/modules распакованного tar-архива программного обеспечения Apache.

Чтобы модуль mod_gzip рассматривался как стандартный модуль Apache с помощью этого механизма, необходимы следующие приготовления:

  1. Распакуйте и распакуйте содержимое загруженного архива, содержащего исходный код modgzip (что создаст каталог mod_gzip- *номерверсии*),
  2. Создайте каталог src/modules/gzip в дереве каталогов исходного кода Apache
  3. Скопируйте все файлы с расширениями .c*, .h и .tmpl в этот новый каталог gzip.

На следующем этапе вы расширяете вызов configure параметром –activate-module=src/modules/gzip/mod_gzip.c. Теперь скрипт configure найдет исходный код mod_gzip и создаст подходящий Makefile из поставляемого файла Makefile.tmpl - зафиксированного сообщениями

 + активирован модуль gzip (modules/gzip/mod_gzip.c)

и

Создание Makefile в src/modules/gzip
  • последний, как и для собственных модулей Apache. (Поставляемый Makefile с mod_gzip не подходит для этого типа установки - он только для создания разделяемого объекта.)

Теперь установка Apache будет работать как обычно - и mod_gzip будет рассматриваться как обычный модуль Apache.

Но configure знает, что модуль, интегрированный через параметр –activate-module, является модулем стороннего производителя, который, вероятно, имеет специфические требования, и поэтому будет автоматически загружать mod_gzip на вершину стека модулей, чтобы он имел доступ к входящему HTTP-запросу до всех других модулей - что именно и необходимо mod_gzip.

На некоторых платформах configure Apache, похоже, не устанавливает автоматически значение переменной окружения $(LIBEXT) на правильное значение .a. В этом случае компиляция mod_gzip завершится неудачей. Точная причина этого поведения в настоящее время неизвестна; в качестве обходного пути вы можете заменить строку

LIB=libgzip.$(LIBEXT)

на

LIB=libgzip.a

в поставляемом файле Makefile.tmpl, т.е. вручную вставить правильное значение.

Убедитесь, что вы используете редактор, который не преобразует символы табуляции в пробелы для этой задачи!

(Для проверки: Что произойдет при интеграции более чем одного модуля стороннего производителя с –activate-module? Имеет ли порядок значений параметров значение в этом случае?)

Проверьте, что mod_gzip был интегрирован правильно

Чтобы проверить, был ли mod_gzip фактически интегрирован в программный код Apache, как было запрошено, сервер Apache предоставляет команду httpd -l. Это отобразит список всех интегрированных модулей (в порядке их загрузки); mod_gzip.c должен быть последней записью, отображаемой там.

Динамическая интеграция mod_gzip

Концепция загружаемых модулей Apache

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

Практически каждый модуль Apache может быть

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

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

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

Документация Apache 1.3 предоставляет следующие статьи по этой теме:

  • Поддержка динамических разделяемых объектов (DSO) - описание соответствующей концепции для веб-сервера Apache
  • Модуль mod_so - описание модуля Apache для загрузки других модулей и необходимых директив конфигурации

Директива для загрузки mod_gzip

Чтобы динамически добавить разделяемый объект mod_gzip в код Apache, требуется одна из следующих директив конфигурации:

# ---------------------------------------------------------------------  
# загрузить DLL / Windows:  
  LoadModule gzip_module modules/ApacheModuleGzip.dll  
# ---------------------------------------------------------------------  
# загрузить DSO / UNIX:  
  LoadModule gzip_module modules/mod_gzip.so**  
# ---------------------------------------------------------------------  
# (ни один из обоих, если модуль статически интегрирован)  
# ---------------------------------------------------------------------

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

Обработка модулей Apache 1.3

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

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

Только один из всех рассматриваемых модулей может быть ответственным за обработку запроса в Apache 1.3 - последующие модули даже не будут запрашиваться.

Интеграция mod_gzip в оценку запроса Apache

Поэтому, чтобы иметь возможность обрабатывать вывод произвольных модулей, mod_gzip должен сделать то, что на самом деле противоречит архитектуре Apache 1.3: Он должен ‘обрабатывать’ запрос, но затем отменить ответственность за обработку этого запроса. Только таким образом модуль, который фактически отвечает за обработку запроса, может быть активирован сервером Apache вообще.

На этом первом этапе ‘обработка’ этого запроса mod_gzip не означает сжатие содержимого страницы, которое должно быть обслужено - потому что это содержимое даже еще не существует, его все еще необходимо сгенерировать другим модулем! Вместо этого на данный момент mod_gzip просто готовится быть снова спрошенным, хочет ли он сделать что-либо после создания содержимого страницы. Только на этом втором этапе своей активации (где содержимое HTTP-ответа уже доступно) mod_gzip может выполнить свою основную задачу, которая заключается в сжатии содержимого пакета HTTP-ответа (и модификации определенных HTTP-заголовков).

Эта ‘регистрация’ для последующей постобработки HTTP-ответа, выполненная mod_gzip, необходима только в том случае, если mod_gzip не может уже на этом этапе определить, что он определенно не будет заинтересован в обработке содержимого ответа.

Таким образом, на этом первом этапе mod_gzip уже выполняет часть оценки директив фильтра, указанных в конфигурации Apache: Он проверяет те правила, где он может это сделать, основываясь только на описании запроса (т.е. содержимом соответствующих HTTP-заголовков). Это относится к правилам mod_gzip_item_include / mod_gzip_item_exclude типа

  • reqheader (содержимое заголовков HTTP-запроса запроса),
  • url (URL запрашиваемого HTTP-ресурса),
  • file (имя файла, затронутого этим запросом, после оценки всех переводов Alias и т.д.) и
  • handler (имя обработчика, ответственного за оценку этого запроса, согласно конфигурации Apache).

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

  • выполнено хотя бы одно правило exclude или
  • ни одно из правил include не выполнено или
  • если любое другое условие для выполнения сжатия не выполнено (например, на этом этапе уже можно проверить, разрешил ли клиент обслуживание сжатых данных, отправив заголовок HTTP Accept-Encoding: gzip)

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

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

  • rspheader (содержимое заголовков HTTP-ответа) а также
  • mime (HTTP-тип содержимого результата).

Кроме того, теперь проверяются некоторые другие условия, такие как размер пакета ответа (директивы mod_gzip_minimum_file_size и mod_gzip_maximum_file_size).

И только если все эти тесты привели к положительному результату, сжатие пакета ответа будет фактически выполнено.

Позиция mod_gzip в последовательности загрузки всех модулей Apache

Чтобы иметь возможность выполнять все описанные выше задачи, модуль mod_gzip должен иметь доступ к обработке HTTP-запроса до каждого другого модуля Apache, вывод которого он предназначен для обработки. Из-за обратного порядка доступа к обработке запроса для всех модулей Apache, mod_gzip следует загружать последним из всех модулей Apache.

Для статической интеграции этот порядок модулей определяется ‘планом’ программы httpd во время компиляции исходного кода Apache. Процедура компиляции исходного кода Apache, поставляемого группой Apache, активируемая оболочкой configure, знает все зависимости между поставляемыми модулями (и обеспечивает соответствующий порядок этих модулей), но не требования сторонних модулей, таких как mod_gzip, которые интегрированы в процесс компиляции с помощью параметра –add-module= file. Чтобы обеспечить максимальное влияние на эти сторонние модули, такие модули загружаются как последние модули в стеке модулей.

Таким образом, если mod_gzip должен быть интегрирован в сервер Apache как единственный модуль стороннего производителя, то configure автоматически делает все правильно. В случае использования более чем одного модуля стороннего производителя администратор несет ответственность за упорядочение этих модулей (возможно, по порядку его значений –add-module=? Я еще не тестировал это).

Компиляция mod_gzip с использованием apxs

Функция утилиты компиляции Apache apxs

Если сервер Apache работает для поддержки динамической интеграции модулей (т.е. использует модуль mod_so), то утилита под названием apxs будет сгенерирована в каталоге bin Apache во время установки Apache.

Эта программа позволяет пользователю компилировать исходный код программы модуля Apache (с использованием компилятора C) и создавать соответствующий разделяемый объект файл, не требуя наличия полного исходного кода серверов Apache: apxs знает все необходимые интерфейсы программы Apache и предоставляет компилятору C необходимую информацию.

Создание разделяемого объекта для mod_gzip с использованием make

Чтобы избавить пользователя от необходимости выяснять, как именно mod_gzip должен быть скомпилирован и полностью установлен при использовании apxs, в архиве исходного кода предоставляется файл с именем Makefile.

Использование этого Makefile сокращает процедуру установки до следующих шагов:

  1. Извлеките файлы из загруженного архива исходного кода mod_gzip в (новый, временный) каталог по вашему выбору и измените ваше текущее положение каталога на него.
  2. Узнайте имя пути программы apxs из вашей установки Apache.
  3. Выполните компиляцию, запустив команду make APXS=*ваше_имя_пути_apxs* Это создаст разделяемый объект файл mod_gzip.so в текущем каталоге.
    (Этот шаг операционной последовательности может быть пропущен, так как он будет покрыт последующим шагом.)
  4. Выполните установку, запустив команду make install APXS=*ваше_имя_пути_apxs* Это не только скопирует разделяемый объект файл в соответствующий каталог установки Apache, но и автоматически расширит файл конфигурации Apache httpd.conf необходимыми директивами LoadModule и AddModule … если вам не нравятся посторонние программы, переписывающие ваши драгоценные конфигурационные файлы, вы можете предпочесть выполнить этот последний шаг вручную или, по крайней мере, сделать резервную копию вашей конфигурации Apache сначала.

Кроме этих необходимых шагов, Makefile поддерживает следующие команды (которые могут быть интересны разработчикам):

  • make clean удаляет все созданные объектные файлы модуля исходного кода mod_gzip из текущего каталога (т.е. все файлы с именем, соответствующим шаблону *.o).
  • make clean дополнительно удаляет созданный разделяемый объект файл mod_gzip.so также.

Оригинальное местоположение этого документа:

http://www.schroepl.net/projekte/mod_gzip/install.htm

Share: X/Twitter LinkedIn

Get new posts in your inbox

No spam. Unsubscribe anytime.