TCP is Broken: Here's the Fix
Вставка
- Опубліковано 29 гру 2024
- In today's episode, we're diving into the world of WebTransport and its role as the unsung hero fixing TCP's biggest headache: Head of Line Blocking. It's a deep dive into the nitty-gritty of internet protocols, where one lost packet can cause a domino effect of digital chaos. But here's where it gets interesting: WebTransport, the new kid on the block, is making waves by tackling this issue head-on.
The spotlight, however, is on the WebTransport.rs toolkit, a creation designed to seamlessly integrate into your web development arsenal. It's not just a toolkit; it's a doorway into the future of web communication, built for efficiency and streamlined experiences. Developed alongside Griffin, this toolkit stands as a testament to innovation in web technology, making WebTransport accessible and understandable.
github repo: github.com/sec...
demo website: webtransport.rs/
We'll explore how this toolkit simplifies complex processes, offering a hands-on approach with datagrams, unistreams, and bistreams. It's about making the web faster, more reliable, and ready for the challenges of tomorrow. So, whether you're a developer looking to stay ahead of the curve or a tech enthusiast curious about the future of the internet, this episode is for you. Join me in unraveling the mysteries of WebTransport and how it's setting the stage for the next generation of online communication.
Video Chapters
0:32 The Head of Line blocking problem
1:08 What is WebTransport.rs?
2:44 Quic Datagrams
3:34 Datagrams use cases
4:08 Datagrams echo explanation
4:30 Unidirectional Streams
5:28 Bidirectional Streams
7:15 Helm chart
8:37 Running WebTransport Locally
You continue to inspire! Kudos.
Wow 🤩 I am so happy that you found this useful!!! 🙏🙏🙏 which part helped the most???
TCP was just made for a completely different ERA where we didn't need so many files for a single website or didn't have have web-applications at all like UA-cam or TLS/SSL cryptography.
QUIC is just made for this era, TCP is ancient compared to it and inefficient.
I wish I could use it, but even with NGINX when I tried so many things broke when I tried to use either QUIC or HTTP3. What I mean is that it's not battery included yet, and the universal transition has not happened yet. Even now most of the websites use HTTP2 I think and even some still use HTTP1 which is just horrible for this age.
You are absolutely right!!
We went through the same pains.
Checkout our helm chart that contains a udp load balancer to replace nginx! github.com/security-union/leptos-webtransport-template/tree/main/helm
I also know that the nginx team recently merged some code to support quic, I think it is time for me to go check on them
I'm not sure I understand why head of line blocking is a problem or how it is fixed by Quic.
Hey @aspizling! Let me use a website loading as an example here, let me know if this helps.
In the TCP protocol, imagine you're loading a website that requires multiple resources to be downloaded, such as images, CSS files, and JavaScript files. These resources are sent over the network in a sequence of packets. If one of these packets (say, an image file) gets lost or delayed, all subsequent packets (like the CSS and JavaScript files) are held up until the lost packet is retransmitted and received. This delay affects the entire website loading process, even though most of the resources have arrived and are ready to be used. This is head-of-line blocking in action.
Now, let's consider the same scenario with QUIC. QUIC allows these resources to be sent over different independent streams within the same connection. So, if a packet containing part of an image gets lost, only the stream responsible for that image is affected. The other resources (like CSS and JavaScript files) continue to load independently without waiting for the lost packet to be retransmitted. This means the overall website can load faster because it's not held back by a delay in a single resource.
In summary, with TCP, a lost packet can delay the loading of an entire website, while with QUIC, the impact of packet loss is isolated to the specific resource in its own stream, making web page loading more efficient.
@@dario.lencina that makes sense, thanks, although I think modern browsers tend to use multiple TCP connections per host when loading data on a website but I guess there is an overhead to that. Actually I just checked and my browser is configured to use a max of 6 so I guess the overhead must be pretty big.
@aspuzling yes sir! I believe that this is why UA-cam already moved over to QUIC
the p in tcp is protocol
Well, technically you're right, but let's just say the "p" in TCP stands for "pretty awesome protocol"!
github repo: github.com/security-union/leptos-webtransport-template
demo website: webtransport.rs/
Low latency apps (voice, video) use UDP anyway. Datacenter apps have reliable networks. Problem does not manifest itself in most real world scenarios.
Hey @adontz yes, we are on the same page, QUIC is UDP and most video/voice platforms are already switching from DASH and WebRTC to quic.
As of 2023, the total number of mobile phone users in the world, including both smartphones and feature phones, is approximately 7.33 billion. This number represents about 90.93% of the global population. Specifically, the number of smartphone users is around 6.92 billion, accounting for 85.74% of the world's population.
So all those do not have reliable networks 😄 .
What do you think about this?
@@dario.lencina I can't help but wonder, what if we just split the browser into a client-server application, with the server part being in charge of communicating with other servers. This would then be able to use the TCP/IP stack, just like in the old days. Real sockets. Raw or TCP, whatever the application needs and what fits the bill best. That would of course need a sandbox. Just like the browser does.
If all the engineering effort that went into long polling, web sockets, web rtc, web whatever had been invested and making a nice secure and efficient sandbox, I would love to compare that to "modern technology".
I find it mind boggling how many hundreds of millions we invest into sticking to a monumentally stupid idea. And every time we get a new "technology" that is always a new wrapper around the same old technology we use since the eighties with a couple of onions wrappers around it, we get excited and think, hey, this is a promise kept! We can actually use the web for this or that.
Super interesting thank youuuuu
Comeon, that's dramatizing the thing. We use hyper text transport protocol as universal transport for everything. We do that, because some people decided it's ok to just block all traffic but web pages and somebody else decided that this was a good enough fundament to build everything upon. So to get non-web traffic through corporate firewalls, we make everything web traffic and thus make the very firewall obsolete, because one thing it's no longer allowed to block is web traffic. Web traffic that is now encrypted and can no longer be inspected.
In parallel, we decided that all (enterprise-) software has to be web applications. Why? Because it's too hard to manage dependencies of Windows DLLs. I'm not kidding, that was the argument at the time. What's the most painful problem in Web development? I would say it's dependencies in npm. Right after dependencies on browser features. We got the last one fixed by replacing internet explorer with chrome. But now we depend on Google. Not yet a problem I guess, Google is not evil after all. I'm sure we find an excellent solution to dependencies on the Web.
And you claim that TCP is the original sin? Really? 😀
Hey Michael:
First of all thank you for your thoughtful comment 🙏🙏🙏.
TCP is the most successful protocol, it is a fact and to your point we use it just about everywhere.
What I meant is that imo the head of line blocking is an “original sin” because it is built in the core of the ack-sequence of the protocol, this is why google and big tech just keep increasing the min frame size to avoid segmentation.
Yes, I was a bit dramatic about it 🙈🙈
@@dario.lencina Not half as thoughtful as your videos, a real nice discovery! 🙂
I just came out of a deep dive into TCP trying to find out why my VPN connections to a customer hang. Turned out to be an issue with mtu path discovery. I'm currently in north africa and I guess their chinese equipment is a bit too flexible. I have a glorifed window of 2 bytes to set my frame size in order to not have "the wrong kind of segmentation" between some chinese router and my customers vpn settings to see TCP fold in on itself and die.
I think I get your gist, there is a certain kind of suffering that shines through this kind of stories ;-)
But it doesn't even come close to the malicious idiocy of strategic management decisions - or "pragmatism" :D
Yaay! You cut your hair😁
Yeah!! My family and wife really pushed me to do this…. And they were right mate!! Mamma is always right 🤗🤗🤗
This guy
☝
🙌😍