Using Reference Models

0:00Hello and welcome. My name is Keith Barker. And when we sit at a computer, whether it's a mobile device or laptop or desktop or something else, and we go out to the internet, there's a lot of things that are happening in the background to make that all successful. And a lot of that is based on network activity where we send a request out to the server and we get a response back. Now, there's a couple of ways of approaching how we could understand all those details that happen. One is to say, "Wow, that's just amazing." And just leaving a big bubble says, "Amazing." Or, we could break it down into individual components or layers. And one way of slicing it up and chopping into smaller components that we can understand is using the concept of a model or a reference model.

0:39And that's what this set of videos are all about is how to use a reference model to better understand how the computer network works. So in preparation for this, I have some props ready to go. I also have some live demonstrations and hands-on lab for you to use to practice with to really get insight and understanding regarding the parts and pieces to make the basic network function. So if you're ready, I'm ready. And I'll see you in the next video as you take a big picture look at the world of using reference models to understand how computer networks work .

0:00I'd like to start off with this topology, which is the fancy way of saying a representation of a given network. So we have a computer down here and I'd like to think about a typical computer. Maybe it's a Windows computer like this one, a Windows 11 computer or maybe it's running Linux or maybe it's running macOS and maybe we're connected to the network with a physical cable like a patch cable. And here is an example of a patch cable that would go from our computer. For example, our computing device. There's a really teeny computer right here. Here's this network port. So we go ahead and connect there. Then we take the other end and plug it into our network infrastructure device. Now in this case, it happens to be a switch. So plug it in there and boom, that's our physical connectivity. So let's go take a look at that in our topology. So here in our topology, here is a representation of our computer. And here's that little cable right here that's connecting the computer over into the physical network device. So that's one way of connecting to a network. We could also connect to a network via wireless. We have some wireless gear that's connecting over the airwaves, but eventually that wireless connection is going to connect to a physical network. So let's imagine that we are sitting right here at our computer and we want to access a server. And this server over here in the network topology is a server called server1.negutlab.com.

1:10And this is just here in a lab environment. I currently have this little server sitting. And in computer networking, we have two primary roles. We have a role of a client, meaning we're making a request like asking for something like going to a store or restaurant and saying I would like this or I would like that. And then we also have the component or entity that's providing that service. And that's called a server. So in this topology, client one, if it was going to a website, for example, like server1.negutlab.com, our server would be this server providing the web services. And the client would be the device making the request. So as far as a client or a computer device making a request, let's make sure we're both clear on what that really looks like. Let's go to client nug and we'll make a request to get some content from this server.

1:50So I'm going to go ahead and click right here on client nug to bring that up. That's our little Windows client machine from the topology. And here it is. If we bring up a command prompt here on this little client computer, we can find out what its address is on the network by typing in a command called IP can fig on Windows. And there's its address. So think of an address like a street name and a house number that we use to reach somebody. That's the address we have right here on this local computer. So if we wanted to access a server on minimize this command prompt here, we could go ahead and open up a browser. So I'll go ahead and open up Chrome as an example of a browser.

2:21And here I have a little shortcut for server one dot nugget lab dot com. So if we click on that in the background, this computer put together a request, sent it to that server server at server one dot nugget lab dot com. And this is the response we got back. And this kind of activity between a client asking for services and a server responding back happens on the internet billions of times a day. So to better understand all the details that happen behind the scenes with these computers and servers as they're communicating back and forth over the network, we can leverage the concept of a reference model.

2:52So one way of breaking the individual pieces down into smaller components using reference models, we're like taking a say a recipe, we'll say this represents a recipe. And we have a whole bunch of different ingredients as part of that recipe. And they've been put together and processed in the right order. And then it's finally delivered. So as a user as a customer , all we get is the meal. But behind the scenes, the individual components and how they're put together is how we understand that meal. And just like a recipe identifies the individual components that go into a meal, we can also use a reference model to help us understand the individual pieces and parts that are making all of this work here between the client and the server.

3:29Another way of thinking of it is thinking of it like a building. So here's our foundation. And then maybe we have a first floor and a second floor and a third floor. And then beyond that we have things like plumbing and electrical and other details that go in. But by taking it piece by piece and part by part, we can better understand all the components like a recipe that makes it work. And that's one of the benefits of using a reference model and the OG of reference model, the original reference model is called the OSI reference model. And that stands for open system interconnect model. But we just call the OSI model. So what I look forward to getting to do with you in this set of videos is taking a closer look at the OSI reference model, including the details that can happen behind the scenes at a computer, very much like a recipe with this individual ingredients.

4:13And then apply that knowledge regarding the OSI reference model to the actual computer network protocols that we actually use today. So if you are ready to join me as we unravel the mystery of the reference models and better understand how computers actually can communicate over a network, join me in the next video and we'll take a closer look at the original OSI reference model.

0:00In this video, as we take a look at the OSI reference model, here is the seven individual components. Think of like seven ingredients that go into what has to happen to go ahead and allow a computer like client like here to communicate with a server like server one over here. So, let's be the client making the request. I'd like a website where the client is saying something like I'd like to see this web page and the server saying, okay, here it is. And again, the model concept can help us break down the entire detail behind the scenes what has to happen for the client to make that request in the first place and then for the server to respond to it. I'd like to share with you a couple of easy ways to remember the various names or sections of the OSI reference model. Again, the purpose of this model as we start digging into the individual sections is to better understand what has to happen at the computer and at the server for communications to happen between them. And as a spoiler alert, the client who's making the request has to do a little bit of work at each of these layers before it's going to go ahead and actually send that traffic out on the network. So before we begin, let's talk about a great way of helping to remember the various names of the OSI reference model. So as a help in remembering the names of the OSI reference model, let's go ahead and use the first letter of each of the names. So I'll go ahead

1:16and put a little mark there P for physical D for data link and for network T for transport S for session P for presentation A for application. And one way of remembering these, and I'm going to start from the ground up on this first example, is to use a phrase and that phrase could be something like please. So there's the P and please reminding us of the first letter of the first layer of physical. And then as we go up, we'll say do and maybe the whole phrase please do not. Now, whether or not you like sausage pizza, we're going to encourage you with this phrase to please do not throw sausage pizza away. Please do not throw sausage pizza away. So if you can repeat that phrase, that's going to be a little clue as far as the first initial of each of the layers in the OSI reference model. Another phrase I heard many, many years ago was the phrase all people seem to need data processing. But you know, that one doesn't roll off the tongue quite as well as please do not throw sausage pizza away. And also this one starts from, you know , layer seven working all the way down to layer one. But either way is fine. If you want to just pick one of those, memorize it, write it out. That will help you in remembering the various names of the layers in the OSI reference model. Now, I'd like to ask you a question. If this computer,

2:32and we haven't covered the facts of this yet, but if this computer is going to send a request for like say web services over to a server, I'm going to ask you a question about how many of these layers do you think this computer has to go through before it actually sends the data out to the server? And the answer to that question is all of it. So in the brain of this computer in the background, when the user types in, for example, let's go to this website or that website behind the scenes, the computer is going through these individual layers in this model to get all the data it needs before it ships that data over that patch cable in this example over to the network. And then it's the network's job to forward that traffic over to the server who then receives that request.

3:14And when the server receives that request, guess what it has to do? It has to basically go in the reverse direction and process all that traffic and data that came in. So it's also going to the work of all these logical layers. And part of that would be things like, Oh, this traffic that's coming from the client is for me. And I do have a web service running in this clients requesting it, and I respond back. But logically, it has to go ahead and receive and process that data in pretty much the reverse order. Now I have some great news for you. The OSI reference model is just a model. It is not a literal protocol that we use today. It's just an idea that helps us compartmentalize and better understand the individual details. So what I'm going to do is I'm going to encourage you to memorize the names of the seven layers. Please do not throw sausage pizza away, physical day link network transport session presentation application, or use another phrase to help you remember what it is. So once you've memorized what these layer names are, the good news is, because this is just a model, we don't actually use literally the OSI reference model when computers are talking over network, because today we use a protocol called TCP IP and IP stands for internet protocol. And the good news about IP is that it does not, it does not use every

