The header compression in HTTP 2.0 isn't based on gzip or something like that. The CRIME attack pretty much killed those approaches dead. It's more akin to differential updates for header during the lifetime of the connection. So if you request a lot of files with fairly similar headers you'll effectively only have to transmit the bulk of the header once while the other request will efficiently re-use the previously transmitted fields.

So to answer your question: Header compression as employed in HTTP 2.0 helps if you do many requests with similar headers on the same connection.

> So to answer your question: Header compression as employed in HTTP 2.0 helps if you do many requests with similar headers on the same connection.

In general, HTTP/2.0 seems to be about improving things if you do many requests over the same connection.

I think this is correct - because that is one big area where TCP and HTTP really fall short.

HTTP/2 should be a huge improvement for lowering latency in anything but the simplest web sites, without having to use ugly hacks such as sprite sheets and putting all your javascript/CSS in one file (which is sub-optimal in terms of caching if you want to update say a single javascript file, because then a user with a full cache has to re-download the huge concatenated javascript file instead of just the single source that changed), and avoiding spanning things across multiple domains to get around browsers having a connection limit.

Doing many requests over the same connection is very common.

And one of the fundamental goals of HTTP/2 was to get clients to create only a single connection to a server.

right. The other key fact is that request header compression is necessary to make parallelism work when interacting with tcp congestion control. Its critical.

> Am I missing something?

Google has about 200 different tracking cookies with lots of redundancies which is compressed sufficiently better than that.

Google's aim with SPDY was to be able to track you across all HTTP-requests without the bloat of the tracking-cookies causing you to exceed a normal ADSL MTU-size and thus having the tracking cause packet-fragmentation and potentially reduced performance.

Possibly good goals for all the wrong reasons. And again it's Google's needs above those of the internet at large.

As far as I can tell, the compression is separate for the headers, does not use deflate, and (most importantly) is over the entire session, not just one request.

This would benefit from the fact that in one request headers are not repeated, but over multiple requests they certainly are.

http://www.greenbytes.de/tech/webdav/draft-ietf-httpbis-head...