When to use UDP vs TCP in Building a Backend Application?

00:00

What is going on guys? My name is Hussain and I got this question from one of you guys

00:05

When should I use UDP versus TCP to build a brand new

00:13

Back-end application from scratch and

00:17

The first question that comes to mind is like why did you pick only those two?

00:22

Right? It's like saying why are you talking about these two protocols? They are like million protocols out

00:27

There is HTTP. There is HTTP too. There's GRPC. There is XMPP

00:33

Why why only those two?

00:36

Because those two are the building blocks and the fundamentals of

00:41

Everything that comes on top

00:43

So if you understand that you pick UDP over TCP, then you will be okay to pick quick

00:52

Which is on top of UDP or

00:54

HTTP which is on top of TCP or

00:57

GRPC which is on top of HTTP too, which is on top of TCP, right?

01:02

So if you understand how these puppies work

01:05

Then you will understand how these work and as a result and

01:09

Based on that if your

01:11

Application back in application require low latency versus high throughput versus accuracy versus quality

01:19

You will pick the right choice, right?

01:22

It all really depends on what you pick on this

01:27

Down basic fundamentals. That's why I really implore any of you guys if you weren't too back in if you weren't viewing the back and

01:34

Understand how these two puppies work check out this video right here TCP versus UDP

01:39

You don't have to know how the headers look like no

01:42

Let's leave this at the expert network engineer if you're a network engineer. Yes, definitely you need to understand that but

01:48

Yeah, if you're building a new RFC to improve TCP, yeah, you will need to understand how the headers work

01:55

What you need to understand is I'm gonna go quickly over the difference between TCP UDP because I don't have an hour

02:01

I spent an hour talking about the differences

02:04

However, the difference between TCP versus UDP is UDP. You sent a packet and you just forget about it, right?

02:11

The only guarantee that UDP gives you is I

02:14

Can tell you if the packet arrived

02:17

correctly or not if I'm sending the

02:21

Letter a right I can't guarantee that I have sent an a and then I got an a right

02:28

That's it. I'm not gonna retry. I'm not gonna check if you can handle the letter a or not

02:35

I'm not gonna check any of that stuff now

02:37

I'm not gonna do any flow control. I'm gonna need to do any retransmission if it fails

02:41

I don't know if you even get it or not. I'm just as a client. I just send it

02:47

That's it. I don't do anything else. That's UDP, right?

02:51

And that's very very powerful, right? Because it does the job that most engineers want

02:57

Send the dang packet. That's it

03:00

TCP on the other hand

03:03

And it tries to solve the problems up in the UDP, right? And here's is what TCP tries to solve so no first of all

03:12

Let me taste TCP does that. Okay. Well, I'm about to establish a connection. Let me let me say it. Okay

03:18

Send

03:21

Which is the synchronization. Hey, sir. Are you even there? Let me check. Oh, I can't just send stuff

03:27

Let me establish a connection which is something doesn't exist in the UDP. There's no connections, right?

03:32

There's just a bear just send it TCP

03:36

actually

03:37

Creates a physical connection between the two and and and and how it actually

03:42

Reserves some memory on the server side. So this is hey, send

03:46

I am going to start

03:48

My sequence with the within my packets with the number hundred

03:53

All right, and then the server say okay. I acknowledge that

03:57

I mean I received that and then let's start from I'm gonna start from 500 right and then okay

04:03

I acknowledge that so I'm gonna start packet number hundred and one

04:06

And you're gonna start sending you packet number five hundred and one and they keep track of these sequence

04:10

This is a stateful protocol. There is a state on the server

04:14

There's a there's a state on the server that stayed in the client and these state is the sequence of the stinking state

04:19

Sequences and other stuff as well, right?

04:22

So there is first of all that's the first thing TCP and then the first another thing in TCP anything that I send

04:28

I need you to tell me whether you can handle it or not, right?

04:33

Okay, I'm gonna send five bytes. Can you handle five bytes five bytes a little bit low, but can you handle this?

04:38

Well, yeah, I can handle up to 10. Okay

04:42

And we're gonna start playing we're gonna start for playing that that's that's what I call TCP for play or TCP slow start

04:50

Check it right here. I may I may be about

04:53