4:29single literal layer of the OSI reference model. The actual protocol itself that we use has five. So it makes sense for us to better understand what this protocol stack is, then we'll also take a look at how we can leverage the OSI reference model in understanding how the protocol that we use on the internet today, the internet protocol, how it works. So before we go to the next video, we start comparing and contrasting the reference model to the actual protocol stack that we use today, I would encourage you to take a few minutes right now and write out the phrase you want to use to help you remember the actual names of the layers in the OSI reference model, because we're going to use some of those, not all of them, but some of those as we take a look at the TCP IP protocol stack coming up. So when you take it a minute and you've written out the phrase you want to use to remember the layers of the OSI reference model, and you can do it a couple times without referring to the video, when you're ready to go on, join me in the next video and we'll compare the OSI reference model to an actual TCP IP protocol stack that we use today. So I 'll see you in just a

0:00So here is a little representation of our network. Here is our client computer, and here is the server they have not moved since the last video. And here are our options for identifying what's happening behind the scenes. The OSI reference model, as I mentioned in the previous video, is just an idea. And it was created decades ago, just as a logical way of representing what has to go on in the brain of this computer before it starts sending the data over the network, that'll then be forwarded to the server who then process it. So with that in mind, that this is just an idea.

0:30It's not a real set of protocols, and a protocol is a fancy word for saying a set of rules. So for example, as I speak to you, I'm currently speaking in English, and there are certain rules that are set up regarding English. And if you understand how English works, and I understand how English works, we can communicate together. Now, if I understood French, which I don't, but let's pretend for a moment that I did, and I wanted to communicate with you in French, and you don't understand French at all, we wouldn't be able to communicate. So whenever you hear the word protocol, think of like an agreement or set of rules that two devices, in this case, the whole network, are going to agree to and understand, so they can go ahead and interact with each other.

1:07So going back to the OSI reference model, it's just an idea. Now, a long time after the OSI reference model came out, the Department of Defense in the United States came out with a protocol stack, an actual set of rules and agreements that could be used to communicate, and they called it, and they still do, the TCP/IP protocol stack. We'll talk in a little bit why they call it TCP/IP, but this is the actual Department of Defense set of protocols that can be run on a computer and a server, and if the network devices all in between them can understand that protocol as well, we can have the client make a request, have that delivered to the server, and then the server can respond back.

1:42Now, the DOD's TCP/IP protocol suite, or TCP/IP protocol stack, you call it a suite of protocols, think of it like a collection that works together, or you can call a stack that represents a set of protocols that all can work together, even though they created it. When they created it, it had four layers. They had this layer right here, and this one, and this one, and this one, but you can see how it didn't really match up to the actual reference model of just a real protocol that they created and that we currently use today. So here's the magic about where we're at today.

2:13Today, and I'm going to call this actual or real, because this is actually what we use today, we use the TCP/IP protocol stack. There's a couple different flavors, IPv4 and IPv6, but we use the actual TCP/IP protocol stack, but here's the catch. We actually borrow some of the names from the OSA reference model as we talk about and discuss the actual TCP/IP protocol stack that we use today . For example, here's the one-to-one match-ups, even though in the TCP/IP protocol stack, it has one layer called network access.

2:45We actually borrow and use the name physical, and also borrow and use the name data link to represent this bottom part here, which in the TCP/IP protocol stack is just called network access, but we borrow the actual names from the OSA reference model. Now, that was a period of time where that was established, and that is the norm today. So if somebody's talking about layer one or layer two in the TCP/IP protocol stack today, they're talking about this component layer one, this section. Think of it like that ingredient of the recipe, and layer two would be the data link.

3:18And then for the third layer here, the OSA reference model called it the network layer or layer three. In the TCP/IP protocol stack, they called it the internet layer, but once again, we borrowed the actual name from the OSA reference model as we refer to it today. Think of it like, you know, if somebody's name is Robert and we could go ahead and call him Bob, even though that's not its real name, we just use it as a reference, and everybody knows that we're talking about Robert. Same thing with the actual protocol stack we use today with TCP/IP, even though it's the actual protocol stack that was created with originally four big layers.

3:50We've sliced and diced and borrowed some of the layer numbers and names as we actually use the TCP/IP protocol stack today. Then at layer four is the same across the board. The OSA reference model has this compartment or layer called transport, and in the TCP/IP protocol stack, we actually have a layer four that's also called transport. And then for the best news is that these three layers of the OSA reference model, application, presentation, session, they've all been lumped together in one layer in the TCP/IP protocol stack called the application layer, and that's actually what we call it today.

4:22We call it the application layer, and nobody calls it layer five. We just call it the application layer. So going forward, as we take a look at the individual details that a computer has to do as it communicates across the network, we're going to be using this column right here, which is a representation of the TCP/IP protocol stack that is a real protocol, and we're going to borrow some of the layer numbers and labels that were in the original OSI reference model. So going forward, just to be clear, we're not going to be talking about details of the OSI reference model, other than just memorizing the layer names with things like, "Please do not throw sausage pizza away."

4:57And also, as we talk about TCP/IP and use it, we're not going to be actually referring to the network access layer, but instead, we'll be talking about layer one physical layer and layer two data link layer as a representation of the individual components happening in the network access layer in the TCP/IP protocol suite. So in short, our winner is right here and going forward, and for the balance of the entire course and everything I talk about from this point forward, when we talk about layers and names of layers and individual ingredients in the recipe of getting a computer network to operate, we're going to be using these representations with layers one, two, three, and four, physical data link network transport, and then up here, representing what was in the OSI reference model, the top three layers, we're just going to call it the application layer.

5:42So to really dig in and understand now the TCP/IP protocol stack or the suite of protocols in the TCP/IP protocol suite, using the numberings and the labels that we just described, in the next video, I'd like to take each individual component, like one recipe ingredient at a time and give you a real world example of what they do, how they work, and then as we build layer by layer by layer, it'll help fill in the gaps and show us a behind-the-scenes tour of what's happening when computers on a network are talking with each other. So we're going to start at the top with the application layer, and we're going to do that in the very next video, so I'll see you there in just a moment.

0:00Now, as promised to better understand logically what has to happen at a client, for example, right here, when it's communicating with the server right here and when it makes a request and the other gives a response or an answer to that request, we're going to be using the TCP/AP protocol stack as we discussed in the previous video and we're going to break it down one section at a time. It's like taking a recipe and breaking it down into one ingredient at a time and then we'll take a look at their relationship to each other. So we're going to start with the application layer. Now, what exactly does that mean, the application layer?

0:32And sometimes it's referred to as a service, like an application layer service. Now, what is an example of an application layer service? It's pretty much what you want from the network. For example, if this client right here opens up a browser and they go to www. server.com, I'd like to ask the question, what is it that the client's expecting to have happen as a result of opening a browser and going to www.server.com? Well, the answer is, of course, they want a response back. They want to go ahead and have their web page fill in with the response from that server.

1:05So what the client is actually requesting in this example would be an example of a web service like HTTP is an example of an application layer service. So HTTP stands for Hypertext Transfer Protocol and there's a secure flavor called HTTPS. But think of it like an example of an application layer service. That's why I'm putting it here in green. I'm going to jot down HTTP. And then I'm going to put it in a web like a web page. Now, in current networks, we're moving a lot more to things like HTTPS. That's a secure flavor of web services. But for now, I just want to provide a single example here of HTTP as an example of an application layer service.

1:41Now, what does an application layer service like HTTP look like? Let's get real. Let me show you. Let's go to client and I for a moment. I'll demonstrate this for us. We'll go to client and we'll open up a browser and we'll ask to see the content at server one. That's server one.nuggetlab.com, which is here in a lab environment. So here is my little client nug computer. And if we open up a browser, I've got a shortcut here on the taskbar for it. I'm going to click on Chrome there and I'm going to go to this URL. It's a fancy way of saying the name of the site you want to go to and it's HTTP colon slash slash server one.nuggetlab.com.

