We’ve talked about the OSI and TCP/IP models now we’re going to focus on two of the protocols in the transport layer these are TCP and UDP we’re going to see how they get information from one application to another, and their different approaches at their job two.
Devices on a network rely on IP to deliver information between each other this happens at layer 3 which may include routing packets across several networks at layer four though we see very different behavior the transport layer doesn‘t care too much about the networks in between why it doesn‘t need to that’s layer three’s job it also doesn‘t care too much about the devices themselves instead it cares more about getting data between applications the two, protocols that are responsible for these are TCP and UDP they share a few things in common, For, example, they both have headers, and they both have port numbers, but as you can see in the headers there’s a lot more going on with TCP than UDP that’s because of The TCP supports a lot of features while UDP is extremely lightweight through the rest of this video we’re going to see how TCP, and UDP have different approaches for get the job done and why some applications will use one protocol or the other in the header, you’ll see fields for the source and destination ports the ports are used to identify the applications on each device in this way ports are like addresses for applications this is similar to how the devices themselves have IP addresses when an application starts a conversation it chooses a protocol to use as a well as a random source port this is some value from 1024 to 65535 the exact number is generally not too important the important part is that this port number is not already in use on the device one port number cannot be given to more than one process at a time the destination port number that is the port number of the sir application is usually a well-known value, for example, if we were using HTTP for web browsing the port will normally be port 80 well-known ports are in 0 to 1023 range by making a port well-known it’s easy for the client to guess what port the destination application will use if you want to see some well-known ports have a look at the list in this URL of course a server application could be configured to use a non-standard port maybe port 81 for HTTP, for example, and this is fine but the client can’t guess the port number anymore the client application will need to be manually configured to support this using different ports gives us a really useful feature called multiplexing is away for one host to have several applications accessing the network at once they all share the one network card the one network stack the one IP address, but they each use different ports think of our client over here on the left it already has a web browser open with a connection to a web server now it opens a mail client and is able to send and receive mail both applications can access the network at the same time but when data arrives at this device how does it knows which application it belongs to the IP and the MAC address is the same, so, they won’t help yeah you guessed it the two applications use different port numbers a network application uses a concept called a socket the exact definition of what a Socrates will vary a little but most agree that it is made up of a local IP address a local port number and a protocol the protocol being either TCP or UDP as port numbers are unique so our sockets there for a soccer can identify which application the network data belongs to that’s fairly straightforward so far, but it gets more interesting a single application like our web server software over here can also access the network many times at once but as is only one application he only has one port and one IP the soccer details are the same for all incoming connections, so how can you tell one from the other it needs to look at the combination of the local socket information, and the remote socket information it can find all of this in the layer 3 and layer 4 headers it now has five pieces of information the local IP the local port the remote IP the remote port and the protocol this combination of details is often called the five tuple each conversation is now truly unique let’s have a quick look at this on a workstation I’m using Windows here, but Linux Mac and other devices all use the same principles here we have a list of processes each process has a process ID shown here in the PID column these processes all make up applications some applications have one process while others like chrome have several some of these processes will be accessing the network that means they’ll have either a TCP or UDP port assigned, and we can find this from the command line with the command netstat using the a and AA have a shows all connections and shows IP addresses instead of host names and Osho‘s the process ID that owns the connection looking at these processes we can see whether they’re using TCP or UDP the local IP address, and port number the remote IP and port the state that the connection is in and the process number which we can match up on the list we looked at earlier.
now for a quick quiz to see if you’re following along.
can you identify which protocols use these headers? what is a socket used for what pieces of information are in a socket detailed answers are available on the website for patreon supporters but please feel free to discuss them or ask questions in the comments below you could also look at an online studying groups like the Cisco Learning Network for further discussion if you’re studying for the exam the book here is quite useful I’ll include a link in the description everything we’ve seen so far has been common to both TCP and UDP but as you can see from the headers they’re quite different this is because UDP was assigned to be very lightweight while TCP was designed with a lot of extra features, for example, TCP is connection-oriented while UDP is connectionless connection-oriented means that TCP will build and track a connection between applications on a pair of hosts before the sending data when they’re done TCP will close this connection this stateful connection enables more features like error recovery, and flow control there’s a lot to understand around TCP connections, so we’ll use the next article to go into those in detail you dip here, on the other hand, doesn‘t try to build a connection it just starts setting data without worrying about any of those details TCP and UDP also have very different feelings on what to do about errors UDP for one doesn‘t care about errors if a packet or segment goes missing UDP doesn‘t worry it just moves on to the next piece of data TCP though does care about lost data the receiver must acknowledge that all the data that have received, and if data am lost TCP will manage the retransmission because of this TCP is known as reliable while UDP is known as unreliable this also leads into a TCP feature called windowing this is where both sides of the conversation agree on how many data can be sent at once before acquiring the receiver to acknowledge it this value is called the window size if there is no data loss the window size can dynamically grow if there is a datum loss the window size will dynamically shrink I’m not going to go into much detail on error recovery and windowing right now because they’ve got their article coming up is very soon the final difference, I want to mention at this point is ordered data transfer TCP uses sequence numbers in the header to track the order that segments should be processed in this may be critical for some applications but it does add extra overhead in processing time this is not important for other applications which may be why they use UDP does not care about the order the data is in you may be wondering what UDP is even used for as it seems to lack some critical features after all is no error recovery isn‘t that quite important it may sound silly to give up features like that but there are some cases where this helps think about real time applications like voice and video streaming imagine that one person on the phone called has network problems, and a few second of data go missing if TCP is used here this would be noticed, and the missing data would need to be resent while this is happening the phone call is still going on now one of our calls is lagging behind you see how that could be a problem, so instead voice traffic uses UDP if some data are lost there are no retransmissions they just move on and continue the rest of the phones call so, you can see that TCP and UDP are used for different purposes UDP is lightweight smaller headers no retransmissions, and no flow control it’s great for real-time applications like voice or video or for applications that manage these features themselves like DNS which we’ll talk about some other time TCP, on the other hand, has a full feature set for applications that would rather leave these details up to the network stack he’s an opportunity to see if you really understand what we’ve been talking about even if you don‘t want to look at my answers try to use these questions to challenge your understanding we’re going to take a deeper in the next article by looking at the process TCP uses to build a connection if you’ve liked this article please give it a thumbs up so Enagest.com can recommend it to more people and I’ll see you in the next article.