- From: Willy Tarreau <w@1wt.eu>
- Date: Sun, 1 Apr 2012 20:14:35 +0200
- To: Peter Lepeska <bizzbyster@gmail.com>
- Cc: ietf-http-wg@w3.org
Hi Peter, On Sun, Apr 01, 2012 at 12:50:20PM -0400, Peter Lepeska wrote: > From the SPDY whitepaper <http://dev.chromium.org/spdy/spdy-whitepaper>, > the primary performance benefit of header compression is in the upload > direction. The benefit can be as much as a 1 second impact for slow DSL > (375 Kbps) links based on these tests. This is primarily due to long > repeating strings in URLs, User Agents, and Cookies. Ideally we could find > a way to reduce the bytes associated with these headers without obscuring > them. The goal is now to optimize every agent in the chain, not to make it easy to read them from a human eye. Something like 1 requests over 1 billion is read by a human, yet networks are full of them and parsers have a lot of difficulties trying to get them right because they're made for humans. Don't get me wrong, I *love* to read captures and to quickly spot what's right or wrong, but people who do this like me are also able to develop some additional tools to continue doing this. > Since a SPDY session is associated with a single TCP connection, we can > assume all GETs on that connection are being routed to the same web server. > This allows us to consider other "compression" schemes for SPDY that will > maintain transparency on the wire, or at least make it easier for tools to > be built to interpret the headers. For instance, in a given TCP connection > / SPDY session, HTTP headers in GETs and responses can be dropped if they > have the same value as previous. If different from previous, only > differences can be sent. This would immediately drop User Agent headers > from all but the first GET. Additionally requests would contain only > cookies whose values are changing, similar to the way that Set-Cookie works > in HTTP responses today. Even URLs could use relative paths from the > previous object. You should then take a look at what is proposed in our draft here, as it's more or less what you're describing, with binary-encoded header field names in order to save more space (stop sending "if-modified-since" for instance) : http://tools.ietf.org/html/draft-tarreau-httpbis-network-friendly-00 Best regards, Willy
Received on Sunday, 1 April 2012 18:15:03 UTC