mod_gzip - 압축된 콘텐츠 제공하기 - 아파치 웹서버

저자: Michael Schröpl

실제로 설치를 수행하는 것은 어렵지 않지만, 귀하의 아파치 설치에 가장 적합한 방법을 찾는 데는 시간이 걸릴 수 있습니다.

따라서 작업 방법을 선택하고 설치를 수행하기 전에 이 장을 완전히 읽고 다양한 옵션의 장단점을 인식하는 것이 강력히 권장됩니다.

현재 문서는 mod_gzip의 내부 처리 모델을 아파치 모듈로 다루고 있으며, 따라서 mod_gzip의 구성 지시문 평가 방법을 이해하는 데 도움이 될 수 있는 정보를 제공할 수 있습니다.

기본 사항

소개

아파치 웹 서버는 모듈을 프로그램 코드에 통합하는 두 가지 방법을 지원합니다:

정적 및
동적 통합.

귀하의 아파치 서버에 사용되는 운영 개념과 주어진 요구 사항에 따라

mod_gzip에 대한 이 두 가지 작업 방법 중 하나를 선택해야 하며
이 방법에 필요한 파일 세트를 다운로드해야 합니다.

아파치 모듈의 정적 통합

정적 통합은 모듈이 아파치 서버를 구현하는 링크된 프로그램 바이너리 httpd의 영구적인 부분이 된다는 것을 의미합니다.

이를 위해 아파치 서버 소스 코드는

이 모듈의 소스 코드로 확장되어야 하며, 그 후
C 컴파일러를 사용하여 전체적으로 컴파일되어야 합니다.

일반적으로 각 관리자는 자신의 요구 사항에 맞게 조정된 아파치 서버에 대해 다른 기능 세트를 사용하고 싶어 할 수 있으므로, 여러 플랫폼에서 실행할 준비가 된 프로그램 파일을 제공하는 것은 실현 가능하지 않은 것 같습니다.

아파치 모듈의 동적 통합

동적 통합은 모듈이 아파치 프로세스를 시작할 때 공유 객체로서 별도의 모듈 파일에서 로드될 수 있음을 의미합니다.

이를 위해

필요한 대상 플랫폼에 대한 이 모듈의 공유 객체 파일을 조달하거나 생성해야 하며,
해당 아파치 디렉토리에 설치해야 하고,
이 모듈을 로드하기 위한 지시문으로 아파치 구성 파일을 확장해야 합니다.

mod_gzip 모듈 소스 코드의 구조

대부분의 아파치 모듈은 단일 소스 코드 파일로 구성됩니다. 이 파일은 apxs 프로그램을 호출하여 컴파일할 수 있습니다(해당 매개변수 값과 함께); 이렇게 생성된 공유 객체의 설치를 위해서는 apxs를 한 번 더 호출해야 합니다(다른 매개변수 값으로).

버전 1.3.26.1a부터 mod_gzip의 소스 코드는 세 개의 개별 파일로 나뉩니다:

mod_gzip.c (약 8000줄)는 mod_gzip 아파치 모듈의 처리 논리를 구현하는 데 필요한 모든 함수를 포함합니다.
이 파일은 아파치 버전 1.3의 모듈 인터페이스에 매우 의존적입니다(수년 동안 변경되지 않았습니다).
mod_gzip_debug.c (약 500줄)는 개발자를 위한 디버깅 작업에 필요한 함수만 포함합니다; 이 함수의 일부는 모드_gzip이 ‘정상적인 방식‘으로 컴파일된 경우에도 포함되지 않습니다(기호 상수를 정의하기 위한 -D 유형의 주어진 컴파일러 지시문의 값에 따라 다릅니다).
mod_gzip_compress.c (약 3000줄)는 ‘실제로 작업을 수행하는‘ gzip 압축 함수의 Kevin Kiley 구현을 포함합니다.
이 부분은 특정 아파치 버전에 의존하지 않으며(순수 기술적 관점에서) 다른 압축 도구에서도 사용될 수 있습니다(mod_deflate와 같이 현재 ‘zlib’를 사용하여 압축합니다).

이 소스 코드 구조는 mod_gzip 유지 관리를 조금 더 쉽게 만들지만 설치는 조금 더 복잡하게 만듭니다(이제 단일 파일 대신 여러 소스 파일을 컴파일해야 하므로). 따라서 mod_gzip은 이제 이 설치 프로세스를 단순화하기 위해 Makefile을 제공합니다.

