mod_gzip - 압축된 콘텐츠 제공하기 - Apache 웹서버 - 페이지 8

저자: Michael Schröpl

이 문서는 mod_gzip의 현재 버전 1.3.26.1a에 너무 많은 노력 없이 구현될 수 있는 몇 가지 가능한 기능 향상을 설명하며, 이 모듈의 사용성을 향상시키기를 희망합니다.

로깅 클래스 및 결정적인 필터 규칙의 값

문서 콘텐츠가 mod_gzip에 의해 압축될 자격이 있는지에 대한 결정은 최종적으로 mod_gzip_item_include 및 mod_gzip_item_exclude 지시문에 의해 정의된 필터 규칙의 평가 중에 이루어지며, 이는 mod_gzip_validate1 함수에 의해 확인됩니다.

하지만 이 함수는 소스 코드 내에서 다섯 개의 위치에서 호출되며, 각 경우마다 특정 규칙 클래스의 특정 부분을 확인하기 위한 서로 다른 매개변수 설정으로 호출됩니다. 이러한 경우 중 일부에서는 제한된 매개변수 설정으로 인해 어떤 규칙 클래스가 특정 결과로 이어졌는지 명확하지만(어떤 규칙 값인지는 아님), 다른 경우(예: file, uri, mime 및 handler 클래스의 모든 규칙을 동시에 테스트하는 경우)에는 결정적인 규칙의 클래스조차 명확하지 않습니다(왜냐하면 mod_gzip_validate1이 호출자에게 너무 비특정적인 결과 값을 반환하여 정확히 무슨 일이 일어났는지 이해할 수 없기 때문입니다 - 어떤 경우에는 내부 오류조차도 배제 규칙으로 인한 결정처럼 인코딩됩니다). 이러한 경우에는 mod_gzip 상태 코드를 합리적으로 평가하는 것도 불가능합니다.

하지만 적절한 규칙 세트를 정의하는 것은 전체(현재 여전히 다소 복잡한) mod_gzip 구성 절차에서 가장 중요한 단계입니다. 정의된 규칙 중 어떤 것이 어떤 경우에 문서 콘텐츠를 압축할지에 대한 결정을 내렸는지에 대한 정보는 많은 경우 사용자에게 도움이 될 것입니다.

반면에 mod_gzip은 이미 문서를 성공적으로 처리한 후에 Apache 로그 형식에서 사용할 수 있는 몇 가지 변수를 설정하여 처리 투명성을 지원합니다(처리 상태, 압축 전후의 문서 크기 및 백분율로 절약된 용량 - 마지막 것은 잘못하여 항상 올림 처리됨). 따라서 mod_gzip은(문서 콘텐츠를 압축하기로 결정한 순간에) 결정적인 규칙의 클래스와 내용을 두 개의 추가 로그 변수에 쉽게 저장할 수 있으며, 이는 로그 형식 내에서 mod_gzip_rule_class 및 mod_gzip_rule_content라는 이름으로 참조될 수 있습니다.

구성 가능한 gzip 압축 수준

현재 mod_gzip은 gzip 압축 수준 6을 사용합니다. 이는 gz1->level = 6의 할당에 의해 하드코딩되어 있습니다.

압축 수준이 높을수록(gzip은 1에서 9 사이의 값을 허용함) 압축 효과가 더 좋지만 CPU 시간 소비도 증가합니다. 이 압축 수준을 조정함으로써 사용자는 자신의 요구에 따라 CPU 부하와 대역폭 절약 간의 균형을 맞출 수 있습니다. 자체 실험에 따르면 수준 3은 이미 압축 수준 6의 효과에 근접하며 - 적어도 이 두 값 간의 선택은 사용자에게 남겨져야 합니다.

따라서 이 압축 수준을 mod_gzip_compression_level이라는 또 다른 지시문을 제공하여 구성 가능하게 만드는 것이 합리적일 것입니다.

Christian Kruse의 자세한 검토에 따르면 Kevin Kiley의 mod_gzip 압축 코드는 모든 9개의 압축 수준을 지원하지 않는 것으로 보이며,

gzip

에 대해 기본적으로 수준 6에 필요한 것만 지원합니다(비록 프로그램 구조는 나중에 모든 9개 수준을 구현하기 위해 설계되었지만). 따라서 앞서 언급한 상수를 단순히 변경하는 것으로는 충분하지 않으며; 사실 mod_gzip은 이러한 종류의 수정 후에는 더 이상 사용이 불가능합니다.

include / exclude 지시문에서의 불리언 표현식

mod_gzip 1.3.19.1a는 Apache 요청 처리 방식으로 인해 요청의 결과를 압축할지 여부를 결정하기 위해 복잡한 2단계 필터 절차를 사용합니다. (수정된 Apache 2.0 아키텍처에서는 더 간단한 방식의 임베딩이 가능할 수 있습니다.)

현재 요청은 mod_gzip에 의해 정확히 두 개의 결정 단계에서 각각 최소한 하나의 include 규칙이 작동하고 exclude 규칙이 작동하지 않을 때만 수용됩니다. 이러한 규칙은 매개변수 값으로 정규 표현식을 허용하므로 강력한 조건을 제공합니다.

그럼에도 불구하고 모든 규칙은 서로 독립적입니다; 현재 사용 가능한 지시문은 사용자가 특정 MIME 유형이 특정 브라우저에 대해서만 압축된 형태로 제공되도록 표현할 수 없게 합니다 - 여러 규칙 간의 AND 연결이 부족합니다.

이것이 정말로 도움이 될 수 있는 경우는 드문 것 같습니다 - 현재로서는 Netscape 4의 모든 버그를 처리하기 위해 필터 규칙을 미세 조정해야 할 필요가 있으며, 이 브라우저를 압축에서 완전히 제외하는 것 외에는 방법이 없습니다. 시간이 지나면서(브라우저의 표준 준수 개선) 이 기능은 쓸모없게 될 수 있습니다.

GET 및 HEAD 요청에 동일한 HTTP 헤더 제공

RFC 2616에 따르면, HEAD 메서드를 사용하는 요청에 대해 HTTP/1.1 준수 구현은 GET 메서드를 사용하여 동일한 리소스에 대한 요청에 대해 제공될 HTTP 헤더와 동일한 HTTP 헤더를 제공해야 합니다.

mod_gzip의 경우 이는 HEAD 요청에 대해서도 콘텐츠가 압축되어야 함을 의미합니다(정적 사전 압축 파일의 경우 읽어야 함) 단지 올바른 Content-Length HTTP 헤더를 생성할 수 있도록 하기 위해서입니다.

현재 mod_gzip은 이(극히 드문) 애플리케이션 사례를 처리하지 않습니다(아마도 성능 고려 사항 때문일 것입니다); 그러나 RFC 2119에 따르면 이는 모듈의 동작이 HTTP/1.1과 조건부 호환성만을 가지게 할 수 있습니다. 왜냐하면 권장 요구 사항을 지원하지 않는 데에는 유효한 이유가 있어야 하기 때문입니다.

이 문서의 원본 위치:

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