2:16So I'll click on that and that's my web request and now I got a web response because I specify that I wanted to use HTTP. That's the application layer service that used. So that's one example of an application layer service is HTTP that's being used to serve up web pages. Now, a long, long time ago in a galaxy far, far away, there used to be a thing called a phone look where you could actually look up somebody's name and then find out, for example, what their phone number was. I know we can look it up online now, but behind the scenes, this computer right here, client nug, if it wants to go out to server one.nuggetlab.com, that is an example of the name of that server or that service.

2:52However, behind the scenes, when computers communicate over an IP network, they are going to be using IP addresses. So here's an example of some IP addresses. We have one right here for a client. I think of that address. That's an example of what's called an IPV for address. We'll have future videos and skills regarding that, but an IP address, basically think of it like a street name and a house number. And so the client has a house number on a given street and so does the server. So the server is up here. So on the client, it's like 10, 10, zero. Think of that like a street name and 50 would be the house address on that street for this client computer.

3:28And in the server, we can think of 10, 40, zero. Think of that like a street name and think of dot 100 as the house number, if you will, on that street. And it will take a closer look later at those details. But the important part here is that if this computer right here, client nug wants to communicate with the server, it needs to know what that IP address is. So if we as a user put in the URL of http colon slash slash server one that nug getlab.com somehow this computer needs to know what the actual IP address is for that computer.

3:59So it's going to use yet another application layer service called DNS to make that request. So DNS stands for domain name system. Think of it like a lookup for IP addresses. So behind the scenes, the computer, it wants to know the IP address of server one dot nuggetlab.com. We can see right here in my lab environment, it's 10, 40, zero, 100, but the client doesn't know that yet. So it would use the client behind scenes would use DNS to make that request to find out what the actual address is. So as an example of another application layer service, I'm going to put DNS right here.

4:31And below it, I'll just write name lookup because that's what that service is providing. So one of the questions might be, well, who are we going to ask if we're using DNS? Who are we going to ask? So perhaps this client here in their local network has a DNS server that can interact with the internet or perhaps the client is connected to a DNS server out on the internet. So in this example, if we're connecting to a server inside of our company, it's very likely we also have a DNS server sitting inside of our company as well. So the computer would reach out to its DNS server and say, hey, I need the IP address for server one dot nuggetlab.com.

5:04And the server would respond back to the client. And then with that information, the client could continue his processing to forward a packet out to the actual IP address of that server. This example is 10 dot 40 dot 0 dot 100. And as an example of DNS, let's go back to this client machine and then we demonstrate DNS in action where this client is making a request to determine the IP address of the server. So here is our client. Let me go ahead and close that Chrome window. And let's go to a command prompt. And on a Windows computer, if we use the command IP config, it'll show us our information regarding our IP address.

5:35Again, we'll come back to that later. And if we type in IP config space slash all, it'll also tell us who are DNS servers. And right here, it's indicating who are DNS servers. If we made a request, for example, if I did a ping to server one dot nuggetlab. com and press dinner, before I press center, ping is just a connectivity testing tool just to verify we can reach it. So behind the scenes, even though as a user, I'm just typing ping behind the scenes, this computer is going to, if it doesn't already know, it's going to have to make a request to its DNS server say, Hey, what is the actual IP address behind server one dot nuggetlab.com cell press enter.

6:10And all of that just happens in the background in a flash before it starts to the ping to this IP address. And on a Windows computer, we can use the command IP config space slash display DNS to show the local DNS cache on this computer. So when the computer makes a request, it can store that information for a short period of time. And that way, if it's going to the server over and over and over again, it didn 't have to make the DNS request over and over again. So this is the cache on the local computer. So we wanted to go to server one dot nuggetlab.com. We made a DNS request for that to happen.

6:42And the response we got back, the answer we got back was, Hey, it's at 10 dot 40 dot zero dot 100. So these are examples of two application layer services. One where we're asking for web content, we want to see it. And behind the scenes, what we also just demonstrated was another application layer service being used called DNS, which is doing name lookup, where it converted and found out for us from a DNS server, what the actual IP address was that it needed based on the name of the server we're trying to go to. Now one other thing I really enjoyed doing, especially with the fundamentals of networking is let me go ahead and clean this up just a little bit.

7:16And let's talk about proving because it's always nice to hear a concept like, Oh, here's what happens. And here's what happens. But it's also really important periodically to validate and prove that what we think is happening is happening. So I'm going to go ahead and share with you a little tool called a packet capture, more specifically, it could be called packet capture software. And one of those out there that's super popular and it's free is called wire shark. So what we could do is we could run a wire shark right here on this local computer.

7:47And what it would do, it would capture all the packets and traffic. They're going in and out of this interface. And then put them in a nice interface so we can actually see the actual packets and traffic that's going in and out. So I'd like to share with you a packet capture with wire shark and just confirm that HTTP and DNS are both being used. So to do that, let's go down to client one and we'll start a packet capture. So here at client one, I'm going to go ahead and close the command prompt and to start a packet capture here, I have a shortcut on the desktop of client nug right here, a little fin of a shark and that is the taskbar shortcut for wire shark.

8:24And then I'm just going to tell it to go ahead and take a look at my network card that I have connected to this lab network. And now it's capturing traffic as it sees it off the network. So I go ahead and minimize that and let's generate some traffic. So let's go ahead and do a few things. Let's go to a command prompt here and I'm going to clear the DNS cache. So earlier we did the command IP config space slash display DNS. So we've already learned what the answer is about the IP address for our server . I want to go ahead and clear that and make it happen again. So we're actually sending out another DNS request.

8:56So we'll type in IP config slash DNS. That flushes the cache. We'll hit the upper key a few times. Do an IP config display DNS and just to confirm there's nothing currently in the cache like the temporary saved location on this computer. So at the moment, it doesn't know this little windows computer doesn't know what the actual IP address is behind server one.nuggetlab. So if we did a ping over to server one.nuggetlab.com and press enter behind the scenes, it had to do a DNS request to relearn the IP address of 1040 0 100.

9:27We can verify that with or if you're on a Windows 11 machine, you can also use a dash, although the slash has been used for decades. And there's the answer that happened in via DNS. And so if we then go to a browser and we want to capture some HTTP traffic, another application layer service, we can use this shortcut right here to go to HTTP server one.nug getlab.com and I'll hit refresh a couple of times just to make sure we're not just playing it from the cache. Now that we have done a DNS request, we've also done an HTTP request and our packet captures running, let's go ahead and take a look at the results.

9:59So I'm going to open up the packet capture here. I'm going to stop it and then I'm going to go ahead and do something called a display filter just to filter out some of the traffic. So when I type in DNS press enter and this shows us just the DNS traffic. So there's a whole bunch of DNS requests. I'm going to scroll down until I see the one that's the DNS request and I'm looking over here on the right hand side. I'm looking for the DNS request for server one.nuggetlab.com and there it is right there. So if you look at the details for this and again, my goal right here is to help us be experts at Wireshark.

10:30But I just want to confirm that in this DNS request and oops, this is the response. Go one up. Here is the request. So here's the DNS, the domain name system query where the client is saying, hey , I really would love to know the IP address for server one.nuggetlab.com. Think of it like you want to go to your friend's house and your friend's name, but you don't know their address. Think of it like asking somebody, hey, for Steve or Bob or Ali or whoever it is , what is the actual address for them? That's a lot like a DNS request where we know the name of the server we want to go to, but we don't have the address and so we make a request.

11:01So here's a request and at the application layer here, this is the DNS that's being used. And then for the packet right below it, that is a response coming back and the response that came back said, hey, that server is at this IP address and we'll open up the answer to see that. So here's the address right there, 1040, 0100. So before we get too wrapped up in the individual details regarding Wireshark, the main purpose of that demonstration was to help reinforce two examples of application layer services, what we want. For an HTTP, we want a webpage effectively.

