Ask HN: Please help Does HTTP/3 chain requests?
Afternoon HN,
I may have rather serendipitously implemented HTTP/3 support for a Flask-like CMS.
Does HTTP/3 reduce server requests by concatenating multi-resource requests into a single request conveyed through a "chained-path"?
For example:
Loading example.com/about requires loading style.css and favicon.ico.
HTTP/2 would request example.com/about, request style.css, request favicon.ico.
Does HTTP/3: request example.com/about & style.css & favicon.ico with a single request path similar to "/about/style.css/favicon.png"?
Any insight would be appreciated. Thanks!
7 comments
[ 3.0 ms ] story [ 28.4 ms ] threadI have NGINX -> Gunicorn (Python) -> Experimental WSGI App (Python) serving a website.
A hit from my cellphone initiated that type of request and it caused a strange error. I was able to identify the issue and successfully guessed it was asking me to yield these resources in that specific order.
Now "devtools" shows its HTTP/3.
My load time improved too. The homepage loads < 200ms and its self-hosted on an old Pixelbook.
No. HTTP/3 can multiplex requests, but "/about/style.css/favicon.png" is a single, valid path. If you are seeing requests for that (specifically), then it's probably a bug.
As for HTTP/3 itself, NGINX is probably providing that. Mobile connections (well, really any connection that is prone to packet loss) benefits greatly from HTTP/3, which accounts for your speedup.
HTTP/3 also will use UDP streams in addition to the single TCP stream of HTTP/1.1 and HTTP/2.
This is what I can tell you for sure.
- it is not a bug
- once I determined the aforementioned, I thought about what it might want from me
- I chose to yield those resources in order (assuming the mechanism would be used to reduce requests)
- After a few refreshes, Chome Dev Tools shows the page and resources have loaded via HTTP/3
This was not the problem I sought out to solve. I'm trying to figure out exactly what's happening here.
"As for HTTP/3 itself, NGINX is probably providing that."
Agreed, NGINX is acting as a reverse proxy and passing requests through Gunicorn. However, before my change these requests were, in fact, HTTP/2.
https://www.rfc-editor.org/rfc/rfc9114.html#section-4.1-1 specifically https://www.rfc-editor.org/rfc/rfc9114.html#section-4.1-3
Also, I'm writing a HTTP server at the moment, so I'm pretty familiar with the protocols. (Not claiming to be an expert, but the reason I responded is that I've put A LOT of effort into understanding the protocols at a low level that last month or so, and I wanted to help if I could.)
I would go into this assuming that either there is something else on the page with that path, or an errant javascript request, or something else is mangling the message before it gets to you.
HTTP/2 and HTTP/3 both allow you to do a server push (where the server tells the client that it wants to send multiple files to it), and that might be what gunicorn is doing (I'm not familiar with it).
But, again, HTTP/3 does not chain together requests as a single path in the way that you described.
As for why it switched from 2 to 3, perhaps it was the fact that you were attempting to send multiple files that prompted the connection upgrade? Maybe it's the presence of a https connection (HTTP/3 requires TLS, but HTTP/2 does not).
There is no JavaScript present. I'm 100% certain this behavior is intentional. I've responded to the unexpected behavior (which originally caused my application to crash under those circumstances) by yielding resource generators in the specified order which ultimately upgraded the connection to HTTP/3. I can repeat that behavior, log the same path, and get a new result. I don't know what else to say about it.
"But, again, HTTP/3 does not chain together requests as a single path in the way that you described."
I wonder if that path might be how the HTTP3 request gets translated to the WSGI app. Basically... something between the Cloudflare tunnel and my WSGI app.
"Also, I'm writing a HTTP server at the moment, so I'm pretty familiar with the protocols."
Very fun! This is my next task actually. I have the TCP/IP series arriving next week and already have Unix Network Programming on the shelf.
Awesome! Good luck!
Mine is in C++, and is part of a larger project. I've thoroughly enjoyed the process!
So far, I've written a scripting language, a thread pool worker queue, and now I'm working on the HTTP server. I'm writing them as libraries (in the same way that libpng or libjpeg exist as libraries). I have a few more "steps" before gluing it all together into a larger project, but it's taking shape!
There's a simple pleasure in getting to the fundamentals of computing, away from the layer upon layer of abstraction that plagues development today.