Re: Overhead of HTTP/2 Stream Management.

[Max Bruce <[e-mail]>]

The way HTTP works though, we don't need streams in such a conventional and
TCP-like way. We only need multiplexed packets to carry data over, so just
associate request/response pairs with an ID, and allow server push via
server sending the request path in a header too. Why do we even need a
frame structure? It's unnecessary overhead. Same with the virtual streams.

On Sun, Apr 5, 2015 at 11:57 AM, Willy Tarreau <[e-mail]> wrote:

> 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
>
>