Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP/3 is everywhere but nowhere

httptoolkit.com

Post reply on HN
Print view View original

211–220 of 504 posts

Re: HTTP/3 is everywhere but nowhere

#211

Post by jayd16 »

shepherdjerred wrote: post #163
hypeatei wrote: post #24

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.

Why would I use C# over any other language though?

C# has a strong high level feature set and lower level tools to keep performance up. The language itself is well designed and consistent. Its able to mix functional and OO features without being dogmatic, leading to better dev-x over all.

ASP is actually very good these days and feels cleaner than Spring Boot. There's less choice but the available choices are good. It has arguably the best gRPC implementation. It's just a nice experience over all.

Re: HTTP/3 is everywhere but nowhere

#212

Post by plopz »

ralferoo wrote: post #47

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…

the big one is multiplayer games. udp is preferred and trying to work with webrtc is awful

Re: HTTP/3 is everywhere but nowhere

#213

Post by neonsunset »

CharlieDigital wrote: post #30
victor106 wrote: post #27

Earlier quoted context omitted.

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

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…

I don't know why we're trying anymore.

You're not going to convince someone who is looking for a way to make something not work however minor it is and not the other way around.

Re: HTTP/3 is everywhere but nowhere

#214

Post by kstrauser »

djha-skin wrote: post #209

> Really it's hard to point to any popular open-source tools that fully support HTTP/3: rollout has barely even started. > This seems contradictory. What's going on? IT administrators and DevOps engineers such as myself typically terminate HTTP/3 connections at the load balancer, terminate SSL, then pass back HTTP 1.1 (_maybe_ 2 if the service is GRPC or GraphQL) to the backing service. This is way easier to administ…

I'm not an expert on HTTP/3, but vehemently disagree about IPv6. It removes tons of overhead and cruft, making it delightful for datacenter work. 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.

Re: HTTP/3 is everywhere but nowhere

#215

Post by aoeusnth1 »

djha-skin wrote: post #209

> Really it's hard to point to any popular open-source tools that fully support HTTP/3: rollout has barely even started. > This seems contradictory. What's going on? IT administrators and DevOps engineers such as myself typically terminate HTTP/3 connections at the load balancer, terminate SSL, then pass back HTTP 1.1 (_maybe_ 2 if the service is GRPC or GraphQL) to the backing service. This is way easier to administ…

What kind of overhead? I’m curious if there’s data about this because I hadn’t heard that 1.1 was better for the data center.

Re: HTTP/3 is everywhere but nowhere

#216

Post by neonsunset »

actionfromafar wrote: post #122
homebrewer wrote: post #56

Earlier quoted context omitted.

If your code does not rely on native libraries, or you're fine with shipping multiple copies for different operating systems, a single build works everywhere with dotnet installed. Or you can cross-compile and run without having dotnet on the target system, I do it from Linux to all three platforms all the time, it's pretty seamless. The application can be packaged into a single binary (similar to Go), or as a bunch…

How do you cross compile from linux to macos?

JIT deployments do not care where they get built on. AOT deployments do because they use OS-provided linker to produce the final binary, much like C++ and Rust do (unless you use PublishAotCross nuget package which uses Zig toolchain to allow you to build Linux binaries from under Windows, I'm sure if someone's interested it could be extended further)

Also, if you want to have just a single binary, you want to do 'dotnet publish /p:PublishSingleFile=true /p:PublishTrimmed=true' instead. Self-contained build means it just ships everything needed to run in a folder without merging the assembly files or without trimming unreachable code and standard library components.

Re: HTTP/3 is everywhere but nowhere

#217

Post by AnthonyMouse »

ralferoo wrote: post #47

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…

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

Then you're trying to rely on the OS for this when it should actually be a dynamically linked third party library under some open source license.

Trying to get the OS to do it fails to one of two problems. Either each OS provides its own interface, and then every application has to be rewritten for each OS and developers don't want to deal with that so they go back to using a portable library, or the OS vendors all have to get together and agree on a standard interface, but then at least Microsoft refuses to participate and that doesn't happen either.

The real problem here is that mobile platforms fail to offer a package manager with the level of dependency management that has existed on Linux for decades. The way this should work is that you open Google Play and install whatever app that requires a QUIC library, it lists the QUIC library as a dependency, so the third party open source library gets installed and dynamically linked in the background, and the Play Store then updates the library (and therefore any apps that use it) automatically.

But what happens instead is that all the apps statically link the library and then end up using old insecure versions, because the store never bothered to implement proper library dependency management.

Re: HTTP/3 is everywhere but nowhere

#218

Post by hbn »

CharlieDigital wrote: post #109
shermantanktop wrote: post #84

Earlier quoted context omitted.

.NET suffers from the long lasting reputational taint of Microsoft. It was seen as the sworn enemy of open source and Linux, and for good reason. Today’s MS is not what it was back then. But long memories are not a bad thing, really. If .NET suffers a bit from some unfair perception, perhaps that can remind MS and others what happens when you take an aggressively adversarial approach.

The ironic thing? GitHub, VS Code, and TypeScript are all Microsoft products.

The exceptions prove the rule.

In my head, when I think Microsoft I think about the stress and anger I feel using Windows, and the OS-level notification I got apropos of nothing a few minutes ago trying to sell me an Xbox Game Pass subscription. The fear of what is going to break in the next forced update. For months now I haven't been able to do a task as simple as take a screenshot on my PC because seemingly the flash effect it plays gets caught in the image and the resulting screenshot has all the colors blown out, so it's mostly white.

So yes, this does color my opinion of how many ecosystems of theirs I want to tie myself too (minimal)

Re: HTTP/3 is everywhere but nowhere

#219

Post by preisschild »

pas wrote: post #158
nine_k wrote: post #104

Earlier quoted context omitted.

What good is your IPv6, Mr Anderson, if your upstream provider and/or middleboxes along the way do not support it?

I'm happy to report that - to my utter amazement - my ISP's on-prem device does /64 prefix delegation to each (DHCPv6?) client.

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)

Re: HTTP/3 is everywhere but nowhere

#220

Post by llm_nerd »

troupo wrote: post #204
llm_nerd wrote: post #64

Earlier quoted context omitted.

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…

> 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. And yet it's somehow being pushed as a be-all solve-all replacement despite this: --- start quote --- We experimentally demonstrate that QUIC’s performance degradation affects not only bulk file transfers but also other applications inclu…

>And yet it's somehow being pushed as a be-all solve-all replacement

But it isn't a be-all solve-all replacement. The whole point of HTTP/3 is that you can still use HTTP/2 all you want in your build-outs, and it uses as appropriate. If large file, many packet, high speed sustained performance is your thing and you've got problems with HTTP/3, deploy it on an HTTP/2 server. Go nuts. Positively nothing will go awry. Everything will be fine.

You're arguing a strawman.

>Additionally, if your performance degrades even in these ideal conditions, what does this promise for non-ideal conditions?

This is an absolutely nonsensical statement. HTTP/3 is quite literally built for situations where you have many small requests, often in suboptimal situations. The average web user interacting with an average web page over something other than their local ethernet connection, exchanging tens of thousands of back and forths for different resources and navigations and posts. Screeching, with moral superiority I might add, that if it pins the CPU using their oddball no-name server -- oh, and where they bizarrely forced the HTTP/3 server to use HTTP/2 congestion control because that made the results funner -- with their client machine with a CPU 1/4 the performance of my smartphone, downloading a many GB file, isn't the big win you seem to think it is.

Post reply on HN