Re: SPDY Header Frames

In message <CABP7RbdZPYYqtDFWUprrAmGQ8GehOTh-LvXq9gizXGUJg4=68g@mail.gmail.com>
, James M Snell writes:

>3. Values may be binary or character based, as indicated by a flags field.
>Values may be up to max(int32) in length.

Allowing such large fields is counterproductive in my opinion.

No implementation can have a limit that large without becoming
a sitting duck for DoS attacks.

It would be far better to put a realistic, but still generous size
restriction.  Not sure if 16 bits is always enough, but the advantage
will likely outweigh any disadvantages.

>The entire header block is encoded into a structure of 145 bytes in length;
>
[...]
>
>By comparison, the same structure encoded using the existing SPDY HEADER
>block would require 208 bytes sans compression.
>
>After applying compression of the block using the SPDY dictionary, the
>block compresses into 6 compact bytes.
>
>[120, 63, -29, -58, -89, -62]

This is where I think we should be careful about what we measure
and optimize for.

Those six bytes will take a lot more CPU effort to unpack than
your 145 bytes (I think your proposed encoding is quite bloated
btw, but that's not an argument I need to carry for this point).

The really important metric is that most requests fit in a single
MTU.  Inside that limit, expending bytes to gain parsing speed can
be both a good and necessary (for HTTP-routers) tradeoff.

In that view, the difference between six and 208 bytes is not
terribly significant on its own, whereas a difference between
1400 and 1602 bytes would be.

The main and almost only reason requests don't fit in one MTU is
cookies, with a minor side-order of URI and User-Agent,
so if we can design away the need for cookies, we (almost)
don't need the computational complexity of deflate.

And there is another aspect which has me very worried about
deflate at this point in the protocol:  Has anybody tried
to see how big a deflate output they can produce with
a single MTU of input ?

My guestimate is well north of a 1MB.

That's a lot of DoS leverage for a single packet.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Tuesday, 17 July 2012 07:27:41 UTC