11:34For DNS, we want the information regarding the address for a server like server one.nuggetlab.com. And those are two examples of application layer services. But not the only two, there are hundreds of different application layer services, but these are two great examples of application layer services. Now just like building a house with a foundation and then first floor and second floor and third floor, et cetera, each of those layers depends on the one below it. So even though we have these application layer services, we have other functions that we need to call upon and use to actually make the request able to go from this client up to the server.

12:09So in this video, I'd like to take it the next logical step, still using HTTP and DNS as an example and talk about some of the protocols that are used, some of the rules that are used in the TCP/AP protocol stack at layer four. And that'll help us better understand the logical process that has to happen at layer four to support the application layer services. So I'll see you in the next video as we take a closer look at the transport layer, layer

0:00We are going to continue using this as an example of a client who's accessing a server up here and that's server one. In the previous video, we took a look at two application layer services. One was HTTP, which think of it like web services, getting a web page. And the other we looked at was DNS, an acronym for domain name system, which is the way to look up the actual address like the street name and the house number for a computer or system you want to go to. But you don't know that yet, so you make a DNS request and say, hey, for this server one.nuggetlab.com, what is the actual address behind it?

0:33Again, these are two examples of application layer services. So I'm going to go ahead and put those in green and that way they match our color coding here for the application layer. So let's go back to this computer here, client nug, as we continue our discussion. Now the application layer is just one component of what this computer needs to put together before making that request. There's also going to be as part of the TCPP protocol stack. There's also layer four information that needs to be included. And that's because these application layer services have specific layer four protocols that they're built or designed to use.

1:06And so as part of making a request, the computer would not only specify the protocol at the application layer they want to use for the request, but they would also specify the layer four transport protocol needs to be used in combination with that application layer service. So for the transport layer, let me go ahead and try to match that color here. So I'm going to go ahead and put a little arrow that represents layer four, the transport layer. And this top one is the application layer. I'll put app for short. And our two examples are HTTP and DNS as application layer services. And let's start with the DNS request. When we type in the name of the server we want to go to, behind the scenes, if our computer doesn't already know what the address is for that server, it's going to make a DNS request.

1:45And at layer four, for the original flavor of DNS, it's going to use a layer four protocol called UDP. And that stands for user data gram protocol, but we don't really need to memor ize the actual full name, we can just call it UDP. And UDP is a layer four transport protocol that's used with the original DNS. Now there are some varieties and other flavors, but we're going to stick to the basics here and just say that DNS, the application layer service, uses the layer four transport layer protocol of UDP. And let me explain the logic of how UDP works.

2:15UDP has the opinion of not really caring or checking to see whether something arrives. So let's imagine we have ourselves. So this will be you and I, I'll call it us, to here and we'll have our neighbor over here. And we'll go ahead and identify that we're both happy. And this right here is going to represent a wall between us. So with UDP, here's the attitude. We're going to take some data and we're just going to send it over to our neighbor, but we're not going to know whether or not that neighbor got it. Think of it like throwing a brick or something over the wall and you assume it 's going to land, you hope it's going to land, but you just don't know for sure whether it 's going to land or not.

2:52That's the attitude of the UDP protocol at the transport layer. It doesn't do anything on its own to verify or check to see whether it arrived or not. It's something that takes the data or the request is going to be made and ships it over and hopes for the best. Now in the event the neighbor sees it and responds back, that's a good indication that it works, but by itself user data gram protocol, therefore doesn't do any checking. Think of it like throwing a brick over the wall and hoping it lands. And that's the protocol at layer four associated with the original DNS. In fact, we have that protocol capture we just did. Let's go back and take a look.

3:23So here is our protocol capture and let's go ahead and take the query. Here's our request for server one.nuggetlab.com. And if we collapse the details down here, here's our DNS request. And then just below that, now in this protocol analyzer is showing the application layer information at the bottom and then the transport layer and then it goes down, down, down. So this represents the layer four transport protocol that's being used by DNS. So again, the DNS is an example of an application layer service. What we're trying to do, we're trying to resolve or find out the address for a server and then layer four it's using the user data gram protocol.

3:59And so behind the scenes, the client computer is adding that layer four information regarding the UDP header and that detail before it sends that request out on the network. Now not every application layer service is going to be using UDP. Another example of a layer four protocol that HTTP uses is TCP. Let me go ahead and put that in the same color here as our transport layer. So put TCP right here and TCP at the transport layer uses a different attitude rather than just sending the data and hope it arrives. So let me go ahead and clean up this little analogy here for UDP where we're just shipping it over and hoping it arrives and compare that with a reliable layer four transport protocol called TCP.

4:39So with TCP I like to think of it like two people that are going to have a discussion. Now one of the things that I've discovered and I've been on the planet for a while, one of the things I've discovered when two people communicate is that if we just shout something out immediately the receiver may or may not receive it or understand it correctly. So sometimes it deserves a little warm up conversation. So if we see our neighbor we might say something like, "Hey, beautiful day today." And then our neighbor might say, "Back, sure is." And then we might say, "Back, hey, have a great day." Now at that point we know we're talking to each other, we know we have a communication path between each other and as a result if we start communicating about sports or about something else we know back and forth that we have a reliable communication.

5:20So if we begin talking about sports or some other topic it's not like the neighbor is going to think, "Oh, he talking to me?" They know they're talking to each other because they already have that initial dialogue. And so in the world of TCP that's a lot like an initial warm up conversation before we start talking about sports or some other topic between the client, in this case the neighbor on the left and the server and example that be our neighbor. So again here in our real example we have our client here and our server here. So for application layer services that use TCP they have a little warm up session before we start making a request.

5:52So a TCP is called a three way handshake where the client sends a little request out a synchronization request that's called saying, "Hey, I'd love to chat with you." And the server then sends a response back and that's called an ACK. So I'll put the client here on the left and the server here on the right. And the ACK is short for an acknowledgement. And the server is also going to want to make sure that from its perspective the client's willing to talk to it. So in addition to that acknowledgement it'll also send its own synchronization request and they call that a CINAC. It's sent to actually one packet with both those elements included and then if the client wants to continue that conversation it'll go ahead and send its own acknowledgement back.

6:26So think of this little TCP three way conversation like the little warm up conversation between two neighbors before they start talking about sports. In this case that little warm up session with TCP is called a three way handshake. And assuming that that three way handshake goes well we've just confirmed that the client and server can talk to each other, they're willing to go ahead and communicate. And then once that three way handshake happens with TCP they can start negotiating and setting up the actual request for the application layer services. Now the cool thing is because we already from the client went to the server for our web request with HTTP and because I still have that capture open we should be able to find that TCP three way handshake as part of the HTTP session.

7:10So let's go take a look and verify that what we think might happen at layer four with the TCP protocol being used to support HTTP let's verify that it is. So back to the packet cap for we go and I currently have a little filter here saying only show DNS on that type of HTTP press center and here's our HTTP session and just for ease of use I'm going to right click on one of these and say please follow the HTTP stream which is going to include the TCP and here it is right here. So there's the HTTP conversation I'm going to go ahead and close that because what that also is going to do you put that filter in for us we can also see here the three way handshake that happened just before the HTTP so here's the actual HTTP request and at layer four it's using TCP but before it actually made that request it had that warm up conversation and this is an example of the three way handshake from the client saying hey I'd like to go ahead and communicate with you and they call that a send request as shown right here the server responds back with an acknowledgement and its own send request again send a search for synchronization and then we have the final acknowledgement from the client going back to the server so our three way handshake is right here and then presuming that went well which it did we didn't have the client making an HTTP request so again just to confirm that TCP uses a three way handshake it also uses