다운로드

위에서 언급한 작업 개념 중 어떤 것이 실행될 것인지에 따라 사용해야 할 다양한 파일(각각의 사용 목적에 적합한)이 있습니다.

이 문서를 작성하는 시점에서 mod_gzip 프로젝트의 다운로드 페이지에서 각 mod_gzip 버전에 대해 다음 파일이 제공됩니다:

| mod_gzip- version .tgz: | mod_gzip 제품의 gzip 압축 tar 아카이브, 포함 - 모듈의 소스 코드 (C 프로그래밍 언어로),

여러 Makefile (소스 코드를 컴파일하기 위해),
Change-Log (모든 프로그램 버전의 가장 중요한 변경 사항에 대한 간단한 문서) 및
현재 문서. | | ApacheModuleGzip.dll.zip: | Windows 플랫폼을 위한 mod_gzip의 공유 객체 파일을 포함하는 ZIP 아카이브. | | mod_gzip- version -FreeBSD-4.6-i386.so.gz: | FreeBSD-UNIX 4.6 플랫폼을 위한 mod_gzip의 공유 객체 파일을 포함하는 gzip 압축 파일. | | mod_gzip.so.gz: | Solaris 2.7 플랫폼을 위한 mod_gzip의 공유 객체 파일을 포함하는 gzip 압축 파일. |

mod_gzip이 다른 플랫폼에서 동적 통합으로 실행되려면 해당 플랫폼을 위한 공유 모듈 파일을 관리자가 생성해야 합니다.

mod_gzip의 정적 통합

아파치 웹서버의 일반적인 컴파일

UNIX 머신에서 아파치 웹서버를 설치하는 절차는 아파치 그룹에 의해 다음과 같이 문서화되어 있습니다(짧은 버전):

WWW에서 아파치 소스 코드가 포함된 아카이브를 다운로드합니다.
아카이브를 압축 해제합니다.
이전 작업으로 생성된 디렉토리로 이동합니다.
INSTALL 파일을 읽고 이해합니다.
./configure 셸 스크립트를 적절한 매개변수 값으로 시작합니다(이로 인해 많은 하위 디렉토리에 Makefile 파일이 생성됩니다).
make install (이로 인해 아파치 서버와 그 온라인 문서가 컴파일되고 설치됩니다).

이렇게 아파치 웹서버가 생성되면, 제공된 모듈은 일반적으로 아파치 프로그램 디렉토리의 생성된 프로그램 파일 httpd의 정적 부분이 됩니다 - configure 호출의 매개변수에서 다른 것을 지정하지 않는 한.

(configure의 실제 호출은 표준 매개변수 값에서의 편차 정도에 따라 매우 광범위해질 수 있습니다. 이 호출 자체를 작은 셸 스크립트에 저장하여 처리된 설치 유형을 문서화하는 것이 좋습니다.)

mod_gzip을 아파치 소스 코드에 통합하기

공식 아파치 모듈의 소스 코드는 압축 해제된 아파치 소프트웨어의 tar 아카이브의 src/modules 하위 디렉토리에 포함되어 있습니다.

mod_gzip이 이 메커니즘에 의해 표준 아파치 모듈처럼 처리되도록 하려면 다음 준비가 필요합니다:

mod_gzip 소스 코드가 포함된 다운로드 아카이브의 내용을 압축 해제하고 풀어냅니다(이로 인해 mod_gzip- versionnumber 디렉토리가 생성됩니다),
아파치 소스의 디렉토리 트리 내에 src/modules/gzip 디렉토리를 생성합니다.
.c*, .h 및 .tmpl 확장자를 가진 모든 파일을 이 새로운 gzip 디렉토리로 복사합니다.

다음 단계로, configure 호출을 –activate-module=src/modules/gzip/mod_gzip.c 매개변수로 확장합니다. 이제 configure 스크립트는 mod_gzip 소스 코드를 찾고 제공된 Makefile.tmpl 파일에서 적절한 Makefile을 생성합니다 - 메시지에 의해 기록됩니다.

 + 활성화된 gzip 모듈 (modules/gzip/mod_gzip.c)

및

src/modules/gzip에 Makefile 생성

후자는 아파치의 자체 모듈에 대해 생성된 것과 같습니다. (mod_gzip과 함께 제공된 Makefile은 이 유형의 설치에 적합하지 않습니다 - 이는 공유 객체 파일을 생성하기 위한 것일 뿐입니다.)

