Perché usare deflate invece di gzip per i file di testo forniti da Apache?

Quali vantaggi offrono entrambi i metodi per i file html, css e javascript serviti da un server LAMP. Ci sono alternative migliori?

Il server fornisce informazioni a un'applicazione cartografica tramite Json, quindi un volume elevato di piccoli file.

Vedi anche C'è qualche hit delle prestazioni coinvolto nella scelta di gzip su deflate per la compressione http?

Perché usare deflate invece di gzip per i file di testo forniti da Apache?

La semplice risposta è no .

RFC 2616 definisce deflate come:

deflate Il formato "zlib" definito in RFC 1950 in combinazione con il meccanismo di compressione "deflate" descritto in RFC 1951

Il formato zlib è definito in RFC 1950 come:

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

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

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

Quindi, alcune intestazioni e un checksum ADLER32

RFC 2616 definisce gzip come:

gzip Un formato di codifica prodotto dal programma di compressione file "gzip" (GNU zip) come descritto in RFC 1952 [25]. Questo formato è un codice Lempel-Ziv (LZ77) con un CRC a 32 bit.

RFC 1952 definisce i dati compressi come:

Il formato attualmente utilizza il metodo di compressione DEFLATE ma può essere facilmente esteso per utilizzare altri metodi di compressione.

CRC-32 è più lento di ADLER32

Rispetto a una verifica di ridondanza ciclica della stessa lunghezza, scambia affidabilità e velocità (preferendo quest'ultima).

Quindi ... abbiamo 2 meccanismi di compressione che usano lo stesso algoritmo per la compressione, ma un algoritmo diverso per intestazioni e checksum.

Ora, i pacchetti TCP sottostanti sono già abbastanza affidabili , quindi il problema qui non è Adler 32 vs CRC-32 che utilizza GZIP.

Risulta che nel corso degli anni molti browser hanno implementato un algoritmo di deflazione errato. Invece di aspettarsi l'intestazione zlib in RFC 1950, si aspettavano semplicemente il carico utile compresso. Allo stesso modo vari server Web hanno commesso lo stesso errore.

Pertanto, nel corso degli anni i browser hanno iniziato a implementare un'implementazione deflate della logica fuzzy , provano per l'intestazione zlib e il checksum adler, se ciò fallisce provano per il payload.

Il risultato di avere una logica complessa come quella è che è spesso rotto. Verve Studio ha una sezione di test fornita dall'utente che mostra quanto sia grave la situazione.

Ad esempio: deflate funziona in Safari 4.0 ma è rotto in Safari 5.1, inoltre presenta sempre problemi su IE.

Quindi, la cosa migliore da fare è evitare di sgonfiare del tutto, l'aumento di velocità minore (dovuto all'adler 32) non vale il rischio di carichi utili interrotti.

GZip è semplicemente sgonfiare più un checksum e un'intestazione / piè di pagina. Deflate è più veloce , però, come ho imparato nel modo più duro.

Probabilmente non è possibile selezionare deflate come opzione. Contrariamente a quanto ci si può aspettare, mod_deflate non utilizza deflate ma gzip. Quindi, sebbene la maggior parte dei punti formulati siano validi, probabilmente non è rilevante per la maggior parte.

Penso che non ci sia grande differenza tra deflate e gzip, perché gzip è fondamentalmente solo un'intestazione racchiusa tra deflate (vedi RFC 1951 e 1952).

Il motivo principale è che deflate è più veloce da codificare rispetto a gzip e su un server occupato che potrebbe fare la differenza. Con le pagine statiche è una domanda diversa, poiché possono essere facilmente precompresse una volta.

mod_deflate richiede meno risorse sul tuo server, anche se potresti pagare una piccola penalità in termini di quantità di compressione.

Se stai offrendo molti file di piccole dimensioni, ti consiglio di eseguire il benchmarking e testare il carico delle tue soluzioni compresse e non compresse - potresti trovare alcuni casi in cui abilitare la compressione non comporterà risparmi.

Non ci dovrebbe essere alcuna differenza in gzip e deflate per la decompressione. Gzip viene semplicemente sgonfiato con un'intestazione di poche decine di byte avvolta attorno ad esso, incluso un checksum. Il checksum è il motivo della compressione più lenta. Tuttavia quando precomprimi miliardi di file vuoi quei checksum come controllo di integrità nel tuo filesystem. Inoltre, puoi utilizzare gli strumenti da riga di comando per ottenere statistiche sul file. Per il nostro sito stiamo precomprimendo un sacco di dati statici (l'intera directory aperta, 13.000 giochi, il completamento automatico per milioni di parole chiave, ecc.) E siamo classificati al 95% più veloci di tutti i siti Web da Alexa. Ricerca fax. Tuttavia, utilizziamo un server Web proprietario cresciuto in casa. Apache / mod_deflate non l'hanno tagliato. Quando questi file vengono compressi nel filesystem non solo si ottiene un hit per il file con la dimensione minima del blocco del filesystem ma tutto l'overhead non necessario nella gestione del file nel filesystem di cui al server web potrebbe interessare di meno. Le vostre preoccupazioni dovrebbero essere il footprint totale del disco e il tempo di accesso / decompressione e la velocità secondaria nel poter ottenere questi dati precompressi. L'impronta è importante perché anche se lo spazio su disco è economico, si desidera che il più possibile si inserisca nella cache.

Su Ubuntu con Apache2 e il modulo deflate già installato (che è di default), puoi abilitare la compressione deflate gzip in due semplici passaggi:

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

E tu sei via! Ho trovato le pagine pubblicate sulla mia connessione adsl caricate molto più velocemente.

Modifica: come da commento di @ GertvandenBerg, questo abilita la compressione gzip, non lo sgonfiamento.

se ricordo bene

• gzip comprime un po 'di più che sgonfiare
• sgonfiare è più efficiente