8:27confirmations and acknowledgments periodically just to make sure that all the data that's being sent back and forth has been received and processed correctly so that's why periodically here after our request for the website we also have a TCP acknowledgement right here just validating that the data was received and it'll continue on periodically again until that TCP session is closed so what is the takeaway from this the takeaway is that at the application layer we have services that we want to have happen or receive for example web services or name resolution with DNS and at layer four each of those application layer services have a predetermined layer four protocol that they are going to use to assist with those requests in the case of HTTP it uses TCP which has a three way handshake it's considered a connection oriented and reliable protocol because of the checks and balances that happen for the TCP session and then the original flavor of DNS domain name system is an application layer service used to request the IP address or address for a server and behind the scenes at layer four it's using UDP and again UDP is like throwing a brick over the wall there's nothing specifically at layer four that's going to guarantee that the request that we send for DNS is going to make it or not hopefully we get a response and then we 're good to go so a typical client if it makes a DNS request with UDP there's a problem with

9:45the network and the client times out in the background it's very likely just to go ahead and make another DNS request and another until it gives up and again most of that is transparent to the user unless there's a failure and it actually never gets a DNS response which would cause a failure for us to identify what the IP address is of the server and we would never get there so let me clean that up just a little bit and let's talk about yet another challenge when this client is attempting to go to this server and let's imagine it's already done the DNS request so it knows exactly the IP address needs to send that traffic to not only does this client need to know what that IP address is but it also needs to include that information in the traffic in the packet before it sends it out and that my friend is one of the primary responsibilities of this layer of the TCP/IP protocol stack the network layer that's also the layer of the protocol stack that we're going to look at in close detail in the very next video so when you're ready I'll see you there in just a moment.

0:00In the previous video, we identified that HTTP at the application layer uses the services of TCP at layer 4 and the TCP is connection oriented meaning it's checking and validating that the connection state is good and the receiver received all the data. For example, the client went and sent a request, it did the three way handshake, validated it, it could communicate with the server and then once that three way handshake was done, it then was able to make the HTTP request and get the content on the screen of this client computer. And then periodically with TCP, it's going to validate that all the data that was sent received actually made it to the other side and was acknowledged by the other side. One in the case of the original favorite of DNS, the main name system, when it makes a DNS request, that request doesn't use all of that overhead at layer 4 because it's using a different layer 4 protocol, in this case UDP, which is like throwing a brick over the wall. So if that request never makes it, it's just going to time out and DNS is going to think, well, I guess it didn't make it, maybe I do it again. Because at layer 4, there's no synchronization or testing or validation that the actual request ever made it. So with that in mind, as we work our way down the protocol stack, we're now going to focus on the network layer and what is included at the client machine in that network layer information before it actually sends that traffic out on the network.

1:12So I'll go ahead and make this new section here called the network layer. I'll put a little arrow there to represent. That's what we're talking about right here. I've also color coded it. And there's one primary thing that's going to be included at the network layer and those are addresses. Specifically IP or internet protocol addresses. Again, for right now, let's just think of an IP address like the street name and the house number. And on a computer network with IP, the street name is called the network and the house number is called a hosted rest. But for now, we'll just use the analogy of a street name and house number. So this client computer needs to include that information before it sends that traffic on the network so that the network knows who to deliver the traffic to. And that's what layer three is all about. So in this example, where client nugged down here is a client at 10 dot 10 dot 0 dot 50, that's its address. And that's the source address of the client who's making the request and the servers address, which we'll call the destination address for this request, that destination address will be 10 40 0 100. So the client before it's going to even send the data out on the network, it needs to include that information about what IP address is this coming from my address as the client computer.

2:20And what is the IP address that we want to send it to, which is the IP address of the server. And all that information is included at the network layer. Now in the world of IP in a protocol, there's IP v4, there's also IP v6. And these addresses you see here and this topology and right here and here, those are examples of IP v4 addresses. And we'll have further discussions in great detail about both IP v4 and IP v6. But for now, those are the addresses that need to be included in the headers. Now, good news. When we did our initial requests with HTTP and with DNS, and we captured it, we should also be able to see at layer three for the HTTP request, we should see at layer three, the source address of client nugge and the destination address of the server.

3:04And for DNS, we'd be able to see the source address of the client and the IP address of whoever the DNS server is this client had been configured to use. So to reinforce that, let's take a peek at that same packet capture for the HTTP. We'll verify once again that it's using TCP at layer four, and we'll also verify at layer three, the IP address information, which is right there. So let's go back to that same packet capture and take a look. So back to the packet capture we go. And here's our HTTP request. So here we have at the application layer, it's HTTP, that's an acronym for the Hypertext Transfer Protocol at layer four, just reconfirming that we're using TCP, the Transmission Control Protocol, and then at layer three, if we take a look at that, right here, it includes at layer three, the source address, that's the client 10, 10, 0, 50's address, and the destination 10, 40, 0, 100.

3:54So that's the primary function of layer three is to include the IP address information. Also referred to as the layer three address, because at the end of the day, an IP address at layer three is really a layer three IP address. So either way, it's the IP address that's associated with layer three of the TCP/AP protocol stack. So in the capture, we were able to identify that at layer three, it had the source address of the client at 10, 10, 0, 50, and the destination address of the actual server at 10, 40, 0, 100. I also had a point out and remind you that all this information that's currently happening is being done by our computers in the background just by us making a few simple requests. So in the background, it's identified what the layer four protocol needs to be based on the application layer service that's being used. And then furthermore, based on the IP addresses involved, it includes the source and the station IP address in the layer three component or compartment or layer of the protocol stack. And if a client doesn't know, for example, what the IP address is of a server like server one.nuggetlab.com, it will simply make a DNS request, get that IP address, and once it has the IP address of the server, it can then include it in the request for HTTP services. At that point, use HTTP for the web service request, which is using

5:11TCP. And then at layer three, as we go down, it had the information regarding the source and destination IP addresses as we just identified in the packet capture. Now, after all this work that's been done right here in the brain, if you will, of this client computer who wants to make this HTTP request, are we done? And the answer is no, we're not done yet because we have two more layers of detail that we want to break apart and identify. So in the next video, we're going to leverage our existing HTTP session that's using TCP layer four, and at layer three has the IP address information. And we're going to take a look at what else is added and needed at layer two in the TCP protocol suite. So we'll discuss that in the next video. And I look forward to seeing you there

0:00So as we continue our discussion, let's focus in on our HTTP session. Think of it like our web request that we're going to be making in order to server one. That's an example of an application layer service. And as we discussed in our previous videos, HTTP at the transport layer uses a protocol called TCP. Now, who gets to choose that? Like, do we as a user say, "Hey, I want to use TCP or UDP?" The answer is no, we don't get to choose that because those are coded or planned on. When the application layer services are set up, they already have identified which layer four protocols are going to use.

0:31And then our computer just does all that background work to include all the right information to make the request. So at layer four, our computer is logically adding the correct protocol information for the request. And in HTTP, it's going to be using TCP. And then at layer three, it's going to be adding the information about the addresses. Again, think of an address like a street name and a house number of how to get somewhere. On the case of an IP network, the source IPV4 address here of 10, 10, 0, 50, and the destination IP address here of 10, 40, 0, 100. And so I'm going to put IP addresses.

1:01And I'm also going to put S and D, just to remind us that's going to include at layer three, the source and the destination IP address. And that's important because if the client makes a request up to the server, and the server wants to respond, it needs to know who to send the response to, based on the IP address. So next, let's focus our attention on the data link layer. Also referred to as layer two of our TCP/PP protocol stack. And at the data link layer, we are also going to be including addresses, but these are what we refer to as physical addresses. You might say physical addresses, what do you mean? And we talk about physical addresses.

1:32Let me give you an analogy that's going to help. Now, in many communities that I've lived in over my lifetime, we have a street. So let's imagine these are the houses. So if this is Elm Street, and this is house 101, and this is 103, and 104, and this is 102, and 105, let's imagine we want to deliver some mail to one of these houses. Now, if we had mailboxes at every single house, that'd be great, but in many communities I've lived in, they have a group mailbox with just slot number. So let's imagine we have slot one, and two, and three, and four, and five, and six, and seven, and eight, and nine, and ten, and eleven, and twelve, and thirteen, and fourteen.

