pipe mode and sendfile?

Poul-Henning Kamp phk at phk.freebsd.dk
Tue Mar 29 10:51:17 CEST 2016


--------
In message <CAOXZevDF-6QWg8JxdpcHaZHWUYzr9Cj8B4YqQ0qVQ_0A9DuyHA at mail.gmail.com>
, Per Buer writes:

There is a very big elephant in this room: "what does 'pipe' mean in HTTP/2"

One option is to make it connection based, like H1, in which case
vcl_recv{} is far too late to decide it.

The other option is to make it stream based, in which case vcl_recv{}
will only work for streams which look like HTTP, which are probably
the least useful ones to do it to.

My current thinking is that we need to split vcl_recv{} into
the moral equivalent of vcl_sess{} and vcl_req{}.

It's tempting to keep the vcl_recv{} name for vcl_req{}, but
if history is any guide we will regret that decision later on
and biting the bullet is probably the right thing.

So vcl_sess{} would allow you to do things with the 4 ip numbers
and the protocol type (H1/H2/whatever) but you do not have a request.

For H2 vcl_sess{} probably has access to the HEADERS, and if the
PROXY offers it, also ALPN and client cert info.  This is where you
decide to pipe the entire connection.

vcl_req{} is where we have a HTTP request.

This only allows us to pipe per connection, but not per stream, and
in particular it does not allow H1 to switch to piping after the
first request.

If we want per-stream piping, we need also vcl_http1_stream{} and
vcl_http2_stream{} to decide that, and now it gets really messy.
Do we give vcl_http1_stream{} access to req.* ?  Do we give
vcl_http2_stream{} access to the frame that opened the stream or
do we attempt to turn it into a req.* ?  And how does H2 pipe-per-stream
even work in the first place ?  Do we even know which shared state
we have to synchronize ?

So my inclination at this point is to say "pipe is per connection".

If we do that, the only remaining question is if we should allow
a hac^H^H^Hcat-flap so H1 can still switch to pipe in vcl_req{} ?

And it definitively settles the question if pipe should always
start on a new backend connection, which again, enables us to
send PROXY headers if we want to.

Comments ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.



More information about the varnish-dev mailing list