401–410 of 504 posts
Earlier quoted context omitted.
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.
I even used its experimental http3 support in v2, and now it's stable in v3. As stable as it can get I guess.
Earlier quoted context omitted.
> 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?
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 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.
Earlier quoted context omitted.
> 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?
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.
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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 wher…
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
I'm happy to report that - to my utter amazement - my ISP's on-prem device does /64 prefix delegation to each (DHCPv6?) client.
Can you request a bigger delegation? a single /64 is very limiting, since that effectively limits you to 1 subnet (so no extra guest / IoT subnet)
Earlier quoted context omitted.
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.
> results in hardcoding protocol details in application code Are you suggesting that this could have been implemented a different way? Example: IP could be negotiated to upgrade from v4 to v6? I am curious about your ideas.
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)