Live data from Hacker News

HTTP/3 is everywhere but nowhere

httptoolkit.com

61–70 of 504 posts

Re: HTTP/3 is everywhere but nowhere

#61
post #55

Earlier quoted context omitted.

Yes, it can. I work on .NET and work on Mac (hate the OS, but the hardware and battery life are way better). Last startup, we shipped AWS t4g Arm64 and GCP x64 Linux containers. A few devs started on Windows (because of their preferred platform), but we all ended up on M1 MacBook Pros using a mix of Rider and VS Code. Common misconception between old .NET Framework and new .NET # (e.g. .NET 9) (MS terrible naming). C…

Are you sure? https://learn.microsoft.com/en-us/dotnet/core/deploying/nati... "Since there's no standardized way to obtain native macOS SDK for use on Windows/Linux, or Windows SDK for use on Linux/macOS, or a Linux SDK for use on Windows/macOS, Native AOT does not support cross-OS compilation. Cross-OS compilation with Native AOT requires some form of emulation, like a virtual machine or Windows WSL." Now, you don't…

    > Native AOT does not support cross-OS compilation

    > ...runtime-dependent and self-contained are fine
This certainly reads like you moved the goal posts and recognized it.

Re: HTTP/3 is everywhere but nowhere

#62

Earlier quoted context omitted.

> side note: sad that .NET and C# are not considered "major I've said it before on here, but the tech community severely underrates .NET today. It's not Windows only (and hasn't been for ~8 years) plus C# is a very nice language. F# is also an option for people who like functional languages. I'd highly recommend giving it a try if you haven't already.

Can .net produce cross platform libraries/executables like Go does? With Go I can develop on Mac and create executables for windows and Linux

I'm a dabbler in Go, far from an expert. But I'm not familiar with a capability to use, say, native MacOS platform libraries from a go app that I'm compiling in Windows/Linux without using a VM of some sort to compile it. If that's possible I'd love to learn more.

Re: HTTP/3 is everywhere but nowhere

#63

> At the same time, neither QUIC nor HTTP/3 are included in the standard libraries of any major languages including Node.js, Go, Rust, Python or Ruby. .NET actually looking like it has decent support for any teams that are interested[0] (side note: sad that .NET and C# are not considered "major"...). There is an open source C library that they've published that seems rather far along[1] Support for Windows, Linux[2],…

> side note: sad that .NET and C# are not considered "major"... Even Microsoft does not use C# for their new projects. See the new TypeScript compiler that is being rewritten in Go. So I think it is safe to say C# is indeed a minor language.

This is an interesting point I hadn't thought of when I saw the announcement of the new TypeScript compiler. It might be overstating the case to say that C# is indeed a minor language, but it's thought-provoking that it wasn't Microsoft's automatic choice here, the way it is for some all-Microsoft in-house IT shops.

Re: HTTP/3 is everywhere but nowhere

#64
post #21

A lot of the article is the same marketing spiel that Google has been using to promote QUIC (and then HTTP/3) At best those amazeballs advantages are applicable only at Google's scale, and have very little impact anywhere else. Worse, still, --- start quote --- We find that over fast Internet, the UDP+QUIC+HTTP/3 stack suffers a data rate reduction of up to 45.2% compared to the TCP+TLS+HTTP/2 counterpart. Moreover,…

The benefits of QUIC / HTTP/3 have been extremely well defined as-

-higher latency connections.

-packet loss under multiplexing scenarios / suboptimal connections (e.g. mobile).

These are the situations where it shines and runs away from HTTP/2. And this has been the promised advantage from the outset, and is literally the problem it is designed to solve.

Given that the linked paper mentions the word latency once in an irrelevant context, I think that's telling. Of course there is no advantage -- and in fact is an expected disadvantage -- when your client and server are 0ms from each other with 0% packet loss. Now put them 100ms from each other with 5% packet loss/reordering/retransmission and multiplexing.

Re: HTTP/3 is everywhere but nowhere

#65
Very interesting. The article states that

> Really it's hard to point to any popular open-source tools that fully support HTTP/3: rollout has barely even started.

But isn’t Caddy a widely used reverse proxy with HTTP/3 support? Or what features are missing?

Re: HTTP/3 is everywhere but nowhere

#66

it's quite shocking to know that http/3 is still not gain enough opensource libraries support. Maybe really some users does not care more about it,as a developper I'd rather not taking much overhead to maintain a server that support http/3.

The sheer truth is the prime user for the protocol is ads serving, for common case (API calls with some keep-alive) it's an effective downgrade to even http1.1.

Re: HTTP/3 is everywhere but nowhere

#67
post #20

Caddy does support http 3 in production now, and so can be used as a reverse proxy. The http client libraries almost everywhere do lack support, though.

We switched to Caddy in multiple projects and really happy with it... Certificate generation feels like magic and http3 works great as well. Config files are much smaller and easier to read as well!

Re: HTTP/3 is everywhere but nowhere

#68
post #65

Very interesting. The article states that > Really it's hard to point to any popular open-source tools that fully support HTTP/3: rollout has barely even started. But isn’t Caddy a widely used reverse proxy with HTTP/3 support? Or what features are missing?

I don't think I'd call Caddy "widely used" it is used, but nowhere near nginx, apache, haproxy, squid, etc.

Re: HTTP/3 is everywhere but nowhere

#70
post #21

A lot of the article is the same marketing spiel that Google has been using to promote QUIC (and then HTTP/3) At best those amazeballs advantages are applicable only at Google's scale, and have very little impact anywhere else. Worse, still, --- start quote --- We find that over fast Internet, the UDP+QUIC+HTTP/3 stack suffers a data rate reduction of up to 45.2% compared to the TCP+TLS+HTTP/2 counterpart. Moreover,…

The benefits of QUIC / HTTP/3 have been extremely well defined as- -higher latency connections. -packet loss under multiplexing scenarios / suboptimal connections (e.g. mobile). These are the situations where it shines and runs away from HTTP/2. And this has been the promised advantage from the outset, and is literally the problem it is designed to solve. Given that the linked paper mentions the word latency once in…

>with 5% packet loss

This is absolutely massive

Post reply on HN