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

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로 인한 작은 속도 향상은 페이로드가 부러 질 위험이 없습니다.

---

답변