OSI Model Layer 4 - The Transport Layer

Hi, welcome back. Today I'm going to talk about layer four of the OSI model, the transport layer. But before I get started, let me walk you through a simple use case I've been using for this video series. Okay, let's say you're on your computer at home and you want to bring up a web page. A request is made and an HTML response is returned. Today I'm going to focus on this part of the URL called the port or the TCP port. Let's say you have a business and you need accounting services. Maybe you live in a small town, so you go to visit your local accountant located at this address. You may also need legal services, so you go to visit your attorney on the other side of town. Now, the downside of having services in separate buildings is you have to duplicate a lot of infrastructure, things like land, real estate, electricity, water, and other utilities. And this is the same situation when you have services running on separate computers. You now have to duplicate the infrastructure or the equipment. And this can uh get really costly, especially if the services don't use a lot of resources. In real estate, the way you manage this problem is with a big office building. Now, all your services can share a lot of the same infrastructure, and this includes the same physical address. You can see here we have legal and accounting services now in the same building, but they're identified with a different suite number. Going back to our small town example, we had two physical addresses. This means to send a message to our accountant and our attorney, the mail carrier would have to traverse two different paths. With our office building, life is a lot easier for our mail carrier. They only have to make one trip. And this is called multipplexing where you have separate services sharing the same path and infrastructure. In our office building example, all the services share the same physical address and use a suite number to identify where the message will be routed inside the building. Now, let's apply our analogy to networking. Just like our big office building, we now have a single server that's running our web service and our database. The services will be sharing the same IP address as well. And just like the suite number in our office building, the server will be using port numbers to route the messages internally inside the server. Let's take a closer look at the URL. You might notice that uh there's a colon highlighted here. This is a delimiter that separates the IP address from the port. On the left hand side of the colon will be the IP address or host and on the right hand side they'll contain the port number. By default, port numbers are typically mapped to a specific service. There's a page on Wikipedia that lists the most common port service combinations. If we search for the port number 8080, you'll see that this is an alternative to port 80, which is the HTTP port. Some of the most common ports you'll run into are port 80 for HTTP traffic and 443 when the traffic is encrypted. Okay, now that we've seen the common ports, let me show you something a little bit interesting. Let's look closely at the uh URL for Wikipedia. The URL begins with HTTPS and this tells us the page is going to be encrypted. So, it should be using port 443. However, there's no colon or port number listed in the URL. So, where did it go? The answer is your browser will automatically assume HTTPS URLs are using port 443 and the HTTP URLs are using port 80. Next, I'll use a letter analogy to better explain how the layers interact with each other. Here we have a workstation making a request to the server. The goal here is to retrieve a file called index.html from the web server using the HTTP protocol. You can think of this as a letter that we're writing to the web server asking it to return a file called index.html. We'll then place that letter into an envelope with an address of port 8080. And we'll call this envelope layer 4. We'll then place the layer 4 envelope which contains our letter and place it into another envelope. This time we'll use the IP address as the destination. And we'll call this envelope layer 3. We then take the nested layer 3 envelope and place it into another envelope with the MAC address of our server as the destination. This envelope is called layer 2. It's important to understand that the layer 2 envelope contains all the other envelopes including our original letter that was requesting the index.html file. My goal with this analogy was to give a conceptual understanding of the layers. But next I want to dive deeper and look at the actual structure of the data. In the first video of this series, we talked about layer 1 and how the bits are sent down an Ethernet cable. But for those ones and zeros that have any meaning, we have to give them some structure. The first structure that the bits form is a layer 2, and it's called a frame. And all the other layers in the OSI model are nested inside of this frame as a payload. We'll get to that in just a minute. To reach our web server, we'll put it MAC address here. And then we'll expand the payload section, which gives us a nested structure at layer three. And this is called a packet. In the destination field, we'll add the IP address of the web server. And at the end of the packet, we have a data section. Expanding this will give us our layer 4 structure. But we have a few options that we can use for our layer 4 protocol. For this video, I'll focus on just two, TCP and UDP. I'll start with UDP first. Now, I'm expanding the data section in our layer 3 packet where I'll add a UDP structure for layer 4. The structure is called a datagramgram. Inside the datagramgram, there's a destination port where I'll put the web server's port address, which is 8080. Our datagramgram structure also has a data section. And to get a better idea of what goes inside of here, let's switch back to our envelope analogy. In our original request, we were asking the web server to return a file called index.html using the HTTP protocol. It's this request that will go inside the data section of the layer 4 datagramgram. Once all the envelopes are nested inside of each other, we end up with one big envelope that's transmitted down the wire. UDP is a simple protocol. You make a request and you get a response back. However, it doesn't provide any kind of safeguards. It's essentially fire and forget. You don't establish a connection or wait for acknowledgements. You just send a request and you kind of hope for the best. So, if your server is sending audio or video where uh losing some of the transmission isn't a big deal, then UDP is a great choice. But what if you're doing something more important like submitting a bank transaction? You probably want something with better guarantees. And that's where another layer 4 protocol comes into play. It's called TCP. For reference, this is our UDP datagramgram. Since this is a simple fire and forget protocol, you don't need a lot of options, just your destination and your data. This structure is for TCP layer 4 and it's called a segment instead of a datagramgram. You can see right away that there are a lot more options. We still have our destination field just like before where you would put your port, but now we have this section for flags that determine the state of the TCP segment. Here's an example. For TCP, we first had to establish a connection with our web server. And this is accomplished by setting the state flag in our TCP segment to SIN, which is short for synchronize. The server then responds back with the state flag set to send and act. Looking back at the TCP segment, this is where the sin and act flags would be set in the response. And at this point, we've established a TCP connection between our client and our server. With our connection now established, the client can make another request. This time, it starts sending data to the server. And that data goes here in the TCP segment. The server then sends back a response with a state set to act to acknowledge that it successfully received the data. And this process is repeated until all the data is sent. When the client is finished sending the data, it'll set the state to FIN to let the server know that it wants to close the connection. And the FIN state would be set here in the TCP segment. The server then sends two responses to let the client know that it's acknowledged the request and it's ready to close the connection. The client will then acknowledge that the connection has closed. And at this point, the connection is finally closed. So this is a lot of transmissions especially compared to UDP where it's a simple request response. What we get from all these acknowledgements is a reliability and a few other capabilities as well. Let's look again at the actual transmission of data in this flow. I mentioned that the process of sending data and getting an acknowledgement back repeated itself until all the data was sent. So that implies that the data is being chunked up or segmented in some way. So let's take a look at that next. In our TCP segment, there's a field called window. And this determines the size of each chunk or segment that's going to be sent. To better explain this, let's assume our server is responding with HTML. Now, the way windowing works is the receiving computer is the one that determines how big the data should be. Let's assume the first data transmission is 20 bytes from the web server. And just to be clear, the HTML would go inside the data section of the TCP segment. Our client would then acknowledge the data, but request that the window size be set to 10 bytes instead of 20, which would be set here in the window field of the TCP segment. Server would then send more data back using the smaller window size. So, this poses an interesting problem. And let's use our HTML as an example. What if we have to break up the HTML into two chunks based on the window size? Each of those chunks or segments would be independently sent down the wire and based on the network congestion, it's possible that they could arrive in the wrong order and this would cause errors when our web browser tries to render the page. To solve this problem, the TCP segment has another field called sequence and this allows us to identify the order of the data. So our client can then reassemble the document in the correct order once all the data is received. And finally, with the HTML properly reassembled, our web browser can render the page correctly. Okay, I think that's enough for today. In the next video, I'm going to cover the remaining layers of the OSI model, layers 5 through 7, and these are collectively called the application layers. Thanks for stopping by and I'll see you in the next

In this video, I'll discuss TCP and UDP ports, called the Transport Layer. This is Layer 4 of the OSI Model. This video is a part of my series on Networking fundamentals. 00:00 Intro 00:23 Why do we need port numbers? 03:22 Where does Layer 4 fit in the OSI Model 04:29 Frame, Packets, and Datagrams 05:21 User Datagram Protocol (UDP) 06:40 Transmission Control Protocol (TCP) Links referenced in this video: https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers