Graham, I am very happy to get such feedback and start thinking about how to make the http/2 integration tighter. As it is designed now, it was intended to fit into a 2.4.x server which limited several design decisions and resulted in the separate worker pool. Since HTTP/2 changes the processing model for a server (unless you just reverse proxy it in front of the http/1 engine), not all existing parts will fit unchanged.
What you are currently sketching below is that http2 workers need to become one with the mpms and I very much agree. What you described with the socket pairs however sounds much more like a in-process reverse proxy. That, I think, is not so fantastic. For example, a lot of use cases serve static files and for best performance - I think - we need to directly write the file, chunked as needed by the transport, onto the outgoing connection. So, the file bucket (or the handle itself) should find its way from the slave to the master connection. This is what mod_http2 already achieves. Jim invented the slave connections in trunk, where the relation ship between master and slaves is visible to all. This is nice. I could not use them for the 2.4 approach and I think there are some multi-threading issues around pool reclaiming open... But ultimately, the existence of slave connections will become visible to a lot of parts of the server and pretending that we still live in http/1 land becomes harder and harder (or affords more and more compromise). HTTP/2 on https:// connections, as reported by Firefox, is currently at ~30% of requests. //Stefan PS. As to the prefork compatiblity: mod_http2 has by default a single worker thread in this mpm. One can configure more, of course. > Am 08.10.2015 um 12:56 schrieb Graham Leggett <minf...@sharp.fm>: > > On 07 Oct 2015, at 4:30 PM, Stefan Eissing <stefan.eiss...@greenbytes.de> > wrote: > >> In http2 land, the request happen on "pseudo" connections, connections >> properly created by ap_run_create_connection(), but with own filters of type >> AP_FTYPE_PROTOCOL and AP_FTYPE_NETWORK, registered by mod_h2. >> >> These filters copy the data (or move the files) across the processing >> filters thread into the h2 multiplexer (h2_mplx) where the master connection >> thread reads it and send it out to the client, properly framed for HTTP/2. > > Having gone through this in a bit more detail (and slept on it) I > simultaneously see how we needed to do this to reach this point given the > limitations of the server, but at the same time this approach causes a number > of problems that we need to solve in the medium term (which is doable from > what I can see). > > What mod_http2 is doing is creating it’s own “mini-worker-mpm” inside the > module, and this creates a number of problems. The first is that code out > there that cares about being single threaded (historically php, for example) > suddenly finds itself running in a “pseudo-worker” MPM when the actual MPM in > use is prefork. This will cause unexpected breakage for people trying to use > http2. > > The second problem is that with mod_http2 being a “pseudo-mpm”, it needs to > emulate all the functions of an mpm in order to correctly do so. I believe > the problems with async filters are a manifestation of mod_http2 not > implementing all the capabilities of an MPM. We could try and make mod_http2 > do so, but I think ultimately we’re making life hard for ourselves - we > should really be leveraging the MPMs directly to make workers for us instead > of trying to bake workers of our own. > > So, bringing this down to actual practical stuff we can do to make this > happen, the basic problems to solve are: > > - The master connection currently runs under an existing MPM, and this works > fine today. > - The slave connection needs to run under an existing MPM instead of the > “pseudo MPM” it works under today. > - In theory, we can let the master connection and slave connection talk to > each other over two pairs of sockets otherwise created with socketpair() > (workaround for Windows at > http://code.activestate.com/recipes/525487-extending-socketsocketpair-to-work-on-windows/). > - We would need a mechanism to inject the just-created socket into the MPM’s > worker queue (ie in event MPM, call push2worker()), that would be an > additional call to MPMs that could support it. > - When the slave connection is accepted by the worker, the normal request > acceptance mechanism applies. We might signal the connection is an HTTP2 > slave connection on the request line in some way, or perhaps emulate HTTP/1.1 > (not sure if workable), will need to come up with a solution. > > Regards, > Graham > — >