이제 아파치 설치는 일반적으로 작동하며 mod_gzip은 일반 아파치 모듈처럼 처리됩니다.

하지만 configure는 –activate-module 매개변수를 통해 통합된 모듈이 특정 요구 사항이 있을 수 있는 제3자 모듈이라는 것을 알고 있으며, 따라서 mod_gzip을 모듈 스택의 맨 위에 자동으로 로드하여 모든 다른 모듈보다 먼저 들어오는 HTTP 요청에 접근할 수 있도록 합니다 - 이는 mod_gzip이 절실히 필요로 하는 것입니다.

일부 플랫폼에서는 아파치의 configure가 $(LIBEXT) 환경 변수의 값을 적절한 .a 값으로 자동으로 설정하지 않는 것 같습니다. 이 경우 mod_gzip의 컴파일이 실패합니다. 이 동작의 정확한 이유는 현재로서는 알려져 있지 않습니다; 해결 방법으로는 다음 줄을 교체할 수 있습니다.

LIB=libgzip.$(LIBEXT)

를

LIB=libgzip.a

로 변경하여 적절한 값을 수동으로 삽입합니다.

이 작업을 위해 탭 문자를 공백으로 확장하지 않는 편집기를 사용해야 합니다!

(테스트해야 할 사항: –activate-module로 둘 이상의 제3자 모듈을 통합할 때 어떤 일이 발생합니까? 이 경우 매개변수 값의 순서가 중요합니까?)

mod_gzip이 올바르게 통합되었는지 확인하기

mod_gzip이 실제로 요청한 대로 아파치 프로그램 코드에 통합되었는지 확인하기 위해 아파치 서버는 httpd -l 명령을 제공합니다. 이 명령은 통합된 모든 모듈의 목록을 표시합니다(로드되는 순서로); mod_gzip.c는 여기에서 마지막 항목으로 표시되어야 합니다.

mod_gzip의 동적 통합

로드 가능한 아파치 모듈의 개념

아파치 웹서버는 로드 가능한 모듈의 개념을 지원합니다.

거의 모든 아파치 모듈은

공유 객체로 컴파일된 다음
아파치 서버 시작 시 아파치의 주소 공간에 동적으로 로드될 수 있습니다(해당 구성 지시문을 사용하여).

로드 가능한 모듈을 처리하려면 아파치 구성에 대한 추가 지식이 필요합니다(이 모듈이 로드되는 순서가 기능에 중요할 수 있기 때문) 하지만 아파치 서버의 코드 범위를 재컴파일하지 않고도 변경할 수 있습니다.

Windows와 같은 플랫폼에서는(여기서는 많은 아파치 관리자가 아파치 코드를 컴파일하고 링크할 수 있는 C 개발 환경을 갖고 있지 않기 때문에) 로드 가능한 모듈의 사용이 아파치 서버의 기능 범위를 확장하는 유일한 가능성일 수 있습니다.

아파치 1.3 문서는 이 주제에 대해 다음 기사를 제공합니다:

동적 공유 객체(DSO) 지원 - 아파치 웹서버에 대한 해당 개념의 설명
모듈 mod_so - 다른 모듈을 로드하기 위한 아파치 모듈 및 필요한 구성 지시문의 설명

mod_gzip 로드를 위한 지시문

mod_gzip 공유 객체를 아파치 코드에 동적으로 추가하려면 다음 구성 지시문 중 하나가 필요합니다:

# ---------------------------------------------------------------------  
# DLL 로드 / Windows:  
  LoadModule gzip_module modules/ApacheModuleGzip.dll  
# ---------------------------------------------------------------------  
# DSO 로드 / UNIX:  
  LoadModule gzip_module modules/mod_gzip.so**  
# ---------------------------------------------------------------------  
# (정적으로 통합된 경우 둘 다 아님)  
# ---------------------------------------------------------------------

실제 파일 이름은 자유롭게 선택할 수 있습니다 - 단지 실제로 사용되는 파일의 이름과 일치해야 합니다. 반면에 이 이름은 운영 체제 플랫폼 및 이 모듈에 사용된 컴파일 방법에 따라 달라질 수 있습니다 - 이 경우 위에 표시된 지시문을 조정하거나 파일 이름을 적절히 변경해야 합니다.

아파치 1.3에 의한 모듈 처리

아파치 서버는 아무 수의 모듈을 동적으로 로드할 수 있습니다. 이때 해당 LoadModule 지시문은 구성 파일 내에서 발생하는 순서에 따라 처리됩니다.

