>From the 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.
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.
This would provide some of the benefit of header compression without any of the opaqueness downside.
On Sun, Apr 1, 2012 at 12:39 AM, Willy Tarreau <w@...> wrote: > > On Fri, Mar 30, 2012 at 03:22:12PM +0200, Mike Belshe wrote: > > What is "transparency on the wire"? You mean an ascii protocol that you
> > can read? I don't think this is a very interesting goal, as most people > > don't look at the wire. > > I agree with you here Mike, despite being used to look at network captures
> all the day and testing proxies with "printf|netcat" at both ends. But we > must admit that if developers need tools, they will develop their tools. > Having an HTTP option for netcat would work well, or even having an 1.1-to-2.0
> and 2.0-to-1.1 message converter on stdin/stdout would do the trick. So I > prefer to lose the ability to easily debug and have something efficient than > the opposite. And it costs me a lot to say this :-)
> > Willy >