RE: Stuck in a train -- reading HTTP/2 draft.

> >That is a good point.  https://github.com/http2/http2-spec/issues/529

I've been working on the assumption that SETTINGS_MAX_CONCURRENT_STREAMS applies only to a single connection up to now.
I'm not sure how else it makes sense.

> If we state up front that clients SHALL NOT have more than one TCP connection opened to the same
> destination IP#, then we lay the ground work for the first layer of DoS mitigation strategy without seriously inconveniencing any normal clients.

> But unless servers somehow detect client side proxies and offer them a much more generous SETTINGS_MAX_CONCURRENT_STREAMS,
> service to clients behind those proxies will suck, in direct proportion to the number of clients behind the proxy.

Even this wouldn't be sufficient. You need multiple TCP connections. Without it, you'd have to assume connection coalescing on the
proxy- which I don't think is a given. Moreover, I don't believe it's desirable in many places. In particular, if the upstream maybe doing
some form of identification (of user, of organization, of geography, ...) based on the incoming source IP or if the proxy itself is incapable
of efficiently restricting itself to a single TCP connection. Let's take CWS for example. What is a CWS proxy? It's actually a set of multiple
servers load-balanced behind a single IP - there's no way in which we're sharing a single TCP connection for a dozen servers and
10,000+ users.

On the other hand, if you don't enforce constraints for proxies then there's a simple workaround for a client that wants to misbehave
pretend to be a proxy.

> The necessary logic to tell a proxy from a client from a hostile DoS-zombie is neither going to be pretty nor particularly efficient

Yup. No argument on this bit.

Richard

Received on Thursday, 19 June 2014 18:21:07 UTC