Apache에서 제공하는 텍스트 파일에 gzip 대신 deflate를 사용하는 이유는 무엇입니까?

LAMP 서버가 제공하는 html, css 및 javascript 파일에 대해 어떤 방법이 장점을 제공합니까? 더 나은 대안이 있습니까?

서버는 대량의 작은 파일 인 Json을 사용하여 맵 응용 프로그램에 정보를 제공합니다.

참조 HTTP 압축 공기를 빼다 이상 GZIP 선택에 관여 히트 어떤 성능이 있습니까?

Apache에서 제공하는 텍스트 파일에 gzip 대신 deflate를 사용하는 이유는 무엇입니까?

간단한 대답은 아닙니다 .

RFC 2616 은 수축을 다음과 같이 정의합니다.

deflate RFC 1951에 설명 된 "deflate"압축 메커니즘과 함께 RFC 1950에 정의 된 "zlib"형식

zlib 형식은 RFC 1950 에서 다음과 같이 정의 됩니다.

     0   1
     +---+---+
     |CMF|FLG|   (more-->)
     +---+---+

       0   1   2   3
     +---+---+---+---+
     |     DICTID    |   (more-->)
     +---+---+---+---+

     +=====================+---+---+---+---+
     |...compressed data...|    ADLER32    |
     +=====================+---+---+---+---+

따라서 몇 가지 헤더와 ADLER32 체크섬

RFC 2616은 gzip을 다음과 같이 정의합니다.

gzip RFC 1952 [25]에 설명 된대로 파일 압축 프로그램 "gzip"(GNU zip)에 의해 생성 된 인코딩 형식입니다. 이 형식은 32 비트 CRC를 사용하는 Lempel-Ziv 코딩 (LZ77)입니다.

RFC 1952 는 압축 된 데이터를 다음과 같이 정의합니다.

형식은 현재 DEFLATE 압축 방법을 사용하지만 다른 압축 방법을 사용하도록 쉽게 확장 할 수 있습니다.

CRC-32가 ADLER32보다 느리다

동일한 길이의 순환 중복 검사와 비교하여 속도의 신뢰성을 교환합니다 (후자를 선호 함).

그래서 ... 압축에는 동일한 알고리즘을 사용 하지만 헤더와 체크섬 에는 다른 알고리즘을 사용하는 2 개의 압축 메커니즘이 있습니다 .

이제 기본 TCP 패킷은 이미 매우 안정적 이므로 여기서 문제는 GZIP가 사용하는 Adler 32 vs CRC-32 가 아닙니다 .

수년 동안 많은 브라우저가 잘못된 수축 알고리즘을 구현 한 것으로 나타났습니다. RFC 1950의 zlib 헤더를 기대하는 대신 압축 된 페이로드를 예상했습니다. 마찬가지로 다양한 웹 서버도 같은 실수를했습니다.

따라서 수년 동안 브라우저는 퍼지 논리 수축 구현을 구현 하기 시작 하여 페이로드를 시도하지 않으면 zlib 헤더 및 애들러 체크섬을 시도합니다.

이와 같은 복잡한 논리의 결과는 종종 깨진 것입니다. Verve Studio에는 상황이 얼마나 나쁜지 보여주는 사용자 제공 테스트 섹션이 있습니다.

예를 들어, deflate는 Safari 4.0에서 작동하지만 Safari 5.1에서는 손상되었으며 항상 IE에 문제가 있습니다.

따라서 가장 좋은 방법은 수축을 완전히 피하는 것입니다. 애들러 32로 인한 작은 속도 향상은 페이로드가 부러 질 위험이 없습니다.

GZip은 단순히 수축 및 체크섬 및 머리글 / 바닥 글입니다. 그러나 어려운 방법을 배웠 으므로 수축 이 더 빠릅니다 .

실제로 옵션으로 수축을 선택하지 못할 수도 있습니다. mod_deflate 가 deflate를 사용하지 않고 gzip을 사용 하는 것과 반대로 . 따라서 대부분의 포인트가 유효하지만 대부분 관련이 없습니다.

gzip은 기본적으로 수축으로 둘러 싸인 헤더이기 때문에 수축과 gzip 사이에는 큰 차이가 없다고 생각합니다 (RFC 1951 및 1952 참조).

주된 이유는 디 플레이트가 gzip보다 인코딩 속도가 빠르며 사용량이 많은 서버에서 차이가 발생할 수 있기 때문입니다. 정적 페이지에서는 한 번만 쉽게 사전 압축 할 수 있으므로 다른 질문입니다.

mod_deflate는 서버에서 더 적은 리소스를 필요로하지만 압축 량 측면에서 약간의 페널티를 지불 할 수도 있습니다.

많은 작은 파일을 제공하는 경우 압축 및 압축되지 않은 솔루션을 벤치마킹하고로드 테스트하는 것이 좋습니다. 압축을 활성화해도 비용이 절약되지 않는 경우가 있습니다.

압축 해제시 gzip & deflate에는 차이가 없어야합니다. Gzip은 체크섬을 포함하여 수십 바이트 헤더로 감싸 져 있습니다. 체크섬은 압축 속도가 느린 이유입니다. 그러나 수십억 개의 파일을 사전 압축 할 때 해당 체크섬을 파일 시스템에서 온 전성 검사로 사용하려고합니다. 또한 명령 줄 도구를 사용하여 파일에 대한 통계를 얻을 수 있습니다. 우리 사이트에는 수많은 정적 데이터 (전체 오픈 디렉토리, 13,000 게임, 수백만 개의 키워드에 대한 자동 완성 등)를 사전 압축하고 있으며 Alexa는 모든 웹 사이트보다 95 % 빠른 순위를 기록했습니다. 팩스 검색. 그러나 우리는 자체 개발 한 독점 웹 서버를 사용합니다. 아파치 / mod_deflate는 그것을 자르지 않았습니다. 이러한 파일이 파일 시스템으로 압축되면 파일 시스템의 최소 크기로 파일을 검색 할뿐 아니라 웹 서버가 신경 쓸 수없는 파일 시스템에서 파일을 관리 할 때 불필요한 모든 오버 헤드가 발생합니다. 총 디스크 풋 프린트와 액세스 / 압축 해제 시간 및이 데이터를 미리 압축 할 수있는 속도의 이차 문제가 있어야합니다. 디스크 공간이 저렴하더라도 가능한 한 캐시에 맞추기를 원하기 때문에 설치 공간이 중요합니다.

Apache2 및 deflate 모듈이 이미 설치된 Ubuntu에서 (기본값) deflate gzip 압축을 두 단계로 쉽게 활성화 할 수 있습니다 .

a2enmod deflate
/etc/init.d/apache2 force-reload

그리고 당신은 멀리있어! 내 광고 연결을 통해 게재 된 페이지가 훨씬 빠르게로드되는 것을 발견했습니다.

편집 : @GertvandenBerg의 의견에 따라 이것은 수축하지 않고 gzip 압축을 가능하게합니다.

내가 정확하게 기억한다면

• gzip은 수축보다 약간 더 압축합니다
• 수축이 더 효율적입니다