HTTP/3 is everywhere but nowhere(httptoolkit.com)
httptoolkit.com
HTTP/3 is everywhere but nowhere
https://httptoolkit.com/blog/http3-quic-open-source-support-nowhere/
502 コメント
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.
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.
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.
Major reason for that is BSD Sockets and their leaky abstraction that results in hardcoding protocol details in application code.
For a good decade a lot of software had to be slowly patched in every place that made a socket to add v6 support, and sometimes multiple times because getaddrinfo didn't reach everyone early enough.
For a good decade a lot of software had to be slowly patched in every place that made a socket to add v6 support, and sometimes multiple times because getaddrinfo didn't reach everyone early enough.
> results in hardcoding protocol details in application code
I think in principle, an application didn't need to know the exact format of an IP address, even if connecting directly to an IP. A simple idea that could have made application code much more IP-agnostic would have been for SOCK_ADDR_IN to take the IP in string format, not as a four-byte value. That way, lots of application code would not need to even be recompiled to move from a 4 byte IPv4 address to a 16 byte IPv6 address, whereas today they not only need to be recompiled, they need to be changed at the source level to use a new type that allows for both.
Of course, code that operates on packets, in the TCP/IP stack of the OS would have still needed to be rewritten. But that is far less code than "every application that opens a socket".
Of course, this only applies to code that uses IPs only to open connections. There's lots of application code that does more things with IPs, such as parsing, displaying, validating etc. All of this code would still need to be rewritten to accept IPv6 addresses (and its much more complex string representations), that part is inevitable.
Of course, code that operates on packets, in the TCP/IP stack of the OS would have still needed to be rewritten. But that is far less code than "every application that opens a socket".
Of course, this only applies to code that uses IPs only to open connections. There's lots of application code that does more things with IPs, such as parsing, displaying, validating etc. All of this code would still need to be rewritten to accept IPv6 addresses (and its much more complex string representations), that part is inevitable.
Yeah, the big issue is that any code that took addresses from user input had to do validation to make sure addresses were valid, in allowed ranges, etc.
While the sockaddr struct allowed to to abstractly handle v4/v6 socket connections, there wasn’t a clean way to do all of that additional stuff and IP address logic leaked into all kinds of software where you wouldn’t first expect it.
Something as simple as a web app that needs to inspect proxy headers would even have it.
It also didn’t help that it became practice to explicitly not trust the addr resolution offered by the sockets API because it would do unexpected things like resolving something that looked like an integer to a uint32 and then a 4 byte V4 addr.
While the sockaddr struct allowed to to abstractly handle v4/v6 socket connections, there wasn’t a clean way to do all of that additional stuff and IP address logic leaked into all kinds of software where you wouldn’t first expect it.
Something as simple as a web app that needs to inspect proxy headers would even have it.
It also didn’t help that it became practice to explicitly not trust the addr resolution offered by the sockets API because it would do unexpected things like resolving something that looked like an integer to a uint32 and then a 4 byte V4 addr.
This is vastly oversimplifying the problem, the difference between IPv4 and IPv6 is not just the format of the address. Different protocols have different features, which is why the sockaddr_in and sockaddr_in6 types don't just differ in the address field. Plus the vast majority of network programs are using higher level abstractions, for example even in C or C++ a lot of people would be using a network library like libevent or asio to handle a lot of these details (especially if you want to write code that easily works with TLS).
There isn't much need for many applications to know or care what IP protocol they are speaking, they are all just writing bytes to a TCP stream. I think the parent is saying that existing socket abstractions meant that these applications still had to be "upgraded" to support IPv6 whereas it could/should have been handled entirely by the OS with better socket APIs.
The simplest case would have been using a variant of Happy Eyeballs protocol.
Resolve the A and AAAA records, and try to connect to them at the same time. The first successful connection wins (maaaaybe with a slight bias for IPv6).
This would have required an API that uses the host name and folds the DNS resolution and connection into one call. Instead, the BSD socket API remained at the "network assembly" level with the `sockaddr_in/sockaddr_in6` structures used for address information.
Resolve the A and AAAA records, and try to connect to them at the same time. The first successful connection wins (maaaaybe with a slight bias for IPv6).
This would have required an API that uses the host name and folds the DNS resolution and connection into one call. Instead, the BSD socket API remained at the "network assembly" level with the `sockaddr_in/sockaddr_in6` structures used for address information.
Yes, multiple ways, including implemented ways.
For the examples I am going to use the typical "HTTP to example.com" case.
Some OSI-focused stacks provided high level abstraction that gave you a socket already set for listening or connected to another service, based on combination of "host name", "service name", and "service type".
You'd use something like
Similar approach was done in Plan 9 (and thus everyone who uses Go is going to see something similar) with the dial API:
For the examples I am going to use the typical "HTTP to example.com" case.
Some OSI-focused stacks provided high level abstraction that gave you a socket already set for listening or connected to another service, based on combination of "host name", "service name", and "service type".
You'd use something like
connect("example.com", "http", SVC_STREAM_GRACEFUL_CLOSE) // using OSI-like name for the kind of service TCP provides
Similar approach was done in Plan 9 (and thus everyone who uses Go is going to see something similar) with the dial API:
dial("example.com!http",0,0,0)
No, for example on Android and iOS the APIs for when you connect to a server the hostname is a string. This hostname can be either an ipv4 address, an ipv6 adress, or a domain. The BSD sockets API on the other hand forces each application to implement this themselves and a lot of them took the shortcut of only supporting ipv4.
It isn't about upgrading one protocol to another but about having the operating system abstract away the different protocols from the application.
It isn't about upgrading one protocol to another but about having the operating system abstract away the different protocols from the application.
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 protocol, but it's not being used.
"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 protocol, but it's not being used.
And it would have failed for exactly the same reasons, because just changing the address field size is enough to have everyone who uses BSD Sockets to rewrite all parts of code that create sockets.
Especially since getaddrinfo was ported over from more streams/OSI oriented stacks pretty late, precisely because BSD Sockets required separate path for every protocol.
On hw side, by mid-1990s even changing one routing-important field would mean possibly a new generation of ASICs needed with more capabilities.
Essentially, once you agree to break one field, the costs are so big why not try fixing other parts? Especially given that IETF has rejected an already implemented solution of just going with OSI for layer 3.
Especially since getaddrinfo was ported over from more streams/OSI oriented stacks pretty late, precisely because BSD Sockets required separate path for every protocol.
On hw side, by mid-1990s even changing one routing-important field would mean possibly a new generation of ASICs needed with more capabilities.
Essentially, once you agree to break one field, the costs are so big why not try fixing other parts? Especially given that IETF has rejected an already implemented solution of just going with OSI for layer 3.
All that code using BSD sockets is rewritten by now to support v6, right? If so, that can't be the reason, cause v4 is still dominant.
And btw, what I suggested would actually work without userspace code changes until you want to start subdividing the /32s. Cause v4 addresses would've still been valid in v6.
And btw, what I suggested would actually work without userspace code changes until you want to start subdividing the /32s. Cause v4 addresses would've still been valid in v6.
Where would you store the other 96 bits. In the body?
Ipv6 packet format was needed either way, but only with the 32-bit address space at first (the other 92 bits set to 0). You simply tell your system to start using v6 instead, and everything else stays the same. No dual-stack.
Next step would be upgrading all those parts like DNS, DHCP, etc to accept the 128-bit addrs, which again can be done in isolation. Then finally, ISPs or home routers can start handing out longer addresses like 1.1.1.1.2.
Next step would be upgrading all those parts like DNS, DHCP, etc to accept the 128-bit addrs, which again can be done in isolation. Then finally, ISPs or home routers can start handing out longer addresses like 1.1.1.1.2.
There are two ways for me to interpret "simply tell your system to start using v6".
If it means upgrading every program, then your plan works but it's the same as how things work today. You're telling people to do a thing, and they aren't bothering. The "simple" step isn't simple at all.
If it doesn't mean upgrading every program, then your rollout fails on the last step. You start handing out longer addresses and legacy programs can't access them.
If it means upgrading every program, then your plan works but it's the same as how things work today. You're telling people to do a thing, and they aren't bothering. The "simple" step isn't simple at all.
If it doesn't mean upgrading every program, then your rollout fails on the last step. You start handing out longer addresses and legacy programs can't access them.
It's the second one. But legacy programs did get upgraded, so I don't see why they wouldn't under this other plan. If anything, it's easier because you're only making the address field bigger and it's not a separate case. Some routers struggled with 128-bit addrs due to memory, and could've gotten away with like 48 or 64 bits if they're using DHCP.
Lots of legacy programs, and current programs, and other things that could have been upgraded did not get upgraded. Getting to the situation where you can just flick a switch is not a realistic dream. There's not enough motivation for the average business to add support for a version that isn't in use yet.
"It's not being used", except for nearly half of Google's traffic: https://www.google.com/intl/en/ipv6/statistics.html
Disconnect your phone from Wi-Fi and visit https://ifconfig.co/ . If you're a Verizon customer, it's probably going to show you an IPv6 address. It's huge, right now, today.
Disconnect your phone from Wi-Fi and visit https://ifconfig.co/ . If you're a Verizon customer, it's probably going to show you an IPv6 address. It's huge, right now, today.
"Depended on" is what I should have said. An ISP or website can be v4-only or support both, but it's not going to be v6-only.
Fair. I bet that'll change soon though. My prediction is that it'll be a mobile-first game, like the next Pokemon Go sort of thing, that'll be IPv6-only.
Plenty of mobile users use wifi at home/work. Telling them to disable their ipv4-only wifi just to play your game is going to be a non-starter, especially when the cost of ipv4 address adds negligible cost to infrastructure. Is your CTO really going to massively increase user friction ("turn of your wifi to play!") just so try to save a few cents (comparatively speaking) on infra?
It could be in a country where people don't have home wifi.
Like africa which does not have a shortage of V4 address and there is effectively no v6 rollout?
I agree it would probably be something mobile-first that does it, since those carriers all(?) support v6.
I ran an ipv6-only website because that's the only way I can have a publicly routeable address at home. Just as an anecdote.
this isn't true. I know because at some point XFinity started dropping ipv6 connections for me and I noticed because a number of sites (forget which) were broken
What do you mean by dropping ipv6 connections, like dropping ipv6 packets? That's only an issue if you're using v6. I disabled ipv6 on my router years ago and have never had a problem just using v4.
There is not a single widely used service on the Internet that depends on IPv6 exclusively.
I had to check if HackerNews even supports ipv6, apparently it only recently started: https://news.ycombinator.com/item?id=39099065
> "It's not being used", except for nearly half of Google's traffic:
One of the world's largest ISPs, Vodafone, is yet to support IPv6.
What Google supports is irrelevant if your ISP can't handle the traffic.
One of the world's largest ISPs, Vodafone, is yet to support IPv6.
What Google supports is irrelevant if your ISP can't handle the traffic.
True, but irrelevant to my point. Whether a particular ISP supports doesn’t matter: it is being widely used by the rest of the world, to the point that it’s half of Google’s traffic.
> True, but irrelevant to my point.
Vodafone's network is reported to handle around 20% of the world's traffic. It's not a random ISP. It's network does not support IPv6. It is how a big chunk of all internet users experience the internet. Claiming it doesn't matter in a discussion over IPv6 adoption rate is ludicrous.
Vodafone's network is reported to handle around 20% of the world's traffic. It's not a random ISP. It's network does not support IPv6. It is how a big chunk of all internet users experience the internet. Claiming it doesn't matter in a discussion over IPv6 adoption rate is ludicrous.
> 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).
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).
The main problem wasn't all the smaller features but one big one in particular that can't be split into smaller pieces, the new addressing scheme. They wanted to replace all the existing addresses, which meant replacing all the routes. Besides the difficulty of that by itself, it automatically meant that the v6 versions of DNS, DHCP, NAT, etc wouldn't support v4, rather it'd be a totally separate stack.
There were also some small things. And routers often having bad defaults for v6, which btw, would not even be a concern if they left the big thing alone.
There were also some small things. And routers often having bad defaults for v6, which btw, would not even be a concern if they left the big thing alone.
> Besides the difficulty of that by itself, it automatically meant that the v6 versions of DNS, DHCP, NAT, etc wouldn't support v4, rather it'd be a totally separate stack.
Sure, "make the addresses bigger" would have required providing DHCPv6, DNS AAAA records, and various other protocol updates for protocols that embedded IP addresses. And making changes to the protocol header at the same time (e.g. removing the redundant checksum) were also a good idea.
It didn't require pushing SLAAC instead of DHCP.
It didn't require recommending (though fortunately not requiring) IPsec for all IPv6 stacks.
It didn't require changing the address syntax to use colons, causing pain for all protocols that used `IP:port` or similar.
It didn't require mandating link-local addresses for every interface.
It didn't require adding a mandatory address-collision-detection mechanism.
And I'm sure I'm forgetting a few.
Sure, "make the addresses bigger" would have required providing DHCPv6, DNS AAAA records, and various other protocol updates for protocols that embedded IP addresses. And making changes to the protocol header at the same time (e.g. removing the redundant checksum) were also a good idea.
It didn't require pushing SLAAC instead of DHCP.
It didn't require recommending (though fortunately not requiring) IPsec for all IPv6 stacks.
It didn't require changing the address syntax to use colons, causing pain for all protocols that used `IP:port` or similar.
It didn't require mandating link-local addresses for every interface.
It didn't require adding a mandatory address-collision-detection mechanism.
And I'm sure I'm forgetting a few.
It didn't require removing ARP and inventing Neighbor Discovery that embeds the hardware addresses into the IP address.
It didn't require the Ruby Goldberg "on link" network mechanism.
It didn't require multicast instead of broadcasts for local network discovery.
It didn't require using DNS config (of all things) to specify V4/V6 priority.
It didn't require adding a "flow label" that is nobody to this day knows how to use properly.
The list of fails is ridiculous.
It didn't require the Ruby Goldberg "on link" network mechanism.
It didn't require multicast instead of broadcasts for local network discovery.
It didn't require using DNS config (of all things) to specify V4/V6 priority.
It didn't require adding a "flow label" that is nobody to this day knows how to use properly.
The list of fails is ridiculous.
Yeah. I didn't like any of those proposed changes, especially the colons. You also didn't mention how NAT6 isn't a thing by default.
I wonder if something like HTTP connection upgrade would have been possible with ipv6-ipv4, maybe something like imagine Machine 1 with ips 1.1.1.1 and 11::11 and machine 2 with ips 2.2.2.2 and 22::22.
When machine 2 receives a packet from 1.1.1.1 at 2.2.2.2 it sends a ipv6 ping-like packet to the ipv4-mapped address ::ffff:1.1.1.1 saying something like "hey you can also contact me at 22::22 and if machine 1 undertands then it can try to use the new address for the following packets.
I can see how it would be hard to secure this operation.
When machine 2 receives a packet from 1.1.1.1 at 2.2.2.2 it sends a ipv6 ping-like packet to the ipv4-mapped address ::ffff:1.1.1.1 saying something like "hey you can also contact me at 22::22 and if machine 1 undertands then it can try to use the new address for the following packets.
I can see how it would be hard to secure this operation.
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.
>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 unilaterally changing your prefix - something that can only happen in IPv6.
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 unilaterally changing your prefix - something that can only happen in IPv6.
> 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.
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
My understanding is that for some bizarre reason this is not usually the case with IPv6
> It removes tons of overhead and cruft
Can you elaborate? Here, or with links? What kinds of overhead and cruft?
Can you elaborate? Here, or with links? What kinds of overhead and cruft?
* The header is a fixed length.
* You can't fragment packets.
* The redundant checksum header was removed.
* No more private addressing (unless you're a glutton for punishment).
* No more NAT (see above).
* Simpler routing.
* Doesn't require DHCP.
It benefits hugely from the lessons learned with IPv4.
* You can't fragment packets.
* The redundant checksum header was removed.
* No more private addressing (unless you're a glutton for punishment).
* No more NAT (see above).
* Simpler routing.
* Doesn't require DHCP.
It benefits hugely from the lessons learned with IPv4.
IPv6 packets can still be fragmented, but only at the source. IPv4 fragmentation has only worked this way in practice for a long time.
Private addressing is still needed with IPv6, it's a crucial part of how address allocation works, and it's the only way to reliably connect to a client-like IPv6 device on the local network, since its public IP address will change all the time for privacy reasons, assuming it respects best practices.
Routing is only simpler if the ISPs actually hand out the large prefixes they are supposed to. Not all of them do.
DHCP is still required for many use cases. So now you have two solutions for handing out addresses, and you need to figure out when to use SLAAC and when to use DHCP. This is strictly more complex than IPv4, not simpler. SLAAC is mostly just unnecessary cruft, a cute little simple path for limited use cases, but it can never replace DHCPv6 for all use cases (e.g. for subnets smaller than a /64, for communicating additional information like a local DNS server or NTP server, for complex network topologies, for server machines etc).
Private addressing is still needed with IPv6, it's a crucial part of how address allocation works, and it's the only way to reliably connect to a client-like IPv6 device on the local network, since its public IP address will change all the time for privacy reasons, assuming it respects best practices.
Routing is only simpler if the ISPs actually hand out the large prefixes they are supposed to. Not all of them do.
DHCP is still required for many use cases. So now you have two solutions for handing out addresses, and you need to figure out when to use SLAAC and when to use DHCP. This is strictly more complex than IPv4, not simpler. SLAAC is mostly just unnecessary cruft, a cute little simple path for limited use cases, but it can never replace DHCPv6 for all use cases (e.g. for subnets smaller than a /64, for communicating additional information like a local DNS server or NTP server, for complex network topologies, for server machines etc).
* First three points matter more on bad connections, but are less of a problem on good ones.
* Private addressing is a feature, not a bug, in the datacenter.
* NAT is a feature, not a bug, in the datacenter.
* Simpler routing matters more on bad connections, but is less of a problem on good ones.
* DHCP is a feature, not a bug, in the datacenter.
Overall, it adds features that I don't need in my datacenter, and takes away others that I do and now need to add back. Like I said: it's great outside the datacenter, not so great inside it.
* Private addressing is a feature, not a bug, in the datacenter.
* NAT is a feature, not a bug, in the datacenter.
* Simpler routing matters more on bad connections, but is less of a problem on good ones.
* DHCP is a feature, not a bug, in the datacenter.
Overall, it adds features that I don't need in my datacenter, and takes away others that I do and now need to add back. Like I said: it's great outside the datacenter, not so great inside it.
> * No more private addressing (unless you're a glutton for punishment).
The question of whether or not you use private addressing is, AFAICT, independent of the protocol. I mean, there's no material difference between private and public addressing.
> * No more NAT (see above).
Ditto. You don't have to NAT over IPv4, and you can NAT over IPv6; and - you may want to or need to, depending on restrictions on your connection.
> * Simpler routing
In what way?
> * Doesn't require DHCP.
IPv4 doesn't require DHCP either, IIANM.
But - point taken on the other simplifications!
The question of whether or not you use private addressing is, AFAICT, independent of the protocol. I mean, there's no material difference between private and public addressing.
> * No more NAT (see above).
Ditto. You don't have to NAT over IPv4, and you can NAT over IPv6; and - you may want to or need to, depending on restrictions on your connection.
> * Simpler routing
In what way?
> * Doesn't require DHCP.
IPv4 doesn't require DHCP either, IIANM.
But - point taken on the other simplifications!
> * No more private addressing (unless you're a glutton for punishment).
OK. So what happens if your ISP connection goes down? Your router will detect this and withdraw the ISP's prefix.
So now you can't print because your printer doesn't have an address. Good luck.
> * Doesn't require DHCP.
This turns out to be a problem, as you can't easily see what's going on in the network.
OK. So what happens if your ISP connection goes down? Your router will detect this and withdraw the ISP's prefix.
So now you can't print because your printer doesn't have an address. Good luck.
> * Doesn't require DHCP.
This turns out to be a problem, as you can't easily see what's going on in the network.
I really have to agree with the "easier to debug" part. I one time had to debug a particularly nasty networking issue that was causing HTTP connections to just "stop" midway through sending data. Turned out to be a confusion mismatch between routers and allowed packet sizes. It would have been so much worse with a non-plaintext protocol.
Totally agree. Most of the benefit of HTTP 2/3 comes from minimizing TCP connections between app->lb. Once you are past the lb the benefits are dubious at best.
Most application frameworks that I've dealt with have limited capabilities to handle concurrent requests, so it becomes a minor issue to have 100+ connections between the app and the lb.
On the flipside, apps talking to the LB can create all sorts of headaches if they have even modest sized pools. 20 TCP connections from 100 different apps and you are already looking at hard to handle TCP flooding.
Most application frameworks that I've dealt with have limited capabilities to handle concurrent requests, so it becomes a minor issue to have 100+ connections between the app and the lb.
On the flipside, apps talking to the LB can create all sorts of headaches if they have even modest sized pools. 20 TCP connections from 100 different apps and you are already looking at hard to handle TCP flooding.
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.
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.
I will acknowledge that truly massive datacenter deployments can and do use these technologies to good effect, but I haven't worked at any of these kinds of places in the last fifteen years and I suspect many (most?) of my colleagues haven't either. Anything smaller than a /8, they usually don't add much and just get in the way more often than not.
HTTP3 is patch that unfucked some stupid design choices from HTTP2[1]
However IPv6 is perfectly suited to the datacentre. So long as you have properly infrastructure setup (ie properly functioning DNS) IPv6 is a godsend for simplifying medium scale infra.
In fact, if you want to get close to a million hosts, you need ipv6.
[1] Me and http/2 have beef, TCP multiplexing was always going to be a bad idea, but because idealism got in the way of testing
However IPv6 is perfectly suited to the datacentre. So long as you have properly infrastructure setup (ie properly functioning DNS) IPv6 is a godsend for simplifying medium scale infra.
In fact, if you want to get close to a million hosts, you need ipv6.
[1] Me and http/2 have beef, TCP multiplexing was always going to be a bad idea, but because idealism got in the way of testing
> pass back HTTP 1.1 ... to the backing service.
Sure, but now you've lost some of the benefits of HTTP/3, such as the header compression and less head-of-line blocking. To some degree the load balancer can solve this by using multiple parallel HTTP 1.1 streams, but in practice I've seen pretty bad results in many common scenarios.
Sure, but now you've lost some of the benefits of HTTP/3, such as the header compression and less head-of-line blocking. To some degree the load balancer can solve this by using multiple parallel HTTP 1.1 streams, but in practice I've seen pretty bad results in many common scenarios.
No one cares about those "benefits" _on a gigabit line_. The head of your line is not blocked at such speeds, believe you me. Same thing with compression. Like, why. Other than to make it harder to debug?
I had head-of-line-blocking issues recently on a 10 Gbps data centre link!
HTTP client packages often use a small, fixed number of connections per domain. So if you have two servers talking to each other and there's slow requests mixed in with short RPCs, the latter can sit in a queue for tens of seconds.
HTTP client packages often use a small, fixed number of connections per domain. So if you have two servers talking to each other and there's slow requests mixed in with short RPCs, the latter can sit in a queue for tens of seconds.
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.
QUIC/HTTP3 relies on TLS. If you already have some encrypted transport, like an Istio/Envoy service mesh with mutual TLS, or Zerotier/Tailscale/Wireguard style encrypted overlay network, then there are no benefits to using HTTP3. Moreover native crypto libraries tend do a better job handling encryption anyway so rather than wasting cycles doing crypto in Go or Node it makes more sense to let the service mesh or the overlay handle encryption and let your app just respond to clear requests.
> let the service mesh or the overlay handle encryption
which could use HTTP/2 or HTTP/3
and HTTP/2 for the localhost (or unix socket) gateway<->app step to provide e.g. WebTransport support
which could use HTTP/2 or HTTP/3
and HTTP/2 for the localhost (or unix socket) gateway<->app step to provide e.g. WebTransport support
Sure I was responding to the context as I understood it here which was listening on HTTP/3 as an application rather than a service mesh layer. HTTP/3 can definitely be a choice for service mesh or some sort of overlay. Personally if I were setting up a new cloud/DC today I'd probably just use ZeroTier (or Tailscale) and let the overlay deal with encryption while I just have my sources and destinations do IP based filtering.
How is IPv6 not suitable?
Ok, HTTP/3 is mobile centric. But why not fallback to HTTP/2 in all other cases?
HTTP/2 is still mostly implemented only over TLS, and that can mean significant and completely useless overhead if the server-LB connection is already encrypted using some VPN solution like WireGuard.
http/1 traffic is a lot easier to inspect
Speaking of gRPC, it's unfortunate that they went all-in on HTTP/2. Should have made it work over HTTP/1.1. I know others made it work, but it wasn't first-party. Maybe it could've been more popular than JSON-over-HTTP by now.
No reason to choose HTTP/1.1 over HTTP/2.
The reason is that a lot of things don't support /2, ironically including Google's own AppEngine. Also Heroku.
Nobody needs HTTP/2. It's just Google doing embrace-extend-extinguish of public domain protocols.
> 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.
Support for Windows, Linux[2], and Mac[3] (the latter two with some caveats).
Overall, I think for most dev teams that are not building networking focused products/platforms, HTTP/3 is probably way down the stack of optimizations and things that they want to think about, especially if the libraries available have edge cases and are too early for production. Who wants to debug issues with low-level protocol implementations when there are features to ship, releases to stabilize, and defects to fix?
[0] https://learn.microsoft.com/en-us/dotnet/fundamentals/networ...
[1] https://github.com/microsoft/msquic
[2] https://learn.microsoft.com/en-us/dotnet/fundamentals/networ...
[3] https://learn.microsoft.com/en-us/dotnet/fundamentals/networ...
> 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 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.
.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.
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/
These are handful of handpicked twitter posts that are almost 3 years old, including the page itself.
https://github.com/ghuntley/isdotnetopen
The website doesn't even explain what they mean by open.
Nor they explain why they think .NET is not open source.
https://github.com/ghuntley/isdotnetopen
The website doesn't even explain what they mean by open.
Nor they explain why they think .NET is not open source.
Isn't `vsdbg` still distributed with an incredibly restrictive license? Doesn't sound all too open to me.
Further, the twitter posts themselves are still relevant I believe. If someone took over my repo, I'd remember it 3 years later.
Further, the twitter posts themselves are still relevant I believe. If someone took over my repo, I'd remember it 3 years later.
VSCodium uses NetCoreDbg. There are community snippets to make the same work for Cursor, NeoVim, etc.
So far, there was little demand to write another debugger integration (because, really, the debugger core is implemented in the runtime itself - what vsdbg, NetCoreDbg and Rider all primarily do is consume the runtime API).
So far, there was little demand to write another debugger integration (because, really, the debugger core is implemented in the runtime itself - what vsdbg, NetCoreDbg and Rider all primarily do is consume the runtime API).
Yes, it is annoying. You can run VS Code on a PI and have an amazing Rust environment, or Zig, or any language. Except for .Net. Why MS? What is the benefit to your business to make .net suck without your closed sourced bits?
They are criticising Microsoft closing access to .NET debugging tools: https://www.theverge.com/2021/10/22/22740701/microsoft-dotne...
This link again?
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.
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.
First time I've seen that link. What's bad faith about it? Don't know why you're bringing Rust into this.
Parent comment was edited, it no longer seems to include "Rust", difficult to follow. :P
I edited it because it's not just my own experience of dealing with this. On twitter, I follow a couple Japanese developers from mainly gamedev scene and even they complain they started hearing more about "but it only works on windows" and "it's not open-source". Don't you find it strange that it should be the other way around the more years pass since .NET went OSS?
The link itself is also quite outdated and mainly consists of posts from Miguel de Icaza who's promoting Swift, arguably less OSS language. Take from that what you will.
The link itself is also quite outdated and mainly consists of posts from Miguel de Icaza who's promoting Swift, arguably less OSS language. Take from that what you will.
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 management until he finally gave up.
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 management until he finally gave up.
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 complaints you will read here are about what the authors think .NET’s problems are without ever verifying if any of that is true in hopes of making swipes for god knows what reason, because posting something accurate requires knowledge on the subject and the results of a cursory search usually do not support cheap arguments.
(and I see this as an embarrassment because you can learn a lot from doing research instead of repeating the same tired phrases you heard elsewhere)
Instead, the complaints you will read here are about what the authors think .NET’s problems are without ever verifying if any of that is true in hopes of making swipes for god knows what reason, because posting something accurate requires knowledge on the subject and the results of a cursory search usually do not support cheap arguments.
(and I see this as an embarrassment because you can learn a lot from doing research instead of repeating the same tired phrases you heard elsewhere)
My point is that there was no "conflict of interest" when it comes to Miguel. If there was one person in the entire F/OSS ecosystem that ever wanted .NET to succeed, it was him. That is also why he spent so much time and effort trying to get Microsoft to not do things that alienate the community and harm .NET uptake.
Speaking for myself, I happen to like .NET from the technical perspective. While both the language and the stdlib have a lot of cruft from days of yore, it can mostly be ignored, and that aside it's a fast runtime with a decently expressive type system giving one considerable flexibility to pick the right tool to model different domains. It also has great tooling around it. But this all is separate from the question of how open .NET really is, and its long-term prospects in that department.
Speaking for myself, I happen to like .NET from the technical perspective. While both the language and the stdlib have a lot of cruft from days of yore, it can mostly be ignored, and that aside it's a fast runtime with a decently expressive type system giving one considerable flexibility to pick the right tool to model different domains. It also has great tooling around it. But this all is separate from the question of how open .NET really is, and its long-term prospects in that department.
.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!
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.
I assumed .NET is Windows-only and proprietary, too, but it has to do with me not having done enough research, so if it is not the case anymore, the blame is on me.
Hey, I just want to commend you for amending your perspective (even if a little). There's a lot of intellectual hoop jumping in this thread with respect to Microsoft.
One has to know what they don't know, or at least consider the possibility that they might not know the whole story. I did not know the whole story, but I do now, thanks to earlier comments with regarding to .NET!
It's not windows only but it's windows first. A lot of things are missing on other OSs and not nearly all of it is open source.
Fanboys are a bit in denial about this.
Fanboys are a bit in denial about this.
Why hasn't Java been tainted the same since Oracle bought Sun and now 100% controls Java's development? I am continuously surprised to see they continue to make major investments in the platform. Project Valhalla was started in 2014 and is still going strong. I keep waiting for Oracle to cancel all major Java improvements, then milk the remaining corpse.
Me too! And yet it keeps going, with a reasonably open process, and multiple OSS alternatives out there. It is possible to run a Java shop with zero Oracle-derived code, which may be why people are ok with actually using the Oracle JDK.
My bet is this is a pitched battle inside Oracle, and the forces that keep it open have been winning...so far.
My bet is this is a pitched battle inside Oracle, and the forces that keep it open have been winning...so far.
> multiple OSS alternatives out there
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)
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)
GitHub was purchased, which is a bit different.
TypeScript though I had no idea about! Good for them!
TypeScript though I had no idea about! Good for them!
> GitHub was purchased, which is a bit different.
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.
It only matters in the context of it being "ironic" that it is used and favored in the coding community.
OK, then thoughts on VS Code and TypeScript?
Microsoft contributions to Python?
Do they all trigger some weird instant irrational reaction?
Microsoft contributions to Python?
Do they all trigger some weird instant irrational reaction?
Depends. Is everything open source (TypeScript)? Or does it give me basically everything for free when building open source (Github)?
Github looks and works mostly indistinguishable from how it was 7 years ago.
So you are of the belief that Microsoft has not had any effect on GitHub over the last 7 years? Interesting.
Uh? That's not the case at all. It even has popup ads for copilot now.
Why is that ironic? Only one of those are Free Software
Yet, somehow DevOps and Visual Studio (proper) continue living as near zombies.
I would never have predicted Microsoft would still be developing a (sort of) Github competitor after acquiring Github. Why not plow all of that focus and energy into making Github the best project management system around? Project management in Github is one of the biggest gripes people have - even on Teams and Enterprise.
I would never have predicted Microsoft would still be developing a (sort of) Github competitor after acquiring Github. Why not plow all of that focus and energy into making Github the best project management system around? Project management in Github is one of the biggest gripes people have - even on Teams and Enterprise.
GitHub is behind ADO in multiple areas. Boards is the one they're furthest from ADO on; leaving that for last is letting them get the others to a state where ADO users can successfully migrate some of their work to GitHub now, even if the boards need to stay in ADO.
That said, Microsoft is never going to be able to completely kill Azure DevOps. If nothing else, they'll have to keep it alive for enterprise customers' TFVC source control history.
That said, Microsoft is never going to be able to completely kill Azure DevOps. If nothing else, they'll have to keep it alive for enterprise customers' TFVC source control history.
> TFVC source control history
Surely there's a migration path to git from TFVC? Many large projects successfully moved from CVS and SVN into git.
I'm just surprised that, after 7 years of owning Github, Microsoft hasn't plowed their resources into Github's Projects. It's literally the number one complaint I see regarding project management inside Github - and would likely be an easy way to scale subscriptions for Teams and Enterprise. Heck, today it's still impossible to generate a Burn Down chart without using 3rd party "Apps" or the API.
Surely there's a migration path to git from TFVC? Many large projects successfully moved from CVS and SVN into git.
I'm just surprised that, after 7 years of owning Github, Microsoft hasn't plowed their resources into Github's Projects. It's literally the number one complaint I see regarding project management inside Github - and would likely be an easy way to scale subscriptions for Teams and Enterprise. Heck, today it's still impossible to generate a Burn Down chart without using 3rd party "Apps" or the API.
The different branching approaches makes migrating history difficult. Microsoft's recommendation is to migrate just the tip, but will allow you to migrate up to 180 days of history for the trunk (no branches).
If you need branch history, or more than 180 days worth of history, the only option is third-party tooling (git-tfs). It seems to work good enough for development purposes (i.e. git blame)... but I'm not sure if it's good enough if we need the history for legal purposes.
If you need branch history, or more than 180 days worth of history, the only option is third-party tooling (git-tfs). It seems to work good enough for development purposes (i.e. git blame)... but I'm not sure if it's good enough if we need the history for legal purposes.
Yikes. I had no idea the situation was so bleak for those still stuck on TFSV.
Only Typescript is in-house. Others are acquisitions. Do you remember Embrace, extend, and extinguish times?
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
VS code is mostly in house too. Sure, they don’t own Electron, but I was at MSFT when project Monaco (which became the basis for VS Code) was started and remember being very impressed by it back then
Text editors and IDEs come and go, there is very little commitment to using one.
If you write a project in C#, you've committed to it and it's ecosystem. Getting out of there when MS makes a choice you don't agree with is going to be near impossible.
If you write a project in C#, you've committed to it and it's ecosystem. Getting out of there when MS makes a choice you don't agree with is going to be near impossible.
Eh, these days there's a lot of investment in the VSCode extension ecosystem.
They acquired Electron alongside with Atom with GitHub. It is hard not to make parallels between Atom and VS Code
They own Electron now...
From whom was VSCode acquired?
Does the distinction matter?
In the case of GitHub, yeah. I don’t think a Microsoft source control “social network” would have taken off in the same way GitHub did.
In fact when Microsoft purchased GitHub, quite a few people did leave and close their account. But GitHub already had such a monumental market lead that the departures ended up being a drop in the ocean.
To be honest, I’m still waiting for the moment when Microsoft managed to fuck it all up like they did with Skype.
In fact when Microsoft purchased GitHub, quite a few people did leave and close their account. But GitHub already had such a monumental market lead that the departures ended up being a drop in the ocean.
To be honest, I’m still waiting for the moment when Microsoft managed to fuck it all up like they did with Skype.
Don't forget prior to GitHub Microsoft ran the home-grown, TFS-enabled Codeplex. It worked quite well if using Visual Studio but obviously, like Skype, there was no reason to run it when "something better" came along.
https://en.wikipedia.org/wiki/CodePlex
https://en.wikipedia.org/wiki/CodePlex
I've left later on, when they started to impose 2FA and decided to scan all my code to train their AI.
They may be much less Linux-hostile today, but are still plenty user-hostile. Not to mention their lackadaisical security record.
Can you please highlight some examples of .NET’s lackadaisical security record? I’m curious for my own awareness.
Microsoft's. Consult your favorite search engine.
You might be interested in GitHub's State of the Octoverse report from 2020 that had a section dedicated to security of popular languages, active open source projects on GH with those languages, and the package managers for those platforms.
https://octoverse.github.com/2020/
https://octoverse.github.com/2020/
Microsoft's security record. Not one package manager.
https://arstechnica.com/security/2024/01/microsoft-network-b...
https://arstechnica.com/security/2024/01/microsoft-network-b...
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.
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.
except if you want to use for example system.windows.forms, then "oh well different teams maintain that, nobody made it for linux!!!" "the core is open!!!"
they clearly WANT applications written in .net not to be cross platform
they clearly WANT applications written in .net not to be cross platform
It's not about different teams, it's that System.Windows.Forms is exactly what the namespace says. It's Windows Forms. It's a fairly thin wrapper over the Windows API. It's never going to be adapted to be cross-platform and isn't really something they've put any development work into for many years at this point.
If you want a cross platform UI, use WPF with Avalonia. Or if you want something entirely from Microsoft themselves, there's MAUI as an option.
If you want a cross platform UI, use WPF with Avalonia. Or if you want something entirely from Microsoft themselves, there's MAUI as an option.
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 really really want to run WinForms on Linux, Mono is where it's at. But ... why?
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 really really want to run WinForms on Linux, Mono is where it's at. But ... why?
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"
We are talking about WinForms specifically. If you want crossplatform GUI, then don't write it in WinForms - write it in Gtk#, or Avalonia, or Uno, or ...
Note that C++, Rust, Go all don't have any kind of standard GUI support out of the box at all.
Note that C++, Rust, Go all don't have any kind of standard GUI support out of the box at all.
Avalonia: https://avaloniaui.net/, https://docs.avaloniaui.net/docs/overview/supported-platform...
Uno: https://platform.uno/, https://platform.uno/platforms/
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?
There's no such thing; it depends on the app that people are building, their use cases, and platforms.
Case in point: both Teams and VS Code: both web view wrappers.
Some trading shops are still using WPF and some are even using Windows Forms apps still.
Case in point: both Teams and VS Code: both web view wrappers.
Some trading shops are still using WPF and some are even using Windows Forms apps still.
I'm amazed people are still using WinForms. When I was going around tables at a job fair in college, 13ish years ago, one of the questions for me from representatives for a large bank was about if I've used WPF. I said I don't use it, and they basically told me I should get with the times.
JS is the only true cross-platform UI; sadly.
You spelled qt wrong
More accurately, HTML (+CSS)(+JS).
HTML is all you need for a cross platform UI.
HTML is all you need for a cross platform UI.
HTML is all you need for a very slow cross platform UI.
FTFY
FTFY
I haven’t developed with .NET in a dozen years, let alone since it went cross platform, but I at least know it is capable of being cross platform. It amazes me how many developers I speak to that still assume .NET is 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
That comes after adding an untrusted 3rd party repository no? Why are you omitting that part?
Which means that nothing written in .net will enter the real repository until that changes.
Which means that nothing written in .net will enter the real repository until that changes.
Because in the relevant distros it is included in the first-party feeds. Only Debian acts like a special snowflake making it needlessly complex for everyone (including Rust). I believe there is an ongoing work to modify .NET's full source build (i.e. https://github.com/dotnet/source-build) to satisfy Debian's admission requirements, but really it's a problem inflicted by Debian on themselves, not the other way around.
Rust is in debian. Why do you do FUD?
My comment says
> making it needlessly complex for everyone (including Rust)
have I missed something?
> making it needlessly complex for everyone (including Rust)
have I missed something?
Rust isn't a person, just FYI. If you had a point, please make it.
> Why are you omitting that part?
Because I didn't have to do that. Have you considered your distro might be special for reasons that have nothing to do with .NET?
Because I didn't have to do that. Have you considered your distro might be special for reasons that have nothing to do with .NET?
Can you name some examples of popular .Net applications on GNU/Linux or *BSD operating systems?
I can't even name any on Windows.
But that's not really what's being discussed in the context of this thread: application servers handling HTTP/3.
But that's not really what's being discussed in the context of this thread: application servers handling HTTP/3.
On Windows, a lot of desktop software is .NET these days. It can be pretty hard to say when the apps use native (or XAML) UI, though.
To give one example with a particularly large user base, NVidia control center was a WinForms app for a very long time.
To give one example with a particularly large user base, NVidia control center was a WinForms app for a very long time.
Sonarr/Lidarr and Jellyfin as a start, Ryujinx was one too in game emulation space until Nintentdo DMCA'd everything into oblivion.
These are user-facing applications anyway, not back-end ones which is the more common use-case of .NET (where Linux is the most popular OS).
These are user-facing applications anyway, not back-end ones which is the more common use-case of .NET (where Linux is the most popular OS).
I have not heard of these apps, but - I'll go look them up (well, the first two), and learn something. Thanks.
About back-end - I would repeat my question but I don't want to derail the conversation too far away from the original subject.
About back-end - I would repeat my question but I don't want to derail the conversation too far away from the original subject.
osu is a fairly popular rhythm game that is written in .net
https://github.com/ppy/osu
https://github.com/ppy/osu
They also severely underrate it's actual usage. For a non "major" language, there sure are a lot of jobs out there.
.NET ain't hip.
.NET ain't hip.
[deleted]
.NET ain’t hip because many of the shops that use it are dinosaurs in processes and culture.
And many are not. How many Python shops are living in the past? It’s the same problem everywhere.
I'd like this to be a lie but it's true, different languages have different cultures associated to them.
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 Cursor and the other VS Code forks, and won’t let the .net extensions work. I jumped through a lot of hoops but they keep finding ways to break it. I don’t want an adversarial relationship with my development stack.
I miss C# and I really don’t like Python as a language, but I don’t see myself doing a lot more C# in the future if these trends continue.
Plus now Microsoft is being a bully when it comes to Cursor and the other VS Code forks, and won’t let the .net extensions work. I jumped through a lot of hoops but they keep finding ways to break it. I don’t want an adversarial relationship with my development stack.
I miss C# and I really don’t like Python as a language, but I don’t see myself doing a lot more C# in the future if these trends continue.
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.
Have you given C# a new try with Cursor and newer models?
There's a huge difference from Copilot in 2023, if that was your example.
Also, interesting you feel more productive on a language you don't even like than your "main" one.
There's a huge difference from Copilot in 2023, if that was your example.
Also, interesting you feel more productive on a language you don't even like than your "main" one.
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#/.NET has been capable of cross platform binaries for close to a decade?
I have a bit more info here: https://typescript-is-like-csharp.chrlschn.dev/pages/intro-a...
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#/.NET has been capable of cross platform binaries for close to a decade?
I have a bit more info here: https://typescript-is-like-csharp.chrlschn.dev/pages/intro-a...
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 have to actually use AOT, the other deployment options are actually much easier to cross-build, but true cross build AOT is still not supported.
(this comment is correct: https://news.ycombinator.com/item?id=43388962 ; runtime-dependent and self-contained are fine)
"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 have to actually use AOT, the other deployment options are actually much easier to cross-build, but true cross build AOT is still not supported.
(this comment is correct: https://news.ycombinator.com/item?id=43388962 ; runtime-dependent and self-contained are fine)
> Native AOT does not support cross-OS compilation
> ...runtime-dependent and self-contained are fine
Native AOT compilation is definitely not the same as self-contained package. With that logic, every Docker container could be considered AOT compiled static executable.
An image or a container could be, yes. It isn't, because Docker stuff is mostly distributed as Dockerfiles and docker-compose files, and those cause your system to download and install stuff, and that part is not like self-contained package.
More that there are at least three different ways to deploy things in dotnet, and only AOT is directly equivalent to Go executables. I like dotnet and use it at work but this is a nuisance limitation for us.
The original question did ask about creating executables like Go, which means a single file you can run as is, so it was fair to mention AOT. For servers etc you usually don't want the AOT version, so then it doesn't matter which platform you develop on, but it's not always just like Go when you want to ship little applications.
The context of the thread is HTTP/3 servers; would it not make sense to take the comment in that context? Original article mentions that browsers (the client side) already supports HTTP/3 with the application server ecosystem being the missing piece.
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.
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.
Hi, I own the Native AOT compiler and self-contained compiler for .NET.
Self-contained will work fine because we precompile the runtime and libraries for all supported platforms.
Native AOT won't, because we rely on the system linker and native libraries. This is the same situation as for C++ and Rust. Unlike Go, which doesn't use anything from the system, we try to support interop with system libraries directly, and in particular rely on the system crypto libraries by default.
Unfortunately, the consequence of relying on system libraries is that you actually have to have a copy of the system libraries to link against them, and a linker that supports that. In practice, clang is actually a fine cross-linker for all these platforms, but acquiring the system libraries is an issue. None of the major OSes provide libraries in a way that would be easy to acquire and deliver to clang, and we don't want to get into the business of building and redistributing the libcs for all platforms (and then be responsible for bugs etc).
Note that if you use cgo and call any C code from Go you will end up in the same situation even for Go -- because then you need a copy of the target system libc and a suitable system linker.
Self-contained will work fine because we precompile the runtime and libraries for all supported platforms.
Native AOT won't, because we rely on the system linker and native libraries. This is the same situation as for C++ and Rust. Unlike Go, which doesn't use anything from the system, we try to support interop with system libraries directly, and in particular rely on the system crypto libraries by default.
Unfortunately, the consequence of relying on system libraries is that you actually have to have a copy of the system libraries to link against them, and a linker that supports that. In practice, clang is actually a fine cross-linker for all these platforms, but acquiring the system libraries is an issue. None of the major OSes provide libraries in a way that would be easy to acquire and deliver to clang, and we don't want to get into the business of building and redistributing the libcs for all platforms (and then be responsible for bugs etc).
Note that if you use cgo and call any C code from Go you will end up in the same situation even for Go -- because then you need a copy of the target system libc and a suitable system linker.
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 of files which you can then then package up into a zip file.
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 of files which you can then then package up into a zip file.
How do you cross compile from linux to macos?
dotnet publish -r osx-x64 --self-contained
Just like for windows or Linux, in other words. The dotnet tooling is amazingly friction and ceremony free these days.
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.
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.
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.
If you’re calling against shared libraries using cgo then things are a little more tricky, but still doable.
But if it’s native Go code, then cross platform compiling is just an a few environmental variables
But if it’s native Go code, then cross platform compiling is just an a few environmental variables
GOOS=darwin
GOARCH=arm64Mono's been on Linux for like 20 years, maybe longer... C# is like Java, can run basically anywhere.
I think being on linux and being decent on linux are not the same, and there's .net problem.
Can you link to anything recent which could support your argument?
https://learn.microsoft.com/en-us/dotnet/api/system.diagnost...
Look at this garbage API that for no reason whatsoever mirrors winapi on posix for example.
Then after you painfully wrote your linux application despite all of that, you find out that .net is not included by any linux distribution, so have fun distributing your app!
Look at this garbage API that for no reason whatsoever mirrors winapi on posix for example.
Then after you painfully wrote your linux application despite all of that, you find out that .net is not included by any linux distribution, so have fun distributing your app!
I'm not sure why you are reading the docs sideways but just in case - C# has method overloading. Process API, while dated, simply offers multiple overloads suitable for different scenarios.
Launching a new process can be as easy as `Process.Start(path, args)`.
Although if you are doing this, I can recommend using CliWrap package instead which provides nicer UX. Anything is possible the second you stop looking for a strawman.
> you find out that .net is not included by any linux distribution
Would I? If it's a CLI or a GUI application, I'd distribute it as either a native binary or as the recipe the user will be easily able to build with the .NET SDK (which is a standard approach - you'd need Rustc and Cargo in the same way).
Lastly - no one wants to put up with the maintainers with such attitude and you know well enough that "not included in any linux distribution" is both provably false and a non-factor - in all the distributions that matter it is `sudo {package manager} install dotnet9` away :)
Launching a new process can be as easy as `Process.Start(path, args)`.
Although if you are doing this, I can recommend using CliWrap package instead which provides nicer UX. Anything is possible the second you stop looking for a strawman.
> you find out that .net is not included by any linux distribution
Would I? If it's a CLI or a GUI application, I'd distribute it as either a native binary or as the recipe the user will be easily able to build with the .NET SDK (which is a standard approach - you'd need Rustc and Cargo in the same way).
Lastly - no one wants to put up with the maintainers with such attitude and you know well enough that "not included in any linux distribution" is both provably false and a non-factor - in all the distributions that matter it is `sudo {package manager} install dotnet9` away :)
> Took you long enough.
Yeah I do have a life. I advice you to get one as well.
> Launching a new process can be as easy as `Process.Start(path, args);`.
-_-' Same exact problem. Letting every single process do their own escaping of the arguments. A proper portable API would have an array of strings for the arguments, to map execve(). That's how on windows every program does its own escaping and there's lots of programs doing it differently than others, but not how it works on posix.
Thanks for confirming you don't even comprehend the issue here. Crying "strawman!" won't help.
> If it's a CLI or a GUI application, I'd distribute it as either a native binary or as the recipe the user will be easily able to build with the .NET SDK (which is a standard approach - you'd need Rustc and Cargo in the same way).
You can't do any GUI in .NET outside of windows and you know it fully well.
The difference with cargo or go or pip is that all of these are found in every linux distribution, while .net is in none. Please go ahead and misunderstand this sentence on purpose like you've been doing so far.
> in all the distributions that matter it is `sudo {package manager} install dotnet9` away :)
I guess ubuntu, debian, red hat do not matter? What's left? neonsunsetimaginarylinux?
Yeah I do have a life. I advice you to get one as well.
> Launching a new process can be as easy as `Process.Start(path, args);`.
-_-' Same exact problem. Letting every single process do their own escaping of the arguments. A proper portable API would have an array of strings for the arguments, to map execve(). That's how on windows every program does its own escaping and there's lots of programs doing it differently than others, but not how it works on posix.
Thanks for confirming you don't even comprehend the issue here. Crying "strawman!" won't help.
> If it's a CLI or a GUI application, I'd distribute it as either a native binary or as the recipe the user will be easily able to build with the .NET SDK (which is a standard approach - you'd need Rustc and Cargo in the same way).
You can't do any GUI in .NET outside of windows and you know it fully well.
The difference with cargo or go or pip is that all of these are found in every linux distribution, while .net is in none. Please go ahead and misunderstand this sentence on purpose like you've been doing so far.
> in all the distributions that matter it is `sudo {package manager} install dotnet9` away :)
I guess ubuntu, debian, red hat do not matter? What's left? neonsunsetimaginarylinux?
Look, it is very difficult to hold a conversation with someone who responds with "you're just a fanboy, it's 5!" to "2 + 2 equals 4".
On the off chance you are making an intentionally inflammatory reply - you could also ask normally.
Let me try one last time (and now I vaguely remember having similar conversation here before).
On Ubuntu:
The build folder will contain the native application itself and the Skia dynamically linked dependency alongside it (and possibly some symbols you can delete). This is very similar to the way Qt applications are shipped.
This is just one GUI framework. There are other: Uno Platform, Gir.Core (GTK4 + GObject libraries), SDL2 via Silk.NET, Eto. I'm sure there's more.
What is bewildering is you could argue about "first-class" or "subpar", etc. But "does not work at all" is just ridiculous and indefensible. What kind of thought process leads to this conclusion?
In any case, I doubt you're going to read this since your replies seem to indicate interest in tilting at any windmill with ".NET" label on it instead, but at least my conscience is clear that I tried to explain this to the best of my ability.
On the off chance you are making an intentionally inflammatory reply - you could also ask normally.
Let me try one last time (and now I vaguely remember having similar conversation here before).
On Ubuntu:
sudo apt install dotnet9
sudo dnf install dotnet-sdk-9.0
sudo apk add dotnet9-sdk
dotnet new install Avalonia.Templates && \
dotnet new avalonia.app -o AvaloniaExample && \
cd AvaloniaExample && \
dotnet publish -o build -p:PublishAot=true && \
./build/AvaloniaExample
The build folder will contain the native application itself and the Skia dynamically linked dependency alongside it (and possibly some symbols you can delete). This is very similar to the way Qt applications are shipped.
This is just one GUI framework. There are other: Uno Platform, Gir.Core (GTK4 + GObject libraries), SDL2 via Silk.NET, Eto. I'm sure there's more.
What is bewildering is you could argue about "first-class" or "subpar", etc. But "does not work at all" is just ridiculous and indefensible. What kind of thought process leads to this conclusion?
In any case, I doubt you're going to read this since your replies seem to indicate interest in tilting at any windmill with ".NET" label on it instead, but at least my conscience is clear that I tried to explain this to the best of my ability.
All these words and you lost the original part where the APIs are windows oriented?
Man.. All of these words did proof you were wrong.
> The difference with cargo or go or pip is that all of these are found in every linux distribution, while .net is in none.
This statement is false. It is also in arch. If it is not in debian and ubuntu, that is their fault. (But it would not surprise me, any user will soon run into the fact that even for non-obscure software there are no up-to-date packages in the main repo. The default escape hatch is to add extra repo sources, but my advice is to skip those distro's altogether anyways, unless you have very specific needs.)
But then again, if you think package management is a serious topic and then dismiss .net for the python mess, come on.
> the APIs are windows oriented?
The design of this particular API might be off. I guess this dates from the pivot to cross-platform. Usually, tuning for .net performance is better on Linux. I think nobody in MS believes in Windows as a platform really, it is a sinking ship.
> The difference with cargo or go or pip is that all of these are found in every linux distribution, while .net is in none.
This statement is false. It is also in arch. If it is not in debian and ubuntu, that is their fault. (But it would not surprise me, any user will soon run into the fact that even for non-obscure software there are no up-to-date packages in the main repo. The default escape hatch is to add extra repo sources, but my advice is to skip those distro's altogether anyways, unless you have very specific needs.)
But then again, if you think package management is a serious topic and then dismiss .net for the python mess, come on.
> the APIs are windows oriented?
The design of this particular API might be off. I guess this dates from the pivot to cross-platform. Usually, tuning for .net performance is better on Linux. I think nobody in MS believes in Windows as a platform really, it is a sinking ship.
It's not Windows only but it is Windows-first. Every few years I take a look but it still doesn't feel like a serious ecosystem for Linux development (in the same way that e.g. Perl might have a Windows release, but it doesn't feel really first-class). I can't think of a single .NET/C# program that people would typically run on Linux to even have the runtime installed, so no wonder people don't bother investigating the languages.
Definitely not Windows-first.
Last startup we built our entire backend in .NET and C#. Every dev ended up using MacBooks. We shipped to AWS t4g Arm64 Linux targets.
This mis-perception is so irrational and not based on any facts.
Last startup we built our entire backend in .NET and C#. Every dev ended up using MacBooks. We shipped to AWS t4g Arm64 Linux targets.
This mis-perception is so irrational and not based on any facts.
Just because .NET is what you know best, doesn't necessarily mean it's the best in all use cases.
You're seeming like the node developers trying to push js everywhere because it's all they know. It's not a very rational approach I think.
You're seeming like the node developers trying to push js everywhere because it's all they know. It's not a very rational approach I think.
I don't think I've ever said it was good for all use cases and probably said to the contrary.
I write it very explicitly here[0]:
Most of my side projects are TS/JS and run serverless Node.js functions on the BE[1]. I don't choose favorites; I choose the right one for the job.
[0] https://typescript-is-like-csharp.chrlschn.dev/pages/intro-a...
[1] https://github.com/CharlieDigital/coderev
I write it very explicitly here[0]:
> Should you use C# for web front-ends?
>
> We're only considering backends here; I do not think that .NET-based front-ends (e.g. Blazor) are competitive in all use cases.
Most of my side projects are TS/JS and run serverless Node.js functions on the BE[1]. I don't choose favorites; I choose the right one for the job.
[0] https://typescript-is-like-csharp.chrlschn.dev/pages/intro-a...
[1] https://github.com/CharlieDigital/coderev
node is the wrong tool for any job.
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.
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.
[deleted]
It's very productive and kinda nice.
Especially for big backend APIs: https://typescript-is-like-csharp.chrlschn.dev/
Especially for big backend APIs: https://typescript-is-like-csharp.chrlschn.dev/
LINQ alone is unmatched.
Addendum: having `Expression`[0] type representing the expression tree is a really killer feature.
I've been doing a writeup comparing how ORMs work in TypeScript vs ORMs in .NET and one thing that is magical is that having the `Expression` type enables a much more functional and fluent experience with ORMs.
[0] https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...
I've been doing a writeup comparing how ORMs work in TypeScript vs ORMs in .NET and one thing that is magical is that having the `Expression` type enables a much more functional and fluent experience with ORMs.
[0] https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...
LINQ in EntityFramework certainly isn't perfect, but frankly it's so far ahead of anything else available in all other languages. It was a brilliant idea to add expressions type into the language AND to create a standard set of interfaces that enable collection interop AND to to then create universal clients for local and remote collections that use all this machinery to deliver first class DX.
"All other languages" is a stretch IMO. Any language that has proper macros (e.g. Rust, Clojure) can do something LINQ-like as well as C#.
Can you post some examples?
Having been working in TS with Prisma for a bit, what stands out is how a Prisma query is effectively trying to express an expression tree in structural form
An example on TS with Prisma:
And the same in C# with EF and LINQ:
Having been working in TS with Prisma for a bit, what stands out is how a Prisma query is effectively trying to express an expression tree in structural form
An example on TS with Prisma:
const loadedAda2 = await tx.runner.findFirst({
where: { email: '[email protected]' },
include: {
races: {
where: {
AND: [
{ position: { lte: 10 } },
{ time: { lte: 120 } },
{
race: {
name: { contains: 'New' }
}
}
]
}
}
}
})
And the same in C# with EF and LINQ:
var loadedAda = await db.Runners
.Include(r => r.RaceResults.Where(
finish => finish.Position <= 10
&& finish.Time <= TimeSpan.FromHours(2)
&& finish.Race.Name.Contains("New")
)
)
.FirstAsync(r => r.Email == "[email protected]");
TS does not have macro facilities.
Proper macros operate on AST, which it to say, it is exactly like the Expression stuff in C#, except it can represent the entirety of the language instead of some subset of it (C# doesn't even fully support the entirety of System.Linq.Expressions - e.g. if you want LoopExpression, you have to spell the tree out explicitly itself).
Proper macros operate on AST, which it to say, it is exactly like the Expression stuff in C#, except it can represent the entirety of the language instead of some subset of it (C# doesn't even fully support the entirety of System.Linq.Expressions - e.g. if you want LoopExpression, you have to spell the tree out explicitly itself).
> TS does not have macro facilities
For details, take a look at the examples here: https://doc.rust-lang.org/book/ch20-06-macros.html
For procedural macros, what you get is not even the syntax tree but rather the token tree: https://doc.rust-lang.org/proc_macro/struct.TokenStream.html. You can then use stdlib to parse that into a Rust syntax tree (which is roughly the equivalent of Expression): https://docs.rs/syn/latest/syn/enum.Expr.html
Or you can do your own parsing, meaning that you can handle pretty much any syntax that can be lexed as Rust tokens. Which means that e.g. the C# LINQ syntactic sugar (from ... select ... where etc) can also be implemented as a macro. Or you could handle raw SQL and do typechecking on it.
For procedural macros, what you get is not even the syntax tree but rather the token tree: https://doc.rust-lang.org/proc_macro/struct.TokenStream.html. You can then use stdlib to parse that into a Rust syntax tree (which is roughly the equivalent of Expression): https://docs.rs/syn/latest/syn/enum.Expr.html
Or you can do your own parsing, meaning that you can handle pretty much any syntax that can be lexed as Rust tokens. Which means that e.g. the C# LINQ syntactic sugar (from ... select ... where etc) can also be implemented as a macro. Or you could handle raw SQL and do typechecking on it.
It wasn't good enough for the typescript rewrite...
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.
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.
TSC codebase is quite unlike regular TypeScript code you will see out there. So it is about specific way TSC is written in being the easiest to port to Go rather than the TS language as a whole.
There's a screenshot comparing the two side-by-side, IIRC it was showcased on the video of the talk (if someone has a timestamp - please post).
There's a screenshot comparing the two side-by-side, IIRC it was showcased on the video of the talk (if someone has a timestamp - please post).
Got it; thanks for the tip!
The TL;DR version is that they don't really use classes and inheritance (which is the part that would be hard to map to Go but easy to map to C#). It's all functions dealing with struct-like objects.
The other part of it is that C# is very firmly in the nominal typing camp, while TS is entirely structurally typed. Go can do both.
The other part of it is that C# is very firmly in the nominal typing camp, while TS is entirely structurally typed. Go can do both.
Indeed. And I would think you can use Microsoft's free reverse proxy, YARP, in front of an app (on any platform) that doesn't natively support HTTP/3?
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/s...
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/s...
> 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 omission notwithstanding, one of the languages in the list is not like the others: Rust has a deliberately minimal standard library and doesn't include HTTP at all. I don't follow Rust HTTP/3 efforts closely, but there are at least two actively developed libraries: quiche and quinn.
.NET omission notwithstanding, one of the languages in the list is not like the others: Rust has a deliberately minimal standard library and doesn't include HTTP at all. I don't follow Rust HTTP/3 efforts closely, but there are at least two actively developed libraries: quiche and quinn.
The official Python stance on using the standard library HTTP client is also "are you sure?" and their stance on using the standard library HTTP server is "don't".
https://docs.python.org/3/library/http.client.html#module-ht...
https://docs.python.org/3/library/http.server.html#module-ht...
https://docs.python.org/3/library/http.client.html#module-ht...
https://docs.python.org/3/library/http.server.html#module-ht...
> sad that .NET and C# are not considered "major"...
I just checked the Java class HttpClient (a common JDK11+ HTTP client). It currently does not support HTTP/3, so add one more to the list!
Ref: https://docs.oracle.com/en/java/javase/24/docs/api/java.net....
Also, most of the very best network clients are now built on top of NettyIO. I can see an "incubator codec" here: https://github.com/netty/netty-incubator-codec-http3
Holy hell, this code is ridiculously complex: https://github.com/netty/netty-incubator-codec-http3/tree/ma...
I'm not hating on NettyIO here, but the protocol looks complex. Yet another reason why it is so slow to be deployed to more application frameworks.
I don't think many people use the builtin HttpClient these days. Apache httpclient would be the conservative standard, apparentyl it has some support for 2 but not 3: https://hc.apache.org/httpcomponents-client-5.4.x/index.html .
There is a very simple reason for not being on the list: It support HTTP/3 and the purpose of the post was to show the lack of support in common languages. .NET does not fit that list well.
And it is obviously only popular in the dark matter of Enterprise Software Development.
And it is obviously only popular in the dark matter of Enterprise Software Development.
C# is much closer in popularity to TypeScript/Python (the number 1s) than it is to Rust.
In usage yes, in analysis yes but not in general popularity.
And to Rust ... definitely. Rust is a niche product for system development. A very good one. A very popular one. But nothing you need for your day to day microservice.
And to Rust ... definitely. Rust is a niche product for system development. A very good one. A very popular one. But nothing you need for your day to day microservice.
> And it is obviously only popular in the dark matter of Enterprise Software Development.
Kind of misleading - Rust stdlib doesn't include HTTP 1 or 2 either
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.
But apparently there aren't enough people willing to actually do the work.
> 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.
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.
> So I think it is safe to say C# is indeed a minor language
You get the same result from scraping job postings: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...
1. JS/TS (note these two are collapsed)
2. Python
3. Java
4. C#
> See the new TypeScript compiler that is being rewritten in Go
C# is good for many things -- in particular application backends, game engines (both Godot and Unity) -- and not optimal for other things -- like serverless functions. Each language has a place and Go and Python are certainly better for CLI tools, for example.
[0] https://survey.stackoverflow.co/2024/technology
> StackOverflow survey[0] shows C# (27.1%) right behind Java (30.3%)
Can we rule out sample bias here? After all, Jon Skeet [0] is an important part of the Stack Overflow's C# community.
It might just be the case that C# and Java developers use Stack Overflow more than users of other languages.
[0] https://toggl.com/blog/save-princess-8-programming-languages
Can we rule out sample bias here? After all, Jon Skeet [0] is an important part of the Stack Overflow's C# community.
It might just be the case that C# and Java developers use Stack Overflow more than users of other languages.
[0] https://toggl.com/blog/save-princess-8-programming-languages
You get the same result from scraping job postings: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...
I'd say it's consistent and reliable?
It's not like people use StackOverflow because it's written in C#; people use StackOverflow because Google points us there.
1. JS/TS (note these two are collapsed)
2. Python
3. Java
4. C#
I'd say it's consistent and reliable?
It's not like people use StackOverflow because it's written in C#; people use StackOverflow because Google points us there.
But because they had an existing body of code that was not class based, it would be more of a re-write (C#) versus a refactor (Go).
I don't understand this reasoning at all, and I'm hoping you can shed some light on it.
As far as I know, C# supports static methods. Thus, using OO in C# would not have been required, would it?
I feel like I'm missing something here.
I don't understand this reasoning at all, and I'm hoping you can shed some light on it.
As far as I know, C# supports static methods. Thus, using OO in C# would not have been required, would it?
I feel like I'm missing something here.
C# supports top-level functions as well, that's not the issue. But, just to give a simple example, in TS you can do things like:
var foo: { bar: { baz: string } }
var foo struct { bar struct { baz string } }
The interesting thing is that you can do this in C# with tuples because tuples can nest tuples.
type Platform = "Mastodon" | "Bluesky" | "Threads";
type Profile = {
name: string,
socials: {
handle: string,
platform: Platform
}[]
}
function getProfiles() : Profile[] {
return [{
name: "Charles",
socials: [
{ handle: "@chrlschn", platform: "Mastodon" },
{ handle: "@chrlschn", platform: "Bluesky" }
]
},
{
name: "Sandra",
socials: [
{ handle: "@sndrchn", platform: "Threads" }
]
}]
}
using Profile = (
string Name,
(
string Handle,
Platform Platform
)[] Socials // Array of tuples in another tuple
);
enum Platform { Mastodon, Bluesky, Threads }
Profile[] GetProfiles() => new[] {
("Charles", new[] {
("@chrlschn", Platform.Mastodon),
("@chrlschn", Platform.Bluesky),
}),
("Sandra", new[] {
("@sndrchn", Platform.Threads)
}),
};
I would love if in mapping the typescript types to go they ended up building a "compiler plugin" to enhance go's type system.
TypeGo by Microsoft (TM).
Considering how fast the TypeScript compiler is, the TypeGo -> Go transpilation might as well be similar (up to a constant factor) in speed to Go compilation itself.
I'd give it a try. As a highly enthusiastic Go programmer, a powerful TypeScript-like type system is something I'd welcome in Go with open arms.
Considering how fast the TypeScript compiler is, the TypeGo -> Go transpilation might as well be similar (up to a constant factor) in speed to Go compilation itself.
I'd give it a try. As a highly enthusiastic Go programmer, a powerful TypeScript-like type system is something I'd welcome in Go with open arms.
That wouldn't feel very idiomatic - you can do it but would feel wrong
I’ve never filled out a stack overflow survey. I wouldn’t say Stack Overflow is statistically representative what’s being used — it’s statistically representative of people that use Stack Overlow. 10 years ago SO was my go-to. Now, I barely notice it — it seems very outdated in many respects.
I never understood SO as a measurement tool for anything, but people that can't read docs.
You have to have some metrics from somewhere to be able to understand which languages are being used.
SO is one data point, but there are certainly others.
SO is one data point, but there are certainly others.
GitHub is probably a better source. SO is self selecting for people asking questions about something, not actually using it. A “harder” thing might have more SO questions, so it isn’t representative of actual usage.
I posted above, but you can also see:
You get the same result from scraping job postings: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...
You get the same result from scraping job postings: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...
1. JS/TS (note these two are collapsed)
2. Python
3. Java
4. C#
It tells me which languages have people asking questions about them. That metric is useful only if it's normalized around how many people are using that language, but we don't have that metric.
The interviews with the Typescript dev doing the rewrite will tell you why. Switching their compiler to Go was a quick transition since Go matched their current JS build. The dev also wanted to use go, and use functional programming. It would have required more work to switch from functional to OOP style that C# has. Dev also didn't want to learn F#. Nothing about C#, just a personal decision with the least amount of work to get to a beta.
FWIW the "functional programming" angle here is misconstrued - C# has better facilities for it than Go.
The thing that they actually wanted is data-centric programming with structural types.
The thing that they actually wanted is data-centric programming with structural types.
It's pretty true from recent experience. I've recently started rewriting a C# based desktop/window stream tool because of how weak the support is across the board for C#. Microsoft abandoned WinRTC, Sipsorcery is one guy and is missing VP9 HEVC and AV1 support. And for fancier stuff like using computer shaders for color space conversion, SharpDX is constantly referenced by chatgpt and MS docs, yet it's archived and unmaintained as well. I ended up using media streams VideoFrame class but it and two other classes required to interact with it have unpreventable thread and memory leaks built into the WinRT implementations themselves 4+ years ago. Good times.
All of the above was easy to implement in Rust
All of the above was easy to implement in Rust
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.
Microsoft themselves ship on a variety of platforms.
It's more about right tool for the right job.
Good example is Azure CLI; it's Python. Microsoft is also a big contributor in the Python scene[0]
I don't think it's surprising at all that they didn't use C# to write a compiler for TS.
They have internal champions for Rust[1]
I'd say Microsoft is possibly one of the most diverse shops when it comes to tech selection.
[0] https://devblogs.microsoft.com/python/supporting-the-python-...
[1] https://www.theregister.com/2022/09/20/rust_microsoft_c/
It's more about right tool for the right job.
Good example is Azure CLI; it's Python. Microsoft is also a big contributor in the Python scene[0]
I don't think it's surprising at all that they didn't use C# to write a compiler for TS.
They have internal champions for Rust[1]
I'd say Microsoft is possibly one of the most diverse shops when it comes to tech selection.
[0] https://devblogs.microsoft.com/python/supporting-the-python-...
[1] https://www.theregister.com/2022/09/20/rust_microsoft_c/
TypeScript guys have a FAQ and even a video explaining why they chose Go exactly, and why not C# (or Rust, or other things). They had their reasons.
Go folks are going to be holding up this Typescript decision for years, aren't they...
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.
Additionally, I'd posit that for most client applications, a few extra ms of latency on a request isn't really a big deal. Sure, I can imagine applications that might care, but I can't think of any applications I have (as a developer or as a user) where I'd trade to have more complexity on the networking layer for potentially saving a few ms per request, or more likely just on the first request.
Additionally, I'd posit that for most client applications, a few extra ms of latency on a request isn't really a big deal. Sure, I can imagine applications that might care, but I can't think of any applications I have (as a developer or as a user) where I'd trade to have more complexity on the networking layer for potentially saving a few ms per request, or more likely just on the first request.
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.
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.
> A "few extra ms" is up to 3 roundtrips difference, that's easily noticeable by humans on cellular.
That's a valid concern. That's the baseline already though, so everyone is already living with that without much in the way of a concern. It's a nice-to-have.
The problem OP presents is what are the tradeoffs for that nice-to-have. Is security holes an acceptable tradeoff?
That's a valid concern. That's the baseline already though, so everyone is already living with that without much in the way of a concern. It's a nice-to-have.
The problem OP presents is what are the tradeoffs for that nice-to-have. Is security holes an acceptable tradeoff?
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.
That's a software architecture problem, not a transport layer problem.
Making the transport layer faster makes some architectures more performant. If you can simply swap out the transport layer that's a way easier optimization than rearchitecting an app that is correct but slow.
The problem with that is unlikely to be making HTTP connections. HTTP/1.1 already allows connections to be re-used.
But it doesn’t allow you to multiplex that connection (HTTP pipelining is broken and usually disabled). So depending on the app setup you could be losing quite a bit waiting on an API call while you could be loading a CSS file.
Your static and dynamic assets should be served from different domains anyway, to reduce the overhead of authentication headers / improve cache coherency. https://sstatic.net/ quotes a good explanation, apparently mirrored https://checkmyws.github.io/yslow-rules/. (The original Yahoo Best Practices for Speeding Up Your Web Site article has been taken down.)
Why does saving on cookies outweigh having to go through an additional TCP slow start?
Consider HTTP semantics. If there are cookies in the request, and those cookies change, it has to be re-requested every time. If there are no cookies, the request can remain semantically compatible, so the browser's internal caching proxy can just return the cached version.
There are other advantages: the article elaborates.
There are other advantages: the article elaborates.
Per the official HTTP semantics[1,2], what you say is not true: the only header that’s (effectively) always part of Vary is Authorization, the rest are at the origin server’s discretion; so don’t set Vary: Cookie on responses corresponding to static assets and you’re golden. The article only says that some (all?) browsers will disregard this and count Cookie there as well.
Even still, the question is, what’s worse: a cacheable request that has to go through DNS and a slow-start stage because it’s to an unrelated domain, or a potentially(?) noncacheable one that can reuse the existing connection? On a fast Internet connection, the answer is nonobvious to me.
[1] https://www.rfc-editor.org/rfc/rfc9110.html#name-vary
[2] https://datatracker.ietf.org/doc/html/rfc6265#section-3
Even still, the question is, what’s worse: a cacheable request that has to go through DNS and a slow-start stage because it’s to an unrelated domain, or a potentially(?) noncacheable one that can reuse the existing connection? On a fast Internet connection, the answer is nonobvious to me.
[1] https://www.rfc-editor.org/rfc/rfc9110.html#name-vary
[2] https://datatracker.ietf.org/doc/html/rfc6265#section-3
Oh, would that anyone heeded the official HTTP semantics. (Web browsers barely let you make requests other than GET and POST! It's ridiculous.)
On a fast internet connection, the answer doesn't matter because the internet connection is fast. On a slow internet connection, cacheable requests are better.
On a fast internet connection, the answer doesn't matter because the internet connection is fast. On a slow internet connection, cacheable requests are better.
Is HTTP the issue here though? Most of the time it seems to be more to do with the server taking ages to respond to queries. E.g. Facebook is equally poor on mobile as it is on my fibre-connected desktop (which I assume is using HTTP/3 as well) so I have my doubts that swapping HTTP versions will make a difference on mobile.
I did find it amusing how the author of the linked article says the megacorps are obsessed with improving performance (including the use of HTTP/3 to apparently help improve performance). In my experience the worst performing apps are those from the megacorps! I use Microsoft apps regularly at work and the performance is woeful even on a fibre connection using a HTTP/3 capable browser and/or their very own apps on their very own OS.
I did find it amusing how the author of the linked article says the megacorps are obsessed with improving performance (including the use of HTTP/3 to apparently help improve performance). In my experience the worst performing apps are those from the megacorps! I use Microsoft apps regularly at work and the performance is woeful even on a fibre connection using a HTTP/3 capable browser and/or their very own apps on their very own OS.
So with HTTP/3 it’s just 9.9 sec
Most people still use Google, and so they're living the fast HTTP 3 life, switching off that to a slower protocol only when interacting with non-Google/Amazon/MSFT properties. If your product is a competitor, but slower/inaccessible users are going to bounce off your product and not even be able to tell you why.
MSFT provides some of the slowest experiences I've had e.g. SharePoint, Teams, etc. Am laughing at the assumption that non-MSFT/etc properties are seen as slower when it is i fact MSFT that are the slowpokes. I haven't used Google much lately but they can be pretty poor too.
AWS are pretty good though. However it is notable I get good speeds and latency using S3 over HTTP/1.1 for backing up several hundreds gigs of data, so not sure if HTTP/3 makes any difference if it is already good enough without.
AWS are pretty good though. However it is notable I get good speeds and latency using S3 over HTTP/1.1 for backing up several hundreds gigs of data, so not sure if HTTP/3 makes any difference if it is already good enough without.
Nonsense, most of the web is non Google, Amazon or MSFT. Much of the web apps already uses CDNs which will enable web3 and the browser will support it. Other parts like APIs will not benefit much it they hit the database/auth/etc. MSFT stuff is dead slow anyway, Amazon is out of date, Google is just ads (who uses their search anymore?)
> most of the web is non Google, Amazon or MSFT.
maybe you can point out where that's what I said
maybe you can point out where that's what I said
And then the web app eats all that saved ms with ease.
Does it really matter? The website is first going to download 5mb of js, then it's going to show 3 popups.
Isn't 5G supposed to solve the mobile latency issue?
The connection to your local tower can have a negligible latency. The connection all the way to the datacenter may take longer. Then, there is congestion sometimes, e.g. around large gatherings of people; it manifests as latency, too.
But from the tower onward it shouldn't be any different from fixed internet connections, except for the gatherings, I'll grant that one.
So then (modern) mobile shouldn't be all that special.
So then (modern) mobile shouldn't be all that special.
At a previous job I had to specifically accommodate the backend API design to slow, large-latency 3G links which much of our East Asian audience had at the time. South Korea is one thing, Malaysia, quite another.
Could you talk a little bit more about what changes you made on the back into accommodate that? That sounds interesting.
A lot of traffic still goes over 4G or even 3G in many countries. Most countries have only deployed 5G NSA (non-standalone) which means mobiles uses both 4G and 5G at the same time. Only a few networks in a few countries have deployed 5G SA (standalone) where mobiles use 5G only -- and even those few networks only deploy 5G SA in certain places e.g. selected CBDs. I live in the largest city in my country and I only get 4G still in my suburb and much of rest of my city is 5G NSA which means in most places phones stil use 4G for uplink and a mix of 4G and 5G for the downlink. Hence there is still a long way to go until most traffic (in both directions -- i.e. uplink AND downlink) is over 5G.
> Isn't 5G supposed to solve the mobile latency issue?
Kinda.
So 5g is faster, but its still wireless, and shared spectrum. This means that the more people that use it, or the further they are away, the speed and bandwidth per client is adjusted.
(I'm not sure of the coding scheme for 5G, so take this with caution) For mobiles that are further away, or have a higher noise floor, the symbol rate (ie the number of radiowave "bits" that are being sent) is reduced so that there is a high chance they will be understood at the other end (Shannon's law, or something) Like in wifi, as the signal gets weaker, the headline connection speed drops from 100mb+ to 11.
In wifi, that tends to degrade the whole AP's performance, in 5G I'm not sure.
Either way, a bad connection will give you dropped packets.
Kinda.
So 5g is faster, but its still wireless, and shared spectrum. This means that the more people that use it, or the further they are away, the speed and bandwidth per client is adjusted.
(I'm not sure of the coding scheme for 5G, so take this with caution) For mobiles that are further away, or have a higher noise floor, the symbol rate (ie the number of radiowave "bits" that are being sent) is reduced so that there is a high chance they will be understood at the other end (Shannon's law, or something) Like in wifi, as the signal gets weaker, the headline connection speed drops from 100mb+ to 11.
In wifi, that tends to degrade the whole AP's performance, in 5G I'm not sure.
Either way, a bad connection will give you dropped packets.
And yet, compared to the time you're waiting for that mast head jpeg to load, plus an even bigger "react app bundle", also completely irrelevant.
HTTP/3 makes a meaningful difference for machines that need to work with HTTP endpoints, which is what Google needed it for: it will save them (and any other web based system similar to theirs) tons of time and bandwidth, which at their scale directly translates to dollars saved. But it makes no overall difference to individual humans who are loading a web page or web app.
There's a good argument to be made about wasting round trips and HTTP/3 adoption fixing that, but it's not grounded in the human experience, because the human experience isn't going to notice it and go "...did something change? everything feels so much faster now".
HTTP/3 makes a meaningful difference for machines that need to work with HTTP endpoints, which is what Google needed it for: it will save them (and any other web based system similar to theirs) tons of time and bandwidth, which at their scale directly translates to dollars saved. But it makes no overall difference to individual humans who are loading a web page or web app.
There's a good argument to be made about wasting round trips and HTTP/3 adoption fixing that, but it's not grounded in the human experience, because the human experience isn't going to notice it and go "...did something change? everything feels so much faster now".
Deploying QUIC led to substantial p95 and p99 latency improvements when I did it (admittedly a long time ago) in some widely used mobile apps. At first we had to correct our analysis for connection success rate because so many previously failing connections now succeeded slowly.
It's a material benefit over networks with packet loss and/or high latency. An individual human trying to accomplish something in an elevator, parking garage, or crowded venue will care about a connection being faster with a greater likelihood of success.
It's a material benefit over networks with packet loss and/or high latency. An individual human trying to accomplish something in an elevator, parking garage, or crowded venue will care about a connection being faster with a greater likelihood of success.
Almost every optimization is irrelevant if we apply the same reasoning to everything. Add all savings together and it does make a difference to real people using the web in the real world.
Google operates at such a scale that tiny increases of performances allows them to support a team of engineers and saves money on the bottom line.
For example, Google hires 10 engineers, they deploy HTTP/3, it saves 0.5% cpu usage, Google saves a million dollars and covers the salary of the said 10 engineers.
For the vast majority of society, the savings don't matter. Perhaps even deploying it is a net-negative with a ROI of decades. Or, the incentives can be misaligned leading to exploitation of personal information. For example, see chrome manifest v3.
It's okay to question whether we need it.
For example, Google hires 10 engineers, they deploy HTTP/3, it saves 0.5% cpu usage, Google saves a million dollars and covers the salary of the said 10 engineers.
For the vast majority of society, the savings don't matter. Perhaps even deploying it is a net-negative with a ROI of decades. Or, the incentives can be misaligned leading to exploitation of personal information. For example, see chrome manifest v3.
It's okay to question whether we need it.
It absolutely matters. Machines are orders of magnitude faster than they were 20 years ago; most software isn't doing much more than software did 20 years ago. And no, collaborative editing isn't be-all, end-all, nor does it explain where all that performance is lost.
Many optimizations have bad ROI because users' lives are an externality for the industry. It's Good and Professional to save some people-weeks in development, at the cost of burning people-centuries of your users' life in aggregate. And like with pollution, you usually can't pin the problem on anyone, as it's just a sum of great many parties each doing tiny damage.
Many optimizations have bad ROI because users' lives are an externality for the industry. It's Good and Professional to save some people-weeks in development, at the cost of burning people-centuries of your users' life in aggregate. And like with pollution, you usually can't pin the problem on anyone, as it's just a sum of great many parties each doing tiny damage.
>most software isn't doing much more than software did 20 years ago
This isn't exactly true, but some of the potential reasons are pretty bad. Software turning into an ad platform or otherwise spying on users has made numerous corporations wealthier than the gods at the expense of the user is probably one of the most common ones.
This isn't exactly true, but some of the potential reasons are pretty bad. Software turning into an ad platform or otherwise spying on users has made numerous corporations wealthier than the gods at the expense of the user is probably one of the most common ones.
> Machines are orders of magnitude faster than they were 20 years ago; most software isn't doing much more than software did 20 years ago.
That seems like an absurd statement to the point I wonder if I’m missing something.
That seems like an absurd statement to the point I wonder if I’m missing something.
In my experience almost every optimization is irrelevant for that exact reasoning.
Nearly all of my real world performance issues have come from a very small set of functionality running extremely poorly.
Nearly all of my real world performance issues have come from a very small set of functionality running extremely poorly.
What a bizarre thing to say: not every optimization is imperceptable by humans (jpg, gzip, brotli, JS and CSS payload bundling and minification, etc. etc.) and not all sums of optimizations add up to "something significant in terms of human perception".
HTTP/3 is a good optimization, and you can't sell it based on "it improves things for humans" because it doesn't. It improves things for machines, and given that essentially all internet traffic these days is handled by large scale machine systems, that's a perfectly sufficient reason for adoption.
HTTP/3 is a good optimization, and you can't sell it based on "it improves things for humans" because it doesn't. It improves things for machines, and given that essentially all internet traffic these days is handled by large scale machine systems, that's a perfectly sufficient reason for adoption.
For a long time all my internet connections were bad (slow, unstable or both). Compressing HTML/CSS/JS, avoiding JS unless absolutely needed, being careful with image sizes and formats, etc, helped a lot... so I guess this makes me biased.
Today I have fibre at home, but mobile networks are still patchy. I'm talking sub 1Mbps and high ping/jitter sometimes. So you can see why I think an "irrelevant" optimisation that removes 300ms from a page reload, no compression vs brotli/zstd, jpg vs avif, etc, are important for me, a human.
It's important to keep in mind that many users out there don't have a fast and low latency connections, at least not all the time. What takes 300ms to complete on our fast machine and fast WiFi at the office might take 1s on someone else's device and connection. It's harder to understand this if we only use fast connections/hardware though.
Today I have fibre at home, but mobile networks are still patchy. I'm talking sub 1Mbps and high ping/jitter sometimes. So you can see why I think an "irrelevant" optimisation that removes 300ms from a page reload, no compression vs brotli/zstd, jpg vs avif, etc, are important for me, a human.
It's important to keep in mind that many users out there don't have a fast and low latency connections, at least not all the time. What takes 300ms to complete on our fast machine and fast WiFi at the office might take 1s on someone else's device and connection. It's harder to understand this if we only use fast connections/hardware though.
That was my point: 300ms sounds like a lot until, like me too, you're on a slow connection and those 300ms on the entire 10 second page load are utterly irrelevant. You were already expecting a several second load time, that 300ms is not something that even registers: the HTTP negotiation on a modern page is _not_ what you're noticing on a slow connection. You're noticing literally everything else taking forever instead.
3% speedup is still pretty good. (especially because with some of the awfulness, it's possible to get bottle-necked by multiple of these in which case it could be 6 or 9%)
omfg: YES! YES IT IS! But you won't notice it and so the argument that it improves the experience is nonsense because you as human WON'T NOTICE THOSE 3 OR EVEN 6%
It's good because it speeds up the overall response by a measurable degree, not because it makes the experience better. That only happens in conjunction with tons of other improvements, the big ones of which are completely unrelated to the protocol itself and are instead related to how the page is programmed.
How is everyone this bad are understanding that if someone claims A cannot be justified because of B, that does not mean that A cannot be justified. It's near-trivially justified in this case. This crowd really should know better.
It's good because it speeds up the overall response by a measurable degree, not because it makes the experience better. That only happens in conjunction with tons of other improvements, the big ones of which are completely unrelated to the protocol itself and are instead related to how the page is programmed.
How is everyone this bad are understanding that if someone claims A cannot be justified because of B, that does not mean that A cannot be justified. It's near-trivially justified in this case. This crowd really should know better.
> But it makes no overall difference to individual humans who are loading a web page or web app.
Navigating from my phone at 4g and my fiber connection has drastic differences.
Especially noticeable when on vacations or places with poor connections, TLS handshakes can take many, many, many, seconds..After the handshake and an established connection it's very different.
Navigating from my phone at 4g and my fiber connection has drastic differences.
Especially noticeable when on vacations or places with poor connections, TLS handshakes can take many, many, many, seconds..After the handshake and an established connection it's very different.
[deleted]
> I'd far rather have the OS provide a verified safe socket layer
There is work going on right now[1] to implement the QUIC protocol in the linux kernel, which gets used in userspace via standard socket() APIs like you would with TCP. Of course, who knows if it’ll ultimately get merged in.
[1] https://github.com/lxin/quic
There is work going on right now[1] to implement the QUIC protocol in the linux kernel, which gets used in userspace via standard socket() APIs like you would with TCP. Of course, who knows if it’ll ultimately get merged in.
[1] https://github.com/lxin/quic
Yea, but does the kernel then also do certificate validation for you? Will you pin certs via setsockopt? I think QUIC and TLS are wide enough attack surfaces to warrant isolation from the kernel.
> but does the kernel then also do certificate validation for you
No, the asymmetric cryptography is all done in userspace. Then, post-handshake, symmetric cryptography (e.g., AES) is done in-kernel. This is the same way it works with TCP if you’re using kTLS.
No, the asymmetric cryptography is all done in userspace. Then, post-handshake, symmetric cryptography (e.g., AES) is done in-kernel. This is the same way it works with TCP if you’re using kTLS.
The problem is that the situation where everyone rolls their own certificate stack is lunacy in this day and age. We need crypto everywhere, and it should be a lot easier to configure how you want: the kernel is a great place to surface the common interface for say "what certificates am I trusting today?"
The 10+ different ways you specify a custom CA is a problem I can't wait to see the back of.
The 10+ different ways you specify a custom CA is a problem I can't wait to see the back of.
It's a good thing for a OS to provide, that doesn't mean it needs to be in the kernel.
Putting cert parsing in (monolithic) kernels seems like a bad idea; cert parsing has a long history of security vulnerabilities, and you don't want that kind of mistake to crash your kernel, let alone lead to privilege escalation or a takeover of the kernel itself.
Regardless, your proposal suffers from the usual stuff about proliferating standards (https://xkcd.com/927/): a kernel interface will never get fully adopted by everyone, and then your "10+ ways" will become "11+ ways".
Meanwhile, all the major OSes have their own trust store, and yet some apps choose to do things in a different way. Putting this into the kernel isn't going to change that.
Regardless, your proposal suffers from the usual stuff about proliferating standards (https://xkcd.com/927/): a kernel interface will never get fully adopted by everyone, and then your "10+ ways" will become "11+ ways".
Meanwhile, all the major OSes have their own trust store, and yet some apps choose to do things in a different way. Putting this into the kernel isn't going to change that.
The kernel already does TLS, but the handshake happens in user-space.
It will not.
Experiencing the internet at 2000ms latency every month or so thanks to dead spots along train tracks, the latency improvements quickly become noticeable.
HTTP/3 is terrible for fast connections (with download speeds on gigabit fiber notably capped) and great for bad ones (where latency + three way handshakes make the web unusable).
Perhaps there should be some kind of addon/setting for the browser to detect the quality of the network (doesn't it already for some JS API?) and dynamically enable/disable HTTP/3 for the best performance. I can live with it off 99% of the time, but those rare times I'm dropped to 2G speeds, it's a night and day difference.
HTTP/3 is terrible for fast connections (with download speeds on gigabit fiber notably capped) and great for bad ones (where latency + three way handshakes make the web unusable).
Perhaps there should be some kind of addon/setting for the browser to detect the quality of the network (doesn't it already for some JS API?) and dynamically enable/disable HTTP/3 for the best performance. I can live with it off 99% of the time, but those rare times I'm dropped to 2G speeds, it's a night and day difference.
> 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.
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.
> a few extra ms of latency on a request
That's not what it is, though. The graph embedded in the article shows HTTP/3 delivering content 1.5x-2x faster than HTTP/2, with differences in the hundreds of ms.
Sure, that's not latency, but consider that HTTP/3 can do fewer round-trips. RTs are often what kill you.
Whether or not this is a good trade off for the negatives you mention is still arguable, but you seem to be unfairly minimizing HTTP/3's benefits.
That's not what it is, though. The graph embedded in the article shows HTTP/3 delivering content 1.5x-2x faster than HTTP/2, with differences in the hundreds of ms.
Sure, that's not latency, but consider that HTTP/3 can do fewer round-trips. RTs are often what kill you.
Whether or not this is a good trade off for the negatives you mention is still arguable, but you seem to be unfairly minimizing HTTP/3's benefits.
If the initial tcp 3 way handshake fails it can be quite a bit longer you would have to wait than a few ms. Depending on OS it is a second or more.
>saving a few ms per request, or more likely just on the first request.
That's not given, either as UDP is normally not prioritized under congestion.
That's not given, either as UDP is normally not prioritized under congestion.
But that will change, as more and more clients will rely on UDP on port 443.
It's also a poor congestion control practice to begin with. The main categories of UDP traffic are DNS, VoIP and VPNs. DNS is extremely latency sensitive -- the entirety of what happens next is waiting for the response -- so dropping DNS packets is a great way to make everything suck more than necessary. VoIP often uses some error correction and can tolerate some level of packet loss, but it's still a realtime protocol and purposely degrading it is likewise foolish.
And VPNs are carrying arbitrary traffic. You don't even know what it is. Assigning this anything less than "normal" priority is ridiculous.
In general middleboxes should stop trying to be smart. They will fail, will make things worse, and should embrace being as dumb and simple as possible. Don't try to identify traffic, just forward every packet you can and drop them at random when the pipe is full. The endpoints will figure it out.
And VPNs are carrying arbitrary traffic. You don't even know what it is. Assigning this anything less than "normal" priority is ridiculous.
In general middleboxes should stop trying to be smart. They will fail, will make things worse, and should embrace being as dumb and simple as possible. Don't try to identify traffic, just forward every packet you can and drop them at random when the pipe is full. The endpoints will figure it out.
Allegedly, some traffic is best split into multiple socket addresses to work around the smart middleboxes.
Connection migration sounds like a security nightmare
How is it any worse than session resumption from a different IP address?
the big one is multiplayer games. udp is preferred and trying to work with webrtc is awful
The slow adoption of QUIC is the result of OpenSSL's refusal to expose the primitives needed by QUIC implementations that already existed in the wild. Instead, they decided to build their own NIH QUIC stack, which after all these years is still not complete.
Fortunately, this recently changed and OpenSSL 3.5 will finally provide an API for third party QUIC stacks.[1] It works differently than all the other existing implementations, as it's push-based instead of pull-based. It remains to be seen what it means for the ecosystem.
[1] - https://github.com/openssl/openssl/pull/26683
Fortunately, this recently changed and OpenSSL 3.5 will finally provide an API for third party QUIC stacks.[1] It works differently than all the other existing implementations, as it's push-based instead of pull-based. It remains to be seen what it means for the ecosystem.
[1] - https://github.com/openssl/openssl/pull/26683
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 "plaintext HTTP 1.1 only" world, because those are the abstractions that browser APIs and application servers still maintain. All the crazy stuff in between - encryption, CDNs, changing network protocols - are just as abstracted away as the different hops of an IP packet and might just as well not exist from the application perspective.
As far as developers are concerned, we still live, have always lived and will always be living in a "plaintext HTTP 1.1 only" world, because those are the abstractions that browser APIs and application servers still maintain. All the crazy stuff in between - encryption, CDNs, changing network protocols - are just as abstracted away as the different hops of an IP packet and might just as well not exist from the application perspective.
> because those are the abstractions that browser APIs and application servers still maintain
Because semantics are the same for every version.
Because semantics are the same for every version.
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
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.
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.
It's pretty glaring that nginx still doesn't have production-ready HTTP3 support despite being a semi-commercial product backed by a multi billion dollar corporation. F5 is asleep at the wheel.
Out of curiosity have F5 added any new modules since they acquired Nginx?
https://nginx.org/en/CHANGES
acquisition finished in 2019
there are quite a lot of features, but it's hard to say what constitutes a new module. (well, there's "Feature: the ngx_stream_set_module." so maybe yes?)
acquisition finished in 2019
there are quite a lot of features, but it's hard to say what constitutes a new module. (well, there's "Feature: the ngx_stream_set_module." so maybe yes?)
One would probably have to go through git logs [1] so I guess I should do that after getting some food in the belly to answer my own question. It's a big log. Interesting side note, appears all commits from Maxim stopped in January 2024. Must be all F5 now.
[1] - https://github.com/nginx/nginx
[1] - https://github.com/nginx/nginx
Here's some background:
https://arstechnica.com/information-technology/2024/02/nginx...
https://arstechnica.com/information-technology/2024/02/nginx...
Ah yes, I vaguely recall the drama. Thankyou.
16 commits from F5 from 2020 to 2025, nothing before that. Looks like they are bugfixes and enhancements. Perhaps someone else created the ngx_stream_set_module module prior to the acquisition.
There's some cool stuff & capabilities here. Its surprising to me that uptake has been so slow.
Node.js just posted an update on the state of QUIC, which underlies http3 & has had some work over the years. They're struggling with openssl being slow to get adequate API support going. There's efforts that have working books for quic, but the prospect of switching is somewhat onerous.
Really unfortunate; so much of this work has been done for Node & there's just no straightforward path forwards.
https://github.com/nodejs/node/issues/57281
Node.js just posted an update on the state of QUIC, which underlies http3 & has had some work over the years. They're struggling with openssl being slow to get adequate API support going. There's efforts that have working books for quic, but the prospect of switching is somewhat onerous.
Really unfortunate; so much of this work has been done for Node & there's just no straightforward path forwards.
https://github.com/nodejs/node/issues/57281
I'd love to see that OpenSSL fork drama on the main page of HN. Do you know where this was discussed?
there's a pretty good summary of things with links from daniel stenberg - the curl guy - here : https://daniel.haxx.se/blog/2021/10/25/the-quic-api-openssl-...
I think the issue is the complexity? It pushes a lot of logic into userspace.
My observation is that anything based on public cloud providers using their load balancers is basically using HTTP3 out of the box. This benefits people that use browsers that support this (essentially all browser and mobile browsers). And since it falls back to plain HTTP 1.1, there are no downsides for others.
Sites that use their own apache/nginx/whatever servers are not benefiting from this and need to do work. And this is of course not helped by the fact that http3 support in many servers is indeed still lacking. Which at this point should be a strong hint to maybe start considering something more modern/up to date.
Http clients used for API calls between servers that maybe use pipelining and connection reuse, benefit less from using HTTP3. So, fixing http clients to support http3 is less urgent. Though there probably are some good reasons to support this anyway. Likewise there is little benefit in ensuring communication between microservices in e.g. Kubernetes happens over http3.
Sites that use their own apache/nginx/whatever servers are not benefiting from this and need to do work. And this is of course not helped by the fact that http3 support in many servers is indeed still lacking. Which at this point should be a strong hint to maybe start considering something more modern/up to date.
Http clients used for API calls between servers that maybe use pipelining and connection reuse, benefit less from using HTTP3. So, fixing http clients to support http3 is less urgent. Though there probably are some good reasons to support this anyway. Likewise there is little benefit in ensuring communication between microservices in e.g. Kubernetes happens over http3.
I’ve been using niquests with Python. It supports HTTP/3 and a bunch of other goodies. The Python ecosystem has been kind of stuck on the requests package due to inertia, but that library is basically dead now. I’d encourage Python developers to give niquests a try. You can use it as a drop-in replacement for requests then switch to the better async API when you need to.
https://niquests.readthedocs.io/en/latest/
Traditionally these types of things are developed outside the stdlib for Python. I’m not sure why they draw the line where they do between urllib vs niquests, but it does sometimes feel like the batteries-included nature of Python is a little neglected in some areas. A good HTTP library seems like it belongs in the stdlib.
https://niquests.readthedocs.io/en/latest/
Traditionally these types of things are developed outside the stdlib for Python. I’m not sure why they draw the line where they do between urllib vs niquests, but it does sometimes feel like the batteries-included nature of Python is a little neglected in some areas. A good HTTP library seems like it belongs in the stdlib.
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 there is a feature missing, feel free to raise a feature request, but please do be aware that the overwhelming likelihood is that your feature request will not be accepted.
— https://requests.readthedocs.io/en/latest/dev/contributing/#...
> 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 there is a feature missing, feel free to raise a feature request, but please do be aware that the overwhelming likelihood is that your feature request will not be accepted.
— https://requests.readthedocs.io/en/latest/dev/contributing/#...
It takes a very special case of a person to complain about a feature-complete piece of software not evolving fast enough.
But it's not feature complete if it can't make modern networking requests when the whole point of a library like requests is to make networking requests.
If you can get the content of a web page using requests, then it works just fine.
> whole point of a library like requests is to make networking requests.
The whole point of requests is to make HTTP requests easy. HTTPLib was/is an arse to use.
as HTTP3 is really not that widely adopted, and where it is, has fallbacks to 1.1 whats the point?
Plus the people who are keen on HTTP3 also seem to be keen on async, https://github.com/aiortc/aioquic/tree/main/examples which even though it isn't seems to be overly complex and difficult to use. Contrast that to r.get(url)....
The whole point of requests is to make HTTP requests easy. HTTPLib was/is an arse to use.
as HTTP3 is really not that widely adopted, and where it is, has fallbacks to 1.1 whats the point?
Plus the people who are keen on HTTP3 also seem to be keen on async, https://github.com/aiortc/aioquic/tree/main/examples which even though it isn't seems to be overly complex and difficult to use. Contrast that to r.get(url)....
It’s an HTTP library that doesn’t support async or HTTP/2, let alone HTTP/3. It isn’t feature complete.
Besides, I was responding to this:
> The reason given for not including it in the stdlib was so it could evolve more rapidly.
Pointing out that it isn’t evolving at all is a perfectly reasonable response to that.
Besides, I was responding to this:
> The reason given for not including it in the stdlib was so it could evolve more rapidly.
Pointing out that it isn’t evolving at all is a perfectly reasonable response to that.
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.
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.
Nginx (F5) and Go (Google) are hardly scrappy open source projects with limited resources. The former is semi-commercial, you can pay for Nginx and still not have stable HTTP3 support. Google was one of the main drivers of the HTTP3 spec and has supported it both in Chromium and on their own cloud for years, but for whatever reason they haven't put the same effort into Go's stdlib.
It's in progress: quic is in testing in http://pkg.go.dev/golang.org/x/net/quic
and http3 is being implemented https://github.com/golang/go/issues/70914
Since Go has strong backwards compatibility guarantees, they're unlikely to commit to APIs that may need to change in the standard library.
Since Go has strong backwards compatibility guarantees, they're unlikely to commit to APIs that may need to change in the standard library.
The backwards compatibility guarantees are for the language and not the standard library. They won't make breaking changes nilly willy but it can and has happened for the std.
I'd go with HAProxy over Nginx any day. It far more robust and more capable. They've had QUIC & HTTP/3 since 2022.
The comparison with IPv6 is interesting. IPv6 isn't mainly driven by open source or community. It is driven by the needs of large corporations, including both ISPs and tech companies. ISPs like T-mobile wanting to run an IPv6-only backbone network, and tech companies like Apple forcing every app in the App Store to work in IPv6-only mode (DNS64+NAT64). New operating system levels features for IPv6 are often proposed by big tech companies and then implemented eagerly by them; see for example DHCP option 108.
In a sense the need for IPv6 is driven by corporates just like that for HTTP/3.
In a sense the need for IPv6 is driven by corporates just like that for HTTP/3.
IPv6 always seemed to me to be driven by a certain class of purist networking geeks. Then some corporations started getting on board like you said, but many couldn't care less.
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 where near the quality, affordability, and reliability of their IPv4 stacks.
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 where near the quality, affordability, and reliability of their IPv4 stacks.
What do you mean? IPv6 PI is common and easy to get; there's no big difference between IPv4 and IPv6 there.
I've gone through dozens of applications for a PI block and all been turned down. Heard the same from most of the networking people I know of. One even had their company become a LIR just so they could lock down a block.
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.
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.
Huh, I have one for my personal home network :-) Granted, that is in RIPE. As long as you're multihomed, how can they turn it down?
Multihoming is broken for most people in IPv6 space. It's stupid easy in IPv4.
https://blog.ipspace.net/2010/12/small-site-multihoming-in-i...
https://blog.ipspace.net/2010/12/small-site-multihoming-in-i...
You lost me at “multiple per-interface NAT rules […] with some load balancing trick” being “stupid easy”…
But BGP+PI is indeed how multihoming is supposed to work, both in IPv4 and IPv6. (Well, in IPv6, you can put two prefixes on-link and do poor man's multihoming that way, which you cannot reliably in IPv4.) Of course, if you define “it cannot be BGP+PI”, then indeed it's probably harder, but if you exclude the intended solution, obviously there's no intended solution.
But BGP+PI is indeed how multihoming is supposed to work, both in IPv4 and IPv6. (Well, in IPv6, you can put two prefixes on-link and do poor man's multihoming that way, which you cannot reliably in IPv4.) Of course, if you define “it cannot be BGP+PI”, then indeed it's probably harder, but if you exclude the intended solution, obviously there's no intended solution.
Depends on the country. New Zealand has zero mobile IPv6 users -- not one carrier has deployed IPv6 on mobile (and none plan to do so anytime soon). This includes two carriers that have deployed IPv6 on their xDSL/Fibre networks so it's not like they don't know how. It's interesting that some countries (e.g. NZ) see IPv6 deployed mostly on fixed line (i.e. xDSL/Fibre) while others (e.g. US) are mostly mobile. Perhaps it's not the fixed/mobile layer of the network stack that influences the decision to go IPv6 or not.
The exhaustion of IPv4 address pool was easy to predict even in 2000, just by extrapolation of the growth curve.
Then came IP telephony backbone and the mobile internet, topped up with the cloud, and the need became acute. For the large corporations involved, at least.
Then came IP telephony backbone and the mobile internet, topped up with the cloud, and the need became acute. For the large corporations involved, at least.
Oh many purist networking geeks joined large corporations so that these corporations began to push IPv6 in a direction set by the geeks. They understood that as independent geeks they have essentially no say in the evolution of IPv6. My favorite example here is Android refusing to support stateful DHCPv6; it's clear that it's being pushed by purist networking geeks inside Google.
With IPv6 RAs, there's no need for DHCPv6. I don't use it at all and I use IPv6 just fine on mobile. One place where DHCPv6 may make some sense is the router<->WAN/ISP connection. However once your router has a IPv6 prefix, it can easily advertise it on your LAN/WLAN for devices to capture it via IPv6 RAs for its IPv6 autoconfiguration which Just Works. Given that Android devices will attach to a WLAN router (and not directly to your WAN/ISP) it makes sense for there to be no DHCPv6 as it's not necessary for end user devices that aren't expected to be attached directly to the WAN/ISP.
My home network doesn't use stateful DHCPv6 either. I agree there's no need.
The bigger thing is carrying this "you don't need it" attitude to a product used by billions. Thousands of network operators who do not believe in "you don't need it" are now forced to make their network work for Android. If those purists had guts they should go to the IETF and formally deprecate stateful DHCPv6.
The bigger thing is carrying this "you don't need it" attitude to a product used by billions. Thousands of network operators who do not believe in "you don't need it" are now forced to make their network work for Android. If those purists had guts they should go to the IETF and formally deprecate stateful DHCPv6.
> My favorite example here is Android refusing to support stateful DHCPv6; it's clear that it's being pushed by purist networking geeks inside Google.
If you read the huge bug on it, Google's counter argument is stateful dhcpv6 significantly complicates tethering to the point of needing an ipv6 nat. That's a very practical position to take, hardly "purist network objectionists"
If you read the huge bug on it, Google's counter argument is stateful dhcpv6 significantly complicates tethering to the point of needing an ipv6 nat. That's a very practical position to take, hardly "purist network objectionists"
So what? The Linux kernel already supports NAT66. Android uses the Linux kernel. I use Tailscale and when I use an IPv6-only node as the exit node, NAT66 is being used. Use `ip6tables -t nat -vnL` to check. You can also grep for `v6nat = true` in Tailscale logs.
It's those purists at Google that decide that NAT66 is evil and should not be used and therefore they have chosen not to support stateful DHCPv6.
It's those purists at Google that decide that NAT66 is evil and should not be used and therefore they have chosen not to support stateful DHCPv6.
NAT66 has significant drawbacks. It's a lot more than just Google that is against NAT66.
wanting p2p to work (without quixotic NAT hole-punching) is puristry?
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.
Yes, right now every large provider does that, which is great. That was not the case when the first p2p networks were growing big (Napster, Gnutella, that kind of thing).
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.
Unfortunately, some ISPs (including mine) limit this to /64 only, which is extremely limiting.
It already works. Sometimes the cure is worse than the disease.
Ummm… Google invented QUIC and pushed it into Chrome and shuttled it through IETF to be ratified as a standard. Some of the large OSS projects are maintained by large companies (eg quiche is by Cloudflare) and Microsoft has MsQuic which you can link against directly or just use the kernel mode version built into the OS directly since Windows 11. The need for QUIC is actually even more driven by corporates since IPv6 was a very small comparative pain point compared to better reaching customers with large latency network connections.
99% of the benefit of HTTP/3 is on distributed web serving where clients are connecting to multiple remote ends on a web page (which lets be honest, is mostly used for serving ads faster).
Why would the open source community prioritize this?
Why would the open source community prioritize this?
> see IPv6
"We'll get to IPv6 after we finish IPv5"
"We'll get to IPv6 after we finish IPv5"
> 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 bot.
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 bot.
I've been doing that on my hobby sites ever since all the popular browsers supported HTTP/2.0 [1]
[1] - https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#...
if ($server_protocol != HTTP/2.0) { return 444; }
[1] - https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#...
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
https://news.ycombinator.com/item?id=43329320
What exactly are sites supposed to do to prevent being the targets of DDoS, spam, fraud, aggressive bots, and other abuse? And it's not "locked down", it's usually just a CAPTCHA as long as you're not coming from an abusive IP range like might happen with a VPN.
Also there are a thousand other signals besides HTTP/3. It's not going to make a difference.
Also there are a thousand other signals besides HTTP/3. It's not going to make a difference.
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 its moral equivalent with unwarranted and untrustworthy dynamic content injected). Static file serving is very difficult to DDoS, even without a caching CDN like Fastly. There is still a potentially large bandwidth cost, but generally the DoS actor has to pay more than the victim website, making it relatively unappealing.
Should web sites really be weighing "a thousand signals" to decide which version of the truth to present a given user with? That sounds dystopian to me.
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 its moral equivalent with unwarranted and untrustworthy dynamic content injected). Static file serving is very difficult to DDoS, even without a caching CDN like Fastly. There is still a potentially large bandwidth cost, but generally the DoS actor has to pay more than the victim website, making it relatively unappealing.
Should web sites really be weighing "a thousand signals" to decide which version of the truth to present a given user with? That sounds dystopian to me.
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 and stores.
> generally the DoS actor has to pay more than the victim website
No, generally the DDoS actor pays very little, because they're using bots infecting other people's devices. The bandwidth is free because it's stolen.
> be weighing "a thousand signals" to decide which version of the truth
Nobody said anything about "truth". You're either blocked or you're not. Page content isn't changing.
Yes, spam and fraud and abuse prevention does require weighing a thousand signals. It always has. It sucks, but the world is an adversarial place, and the internet wasn't designed with that in mind.
> 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 and stores.
> generally the DoS actor has to pay more than the victim website
No, generally the DDoS actor pays very little, because they're using bots infecting other people's devices. The bandwidth is free because it's stolen.
> be weighing "a thousand signals" to decide which version of the truth
Nobody said anything about "truth". You're either blocked or you're not. Page content isn't changing.
Yes, spam and fraud and abuse prevention does require weighing a thousand signals. It always has. It sucks, but the world is an adversarial place, and the internet wasn't designed with that in mind.
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.
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.
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 my browser to block ads. You see that this is a bit silly, right?
---
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 my browser to block ads. You see that this is a bit silly, right?
I'm sorry, are you really questioning whether these threats exist? Or whether not using HTTP/3 is one potential signal of being a bot (out of many), since tools like cURL don't support HTTP/3?
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.
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.
I would like you to explain specifically and concretely why you need this, without using any broad abstract ideas like "bots" or "fraud".
For example: "We were receiving 1000 spam and 100 legitimate comments per day even though we used hCaptcha on the comment form. When we disabled HTTP 1.1 on the comment endpoint, the spam stopped entirely, and we still received 95 legitimate comments per day." (in this scenario, I don't think it's necessary to further elaborate what counts as a "spam comment" if it's the usual type. If it's not the usual type then you will have to elaborate it.)
For example: "We were receiving 1000 spam and 100 legitimate comments per day even though we used hCaptcha on the comment form. When we disabled HTTP 1.1 on the comment endpoint, the spam stopped entirely, and we still received 95 legitimate comments per day." (in this scenario, I don't think it's necessary to further elaborate what counts as a "spam comment" if it's the usual type. If it's not the usual type then you will have to elaborate it.)
Sorry, but you seem to be continuing to misunderstand how this works. Disabling a version of HTTP on its own is not going to stop spam. You seem to be confused about how something can be one factor out of many in a statistical model.
If you don't want to talk about basic concepts like bots or fraud, and don't understand how and why detection mechanisms for them exist, I suggest you do your own research. There are lots of explanations out there. An HN comment isn't a place where I can help you with that, sorry.
If you don't want to talk about basic concepts like bots or fraud, and don't understand how and why detection mechanisms for them exist, I suggest you do your own research. There are lots of explanations out there. An HN comment isn't a place where I can help you with that, sorry.
It sounds like you are advocating a policy to solve hypothetical problems or problems you have vaguely heard that somebody had once, not real-life problems where you are familiar with the tradeoffs.
I would say absolutely not, for something that is actually run as static. How many websites could run as static, versus the clients that pay for those websites that believe they need to make a change at any time without going back to their web developers? In my experience, most clients rarely change their websites, and often request changes from my employer after having paid for a solution that allows them to have control should they want or need it. Due to this, I still need to run a dynamic website for truly static content.
A large part of this issue is web development being totally foreign to most users, and clients being burned by past developers that disappeared when needed the most, or hit with a large charge for an update that seems to be "simple". This pushes clients to want a solution where they can make the changes, and that leads to a dynamic website for static content. If you were to stop taking this type of business to further privacy, there are probably tens or hundreds of other companies in your own city that will gladly take on the work.
This absolutely is dystopian, but also current reality. Unless you are able to run completely privately online, the Internet as a whole has become dystopian because shutting down bad actors has been thrown into the hands of individuals instead of part of the backbone to how the Internet functions. Just my two cents, as a developer that needs to use these resources, but also runs a VPN on my phone and desktop nearly all the time for privacy (as well as some speed benefits, depending on the VPN provider).
A large part of this issue is web development being totally foreign to most users, and clients being burned by past developers that disappeared when needed the most, or hit with a large charge for an update that seems to be "simple". This pushes clients to want a solution where they can make the changes, and that leads to a dynamic website for static content. If you were to stop taking this type of business to further privacy, there are probably tens or hundreds of other companies in your own city that will gladly take on the work.
This absolutely is dystopian, but also current reality. Unless you are able to run completely privately online, the Internet as a whole has become dystopian because shutting down bad actors has been thrown into the hands of individuals instead of part of the backbone to how the Internet functions. Just my two cents, as a developer that needs to use these resources, but also runs a VPN on my phone and desktop nearly all the time for privacy (as well as some speed benefits, depending on the VPN provider).
It's not "just a CAPTCHA", it's a monstrosity involving tons of invasive JS that requires the latest Big Browser and attempts to identify you.
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.
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.
It's not clear to me that HTTP/3 is relevant to anyone who isn't already using it. It's most useful for large-scale hosting providers and video. And these people have already adopted it, and don't necessarily use out-of-the-box web servers for their infrastructure.
Small websites gain from reducing roundtrips on connection too. Fast websites are nice
HTTP/2 already reduces roundtrips.
HTTP/3 even more so due to QUIC's shorter handshake process.
At the cost of head-of-line blocking - one dropped TCP packet delays all HTTP/2 streams.
Yes, but head-of-line blocking is a different thing than round trips.
A dropped packet requires a retransmit which is effectively a round trip. Introducing shared fate by bundling many requests into a single TCP connection results in more requests being delayed by round trips per dropped packet.
Isn't head of line blocking a problem with the design of web servers?
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.
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!
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?
> 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.
Make sense. Nowadays, for a new project, I would like to use Caddy where I would otherwise use Apache or nginx, but I would be even more inclined to use a cloud provider's load balancer.
If you are looking for a reverse proxy with good HTTP/3 support, I recommend Envoy. Configuring it is a bit of a chore, but it feels like it was engineered from first principles to be the best possible HTTP/2 and 3 reverse proxy. The architecture for HTTP is entirely based around the h2 protocol, unlike NGINX which splits requests into various phases and struggles to support things like bidirectional streaming and upstream h2. (One down side is that it really is a reverse proxy; no static file serving or anything like that. But if you know what you need it can be great.)
I do hope to see more QUIC and HTTP/3 support, but to be honest, even h2 support in many cases sucks pretty hard. The Go HTTP interface is still pretty much HTTP/1 oriented and really needs a rehaul, and even the h2 implementation feels like it still lacks some battle testing. I think that is a damn shame.
I do hope to see more QUIC and HTTP/3 support, but to be honest, even h2 support in many cases sucks pretty hard. The Go HTTP interface is still pretty much HTTP/1 oriented and really needs a rehaul, and even the h2 implementation feels like it still lacks some battle testing. I think that is a damn shame.
Envoy is so much more. We used it for gRPC, service discovery, health checking, dynamic failover, and so much of our at-scale service topology at my last place.
> and even the h2 implementation feels like it still lacks some battle testing. I think that is a damn shame.
Citation needed.
Citation needed.
I've run into production bugs with Go HTTP/2 at multiple different jobs. They are now fixed, but I'm personally not confident that those were the last ones. I could look them up and link them if you're actually curious, but I'm not sure that will be convincing, you can obviously link to bug reports for anything and claim it's unstable, I can only speak of my personal experience.
Why not Traefik?
Good question! I have nothing against Traefik. I just haven't used it as much, whereas with Envoy I've both used it and contributed to it a little bit too.
Makes sense. I see nothing wrong with any of them, I just never heard of Envoy and I used mostly Traefik.
I even used its experimental http3 support in v2, and now it's stable in v3. As stable as it can get I guess.
I even used its experimental http3 support in v2, and now it's stable in v3. As stable as it can get I guess.
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 performance gap between QUIC and HTTP/2 grows as the underlying bandwidth increases.
https://arxiv.org/abs/2310.09423
--- end quote ---
And if you believe the discussion here https://news.ycombinator.com/item?id=25970258 it increased the load on the server unless you can "spend years optimizing it".
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 performance gap between QUIC and HTTP/2 grows as the underlying bandwidth increases.
https://arxiv.org/abs/2310.09423
--- end quote ---
And if you believe the discussion here https://news.ycombinator.com/item?id=25970258 it increased the load on the server unless you can "spend years optimizing it".
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.
-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.
>with 5% packet loss
This is absolutely massive
This is absolutely massive
It is bad packet loss, but is the sort of situations that people often find themselves in. Congestion, bad connections (which is a lot of mobile scenarios), satellite comms, and the like and it's a reality.
It's interesting how people often say HTTP/3 only benefits the megas like Google. A few years back I worked on a data centric system (fund administration) where we had a single centralized server cluster serving high value users across the globe. Because of the integration and real-time nature of the data, it wasn't possible to replicate to servers around the world, nor was local (relative to the user) caching of much value at all.
QUIC (which became HTTP/3) proved a significant improvement for users of the system. Users in the UK, Singapore, Australia, Germany, California, and so on, were all using a system in Toronto basically transparently, with great usability. That it was continents away suddenly didn't matter.
It's interesting how people often say HTTP/3 only benefits the megas like Google. A few years back I worked on a data centric system (fund administration) where we had a single centralized server cluster serving high value users across the globe. Because of the integration and real-time nature of the data, it wasn't possible to replicate to servers around the world, nor was local (relative to the user) caching of much value at all.
QUIC (which became HTTP/3) proved a significant improvement for users of the system. Users in the UK, Singapore, Australia, Germany, California, and so on, were all using a system in Toronto basically transparently, with great usability. That it was continents away suddenly didn't matter.
Clearly you have never taken the subway, or stood on a particular street corner with bad reception.
Quite frequently I'd love to have just 5% packet loss.
Quite frequently I'd love to have just 5% packet loss.
I live in a third world country, and here we consider 5% to be VERY good.
Most if my servers have about 40-50% packet loss.
50% is just a half. So we naturally expect our 3000gbit links to turn into 1gbit links, but that's not how tcp works.
Most if my servers have about 40-50% packet loss.
50% is just a half. So we naturally expect our 3000gbit links to turn into 1gbit links, but that's not how tcp works.
> 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 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?
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?
>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.
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.
> 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.
Ah yes. Basically back to some links I discussed. Oh, it's amazing but you have to be careful what you deploy, and when, and you have to switch between HTTP/2 and HTTP/3 for some unspecified criteria which may or may not be better in one or another while the article we're in comments to decries "why oh why so few implement HTTP/3"
> HTTP/3 is quite literally built for situations where you have many small requests, often in suboptimal situations.
That is what Google markets it as, for sure.
The rest of that sentence I could not parse.
Ah yes. Basically back to some links I discussed. Oh, it's amazing but you have to be careful what you deploy, and when, and you have to switch between HTTP/2 and HTTP/3 for some unspecified criteria which may or may not be better in one or another while the article we're in comments to decries "why oh why so few implement HTTP/3"
> HTTP/3 is quite literally built for situations where you have many small requests, often in suboptimal situations.
That is what Google markets it as, for sure.
The rest of that sentence I could not parse.
>That is what Google markets it as, for sure.
Can you point me to this Google "marketing"?
Google doesn't particularly care if you use HTTP/3. They don't even build it into the tools they build like Go or Dart, at least not in a timely manner. There was a passing bit of technical notes for RFCs and as they added it in Chromium, but otherwise they've been remarkably silent about it.
Yet they moved trillions of web requests to HTTP/3. Maybe they really don't know what they're doing. Cloudflare also clearly hasn't the slightest, right? Fools!
>while the article we're in comments to decries
HTTP/3 is complex to implement. Very complex. It's pretty simple to understand why it hasn't seen wide implementation in every random tool. And for many people HTTP/2 is fine, especially as you're probably just going to drop Cloudflare (which has HTTP/3) with caching in front of it anyways.
Can you point me to this Google "marketing"?
Google doesn't particularly care if you use HTTP/3. They don't even build it into the tools they build like Go or Dart, at least not in a timely manner. There was a passing bit of technical notes for RFCs and as they added it in Chromium, but otherwise they've been remarkably silent about it.
Yet they moved trillions of web requests to HTTP/3. Maybe they really don't know what they're doing. Cloudflare also clearly hasn't the slightest, right? Fools!
>while the article we're in comments to decries
HTTP/3 is complex to implement. Very complex. It's pretty simple to understand why it hasn't seen wide implementation in every random tool. And for many people HTTP/2 is fine, especially as you're probably just going to drop Cloudflare (which has HTTP/3) with caching in front of it anyways.
Have those findings been independently confirmed?
Has Google said anything? Is it dependent on certain e.g. server-side factors? Did Google "get this wrong" or was this intentional? E.g. is it by far a net positive to be faster on slow internet where the difference is perceivable, than to be slower on fast internet because it's still lightning-fast even when it's slower?
Has Google said anything? Is it dependent on certain e.g. server-side factors? Did Google "get this wrong" or was this intentional? E.g. is it by far a net positive to be faster on slow internet where the difference is perceivable, than to be slower on fast internet because it's still lightning-fast even when it's slower?
Google's needs are not most people's needs, "wrong" for them is different than "wrong" for general users.
I don't know what you mean. In this particular instance, the point is to speed up page loads. In this particular case, speed increases are most people's needs.
How much does http/3 help for server to server traffic? Seems like larger websites can use a CDN or load balancer to do termination and then use http 1.1 to the back end. Is that good enough with large pipes and a high number of connections?
QUIC was not designed for server-to-server. In that use case, you’ll [1]likely experience poor performance due to higher CPU usage (since QUIC is a user-space protocol without TCP optimizations at the kernel/NIC level) and lower throughput.
[1]This is based on public benchmarks, try searching for `TCP vs QUIC`
[1]This is based on public benchmarks, try searching for `TCP vs QUIC`
The primary benefits of QUIC apply in scenarios where you have some packet loss, and are multiplexing multiple independent "transactions" (DB queries, HTTP req's, gRPC calls etc.) over a single connection.
Multiplexing is very common but unless you are at megacorp scale (or operating a cloud hosting platform) packetloss within your own wired network infrastructure isn't a super common issue. Compared to say packetloss to mobile clients on bad networks where QUIC can really provide a significantly improved experience.
Multiplexing is very common but unless you are at megacorp scale (or operating a cloud hosting platform) packetloss within your own wired network infrastructure isn't a super common issue. Compared to say packetloss to mobile clients on bad networks where QUIC can really provide a significantly improved experience.
I subscribe for that
I'm using HAProxy on my 1 machine homelab. I'm not convinced that HTTP/3 a big improvement over HTTP/2, but for me, HTTP/3 was as easy as upgrading and adjusting the config file a little bit. From my perspective, the seeming lack of HTTP/3 support noted in this article is not a big problem. That said, I'm dying to get official 0-rtt support.
https://www.haproxy.org/
https://haproxy.debian.net/
https://www.haproxy.com/blog/announcing-haproxy-2-6
Live example: https://theandrewbailey.com/
https://www.haproxy.org/
https://haproxy.debian.net/
https://www.haproxy.com/blog/announcing-haproxy-2-6
Live example: https://theandrewbailey.com/
Everyone loves to tout TTFB numbers for quic, but there's very little widespread reporting on throughput, particularly analyzed for a large number / wide breadth of real world customers.
This matters because for a lot of operating systems, UDP buffers are still tuned to nearly 1990s levels, and are insufficient to overcome BDP challenges. For CDNs / edge deployment systems such as Cloudflare/Fastly, this may not be "statistically relevant" for their customers, in that they're close to "statistically most" of their customers, however for users in locations where these organizations do not have anywhere near such a good presence (APAC, the islands, etc), their experiences are getting _far worse_.
This matters because for a lot of operating systems, UDP buffers are still tuned to nearly 1990s levels, and are insufficient to overcome BDP challenges. For CDNs / edge deployment systems such as Cloudflare/Fastly, this may not be "statistically relevant" for their customers, in that they're close to "statistically most" of their customers, however for users in locations where these organizations do not have anywhere near such a good presence (APAC, the islands, etc), their experiences are getting _far worse_.
HTTP/3 is enabled in the curl package on Debian:
https://samueloph.dev/blog/debian-curl-now-supports-http3/
https://samueloph.dev/blog/debian-curl-now-supports-http3/
For bidirectional 2 TCP sockets and HTTP/1.1 Comet-Stream works fine.
Fighting HTTP/1.1 for money is going to fail unless you invent something fundamentally better.
Fighting HTTP/1.1 for money is going to fail unless you invent something fundamentally better.
> 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.
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.
It's been proven many times that in well-connected networks (e.g. datacenters) H2 is faster, often because all of the things that H3 improves on is now handled in the user context, which negates the overhead.
The benefits only show in poorly connected networks (public internet), so that's pretty exclusively where it should be used - anything internet-facing.
The benefits only show in poorly connected networks (public internet), so that's pretty exclusively where it should be used - anything internet-facing.
Perhaps, but:
There's ongoing work exploring QUIC-in-kernel-space at https://github.com/lxin/quic, and more generally HTTP/3 will be increasingly optimized over time as it moves towards becoming the majority of HTTP traffic (a few years off, but looks likely eventually). There's no fundamental reason I'm aware of that HTTP/3 would be _inevitably_ slower than HTTP/2, it seems likely for now that it's largely implementation details.
There's plenty of internet-facing cases with average-at-best connectivity where HTTP/3 would be beneficial today, and isn't available (non-megacorp Android apps, CLI tools, IoT, desktop apps, etc). Even on the backend, it's very common to have connections between datacenters with significant latency (e.g. distributed CDN to central application server/database).
There's ongoing work exploring QUIC-in-kernel-space at https://github.com/lxin/quic, and more generally HTTP/3 will be increasingly optimized over time as it moves towards becoming the majority of HTTP traffic (a few years off, but looks likely eventually). There's no fundamental reason I'm aware of that HTTP/3 would be _inevitably_ slower than HTTP/2, it seems likely for now that it's largely implementation details.
There's plenty of internet-facing cases with average-at-best connectivity where HTTP/3 would be beneficial today, and isn't available (non-megacorp Android apps, CLI tools, IoT, desktop apps, etc). Even on the backend, it's very common to have connections between datacenters with significant latency (e.g. distributed CDN to central application server/database).
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 available the old data was irrelevant.
So I don't see how HTTP/3 would of helped there. Most IoT applications are not very sensitive to things like latency and what counts as reliability is very much dependent on the situation. A simple protocol is an advantage.
So I don't see how HTTP/3 would of helped there. Most IoT applications are not very sensitive to things like latency and what counts as reliability is very much dependent on the situation. A simple protocol is an advantage.
>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".
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?
That works reliably with all the various types of NAT?
For some definition of "reliably".
In the sense that nothing is really reliable in the presence of state-level adversaries censuring traffic, malicious ISPs, and crappy hardware. In general I have been more successful with QUIC hole punching than with ipv6.
But having a standard and relatively broadly implemented way to make reliable "TCP-like" streams over UDP is a great thing regardless.
In the sense that nothing is really reliable in the presence of state-level adversaries censuring traffic, malicious ISPs, and crappy hardware. In general I have been more successful with QUIC hole punching than with ipv6.
But having a standard and relatively broadly implemented way to make reliable "TCP-like" streams over UDP is a great thing regardless.
While this article is about H3, I think there is wider issue at play; in general I think the gap of availble tools (/libraries/etc) between these faang megacorps and your average dev has grown very wide. Googles internal tooling maybe is the most famed, I'm sure some xooglers can tell more. This is very sad to see after seeing the massive democratization of sw development in the 00s-10s. I'm concerned about what the impact of having this two classes of developers will have on the community and ecosystem. I suppose this h3 phenomenon is one consequence.
TLS termination is still not working for HTTP/3, I think.
The nicest feature of HTTP/3 is that it is UDP based, and thus does not allow so much interception by the malicious ISPs.
The nicest feature of HTTP/3 is that it is UDP based, and thus does not allow so much interception by the malicious ISPs.
The people whose ISPs are spying on them, won't be able to use HTTP/3 anyway. It's not hard to figure out if a packet is HTTP/3 and when you drop all HTTP/3 packets your browser will usually just use something that does make it through.
Well, http/3 so far works in China and Russia, because, presumably, many enough required services are using it so that blocking indiscriminately is not practical.
I think they mean these intercepting firewall/proxies that many big companies use to spy on their employees don’t work (yet)
can you please elaborate on what do you mean? TLS termination as in HTTP/3 on a reverse proxy?
nginx's implementation works. (but for me it caused a strange performance degradation with Seafile)
nginx's implementation works. (but for me it caused a strange performance degradation with Seafile)
How exactly does it work?
By terminating an udp stream and fetching the backend data using http 2.0?
This might be enough for static web and such, but in a "new web" you'd want to use all those nice features of http/3 which have no direct equivalent in http/2, like multiplexing udp streams for video and such.
And if you forward the udp stream itself, what do you do with the certificate? Use a selfsigned one with no expiration date and add a custom CA? Seems laborious.
By terminating an udp stream and fetching the backend data using http 2.0?
This might be enough for static web and such, but in a "new web" you'd want to use all those nice features of http/3 which have no direct equivalent in http/2, like multiplexing udp streams for video and such.
And if you forward the udp stream itself, what do you do with the certificate? Use a selfsigned one with no expiration date and add a custom CA? Seems laborious.
> 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. Curl recently gained supportopens in a new tab but it's experimental and disabled in most distributions.
That doesn't matter too much, since a certain "security" company is doing deep packet inspection and blocking anything that isn't Firefox, Chrome, or Safari.
That doesn't matter too much, since a certain "security" company is doing deep packet inspection and blocking anything that isn't Firefox, Chrome, or Safari.
It's not even doing that right. I regularly see the same page blocked in Firefox while not being blocked in Chrome, on the same IP and device.
Basically if your browser provides even a tiny bit of privacy, Cloudflare blocks it randomly.
Basically if your browser provides even a tiny bit of privacy, Cloudflare blocks it randomly.
Yep, 90's security is *in* again.
[deleted]
My recent projects in C++ are just using cURL, but given some of the versions of cURL I have to support are 10 years old it isn't being turned on anytime soon.
Even the latest deployments on Rocky 9 are using a 4 year old version of cURL
When you're writing libraries distributed as binaries for other teams you can't just statically link whatever you want willy nilly.
Even the latest deployments on Rocky 9 are using a 4 year old version of cURL
When you're writing libraries distributed as binaries for other teams you can't just statically link whatever you want willy nilly.
What prevents you from using a package manager linking statically with a recent libcurl ?
I’m not OP, but at $WORK we sell a C++ library. We want to make it as easy as possible for clients to integrate it into their existing binaries. We need to be able to integrate with CMake, Meson, vcxproj, and hand-written Makefiles. We’re not the only vendor: if another vendor is using a specific cURL version, you better hope we work with it too, otherwise integration is almost impossible.
You could imagine us shipping our library as a DLL/.so and static-linking libcurl, but that comes with a bunch of its own problems.
You could imagine us shipping our library as a DLL/.so and static-linking libcurl, but that comes with a bunch of its own problems.
Exactly this. You don't want multiple versions of cURL loaded in to your process dynamically.
You need to be in control of the final link if you're shipping a .a to other teams
You need to be in control of the final link if you're shipping a .a to other teams
That doesn't work if other teams want to apply their own cURL patches, or update as soon as upstream publishes new security fixes without waiting for you.
That's the point. We don't do that. You link to the system libcurl dynamically and everyone is told to do the same.
If you want to use a private curl as an implementation detail then the only safe way to do it is to ship a .so, make sure all the symbols are private and that symbol interposition is switched off.
If you ship a .a then the final link can always make symbols public again.
If you want to use a private curl as an implementation detail then the only safe way to do it is to ship a .so, make sure all the symbols are private and that symbol interposition is switched off.
If you ship a .a then the final link can always make symbols public again.
There's also a sort-of informal "standard library" of C libraries that have super-stable ABI's that we can generally assume are either present on the system or easy to install. Zlib is another one that comes immediately to mind, but there are others as well.
HTTP/3 isn't really HTTP. It's a protocol designed to deliver javascript applications to a browser. It's not even TCP. It's UDP and then a CA TLS only layer of QUIC on top of that. It is entirely designed for large corporate use cases the the detriment of anything else.
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)
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)
Surely most hardware / software that has had no support for IPv6 has been mostly phased out by now?
Not even Android has proper IPv6 support.
You cannot manually set an IPv6 address or gateway for a WiFi, it's forced DHCP only. All of this works for IPv4.
You cannot manually set an IPv6 address or gateway for a WiFi, it's forced DHCP only. All of this works for IPv4.
It seems cheap consumer ISP hardware works absolutely fine these days, but prosumer/small business devices sometimes still have trouble with hardware acceleration. You can sometimes get that acceleration when you flash OpenWRT so the problem seems to be a lack of effort from companies that should do better.
Also, IoT crap tends to disable IPv6 (for saving a few kilobytes of ROM I think) but that stuff is better off locked behind six levels of NAT anyway.
Also, IoT crap tends to disable IPv6 (for saving a few kilobytes of ROM I think) but that stuff is better off locked behind six levels of NAT anyway.
HTTP/3 adoption will explode as soon as its provided in `libcurl` with default compile options when combined with OpenSSL and not a moment before. As soon as this happens there will be a bunch of clients that speak HTTP/3 if available, and then there will be effort to build it into servers.
Right now there's no critical mass, and the most commonly used most-reference implementation of an HTTP client doesn't support HTTP/3 in any standardized way.
Right now there's no critical mass, and the most commonly used most-reference implementation of an HTTP client doesn't support HTTP/3 in any standardized way.
As an Akamai user I already serve all my DASH traffic (video) over http3. Akamai itself return to origin only supports http 1.1 LL-HLS forces me use HTTP2.
The problem here is Akamai really in only supporting HTTP1.1 to the origin. Cloudfare I think only supports HTTP2 to origin. Does Fastly yet support QUIC to origin? Does Cloudfront, I could only find information about it supporting QUIC the last mile.
Maybe more CDN support will drive web server support.
The problem here is Akamai really in only supporting HTTP1.1 to the origin. Cloudfare I think only supports HTTP2 to origin. Does Fastly yet support QUIC to origin? Does Cloudfront, I could only find information about it supporting QUIC the last mile.
Maybe more CDN support will drive web server support.
I'm curious if any Ruby gems support HTTP/3? A quick google search found me nothing.
I'm not an expert, so it's likely there are many things I don't get, but I wanted to have "UDP in the browser" for a project, and after looking at quic/http3/web transport I'm depressed by the complexity of it all
A lot of programming interfaces do not even keep alive HTTP/1.1 connections across requests because they do not have means to manage the hidden state. Transparent and meaningful upgrades to HTTP/3 on the library side only appear difficult.
Here’s the question, are the benefits worth the increase in complexity, or rather are they worth more than other features that could be worthwhile for libraries to support.
For the hyperscale web sure, but for the long tail web that is very unclear.
For the hyperscale web sure, but for the long tail web that is very unclear.
Openssl choice here remind me of torvalds and his „don’t break user space“ refrain. They may have gone with a technically cleaner solution but it’s causing chaos downstream
shouldn't QUIC be supported at the operating system level similar to TCP? that way it could get adopted much easily in different languages
Not really. The whole point of quic is that it is built on top of plain old stupid udp, so it does _not_ require any OS level cooperation. The raison d etre of quic was to get rid of interacting with OS developers, convincing them, and patching some old ecomstations, and just "do what we want" in the process level.
I’m wondering why switching Node from OpenSSL to BoringSSL is considered hard? Is the JavaScript API exposing too many implementation details?
I have no specific knowledge about this case, but I would guess one major reason is that BoringSSL does not provide any API or ABI stability guarantees.
Bun uses BoringSSL. Bun is mostly compatible with Node.
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.
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.
Isn't head of line blocking a problem with the design of web servers?
HAProxy supports HTTP/3. Should be mentioned.
I am still super disappointed about HTTP/3 in Rust. AFAICT there was a working HTTP/3 implementation in Rust over 6 years ago, but they (quinn crate) then literally yanked their entire version history from Cargo in order to wait for h3 which proceeded to take about three years (minus three days...) to even show up. I don't know the status of h3 today but that whole thing made me incredibly upset at the time. That having happened also makes me get annoyed again every time someone points out that Rust still doesn't have a very good HTTP/3 implementation, because I get reminded of the implementation from over 6 years ago that practically got retconned out of existence for this.
(I guess though that quiche has been an option if you like to write Rust like it's C.)
(I guess though that quiche has been an option if you like to write Rust like it's C.)
There's also s2n-quic.
The most popular internet protocols are 100% text. This fact is indisputable. I doubt that the guys at google even know this, or know why ....
Not really. Most of internet traffic now is video.
I think a lot of this is missing the point. The features HTTP/3 provides are features of value to datacenter and large scale deployment. Most sites deploying off-the-shelf solutions like nginx or whatever don't care. Most behind-the-reverse-proxy services don't care. So Cloudflare cares about HTTP/3, but their customers mostly don't, except the biggest ones.
Use the tool for the job. If a single-threaded Python server running HTTP/1.1 works for your IT app, then use that. HTTP/3 has nothing to offer you.
Use the tool for the job. If a single-threaded Python server running HTTP/1.1 works for your IT app, then use that. HTTP/3 has nothing to offer you.
Coordinate efforts for more of most of popular programming languages, then switch from experimental in synchrony
Cool, let me see if I can block HTTP/1.1 on Cloudflare to get rid of bot traffic.
as an indie web master, some percentage improvement on ttfb brings zero benefit to me and my users, but requiring or recommending it to users only help big tech.
Could you elaborate on why faster responses don't benefit you or your users?
Because the faster response is negligible when you're an indie web host that can serve content over a single connection with reasonable speed. Where HTTP/3 really "shines" is when you connect to a web site that then has dozens of connections to other hosts (internal or external)...which is facebook/google/ad companies.
HTTP/3 speeds up that kind of content by reducing connection startup times to all of them, which can be compounded.
HTTP/3 speeds up that kind of content by reducing connection startup times to all of them, which can be compounded.
but it doesn't help for different external connections, each one needs a new connection.
it's good for multiple resources from the same host, maybe you have a lot of images on your photo blog or something
it's good for multiple resources from the same host, maybe you have a lot of images on your photo blog or something
http3 has enhancements that speed up initial handshakes for new connections (QUIC essentially is UDP plus combining TLS and a native reliability layer to replace separate initial SYNs for them separately). So when you go to a page with tons of ads/trackers/javascript libraries, you're not left waiting as long for the ads to serve while browser reaches out to all those components and does separate TCP, TLS, and HTTP connections.
But users of most other websites won't see a ton of noticable benefits unless they have facebook/netflix/google levels of traffic. And at that point, you're either highly focused on the end user component code or you've outsourced it to a CDN that'll do the http3 for you anyways.
But users of most other websites won't see a ton of noticable benefits unless they have facebook/netflix/google levels of traffic. And at that point, you're either highly focused on the end user component code or you've outsourced it to a CDN that'll do the http3 for you anyways.
> And Fastly shared the major improvements in time-to-first-byte they're seeing in the real world:
What's time until last byte though?
Yeah, The metric that got you promoted is cool and all, but if my application works on files atomically, it's the time until last byte that has meaning to me.
I'm also gonna assume a bit more, and say it's also the byte where the service can start processing someone else's connection. So if http/3 increases the load on servers, with their CPU, instead of network hardware, with their ASIC, this would be a net loss as soon as you look at amount of complete requests per energy used. Instead of just looking at single session metrics.
I guess I should probably read the HTTP/3 spec now...
What's time until last byte though?
Yeah, The metric that got you promoted is cool and all, but if my application works on files atomically, it's the time until last byte that has meaning to me.
I'm also gonna assume a bit more, and say it's also the byte where the service can start processing someone else's connection. So if http/3 increases the load on servers, with their CPU, instead of network hardware, with their ASIC, this would be a net loss as soon as you look at amount of complete requests per energy used. Instead of just looking at single session metrics.
I guess I should probably read the HTTP/3 spec now...
> neither QUIC nor HTTP/3 are included in the standard libraries of any major languages
Like dotnet?
Like dotnet?
Just pointing this out in case it's helpful: there's tons of great discussion of this topic elsewhere in the thread!
Google invents something and uses its huge market share and power to force everybody to use their thing, shaming and threatening those who don't. Amazing outcome.
Isn't this just going to get resolved within one year when programmers aren't needed and AI will create all the needed libraries? </sarcasm>
> We've developed a totally new version of HTTP, and we're on track to migrate more than 1/3 of web traffic to it already! This is astonishing progress.
It's astonishing change. You could have used the same argument to show that any dismaying historical development was "astonishing progress". From my point of view HTTP/3 looks like an advantage for hyperscalers but no benefit to regular users using small-scale websites.
That's progress toward a future I don't want to arrive.
It's astonishing change. You could have used the same argument to show that any dismaying historical development was "astonishing progress". From my point of view HTTP/3 looks like an advantage for hyperscalers but no benefit to regular users using small-scale websites.
That's progress toward a future I don't want to arrive.
> 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.