In TCP, a connection is uniquely identified by the following tuple:
(src ip, src port, dst ip, dst port)
We can do some trickery to let people keep their addresses while inside of a network, but switch from mobile data to wifi and every TCP connection drops.
This is easy enough to solve, in theory. Give every connection an unique ID, and then remember the last address you received a packet for that connection from, ideally in the kernel. This makes IP addresses completely transparent to applications, just like MAC addresses are. However, the tuple is assumed almost everywhere and NAT makes new layer 4 protocols impossible. Unless you layer them over UDP. And this is exactly what Wireguard, QUIC, mosh and others do. Once it's ubiquitous, you'll be able to start an upload or download at home, hop on your bike, ride to the office, and finish it without the connection dropping once.
...and part of me think HTTP/3 could be that universal transport protocol that could eventually solve this problem, and then I agree.
However, the solution should not and cannot be a global routing table. Aside from privacy issues, routing tables are very expensive. It needs to be decentralized, done on or at least near the endpoints, similar to programs like mosh, wireguard etc. Though there are certain security and privacy trade-offs in mentioned protocols that may not be appropriate.
The "flat address space" idea however is completely ridiculous. That would mean every node on the internet keeping track of the path to every singe other node. This is what ethernet does and it barely scales to ten or so thousand nodes. Routers are already struggling hard with the 700k table entries we have for the IPv4 internet. To the point where providers actually wrap IP packets inside of simpler protocols once they enter the network.
We need some kind of hierarchical addressing that expresses the location of a node in the network. We know this works. We just need the layers above not to rely on those addresses staying constant.
If anything, we need a more hierarchical structure, with stricter separations by, e.g. Continent/Country/Province and possibly down to street or even house level, so routers can more easily just throw the data in the right general direction. Note the obvious privacy problem there.
you could do this for over 20 years as long as server supports HTTP/1.1 https://en.wikipedia.org/wiki/Byte_serving
One of the things I was looking forward to from IPv6 was the mobility of IPs [1].
[1] - https://en.wikipedia.org/wiki/Mobile_IP#Changes_in_IPv6_for_...
Acknowledgements are encrypted.
I know it's possible for wireguard, maybe mosh.
Doesn't that mean we need to rethink TCP instead of pulling all these transfer concerns to the application layer?
You may also be interested in SCTP, which is awesome on paper and works well across the internet. But since most firewalls only understand TCP, UDP, and ICMP other protocols get auto dropped.
SCTP could have been amazing. https://en.m.wikipedia.org/wiki/Stream_Control_Transmission_...
It still is, it's part of the WebRTC spec, and when you use a WebRTC data channel, you're using SCTP over DTLS over UDP! (or TCP, possibly with a TURN relay, which may end up tunneling the whole thing over TLS over TCP :))
There are a lot of acronyms in WebRTC, thankfully there's https://webrtcglossary.com
https://orchid.com VPN does tunnel the traffic over webrtc.
On the other hand, there will never be a time when TCP could possibly be "update", it is too entrenched and fossilized.
Chrome is happily using QUIC, also on Android. And for non-browser apps, every Android app that links against the recommended network client library will do QUIC transparently.
https://developer.android.com/guide/topics/connectivity/cron...
> On a well-optimized site like Google Search, connections are often pre-established, so QUIC’s faster connections can only speed up some requests—but QUIC still improves mean page load time by 8% globally, and up to 13% in regions where latency is higher.
https://cloudplatform.googleblog.com/2018/06/Introducing-QUI...
Another summary: https://kinsta.com/blog/http3/
Older Cloudflare blog: https://blog.cloudflare.com/http3-the-past-present-and-futur...
Personally, whenever I've experienced "this site is slow", it's either because the server is really congested or there's something else taking the time (like copious amounts of JS executing on the client); both cases in which the tiny improvements (if any) of a protocol version would have zero effect.
When you consider that there's an additional huge chunk of complexity (= bugs) added by these new protocols, for small or even negative performance improvement, it really seems like there is no value being added --- it's more of a burden on everyone except those working on it.
Syncthing uses a bunch of protocols by default to find clients, including TCP, QUIC and a few others. If you want to have some insight into how your network behaves with these protocols head-to-head, spin up syncthing and wireshark.
> With HTTP/2, any interruption (packet loss) in the TCP connection blocks all streams (Head of line blocking). Because HTTP/3 is UDP-based, if a packet gets dropped that only interrupts that one stream, not all of them.
So while HTTP/3 on a perfect network might be a 1 - 4% slower it's more stable/reliable in that any packet loss won't cause a dramatic drop off in performance... so 1-4% in best case network conditions but in real world network conditions http/3 should~ be much better...
Congestion control algorithm - and congestion window sizing/tuning - plays a not-insignificant role in throughput, especially when comparing a 15KiB object vs. a 1MiB object. It's often _more_ outsized for those "medium sized" objects, as too small a window won't scale up by the time the transfer completes in some cases.
In other words: this is a good post, but the caveats around congestion control algorithm are a little understated w.r.t. the benchmarks.
> Overall, we’re very excited to be allowed to help push this standard forward. Our implementation is holding up well, offering better performance in some cases and at worst similar to HTTP/2. As the standard finalizes, we’re looking forward to seeing browsers add support for HTTP/3 in mainstream versions.
I feel like the conclusion should be "Hypothetical advantages of HTTP/3 still not realized," but they are "We're excited to be working on this", with no mention of... why. Like, why isn't HTTP/3 resulting in expected advantages; what might be changed to change this; what are you going to do to try to realize actual advantages to 'push the standard forward'? It seems like a standard for the sake of saying you have done something and have a standard, if there aren't any realized advantages, no?
> For a small test page of 15KB, HTTP/3 takes an average of 443ms to load compared to 458ms for HTTP/2. However, once we increase the page size to 1MB that advantage disappears: HTTP/3 is just slightly slower than HTTP/2 on our network today, taking 2.33s to load versus 2.30s
And in their closer to real world benchmarks, they find no improvement, instead some negligible degradation.
> As you can see, HTTP/3 performance still trails HTTP/2 performance, by about 1-4% on average in North America and similar results are seen in Europe, Asia and South America. We suspect this could be due to the difference in congestion algorithms: HTTP/2 on BBR v1 vs. HTTP/3 on CUBIC. In the future, we’ll work to support the same congestion algorithm on both to get a more accurate apples-to-apples comparison.
As a developer of web apps, I will personally continue to not think that much about HTTP/3. Perhaps in the future network/systems engineers will have figured out how to make it bear fruit? I don't know, but it seems to me of unclear wisdom to count on it.