Damn it's nice reading a simple static site like this. Links open instantly to the next fully laid out page of content. If only the rest of the web could be like this..
Worth nothing, that react application (using React Server Components?)! If you have javascript enabled, it renders as a single page app, fetching each additional page via an API. If you disable JS, it renders it all on the server.
Agreed but where is the actual git repo? I see a text saying this "contents get updated automatically on every commit to this git repository" but where is "this git repository"?
Damn it's nice to log onto Hacker News and see yet another top comment on an interesting article be bike shedding about webshit. And also wrong because if you crack open your react dev tools and have a peak inside the 2MB of javascript you'll see that this site is still everything you despise.
But how will the author know the last 500 websites you visited and where your eyes are looking right now and what you ate last Tuesday? They should put some AnAlYtIcS in.
Here’s a conceptual background about how and why HTTP/3 came to be (recollected from memory):
HTTP/1.0 was built primarily as a textual request-response protocol over the very suitable TCP protocol which guaranteed reliable byte stream semantics. The usual pattern was to use a TCP connection to exchange a request and response pair.
As websites grew more complex, a web page was no longer just one document but a collection of resources stitched together into a main document. Many of these resources came from the same source, so HTTP/1.1 came along with one main optimisation — the ability to reuse a connection for multiple resources using Keep Alive semantics.
This was important because TCP connections and TLS (nee SSL) took many round-trips to get established and transmitting at optimal speed. Latency is one thing that cannot be optimised by adding more hardware because it’s a function of physical distance and network topology.
HTTP/2 came along as a way to improve performance for dynamic applications that were relying more and more on continuous bi-directional data exchange and not just one-and-done resource downloads. Two of its biggest advancements were faster (fewer round-trips) TLS negotiation and the concept of multiple streams over the same TCP connection.
HTTP/2 fixed pretty much everything that could be fixed with HTTP performance and semantics for contemporary connected applications but it was still a protocol that worked over TCP. TCP is really good when you have a generally stable physical network (think wired connections) but it performs really badly with frequent interruptions (think Wi-Fi with handoffs and mobile networks).
Besides the issues with connection reestablishment, there was also the challenge of “head of the line blocking” — since TCP has no awareness of multiplexed HTTP/2 streams, it blocks everything if a packet is dropped, instead of blocking only the stream to which the packet belonged. This renders HTTP/2 multiplexing a lot less effective.
In parallel with HTTP/2, work was also being done to optimise the network connection experience for devices on mobile and wireless networks. The outcome was QUIC — another L4 protocol over UDP (which itself is barebones enough to be nicknamed “the null protocol”). Unlike TCP, UDP just tosses data packets between endpoints without much consideration of their fate or the connection state.
QUIC’s main innovation is to integrate encryption into the transport layer and elevate connection semantics to the application space, and allow for the connection state to live at the endpoints rather than in the transport components. This allows retaining context as devices migrate between access points and cellular towers.
So HTTP/3? Well, one way to think about it is that it is HTTP/2 semantics over QUIC transport. So you get excellent latency characteristics over frequently interrupted networks and you get true stream multiplexing semantics because QUIC doesn’t try to enforce delivery order or any such thing.
Is HTTP/3 the default option going forward? Maybe not until we get the level of support that TCP enjoys at the hardware level. Currently, managing connection state in application software means that over controlled environments (like E-W communications within a data centre), HTTP/3 may not have as good a throughput as HTTP/2.
Thank you for a great overview! I wish HTTP3/QUIC was the "default option" and had much wider adoption.
Unfortunately, software implementations of QUIC suffer from dealing with UDP directly. Every UDP packet involves one syscall, which is relatively expensive in modern times. And accounting for MTU further makes the situation ~64 times worse.
In-kernel implementations and/or io-uring may improve this unfortunate situation, but today in practice it's hard to achieve the same throughput as with plain TCP. I also vaguely remember that QUIC makes load-balancing more challenging for ISPs, since they can not distinguish individual streams as with TCP.
Finally, QUIC arrived a bit too late and it gets blocked in some jurisdictions (e.g. Russia) and corporate environments similarly to ESNI.
> As the packet loss rate increases, HTTP/2 performs less and less well. At 2% packet loss (which is a terrible network quality, mind you), tests have proven that HTTP/1 users are usually better off - because they typically have up to six TCP connections to distribute lost packets over. This means for every lost packet the other connections can still continue.
Email is mostly dead - we use Gmail (or Microsoft 365) now. It is to email what Slack is to IRC. With only one or two vendors, the need for widely interoperable protocols is gone - they only need to interoperate between a few large service providers, and that can be done by private agreement.
About 30% percent of traffic to Cloudflare uses HTTP/3 [0], so it seems pretty popular already. For comparison, this is 3× as much traffic as HTTP/1.1.
[+] [-] akdor1154|5 months ago|reply
[+] [-] madeofpalk|5 months ago|reply
[+] [-] INTPenis|5 months ago|reply
I can't find a link to the source anywhere.
[+] [-] fny|5 months ago|reply
There are a also ton of outbound requests for JS on first load.
[0]: view-source:https://http3-explained.haxx.se/
[+] [-] fkyoureadthedoc|5 months ago|reply
[+] [-] thegrim33|5 months ago|reply
[+] [-] Nifty3929|5 months ago|reply
I need fancy javascript crap like I need a hole in my head.
[+] [-] Razengan|5 months ago|reply
[+] [-] sedatk|5 months ago|reply
[+] [-] esnard|5 months ago|reply
Looks unmaintained, though.
[+] [-] lsaferite|5 months ago|reply
[+] [-] code_martial|5 months ago|reply
HTTP/1.0 was built primarily as a textual request-response protocol over the very suitable TCP protocol which guaranteed reliable byte stream semantics. The usual pattern was to use a TCP connection to exchange a request and response pair.
As websites grew more complex, a web page was no longer just one document but a collection of resources stitched together into a main document. Many of these resources came from the same source, so HTTP/1.1 came along with one main optimisation — the ability to reuse a connection for multiple resources using Keep Alive semantics.
This was important because TCP connections and TLS (nee SSL) took many round-trips to get established and transmitting at optimal speed. Latency is one thing that cannot be optimised by adding more hardware because it’s a function of physical distance and network topology.
HTTP/2 came along as a way to improve performance for dynamic applications that were relying more and more on continuous bi-directional data exchange and not just one-and-done resource downloads. Two of its biggest advancements were faster (fewer round-trips) TLS negotiation and the concept of multiple streams over the same TCP connection.
HTTP/2 fixed pretty much everything that could be fixed with HTTP performance and semantics for contemporary connected applications but it was still a protocol that worked over TCP. TCP is really good when you have a generally stable physical network (think wired connections) but it performs really badly with frequent interruptions (think Wi-Fi with handoffs and mobile networks).
Besides the issues with connection reestablishment, there was also the challenge of “head of the line blocking” — since TCP has no awareness of multiplexed HTTP/2 streams, it blocks everything if a packet is dropped, instead of blocking only the stream to which the packet belonged. This renders HTTP/2 multiplexing a lot less effective.
In parallel with HTTP/2, work was also being done to optimise the network connection experience for devices on mobile and wireless networks. The outcome was QUIC — another L4 protocol over UDP (which itself is barebones enough to be nicknamed “the null protocol”). Unlike TCP, UDP just tosses data packets between endpoints without much consideration of their fate or the connection state.
QUIC’s main innovation is to integrate encryption into the transport layer and elevate connection semantics to the application space, and allow for the connection state to live at the endpoints rather than in the transport components. This allows retaining context as devices migrate between access points and cellular towers.
So HTTP/3? Well, one way to think about it is that it is HTTP/2 semantics over QUIC transport. So you get excellent latency characteristics over frequently interrupted networks and you get true stream multiplexing semantics because QUIC doesn’t try to enforce delivery order or any such thing.
Is HTTP/3 the default option going forward? Maybe not until we get the level of support that TCP enjoys at the hardware level. Currently, managing connection state in application software means that over controlled environments (like E-W communications within a data centre), HTTP/3 may not have as good a throughput as HTTP/2.
[+] [-] newpavlov|5 months ago|reply
Unfortunately, software implementations of QUIC suffer from dealing with UDP directly. Every UDP packet involves one syscall, which is relatively expensive in modern times. And accounting for MTU further makes the situation ~64 times worse.
In-kernel implementations and/or io-uring may improve this unfortunate situation, but today in practice it's hard to achieve the same throughput as with plain TCP. I also vaguely remember that QUIC makes load-balancing more challenging for ISPs, since they can not distinguish individual streams as with TCP.
Finally, QUIC arrived a bit too late and it gets blocked in some jurisdictions (e.g. Russia) and corporate environments similarly to ESNI.
[+] [-] NeutralForest|5 months ago|reply
[+] [-] vivzkestrel|5 months ago|reply
[+] [-] sebazzz|5 months ago|reply
[+] [-] kevg123|5 months ago|reply
Why doesn't HTTP/2 use more than one socket?
[+] [-] thwarted|5 months ago|reply
[+] [-] unknown|5 months ago|reply
[deleted]
[+] [-] gramakri2|5 months ago|reply
[+] [-] panki27|5 months ago|reply
https://http3-explained.haxx.se/~gitbook/pdf?limit=100
[+] [-] derelicta|5 months ago|reply
[+] [-] stock_toaster|5 months ago|reply
[1]: https://en.wikipedia.org/wiki/JSON_Meta_Application_Protocol
[+] [-] immibis|5 months ago|reply
[+] [-] sharts|5 months ago|reply
[+] [-] ahoka|5 months ago|reply
[+] [-] detaro|5 months ago|reply
[+] [-] MallocVoidstar|5 months ago|reply
[+] [-] frmdstryr|5 months ago|reply
[+] [-] ckbkr10|5 months ago|reply
[+] [-] gucci-on-fleek|5 months ago|reply
[0]: https://radar.cloudflare.com/adoption-and-usage#http1x-vs-ht...
[+] [-] ofrzeta|5 months ago|reply
https://en.wikipedia.org/wiki/HTTP/3
[+] [-] frmdstryr|5 months ago|reply