Re: Ascii-based SPDY "compression" idea

This works IF all the requests get sent to the same web server.  This
is quite possibly not true in particular with GET requests to a large
web-facing property with a sharded cache.  At a deeper level, it
requires more server state, which can be quite expensive in some
cases.

But still, quite a clever idea.

 -T

On Sun, Apr 1, 2012 at 9:50 AM, Peter Lepeska <bizzbyster@gmail.com> wrote:
> >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.
>
> Peter
>
>
>
>
>
>
> On Sun, Apr 1, 2012 at 12:39 AM, Willy Tarreau <w@1wt.eu> 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
>>

Received on Sunday, 1 April 2012 18:18:05 UTC