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.

@Dekharen

8 ай бұрын

Hands in the air, this variable is called "a" !

@VivekYadav-ds8oz

8 ай бұрын

This should be a real thing. All the Microsoft engineers sweating rn

@efkastner

8 ай бұрын

And in reality it’s mostly being involved in multiple years-long arguments over text

@someoneelse5005

8 ай бұрын

sooo you mean... all premises?

@RedHatTurtle

8 ай бұрын

IETF, OPEN UP!

UDP = launch missles, TCP = Did the missiles launch?

@andrews8733

8 ай бұрын

ACK armageddon

@darukutsu

8 ай бұрын

I didn't get the missiles. Pls launch again!

@canoozie

8 ай бұрын

@@darukutsu Here are your missles (for the second time), please confirm receipt.

@subvind

8 ай бұрын

@@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.

@AlexanderVulpes

8 ай бұрын

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."

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.

@theodorealenas3171

8 ай бұрын

I never understood why TCP wanted to drop arrived packets. It's so weird that it took so long, but there must be reasons

@Asto508

8 ай бұрын

@@theodorealenas3171 Yes, finite buffers

@PeterVerhas

8 ай бұрын

@@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.

@I_am_DD

7 ай бұрын

​@@theodorealenas3171Maybe it is because hard disks are written sequentially?

@theodorealenas3171

7 ай бұрын

@@I_am_DD interesting, are the packets aren't THAT big? Was it a big deal to cache potential misses back then?

Pour one out for all the old network admins having flashbacks to the Doom days when their firewall alerts for KZread causing a UDP flood attack warning.

Guys, I have a joke about UDP for you! I'm afraid you won't get it though...

@ThePrimeTimeagen

8 ай бұрын

nack

@voicevy3210

8 ай бұрын

better than tcp, if it doesn't go through i wont leave you

@ybvb

8 ай бұрын

Our nephew wished a Switch for Christmas, I don't understand why he doesn't like the Nexus we got him.

@LtdJorge

8 ай бұрын

​@@ybvb was it a 7000 series?

@theodorealenas3171

8 ай бұрын

Took me a few seconds. I should revise

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.

Thanks for explaining HTitty3 protocol

At this rate Hyper Text Transfer Protocol version will overtake Internet Protocol version.

Open up! Htittyp task force

@LordFokas

8 ай бұрын

Age Titty Pee

@jaideepshekhar4621

8 ай бұрын

LMAO!

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...

@brunoais

7 ай бұрын

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

6 ай бұрын

@@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

@brunoais

6 ай бұрын

@@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.

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.

@ScottChenRightson

7 ай бұрын

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.

@gravisan

7 ай бұрын

@@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.

H TIDDY P 3

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.

@LtdJorge

8 ай бұрын

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..

@dilanboskan2222

8 ай бұрын

Wow 10 bytes 😂😂. +1 for the effort though :)

@gustavbw

8 ай бұрын

@@dilanboskan2222 Yeah well, it'd be in the application layer too so add that overhead on there aswell.

@Satook

8 ай бұрын

It pays to know your protocols for sure.

@fluffyfetlocks

8 ай бұрын

It makes a difference at scale

@georgehelyar

8 ай бұрын

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.

If you were a part of the task force, you would make HTMX one of the web standard 😁

@fluffyfetlocks

8 ай бұрын

This is opinionated. There are downsides to htmx

@IbrahimAlshekh

8 ай бұрын

@@fluffyfetlocks Is it not obvious this is a joke?

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.

@indiesigi7807

8 ай бұрын

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.

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.

when he says it like "H-tittie-pee" it sounds like a name of some rapper 😀

It's all Google... because they were already using it before it was standard.

@LtdJorge

8 ай бұрын

Well, they created QUIC (and SPDY, which turned into HTTP/2)

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.

I seen Dvorak in those random keystrokes

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.

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.

Does anyone know why it's called `HTTP/3` btw? instead of just `HTTP 3`?

@LordFokas

8 ай бұрын

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.

@n_x1891

8 ай бұрын

It’s similar to a url path route so that’s the idea?

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.

@Andrew-jh2bn

8 ай бұрын

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

8 ай бұрын

Same as ACKing, what happens if you don't get the ACK for that packet?

@Andrew-jh2bn

8 ай бұрын

@@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.

@claudiusraphael9423

8 ай бұрын

@@Andrew-jh2bnMaybe SACK it?

@matheusjahnke8643

8 ай бұрын

​@@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.

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

@airkami

13 күн бұрын

