On 29 Jun 2020, at 10:16, Stefan Eissing <[email protected]> wrote:
>> The main point is that it must be done carefully and properly, but this is >> not a reason to not do it at all. > > Apache httpd is a very strong HTTP/1.x server. And your efforts to make > response streaming more event driven have been great. > > However it has resulted in code that is, in my impression on talks on the dev > list regarding Yann's changes, very hard to read and improve. Not impossible, > but not for the meek. And not because it is written badly, but because the > state handling and interactions between buckets and pools is complex and full > of pitfalls. > But if it's done properly, as you say, it works nicely. Where the h2 effort was made hard, was that it was done within the limitation that httpd wasn’t changed to accommodate your needs. H2 exists with the existing event MPM, the existing network filter, and the existing mod_ssl filter. Hats off to you for what you’ve achieved, but there reaches a point where you have to stop and say “what does httpd need to do for me that it doesn't do now”. You then ask a second question - “if I need to change httpd, where would I change it”. Right now, today, we have the following tools at your disposal: - An MPM. This translates between the architecture specific to each client, and httpd. - The network filter. This creates a TCP connection on any platform. - mod_ssl. This adds an SSL layer to a TCP connection. - mod_http. Turns a connection (conn_rec) into a request (request_rec). So, lets see what you might need. - A UDP based protocol needs UDP based services from the operating system. I predict a new MPM called mpm_event+ that can do generic TCP and UDP. You don't write this from scratch - fork mpm_event, and work from there. - The network filter. This might make your life hard and get in the way, you might choose to scrap the network filter, or move the network filter further down. - mod_ssl. Looks like this would be replaced completely with a mod_h3. - mod_http - maybe that’s still here, maybe it’s mod_h3’s job, not sure. What you need to acknowledge: - People want to write there own server extensions, be they modules, python code, etc etc. That code may not work. - People will call blocking code. - H3 code will need to cater for when - not if - people write either bad code or blocking code. - This is not a showstopper, this just needs to be catered for. Prefork catered for it by giving a dedicated process to every bit of code. Worker gave a thread to each bit of code, and accepted if one thread crashed so would the others. Event catered by being Worker, with the option of being async after the initial work was done. - Having an async “core” interacting over unix domain sockets or the like with code that is free to block, crash, leak, etc means we remain bulletproof in the real world. > For anyone thinking about bringing h3 into the server, consider your options: > 1. Think of a mod_h3 as its own h3->h1 proxy. Open a h1 connection for every > quic stream, write a h1 request, read (often event based, often not) a h1 > response from it, transform this to your h3 answer. Stay away from touching > the server's h1 stasis field - cope with it. > 2. Redesign a FOSS httpd v3.x with a new architecture, embracing a > non-blocking processing model. Maybe under a different name. Option 2 has been done, over and over. Where option 2 falls flat is that after the initial euphoric implementation is made, the really non sexy work of protocol compliance begins, testing begins, and so on. Apache httpd started to support RFC2616 in 1999 when it was published, but httpd only properly supported RFC2616 14 years later in 2013 when we were generously gifted access to a compliance test suite, and I spent 2 solid weeks of my life killing every protocol violation reported. You don’t want to start from scratch, trust me. I recommend the following: - Start the work on a branch, but ultimately you want this to be in httpd trunk. No rewrites. - Look at what a mod_event+ MPM might need to do to provide the UDP and TCP services you need. No sacred cows, if you need to change something, change it. - Look at mod_ssl and mod_http, and ask what a mod_h3 might do to replace them both. - Look at how a mod_h3 might create a request (request_rec), and how it might process it. Do you want to insulate people from blocking/crashing code here or higher up? How might the MPM help here? Regards, Graham —
