Po co używać deflate zamiast gzip dla plików tekstowych obsługiwanych przez Apache?

Jakie zalety oferuje jedna z metod w przypadku plików HTML, CSS i javascript obsługiwanych przez serwer LAMP. Czy są lepsze alternatywy?

Serwer dostarcza informacje do aplikacji mapującej za pomocą Jsona, a więc dużej ilości małych plików.

Zobacz także Czy jest jakiś spadek wydajności związany z wyborem gzip zamiast deflacji do kompresji http?

Po co używać deflate zamiast gzip dla plików tekstowych obsługiwanych przez Apache?

Prosta odpowiedź brzmi : nie .

RFC 2616 definiuje deflację jako:

deflate Format „zlib” zdefiniowany w RFC 1950 w połączeniu z mechanizmem kompresji „deflate” opisanym w RFC 1951

Format zlib jest zdefiniowany w RFC 1950 jako:

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

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

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

Kilka nagłówków i suma kontrolna ADLER32

RFC 2616 definiuje gzip jako:

gzip Format kodowania stworzony przez program do kompresji plików „gzip” (GNU zip), jak opisano w RFC 1952 [25]. Ten format to kodowanie Lempel-Ziv (LZ77) z 32-bitowym CRC.

RFC 1952 definiuje skompresowane dane jako:

Format używa obecnie metody kompresji DEFLATE, ale można ją łatwo rozszerzyć, aby używała innych metod kompresji.

CRC-32 jest wolniejszy niż ADLER32

W porównaniu do cyklicznej kontroli redundancji o tej samej długości, zamienia niezawodność na szybkość (preferując tę ​​drugą).

Więc ... mamy 2 mechanizmy kompresji, które używają tego samego algorytmu do kompresji, ale inny algorytm dla nagłówków i sumy kontrolnej.

Teraz bazowe pakiety TCP są już dość niezawodne , więc problemem nie jest Adler 32 vs. CRC-32, którego używa GZIP.

Okazuje się, że wiele przeglądarek na przestrzeni lat zastosowało nieprawidłowy algorytm deflacji. Zamiast oczekiwać nagłówka zlib w RFC 1950, po prostu oczekiwali skompresowanego ładunku. Podobnie różne serwery internetowe popełniły ten sam błąd.

Tak więc, z biegiem lat przeglądarki zaczęły implementować rozmytą implementację deflacji logicznej , próbują uzyskać nagłówek zlib i sumę kontrolną adlera, jeśli to się nie powiedzie, próbują załadować.

Rezultatem takiej złożonej logiki jest to, że często się psuje. Verve Studio ma sekcję testową napisaną przez użytkownika, która pokazuje, jak zła jest sytuacja.

Na przykład: deflate działa w Safari 4.0, ale jest uszkodzone w Safari 5.1, zawsze ma problemy z IE.

Najlepszym rozwiązaniem jest całkowite spuszczenie powietrza, niewielkie zwiększenie prędkości (z powodu Adlera 32) nie jest warte ryzyka zepsutych ładunków.

GZip to po prostu deflacja plus suma kontrolna i nagłówek / stopka. Deflate jest jednak szybsze , ponieważ nauczyłem się na własnej skórze.

Prawdopodobnie nie jesteś w stanie wybrać opcji deflacji jako opcji. Wbrew oczekiwaniom mod_deflate nie używa deflacji, ale gzip. Tak więc, chociaż większość z podanych punktów jest poprawna, prawdopodobnie nie ma to znaczenia dla większości.

Myślę, że nie ma dużej różnicy między deflate a gzip, ponieważ gzip to po prostu nagłówek owinięty wokół deflate (patrz RFC 1951 i 1952).

Głównym powodem jest szybsze kodowanie deflacji niż gzip na zajętym serwerze, co może mieć znaczenie. W przypadku stron statycznych jest to inne pytanie, ponieważ można je łatwo skompresować raz.

mod_deflate wymaga mniej zasobów na twoim serwerze, chociaż możesz zapłacić niewielką karę za ilość kompresji.

Jeśli udostępniasz wiele małych plików, zalecam testy porównawcze i testowanie obciążenia skompresowanych i nieskompresowanych rozwiązań - możesz znaleźć przypadki, w których włączenie kompresji nie przyniesie oszczędności.

Nie powinno być żadnej różnicy w gzip i deflate do dekompresji. Gzip jest po prostu opróżniany z kilkadziesiąt nagłówków bajtów owiniętych wokół niego, łącznie z sumą kontrolną. Suma kontrolna jest przyczyną wolniejszej kompresji. Jednak gdy kompresujesz zilliony plików, chcesz, aby te sumy kontrolne były sprawdzeniem poprawności w twoim systemie plików. Ponadto można użyć narzędzi wiersza polecenia, aby uzyskać statystyki dotyczące pliku. W przypadku naszej witryny wstępnie kompresujemy masę danych statycznych (cały otwarty katalog, 13 000 gier, autouzupełnianie milionów słów kluczowych itp.) I jesteśmy w rankingu 95% szybciej niż wszystkie strony internetowe autorstwa Alexa. Wyszukiwanie faksu. Korzystamy jednak z własnego, zastrzeżonego serwera internetowego. Apache / mod_deflate po prostu tego nie wyciął. Kiedy te pliki są kompresowane do systemu plików, nie tylko trafiasz w plik z minimalnym rozmiarem bloku systemu plików, ale cały niepotrzebny narzut związany z zarządzaniem plikiem w systemie plików, na którym serwer sieciowy mógłby się mniej przejmować. Twoje obawy powinny dotyczyć całkowitego miejsca na dysku i czasu dostępu / dekompresji, a po drugie szybkości w uzyskaniu wstępnego skompresowania tych danych. Ślad jest ważny, ponieważ chociaż miejsce na dysku jest tanie, chcesz jak najwięcej zmieścić się w pamięci podręcznej.

W systemie Ubuntu z Apache2 i już zainstalowanym modułem deflacji (który jest domyślnie), możesz włączyć kompresję gzip podczas deflacji w dwóch łatwych krokach:

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

I ciebie nie ma! Znalazłem strony wyświetlane przez moje połączenie ADSL ładowane znacznie szybciej.

Edycja: Zgodnie z komentarzem @ GertvandenBerg umożliwia to kompresję gzip, a nie deflację.

Jeżeli dobrze pamiętam

• gzip skompresuje trochę więcej niż deflate
• deflacja jest bardziej wydajna