하지만 모듈은 작업 메모리 내에서 스택에 로드됩니다: 마지막으로 로드된 모듈이 아파치 웹서버에 대한 해당 HTTP 요청을 처리하는 데 첫 번째로 접근하게 되며, 이후 이 요청을 처리할 책임이 있는지 여부를 결정할 수 있습니다.

아파치 1.3에서는 요청을 처리하는 데 책임이 있는 모듈은 오직 하나만 존재할 수 있으며, 이후 모듈은 요청을 처리하는 데 질문조차 받지 않습니다.

mod_gzip의 요청 평가에 대한 통합

따라서 임의의 모듈의 출력을 처리할 수 있도록 하려면 mod_gzip은 아파치 1.3 아키텍처와 실제로 모순되는 작업을 수행해야 합니다: 요청을 ‘처리’해야 하지만 이후 이 요청을 처리할 책임을 철회해야 합니다. 이러한 절차를 통해 요청을 처리하는 데 실제로 책임이 있는 모듈이 아파치 서버에 의해 여전히 활성화될 수 있습니다.

이 첫 번째 단계에서 mod_gzip에 의한 이 요청의 ‘처리’는 제공될 페이지의 콘텐츠를 압축하는 것을 의미하지 않습니다 - 왜냐하면 이 콘텐츠는 아직 존재하지 않으며, 다른 모듈에 의해 생성되어야 하기 때문입니다! 대신, 이 시점에서 mod_gzip은 페이지 콘텐츠 생성 후에 무엇을 할 것인지 다시 요청받기 위해 준비합니다. 이 활성화의 두 번째 단계에서(HTTP 응답의 내용이 이미 사용 가능할 때) mod_gzip은 HTTP 응답 패킷의 내용을 압축하는 본질적인 작업을 수행할 수 있습니다(그리고 특정 HTTP 헤더를 수정합니다).

mod_gzip에 의한 이 HTTP 응답의 후처리를 위한 ‘등록‘은 mod_gzip이 이 단계에서 이미 응답 콘텐츠를 처리하는 데 관심이 없음을 확실히 판단할 수 없는 경우에만 필요합니다.

따라서 이 첫 번째 단계에서 mod_gzip은 아파치 구성에서 지정된 필터 지시문의 평가의 일부를 이미 수행합니다: 요청 설명만으로 이를 수행할 수 있는 규칙을 확인합니다(즉, 해당 HTTP 헤더의 내용). 이는 다음과 같은 mod_gzip_item_include / mod_gzip_item_exclude 규칙에 적용됩니다.

reqheader (요청의 HTTP 요청 헤더의 내용),
url (요청된 HTTP 리소스의 URL),
file (이 요청에 의해 영향을 받는 파일의 파일 이름, 모든 Alias 변환 등을 평가한 후) 및
handler (아파치 구성에 따라 이 요청을 평가하는 데 책임이 있는 핸들러의 이름).

이 필터 규칙의 평가가 이미 이 요청의 결과가 압축되지 않아야 함을 증명하는 경우, 즉

적어도 하나의 exclude 규칙이 충족되거나 *
어떤 include 규칙도 충족되지 않거나
압축 수행을 위한 다른 조건이 충족되지 않는 경우(예: 이 단계에서 클라이언트가 Accept-Encoding: gzip HTTP 헤더를 보내어 압축된 데이터 제공을 허가했는지 여부를 이미 확인할 수 있습니다)

그렇다면 mod_gzip은 응답 콘텐츠 생성 후 나머지 규칙을 확인할 필요가 없습니다 - 따라서 이 경우 mod_gzip은 첫 번째 평가 단계의 결과를 기억하고 두 번째 단계를 즉시 종료합니다.

그렇지 않으면 mod_gzip은 생성된 응답 패킷의 실제 내용만으로 평가할 수 있는 나머지 필터 규칙을 확인합니다:

rspheader (HTTP 응답 헤더의 내용) 및
mime (결과의 HTTP 콘텐츠 유형).

또한 응답 패킷의 크기와 같은 다른 조건도 이제 테스트됩니다(지시문 mod_gzip_minimum_file_size 및 mod_gzip_maximum_file_size).

그리고 이러한 모든 테스트가 긍정적인 결과를 가져온 경우에만 응답 패킷의 압축이 실제로 수행됩니다.

모든 아파치 모듈의 로딩 순서 내에서 mod_gzip의 위치