Where where even when you start the TCP is just don't it doesn't want to send everything that it has

04:59

Says, oh, let me check. There's the server actually can handle this window size that wouldn't that the big thing

05:05

I'm gonna send right if it can't I'm gonna reduce and gonna play so so so so so the TCP start tasting

05:12

So okay, I'm gonna send you just this yes, you do be doesn't care. It'll be just there

05:17

So everything at once. Who cares? That's why some fire was actually blocky to be because of this problem

05:23

So like you're just

05:25

Killing our bandwidth with this, right?

05:28

Another feature is

05:30

acknowledgement, which is the most expensive thing in TCP if I send you a packet

05:35

I need to know that you

05:37

Saw did you grab my packet saw all right and the server actually sends an acknowledgement with the label of the sequence number of that packet

05:46

Telling that server that

05:49

Sure, I I got the packet right so

05:54

It will send back the acknowledgement saying I got it. So that's TCP and you to be an actual took me six minutes to explain

06:00

All right. Hopefully you're still there

06:04

Now you're building a back in app

06:08

You're building a chatting app, right? So you need a server

06:11

And and if you want to what why do you need a server? You might say to build a chatting app

06:17

Well, unless you're building a peer to peer you need some some centralized plays

06:22

Where you're gonna send your message right and then another party will join the same server and then they can exchange

06:30

The messages between them, right?

06:33

So if you're gonna use UDP to build a chatting app

06:37

Then you're in trouble if you get if if you used

06:41

UDP as it's raw protocol as is you might send high and

06:47

You might be lucky and the server receives the high and then

06:51

Finds out who to send it to and then it sends it to the to the actual server to the actual client

06:58

Right, assuming there's a UDP server right here

07:01

Then the client might get you might give the actual message correctly if we're lucky

07:07

Or a bit or two might have flipped and you're gonna get a completely different message, right?

07:13

Or I'm assuming you're gonna do some encryption if you do an encryption then you have to do another thing

07:18

Right if you're gonna flip and then it cannot even be decrypted

07:22

Right if the bit flip the cipher bit is flip then you will not get that message at all

07:28

So UDP with chatting app is not really great because you need those

07:34

Guarantees, right?

07:37

However, do you need all those guarantees? Do you need TCP to build a chat app?

07:42

Well, yeah, do I need a flow control?

07:44

I don't need that flow control because I'm gonna send small messages anyway, right?

07:49

So I can I don't need a TCP flow control. I need doing an acknowledgement

07:56

Now really, I can build these features on top of UDP, right?

08:02

And here is where you as a back-end engineer can think about this. It's like okay

08:08

Can I is it worth it to use TCP and get these acknowledgements and flow control for free, right?

08:14

Finebilling a chat application. Yeah, it's actually worth it because if I'm gonna send this these bytes these packets the chatting

08:23

Usually it's very small

08:26

Packets, right and if I send it

08:28

It's okay, right? I can use TCP because I'm gonna get an acknowledgement. I'm okay. I have to wait for a

08:34

Mobile a little bit of a time. That's it. All right, and I have to add a technology man. Chatting is okay

08:40

I'm gonna send a message. I'm gonna wait. That's okay. I'm expecting to wait

08:45

Right

08:47

So that's so using TCP to build a chatting app is okay. Now when I say TCP

08:53

Feel free to use web sockets which is on top of HTTP which is on top of TCP. That's absolutely fine

08:59

Use pure HTTP if you want you don't want

09:02

By directional that is absolutely fine. You can you can use that and pull at the other client just pulls

09:08

Hey, I'll use long polling which we talked about right so you can use web sockets

09:12

You can use her which is all on top of TCP which has this ability to

09:18

To send a message and then wait for acknowledgement

09:20

Right if you're okay with that, which you should be building a chatting app. That's not big

09:27

Building a game however on the other end if I am

09:33

Building a game multiplier game between two parties. You can still use TCP and

09:39

Obsock it on HTTP however

09:43

Be

09:45

Be sure that there will be some lags

09:49

Right

09:50

Because those lags are because of the expense of the acknowledgement or because of the expense of the flow control and other stuff as well

09:59

Right, so if you don't

10:02

If you use TCP and you're playing a game where it has a very fast pace remember

