iOS 14 / macOS 11 and HTTP/3 support

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

iOS 14 / macOS 11 and HTTP/3 support

Alex Hautequest
From Apple’s developer beta release notes, the newest Apple code is now shipping with HTTP/3 support. Disabled by default, but can be enabled by users. As of today, HTTP/3 Draft 29 isn’t yet supported.

Alex
Reply | Threaded
Open this post in threaded view
|

Re: iOS 14 / macOS 11 and HTTP/3 support

Luca Toscano
Hi Alex,

the challenges are the same one discussed in your previous email
thread (https://lists.apache.org/thread.html/eb086eafbd9309eb1efedac3bf3dcc410a95d06206c97e7ade01c254%40%3Cdev.httpd.apache.org%3E).
I think that everybody would love to start working/helping on adding
HTTP/3 support but the work to be done is huge, involves invasive
changes to the httpd's source code and the current dev resources don't
have (rightfully) bandwidth to support the current codebase and plan a
major refactoring.

Having said that: if anybody is interested in helping, the project
would really be grateful (new contributors are always welcome!).

Luca

On Mon, Jun 22, 2020 at 10:47 PM Alex Hautequest <[hidden email]> wrote:
>
> From Apple’s developer beta release notes, the newest Apple code is now shipping with HTTP/3 support. Disabled by default, but can be enabled by users. As of today, HTTP/3 Draft 29 isn’t yet supported.
>
> Alex
Reply | Threaded
Open this post in threaded view
|

Re: iOS 14 / macOS 11 and HTTP/3 support

Helmut K. C. Tessarek
On 2020-06-27 08:48, Luca Toscano wrote:
> the challenges are the same one discussed in your previous email
> thread

These are all valid points, although in the end absolutely irrelevant.

It's very easy and it doesn't take a genius to figure this out: as soon as
there is a web server out there that can do HTTP/3, people will just use that
one instead. All the excuses (even though I do understand how valid they are)
won't change a thing.

Cheers,
  K. C.

--
regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: iOS 14 / macOS 11 and HTTP/3 support

Luca Toscano
Hi,

On Sun, Jun 28, 2020 at 7:58 AM Helmut K. C. Tessarek
<[hidden email]> wrote:

>
> On 2020-06-27 08:48, Luca Toscano wrote:
> > the challenges are the same one discussed in your previous email
> > thread
>
> These are all valid points, although in the end absolutely irrelevant.
>
> It's very easy and it doesn't take a genius to figure this out: as soon as
> there is a web server out there that can do HTTP/3, people will just use that
> one instead. All the excuses (even though I do understand how valid they are)
> won't change a thing.

there are already web servers doing HTTP/3, but the httpd project is
not in any "race" to get first to new features, this is not the way
Apache works. We will release HTTP/3 support when the development
community will be ready to deliver a strong and solid codebase, not
before. Supporting HTTP/3 is also a strong requirement that holds for
some use cases (for example, services that are directly Internet
facing), but does not for others (in case of HTTP/2, I am not aware of
a lot of people preferring it to HTTP when dealing with proxied
requests between services etc..).

Again, we welcome any contribution to reach the HTTP/3 goal, as stated
multiple times, since we consider it very important. On our side we'll
also try to do everything to keep supporting httpd and adding new
features in a timely manner (the former is not a simple thing to do
too, given the amount of users to support).

Luca
Reply | Threaded
Open this post in threaded view
|

Re: iOS 14 / macOS 11 and HTTP/3 support

Graham Leggett
In reply to this post by Luca Toscano
On 27 Jun 2020, at 14:48, Luca Toscano <[hidden email]> wrote:

> the challenges are the same one discussed in your previous email
> thread (https://lists.apache.org/thread.html/eb086eafbd9309eb1efedac3bf3dcc410a95d06206c97e7ade01c254%40%3Cdev.httpd.apache.org%3E).
> I think that everybody would love to start working/helping on adding
> HTTP/3 support but the work to be done is huge, involves invasive
> changes to the httpd's source code and the current dev resources don't
> have (rightfully) bandwidth to support the current codebase and plan a
> major refactoring.

I would be careful with wide reaching statements like this.

I’ve been working on identifying and removing blockers in various parts of the httpd subsystems that prevent httpd to be cleanly event driven, and most of those blockers have been removed.

The underlying architecture of httpd is very strong, and would support new protocols without too much trouble.

The main point is that it must be done carefully and properly, but this is not a reason to not do it at all.

Regards,
Graham


Reply | Threaded
Open this post in threaded view
|

Re: iOS 14 / macOS 11 and HTTP/3 support

Luca Toscano
Hi Graham,

On Sun, Jun 28, 2020 at 12:53 PM Graham Leggett <[hidden email]> wrote:

>
> On 27 Jun 2020, at 14:48, Luca Toscano <[hidden email]> wrote:
>
> > the challenges are the same one discussed in your previous email
> > thread (https://lists.apache.org/thread.html/eb086eafbd9309eb1efedac3bf3dcc410a95d06206c97e7ade01c254%40%3Cdev.httpd.apache.org%3E).
> > I think that everybody would love to start working/helping on adding
> > HTTP/3 support but the work to be done is huge, involves invasive
> > changes to the httpd's source code and the current dev resources don't
> > have (rightfully) bandwidth to support the current codebase and plan a
> > major refactoring.
>
> I would be careful with wide reaching statements like this.

This is my opinion, supported by my understanding of the thread above,
that's it :). I am just trying to answer to the community with what I
think are the road blockers, please correct me where I am wrong.

> I’ve been working on identifying and removing blockers in various parts of the httpd subsystems that prevent httpd to be cleanly event driven, and most of those blockers have been removed.
>
> The underlying architecture of httpd is very strong, and would support new protocols without too much trouble.

I don't think that my words implied anything against httpd, but in
case you feel in this way apologies. Even if httpd's source is very
strong and has been proven reliable during the years, it was visible
from the development of HTTP/2 that in order to support new protocols,
httpd would have needed to evolve in a significant way, and what I am
trying to say is that it needs resources and people time.

> The main point is that it must be done carefully and properly, but this is not a reason to not do it at all.

Never said (I think) that it is not doable, only that there is a lot
of work to be done.

Luca
Reply | Threaded
Open this post in threaded view
|

Re: iOS 14 / macOS 11 and HTTP/3 support

William A Rowe Jr
In reply to this post by Graham Leggett
On Sun, Jun 28, 2020 at 5:53 AM Graham Leggett <[hidden email]> wrote:
On 27 Jun 2020, at 14:48, Luca Toscano <[hidden email]> wrote:

> the challenges are the same one discussed in your previous email
> thread (https://lists.apache.org/thread.html/eb086eafbd9309eb1efedac3bf3dcc410a95d06206c97e7ade01c254%40%3Cdev.httpd.apache.org%3E).
> I think that everybody would love to start working/helping on adding
> HTTP/3 support but the work to be done is huge, involves invasive
> changes to the httpd's source code and the current dev resources don't
> have (rightfully) bandwidth to support the current codebase and plan a
> major refactoring.

I would be careful with wide reaching statements like this.

I’ve been working on identifying and removing blockers in various parts of the httpd subsystems that prevent httpd to be cleanly event driven, and most of those blockers have been removed.

The underlying architecture of httpd is very strong, and would support new protocols without too much trouble.

The main point is that it must be done carefully and properly, but this is not a reason to not do it at all.

I didn't read anyone saying "don't do it", in fact all the communication has said exactly the opposite.

Irrespective of getting the code into a state where true async behavior "just works", and request handlers will have no problem with free threading (this is not true of PHP and other third party modules), that still leaves a huge hole.

Right now, we couple httpd <-> mod_ssl <-> mod_http2 <-> nghttp2 <-> httpd filters and handler. This works, since the protocol layer exists apart from the SSL stack.

What we are running up against at another project is the tight interconnect between the ssl protocol implementation and the quic implementation. They are almost insperable. You can't do this with mod_ssl out-of-the-box. There are hacks of mod_ssl to enable the callbacks and sideways ingress points which the quic transport protocol requires, but effectively it's a marriage between Google's quiche and boringssl, or another quic implementation and their elected ssl transport.

So it might be that mod_ssl almost entirely disappears in this scenario, replaced by a triplet of httpd skin around one specific quic tightly coupled to one specific tls provider.

The openssl project has published that following 3.0.0 GA, they are devoting energies into implementing all of the hooks into openssl required of a quic implementation (alongside building a FIPS crypto provider coupled to 3.0.0.) These were simply things that current 3.0.0 release plan couldn't accommodate, and they were further worried that the specifics of the spec weren't sufficiently ironed out during their pre-alpha development stage to commit to 10+ years of support for mangled API's.

Tatsuhiro himself has been contributing commits to https://github.com/ngtcp2/nghttp3 although I have yet to read any specific roadmap or plan on what direction he is taking his efforts. At $dayjob OSS projects, it's largely been a matter of consuming his implementation of nghttp2, while consuming boringssl+quic to get to http3 for the time being.

I don't think Luca's general guidance is off-base, nor that his cautions are at all misplaced, and he has perhaps taken a fair assessment of the complexity of this challenge.


Reply | Threaded
Open this post in threaded view
|

Re: iOS 14 / macOS 11 and HTTP/3 support

Stefan Eissing


> Am 28.06.2020 um 18:03 schrieb William A Rowe Jr <[hidden email]>:
>
> On Sun, Jun 28, 2020 at 5:53 AM Graham Leggett <[hidden email]> wrote:
> On 27 Jun 2020, at 14:48, Luca Toscano <[hidden email]> wrote:
>
> > the challenges are the same one discussed in your previous email
> > thread (https://lists.apache.org/thread.html/eb086eafbd9309eb1efedac3bf3dcc410a95d06206c97e7ade01c254%40%3Cdev.httpd.apache.org%3E).
> > I think that everybody would love to start working/helping on adding
> > HTTP/3 support but the work to be done is huge, involves invasive
> > changes to the httpd's source code and the current dev resources don't
> > have (rightfully) bandwidth to support the current codebase and plan a
> > major refactoring.
>
> I would be careful with wide reaching statements like this.
>
> I’ve been working on identifying and removing blockers in various parts of the httpd subsystems that prevent httpd to be cleanly event driven, and most of those blockers have been removed.
>
> The underlying architecture of httpd is very strong, and would support new protocols without too much trouble.
>
> 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.

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.
3. Wait for someone else to do 1 or 2.

Cheers, Stefan

Reply | Threaded
Open this post in threaded view
|

Re: iOS 14 / macOS 11 and HTTP/3 support

Jacob Champion-2
On Mon, Jun 29, 2020 at 1:17 AM Stefan Eissing
<[hidden email]> wrote:
> 2. Redesign a FOSS httpd v3.x with a new architecture, embracing a non-blocking processing model. Maybe under a different name.

Is there widespread interest in this approach (option 2)? It's, in
theory, my preference -- I get the feeling, viewing from the outside,
that the mod_h2 architectural work was incredibly painful due to the
mismatch between what httpd provides and what was needed. Option 1
doesn't feel like a good long-term strategy.

Re: the SSL library problems, does anyone know if mod_nss is a stable
enough thing to begin building off of?

--Jacob
Reply | Threaded
Open this post in threaded view
|

Re: iOS 14 / macOS 11 and HTTP/3 support

Graham Leggett
In reply to this post by Stefan Eissing
On 29 Jun 2020, at 10:16, Stefan Eissing <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: iOS 14 / macOS 11 and HTTP/3 support

Luca Toscano
Hi Graham,

On Fri, Jul 3, 2020 at 11:42 PM Graham Leggett <[hidden email]> wrote:
>
> 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?
>

Thanks a lot for the email explaining your insights, a very good
reading. I have some questions in my mind that I'd like to add to the
discussion, hopefully they'll not be completely off track (but surely
not very precise).

1) Should we support, in core, QUIC itself rather than only UDP? IIUC
the current mod_h2 model is that a TCP connection, carrying H2
streams, is handled by mod_h2 with its own set of threads, so possibly
having core assigning one mpm-thread to each QUIC stream if needed
could be more intuitive for people that want to create mod_h3 or
similar (who knows what protocols will be running on top of QUIC in 5y
time).
2) Stefan wrote https://icing.github.io/mod_h2/beams.html, as an
elegant solution to bypass an APR limitation for H2. Should we
consider adding more functionalities to APR in light of the H3 work to
ease the job of whoever will write mod_h3?
3) Finally, and I think this is the most important point, how should
we change our current release process to accommodate all the changes
that we are discussing? Releasing 2.6 could be a possible answer, but
we might need more (maybe 2.8/3.0 etc..). Defining when/how we should
release trunk's code has been proven a challenging decision in the
past :D. From the last discussion a lot of things have changed,
especially the fact that we now have a CI (kudos to Joe for all the
work in improving it BTW) but we should start talking about next steps
very soon in my opinion.

Thanks in advance,

Luca