2:09And I just realized I have way more mail slots that I need. So I'll call this our community mailbox. So if the mail person received a piece of mail, and they need to put in the right box, we'd have to have some way of knowing, okay, for house number 101, which mailbox number you have, or for 105, which mailbox number do you have? Let's also add house 100 here as well. So let's imagine for our discussion that house number 100 is using mailbox 13. So there have to be some correlation or knowledge between the actual house number, like the address on the Elm Street, and which mailbox number that mail should go to for that house.

2:46Now, how is this applicable in a network? Each network device, like this computer right here, with this network interface card, and this little computer here with this network interface card, and this wireless computer with this network interface card for the wireless network, each of those have their own burned in from the manufacturer a hardware address , a physical address. And that's associated with their network interface card. So if you see the term "NIC", if we're not talking about a person named "NIC", a NIC refers to an acronym network interface card. It's the actual component on the computer that lets it communicate on the network.

3:18So each network interface card has its own unique physical address that's burned in from the manufacturer who made that either that computer with network adapter, or who made that network adapter. Now, this physical address, good and bad, it has many different names. So it could be called a physical address, think of it like because it's part of the physical card, whether it's a wireless physical card or a physical network adapter. It also can be called the "Layer 2 Address" because its address, that physical address is associated with "Layer 2" and the "Protocol Stack". It also could be called the "Mac Address" and not "Mac" as in Apple products, but "Mac stands for Media Access Control". So if you see a "Mac Address", they're talking about the burned in address on these network interface cards.

3:59And because it's burned in, sometimes you'll see it as the "BIA" for burned in address. And I've also seen it referred to as the "hardware Address". And that's because it's the address that's given to that specific network interface card, that physical piece of hardware, for example, that you're using on your computer to communicate on the network. So basically we have five names for the same type of address. Physical address, "Layer 2 Address", "Mac Address", "Burned in Address", "Hard ware Address". They're all referring to that address that's given to the network interface card. So, for example, if we took a look at this interface right here on ClientNug, and if we took a look at this address here on this network interface card on the router, and that router interface right there is "GIG" for "GIG-A-bit Ethernet", and that happens to be in this topology 2/0, if we were to take a look at those two interfaces, we could actually see the special physical address, or a layer two address, or "Mac Address", or "Burned Address", or "Hardware Address", whatever you want to call it that's been given to that network adapter.

4:53And that is 12 characters long. And it's implemented in what's called "hexadecimal". So you and I, in our dating dealings, we deal with "decimal". decimal. Let's zero through nine then you get past nine and you carry the one and start over; with hexadecimal it's zero through fifteen except for those last characters it goes like this zero, one two three all the way through nine and then because there's 16 different characters for the ten it goes to A and then B and C and D and E and F; for a total of 16 characters one, two, three, four, five, six, seven, eight, nine, ten, eleven, twelve, thirteen, fourteen, fifteen, sixteen.

5:31So the burned-in address, the physical address is twelve characters long, it is allowed to have some A, B, C, etc. in it up to F as well as zero through nine and those are all valid characters that can be used by the manufacturer as they assign and address a layer two address to an interface and as reinforcement of that let's go over to our client and egg machine and take a look, we'll also take a look at our router's interface here just to verify that no matter what type of network card or who the manufacturer is all of them are going to have this 12 hexadecimal character long MAC address associated with them. So if we go back to our client this is client nug, we'll go back to a command prompt here and we did some IP config earlier so let's go ahead and let's do an IP config all by itself and press enter so IP config that command on a Windows computer will show us the IP address that we currently have and if we use the command IP config space slash all or dash all it works on the current flavor of Windows it'll show us more information including this information right here. So this is an example of our physical address our layer two address our hardware address our burned and address on this specific Windows 11 computer and it's zero zero fifteen five D zero zero zero zero zero zero eight. So I'm just remember this Windows computer ends in zero four zero eight. So back in our topology and let 's take a look at this interface right here on this router. So in my little

6:48lab environment which I'll put you on a little bit later in this set of videos on this interface right here which is gig two slash zero on the Cisco router it also has a layer two address based on that network interface card that's right there. So let me show you that as well. So here we are at what's called the CLI the command line interface for a network device this is a router from Cisco systems and most routers are gonna have some way of looking at the details whether it's a command line or a graphical interface or both. So here if we do a show interface and also gigabit two slash zero those show us the physical interface characteristics for that specific interface. So if we press enter there there's a lot of output here but the part I want to get to is this right here. This is the layer two or hardware address or burned in address that's being used on this Cisco router ending in zero zero three eight. So some vendors will have four characters in a period on our Windows computer if we go back there it was using two characters in a dash and two characters but at the end of the day we're looking at a total of 12 hexasimal characters. So in this case there's four there's four more for a total of eight and four more for a total of 12. So on the router it's ending with zero zero three eight. So as we go back to our topology and let me clean this up a little bit we now know based on what we just looked at that this client and I got its network interface card its layer

8:05two address its physical address its Mac address its burned in address its hardware address ends and I wrote this down in zero four zero eight the little dots in front of it and this router on its interface which is interface gig two zero on that same local network its layer two address its Mac address its physical address its burned in address ends in zero zero three eight. So put three dots there zero zero three eight. So when this computer right here client that needs to send a frame of data some data over to its default gateway to the router at layer two the data link layer it's going to include the information about the source layer two address which is ending in zero four zero eight and the destination address of the router here at zero zero three eight and that way the network in this case a switch can make a forwarding decision and make sure that data gets from the client to its default gateway here which is router one. Now to help us in verifying that the good news is that we have a capture from earlier where this client was actually trying to communicate with a server and behind the scenes when a client needs to send traffic to a different network. They're gonna like the client lives on 10 10 zero street and the server lives on 10 40 zero street a different street in that case the client is going to forward it at layer two to its default gateway so the gateway think of it like a router

9:20can make a decision and forward it on its way. So all of our captures that we did that involve traffic where this client was actually using its default gateway should at layer two have the source address of zero four zero eight and the destination address at layer two of zero zero three eight because that's what the client computer would need to include at layer two to make sure that traffic got forwarded to the right next device in this case is default gateway. So let 's go back to our packet capture and look for zero four zero eight as a source and zero zero three eight as a destination. So let's go back to the right computer and here we go this is our client and add computer woman to my zat and we'll go back to our capture that we made earlier and let's go ahead and we can use pretty much any of these packets. So let's go ahead and take our HTTP request right here. So the application layer here's our HTTP request at layer four. There's the TCP protocol that was being used at layer three. We have the IP address information for source and destination and layer two. Let's go ahead and expand that. We had the layer two information primarily including the source layer two address and this is the one from the client ending in zero four zero eight and then look at the notes that's the right source address going to the layer two address of that client's default gateway which ends in zero zero three eight. So that's the purpose or the function of the layer two information

10:37also called the layer two header is to include the layer two address information. So if we look at the big picture when we simply go to this client and we open up a browser and we say we want to go to for example server one dot nuggetlab.com in the background is very likely if it has already learned the IP address or the destination address of that server it will behind the scenes to a DNS request to find out that information from a local or internet DNS server and then once it has the IP address it'll then turn around the client will and the computer will make that HTTP request which is using TCP at layer three it'll have the source IP address and destination address for that traffic flow it'll also have the physical addresses for the client and the default gateway. Now if the server was on the same street leave like this if the client was right here on Elm Street since our client and the server was on that same street Elm Street the client would need to forward the traffic to a router to forward it out to some other destination the client and server could talk locally on the same network however because most of our traffic is not on the same exact local network as we are most of the time our traffic is going to go to the default gateway or to a router who can then make a routing decision and send that traffic on its way. So at layer three we're going to include the IP addresses the source and destination and at layer two we're going to include the physical addresses that are involved in this case the client nug

