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

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel