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

291–300 of 504 posts

Re: HTTP/3 is everywhere but nowhere

#291

Post by CharlieDigital »

neonsunset wrote: post #266
int_19h wrote: post #256

Earlier quoted context omitted.

You forgot to mention that Miguel de Icaza was probably the single biggest .NET fanboy for literally decades before throwing in the towel. The fact that a person like this ended up being alienated tells volumes. I should also add that the general public only saw the tip of the iceberg in this entire episode. Miguel spent a lot of time and effort internally trying to right the .NET ship, gradually escalating through m…

I don’t doubt this but the criticism has to be rooted in facts and the current state of affairs, and you have to consider conflict of interest. It’s not too different to what you can read here. No one ever talks about whether C# offers good cohesive experience when solving a specific task, or what are the pros and cons of its build system, or how a typical .NET team looks like in a particular region. No. Instead, the…

.NET after .NET Framework is just terrible branding by Microsoft.

Call it TypeScript++ or just `dot`; rebrand it Microsoft! Look at this thread full of misunderstandings and confusion around modern .NET!

Re: HTTP/3 is everywhere but nowhere

#292

Post by Navarr »

CharlieDigital wrote: post #260
Navarr wrote: post #176

Earlier quoted context omitted.

GitHub was purchased, which is a bit different. TypeScript though I had no idea about! Good for them!

> GitHub was purchased, which is a bit different. Why is that different? The purchase was 7 years ago (?) at this point. Do we make an exemption for SharePoint because it, too, is an extension of FrontPage acquired via Vermeer?[0] At what point does it lose its exemption from "Hate All Things Microsoft"? 10 years? 20 years? [0] https://en.wikipedia.org/wiki/Microsoft_FrontPage

The difference here is that we didn't select to use a Microsoft product, a produce we used became Microsoft.

It only matters in the context of it being "ironic" that it is used and favored in the coding community.

Re: HTTP/3 is everywhere but nowhere

#293

Post by CharlieDigital »

int_19h wrote: post #258
bjoli wrote: post #102

Earlier quoted context omitted.

Mostly because they didnt consider the AOT compilation mature enough.

Actually, the reason why they went with Go rather than C# is because they wanted to port the existing code as much as possible rather than rewriting from scratch. And it turns out that TS is syntactically and semantically much closer to Go, so you can often convert the former to the latter mechanically.

    > And it turns out that TS is syntactically and semantically much closer to Go, so you can often convert the former to the latter mechanically.
Are there examples of this?

I ask because I've been working on a Nest.js backend in TS and it's remarkably similar to C# .NET Web APIs (controllers, classes, DI). Really curious to see the translation from TS to Go.

Re: HTTP/3 is everywhere but nowhere

#294

Post by cowsandmilk »

kstrauser wrote: post #214
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.

For those building on AWS with VPC per service and using PrivateLink for connections between services, the whole IP conflict problem just evaporates. Admittedly, you’re paying some premiums to Amazon for that convenience.

Re: HTTP/3 is everywhere but nowhere

#295

Post by neonsunset »

CharlieDigital wrote: post #291
neonsunset wrote: post #266

Earlier quoted context omitted.

I don’t doubt this but the criticism has to be rooted in facts and the current state of affairs, and you have to consider conflict of interest. It’s not too different to what you can read here. No one ever talks about whether C# offers good cohesive experience when solving a specific task, or what are the pros and cons of its build system, or how a typical .NET team looks like in a particular region. No. Instead, the…

.NET after .NET Framework is just terrible branding by Microsoft. Call it TypeScript++ or just `dot`; rebrand it Microsoft! Look at this thread full of misunderstandings and confusion around modern .NET!

I don't think we can survive another rename haha. It doesn't seem to have helped PHP either. But we could use a newer .NET language with better lambda lowering, dependent types, HM type inference, structs as the default data type, improved lifetime analysis and different tradeoffs w.r.t now that we're going to have zero-cost-ish non-suspending async calls.

Re: HTTP/3 is everywhere but nowhere

#296

Post by JoshTriplett »

frollogaston wrote: post #275
cogman10 wrote: post #245

Earlier quoted context omitted.

The problem I keep running into is that IPv6 support in common infrastructure is somewhat lacking. It's always a headache to learn that some container orchestration system doesn't support IPv6. Or an http client. Or a DNS resolver. Or whatever. Not to mention the supreme annoyance I have that, to this day, my ISP still does not have IPv6 addressing available.

Yep, it's tragic because it all stems from unforced differences vs ipv4. The design was reasonable, but with perfect hindsight, it needed to be different. They needed to keep the existing /32s and just make the address field bigger, despite the disadvantages. "Everywhere but nowhere" is sorta how I'd describe ipv6. Most hardware and lower-level software supports it, so obviously it wasn't impossible to support a new…

> Yep, it's tragic because it all stems from unforced differences vs ipv4. The design was reasonable, but with perfect hindsight, it needed to be different. They needed to keep the existing /32s and just make the address field bigger, despite the disadvantages.

Exactly. I would love to have seen the world in which that happened, and where all the other parts of IPv6 were independently proposed (and likely many of them rejected as unwanted).

Re: HTTP/3 is everywhere but nowhere

#297

Post by progmetaldev »

userbinator wrote: post #22
confirmr wrote: post #15

> You'll start to see lack of HTTP/3 support used as a signal to trigger captchas & CDN blocks, like as TLS fingerprinting is already today. HTTP/3 support could very quickly & easily become a way to detect many non-browser clients, cutting long-tail clients off from the modern web entirely. That explains it. I've seen this when using 3 year old browsers on retail web sites recently. A few cloud providers think I’m a…

