WEBVTT 0:00:02.900000 --> 0:00:08.120000 Hello and welcome to this video titled an overview of UDP. 0:00:08.120000 --> 0:00:11.260000 In this video I'm going to cover an introduction to UDP. 0:00:11.260000 --> 0:00:14.000000 What is it? What benefits does it do for us? 0:00:14.000000 --> 0:00:15.780000 Why do we need it? 0:00:15.780000 --> 0:00:18.200000 We're going to talk about something called transport layer port numbers 0:00:18.200000 --> 0:00:24.900000 and how those port numbers work in a session of UDP. 0:00:24.900000 --> 0:00:27.020000 So let's start with UDP. 0:00:27.020000 --> 0:00:30.320000 UDP stands for the user datagram protocol. 0:00:30.320000 --> 0:00:32.120000 Now, why do we need it? 0:00:32.120000 --> 0:00:34.320000 Let's back up here for a second. 0:00:34.320000 --> 0:00:38.520000 All right, so in order to explain this, I want to show you something amazing. 0:00:38.520000 --> 0:00:39.880000 You ready for this? 0:00:39.880000 --> 0:00:43.340000 Look at that. Wow, three tabs of Google. 0:00:43.340000 --> 0:00:45.720000 I bet you've never seen that before. 0:00:45.720000 --> 0:00:49.180000 Okay, but there's a reason why I'm showing this to you. 0:00:49.180000 --> 0:00:53.740000 So, if you've learned anything about IP addresses and forget about IP 0:00:53.740000 --> 0:00:57.460000 addresses, let's just say IP, the internet protocol. 0:00:57.460000 --> 0:01:04.260000 So imagine for a moment that this tab right here was going to send a packet 0:01:04.260000 --> 0:01:09.660000 to Google. All right, now I don't know necessarily what address that is. 0:01:09.660000 --> 0:01:10.900000 Let's just make it up. 0:01:10.900000 --> 0:01:16.480000 Let's say the destination is 8.8.8.8. 0:01:16.480000 --> 0:01:22.420000 Now, in the IP header, one of the fields in the IP header was called the 0:01:22.420000 --> 0:01:27.120000 protocol field. The protocol field. 0:01:27.120000 --> 0:01:34.440000 And that field carries some number to indicate what IP version 4 is carrying. 0:01:34.440000 --> 0:01:38.040000 What kind of data is IP version 4 carrying? 0:01:38.040000 --> 0:01:41.480000 Now, let's say, now this is not the way it works, but let's say the protocol 0:01:41.480000 --> 0:01:45.680000 field said, oh, I'm carrying a HTTP. 0:01:45.680000 --> 0:01:48.460000 This is from a web browser. 0:01:48.460000 --> 0:01:53.400000 Okay, so remember, it's coming from this tab right here in Google. 0:01:53.400000 --> 0:01:57.840000 And let's say in that tab, I'm searching on the word cat. 0:01:57.840000 --> 0:02:01.380000 All right, sorry for all you cat haters out there, but let's say I'm searching 0:02:01.380000 --> 0:02:07.000000 on cat. All right, well, and this is coming from me. 0:02:07.000000 --> 0:02:11.340000 Maybe I am 50.1.1.1. 0:02:11.340000 --> 0:02:13.520000 All right, that's my source. 0:02:13.520000 --> 0:02:15.440000 Well here's the big question. 0:02:15.440000 --> 0:02:17.440000 All right, that gets to Google. 0:02:17.440000 --> 0:02:21.160000 That gets to some web server located 8.8.8.8. 0:02:21.160000 --> 0:02:23.340000 And that server is running HTTP. 0:02:23.340000 --> 0:02:25.040000 So it says, oh, okay, this is HTTP. 0:02:25.040000 --> 0:02:30.740000 So it strips off the IP header, sees my lookup request saying, hey, Google, 0:02:30.740000 --> 0:02:33.580000 show me all web pages that have anything to do with cat. 0:02:33.580000 --> 0:02:35.900000 And then it sends me response back. 0:02:35.900000 --> 0:02:38.080000 All right, here comes the response. 0:02:38.080000 --> 0:02:40.400000 Now the response is coming back to me. 0:02:40.400000 --> 0:02:44.000000 It's going back to 50.1.1.1. 0:02:44.000000 --> 0:02:50.140000 And in the IP protocol field, now remember, this is not the way it works. 0:02:50.140000 --> 0:02:52.620000 I'm showing you why we need UDP. 0:02:52.620000 --> 0:02:55.840000 The IP protocol field says HTTP. 0:02:55.840000 --> 0:02:58.700000 Uh oh, we got a problem here. 0:02:58.700000 --> 0:03:03.660000 Because aren't I running three tabs of HTTP? 0:03:03.660000 --> 0:03:08.800000 How is my web browser going to know that the cat responses are supposed 0:03:08.800000 --> 0:03:13.620000 to go here, as opposed to here, or here? 0:03:13.620000 --> 0:03:18.660000 Well, if all we had was the IP header, we couldn't answer that question. 0:03:18.660000 --> 0:03:20.820000 There's no way to answer that. 0:03:20.820000 --> 0:03:28.840000 So what we need is we need something that, yeah, here's my, let's do this. 0:03:28.840000 --> 0:03:30.300000 Here's my IP header. 0:03:30.300000 --> 0:03:33.120000 So let's say once again, let's do this tab this time. 0:03:33.120000 --> 0:03:37.600000 So I type in cat into the search field. 0:03:37.600000 --> 0:03:44.020000 All right, so the source here is going to be from me. 0:03:44.020000 --> 0:03:46.980000 Let's just assume I'm 51.1.1. 0:03:46.980000 --> 0:03:50.620000 The destination is going to be Google. 0:03:50.620000 --> 0:03:53.400000 Once again, we're just making up an address here. 0:03:53.400000 --> 0:03:58.120000 All right. And there's going to be a protocol field here. 0:03:58.120000 --> 0:04:00.920000 Let's just leave that alone for just a moment. 0:04:00.920000 --> 0:04:06.780000 So now what we need is we need another header behind this. 0:04:06.780000 --> 0:04:10.780000 A header that has two unique numbers. 0:04:10.780000 --> 0:04:15.340000 One unique number says, hey, Google, destination, I'm talking to you. 0:04:15.340000 --> 0:04:17.820000 I'm talking to HTTP. 0:04:17.820000 --> 0:04:20.840000 I'm talking to your HTTP process because who knows? 0:04:20.840000 --> 0:04:25.940000 Maybe 888 is running other types of applications above and beyond HTTP. 0:04:25.940000 --> 0:04:28.460000 So HTTP is what I need to talk to. 0:04:28.460000 --> 0:04:36.460000 And we need, as far as source here, why don't we have this tab come up 0:04:36.460000 --> 0:04:40.520000 with a unique random number like 7,000? 0:04:40.520000 --> 0:04:44.980000 And anything that's generated from this tab is a different random number. 0:04:44.980000 --> 0:04:47.380000 Let's say that's 8100. 0:04:47.380000 --> 0:04:53.520000 And this tab here, anything, any search I do on there is 9400. 0:04:53.520000 --> 0:04:58.020000 So if my search is being generated from this tab right here, I'll put 0:04:58.020000 --> 0:05:00.200000 that in this field. 0:05:00.200000 --> 0:05:05.320000 So we need another header here. 0:05:05.320000 --> 0:05:10.600000 And this is where TCP and UDP come into play. 0:05:10.600000 --> 0:05:14.760000 TCP and UDP, now I know this video specifically about UDP, but one thing 0:05:14.760000 --> 0:05:18.040000 they both have in common is they now say, hey, look, if you're running 0:05:18.040000 --> 0:05:24.920000 multiple instances of the exact same HTTP in this case, we'll be able 0:05:24.920000 --> 0:05:29.220000 to create unique session numbers for each one. 0:05:29.220000 --> 0:05:34.420000 Our header, because IP header can't do this for you, our layer four header, 0:05:34.420000 --> 0:05:39.100000 our TCP or UDP header, will give you unique port numbers that you can 0:05:39.100000 --> 0:05:40.280000 use to differentiate. 0:05:40.280000 --> 0:05:45.880000 So now when the reply comes back, the reply will say, hey, destination, 0:05:45.880000 --> 0:05:48.620000 I'm talking to you 50.1.1.1. 0:05:48.620000 --> 0:05:50.500000 This is coming from me, from Google. 0:05:50.500000 --> 0:05:53.060000 I'm giving you back what you wanted. 0:05:53.060000 --> 0:05:59.340000 Oh, and in that layer four header, the destination is 7,000. 0:05:59.340000 --> 0:06:08.300000 Now this tab will know to generate the response in order to show me what 0:06:08.300000 --> 0:06:10.380000 Google is telling me. 0:06:10.380000 --> 0:06:15.920000 So that's why we need a header after the IP header to be able to differentiate 0:06:15.920000 --> 0:06:19.080000 different sessions. 0:06:19.080000 --> 0:06:24.980000 Now, let's go specifically to UDP and see how UDP handles this. 0:06:24.980000 --> 0:06:28.620000 So UDP is the user datagram protocol. 0:06:28.620000 --> 0:06:34.580000 This gives us a header after the IP header that basically all the UDP 0:06:34.580000 --> 0:06:38.940000 header does is give us those source and destination port numbers that 0:06:38.940000 --> 0:06:42.680000 we'll talk more about here in just a moment. 0:06:42.680000 --> 0:06:47.080000 So this is documented in RFC 768 if you want to go into the details of 0:06:47.080000 --> 0:06:52.900000 that. Now UDP, just like its big brother, IP is connectionless. 0:06:52.900000 --> 0:06:57.260000 Once again, meaning that IP and UDP, one thing they have in common is 0:06:57.260000 --> 0:07:00.820000 when you use the services of those protocols, there's nothing in there 0:07:00.820000 --> 0:07:06.160000 to dictate whether the destination you're trying to reach is alive or 0:07:06.160000 --> 0:07:10.080000 if he is alive, if he wants to talk to you, if he's running the same application 0:07:10.080000 --> 0:07:15.300000 that you are, when you send data to him, did he actually get it or not? 0:07:15.300000 --> 0:07:19.780000 In a connectionless protocol, we don't get answers those questions. 0:07:19.780000 --> 0:07:23.820000 A protocol that is connectionless says, hey look, I'll take your data, 0:07:23.820000 --> 0:07:27.380000 I'll stick a header on it that's appropriate for putting it into the network. 0:07:27.380000 --> 0:07:29.940000 After that, my job is done. 0:07:29.940000 --> 0:07:33.280000 I don't care if it got there or not, I did my job to just send it out 0:07:33.280000 --> 0:07:37.900000 on its way. UDP is connectionless. 0:07:37.900000 --> 0:07:43.800000 The UDP header, as I mentioned, is placed right after the IP header. 0:07:43.800000 --> 0:07:50.600000 Here is our, if we just sort of imagine this, this might be our Ethernet 0:07:50.600000 --> 0:07:56.800000 headers, if we're running on Ethernet at layer two, this might be our 0:07:56.800000 --> 0:08:03.600000 IP header. Now, in the IP header, we had the protocol field and the protocol 0:08:03.600000 --> 0:08:08.000000 field is going to have a number that's going to indicate it's carrying 0:08:08.000000 --> 0:08:13.200000 UDP, which is going to be the number 17. 0:08:13.200000 --> 0:08:19.880000 IP protocol value 17 says, what comes next is a UDP header. 0:08:19.880000 --> 0:08:21.240000 What's in the UDP header? 0:08:21.240000 --> 0:08:26.080000 What comes after the IP header, in this case, if we're talking UDP, is 0:08:26.080000 --> 0:08:28.560000 the source port. 0:08:28.560000 --> 0:08:32.000000 Like in my example, this would be a random source port number that my 0:08:32.000000 --> 0:08:38.040000 particular tab of my browser created for its own session, a destination 0:08:38.040000 --> 0:08:43.760000 port number, and we'll talk more about that in just one second, the length 0:08:43.760000 --> 0:08:50.700000 of the header plus the data, a UDP checksum, and then the payload. 0:08:50.700000 --> 0:08:55.320000 The payload in this case would be HTTP, whatever my HTTP request or my 0:08:55.320000 --> 0:08:57.740000 HTTP response happens to be. 0:08:57.740000 --> 0:09:04.000000 So you see UDP, really all we're getting out of it as useful fields are 0:09:04.000000 --> 0:09:08.560000 the source and destination port numbers, which enables us to track unique 0:09:08.560000 --> 0:09:13.040000 sessions of the exact same application that's running simultaneously on 0:09:13.040000 --> 0:09:18.180000 our computer. All right, so let's dig a little bit more into those port 0:09:18.180000 --> 0:09:22.960000 numbers and see how they work. 0:09:22.960000 --> 0:09:27.820000 So TCP and UDP both utilize port numbers. 0:09:27.820000 --> 0:09:30.600000 So these are logical entities. 0:09:30.600000 --> 0:09:32.880000 In other words, they come and they go. 0:09:32.880000 --> 0:09:37.720000 If I shut down a particular tab of my browser, whatever port number was 0:09:37.720000 --> 0:09:42.100000 associated with that tab is now going to be released and not used anymore. 0:09:42.100000 --> 0:09:46.980000 Now maybe some other application could use that same port number. 0:09:46.980000 --> 0:09:51.840000 So it's used by end system applications to bind their transport sessions. 0:09:51.840000 --> 0:09:56.860000 Every TCP, UDP segment or datagram has a combination of a source port 0:09:56.860000 --> 0:09:59.940000 number and a destination. 0:09:59.940000 --> 0:10:02.340000 And we'll see how that works here in just a second. 0:10:02.340000 --> 0:10:08.760000 Now from your laptop's perspective, from your tablet or smartphones perspective, 0:10:08.760000 --> 0:10:13.840000 when it's creating a packet because you're browsing the web or you're 0:10:13.840000 --> 0:10:17.040000 trying to reach out to some instant messaging service or something like 0:10:17.040000 --> 0:10:22.600000 that, the destination port number will be a well known registered port 0:10:22.600000 --> 0:10:25.160000 number for that particular service. 0:10:25.160000 --> 0:10:30.520000 For example, there's a well known port number for HTTP web browsing. 0:10:30.520000 --> 0:10:34.580000 There's another well known port number for email and all sorts of other 0:10:34.580000 --> 0:10:40.000000 stuff. The source port number will typically be something that's randomly 0:10:40.000000 --> 0:10:44.500000 derived. Now these two bullet points here, once again, are specifically 0:10:44.500000 --> 0:10:49.660000 from the reference point of the host, the laptop or PC that's generating 0:10:49.660000 --> 0:10:52.940000 a request going to a server. 0:10:52.940000 --> 0:10:58.020000 So as far as port numbers are concerned, the internet assigned numbers 0:10:58.020000 --> 0:11:02.180000 authority has to divide them into three distinct ranges. 0:11:02.180000 --> 0:11:07.120000 Ports 0 through 1023 are used for common well known services. 0:11:07.120000 --> 0:11:14.240000 1023, 1024 through 49,151 are what's called registered ports. 0:11:14.240000 --> 0:11:19.420000 And then everything above and beyond that are random dynamic ports, what 0:11:19.420000 --> 0:11:21.640000 we sometimes call ephemeral ports. 0:11:21.640000 --> 0:11:24.980000 All right, let's actually see how this works. 0:11:24.980000 --> 0:11:27.180000 How port numbers work. 0:11:27.180000 --> 0:11:29.020000 Step number one. 0:11:29.020000 --> 0:11:35.620000 So we've got a server on the right and a laptop on the left. 0:11:35.620000 --> 0:11:39.680000 So step number one is somebody's going to get on that server at 10222 0:11:39.680000 --> 0:11:43.820000 and start up some service like maybe a web browsing service or a telnet 0:11:43.820000 --> 0:11:50.620000 service. So whatever they service, they start up that service, that application 0:11:50.620000 --> 0:11:54.320000 is going to bind to a well known port number. 0:11:54.320000 --> 0:11:57.840000 So let's say that we want that server on the right to be a telnet server. 0:11:57.840000 --> 0:12:01.260000 We want people to be able to log into it and then actually issue commands 0:12:01.260000 --> 0:12:04.420000 on it and get responses back. 0:12:04.420000 --> 0:12:08.480000 Well telnet has a well known port number of 23. 0:12:08.480000 --> 0:12:12.500000 So now that server is going to say, okay, I'm now listening on that port 0:12:12.500000 --> 0:12:17.560000 number. If somebody sends me a request and the request is going to 23, 0:12:17.560000 --> 0:12:18.960000 I can respond to that. 0:12:18.960000 --> 0:12:22.420000 Now if somebody sends him a request and the destination is port number 0:12:22.420000 --> 0:12:27.500000 1006, he'll say, well, I don't know what that application is, whatever 0:12:27.500000 --> 0:12:29.080000 it is, I'm not running that. 0:12:29.080000 --> 0:12:30.440000 I'm not listening to it. 0:12:30.440000 --> 0:12:34.420000 But he is listening to 23 because that's a well known port number that's 0:12:34.420000 --> 0:12:37.900000 in that well known space that's reserved for telnet. 0:12:37.900000 --> 0:12:43.720000 Okay. Now the laptop comes along and says, hey, I actually want to initiate 0:12:43.720000 --> 0:12:45.180000 a telnet session. 0:12:45.180000 --> 0:12:47.200000 Okay. So he says, all right. 0:12:47.200000 --> 0:12:50.380000 Well, if I want telnet session, I need to be able to track that because 0:12:50.380000 --> 0:12:53.340000 maybe I have more than one telnet session. 0:12:53.340000 --> 0:12:56.840000 I could have like three or four telnet sessions going from this exact 0:12:56.840000 --> 0:13:02.520000 host of 10111 going to that exact same server of 10222. 0:13:02.520000 --> 0:13:06.400000 Nothing preventing me from doing that. 0:13:06.400000 --> 0:13:09.880000 So I could have one telnet session right here, another telnet session 0:13:09.880000 --> 0:13:15.000000 and a third telnet session, all from the same host going to the same destination. 0:13:15.000000 --> 0:13:20.120000 And so when a reply comes back, we have to know, is that reply with the 0:13:20.120000 --> 0:13:22.780000 first session? Is it a reply to the second session? 0:13:22.780000 --> 0:13:24.700000 Is it to the third session? 0:13:24.700000 --> 0:13:29.600000 So that's why we need to have unique random source port numbers to keep 0:13:29.600000 --> 0:13:31.880000 track of these sessions. 0:13:31.880000 --> 0:13:38.220000 So for this initial session in this particular example right here, the 0:13:38.220000 --> 0:13:42.600000 laptop on the left is going to pull a random ephemeral port number from 0:13:42.600000 --> 0:13:44.220000 that last range of ports. 0:13:44.220000 --> 0:13:47.180000 In this case, it's going to pull 50,000. 0:13:47.180000 --> 0:13:49.600000 So now he creates a telnet packet. 0:13:49.600000 --> 0:13:54.800000 So notice in the telnet packet, what we have here, in the IP header, we've 0:13:54.800000 --> 0:13:57.140000 got the destination of 10222. 0:13:57.140000 --> 0:14:01.700000 We've got the source of where it's coming from, 10111. 0:14:01.700000 --> 0:14:09.100000 We've got that. And then in the TCP or UDP header, because they both use 0:14:09.100000 --> 0:14:11.620000 port numbers, now in this case, it's telnet. 0:14:11.620000 --> 0:14:12.560000 So it's going to be TCP. 0:14:12.560000 --> 0:14:16.720000 But even though this was UDP, some UDP application, this theory would 0:14:16.720000 --> 0:14:22.040000 hold true. The destination port number is the well-known port number that 0:14:22.040000 --> 0:14:24.460000 the server is already listening on. 0:14:24.460000 --> 0:14:29.700000 The source port number is this random source port number that the PC generated 0:14:29.700000 --> 0:14:33.700000 for this particular session. 0:14:33.700000 --> 0:14:36.580000 And now when that server responds, he's just going to do everything in 0:14:36.580000 --> 0:14:40.800000 reverse. You can see in the IP header, the source and destinations are 0:14:40.800000 --> 0:14:45.800000 reversed. And the TCP header, the source and destination port numbers 0:14:45.800000 --> 0:14:52.440000 are reversed. And this is how we use port numbers to keep track of individual 0:14:52.440000 --> 0:14:56.080000 sessions of applications. 0:14:56.080000 --> 0:14:59.020000 So that concludes this video. 0:14:59.020000 --> 0:14:59.840000 Thank you for watching.