Live data from Hacker News

HTTP/3 is everywhere but nowhere

httptoolkit.com

421–430 of 504 posts

Re: HTTP/3 is everywhere but nowhere

#421
post #340

Earlier quoted context omitted.

>That, and basically guaranteeing you don't have to deal with the company you just acquired having deployed their accounts with the same 10/16 subnet your own company uses. I always found that to be a desperate talking point. 'Prepare your network for the incredibly rare event where you intend to integrate directly' (didn't anyone hear of network segmentation?). It makes a lot more sense to worry about the ISP unilat…

> It makes a lot more sense to worry about the ISP unilaterally changing your prefix - something that can only happen in IPv6. ISPs unilaterally change your DHCP address on IPv4 all the time. And in any situation where you would have a static address for IPv4, your ISP should have no problem giving you a static v6 prefix. This argument makes no sense at all.

Your ISP provided ipv4 has no relation to your internal private network space

My understanding is that for some bizarre reason this is not usually the case with IPv6

Re: HTTP/3 is everywhere but nowhere

#422

The article talks about the advantages of HTTP/3 for IoT applications. I recently did an IoT application (weather station) where I actually ended up using HTTP/1.0. I only had to send a total of around 70 bytes every two minutes. If at the end of that two minutes I had an invalid or missing response there was nothing more to do other than record the result for a possible future reset. Once there was new data availabl…

>Most IoT applications are not very sensitive to things like latency and what counts as reliability is very much dependent on the situation. IoT is not about latency. IoT is about devices being behind a NAT which does not allow inbound connections. With UDP-based HTTP/3 it is possible to do "udp hole punching".

>With UDP-based HTTP/3 it is possible to do "udp hole punching".

That works reliably with all the various types of NAT?

Re: HTTP/3 is everywhere but nowhere

#423
> 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.

I'm not sure why it would be in the Rust std, Rust std doesn't even have HTTP/1 or TLS, it's not supposed to support any network layer higher than what's provided by the OS.

Re: HTTP/3 is everywhere but nowhere

#424
post #375
post #231

Earlier quoted context omitted.

More than just that it came from MS. For a long time, .NET was completely proprietary, and only ran on Windows. Now it is open source and cross platform, but it is still fighting the momentum of being seen as Windows-only.

Until I can do apt-install, it's got a problem with availability.

I'm pretty it's just:

    sudo apt-get install dotnet-sdk-9.0
No?

Re: HTTP/3 is everywhere but nowhere

#425

Earlier quoted context omitted.

obviously system.windows.forms could easily be implemented elsewhere, but okay, does any of the other UIs work fully properly on for example linux?

> obviously system.windows.forms could easily be implemented elsewhere It can, but not easily . As OP has said, it is a wrapper around Win32, and not an opaque one - it literally has stuff like e.g. the Message struct with members like HWnd and LParam. Mono did try at one point, but they kept hitting edge cases where this kind of stuff would break things. Eventually they gave up and just wrapped Wine. So, yes, if you…

well maybe because there exists countless gui applications that uses it, and furthermore, if you say its crossplatform, you cant say that with a straight face unless you also support gui? fact of the matter is, microsoft was perfectly happy to preach their .net shit as cross platform to try extend into non-windows usage, except for gui stuff, as thats "for windows"

Re: HTTP/3 is everywhere but nowhere

#426

Earlier quoted context omitted.

obviously system.windows.forms could easily be implemented elsewhere, but okay, does any of the other UIs work fully properly on for example linux?

Avalonia: https://avaloniaui.net/ , https://docs.avaloniaui.net/docs/overview/supported-platform... Uno: https://platform.uno/ , https://platform.uno/platforms/

what ui library are most .net applications created in the business world today using? what is microsoft telling people to use?

Re: HTTP/3 is everywhere but nowhere

#427

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.

I’ve been a .Net developer since it launched, but recently I find myself using it less and less. I’m so much more productive with LLM assistance and they aren’t very good at C#. (Seriously, I thought AI coding was all exaggeration until I switched to Python and realized what the hype was all about, these language models are just so much more optimized for python) Plus now Microsoft is being a bully when it comes to C…

You can use VS Code and cursor at the same time. One to code and the other to compile the code. That's how I build for Android. I generate code in Cursor/Windsurf then I compile and deploy using Android Studio.

Re: HTTP/3 is everywhere but nowhere

#428

Earlier quoted context omitted.

Can you request a bigger delegation? a single /64 is very limiting, since that effectively limits you to 1 subnet (so no extra guest / IoT subnet)

You could ask your ISP/RSP for another /64? My RSP can do so I believe, not that I've asked.

With "good" ISPs that support IPv6 well you'd only have to change your DHCPv6 config to request a larger delegation instead of the default /64.

Unfortunately, some ISPs (including mine) limit this to /64 only, which is extremely limiting.

Re: HTTP/3 is everywhere but nowhere

#429

For me, I think the biggest issue with large scale deployment of HTTP 3 is that it increases the surface area of potentially vulnerable code that needs to be kept patched and maintained. I'd far rather have the OS provide a verified safe socket layer, and a dynamically linked SSL library, that can be easily updated without any of the application layer needing to worry about security bugs in the networking layer. Addi…

A "few extra ms" is up to 3 roundtrips difference, that's easily noticeable by humans on cellular. For all the CPU optimisations we're doing, cutting out a 50ms roundtrip for establishing a HTTP connection feels like a great area to optimize performance.

Does it really matter? The website is first going to download 5mb of js, then it's going to show 3 popups.

Re: HTTP/3 is everywhere but nowhere

#430
post #151

I feel another way to look at it is that there is a growing divide between the "fronted/backend developer" view of an application and the "ops/networking" view - or put differently, HTTP2 and HTTP3 are not really "application layer" protocols anymore, they're more on the level of TCP and TLS and are perceived as such. As far as developers are concerned, we still live, have always lived and will always be living in a…

I think its more that HTTP/3 only really gives marginal gains for most people. Just as python3 had almost nothing for programmer over python2, apart from print needing brackets. Sure it was technically better, and allowed for future gains, but in practice, for the end user, there was no real reason to adopt it. For devs outside of FAANG, there is no real reason to learn how to setup and implement http3

I’d go even further and say that HTTP/3 gives almost no gains for the average person using a high speed wired or wireless internet connection at a fixed location (or changing locations infrequently).

However, for high latency mobile connections while roaming and continuously using the internet, it’s quite an optimisation.

I wouldn’t expect even the vast majority of devs in FAANG to care. It should purely be an infrastructural change that has no impact on application semantics.

Post reply on HN