Re: SPDY Review

On Thu, 07 Jun 2012 19:43:09 +0200, Alek Storm <alek.storm@gmail.com>  
wrote:

>
> 4.3. Specialized HTTP frames
>>
>>  For the common case of using SPDY as an HTTP substitute, create
>>  special frames to open HTTP request-response and HTTP push
>>  streams. This removes the need for explicit unidirectional flag and
>>  mandatory header values.
>>
>
> The UNIDIRECTIONAL flag is set to be removed in spdy/4. Elsewhere, you
> advocate moving information specific to request-response and pushed  
> streams
> to the headers section, which appears to conflict with this proposal.

Some of the proposals are mutually exclusive, yes.

>
> 4.4. Typed key-value pairs
>>
>>  Create a better structure for the key-value pair lists where it is
>>  possible to have binary values and typed values. The types can
>>  include binary string, integer and list. Standardize how all
>>  standard HTTP headers should be normalized and typed, including
>>  which ones are disallowed to be in lists of multiple values.
>>
>
> This sounds like a can of worms. Depending on the serialization format  
> you
> look at, there's already a zoo of possible "types" to encode data as -  
> and
> what if you want something outside the norm, like JSON? The only problem
> you raised with the current encoding is that binary data would have to be
> escaped; this looks like overkill.

One complaint that perhaps doesn't come across as clear as it should is  
that the current SPDY serialization takes more space than HTTP (c.f. table  
in 2.4.1). If you are moving away from HTTP, and thus not reusing existing  
protocol code, it's reasonable to consider alternative encodings as well.  
Types here doesn't refer to anything more exotic than the examples given  
(string, integer, list). To encode a time stamp like "Thu, 29 Apr 2010  
13:36:52 GMT" as a 64 bit integer doesn't appear as a radical suggestion  
to me.

>
> 4.7. Header compression
>>
>>  Remove the header compression dictionary. It creates little benefit
>>  for the added complexity it introduces.
>>
>
> This paper (http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf)
> claims 8% size reduction of the request header and an additional 15%
> reduction of the reply header. Giving more detail on the benchmarks you
> cited earlier would help us evaluate the differing results.

It claims an 8/15% improvement over the previous dictionary, but doesn't  
compare it with the no dictionary case. Doing some simple tests over 5000  
requests I see about 15% additional compression on requests and 25% on  
response headers for the first request. For subsequent requests dictionary  
only gives a few bytes extra savings. Somewhat better compression on the  
response side with about 10-20 bytes savings, but then dwarfed by the  
actual payload.

/Martin Nilsson

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Received on Friday, 8 June 2012 16:27:34 UTC