What is the advantage of GZIP vs DEFLATE compression?
I have a web site in asp.NET 4 (C#).
I’m trying to find a way to better optimize bandwidth for my website.
I read many articles saying that DEFLATE is faster and smaller that GZIP because GZIP (based on DEFLATE) adds some extra data.
Checking the headers of bing.com and google.com it seems that they both send GZIP-encoded data.
Assuming what I read is true, I miss the advantage of GZIP in this case. So I suspect there should be a good reason to prefer GZIP to DEFLATE.
My questions:
- Does GZIP offer any advantage over DEFLATE I'm not aware of?
- Any clue why major search engines use GZIP?
Here’s the code I’m using to send DEFLATE (from Global.asax):
protected void Application_PreRequestHandlerExecute(object sender, EventArgs e)
{
H开发者_高级运维ttpApplication app = sender as HttpApplication;
string acceptEncoding = app.Request.Headers["Accept-Encoding"];
Stream prevUncompressedStream = app.Response.Filter;
if (!(app.Context.CurrentHandler is Page ||
app.Context.CurrentHandler.GetType().Name == "SyncSessionlessHandler") ||
app.Request["HTTP_X_MICROSOFTAJAX"] != null)
return;
if (acceptEncoding == null || acceptEncoding.Length == 0)
return;
acceptEncoding = acceptEncoding.ToLower();
if (acceptEncoding.Contains("deflate") || acceptEncoding == "*")
{
// defalte
app.Response.Filter = new DeflateStream(prevUncompressedStream,
CompressionMode.Compress);
app.Response.AppendHeader("Content-Encoding", "deflate");
}
else if (acceptEncoding.Contains("gzip"))
{
// gzip
app.Response.Filter = new GZipStream(prevUncompressedStream,
CompressionMode.Compress);
app.Response.AppendHeader("Content-Encoding", "gzip");
}
}
Gzip is the more reliable because it is deflate plus a few headers and a check sum. In other words gzip is deflate, and extra headers and check sum. Deflate is checked with adler32, which is also part of gzip. Because the gzip payload is a DEFLATE-compressed payload.
Deflate info
Gzip info
a gzip file/stream contains:
- a 10-byte header, containing a magic number, a version number and a time stamp - optional extra headers, such as the original file name, - a body, containing a DEFLATE-compressed payload - an 8-byte footer, containing a CRC-32 checksum and the length of the original uncompressed data
The other answer is mostly wrong. The "deflate" value for the Content-Encoding
HTTP header is a misnomer that actually means ZLIB. Given that, both have checksums and the same compressed content. They only differ in their headers/footer and which checksum they use.
gzip | "deflate" (zlib) | |
---|---|---|
Header size | 10 bytes | 2 bytes |
Footer size | 4 bytes | 0 |
Checksum | CRC32 | Adler-32 |
Compression algorithm | DEFLATE | DEFLATE |
Specification | RFC1952 | RFC1950 |
Historically, "deflate" was problematic because early Microsoft IIS servers would send raw deflate data instead of zlib data (see https://stackoverflow.com/a/9186091/1218408). To work around that, it became common to just use gzip.
Deflate is very slightly faster because Adler-32 is typically faster to compute than CRC32, but the majority of the time is spent actually compressing data and not calculating the checksum.
精彩评论