AppStore takes 30% Using you browser to watch Netflix is less costly to Netflix

Big tech has all this fancy stuff, yet KZread still loads 5x slower than any other website

With the new rules that dont allow us to use encryption in communication, im not sure we need many of these things.

me when i have to learn another node.js api: x_x

it's not TCP in UDP, it's reliable UDP, so it's only nak'd at the endpoint, rather than between every routing device through the whole network path. It's been ridiculous when implementing reliable UDP is trivial.

@claudiusraphael9423

8 ай бұрын

Where would have been the fun in just establishing universal packet-transfer on a universal network-appliance-protocol. Oh oh, we are lagging, oh oh TOO MUCH .. OUCH ... we LACK, let's SACK. BACK. Boom! TCP gone as the provider of cyclopsees walled-garden attempt successfully driven for half a century until even "they" realize it might be worth saving unnecessary procedures, therefore POWER, therefore FUEL, therefore MONEY along the way ... End of story. Or so .. our children will reminisce the gen. X-mess, when it is 2038. (

@Draggeta

8 ай бұрын

Routers are L3 devices and don't look at TCP at all (same with other lower layer devices). Of course they may have L4 functionality such as firewalling which do interact with TCP or UDP. TCP is only between the two endpoints (where endpoint could be client, server, proxy, etc.). Prime is correct in that QUIC is like, but not actually equal to, TCP in UDP.

at Netflix btw

"XYZ is eating the world" considered harmful

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

@themartdog

8 ай бұрын

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

@Andrew-jh2bn

8 ай бұрын

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.

@claudiusraphael9423

8 ай бұрын

@@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 ..

@AlexanderVulpes

8 ай бұрын

That's a good point! I'll bet most every website will need to support HTTP/2 as a fallback for a long time

The name is TheQUICkyagen

H-tity-P 😂

@susbedoo

8 ай бұрын

AYO

That thumbail... 😆

qpack ? what about tupak?

what is alpine?

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?

@SimonBuchanNz

8 ай бұрын

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?

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.

All hail Ache Tittie Pee 3!!

scala w time but non ironically

When you say it I hear Htittiepee

U DP? QUIC! IP!

WHYYYYYYYYY M C A

UDP: when you don't care if the packets are delivered, TCP: when guaranteed packet delivery is essential

@themartdog

8 ай бұрын

UDP+QUIC: When you only care about the packets that are lost

@_FFFFFF_

7 ай бұрын

@@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.

No we DP'ed U!

@thebluriam

8 ай бұрын

Beat me to it! Damn!

When you read, you sound like Rick Sanchez. Dunno if it's just me who thinks it is.

Drinking game: take a shot every time he says etch titty pee

You down with UDP? Yeah you know me

@claudiusraphael9423

8 ай бұрын

Army with harmony gime drop a load on 'em ..

16:20 NATS >>>>>>> *

@LtdJorge

8 ай бұрын

NATS does MQTT

H tittty P.... ok going to start saying that at work

Great article

HtittyP 3 0:34

Nice

Scala ftw

I really like QUIC and HTTP/3 :D

Web3, Http 3. Coincidental

@AlexanderVulpes

8 ай бұрын

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)

@claudiusraphael9423

8 ай бұрын

@@AlexanderVulpes Bruh. You Brain! Let me throw myself in the dirt - three times a charm, right? Just a minute ...

@claudiusraphael9423

8 ай бұрын

​@@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.

HTittyP

talk about Bitcoin

Http is stateless. right ... right...

More complexity.

Usually you are amazingly correct. Boys, do not learn from this video what TCP is!

@claudiusraphael9423

8 ай бұрын

Don't worry, nobody wants to snatch precious TCP - keep it, have fun!

@PeterVerhas

8 ай бұрын

​@@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.

@claudiusraphael9423

8 ай бұрын

@@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)

@claudiusraphael9423

8 ай бұрын

Orchids for example ...

HTITYP3

Whhhhhyyyy is hhtp

@claudiusraphael9423

8 ай бұрын

Yes.

Wtf am i doing here 💀

H tt pp 3

first

I've been on the lookout for content like this! Ready to believe in myself! › "Self›belief is your greatest asset."

http/3✅ half-life 3❌ web3🤦‍♀

@marwan7614

8 ай бұрын

Maybe valve released HL3,we just didn't receive it.

@SandraWantsCoke

8 ай бұрын

lol

@claudiusraphael9423

8 ай бұрын

@@marwan7614 You didn't? Maybe enable QUIC in edge:///flags ...

Haych Tittie Pee 3 Lets Go!