201–210 of 504 posts
Every single project mentioned in the article is to some extent either open source and/or community driven. So nobody considered HTTP/3 interesting enough to rush and add support for it very quickly. It'll get there, but fast? I don't think so, see IPv6. Also, nobody considered HTTP/3 worth enough of paying for maintainers to add support for it.
"We'll get to IPv6 after we finish IPv5"
Earlier quoted context omitted.
The largest use of IPv6 is in mobile (cell) networks. When they effectively killed IP block mobility (provider independent netblocks), they (the standards bodies) effectively killed it's adoption everywhere else. I work in the networking space and outside of dealing with certain European subsidiaries, we don't use IPv6 anywhere. It's a pain to use and the IPv6 stacks on equipment (routers, firewalls, etc) are no wher…
What do you mean? IPv6 PI is common and easy to get; there's no big difference between IPv4 and IPv6 there.
Outside of Europe I don't know anyone not FAANG sized that managed to get it done in the last few years.
In my dealings with small to medium sized biz, I usually go the SDWAN route to aggregate and balance in IPv4 space instead as it is MUCH easier to get it done from an ISP.
Reminds me of IPv6... When I was 17... (2007) and learned about it I was very hyped to see it become mainstream.. I still don't know why we go out of our way to only use IPv4 to this day. Its even older than when I discovered what IPv6 was.
lot of people do use IPv6 but what turned out to be a big problem (not enough IP addresses for clients) was solved by CGNAT and a simple market (for servers) of course it's important to understand that it was cheaper to deploy thousands of CGNAT boxes than to upgrade the whole Internet (and corresponding software)
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…
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 including video content delivery and web browsing, despite their intermittent traffic patterns. QUIC incurs a video bitrate reduction of up to 9.8% compared to HTTP/2 when delivering DASH (Sodagar, 2011) video chunks over high-speed Ethernet and 5G. Again, such QoE degradation only exhibits when the underlying bandwidth is sufficiently high. For example, the impact is hidden over 4G but unleashed over 5G. QUIC’s page load time (PLT) is 3.0% longer than HTTP/2’s, averaged across 100 representative websites, with a long tail of page load time gaps over 50%.
--- end quote ---
Latency is all good ... until latency isn't the only thing affecting the performance
> 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.
Indeed, why not claim something that article never claimed and then claim moral superiority for yourself. Nowhere in the article do authors claim to have servers 0ms from each other with 0 packet loss.
Additionally, if your performance degrades even in these ideal conditions, what does this promise for non-ideal conditions?
I’m wondering why switching Node from OpenSSL to BoringSSL is considered hard? Is the JavaScript API exposing too many implementation details?
Earlier quoted context omitted.
I routinely have concerns about lag on mobile. It sucks to have to wait for 10 seconds for a basic app to load. And that adds up over the many many users any given app or website has.
> I routinely have concerns about lag on mobile. It sucks to have to wait for 10 seconds for a basic app to load. That's a software architecture problem, not a transport layer problem.
Earlier quoted context omitted.
requests dead? The reason given for not including it in the stdlib was so it could evolve more rapidly. Back then the protocol layer was handled/improved by urllib3.
It’s not evolving at all: > Requests is in a perpetual feature freeze, only the BDFL can add or approve of new features. The maintainers believe that Requests is a feature-complete piece of software at this time. > One of the most important skills to have while maintaining a largely-used open source project is learning the ability to say “no” to suggested changes, while keeping an open ear and mind. > If you believe…
Earlier quoted context omitted.
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…
Can you explain more specifically the threats faced by your website? Please help us understand what attacks you are currently facing. Are you currently getting DDoSed? Did the DDoSer stop DDoSing when you blocked HTTP 1.1? Did your credit card chargebacks drop by 50%? --- According to other commenters the main use case for HTTP/3 is ads serving. Should I assume your project is an ad server? I could disable HTTP/3 in…
The two other commenters are wrong, ads are not the main use case at all. And disabling HTTP/3 won't block ads, not even the tiniest bit. It appears you are getting a lot of misinformation.
> 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 administer and debug, and is supported by most reverse proxies. As such, there's not much need for HTTP/3 in server side languages like Golang and Python, as HTTP/1.1 is almost always available (and faster and easier to debug!) in the datacenter anyways.
HTTP/3 and IPv6 are mobile centric technologies that are not well suited for the datacenter. They really shine on ephemeral spotty connections, but add a lot of overhead in a scenario where most connections between machines are static, gigabit, low-latency connections.
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.
I would say that .NET is the best example that Microsoft has not changed: https://isdotnetopen.com/
I'm baffled by insistent behavior like this. I think it is just alienating people and even if they move ecosystems, the negative impression will stay.
If you engage in bad faith behavior in a technical discussion, can you be expected to conduct yourself acceptably in a professional setting? Unlikely.
This is a discussion about HTTP/3 support of all things. Why does it happen only when someone leaves a briefly positive note on C#? I don't know any other language (besides PHP, to an extent) that gets the same amount of hate.