10:07

I'm a press up. I'm better move up. I press down. I better move down and this

10:12

input should be sent to the other client and that

10:17

Input should be applied to my character on the other client machine so that it can it can do that

10:22

So if I send if there is a TCP connection between you and the server so there is an acknowledgement there

10:28

So the server receives it and then you wait for an acknowledgement and the server that immediately turns around and finds

10:35

What other client to send it to and then sends that

10:39

Packet to the client right to the other client assuming there is a t's existing TCP connection between this

10:47

The client this other client and the server and this other and this client and the server

10:52

So there is a TCP engine you can use that right and people do that right?

10:57

Whoever there is there is the problem of

11:01

Of having this delay this acknowledgement

11:05

Right and if you

11:07

Especially if you have high bandwidth game where you essentially

11:12

Transfer the state the whole state from the server to the client which is the other

11:20

Flip of the coin

11:22

Then you might actually express huge

11:26

Details right if you imagine you're sending

11:30

Let's say that you

11:33

Shot

11:34

Building right this is the act right so

11:38

The input of you shooting a building

11:41

Comes to the server right and then server say okay. I shot the cannon at the building and then a building

11:50

Exploded here

11:52

The act the state that the building is now exploded should be

11:57

Transferred to all clients right because you don't know that you actually

12:02

Aimed at the building and you nailed it right so the act of

12:05

Transfering the state back to the clients

12:10

Need to be pushed down so you will say oh now the client just sent that information right

12:18

client a

12:20

Hit pointed the cannon at a 90 degree on this building and then the building actually got hit and now the building state is now destroyed

12:29

Right and and and some other debris hit the other building and now the the other building is now

12:36

Also partially destroyed so all the state should be transferred back to

12:41

To this to the client and this could be huge

12:45

Big state and this is called the server authoritative model where the server is

12:50

The one who decides

12:53

What is the current state in every single world right so like oh we did there and this client?

13:00

Z already moved that way right all these changes or everything that state changes

13:05

It's pushed and this is huge so using UDP in that case

13:10

could

13:12

Eliminate that latency with the acknowledgement the TC but however it's very very very hard to get right

13:19

Because UDP is as

13:21

Lucy, right? It's a little lossy

13:24

Lossy. It's lossy. So now you really think about that and says okay

13:29

Can I if I use this then can I afford losing some packet some data?

13:37

It really depends the state changes on if the state if you can

13:41

If you get the state correctly then you're good, but if you get the state corrupted

13:47

Can you do something on the client's side to repair it?

13:52

At the application level so you can you write your back end or the client in a way to repair

14:00

those packets so that it's

14:03

I can I can get advantage of the UDP protocol because it's fast and

14:08

Doesn't have all this get entities, but it can also

14:13

Give me the content and then I can repair it somehow or maybe ask to retransmit that information, right?

14:22

That's why a lot of people use

14:24

For these kind of gaming. They use just TCP because it's it's really a headache to build a UDP

14:30

Protocol on top of UDP, right? So using TCP versus UDP is very very interesting guys on your back and app, right?

14:37

So if you if you want these guarantees

14:39

Right then use TCP

14:42

Right if you don't really need those guarantees those three transmission for control

14:48

That stuff then use UDP and you get the benefits of highlighting seeing that ability to get that but be prepared that the data might arrive

14:56

Corrupted so either try to repair it if you can or just ask to retransmit it right so that if you can't afford UDP

15:06

BQDP with the video transmission for example. It's just perfect like video

15:11

Images transfer something that you are okay with it getting corrupted

15:17

Or if you got corrupted you try to repair it with a little bit of minimum effort

15:24

At the application level if you can do that UDP is that if you can't then TCP is the answer

15:29

Even with TCP we had a problem with HTTP, right guys with HTTP

15:35

What was the problem with HTTP that

15:38

TCP was was not good enough for us. Yeah, here's the thing with HTTP guys building a browser

15:46

And web app

15:47

TCP was definitely the solution because I need all this transmission

15:51

But TCP was doing me way too much for us

15:56

That we don't really need

15:59

This

16:00

Level of thing with HTTP too specifically, right?

16:03

Well, it should be too. Yeah, I need you to retransmit the packets

