Zmniejsz kompatybilność przeglądarki i zalety kompresji w porównaniu z GZIP

91

AKTUALIZACJA 10 lutego 2012:

zOompf zrealizowała kilka bardzo dokładnych badań na ten sam temat tutaj . Przeważa to wszystkie poniższe ustalenia.

AKTUALIZACJA 11 września 2010:

Platforma testowania został stworzony dla tego tutaj



Definicje HTTP 1.1 GZIP i DEFLATE (zlib), aby uzyskać dodatkowe informacje:

„„ Gzip ”to format gzip, a „ deflate ”to format zlib . Prawdopodobnie powinni zamiast tego nazwać drugi format „ zlib ”, aby uniknąć nieporozumień z formatem danych skompresowanych danych surowych deflate. Chociaż protokół HTTP 1.1 RFC 2616 prawidłowo wskazuje na specyfikacji zlib w RFC 1950 dla kodowania transferu „deflate”, pojawiły się doniesienia o serwerach i przeglądarkach, które niepoprawnie wytwarzają lub oczekują nieprzetworzonych danych deflate zgodnie ze specyfikacją deflate w RFC 1951, w szczególności w produktach firmy Microsoft . Tak więc, nawet jeśli „deflate” przesyłanie kodowania przy użyciu formatu zlib byłoby bardziej wydajnym podejściem ( i właściwie do czego został zaprojektowany format zlib), użycie kodowania transferu „gzip” jest prawdopodobnie bardziej niezawodne ze względu na niefortunny wybór nazwiska ze strony autorów HTTP 1.1. ”(źródło: http://www.gzip.org/zlib/zlib_faq.html )

Więc, moje pytanie: jeśli wyślę dane RAW deflate BEZ opakowania zlib (lub gzip, jeśli o to chodzi), czy są jakieś nowoczesne przeglądarki (np. IE6 i nowsze, FF, Chrome, Safari itp.), Które NIE mogą zrozumieć surowego deflatu skompresowane dane (zakładając, że nagłówek żądania HTTP „Accept-Encoding” zawiera „deflate”)?

Dane opróżnione będą ZAWSZE o kilka bajtów mniejsze niż GZIP.

Jeśli wszystkie te przeglądarki mogą pomyślnie dekodować dane, jakie są wady wysyłania deflate RAW zamiast zlib?



AKTUALIZACJA 11 września 2010:

Platforma testowania został stworzony dla tego tutaj

optimization compression gzip zlib deflate David Murdoch
źródło
1
Czy mógłbyś wyjaśnić, dlaczego System.IO.Compression.DeflateStream jest do bani w porównaniu z zlib.net? Google nie pokazuje mi zbyt wielu informacji, z wyjątkiem jednej osoby, która wspomina o tym, że „nie ma szczególnie dobrego współczynnika kompresji”.
Joel Mueller
Racja, współczynnik kompresji dla obu metod gzip i deflate nie wydaje się być nawet zbliżony do tego, jaki powinien. Jednak nie wykonałem żadnych testów porównawczych szybkości między nimi (zlib.net vs. natywny .net).
David Murdoch,
Dlaczego po prostu nie zapiszesz wyników swojego przypadku testowego?
Gumbo
1
Szperałem w bibliotece System.IO.Compression i wydaje się, że używa statycznego / wstępnie zdefiniowanego drzewa - w związku z tym kompresja nie jest zoptymalizowana dla określonego strumienia. Powinna być najszybszą metodą, ale zdecydowanie zapewni słabe współczynniki kompresji.
Brady Moritz
2
@JoelMueller To może wyjaśniać: virtualdub.org/blog/pivot/entry.php?id=335
Nayuki

Odpowiedzi:

37

AKTUALIZACJA: przeglądarki przestały obsługiwać nieprzetworzone opróżnianie. zOompf zrealizowała kilka bardzo dokładnych badań na ten sam temat tutaj . Niestety wygląda na to, że surowy deflat NIE jest bezpieczny w użyciu.

Sprawdzić http://www.vervestudios.co/projects/compression-tests/results więcej wyników.

Oto przetestowane przeglądarki:

/*  Browser                       DEFLATE      ZLIB     */
    XP Internet Explorer 6        PASS         FAIL
    XP Internet Explorer 7        PASS         FAIL
    XP Internet Explorer 8        PASS         FAIL
    Vista Internet Explorer 8     PASS         FAIL
    XP Firefox 3.6.*              PASS         PASS
    XP Firefox 3.5.3              PASS         PASS
    XP Firefox 3.0.14             PASS         PASS
    Win 7 Firefox 3.6.*           PASS         PASS
    Vista Firefox 3.6.*           PASS         PASS
    Vista Firefox 3.5.3           PASS         PASS
    XP Safari 3                   PASS         PASS
    XP Safari 4                   PASS         PASS     
    XP Chrome 3.0.195.27          PASS         PASS
    XP Opera 9                    PASS         PASS
    XP Opera 10                   PASS         PASS
    XP Sea Monkey 1.1.8           PASS         PASS
    Android 1.6 Browser (v4)*     N/A          N/A
    OS-X Safari 4                 PASS         PASS
    OS X Chrome 7.0.517.44        PASS         PASS
    OS X Opera 10.63              PASS         PASS
    iPhone 3.1 Safari             PASS         PASS

* Android wysyła nagłówek żądania HTTP „Accept-Encoding: gzip”. Opróżnianie nie jest dozwolone.


Wnioskuję, że zawsze możemy wysłać nieprzetworzone DEFLATE (gdy nagłówek żądania HTTP „Accept-Encoding” zawiera „deflate”), a przeglądarka będzie mogła poprawnie zinterpretować zakodowane dane. Czy ktoś może to udowodnić?

Uwaga: natywna implementacja DEFLATE (System.IO.Compression.DeflateStream) w .NET to surowy DEFLATE. To też jest do bani. Proszę używać zlib.net do wszystkich potrzeb związanych z deflacją .NET.

David Murdoch
źródło
1
Czy możesz podać bardziej szczegółowe informacje na temat używania zlib.net do deflacji? Jak to pasuje do powyższego wykresu, gdzie jest napisane, że surowe deflate działa, ale zlib nie w niektórych przypadkach XP IE?
David Eison
Android obsługuje kompresję deflate od API 9. zobacz: developer.android.com/reference/java/util/zip/ ... po więcej informacji
Stuart Blackler
1
@DavidMurdoch jedyny rozsądny wynik z twoich testów wydaje się nigdy nie używać deflate , vervestudios.co/projects/compression-tests/results Myślę, że ta odpowiedź powinna zostać zredagowana, aby to odzwierciedlić
Sam Saffron
Tak, zgadzam się. Aktualizuję to teraz.
David Murdoch
6

Przeglądarka systemu Android 1.6 (v4) nie przechodzi testu zlib i deflate na Twojej stronie. Dodałem to do twojej listy.

Josef Pfleger
źródło
Dzięki! Jakie kodowanie treści wysyła przeglądarka Androida?
David Murdoch
Wysyła „Accept-Encoding: gzip”.
Josef Pfleger
1

Czy nie jest tak, że AddOutputFilterByType DEFLATEużycie mod_deflate domyślnie wysyła przez gzip?

Paul Irish
źródło
1
Hej Paul, czuję się, jakbym rozmawiał z celebrytą ... jesteś wszędzie. :-) W każdym razie AddOutputFilertByType DEFLATEgzipuje odpowiedź zamiast domyślnie ją opróżniać (o ile wiem). Gzipto deflate+ 10-bajtowy nagłówek + 8-bajtowa stopka - co oznacza, że GzipZAWSZE będzie większe niż deflate... więc dlaczego mielibyśmy kiedykolwiek używać programu gzip? (zobacz en.wikipedia.org/wiki/Gzip#File_format, aby dowiedzieć się, z czego składa się gzip). Mając to deflatena uwadze , nie jestem pewien, jak ustawić jako preferowaną metodę kompresji w Apache.
David Murdoch
-1

o ile wiem, tak - prawie zawsze można wysłać surowy DEFLATE i wszystko byłoby w porządku… nie jest „zawsze”, ale w większości przypadków. jeśli nie, jest to problem przeglądarki.

listonosz
źródło
Próbuję znaleźć przypadki, w których nie udaje się opróżnić surowego powietrza. Zgodnie ze specyfikacją powinien zawieść we wszystkich przeglądarkach.
David Murdoch,
Raw deflate(tj. Nie zlib , bez nagłówków) będzie działać tylko w IE7, jeśli encoding:gzipi (testowane tylko w chrome v24) encoding:deflatew chrome .
Scotty.NET