The point of UDP vs TCP is to handle what's called "Head of the line blocking". When you sens packets TCP, it doesn't show packets 4 and 5 if 3 is missing (even if 4 and 5 have arrived). In QUIC, you forego that, so if you have 3 things in parallel, and packet 3 is missing, 4 and 5 are available, and that optimizes parallel data transfer on the same connection.
@@theodorealenas3171the reason is that it was created at a time when memory and local storage were short. The algorithm was designed to send data that, on the receiving end, the application uses up and cannot store in its entirety. When a package is missing, the processing has to stop, and it may not be able to store all the following packages. It has to signal back from where it is missing, and then the data flow has to repeat from that point. Today memory is more available. I have gigs of memory in my notebooks; at that time, we had kilobytes.
@@canoozie The specified country is already being bombed. Perhaps the previous missile that established the connection was terminated abnormally or was not cleaned up properly.
This started as a joke but I got carried away: *TCP:* Client: "Hello, I would like to launch some missiles." Server: "Hello, I acknowledge you would like to launch some missiles. I am a missile launcher." Client: "I acknowledge you are a missile launcher." Client: "Here are targets 1, 2, 3, , 5, and 6" Server: "Received targets up to 3" Client: (again with this guessing game... hmm...) "here is target 4" Server: "Received targets up to 6" Client: "That is the full list of targets. Good bye." Server: "Ok, commencing launch. Good bye." *Plain UDP:* Client: "Hey can you launch missiles at targets 1, 2, 3, , 5, and 6?" Server: (doesn't reply, launches missiles, skips target 4) *QUIC:* Client: "Hey can you launch missiles at targets 1, 2, 3, , 5, and 6?" Server: "I got everything except the 4th one" Client: "Okay, here's target 4 again" Server: "Got it, commencing launch. Good bye." Client: "Good bye."
TLS 1.3 is able to negotiate a session in one round trip, but there still is the roundtrip to establish the TCP connection. The diagram in the video is correct. QUIC allows for both a connection and a TLS session to be established in the very first round trip.
Pour one out for all the old network admins having flashbacks to the Doom days when their firewall alerts for RUclips causing a UDP flood attack warning.
Scala is underrated. (Functional) Scala was the most productive and awesome professional project I had the privilege to work on in a small team of 4... essentially replacing a complex C++ system written by dozens.. while being 10x faster to run and with 5x less lines of code...
Scala has serious language design issues. Great intentions but they were not paying proper attention to how and in what way their intentions were sending the language and default library into.
@@molarmanful I neved used esp3 of Scala. I haven't used it for 3 years or so. Maybe it improved there. It's not a bad language but, at least at the time, has/had quite serious issues because they were trying to do well.
What did he mean by "UDP in Linux lacks behind TCP"? UDP provides backbone infrastructure of the Internet since the beginning and is as mature as TCP. Most of the servers and network infrastructure is running Linux (or some sort of linux kernel) and critical and commercial planet-scale services run on top of UDP. To name a few: DNS, IPsec, RIP, VoIP, online gaming (MMORPG for example), NTP, Video streaming (RTSP, RTP, SRT, WebRTC), etc.
(14:13). 1 week ago I was thinking of letting my clientside app and my server do an upfront exchange of data (header names, constant header values, known payloads etc.) in the background, which could later be referenced by a hash, effectively reducing the payload of each subsequent request to a like..
The problem is that the server then has to store this state, often in a distributed way that involves the server making network requests to get the state, so that if that particular server replica goes down then it can continue, but it really depends on your scenario. If you can keep it in memory and re-send it if you connect to a new server then it could work, at the cost of some server memory. For HTTP this is basically a session token, or more generally it's just storing state on the server.
Problem with UDP is no flow control, the idea of TCP is it scales - without back-pressure the internet would be probably be well congested, like the Amazon toilets.
QUIC, as a transport protocol, is implemented entirely in user space, which includes all its mechanisms such as flow control, congestion control, selective acknowledgments, and packet loss detection. This is unlike traditional transport protocols like TCP, where these mechanisms are typically implemented within the OS kernel.
@@ScottChenRightsonInteresting, I guess the problem with that is a nefarious program could override those and hog all the bandwidth. Technically you can patch your OS kernel, but that's a little bit more work.
This is great news for anti-censorship too. Most national firewalls (think China, Iran, etc; but several Western countries are on this slippery slope as well) rely on TLS SNI to block blacklisted domains; the reason they can do that is SNI is transferred in plaintext in the TLS protocol. There is the rather new ESNI and the newer ECH, but both are extensions to TLS 1.3 and can be (and are) easily banned wholesale by state actors before they have even taken off. Doing similar to an entirely new protocol version is going to be significantly more difficult. Still possible of course; and in the worst case scenario some governments will just ban HTTP3 outright, which will lead to even more internet fragmentation than we already have today. Obviously this is not a valid reason against the adoption of any privacy-respecting technology. And frankly speaking, anything that makes the life of those who wish to impose censorship more difficult and miserable is a win in my book.
UDP is just transport layer, which is connection less nothing to do with state that is done in the application layer(wether it is RTP or quick) same as ACKS's, if needed, in voice there is no retransmission as it would be considered old information.
Insert always has been meme. Any HTTP packet starts with HTTP/version since ever. This is literally how the protocol calls itself. People just went with it.
4:38, "most packets make it so why ack everything" yea, get back to me when you have a network server trying to reach devices over udp and there's a firewall or worse a load balancer that mangles it and everyone thinks it's your devices who's at fault.
and you can only nack what you know should be coming. That might work within this well defined high level protocol but not for a low level protocol like tcp.
Isn`t NAKing a bit worse then ACKing since each packet needs to stay in the buffer in the server for some period of time in case it get`s NAKed? You have a bunch of data, split it into 10 packets, send out each one and then move on to new task and suddenly you get back an info that 'i`m missing packet no. 3, can you resend it?". You need to prep that data once again.
A bit of a simplification, but I find it more helpful to think of quic as acking multiple packets at once. In the negotiation phase, both peers agree how big the respective send buffers can be, and won't send anything more until packets are acknowledged. The receiving peer then occasionally sends an ack for all packets received. It's a balancing act of sending as few acks as possible, but frequently enough to recover from packet loss reasonably. This balance point can shift depending on how reliable the network is moment to moment. Technically, TCP can do this too, but there are differences. Rfc 9002 goes into more detail.
@@LtdJorge actually no, nacking can't work for this situation. Consider that any packet can be lost at any time, including hypothetical "nack" packets. If the connection broke completely, the sender would continue sending packets, none of which reach the destination. The receiver starts sending nacks but they aren't delivered either. Since the sender never received a nack, they Believe everything is fine and continue sending data into the void.
@@LtdJorge if you don't get an ACK for that packet... you assume the worst and keep the supposedly lost packets on the queue and send them again. So... worst case you resend messages and keep data which could have been deleted before but it had no way to know. Compare to NACK... you can never know if the packet arrived... or it didn't arrive, and the NACK also failed to arrive.
Funny enough, first time I heard about HTTP/2 and google trying to make it widely available, the implementation was using QUIC, that's how I heard about it.
Organizations that require this much control can install their own root certificates on company devices and proxy traffic. Certainly more expensive to do, but it can be done.
@@Andrew-jh2bn Yes. Eggsachedly. And in general (aka im lazy to write another comment, heres my rambling rant): Who wants to never invest in futureproofing or checking if the actual status quo makes any sense at all? Yeah, right -- those that could and should afford it -- but hey, it all comes down to keep the status-quo alive, because "we have contracts" ... Right, yeah .. So how about engineering in parallel the alternative based solely on QUIC? Yeah but how can we control if it works exactly like our actual system in the end? That is the point. Btw QUIC is a late millenial and if it wasn't for Google it would have been adopted already around 2006, because they are the ones which explicitly forbid the use of this principle, for exactly that reason that it makes it hard to addon/overwrite/replace advertisements or block those already embedded ... or the right to send content preventing synthetic analytics. Yeah, right use humans, sure .. the one and only single point of failure in any type of processing .. Err, yeah, duh, because it allows to let the ACTUAL CONTENT be checked by ACTUAL HUMANS which allows to find/design/create/shape ways of interaction between man and machine that yet have to be explored. BUT BUT BUT, status quo YKNOW, also who wants that new stuff anyway?? Check out ip v3/v5/v6 and especially Ericssons involvement when they tried to modernize so Symbian would allow actual upgrades independent of the hardware (to overcome the problem that at that point (end 90s/early k2s) we had so many competing proprietary protocols on top or in parallel, plus so many different proprietary data transfer protocols and the mobile networks grew exponentially - what most people forget is that tcp was originally designed as being solely a universal packet transceive protocol to connect completely different machines over any type of connection; went well right?), by defining a fast, very compacted and easily manageable and predictable way to "sort things out" - this effort died in 2005; then Android was bought up by Google ... before it was released to the public in 2008, other vendors and distributors tried to find solutions, Vodafone for example based on linux in 2005/2006). Just some food for thought for lovers of walls of text that seemingly make no sense ..
Looking at the early adoption rate of network protocols and interpolating them to the future can be quite misleading. HTTP/3 are quick to be adopted because it's the large players like Google that comprises a massive amount of web traffic that will adopt them first and they can deploy these new technologies rapidly across their entire network. This makes for a very rapid early adoption, but then you'll get into the long end of the tail where millions of individual developers have to make the choice to adopt the technology. This is in contrast to other technologies like IPv6, which is harder to adopt for larger companies that has many legacy infrastructure because deploying a new IPv6 requires installing new hardware and because interoperability with existing IPv4 infrastructure isn't always seamless or possible, it's hard to just switch wholesale. This makes for a much slower early adoption rate.
What a bizarre issue to have. These are all public specifications, the vast majority of implementations will be open source, and I sincerely doubt that one in a thousand users of the internet understands any of the protocols, let alone that even one in a million users understand *everything* going on. This is no different to literally anything in computing, or really anything else in the world. Do you refuse to get into a car unless you know exactly how the crumple zones are designed? Or do you simply check if the people that really do understand it say if it's good or not?
@@themartdog i had thought htat originally too, but this also means that the application can choose if it wants to request retransmission, for something like streamed video, it may not matter.
@@claudiusraphael9423I do not know how that is a reply to my comment. Nobody said anything about the "preciousness" of TCP. TCP is a protocol, so it cannot be precious. If you are emotionally attached to a specific technology, you have a severe problem. Also, HTTP/3 does not try to replace TCP. There are a lot of protocols that still run and will run on TCP. There are a few factual mistakes in the video about TCP. So, you can find a specific source if you'd like to learn what TCP is. That was all I wanted to say. For example, one factual mistake in this video is that Prime says every package must be acknowledged individually in TCP. Not true. TCP uses a sliding window technique. It sends several packages. When package X is acknowledged, all earlier packages have also arrived. It is not essential from the whole video content's point of view, but it is related to the feature of HTTP/3 vs. TCP, which is the most significant feature and was totally missed in this video. The most significant shortcoming of TCP compared to HTTP/3 comes from the slow start and how this sliding window size increases. It starts with one package, then two, then four, and so on, until the channel loses packages. Imagine having a browser on a local network sitting by the server's side. You can download huge files without package loss, sending 10,000 packages without acknowledgment. Using TCP for the following file, you would start sending just one, then acknowledge, then two, and so on. With HTTP/3, the channel can be flooded immediately based on the information from the previous communication. Having said that, I also enjoy these videos a lot because they are usually precise and accurate, as much as I can tell. His opinions usually align with mine. He is a senior; you must learn from him, not TCP.
@@PeterVerhas "TCP is a protocol, so it cannot be precious." --- preciosa: following guidance, willing to be ruled in the most precise manner (man machine interface kybernaut - the terminal - TCP is the one that is overprecise, basically relects the era: spygame)
No, they sound similar so they must be related! Like how Tor is for Torrents, Java is the base of JavaScript, and Ham comes from Hamsters. (I am joking plz don't kill me)
@@AlexanderVulpes Ham from Hamsters .. that surely is the most brutal food-processing i can casually imagine .. Offtopic i know, lol. Wonder how it tastes though.
Being part of the Internet Engineering Task Force sounds like it grants you the right to raid any premises where bad code is currently being deployed.
Hands in the air, this variable is called "a" !
This should be a real thing. All the Microsoft engineers sweating rn
And in reality it’s mostly being involved in multiple years-long arguments over text
sooo you mean... all premises?
IETF, OPEN UP!
The point of UDP vs TCP is to handle what's called "Head of the line blocking".
When you sens packets TCP, it doesn't show packets 4 and 5 if 3 is missing (even if 4 and 5 have arrived).
In QUIC, you forego that, so if you have 3 things in parallel, and packet 3 is missing, 4 and 5 are available, and that optimizes parallel data transfer on the same connection.
I never understood why TCP wanted to drop arrived packets. It's so weird that it took so long, but there must be reasons
@@theodorealenas3171
Yes, finite buffers
@@theodorealenas3171the reason is that it was created at a time when memory and local storage were short. The algorithm was designed to send data that, on the receiving end, the application uses up and cannot store in its entirety. When a package is missing, the processing has to stop, and it may not be able to store all the following packages. It has to signal back from where it is missing, and then the data flow has to repeat from that point.
Today memory is more available. I have gigs of memory in my notebooks; at that time, we had kilobytes.
@@theodorealenas3171Maybe it is because hard disks are written sequentially?
@@I_am_DD interesting, are the packets aren't THAT big? Was it a big deal to cache potential misses back then?
UDP = launch missles, TCP = Did the missiles launch?
ACK armageddon
I didn't get the missiles. Pls launch again!
@@darukutsu Here are your missles (for the second time), please confirm receipt.
@@canoozie The specified country is already being bombed. Perhaps the previous missile that established the connection was terminated abnormally or was not cleaned up properly.
This started as a joke but I got carried away:
*TCP:*
Client: "Hello, I would like to launch some missiles."
Server: "Hello, I acknowledge you would like to launch some missiles. I am a missile launcher."
Client: "I acknowledge you are a missile launcher."
Client: "Here are targets 1, 2, 3, , 5, and 6"
Server: "Received targets up to 3"
Client: (again with this guessing game... hmm...) "here is target 4"
Server: "Received targets up to 6"
Client: "That is the full list of targets. Good bye."
Server: "Ok, commencing launch. Good bye."
*Plain UDP:*
Client: "Hey can you launch missiles at targets 1, 2, 3, , 5, and 6?"
Server: (doesn't reply, launches missiles, skips target 4)
*QUIC:*
Client: "Hey can you launch missiles at targets 1, 2, 3, , 5, and 6?"
Server: "I got everything except the 4th one"
Client: "Okay, here's target 4 again"
Server: "Got it, commencing launch. Good bye."
Client: "Good bye."
TLS 1.3 is able to negotiate a session in one round trip, but there still is the roundtrip to establish the TCP connection. The diagram in the video is correct. QUIC allows for both a connection and a TLS session to be established in the very first round trip.
Pour one out for all the old network admins having flashbacks to the Doom days when their firewall alerts for RUclips causing a UDP flood attack warning.
Thanks for explaining HTitty3 protocol
At this rate Hyper Text Transfer Protocol version will overtake Internet Protocol version.
The Internet Engineering Task Force coming out with the Ache Titties Pee 3 standard is absolutely wild
Scala is underrated. (Functional) Scala was the most productive and awesome professional project I had the privilege to work on in a small team of 4... essentially replacing a complex C++ system written by dozens.. while being 10x faster to run and with 5x less lines of code...
Scala has serious language design issues. Great intentions but they were not paying proper attention to how and in what way their intentions were sending the language and default library into.
@@brunoaisironically the syntax is why I love Scala (esp. 3) so much, the things I can get away with writing can get downright hilarious at times
@@molarmanful I neved used esp3 of Scala. I haven't used it for 3 years or so. Maybe it improved there. It's not a bad language but, at least at the time, has/had quite serious issues because they were trying to do well.
Open up! Htittyp task force
Age Titty Pee
LMAO!
What did he mean by "UDP in Linux lacks behind TCP"? UDP provides backbone infrastructure of the Internet since the beginning and is as mature as TCP. Most of the servers and network infrastructure is running Linux (or some sort of linux kernel) and critical and commercial planet-scale services run on top of UDP. To name a few: DNS, IPsec, RIP, VoIP, online gaming (MMORPG for example), NTP, Video streaming (RTSP, RTP, SRT, WebRTC), etc.
Nothing, no basis for that claim
(14:13). 1 week ago I was thinking of letting my clientside app and my server do an upfront exchange of data (header names, constant header values, known payloads etc.) in the background, which could later be referenced by a hash, effectively reducing the payload of each subsequent request to a like..
Wow 10 bytes 😂😂. +1 for the effort though :)
@@dilanboskan2222 Yeah well, it'd be in the application layer too so add that overhead on there aswell.
It pays to know your protocols for sure.
It makes a difference at scale
The problem is that the server then has to store this state, often in a distributed way that involves the server making network requests to get the state, so that if that particular server replica goes down then it can continue, but it really depends on your scenario. If you can keep it in memory and re-send it if you connect to a new server then it could work, at the cost of some server memory.
For HTTP this is basically a session token, or more generally it's just storing state on the server.
Problem with UDP is no flow control, the idea of TCP is it scales - without back-pressure the internet would be probably be well congested, like the Amazon toilets.
QUIC, as a transport protocol, is implemented entirely in user space, which includes all its mechanisms such as flow control, congestion control, selective acknowledgments, and packet loss detection. This is unlike traditional transport protocols like TCP, where these mechanisms are typically implemented within the OS kernel.
@@ScottChenRightsonInteresting, I guess the problem with that is a nefarious program could override those and hog all the bandwidth. Technically you can patch your OS kernel, but that's a little bit more work.
This is great news for anti-censorship too. Most national firewalls (think China, Iran, etc; but several Western countries are on this slippery slope as well) rely on TLS SNI to block blacklisted domains; the reason they can do that is SNI is transferred in plaintext in the TLS protocol. There is the rather new ESNI and the newer ECH, but both are extensions to TLS 1.3 and can be (and are) easily banned wholesale by state actors before they have even taken off.
Doing similar to an entirely new protocol version is going to be significantly more difficult. Still possible of course; and in the worst case scenario some governments will just ban HTTP3 outright, which will lead to even more internet fragmentation than we already have today. Obviously this is not a valid reason against the adoption of any privacy-respecting technology. And frankly speaking, anything that makes the life of those who wish to impose censorship more difficult and miserable is a win in my book.
when he says it like "H-tittie-pee" it sounds like a name of some rapper 😀
UDP is just transport layer, which is connection less nothing to do with state that is done in the application layer(wether it is RTP or quick) same as ACKS's, if needed, in voice there is no retransmission as it would be considered old information.
Does anyone know why it's called `HTTP/3` btw? instead of just `HTTP 3`?
Insert always has been meme.
Any HTTP packet starts with HTTP/version since ever.
This is literally how the protocol calls itself.
People just went with it.
It’s similar to a url path route so that’s the idea?
4:38, "most packets make it so why ack everything" yea, get back to me when you have a network server trying to reach devices over udp and there's a firewall or worse a load balancer that mangles it and everyone thinks it's your devices who's at fault.
and you can only nack what you know should be coming. That might work within this well defined high level protocol but not for a low level protocol like tcp.
If you were a part of the task force, you would make HTMX one of the web standard 😁
This is opinionated. There are downsides to htmx
@@fluffyfetlocks Is it not obvious this is a joke?
Isn`t NAKing a bit worse then ACKing since each packet needs to stay in the buffer in the server for some period of time in case it get`s NAKed? You have a bunch of data, split it into 10 packets, send out each one and then move on to new task and suddenly you get back an info that 'i`m missing packet no. 3, can you resend it?". You need to prep that data once again.
A bit of a simplification, but I find it more helpful to think of quic as acking multiple packets at once. In the negotiation phase, both peers agree how big the respective send buffers can be, and won't send anything more until packets are acknowledged. The receiving peer then occasionally sends an ack for all packets received. It's a balancing act of sending as few acks as possible, but frequently enough to recover from packet loss reasonably. This balance point can shift depending on how reliable the network is moment to moment.
Technically, TCP can do this too, but there are differences. Rfc 9002 goes into more detail.
Same as ACKing, what happens if you don't get the ACK for that packet?
@@LtdJorge actually no, nacking can't work for this situation. Consider that any packet can be lost at any time, including hypothetical "nack" packets. If the connection broke completely, the sender would continue sending packets, none of which reach the destination. The receiver starts sending nacks but they aren't delivered either. Since the sender never received a nack, they Believe everything is fine and continue sending data into the void.
@@Andrew-jh2bnMaybe SACK it?
@@LtdJorge if you don't get an ACK for that packet... you assume the worst and keep the supposedly lost packets on the queue and send them again.
So... worst case you resend messages and keep data which could have been deleted before but it had no way to know.
Compare to NACK... you can never know if the packet arrived... or it didn't arrive, and the NACK also failed to arrive.
Funny enough, first time I heard about HTTP/2 and google trying to make it widely available, the implementation was using QUIC, that's how I heard about it.
H TIDDY P 3
It's all Google... because they were already using it before it was standard.
Well, they created QUIC (and SPDY, which turned into HTTP/2)
8:18 this may actully inhibit the adoption in large organizations cause firewalls won't be able to read it. Ans IT guys don't like that
Most orgs like that already block 90% of the internet on their premises anyway so doubt it will make any difference if they block QUIC too
Organizations that require this much control can install their own root certificates on company devices and proxy traffic. Certainly more expensive to do, but it can be done.
@@Andrew-jh2bn Yes. Eggsachedly. And in general (aka im lazy to write another comment, heres my rambling rant): Who wants to never invest in futureproofing or checking if the actual status quo makes any sense at all? Yeah, right -- those that could and should afford it -- but hey, it all comes down to keep the status-quo alive, because "we have contracts" ... Right, yeah .. So how about engineering in parallel the alternative based solely on QUIC? Yeah but how can we control if it works exactly like our actual system in the end? That is the point. Btw QUIC is a late millenial and if it wasn't for Google it would have been adopted already around 2006, because they are the ones which explicitly forbid the use of this principle, for exactly that reason that it makes it hard to addon/overwrite/replace advertisements or block those already embedded ... or the right to send content preventing synthetic analytics. Yeah, right use humans, sure .. the one and only single point of failure in any type of processing .. Err, yeah, duh, because it allows to let the ACTUAL CONTENT be checked by ACTUAL HUMANS which allows to find/design/create/shape ways of interaction between man and machine that yet have to be explored. BUT BUT BUT, status quo YKNOW, also who wants that new stuff anyway?? Check out ip v3/v5/v6 and especially Ericssons involvement when they tried to modernize so Symbian would allow actual upgrades independent of the hardware (to overcome the problem that at that point (end 90s/early k2s) we had so many competing proprietary protocols on top or in parallel, plus so many different proprietary data transfer protocols and the mobile networks grew exponentially - what most people forget is that tcp was originally designed as being solely a universal packet transceive protocol to connect completely different machines over any type of connection; went well right?), by defining a fast, very compacted and easily manageable and predictable way to "sort things out" - this effort died in 2005; then Android was bought up by Google ... before it was released to the public in 2008, other vendors and distributors tried to find solutions, Vodafone for example based on linux in 2005/2006). Just some food for thought for lovers of walls of text that seemingly make no sense ..
That's a good point! I'll bet most every website will need to support HTTP/2 as a fallback for a long time
10:39 - I really thought he was about to say - "Defence against the Dark Arts"😅
my professor in uni is part of the task force.
he is always talking about congestion control and how messed up the web is.
Does netflix (or twitch or the like) use RTMP?
Hey @ThePrimagen, do you have any idea why there’s no Netflix on Mac, it doesn’t seem to make any sense
AppStore takes 30%
Using you browser to watch Netflix is less costly to Netflix
Big tech has all this fancy stuff, yet RUclips still loads 5x slower than any other website
I seen Dvorak in those random keystrokes
Looking at the early adoption rate of network protocols and interpolating them to the future can be quite misleading.
HTTP/3 are quick to be adopted because it's the large players like Google that comprises a massive amount of web traffic that will adopt them first and they can deploy these new technologies rapidly across their entire network. This makes for a very rapid early adoption, but then you'll get into the long end of the tail where millions of individual developers have to make the choice to adopt the technology.
This is in contrast to other technologies like IPv6, which is harder to adopt for larger companies that has many legacy infrastructure because deploying a new IPv6 requires installing new hardware and because interoperability with existing IPv4 infrastructure isn't always seamless or possible, it's hard to just switch wholesale. This makes for a much slower early adoption rate.
me when i have to learn another node.js api: x_x
The software will be completely protected and the average person will not be able to understand what is being transmitted and where. Is this safety?
What a bizarre issue to have. These are all public specifications, the vast majority of implementations will be open source, and I sincerely doubt that one in a thousand users of the internet understands any of the protocols, let alone that even one in a million users understand *everything* going on.
This is no different to literally anything in computing, or really anything else in the world. Do you refuse to get into a car unless you know exactly how the crumple zones are designed? Or do you simply check if the people that really do understand it say if it's good or not?
H-tity-P 😂
AYO
what is alpine?
With the new rules that dont allow us to use encryption in communication, im not sure we need many of these things.
qpack ? what about tupak?
"XYZ is eating the world" considered harmful
at Netflix btw
UDP: when you don't care if the packets are delivered, TCP: when guaranteed packet delivery is essential
UDP+QUIC: When you only care about the packets that are lost
@@themartdog i had thought htat originally too, but this also means that the application can choose if it wants to request retransmission, for something like streamed video, it may not matter.
The name is TheQUICkyagen
16:20 NATS >>>>>>> *
NATS does MQTT
That thumbail... 😆
Usually you are amazingly correct. Boys, do not learn from this video what TCP is!
Don't worry, nobody wants to snatch precious TCP - keep it, have fun!
@@claudiusraphael9423I do not know how that is a reply to my comment. Nobody said anything about the "preciousness" of TCP. TCP is a protocol, so it cannot be precious. If you are emotionally attached to a specific technology, you have a severe problem.
Also, HTTP/3 does not try to replace TCP. There are a lot of protocols that still run and will run on TCP. There are a few factual mistakes in the video about TCP. So, you can find a specific source if you'd like to learn what TCP is. That was all I wanted to say.
For example, one factual mistake in this video is that Prime says every package must be acknowledged individually in TCP. Not true. TCP uses a sliding window technique. It sends several packages. When package X is acknowledged, all earlier packages have also arrived. It is not essential from the whole video content's point of view, but it is related to the feature of HTTP/3 vs. TCP, which is the most significant feature and was totally missed in this video.
The most significant shortcoming of TCP compared to HTTP/3 comes from the slow start and how this sliding window size increases. It starts with one package, then two, then four, and so on, until the channel loses packages. Imagine having a browser on a local network sitting by the server's side. You can download huge files without package loss, sending 10,000 packages without acknowledgment. Using TCP for the following file, you would start sending just one, then acknowledge, then two, and so on. With HTTP/3, the channel can be flooded immediately based on the information from the previous communication.
Having said that, I also enjoy these videos a lot because they are usually precise and accurate, as much as I can tell. His opinions usually align with mine. He is a senior; you must learn from him, not TCP.
@@PeterVerhas "TCP is a protocol, so it cannot be precious." --- preciosa: following guidance, willing to be ruled in the most precise manner (man machine interface kybernaut - the terminal - TCP is the one that is overprecise, basically relects the era: spygame)
Orchids for example ...
All hail Ache Tittie Pee 3!!
Drinking game: take a shot every time he says etch titty pee
No we DP'ed U!
Beat me to it! Damn!
HtittyP 3 0:34
scala w time but non ironically
When you say it I hear Htittiepee
but still no IPv6 😢
When you read, you sound like Rick Sanchez. Dunno if it's just me who thinks it is.
Great article
U DP? QUIC! IP!
H tittty P.... ok going to start saying that at work
everything I can find online shows JVM slower than Bun...
WHYYYYYYYYY M C A
You down with UDP? Yeah you know me
Army with harmony
gime drop a load on 'em ..
Http is stateless. right ... right...
Scala ftw
Web3, Http 3. Coincidental
No, they sound similar so they must be related! Like how Tor is for Torrents, Java is the base of JavaScript, and Ham comes from Hamsters.
(I am joking plz don't kill me)
@@AlexanderVulpes Bruh. You Brain! Let me throw myself in the dirt - three times a charm, right? Just a minute ...
@@AlexanderVulpes Ham from Hamsters .. that surely is the most brutal food-processing i can casually imagine ..
Offtopic i know, lol.
Wonder how it tastes though.
Nice
I really like QUIC and HTTP/3 :D
HTittyP
talk about Bitcoin
More complexity.
Whhhhhyyyy is hhtp
Yes.
Wtf am i doing here 💀
HTITYP3
H tt pp 3
I've been on the lookout for content like this! Ready to believe in myself! › "Self›belief is your greatest asset."
first
http/3✅
half-life 3❌
web3🤦♀
Maybe valve released HL3,we just didn't receive it.
lol
@@marwan7614 You didn't? Maybe enable QUIC in edge:///flags ...
Haych Tittie Pee 3
Lets Go!