11:55source physical address it's hardware address ending with 0408 and the destination layer two address of its default gateway at 038 and then the last step is to get going already and send it so the physical layer represents the physical connections the digital and electrical signals that are being sent over the network including wireless signals that are being sent and the standards regarding those. So in wireless we have something called Wi-Fi with a few different flavors and standards for Wi-Fi and the protocols are used there and for Ethernet we have different standards for various types of Ethernet including 100 megabit ethernet which is called fast ethernet and 1000 megabits per second which is called gigabit ethernet and we also have 10 gig or to gig and so at the physical layer we're talking about those physical components the electrical signals and the standards allowing that data to flow over the networks and the cool thing is this computer is doing most of that work in the background force all we did was you know go to a browser say we want to go to this web server and in the background it was doing all the work of identifying what the application layer services is going to be and the layer four protocols the source and destination IP addresses the source and destination physical addresses and then spitting that data out on the network and that process where this computer is taking all these components first of all the

13:13HTTP and then adding on the TCP information and then adding on the IP address information and adding on the physical layer information for the layer two addresses that process is called encapsulation and think of encapsulation like simply adding on and adding on and adding on the individual components that are part of the TCP/P protocol stack and so when we're starting at the application layer and we're adding on the individual components for each layer that's called encapsulation and when that traffic is received at the server guess what it's going to do it's going to go ahead and start the process of de-encapsulation as it looks at the individual components involved in that request coming from the client now to help reinforce the concept of encaps ulation I have some little tools I'd like to use and they are known as cups so we can think of you know one cup for example being the application layer and then putting that inside of another cup and that would represent the transport layer and then putting that in yet another cup which represents adding the additional information for the network layer the IP addresses and then putting that in another cup which adds on top of all that information regarding the layer two addresses and then finally that data is going to be sent over the network as a stream of bits and it's up to the network to correctly move that data in the correct direction towards the server who can receive it and de-encapsulate it and to help reinforce the concept of encapsulation I've got a little exercise with literal physical cups that I think you'll love and that's in the next

14:29video so we'll see you there in just a moment

0:00To help reinforce the idea that this computer is going through all the work to make that HTTP request for us, including adding the data at each of these layers that needs to be there, I'd like to go ahead and use an analogy with some cups. And the overall picture is this, when we have an application that you're a service like HTTP, the computer before making that request is going to add the additional transport information. Again, this is called encapsulation. So think of encapsulation like adding onto, it takes that HTTP request as the appropriate layer for protocol, which in the case of HTTP is TCP, then it'll add on the appropriate information regarding the IP addresses. Again, this is just adding an additional component or layer with that information, and then it'll add on the appropriate layer two address information, that's the physical addresses or MAC addresses that go by both names. And it's up to the network to deliver that request that the client's making over to the server. So to help reinforce this, let me go ahead and show you an example of this using cups. So earlier we had a computer that was physically connected to the network with this physical patch cable. So I'm going to move those to the side just for a moment.

1:02And let's talk about the process of encapsulations. Let's imagine sitting at this computer, the client does an HTTP request to get access to a web server. So that's an example of an application layer service. So what comes next? I'm likely to think with me for an application layer service like HTTP, which is an example of an application layer service, or sometimes referred to just as a network app, there's a layer for protocol associated with HTTP. Now, in addition to having the HTTP request here, we also need to include before the computer sends it out, we also need to have that computer include the layer for protocol associated with the application layer service. So HTTP, the application layer service called HTTP, uses that layer for it uses the transport protocol called TCP. So the computer would go ahead and add the appropriate information, and that's called encapsulation. So we have the original HTTP request, it's now included the transport or layer for information in the case of HTTP that's TCP. And then we need to add on the layer three information.

1:59And that layer three is referred to as the network layer. And that's going to include the IP addresses, the source IP address of this computer and the destination address of the server. Also, before the traffic is actually sent from this computer out the network, it also needs to include the appropriate layer two information. And that layer two information would be added. And that's the data link layer. And as we discussed that data link layer information would include the layer two address information, both the source, which would be the source layer two or MAC address or burn in address on this computer, its network interface card right here, as well as the next top in the path. So if we were forwarding traffic to our default gateway, so we could forward that packet out to the actual server, the destination layer two address would be the layer two address of our router. Just like we talked about in the demonstration with Wireshark with our computer, its source MAC address ending in 0408 and the client's default gateway on that same local network, where its layer two address ended in 0038. And then last but not least, once all this encapsulation has been done here inside the mind, if you will, of this little computer, the client PC, it'll then go ahead and shoot that information out the network.

3:06So whether it has a wireless network adapter or it has in this case a physical network adapter, in both cases it's referred to as the physical layer. Think of it like FedEx. If FedEx is delivering a package, they've got trucks that deliver it. So what they're delivering are packages and they have all kinds of addresses involved. But at the end of the day, it's the truck that's actually moving it. So think of the truck like the actual physical components and electrical signals that are being used to actually send that information over the network. So this encapsulated data, including the HTTP, the application layer, and in the case of HTTP, the transport layer, layer four using TCP and the network layer layer three, which includes the source and destination IP addresses and the data link layer, including the source and destination layer two addresses, all that's included and encapsulated before shipping that data out on the network. And this, my friend, represents the five basic components involved in today's TCP/AP protocol suite. I also want to point out at this point why we call this the TCP/AP protocol suite. It's because of the two major protocols that are being used at layer four. One of the protocols there, as we discussed, is TCP. That's part of the name, the TCP/AP protocol suite.

4:10And another big part of the protocol stack is the IP addressing itself, which is included at layer three. And so they took the term TCP from layer four and IP from layer three. And that's what we call the TCP/AP protocol stack or the TCP/AP protocol suite. And these cups can help you remember that we're doing encapsulation or adding of the individual components. And most of that work is done right here in the brain of the client before ever sending that data out of its network interface card. So to help reinforce even further the topics that we've talked about in this set of videos regarding reference models and now the TCP/AP protocol stack, in the next video, I'd like to put you on a hands on labs so that you can get up close and personal with TCP/AP and help reinforce the idea that using a model to logically, you know, separate each of the components is just an easier way of helping identify the whole process instead of calling it all magic. Because now we know that we have five specific layers, layer one, two, three, and four and the application layer . And by breaking it down and understanding what goes into each part is going to help us better understand how the network operates as a whole. So when you're ready, I'll see you in the next video for a hands on lab.

0:00To help reinforce a few of the concepts that we've discussed regarding the TCP AP protocol stack, here's the hands-on lab I'd like you to do. I like you to take a moment, you can do it right now if you'd like. If you're watching this on a computer, there's a link just below with a link for the hands-on lab. And on the hands-on lab, I'd like you to open up ClientN ug. And because this may be the first lab you've done with me, let me make sure you know exactly where to go in the lab to open the interface for that Windows 11 ClientNug computer. So here is the lab environment that's already launched and running. And right here is a picture of the lab topology, going to bring that up just as a reference. And here's the client-nug computer that we're sitting at right here. And there's the server that we're going to go ahead and access. So to get to Client Nug, once you have the lab open, you're simply going to go ahead and double-click on the icon right here for ClientNug.

0:47You'll double-click and it'll open up a window for that little virtual machine, that Windows 11 computer. So having said that, let me go ahead and double-click here on ClientN ug and that'll bring it up. That'll take just a moment or two. And it looks like it's here it comes. And I'll go ahead and click to make sure it's active in that window. And on the ClientNug computer, like you'd open up Chrome. There's a little shortcut for it on the taskbar on the very bottom of that Windows computer, or you can go ahead and launch it from the desktop. There's an icon there. And once you launch Chrome on ClientNug, then go ahead and go to this URL. Http colon slash slash server1.

1:18nug@lab.com in the lab environment. You can also just click on the bookmark if you want. That goes exactly that URL. And then once you've done that behind the scenes, what that would have done, if it didn't already know the IP address of server1, it would have made a DNS request. And then secondly, after knows the IP address via the DNS request, it would then make the HTTP request over to the server. So I'd like you to go ahead and do that to experience it. And then after you're done with that, I have as a convenience put on the desktop of our ClientNug computer, I have a file called DNS and HTTP capture. In fact, let's take a moment and verify that it's actually called that. And it's seeing there on the desktop of our ClientNug computer. So here on the ClientNug computer, on the desktop, here's that file of DNS plus HTTP capture. And I captured this earlier. So that way when we do the walkthrough, we'll have exactly the same information. So I'm going to go ahead and open that up. And I also limited the output to just show four packets packets one, two, three, and four, just to make it really clear on a couple of the sessions, the DNS request right here, and the HTTP request right here. And then below each one, I have the DNS response, and then the HTTP response. So when you click on these packets down below, it shows the details, including the application layer information and the layer four information and so forth for each of those packets. So what I'd like you to do regarding

