Re: Overhead of HTTP/2 Stream Management.

On Sun, Apr 05, 2015 at 11:45:53AM -0700, Max Bruce wrote:
> My thoughts is that you just don't use so much overhead. You don't get rid
> of stream IDs, you just don't need so much complex things surrounding it.
> Example: You append a header to HTTP/1.1 request, with a response ID,
> server responds with it. Server can push responses by sending a unsent ID &
> request path in a header.

You still need the stream IDs in the frames themselves so that you know
which stream each frame belongs to.

Multiplexed systems always look simple at first, until you start to
implement them, cover the corner cases (eg: who closes first etc) and
you finally realize once everything is done how much your system looks
like tcp...

There was an elegant (in my opinion) simplification in H/2 compared to
other systems, the stream IDs are always incremented until the largest
encodable ID is reached, which is where a new connection must be used.
I find this elegant because you don't need to keep track of IDs in use
vs available ones and it really simplifies a number of things (eg: no
risk to have late frames from an old stream using the same ID).

It doesn't please me either to have to implement such a complex system
but I am absolutely convinced that it can hardly be simplified further
as long as we want non-blocking, multiplexed streams. I have already
implemented multiplexed streams in the past for some projects, and it
resulted in almost the same design (but more complex).

Willy

Received on Sunday, 5 April 2015 18:58:20 UTC