위의 모든 작업을 수행할 수 있도록 하려면 mod_gzip 모듈은 HTTP 요청을 처리하는 데 접근할 수 있어야 합니다 모든 다른 아파치 모듈보다 먼저. 요청 처리에 대한 접근 순서가 반대이기 때문에 mod_gzip은 모든 아파치 모듈 중 마지막으로 로드되어야 합니다.

정적 통합의 경우 이 모듈 순서는 아파치 소스 코드의 컴파일 중 httpd 프로그램의 ‘청사진’에 의해 정의됩니다. 아파치 그룹에서 제공하는 아파치 소스 코드의 컴파일 절차는 제공된 모듈 간의 모든 종속성을 알고 있으며(이 모듈의 해당 순서를 보장하지만) configure 매개변수 –add-module= file에 의해 컴파일 프로세스에 통합된 mod_gzip과 같은 제3자 모듈의 요구 사항은 알지 못합니다. 이러한 제3자 모듈에 최대한의 영향을 허용하기 위해 이러한 모듈은 모듈 스택에서 마지막 모듈로 로드됩니다.

따라서 mod_gzip이 유일한 제3자 모듈로 아파치 서버에 통합되어야 하는 경우 configure는 자동으로 올바른 작업을 수행합니다. 여러 개의 제3자 모듈을 사용하는 경우 관리자가 이러한 모듈의 순서를 책임져야 합니다(아마도 그의 –add-module= 값의 순서에 따라? 아직 테스트하지 않았습니다).

apxs를 사용하여 mod_gzip 컴파일하기

아파치 컴파일 유틸리티 apxs의 기능

모듈의 동적 통합을 지원하도록 아파치 서버가 운영되는 경우(즉, mod_so 모듈을 사용하는 경우) 아파치 설치 중에 아파치의 bin 디렉토리에 apxs라는 유틸리티 프로그램이 생성됩니다.

이 프로그램은 사용자가 아파치 모듈의 프로그램 소스 코드를 컴파일하고 해당 공유 객체 파일을 생성할 수 있도록 하며, 아파치 서버의 전체 소스 코드를 사용할 필요가 없습니다: apxs는 모든 필요한 아파치 프로그램 인터페이스를 알고 있으며 C 컴파일러에 필요한 정보를 제공합니다.

make를 사용하여 mod_gzip의 공유 객체 생성하기

사용자가 apxs를 사용할 때 mod_gzip을 완전히 컴파일하고 설치하는 방법을 찾는 데서 벗어나도록 하기 위해, 소스 코드 아카이브 내에 Makefile이라는 파일이 제공됩니다.

이 Makefile을 사용하면 설치 절차가 다음 단계로 줄어듭니다:

다운로드한 mod_gzip 소스 코드 아카이브 파일에서 파일을 추출하여 선택한 (새로운 임시) 디렉토리에 넣고 현재 디렉토리 위치를 그곳으로 변경합니다.
아파치 설치에서 apxs의 경로 이름을 찾습니다.
다음 명령을 실행하여 컴파일을 수행합니다. make APXS=*your_apxs_pathname* 이 명령은 현재 디렉토리 내에 공유 객체 파일 mod_gzip.so를 생성합니다.
(이 작업 단계는 이후 단계에서 다루어지므로 생략할 수 있습니다.)
다음 명령을 실행하여 설치를 수행합니다. make install APXS=*your_apxs_pathname* 이 명령은 공유 객체 파일을 아파치 설치의 해당 디렉토리에 복사할 뿐만 아니라 Apache 구성 파일 httpd.conf를 필요한 지시문 LoadModule 및 AddModule로 자동으로 확장합니다 … 외부 프로그램이 귀하의 소중한 구성 파일을 수정하는 것을 원하지 않는 경우, 이 마지막 단계를 수동으로 수행하거나 적어도 아파치 구성을 먼저 백업하는 것이 좋습니다.

이러한 필요한 단계 외에도 Makefile은 다음 명령을 지원합니다(이는 개발자에게 더 관심이 있을 수 있습니다):

make clean은 현재 디렉토리에서 mod_gzip 소스 코드 파일의 모든 생성된 객체 모듈 파일을 제거합니다(즉, 이름 패턴 *.o를 가진 모든 파일).
make clean 추가로 생성된 공유 객체 파일 mod_gzip.so도 제거합니다.

이 문서의 원본 위치:

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

mod_gzip - 압축된 콘텐츠 제공하기 - 아파치 웹서버 - 페이지 5