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 to 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 this 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 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 to getting 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 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 the
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 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 know 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 sócrates 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 flags 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 online study 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 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 video 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 has received and if data is 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 much 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 data 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 own video coming up 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 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 seconds of data go missing if TCP was being 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 is lost there are no retransmissions
they just move on and continue the rest of the phone 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 wanna look at my answers try to use these questions to challenge your understanding
we're going to take a deeper in the next video by looking at the process
TCP uses to build a connection if you've liked this video please give it a thumbs
up so YouTube can recommend it to more people and I'll see you in the next video