It's horrible that the Internet is slowly becoming a locked-down ecosystem. Everyone should turn off HTTP/3 in protest of this. https://news.ycombinator.com/item?id=43329320

When it comes specifically to Cloudflare, it does not have to be this way. A site operator can choose to set their own rules for triggering CAPTCHAs, it's just that most don't actually bother to learn about the product they're using.

I use Cloudflare through my employer because I deal with clients that aren't willing to spend a few hundred dollars a month on hosting. In order to keep up with sales of new websites for these clients (where the real money lies), I need to keep hosting costs down, while also providing high-availability and security. Bot traffic is a real problem, and while I would love to not require using Cloudflare in favor of other technologies to keep a site running quickly and securely, I just can't find another solution near a similar price point. I've already tweaked the CMS I use to actually run with less than the minimum recommended requirements, so would have to take a more hostile action towards my clients to keep them at the same cost (such as using a less powerful CMS, or setting expiration headers far in the future - which doesn't help with bots).

If anyone has suggestions, I'd be open to them, but working for a small business I don't have the luxury to not run with Cloudflare (or a similar service if one exists). I have worked with this CMS since 2013, and have gone into the internals of the code to try and find every way to reduce memory and CPU usage so I don't need to depend on other services, but I don't see too many returns anymore.

I am all for internet privacy, and don't like where things are going, but also do work for lots of small businesses including charities and "mom and pop" shops that can't afford extra server resources. In no way do I use Cloudflare to erode user privacy or trust, but can understand others looking at it that way. If I had the option to pick my clients and their budgets, it wouldn't be an issue.

Re: HTTP/3 is everywhere but nowhere

#298

Post by o11c »

CharlieDigital wrote: post #2

> 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],…

Until the dotnet packages are shipped in every major Linux distro's default repositories (it's okay if it's a 5-year-old version), we can't call C# a major language.

But apparently there aren't enough people willing to actually do the work.

Re: HTTP/3 is everywhere but nowhere

#299

Post by raggi »

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…

HTTP/3 is not a mobile centric technology. Yes there was a lot of discussion of packet pacing and it's implications for mobile in early presentations on QUIC but that's not the same as "centric", that's one application of the behavior. Improved congestion control, reduced control plane cost and removal of head of line blocking behaviors have significant value in data center networks as well. How often do you work with services where they have absolutely atrocious tail latencies and wide gaps between median and mean latencies? how often is that a side effect of http/tcp semantics?

IPv6 is the same deal, I sort of understand where the confusion comes from around QUIC because so much was discussed about mobile early on, and it just got parroted heavily in the rumor mill, but IPv6? that long predates the mobile explosion, and again, it helps as an application, but ascribing it as the only application because of it's applicability somewhere else doesn't hold up to basic scrutiny. The largest data centers these days are pushing up against a whole v4 IP class (I know, classes are dead, sorta) in hardware addressable compute units - a trend that is not slowing.

We did this with quic data center side: https://tailscale.com/blog/living-in-the-future#the-c10k-pro... and while it might be slightly crazy in and of itself, it's far more practical with multiplexing than with a million excessively sized buffers competing over pools and so on.

There is absolutely value to quic and ipv6 in the data center, perhaps it's not so useful for traditionally shaped and sized LAMP stacks, but you can absolutely make great use of these at scale and in modern architectures, and they open a lot of doors/relax constraints in the design space. This also doesn't mean everyone needs to reach for them, but I don't think they should be discarded or ascribed limited purpose so blithely.

Re: HTTP/3 is everywhere but nowhere

#300

Post by progmetaldev »

crazygringo wrote: post #88
kragen wrote: post #60

Earlier quoted context omitted.

The normalization of CAPTCHAs for simply reading what ought to be public information strikes me as very alarming, as does characterizing essential privacy and anti-censorship measures like VPNs as "abusive". Something like 1% of HTTP hits pose some risk of spam or fraud, those where somebody is trying to post a message or a transaction or something. The other 99% are just requesting a static HTML document or JPEG (or…

Of course it's alarming. But what's the alternative? > Something like 1% of HTTP hits pose some risk of spam or fraud It doesn't matter if it's a tiny percentage of requests that are spam/fraud. The only thing that matters is the absolute amount, and that's massive. > Static file serving is very difficult to DDoS No it's not, and most pages aren't particularly static. They're hitting all sorts of databases and caches…

This is also my experience. If you are dealing with clients that can pay to have their content cached, and not hit the originating server, that's great. To me, that sounds like what Cloudflare offers. Unless you have the ability to push an entire website into a CDN, there are things like query (GET) parameters on a URL that will bypass the cache and hit the server. This means that only using file caching is not viable unless you are running a completely static website. Most websites allow the client to make changes to the content through some web based GUI, and you have things like pagination where the maximum page number may not be known ahead of time for your CDN.

I have dealt with DDoS attacks with and without a service like Cloudflare, and without something like Cloudflare, the costs are extremely high. These are not clients pulling in millions of dollars of sales, even per year. There are IP blocks, but sometimes those bots are running on networks shared with the client's customers. Most clients I deal with couldn't fathom dealing with a static website, even if I could give them a hidden backend that pushed all files to a CDN for caching. I have enough trouble explaining why a page isn't showing recent changes, even with a big button stating to press it if your page changes do not display (integration with the Cloudflare caching API).

Bots, human fraud, it's all a balancing act while trying to give your clients the easiest solution possible for them to run their business online. Without a massive hosting budget, it's not feasible to provide for an easily maintainable client solution, that is also easy on their clients, and prevents abuse from bots and those that would cause fraud or damage.

Post reply on HN