Re: why not multiple, short-lived HTTP/2 connections?

On Tue, Jun 24, 2014 at 10:50 AM, <bizzbyster@gmail.com> wrote:

> I've raised this issue before on the list but it's been a while and
> reading Mark's ops guide doc (https://github.com/http2/http2-spec/wiki/Ops) I'm
> reminded that requiring the use of a single connection for HTTP/2 ("Clients
> SHOULD NOT open more than one HTTP/2 connection") still makes no sense to
> me. Due to multiplexing, HTTP/2 will naturally use FEWER connections than
> HTTP/1, which is a good thing, but requiring a single connection has the
> following drawbacks:
>
>
>    1. Servers must keep open idle connections, making load balancing more
>    complex and creating DOS vulnerability.
>
>
As others have mentioned, you don't have to do this.

>
>    1. Servers must turn off *tcp_slow_start_after_idle* in order for
>    browsers to get good performance, again creating DOS vulnerability.
>
> You also don't have to do this; it will drop back to init cwnd levels if
you do, just as though you had opened a fresh connection.


>
>    1. The number of simultaneous GET requests I'm able to upload in the
>    first round trip is limited to the compressed amount that can fit in a
>    single initcwnd. Yes compression helps with this but if I use multiple
>    connections I will get the benefit of compression for the requests on the
>    same connection, in addition to having multiple initcwnds!
>
> It turns out that a larger initcwnd just works better anyway - there was a
tremendous amount of evidence supporting going up to 10, and that was
accepted at in the transport level already.


>
>    1. The amount of data I'm able to download in the first round trip is
>    limited to the amount that can fit in a single initcwnd.
>
> It turns out the browser doesn't really know how many connections to open
until that first resource is downloaded anyway.  Many out-of-band tricks
exist.


>
>    1. Head of line blocking is exacerbated by putting all objects on a
>    single connection.
>
> Yeah, this is true.  But overall, its still faster and more efficient.




>
> Multiple short-lived HTTP/2 connections gives us all the performance
> benefits of multiplexing without any of the operational or performance
> drawbacks. As a proxy and a browser implementor, I plan to use multiple
> HTTP/2 connections when talking to HTTP/2 servers because it seems like the
> right thing to do from a performance, security, and operational perspective.
>

When I tested the multi-connection scenarios they were all slower for me.
 In cases of severe packet loss, it was difficult to discern as expected.
 But overall, the reduced server resource use and the efficiency outweighed
the negatives.

Mike



>
> I know it's very late to ask this but can we remove the "SHOULD NOT"
> statement from the spec? Or, maybe soften it a little for those of us who
> cannot understand why it's there?
>
> Thanks,
>
> Peter
>