16:07

However with HTTP to we have this idea of streams, right?

16:12

The packets are packaged into its own

16:15

applicable layer 7 packet that has

16:19

an id called stream ID or say okay. I'm sending a good request

16:23

Tag it with stream number 7

16:26

Number 7 right and then

16:28

Send that and I'm gonna send

16:31

A post request tag it with

16:33

stream ID number 8. I'm gonna send another post request

16:37

stream ID 9 so you can send three requests at the same time

16:41

However

16:43

Through the TCP layer

16:45

This is just data. This is just garbage data. It doesn't know that. Oh, this is stream one

16:50

This is stream is stream 7. This is three minutes. There is no. No, it doesn't all have stuff

16:54

It knows that this is packet. This is packet. This is packet. This is packet. This is packet

16:57

These are packets and guess what if

17:01

stream 9

17:04

Packets received successfully, but stream 8 and 7 was not for some reason

17:12

The server will actually pause and say

17:16

Hey, I received this packet, but the sequence because they are labeled with the sequences, right?

17:21

This I don't receive this or this. I'm gonna wait for you to send all this stuff because

17:27

Oh, I receive back packet. Let us say packet number 9 is like stream number 9 is actually packet

17:34

100 right and then there's I receive 100, but I don't receive

17:38

90

17:39

99 and 90

17:41

98 or anything above that so there must be some packets. I'm gonna wait

17:47

That's the biggest problem with TCP when it comes to HTTP too because guess what?

17:52

This is an independent request. Why the heck are you waiting?

17:56

Why the heck are you waiting? We already sent that request process request number 9

18:04

Which is stream number 9 process it alone. Leave it alone. So that that's the major problem with TCP, right?

18:11

So we we just say we say wow, okay, we cannot

18:18

Use TCP. We need those guarantees, but they are very harsh at the packet level

18:24

We need the same guarantees, but at the stream level. So if a packet didn't receive here

18:30

Resend it, but if a packet didn't these are isolated these stream and this stream

18:35

This is they are always late it, right? That's why we built quick so that we told key dp

18:39

Which doesn't have any of the guarantee and we built this streams idea on top of UDP and that where

18:49

That's where people thought it's like should I use UDP versus I should I use TCP, right?

18:53

So yeah, if you're building a low level protocol and you don't need streams

18:58

You don't have the idea of channels

19:00

Anything that TCP and and you're using raw TCP. It's probably most of the time. It's a solution for you

19:07

Unless you don't care if your data got corrupted at the end. All right guys very long video to talk about that

19:14

I know it's it's not a straight answer definitely

19:18

But it really depends on your app and that's just what I think right UDP in general

19:24

You can use UDP if you can afford to repair the packet at this destination

19:30

Or you can afford to be corrupted or

19:33

It's okay if it's got lost right because I can somehow construct the content from what I have

19:40

That's the video because the video if you lose some bites. That's okay. You're getting a little bit fuzzy, but it's okay

19:46

Right, but with the with the image same thing maybe not all of images some images for you lose something you're done, right?

19:54

So yeah

19:55

versus TCP if you want to these guarantees again at that raw

19:59

Level then use it

20:01

But if you're building your top of the TCP you're using the TCP connection you're doing so much with it

20:07

Then probably you need something like quick

20:10

right or use UDP and try to do that right if you're using just raw TCP

20:17

Beautiful most of the time works guys nothing wrong with TCP. TCP is great. All right, so

20:23

What is what are you gonna working on guys? What back in application? You're building what protocol did you choose?

20:28

Let me know in the chat in the comment section below. I'm gonna see on the next one you guys a little bit

20:32

Bye


Description

In this video, Hussain covers the basics of UDP and TCP protocols and how they are used in backend development. He explains that UDP is a connectionless protocol that provides lower latency but less reliability, while TCP is a connection-oriented protocol that provides higher reliability but higher latency. Hussain also discusses when to use each protocol based on the application's requirements. He emphasizes that understanding the fundamentals of these protocols is essential for choosing the right one for your application. The video covers topics such as HTTP, GRPC, and XMPP, and how they are built on top of UDP or TCP. Hussain encourages viewers to understand how these protocols work and choose the right one based on their application's requirements.