[HTTP/3] Detecting http session version on the backend (h2 vs h3)

[r00tb33r]

And what advantage do you hope to gain from this? The use of quic primarily serves to improve the deficits in connection establishment with https, because the TCP protocol tends to neglect SSL. Wouldn't it be better to focus on http/3?

Nevertheless, I don't understand how you can use PHP to gain any kind of advantage by recognizing quic?! Especially since http/3 is not a replacement for http/2.

I updated the post above, by the way.

The fact that I wouldn't have to distribute native applications anymore, instead relying on browser and webserver vendors to maintain the functionality, and have the ease of adding features without forcing all users to download a new version of the application.

Bottom line, I have a high performance UDP delivery system right now. HTTP over TCP would be a major downgrade, and frankly won't be accepted by my employer either way. So while websites are meant to be HTTP version agnostic, mine cannot be, which is a setup unlike most others.

My end goal is to roll the delivery system into a web application that leverages QUIC. So everything other than HTTP/3 over QUIC is no good to me.

 

[serpent_driver]

That's all well and good, but how are you going to convince your clients that identifying quic and http/3 is so much better that your work deserves payment?! Maybe you know more than I do, but I don't know of any way to prove the difference?

 

[r00tb33r]

That's all well and good, but how are you going to convince your clients that identifying quic and http/3 is so much better that your work deserves payment?! Maybe you know more than I do, but I don't know of any way to prove the difference?

I don't completely understand what you wrote, maybe you can rephrase it.

I will state that these decisions aren't really up to me. The only options are that I continue developing and maintaining my existing application, adding new features to it, or spend that time developing for a superior and more mature transport, while at the same time no longer having to maintain native applications for multiple platforms. The better option is fairly clear here.

I don't know what you mean about money, nobody pays to use this system, but developing and maintaining it is my job. My employer's facilities have very strict network design constraints so I won't be allowed to just do "whatever". It's their way, or it's their way. No other way.

The users who upload files aren't asked for their opinion. They will use what they are given. There is nothing to prove to anyone.

As an example, there is one user who uploads a 42Gbyte file every week across public Internet. And they're just one of many. Any difficulties they have are my problem. These deliveries require resiliency that older HTTP and FTP protocols just don't provide.

 

[serpent_driver]

I don't completely understand what you wrote, maybe you can rephrase it.

I will state that these decisions aren't really up to me. The only options are that I continue developing and maintaining my existing application, adding new features to it, or spend that time developing for a superior and more mature transport, while at the same time no longer having to maintain native applications for multiple platforms. The better option is fairly clear here.

I don't know you mean about money, nobody pays to use this system, but developing and maintaining it is my job. My employer's facilities have very strict network design constraints so I won't be allowed to just do "whatever". It's their way, or it's their way. No other way.

The users who upload files aren't asked for their opinion. They will use what they are given. There is nothing to prove to anyone.

As an example, there is one user who uploads a 42Gbyte file every week across public Internet. And they're just one of many. Any difficulties they have are my problem. These deliveries require resiliency that older HTTP and FTP protocols just don't provide.

I think you are over-emphasizing quic and http/3 detection, as it does not provide any significant benefit that could be leveraged by your programming.

 

[r00tb33r]

I think you are over-emphasizing quic and http/3 detection, as it does not provide any significant benefit that could be leveraged by your programming.

I don't understand what you mean. Are you saying I should not care about HTTP versions and just let TCP happen where every single packet requires an ACK response? The overhead is unacceptable.

The throughput over UDP is significantly higher.

 

[serpent_driver]

Are you saying I should not care about HTTP versions and just let TCP happen where every single packet requires an ACK response? The overhead is unacceptable.

In short, yes, because there are a lot of many other features you should care. An overload is often caused by PHP and MySQL issues. quic and the protcol used don't compensate any PHP and MySQl leaks.

 

[r00tb33r]

In short, yes, because there are a lot of many other features you should care. An overload is often caused by PHP and MySQL issues. quic and the protcol used don't compensate any PHP and MySQl leaks.

Okay. In that case.

Maybe you know more than I do

Yes, I do.

CPU and memory use are not a concern in my case. However there are non-negotiable hard constraints on the network. (You are welcome to speak your mind but the manner of transport isn't actually debatable.)

Also, more than likely the data will be accepted by the HTTP library in Go, and written to disk by it. Most likely tus will be used.
https://tus.io/
Because the HTTP/3 working group failed to get a standard interrupted upload resuming mechanism into the protocol RFC, so a custom server has to handle it through headers.

PHP and MySQL aren't even involved there.

It would be a fair (and good) question to ask, what does LiteSpeed do then? It would serve as a "front" for the application. There are specific things that have to take place before tus takes over. Maybe it will be a proxy if I don't port tusd to the HTTP/3 library.

 

[r00tb33r]

I'll be back once I have observed the server side variables under different connection scenarios.

Let's get some basics out of the way first. I have set up a server to do some testing with, and have been working with it for the last couple of days.

$ curl --http3 -k --head https://localhost
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0 10261    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
HTTP/3 200
content-type: text/html
last-modified: Fri, 09 Aug 2024 22:30:50 GMT
etag: "2815-66b6989a-b720f36db1479b76;;;"
accept-ranges: bytes
content-length: 10261
date: Wed, 14 Aug 2024 19:22:39 GMT
server: LiteSpeed
alt-svc: h3=":443"; ma=2592000, h3-29=":443"; ma=2592000, h3-Q050=":443"; ma=2592000, h3-Q046=":443"; ma=2592000, h3-Q043=":443"; ma=2592000, quic=":443"; ma=2592000; v="43,46"

This confirms that I am running LiteSpeed, that I have functional TLS, and I listen to and accept HTTP/3 connections over QUIC.

I suppose Alt-Svc would be missing entirely when the connection is already h3...? Maybe I can be sure we're connected via h3 that way?

This is false. Alt-Svc header is still served for HTTP/3 connections, at the very least because it has "ma" values, meaning it is not persistent as served. The reason I did not see them is because browsers don't show complete response headers for cached requests, visible in curl though.

$_SERVER['SSL_PROTOCOL'] // QUIC

This is exactly what I was looking for, so thanks for that. I've been writing test scripts leveraging this for the last couple of days.

Essentially I expect the flow to be something like:
- the browser connects via h2 to the landing page
- Alt-Svc response header proposes h3
- JavaScript calls a page reload after a delay
- the browser is expected to connect via h3
- backend code detects h3 and responds with content submission form
- (otherwise the landing page with a page reload will repeat for some iterations until the browser jumps to h3)

So this seemed like a sound idea, but I only got this working on Firefox.

Firefox is a good sport about switching from h2 to h3 on a 30x status code redirect or a JavaScript reload.

Observe that h2 connection request got served a 301 status code by the script, and on the redirected request the h3 connection is served a happy 200 status code. This is how I envisioned this working.

But...

I get no love on Chrome. It doesn't want to connect over h3 to this server... I refresh many times, very rarely but sometimes it does connect over h3. Maybe 5% of the time. I don't understand how to make it more reliable or predicable, but that's mostly not a LiteSpeed question, probably, although Googling finds similar questions asked with no solution found.
I did read about the "winning the race" behavior in the past, where Chrome supposedly opens two connections simultaneously and looks to see which succeeds first. I did think about that scenario, where I thought maybe h2 responses could be intentionally delayed to make sure h3 always wins the race, but I have not been able to implement this successfully yet. Or it requires a more advanced webserver configuration, which would make it a LiteSpeed question.
Configuring ALPN did not produce the desired effect either.

I have not tried Safari yet either.