[PATCH] SPDY/3.1 protocol implementation

[Valentin V. Bartenev]

On Monday 27 January 2014 15:42:26 Piotr Sikora wrote:
> Hey Valentin,
> 
> > Current receiving flow control implementation is pretty simple and 
effective:
> > we allow browser to send as much data as it wants.  That's why it is 
hardcoded
> > to the maximum value.
> >
> > (...)
> >
> > No, it's actually browser's will to properly prioritize POST requests.
> 
> But now you're relying on the browser to do the right thing vs forcing
> the correct behavior via SPDY's flow control.
[..]

Browser is the only guy who can do the right thing in this case.

We just don't have enough information on the server side, e.g. we don't
know when the browser wants to make another request and open a new stream,
or uploading this POST is the most important thing for the moment.  It is
up to browser to pack another bunch of data into DATA frame, or to create 
SYN_STREAM.

The only decision we can make is to limit or not to limit it in its desire.

> 
> > The receiving flow control has two uses for server:
> 
> I'd argue that making sure that requests are multiplexed is also a
> valid use case ;)
> 
> In any case, I'd prefer if this would be configureable value.
> 
> Also, it seems that we should be forcing minimum value for the
> client's window size, otherwise client can set window size to 2 bytes
> and make nginx return thousands of DATA frames and use way too many
> resources to serve a small static page (same is true for Google's &
> Twitter's web servers). This could be a huge (D)DoS-vector.
[..]

Not that simple, on each such frame client have to send WINDOW_UPDATE
for another two bytes.

There is a lot of absolutely legal ways in SPDY to force a server to
do useless job, e.g. you can send hundreds of SYN_STREAMs followed by 
RST_STREAMs with CANCEL status.

And the one you mentioned seems to me like a drop in the ocean.

Currently there is no way to protect from all of the possible cases
without occasionally breaking some clients.  This is one of cons that
users should consider when they decide whether enable spdy or not.

  wbr, Valentin V. Bartenev