WEBVTT 0:00:03.780000 --> 0:00:09.160000 So, if you've been studying for your CCNA for any more than about a week 0:00:09.160000 --> 0:00:13.820000 or two, you very quickly have run across the topic of the OSI model, the 0:00:13.820000 --> 0:00:17.780000 Open Systems Interconnect model that was created by the ISO, the International 0:00:17.780000 --> 0:00:22.040000 Standards Organization, which is the seven layers that sort of generically 0:00:22.040000 --> 0:00:26.020000 or abstractly define how networking is supposed to work. 0:00:26.020000 --> 0:00:30.080000 From the bits and bytes and the electrical signals of the physical layer, 0:00:30.080000 --> 0:00:33.100000 all the way up to layer seven at the application layer. 0:00:33.100000 --> 0:00:38.900000 Well, any designer of an application, anybody who writes the software 0:00:38.900000 --> 0:00:44.120000 for an application, whether it be an email, a new web browser, some sort 0:00:44.120000 --> 0:00:49.060000 of file transfer, whatever it is, one of the fundamental questions they 0:00:49.060000 --> 0:00:53.920000 have to ask themselves is, do I want this application to be connection 0:00:53.920000 --> 0:00:57.800000 less or connection oriented? 0:00:57.800000 --> 0:01:01.340000 And based on the answer to that question, we'll determine whether they 0:01:01.340000 --> 0:01:05.800000 want to make use of the services of UDP or TCP. 0:01:05.800000 --> 0:01:08.720000 And this will also help us to understand how to troubleshoot the application 0:01:08.720000 --> 0:01:10.960000 and what might possibly go wrong with it. 0:01:10.960000 --> 0:01:13.080000 So, let's take a look at these. 0:01:13.080000 --> 0:01:19.760000 So, TCP and UDP both reside at what layer of the OSI model? 0:01:19.760000 --> 0:01:22.500000 Hopefully, you said layer four. 0:01:22.500000 --> 0:01:24.320000 And what's the name of that layer? 0:01:24.320000 --> 0:01:27.660000 That is the transport layers. 0:01:27.660000 --> 0:01:29.180000 Hopefully, you got that right. 0:01:29.180000 --> 0:01:33.020000 So UDP and TCP reside up there at layer four. 0:01:33.020000 --> 0:01:35.540000 And what makes them different from each other? 0:01:35.540000 --> 0:01:39.220000 Well, UDP is connection less. 0:01:39.220000 --> 0:01:41.240000 What does that mean? 0:01:41.240000 --> 0:01:47.360000 In the world of data transfer, networking data transfer, the term connection 0:01:47.360000 --> 0:01:55.240000 oriented or connection less means connection oriented means before I transfer 0:01:55.240000 --> 0:02:03.000000 any data to a destination, I need to establish a connection with that 0:02:03.000000 --> 0:02:07.400000 destination. Meaning, I have to find out, is that destination alive? 0:02:07.400000 --> 0:02:10.900000 Is he even capable of responding to my information? 0:02:10.900000 --> 0:02:15.500000 Maybe we can negotiate some parameters like how much data I can send him 0:02:15.500000 --> 0:02:17.500000 before he wants me to stop. 0:02:17.500000 --> 0:02:19.860000 Are we going to acknowledge data? 0:02:19.860000 --> 0:02:23.440000 And if so, how is that acknowledgement process going to happen? 0:02:23.440000 --> 0:02:27.620000 That is a connection oriented application. 0:02:27.620000 --> 0:02:30.360000 Connection less is just the opposite. 0:02:30.360000 --> 0:02:34.580000 Connection less means, okay, well, I'm going to take my block of data, 0:02:34.580000 --> 0:02:38.200000 stick an IP header in front of it and just put on the wire. 0:02:38.200000 --> 0:02:40.660000 I don't even know if the destination exists. 0:02:40.660000 --> 0:02:42.520000 I don't care if the destination exists. 0:02:42.520000 --> 0:02:48.160000 A connection less application says it's not my responsibility to babysit 0:02:48.160000 --> 0:02:52.040000 the destination, to see if the destination is alive, if it's happy, if 0:02:52.040000 --> 0:02:55.840000 it can receive my information, if it can acknowledge my information, I 0:02:55.840000 --> 0:02:57.100000 don't care about that. 0:02:57.100000 --> 0:03:00.660000 Connection less says that's not my responsibility, I don't care. 0:03:00.660000 --> 0:03:04.880000 So UDP is connection less, meaning it doesn't do any of those checks, 0:03:04.880000 --> 0:03:08.100000 it doesn't have any of those safeguards. 0:03:08.100000 --> 0:03:11.620000 Now UDP, when it's receiving data from the upper layers, remember UDP 0:03:11.620000 --> 0:03:13.000000 is at layer four. 0:03:13.000000 --> 0:03:17.140000 So when data is coming down from layers five, six and seven, it is expecting 0:03:17.140000 --> 0:03:22.060000 to receive small, discrete messages from the upper layer protocols. 0:03:22.060000 --> 0:03:27.420000 UDP doesn't really have any inherent mechanism built into it to say, okay, 0:03:27.420000 --> 0:03:30.300000 just send me a whole stream of data, just keep it coming, keep it coming 0:03:30.300000 --> 0:03:35.000000 and I'll take certain blocks of it, wrap it in a header and send it and 0:03:35.000000 --> 0:03:37.740000 then take another block of it, wrap it in a header and send it. 0:03:37.740000 --> 0:03:39.880000 That's something that TCP does. 0:03:39.880000 --> 0:03:41.120000 UDP doesn't do that. 0:03:41.120000 --> 0:03:43.780000 UDP says, just send me a little snippet at a time, just send me a little 0:03:43.780000 --> 0:03:48.300000 chunk. In very tiny little chunk you send me, I'll slap a UDP header on 0:03:48.300000 --> 0:03:52.520000 it and then send it downstream to the networking layer. 0:03:52.520000 --> 0:03:57.100000 So because it's connection less, UDP doesn't provide any reliability or 0:03:57.100000 --> 0:04:04.900000 retransmission. Now TCP is much more robust and that's why actually probably 0:04:04.900000 --> 0:04:10.780000 about 80% if not higher of all the traffic that you'll see going across 0:04:10.780000 --> 0:04:17.400000 networks today and going across the internet are TCP based applications. 0:04:17.400000 --> 0:04:19.640000 TCP is connection oriented. 0:04:19.640000 --> 0:04:25.200000 TCP does all those things I talked about with regards to connection orientation. 0:04:25.200000 --> 0:04:29.140000 So, just to recap that, what is meant by connection oriented? 0:04:29.140000 --> 0:04:35.440000 Well, in the case of TCP, TCP verifies the existence of a peer prior to 0:04:35.440000 --> 0:04:38.940000 data exchange and I'll show you in just one second here how it does that. 0:04:38.940000 --> 0:04:42.540000 How does that actually determine if the remote destination is alive and 0:04:42.540000 --> 0:04:47.260000 well before it sends any data to that remote destination? 0:04:47.260000 --> 0:04:49.640000 I'll show you how that works in just a second. 0:04:49.640000 --> 0:04:54.880000 TCP peers negotiate parameters used to control data exchange. 0:04:54.880000 --> 0:04:59.540000 So for example, when a TCP session first starts up, before the data is 0:04:59.540000 --> 0:05:04.700000 even sent, before that web page is sent, before that email is sent, you 0:05:04.700000 --> 0:05:10.520000 know, whatever the application is that's using TCP, TCP will say, okay, 0:05:10.520000 --> 0:05:14.560000 I know that destination exists, now let's exchange some parameters. 0:05:14.560000 --> 0:05:18.980000 Hey, destination, how much data can I send you at one time? 0:05:18.980000 --> 0:05:20.520000 How much can you handle? 0:05:20.520000 --> 0:05:23.120000 I want acknowledgments from you. 0:05:23.120000 --> 0:05:26.860000 So let's put some sequence numbers in our data so that you know what to 0:05:26.860000 --> 0:05:29.820000 acknowledge. And a variety of other things as well. 0:05:29.820000 --> 0:05:36.300000 So the session, that connection is negotiated and configured before even 0:05:36.300000 --> 0:05:41.200000 the first byte of actual data is sent to that destination. 0:05:41.200000 --> 0:05:46.380000 And then TCP data is exchanged reliably using sequence numbers, acknowledgments, 0:05:46.380000 --> 0:05:49.860000 flow control, and retransmission. 0:05:49.860000 --> 0:05:55.400000 And TCP can gracefully inform a peer about the need to close a connection. 0:05:55.400000 --> 0:06:01.040000 So you know what TCP, this isn't mandatory, but once an application says, 0:06:01.040000 --> 0:06:05.260000 okay, I'm done, I don't need to use TCP anymore, that application will 0:06:05.260000 --> 0:06:08.140000 inform TCP. Finished, don't need you anymore. 0:06:08.140000 --> 0:06:13.100000 Then TCP can send a special TCP message called a FIN message, stands for 0:06:13.100000 --> 0:06:17.460000 finish, to the remote connection saying, okay, I'm finished, we don't 0:06:17.460000 --> 0:06:18.660000 need to talk anymore. 0:06:18.660000 --> 0:06:22.260000 And that remote connection can say, okay, our connection's done, that 0:06:22.260000 --> 0:06:26.320000 memory that I was holding aside for stuff from you, I can now free up 0:06:26.320000 --> 0:06:30.260000 that memory for a connection with somebody else that might come along 0:06:30.260000 --> 0:06:40.280000 in the future. So both TCP and UDP, in order to do what they do, take 0:06:40.280000 --> 0:06:43.620000 the data from the upper layer, you know, whether it be your email or your 0:06:43.620000 --> 0:06:49.480000 web page or whatever it is, you know, your voice that was digitized, and 0:06:49.480000 --> 0:06:52.860000 then they take it and they add some bits in the front of that data called 0:06:52.860000 --> 0:06:55.360000 a header. In other words, they encapsulate it. 0:06:55.360000 --> 0:06:59.720000 So with UDP, we say that UDP creates what's called a UDP data gram. 0:06:59.720000 --> 0:07:04.180000 Remember, UDP stands for the user datagram protocol. 0:07:04.180000 --> 0:07:09.840000 So the layer four thing that UDP creates, the data as well as the header 0:07:09.840000 --> 0:07:13.720000 in the front of that data, that whole thing is called a datagram if we're 0:07:13.720000 --> 0:07:15.100000 talking about UDP. 0:07:15.100000 --> 0:07:17.040000 And this is what UDP does. 0:07:17.040000 --> 0:07:22.540000 It basically adds a source port number and a destination port number, 0:07:22.540000 --> 0:07:25.880000 a length field, and a checksum. 0:07:25.880000 --> 0:07:31.340000 And that's it. So the source and destination port numbers indicate, you 0:07:31.340000 --> 0:07:38.880000 see, UDP and TCP can both sort of latch onto or hook into lots of different 0:07:38.880000 --> 0:07:45.600000 applications. At layer four, if I'm developing a software application, 0:07:45.600000 --> 0:07:49.120000 you know, I could be just one of thousands of software applications that 0:07:49.120000 --> 0:07:53.000000 are using UDP or using TCP. 0:07:53.000000 --> 0:07:58.060000 So if I send you a UDP datagram, okay, so let's say you're a computer 0:07:58.060000 --> 0:08:01.860000 or a server or something, and I send you a UDP datagram. 0:08:01.860000 --> 0:08:05.660000 Well, once you get it, as you're processing it from layer one to layer 0:08:05.660000 --> 0:08:11.420000 two to layer three to layer four, at layer four, you now say, okay, I've 0:08:11.420000 --> 0:08:13.540000 got this UDP header right here. 0:08:13.540000 --> 0:08:19.180000 Once I strip off the layer four header, what process in my CPU, in my 0:08:19.180000 --> 0:08:22.000000 processor, am I going to need to send this data to? 0:08:22.000000 --> 0:08:26.900000 Am I going to need to send this block of data to the chip in my CPU that 0:08:26.900000 --> 0:08:31.680000 does all of my IP telephony that sort of converts and digitizes voice 0:08:31.680000 --> 0:08:34.920000 back into analog waves that people can hear? 0:08:34.920000 --> 0:08:38.880000 Am I going to convert it back into video in case it's like an AVI file 0:08:38.880000 --> 0:08:41.880000 or an MPEG or something like that? 0:08:41.880000 --> 0:08:47.860000 So the CPU, UDP has to say, hey, CPU, this is going to your video section, 0:08:47.860000 --> 0:08:51.880000 or this is going to your audio section, and it's the port number, which 0:08:51.880000 --> 0:08:58.560000 indicates where in the CPU this data that's inside of the UDP datagram 0:08:58.560000 --> 0:09:01.120000 actually needs to go. 0:09:01.120000 --> 0:09:05.560000 So it has a source port number and a destination port number. 0:09:05.560000 --> 0:09:12.140000 Now TCP, because it is connection oriented, adds a lot more in its header. 0:09:12.140000 --> 0:09:15.160000 And I'm not going to go through all the details of these various fields 0:09:15.160000 --> 0:09:20.840000 here because I actually have a whole section of videos on TCP and what 0:09:20.840000 --> 0:09:24.500000 each one of these fields does and how TCP works in gory detail. 0:09:24.500000 --> 0:09:28.280000 So I'm not going to reinvent the wheel right here to explain that. 0:09:28.280000 --> 0:09:31.720000 Main thing I want to take away from here, for those of you who are just 0:09:31.720000 --> 0:09:36.520000 beginning with your CCD journey, is you can see that because TCP is connection 0:09:36.520000 --> 0:09:42.120000 oriented and it has to check if the remote destination is alive, make 0:09:42.120000 --> 0:09:44.520000 sure that it gets an acknowledgement back. 0:09:44.520000 --> 0:09:47.120000 Retransmit data if it didn't get an acknowledgement back because it has 0:09:47.120000 --> 0:09:51.720000 all of these things it has to do to maintain the connection. 0:09:51.720000 --> 0:09:56.400000 It's header that it puts at the front of the data is by necessity a lot 0:09:56.400000 --> 0:10:02.860000 larger. All of these fields allow TCP to be connection oriented to do 0:10:02.860000 --> 0:10:04.320000 what it needs to do. 0:10:04.320000 --> 0:10:07.100000 For example, we talked about the sequence numbers, right? 0:10:07.100000 --> 0:10:10.120000 So there's the sequence number right there that we can see, acknowledgment 0:10:10.120000 --> 0:10:15.740000 number, window size, which is a TCP's way of saying, hey buddy, when you 0:10:15.740000 --> 0:10:20.340000 send me information you can send me up to this much stuff and then I will 0:10:20.340000 --> 0:10:22.480000 acknowledge it back to you, right? 0:10:22.480000 --> 0:10:26.360000 So there's a whole bunch of things here in the header that TCP can do. 0:10:26.360000 --> 0:10:31.960000 Now I told you I said I promise you I would explain how does TCP set up 0:10:31.960000 --> 0:10:35.260000 a connection. Once it gets data from the upper layer it says okay let 0:10:35.260000 --> 0:10:39.280000 me put that aside, let me pause that data and make sure the remote destination 0:10:39.280000 --> 0:10:42.560000 actually exists and negotiate some parameters. 0:10:42.560000 --> 0:10:44.400000 How does it do that? 0:10:44.400000 --> 0:10:49.720000 Well that's where we talk about the TCP three way handshake. 0:10:49.720000 --> 0:11:01.160000 So in the world of TCP when you have an application let's say email that 0:11:01.160000 --> 0:11:06.820000 uses TCP. The email application the processor when it's actually active, 0:11:06.820000 --> 0:11:12.400000 when it's doing something, takes a block of memory in the processor and 0:11:12.400000 --> 0:11:16.400000 says okay processor this block of memory is for me, this is for email. 0:11:16.400000 --> 0:11:19.660000 So anything I have to do with regards to email is going to use this block 0:11:19.660000 --> 0:11:24.000000 of memory right here and we call that a transmission control block or 0:11:24.000000 --> 0:11:29.840000 a TCB. Now we're going to talk a little bit more about emails we go along 0:11:29.840000 --> 0:11:34.640000 here but a lot of applications are what we call client server applications 0:11:34.640000 --> 0:11:40.680000 meaning that there's a server like an email server that's always running 0:11:40.680000 --> 0:11:47.520000 email, always listening, always alert, it's CPU has email awake and listening 0:11:47.520000 --> 0:11:52.560000 and active. And then you have the client which is like your laptop where 0:11:52.560000 --> 0:11:56.700000 email is only running if you turn it on right if you bring up email you 0:11:56.700000 --> 0:11:59.460000 say fetch my messages I want something. 0:11:59.460000 --> 0:12:05.640000 So in the case of your client your laptop if you don't have your email 0:12:05.640000 --> 0:12:11.440000 open right now there is no transmission control block assigned for email. 0:12:11.440000 --> 0:12:18.180000 So TCP in your laptop has not allocated any kind of TCB transmission control 0:12:18.180000 --> 0:12:23.080000 block for that particular program because that program is not running. 0:12:23.080000 --> 0:12:26.600000 But if we look at the server which we have here over here is the receiver 0:12:26.600000 --> 0:12:31.660000 in this particular case the server says well at any given point in time 0:12:31.660000 --> 0:12:34.960000 there might be a client out there that wants to talk to me. 0:12:34.960000 --> 0:12:38.140000 I don't know who it is I don't know when he's going to want to talk to 0:12:38.140000 --> 0:12:43.160000 me but I have to be prepared I have to always be listening to email in 0:12:43.160000 --> 0:12:46.960000 case a client says hey buddy I want to talk to you via email. 0:12:46.960000 --> 0:12:52.100000 So the receiver the server has what's called a passive open created. 0:12:52.100000 --> 0:12:55.020000 He basically says okay I'm going to create a TCB I'm going to create a 0:12:55.020000 --> 0:12:59.280000 block of memory which is reserved for email and it's not reserved for 0:12:59.280000 --> 0:13:05.480000 anybody in particular but whoever talks to me I'll give this TCB to them. 0:13:05.480000 --> 0:13:09.840000 So I'm sort of passively waiting for somebody to open a connection to 0:13:09.840000 --> 0:13:12.820000 me and that's what a passive open is. 0:13:12.820000 --> 0:13:19.880000 Okay so let's take it from the client's perspective your laptop your PC. 0:13:19.880000 --> 0:13:25.280000 So you double click on your email icon like Eudora or Microsoft Outlook 0:13:25.280000 --> 0:13:28.760000 or whatever. So what happens in the background well by double clicking 0:13:28.760000 --> 0:13:33.680000 on that you just now alerted your CPU that it needs to start the email 0:13:33.680000 --> 0:13:39.520000 program. As part of that process the email program will start up and the 0:13:39.520000 --> 0:13:43.780000 email program will talk to your processor and say hey I'm a TCP based 0:13:43.780000 --> 0:13:49.260000 program I need to make use of the services of TCP and CPU I know that's 0:13:49.260000 --> 0:13:50.300000 something you do. 0:13:50.300000 --> 0:13:52.960000 So can you start TCP for me? 0:13:52.960000 --> 0:13:58.300000 So at this point the client the laptop now in the CPU the TCP process 0:13:58.300000 --> 0:14:04.440000 will start and TCP will create a transmission control block a TCB will 0:14:04.440000 --> 0:14:08.940000 be created in your laptop for email so this is called an active open because 0:14:08.940000 --> 0:14:14.460000 you actively did something to start up this application. 0:14:14.460000 --> 0:14:19.620000 Now once the active open happens now your TCP process in your laptop says 0:14:19.620000 --> 0:14:24.080000 okay first thing I have to do is I have to figure out who I'm going to 0:14:24.080000 --> 0:14:28.200000 talk to like the email server and I need to figure out if he's alive. 0:14:28.200000 --> 0:14:32.600000 If he's actually waiting there listening for me if he can talk to me. 0:14:32.600000 --> 0:14:38.980000 So the client the sender in this particular case sends a TCP message now 0:14:38.980000 --> 0:14:43.140000 that the data is empty right so if we're actually if we're visualizing 0:14:43.140000 --> 0:14:46.020000 this if you visualize a string of bits you know one zero one one zero 0:14:46.020000 --> 0:14:50.060000 list imagine like you know a couple thousand bits one zero one one zero 0:14:50.060000 --> 0:14:55.780000 the way that would look is the first several hundred bits would be your 0:14:55.780000 --> 0:14:59.180000 Ethernet frame your Ethernet header right the first several bits would 0:14:59.180000 --> 0:15:02.700000 be the destination MAC address followed by the source MAC address followed 0:15:02.700000 --> 0:15:06.680000 by a type code so that'd be all one one one so this block of one one one 0:15:06.680000 --> 0:15:11.140000 zero one one zero is your Ethernet header then after that the next block 0:15:11.140000 --> 0:15:15.860000 of ones and zeros would be your network header which is probably IP so 0:15:15.860000 --> 0:15:19.280000 now you'd have several hundred ones and zeros for your destination IP 0:15:19.280000 --> 0:15:25.660000 address source IP address check sum time to live all of that stuff and 0:15:25.660000 --> 0:15:31.380000 then the final block of ones and zeros would be your TCP header and there 0:15:31.380000 --> 0:15:35.020000 wouldn't be anything behind that so when we're sending out a TCP send 0:15:35.020000 --> 0:15:39.920000 it's just your layer two header your layer three header your layer four 0:15:39.920000 --> 0:15:44.960000 header and that's it there's no data yet because we haven't verified the 0:15:44.960000 --> 0:15:53.200000 connection exists we haven't so the last section of ones and zeros in 0:15:53.200000 --> 0:15:57.840000 this big long stream is our layer four TCP header and in that TCP header 0:15:57.840000 --> 0:16:05.920000 which we saw previously which was this right here in that TCP header so 0:16:05.920000 --> 0:16:08.780000 I didn't have this set up here beforehand but I'll go ahead and do right 0:16:08.780000 --> 0:16:15.740000 here you can see that we've got some control flags these are a series 0:16:15.740000 --> 0:16:20.360000 of bits and each bit means something in particular well one of these bits 0:16:20.360000 --> 0:16:23.180000 and you don't have to know which particular one it is but let's just say 0:16:23.180000 --> 0:16:27.280000 it's this one for the sake of argument that bit right there is what we 0:16:27.280000 --> 0:16:32.280000 call the sin bit so if I set that bit to a one that means I am trying 0:16:32.280000 --> 0:16:36.460000 to synchronize with you I'm trying to establish an initial connection 0:16:36.460000 --> 0:16:41.720000 with you so in the TCP three way handshake the very first message that 0:16:41.720000 --> 0:16:48.260000 goes out is this TCP header with this sin bit set let's write that right 0:16:48.260000 --> 0:16:56.220000 here which stands for synchronization so that's what we're seeing on this 0:16:56.220000 --> 0:17:02.420000 slide so there goes out the sin now also in that TCP header are things 0:17:02.420000 --> 0:17:07.520000 like what sequence number do I want to start out with because when we're 0:17:07.520000 --> 0:17:19.020000 going from left to right is going to have some sort of number in it some 0:17:19.020000 --> 0:17:23.500000 sequence number you know sequence number 100 maybe then sequence number 0:17:23.500000 --> 0:17:28.720000 101 and then 102 well during the sin this is the first TCP message it 0:17:28.720000 --> 0:17:33.060000 says hey receiver let me I'm telling you what I'm going to start out with 0:17:33.060000 --> 0:17:36.940000 what sequence number I'm going to start out with in addition to that because 0:17:36.940000 --> 0:17:40.580000 that TCP header has all kinds of fields in it he's also going to say by 0:17:40.580000 --> 0:17:46.160000 the way receiver when you need to send something back to me back in this 0:17:46.160000 --> 0:17:50.900000 direction right here you can send x number of bytes that's my window size 0:17:50.900000 --> 0:17:55.000000 you can send me x number of bytes and then pause and I'll acknowledge 0:17:55.000000 --> 0:18:02.220000 it so just in this one TCP message right here the sin he's saying I am 0:18:02.220000 --> 0:18:08.460000 a sender I exist receiver I'm trying to find out if you exist I'm trying 0:18:08.460000 --> 0:18:11.940000 to find out if you're listening on this particular port number for example 0:18:11.940000 --> 0:18:26.880000 if we were talking about a network with me on telnet at some point in 0:18:26.880000 --> 0:18:31.360000 time so I need to create a transmission control block that's listening 0:18:31.360000 --> 0:18:36.480000 all the time passively on port number 23 just in case someone needs to 0:18:36.480000 --> 0:18:42.440000 speak to me via telnet so in this TCP sin he's saying hey are you alive 0:18:42.440000 --> 0:18:48.520000 and are you listening to telnet or if you're talking about e-mail it might 0:18:48.520000 --> 0:18:52.100000 be port number 25 are you listening on the simple mail transport protocol 0:18:52.100000 --> 0:18:55.140000 so the sin is going to have some port number in it saying okay I'm going 0:18:55.140000 --> 0:18:58.140000 to have some port number in it okay receiver is your TCP process alive 0:18:58.140000 --> 0:19:03.940000 and active and is your actual application running an active right now 0:19:03.940000 --> 0:19:10.000000 so that's all in the sin and now the receiver has to respond to that remember 0:19:10.000000 --> 0:19:14.000000 the receiver is the server like your e-mail server or your web server 0:19:14.000000 --> 0:19:18.700000 or whatever it is so he says okay well I'm going to respond to your sin 0:19:18.700000 --> 0:19:23.000000 by generating my own sin he says okay this is my synchronization back 0:19:23.000000 --> 0:19:26.920000 to you the receiver says I've never talked to you before sender this is 0:19:26.920000 --> 0:19:34.160000 the first time I'm synchronizing with you so he sets his own sin bit he 0:19:34.160000 --> 0:19:37.280000 says hey let me tell you what sequence number I'd like to use going from 0:19:37.280000 --> 0:19:44.620000 right to left and he also sets the acknowledgement bit saying hey by the 0:19:44.620000 --> 0:19:51.120000 way I got your sin I know you exist I'm acknowledging that so in this 0:19:51.120000 --> 0:19:55.100000 particular case right here in this initial sin he might be saying well 0:19:55.100000 --> 0:20:00.040000 when I'm talking to you from right to left whenever I'm sending you data 0:20:00.040000 --> 0:20:06.460000 I'm going to start out with maybe sequence number 555 is that okay with 0:20:06.460000 --> 0:20:11.780000 you and then the sender on the left will finish up the process by sending 0:20:11.780000 --> 0:20:18.320000 an ACK is that yep I got your sequence number I got your sin I got your 0:20:18.320000 --> 0:20:21.960000 we look good let's start communicating let's actually start transferring 0:20:21.960000 --> 0:20:27.740000 some data here so every application that uses TCP whether it be e-mail 0:20:27.740000 --> 0:20:33.240000 web browsing and like I said like 80 % plus of all applications that you 0:20:33.240000 --> 0:20:38.680000 see on networks today use TCP always have to go through this process before 0:20:38.680000 --> 0:20:43.620000 they start this is the process of building the connection and negotiating 0:20:43.620000 --> 0:20:53.520000 the connection so why is this relevant so if we're going to be creating 0:20:53.520000 --> 0:20:57.300000 some firewall policies some security policies we need to be able to be 0:20:57.300000 --> 0:21:05.880000 aware of how TCP and UDP work for example a lot of times you'll see in 0:21:05.880000 --> 0:21:09.780000 networks you might have a network where you've got some building right 0:21:09.780000 --> 0:21:13.420000 here and some router in the building I'll just put the next right there 0:21:13.420000 --> 0:21:14.600000 connecting to the network and the network where you've got some building 0:21:14.600000 --> 0:21:14.600000 right here and some router in the building I'll just put the next right 0:21:14.600000 --> 0:21:14.920000 there connecting to the network where you've got some to the internet 0:21:14.920000 --> 0:21:24.700000 and we might have an application policy in the building that says this 0:21:24.700000 --> 0:21:30.940000 it says okay if an application needs to start in the building and start 0:21:30.940000 --> 0:21:36.060000 talking to the outside world that's okay the outside world can respond 0:21:36.060000 --> 0:21:40.040000 to that that's a perfectly legitimate stream because it started within 0:21:40.040000 --> 0:21:46.060000 our company however if the outside world tries to initiate a connection 0:21:46.060000 --> 0:21:51.340000 inbound with us that is not okay the only time the internet should be 0:21:51.340000 --> 0:21:55.840000 sending data to us if it's in response to something that we've sent to 0:21:55.840000 --> 0:22:02.780000 them this is not okay well if we're talking about TCP there's a very easy 0:22:02.780000 --> 0:22:05.720000 way to implement this if the application we're concerned with is a TCP 0:22:05.720000 --> 0:22:11.440000 application what do we know well we know that when the connection starts 0:22:11.440000 --> 0:22:21.260000 this will have a sin bit and that's it right what else do we know we know 0:22:21.260000 --> 0:22:26.140000 that from this point on everything that comes from left to right is going 0:22:26.140000 --> 0:22:29.560000 to have an act bit set like in the three ways handshake will have the 0:22:29.560000 --> 0:22:36.360000 sin plus the act and then we'll have an act this way but everything else 0:22:36.360000 --> 0:22:40.380000 that keeps coming back is going to have an act everything that comes back 0:22:40.380000 --> 0:22:44.460000 from the internet is going to have the acknowledgment that said so here's 0:22:44.460000 --> 0:22:49.100000 what we can do we can create a firewall policy that says only allow inbound 0:22:49.100000 --> 0:22:55.400000 data from the internet if you see the act bit if you don't see the act 0:22:55.400000 --> 0:23:00.720000 bit that means somebody is trying to initiate a conversation and that's 0:23:00.720000 --> 0:23:04.640000 not allowed this is what we mean when we talk about a TCP established 0:23:04.640000 --> 0:23:08.380000 session and established session means only allow packets that have the 0:23:08.380000 --> 0:23:11.540000 act bit set which means it's a session it's already in the back of the 0:23:11.540000 --> 0:23:13.760000 internet but it's already been established it's in response to something 0:23:13.760000 --> 0:23:18.320000 I have sent out but if you didn't know if this particular application 0:23:18.320000 --> 0:23:23.800000 used TCP or UDP there being no way for you to know can I take advantage 0:23:23.800000 --> 0:23:41.760000 of this can I actually set up my firewall to look for the network administrator 0:23:41.760000 --> 0:23:45.660000 and certainly as a network engineer one of the things you might be responsible 0:23:45.660000 --> 0:23:51.920000 for is determining how much bandwidth a particular application is allowed 0:23:51.920000 --> 0:23:56.120000 to have in your network okay somebody might say well you know I've got 0:23:56.120000 --> 0:24:00.400000 one particular wire here which is a fast ethernet wire 100 megabits per 0:24:00.400000 --> 0:24:03.840000 second and this one application I'm thinking about that can be really 0:24:03.840000 --> 0:24:10.060000 hungry with bandwidth can have no more than 10 megabits per second I will 0:24:10.060000 --> 0:24:14.680000 allow it to have one tenth of the total bandwidth on this wire and that's 0:24:14.680000 --> 0:24:21.320000 it okay so you implement some sort of quality of service policy like a 0:24:21.320000 --> 0:24:25.880000 police or something that monitors that application counts the number of 0:24:25.880000 --> 0:24:31.620000 bits it's sending to make sure it falls within that threshold well if 0:24:31.620000 --> 0:24:37.740000 that application is a TCP application knowing how TCP works if it starts 0:24:37.740000 --> 0:24:41.360000 going faster and faster and faster than it gets to that level that TCP 0:24:41.360000 --> 0:24:59.420000 application gets to 10 meg and now starts going a little bit over that 0:24:59.420000 --> 0:25:04.000000 is that when it detects that something has been lost like the sender the 0:25:04.000000 --> 0:25:06.460000 guy who's been sending and going faster and faster and faster all of a 0:25:06.460000 --> 0:25:10.140000 sudden he says haven't gotten acknowledgement back in quite a while for 0:25:10.140000 --> 0:25:14.680000 that last segment I sent TCP says I'm going to slow down I'm going to 0:25:14.680000 --> 0:25:19.760000 back off and slow down and then start going a little bit faster again 0:25:19.760000 --> 0:25:25.440000 whereas a UDP a UDP application doesn't do that right because a UDP application 0:25:25.440000 --> 0:25:29.020000 does not monitor the connection it's not connection oriented just goes 0:25:29.020000 --> 0:25:33.220000 as fast as it possibly can it's not looking for acknowledgments so if 0:25:33.220000 --> 0:25:38.840000 you drop some UDP packets that will have no impact on the rate of that 0:25:38.840000 --> 0:25:43.040000 stream that UDP stream will continue going as fast as it possibly can 0:25:43.040000 --> 0:25:47.980000 and it will not respond to packet drops so in this particular regards 0:25:47.980000 --> 0:25:51.720000 if we're implementing quality of service in our network is good for us 0:25:51.720000 --> 0:25:56.300000 to know what applications are running TCP versus what applications are 0:25:56.300000 --> 0:26:00.820000 running UDP because we know that those TCP applications will respond very 0:26:00.820000 --> 0:26:05.660000 very well to quality of service they will very politely back off if we 0:26:05.660000 --> 0:26:09.140000 start dropping some of their traffic because they'll say oh okay I guess 0:26:09.140000 --> 0:26:13.660000 I'm going too fast let me slow down a little bit UDP won't do that so 0:26:13.660000 --> 0:26:15.940000 that's another reason why we need to know the application is going to 0:26:15.940000 --> 0:26:16.480000 be a little bit more so there's a lot of applications that we need to 0:26:16.480000 --> 0:26:23.040000 look for which ones are they using TCP or UDP so voice and video typically 0:26:23.040000 --> 0:26:29.860000 utilize UDP and in these particular things intermittent drops are okay 0:26:29.860000 --> 0:26:35.440000 what does that mean if you think about a voice conversation you pick up 0:26:35.440000 --> 0:26:39.040000 an IP phone at your work or at your office and you start talking into 0:26:39.040000 --> 0:26:44.640000 it what's happening well as you're talking into it the air pressure coming 0:26:44.640000 --> 0:26:49.240000 out of your mouth is vibrating the diaphragm in that phone and that's 0:26:49.240000 --> 0:26:53.560000 vibrating past a magnet which is causing electrical energy which eventually 0:26:53.560000 --> 0:26:58.180000 is being converted into ones and zero so that's how the actual voice is 0:26:58.180000 --> 0:27:01.600000 coming out of your lips and the air pressure is converted into electrical 0:27:01.600000 --> 0:27:08.440000 energy and turned into binary ones and zeros well just one second of your 0:27:08.440000 --> 0:27:13.820000 voice of your voice one second one thousand and one one Mississippi just 0:27:13.820000 --> 0:27:20.680000 that alone can end up creating tens of thousands of bits tens of thousands 0:27:20.680000 --> 0:27:25.920000 of bits so we could be Synthing about dozens of packets just for one second 0:27:25.920000 --> 0:27:31.480000 of voice. Now if I'm talking to you on an IP phone connection and let's 0:27:31.480000 --> 0:27:35.980000 say that a couple of packets get dropped due to congestion somewhere or 0:27:35.980000 --> 0:27:42.640000 whatever that translates to less than one second of audio got clipped 0:27:42.640000 --> 0:27:46.860000 do you think the human ear is really going to be able to tell if a little 0:27:46.860000 --> 0:27:52.120000 part of a constant or a little part of a vowel got clipped off no you're 0:27:52.120000 --> 0:27:55.900000 not going to be able to tell that that's why and video is the same way 0:27:55.900000 --> 0:27:57.000000 with video you know the other thing is that you can't get any more information 0:27:57.000000 --> 0:27:59.660000 on the phone. So if I have a human eye a nice consistent movie for example 0:27:59.660000 --> 0:28:04.960000 the human eye can read things at roughly about 30 33 frames per second 0:28:04.960000 --> 0:28:09.300000 so that means if I have an image and then I change it and I change it 0:28:09.300000 --> 0:28:13.300000 and I change it if I do that 33 times per second that will appear as a 0:28:13.300000 --> 0:28:18.680000 flow for you as a nice movie for you you won't be able to detect those 0:28:18.680000 --> 0:28:23.040000 changes between the images if I'm doing it 33 times per second or faster 0:28:23.040000 --> 0:28:24.860000 you won't be able to tell. 0:28:24.860000 --> 0:28:30.300000 Well if just one if I just press pause on the on the video and I looked 0:28:30.300000 --> 0:28:35.740000 at that one frame that one still frame that could be several dozen packets 0:28:35.740000 --> 0:28:39.680000 just to render that one frame all the colors and all the shapes and everything 0:28:39.680000 --> 0:28:43.360000 that's in it once again if a couple of those packets get lost. 0:28:43.360000 --> 0:28:46.900000 Your human eye will not be able to detect that you won't be able to detect 0:28:46.900000 --> 0:28:50.800000 the momentary blip of when a certain section of the screen went dark because 0:28:50.800000 --> 0:28:54.520000 it just it happened too fast it was within a microsecond you can't tell. 0:28:54.520000 --> 0:28:59.900000 So that's why voice and video intermittent drops are okay but they are 0:28:59.900000 --> 0:29:06.440000 very intolerant of delay or jitter what does that mean. 0:29:06.440000 --> 0:29:11.000000 So delay is an example of you ever had the situation with a phone call 0:29:11.000000 --> 0:29:15.940000 or you pick up the phone and you start talking and you realize that your 0:29:15.940000 --> 0:29:20.500000 voice is taking like a second or two or three to reach the other end. 0:29:20.500000 --> 0:29:23.020000 Which is real irritate because once you talk you have to say okay I'm 0:29:23.020000 --> 0:29:25.960000 going to shut up for a couple seconds wait to make sure that grandma heard 0:29:25.960000 --> 0:29:29.840000 me. Give her a couple seconds to reply and so you actually have to factor 0:29:29.840000 --> 0:29:32.800000 that into your conversation otherwise you end up talking on top of each 0:29:32.800000 --> 0:29:36.040000 other because there's delay going across. 0:29:36.040000 --> 0:29:40.780000 We don't like that right so that's why voice and video delay is a bad 0:29:40.780000 --> 0:29:45.620000 thing. Now what's the difference between delay and jitter. 0:29:45.620000 --> 0:29:50.240000 So I mentioned that both voice and video as applications end up creating 0:29:50.240000 --> 0:29:56.120000 dozens or sometimes hundreds of packets per second to send that voice 0:29:56.120000 --> 0:29:58.020000 to send that video. 0:29:58.020000 --> 0:30:02.860000 So imagine that imagine a stream of let's say a 500 packets just a stream 0:30:02.860000 --> 0:30:07.360000 of packets. So here they come in and let's say that there's some device 0:30:07.360000 --> 0:30:11.240000 in the network maybe a router or switch somewhere that's having some problems 0:30:11.240000 --> 0:30:15.380000 right now. And as all those packets come in it just has to delay them 0:30:15.380000 --> 0:30:18.100000 for a little bit and then it feeds them out. 0:30:18.100000 --> 0:30:22.000000 So as all the packets come in they're being delayed by like you know half 0:30:22.000000 --> 0:30:25.040000 of a second or something but it's all consistent. 0:30:25.040000 --> 0:30:28.720000 Packet number one is delayed by half a second packet number 300 is delayed 0:30:28.720000 --> 0:30:29.860000 by half a second. 0:30:29.860000 --> 0:30:33.500000 Every single packet is being delayed by half of a second. 0:30:33.500000 --> 0:30:34.660000 That's what we mean by delay. 0:30:34.660000 --> 0:30:38.820000 It means that all the packets in a particular stream are experiencing 0:30:38.820000 --> 0:30:42.560000 some congestion at some point and they're all being delayed the exact 0:30:42.560000 --> 0:30:45.260000 same amount of time. 0:30:45.260000 --> 0:30:48.520000 So like in that phone conversation that's what we translate to. 0:30:48.520000 --> 0:30:51.440000 I'm talking and grandma can hear me. 0:30:51.440000 --> 0:30:52.860000 My voice is clear. 0:30:52.860000 --> 0:30:56.120000 It's just taking a second or two to show up on her phone. 0:30:56.120000 --> 0:30:57.260000 So it's irritating. 0:30:57.260000 --> 0:31:01.260000 I don't like it but at least we can still communicate. 0:31:01.260000 --> 0:31:03.460000 Jitter is another form of delay. 0:31:03.460000 --> 0:31:07.720000 Now once again imagine 500 packets coming in but this time that networking 0:31:07.720000 --> 0:31:10.440000 device is random. 0:31:10.440000 --> 0:31:14.900000 So packet number one gets delayed by two seconds. 0:31:14.900000 --> 0:31:16.860000 Packets three through ten. 0:31:16.860000 --> 0:31:18.020000 No delay at all. 0:31:18.020000 --> 0:31:21.720000 Packets 11 through 15 get delayed by five seconds. 0:31:21.720000 --> 0:31:24.200000 And the next packets are delayed by one half of a second. 0:31:24.200000 --> 0:31:27.620000 So when the delay is happening it's not consistent. 0:31:27.620000 --> 0:31:30.240000 Within a stream of traffic some of the stuff is being delayed a lot. 0:31:30.240000 --> 0:31:34.500000 Some of the stuff is being delayed a little bit and everything in between. 0:31:34.500000 --> 0:31:37.340000 Well with voice and video that will just kill it. 0:31:37.340000 --> 0:31:42.300000 So if that happens on a voice call the voice call will just become garbage. 0:31:42.300000 --> 0:31:43.520000 As you're listening to it will be all... 0:31:43.520000 --> 0:31:48.880000 You won't be able to tell what the person's saying. 0:31:48.880000 --> 0:31:53.980000 So jitter will kill a voice or video connection. 0:31:53.980000 --> 0:32:00.160000 Now data like your web browsing, your email, your file transfers, those 0:32:00.160000 --> 0:32:02.800000 typically ride in TCP segments. 0:32:02.800000 --> 0:32:09.540000 With TCP segments drops not a big deal because drops are retransmitted. 0:32:09.540000 --> 0:32:12.900000 TCP has sequence numbers and if it doesn't get an acknowledgement it'll 0:32:12.900000 --> 0:32:17.040000 drop it. So we don't have to worry too much about that. 0:32:17.040000 --> 0:32:20.400000 And minor delay or jitter is okay. 0:32:20.400000 --> 0:32:23.420000 That file transfer or that email. 0:32:23.420000 --> 0:32:26.960000 It's a little irritating if I press the send button and it takes five 0:32:26.960000 --> 0:32:29.840000 seconds instead of two seconds to get my email. 0:32:29.840000 --> 0:32:31.420000 But I can handle it. 0:32:31.420000 --> 0:32:35.240000 I'm kind of used to that with email and with bring up a web page and stuff. 0:32:35.240000 --> 0:32:38.940000 I don't like that with real time stuff like voice and video. 0:32:38.940000 --> 0:32:44.020000 So once again knowing if something's using UDP or TCP can help you sort 0:32:44.020000 --> 0:32:49.960000 of visualize okay is this delay being caused by drops or retransmissions 0:32:49.960000 --> 0:32:52.680000 or what could be causing it. 0:32:52.680000 --> 0:32:55.480000 And the last thing I want to talk about in this section is something called 0:32:55.480000 --> 0:32:57.100000 ephemeral ports. 0:32:57.100000 --> 0:33:01.980000 I have noticed in a lot of my CCNA classes that people are unaware of 0:33:01.980000 --> 0:33:03.980000 what this term means. 0:33:03.980000 --> 0:33:08.220000 And when you're looking at packet sniffers and certainly when you're implementing 0:33:08.220000 --> 0:33:13.360000 security policies like with access lists and firewalls and things, it's 0:33:13.360000 --> 0:33:19.020000 important to understand how port numbers are used and what this concept 0:33:19.020000 --> 0:33:21.660000 of ephemeral ports are. 0:33:21.660000 --> 0:33:27.960000 So both TCP and UDP utilize source and destination ports. 0:33:27.960000 --> 0:33:34.400000 So for example, if this is my laptop right here and this is a server right 0:33:34.400000 --> 0:33:37.920000 here and maybe the server is a web server. 0:33:37.920000 --> 0:33:44.140000 Which means he is listening to HTTP. 0:33:44.140000 --> 0:33:47.560000 That is the protocol he's listening to which has been assigned to port 0:33:47.560000 --> 0:33:55.320000 number 80. Well, when my laptop sends a packet to that web server saying 0:33:55.320000 --> 0:34:00.920000 please give me your web page, the destination port he'll be talking on 0:34:00.920000 --> 0:34:07.600000 will be 80. Right in the TCP header in the destination port section I'll 0:34:07.600000 --> 0:34:11.680000 say look I'm talking TCP to your HTTP. 0:34:11.680000 --> 0:34:13.320000 Are you alive HTTP? 0:34:13.320000 --> 0:34:15.040000 Are you listening? 0:34:15.040000 --> 0:34:19.380000 But the web server when he responds back he'll say okay this response 0:34:19.380000 --> 0:34:23.520000 came from my source port number of 80. 0:34:23.520000 --> 0:34:27.140000 This is HTTP responding back to you. 0:34:27.140000 --> 0:34:31.740000 But he says okay but I need to be able to respond back to some destination. 0:34:31.740000 --> 0:34:33.800000 What's he going to respond back to here? 0:34:33.800000 --> 0:34:36.960000 That destination is going to be corresponding to whatever the source was 0:34:36.960000 --> 0:34:43.660000 right here. Well, when a conversation starts up while the destination 0:34:43.660000 --> 0:34:48.340000 port number is a well known number like a well known number for web browsing 0:34:48.340000 --> 0:34:51.360000 or a well known number for telnet or a well known number for some other 0:34:51.360000 --> 0:34:58.420000 protocol. The source port number is typically some random number like 0:34:58.420000 --> 0:35:03.200000 that. And so he says okay for this conversation the laptop says while 0:35:03.200000 --> 0:35:07.760000 I'm talking to you server if you need to talk back to me, talk to me on 0:35:07.760000 --> 0:35:12.340000 the server. I'll be listening to that and if I get anything back on 50 0:35:12.340000 --> 0:35:15.500000 ,000, I will know that came from you Mr. 0:35:15.500000 --> 0:35:20.940000 Web server. So now the server will respond back to 50,000 and 11. 0:35:20.940000 --> 0:35:26.740000 Well this random port here is what we call any femoral port number. 0:35:26.740000 --> 0:35:30.400000 That's the term for the femoral port number. 0:35:30.400000 --> 0:35:35.080000 So in a conversation between two devices typically one of the port numbers 0:35:35.080000 --> 0:35:39.280000 will be a well known port number reserved for a particular application. 0:35:39.280000 --> 0:35:42.540000 The other port number will be a random port number that you can't possibly 0:35:42.540000 --> 0:35:45.960000 predict what it's going to be. 0:35:45.960000 --> 0:35:49.980000 And that's what we call any femoral port. 0:35:49.980000 --> 0:35:52.720000 And I just give a little bit of additional information right here. 0:35:52.720000 --> 0:35:56.080000 You would never, I don't think you need to know this necessarily for any 0:35:56.080000 --> 0:35:59.220000 exam. But if you're like me and you like to know these types of details 0:35:59.220000 --> 0:36:03.280000 you can see here the range is a port numbers that the internet assigned 0:36:03.280000 --> 0:36:08.500000 numbers authority suggests for use for the femoral ports. 0:36:08.500000 --> 0:36:12.480000 And you can see different operating systems choose certain numbers within 0:36:12.480000 --> 0:36:16.640000 that range or sometimes even outside of that range. 0:36:16.640000 --> 0:36:21.980000 So if you want to be able to block or permit certain traffic you need 0:36:21.980000 --> 0:36:25.320000 to know what the reserved port number is that it's going to be using. 0:36:25.320000 --> 0:36:29.560000 And you need to be able to predict what direction of traffic is going 0:36:29.560000 --> 0:36:32.600000 to be carrying that port number. 0:36:32.600000 --> 0:36:35.180000 So that concludes this video. 0:36:35.180000 --> 0:36:38.360000 In the next video we're going to go into a lot more details on the domain 0:36:38.360000 --> 0:36:40.580000 name service and how that works.