2:34that packet capture is look at it and answer the following questions based on that capture. Regarding packet number one and packet number three, what are the application layer services involved for packet one and for packet three, and then for packet one three, what layer for transport protocols are being used? Again, that'd be for those two packets. And then looking at layer three information, that's the IP address information. What are the IP addresses involved with packets one and two, and that'd be for the source, as well as the destination IP addresses. And then finally, the layer two information, which would be the MAC addresses, sometimes called physical addresses or hardware addresses. Again, that would include the source and the destination . And just to confirm how to look at those components in wire shark, let me go ahead and show you that as well. So here in the packet capture, for example, you go to packet number one, and then here, the way the wire shark is showing this is the application layer information is at the bottom, and then it's going to layer four, and then layer three and layer two. So if we look at another packet like packet number three, at the bottom here, it's showing the application layer service, and then the layer four protocols using, and then the layer three protocol information, and then the layer two information. So that's how you can see the details regarding those, some of you are going to the packet in question, and sorting through it. Again, application layer is going

3:52to be at the very bottom. So with that in mind, have some fun with this hands on lab, and when you are done, and you'd like to do a walk through together, join me in the following video, and we'll do exactly that.

0:00So my objective for us in these labs is to give you the hands-on practice help reinforce and validate the concepts that we learned in the set of videos prior to the lab . So hopefully you've done the lab and now in this video they do a walkthrough of these lab tasks with you. So we're going to launch the lab, we'll go to the client-nug computer, we'll go ahead and do an HTTP request to server1.nuggetlab.com. And then we'll look at the pre-captured file called DNS and HTTP capture and answer the following questions regarding packet number one and packet number three basically asking what is the application layer service, what is the layer four transport protocol being used, what are the layer three addresses involved, the IP addresses if you will that are kept at layer three, and an IP header is another way of saying the information that's included at layer three and then also what's included at layer two, which would be the layer two addresses, the burn-in addresses, the MAC addresses, the hardware addresses based on the vendor using and what they choose to call them. So with that in mind, let's head back to the lab environment and let's do this walkthrough together. So back in the lab environment, I clicked on reset to go ahead and reset the lab back to square one. Also, as we go through these sets of videos and future videos together, if you want to reset the lab and start over, it's really easy to do, just use that reset option right here, give it a few minutes and then once it's reset, you click on start, it'll go ahead and launch and then you can go ahead and

1:17start fresh. So you don't need to worry about breaking anything or doing the wrong thing because you can just reset the lab anytime you need to to give it another go. Alright, so here we go in the lab environment, we'll go ahead and double click here on client nug, to go ahead and launch that , give that just a moment to initialize and here it comes and that looks like a black screen there. So I'm going to click once here on client nug and that brings the interface up, fantastic. And our first task is to go ahead and open up Chrome so we can launch it here from the desktop. We also have a shortcut here down in the taskbar so we'll go ahead and launch Chrome, there it comes.

1:49And then I have a bookmark right here for HTTP colon slash slash server one dot nuggetlab.com, which is here in the lab environment and we are good to go. So behind the scenes, if this computer had not yet learned through DNS what the IP address was from server one dot nuggetlab.com, before it made the HTTP request, it would also have gone out to a DNS server and asked for, hey, what is the actual IP address of server one dot nuggetlab.com and then come back and then start using the HTTP services to make the request. Alright, so now we've done that, let's minimize that. So now we've done that, I'll close that browser window and next let's open up this pre captured file that represents a DNS and an HTTP request by double clicking right here on DNS plus HTTP capture right there.

2:30And here it is. So the question is regarding packets one and three. So let's go ahead and select packet one here and then down below it shows the details. So as far as packet number one, the application layer protocol is DNS as shown right here. So it's a DNS request and we dig into it, you can actually see what we're requesting the client was asking for. Hey, what is the IP address of server one dot nugget lab.com. Alright, so that's the first question regarding packet number one and that one and I was the layer for protocol.

3:02So if we go to the next layer right here, which is layer four. Now they could have wire shark is just an example of a protocol analyzer that lets you see the details for the packets they're going back and forth. They could have, you know, shown the application layer on top, but what they chose to do is order it in this direction. So here's the DNS request and then that's been encapsulated with a UDP header that includes the UDP information. So the layer for transport protocol is UDP and then that got encapsulated like the cups into an IP header, which adds the additional information regarding the source and destination IP addresses.

3:36So the destination IP address is 1040 0 10 for packet number one and the source is the client's address at 10 10 0 50. And then the last question is what is the layer two source address. So if we click here on the layer two information, the source address, we could either see it here where it says source or we could go ahead and double click and open it and highlight this. And that's the source address ending in 0408. And that is the hardware address of the client who's sending out this information onto the network. So that's for packet number one.

4:07And the other question was about packet number three. So we'll click on packet number three and of the application layer, it's HTTP, the hypertext transfer protocol, and then at layer four, it's using TCP, the transmission control protocol, and then at layer three, it's using the internet protocol and includes the source and destination IP addresses and the source address is 10 10 0 50 as client and the destination is 1040 0 100, which is the IP address of the server trying to reach. And then at layer two, it has the layer two addresses and the layer two information layer two header here, which includes the layer two addresses.

4:41Those layer two addresses have many different names. They can be called the hardware address. So the question was, what is the layer two source address. The source address is the source address ending in 0408. That's actually the layer two address of the computer in our case client night that sent this request. So those layer two addresses could be called hardware addresses or the physical address or the MAC address, MAC meaning capital, MAC, not nothing to do with Apple, but rather media access control address or the layer two address. We could just call it that or we could call it the burned in address.

5:12Those all referring to this layer two address that's burned into the network interface cards. And the case of this client saying the traffic to its default gateway so that router can forward it on. There is the layer two address for the destination, which is the layer two address of the client's default gateway. So let's take a look at our tasks and make sure we got all of them. We went through the packet capture. We identified from packet one and packet three, the application layer services and those were DNS and HTTP respectively. So for packet one and three, the application layer services were DNS for packet one and HTTP for packet three.

5:45The layer four protocols where the protocols are associated with those application services. So DNS was using UDP and HTTP was using TCP at layer four. And for both packets one and three, the source address was the client. That's its IP address. Think of it like the street name and the house number where that client is and the destination address was the server. And that was true for packet one and three. So the DNS request because the actual server server one is the DNS server and we had the IP address for our DNS server. That's why the DNS request went to that server as well.

6:17So the source IP address is the client's IP address for both packets one and three. And the destination was the server's IP address. And then for the layer two address, because the client and the server on different networks, the source address was the client's address, meaning the client's layer two address. And the destination was the client's default gateway on each of those subnets. And because the HTTP request and packet three and the DNS request and packet number one, we're both going to a server off the local network, the client was using its own source layer two address. And for both those packets being forwarded to the servers, the destination address would be the layer two address of the default gateway.

6:51And that's what we saw inside the packet captures. And I have very much enjoyed our time together in a set of videos regarding using a reference model. I also love it when I can tell the truth about the OSI reference model and how it's just a model. And it's not literally any protocol that we use today. It's just a reference model, but we leverage pieces and parts of that to better understand the protocol stack that we do use today, which is the TCPP protocol suite. Also sometimes referred to as the TCPP protocol stack, or if somebody just says what protocol are you using and they say IP, they're also generally just referring to the entire TCPP protocol stack, which includes at layer three IP addresses.

7:30So thanks again for joining me for this set of videos for this hands-on lab and this walkthrough. And I look forward to seeing you, my friend, as we continue this journey together in the next set of videos. Until then, I hope this has been informative and I'd like to thank you for viewing.