Hey what's up guys welcome to CertBros. In this video we're going to be talking
about TCP versus UDP. So let's look back through our tcp/ip model which should
hopefully look familiar to you by now. When sending data we start at the top of
the model and work our way down. We're going to ignore the application layer as
it's largely out of our control and start at the transport layer
The two primary protocols at this layer are TCP and UDP. A network application
has to choose how to send its data. That choice comes down to, do I want to
send it reliably or do I want to send it unreliably? Both reliable and unreliable
have their benefits and drawbacks. First let's look at TCP or transmission
control protocol. The first thing to understand is when we send data, this
file, for example, it's not sent all is one piece. It's sent in lots of different
pieces of data. The receiving computer then collects these pieces puts them all
together and then spits out the file. And that's fine but what happens if some
of the data we sent gets lost along the way? The receiving computer won't be able
to put the pieces together and you'll probably end up with a corrupted file. So
this is the reason we need some method to reliably send data. Something that can
resend and resolve missing or corrupted data, and this is exactly what TCP does
TCP is the most widely chosen option for transmitting data this is because it can
reliably send and receive data
If there is a network blip and some of the segments are lost along the way
TCP can recover them meaning the user experience shouldn't be compromised with
half loaded websites or corrupted documents. The way TCP can provide such a
stable and reliable connection is in three ways
first, a uses acknowledgement numbers, second, it uses sequence numbers, third
TCP adds a checksum. But before any of that can happen first we need to start a
reliable connection. TCP does this by using what's called a three-way
handshake and it looked something like this
first, the sender computer sends a message called a SYN which is short for
synchronize. The receiving computer then replies with
an ACK message, this is short for acknowledgement and it also includes a
SYN message of its own, so this message is called a SYN-ACK lastly the sending
computer acknowledges with an ACK message. Now we have an open TCP
connection. A similar process is also followed when closed in this connection
down. Ok, so the next step is to look at sequence numbers. TCP will assign numbers
to segments as they are sent. This way the receiving device can
collect these segments, reorder them correctly and determine if any segments
are missing. The sequence number is just one field in
the TCP header. These messages are then acknowledged
it's almost like saying "sending data" and the receiving computer says "got it"
"sending data" "got it" and so on and so on. The way this works
is by using sequence numbers and acknowledgement numbers. So I also
mentioned a checksum. The checksum is a result of a simple calculation ran
against the data. If the data has been transmitted
successfully the checksum ran on the receiving side should match the checksum
ran on the sender's side
If there has been some problems along the way and some bits got messed up then there will
be a checksum mismatch and the segment will be discarded
As we've already seen a TCP header is added to the application data to create
a segment. This is what a TCP header looks like. We have port numbers which we
will cover in another video, the sequence and acknowledgment numbers and the
checksum. For now there's no need to worry about the other bits of
information. Now unreliable communication comes in
the form of UDP or User Datagram Protocol. UDP has none of the error
handling, sequencing or reliability of TCP
You can think of UDP as a kind of machine gun of data just firing and
firing not caring if data is lost or not. It has one goal and that goal is to send
data. So why would we ever consider using UDP
if it's so unreliable? Well, while TCP offers a great connection
and reliability, it all comes at a price of resource and latency. This is great
for the most common tasks such as web browsing, file transfers etc where we
don't mind the latency issue in return for a stable connection. Where UDP is
useful is in the situations where we need live real-time connections. For
example, voice calls, video calls and gaming all need fast real-time
connections. We can't afford latencies in these situations. We can handle a loss of
voice data because who really cares about a bit of jitter in a voice call? On
the other hand, if we start trying to resend voice data, then this could cause
latency and make the call inaudible. So now let's look at a UDP header
as you can see there is a lot less information here than there is on the
TCP header. We only have the port numbers, the length of the data and a checksum
the small header means less information but is lighter and is quicker. Perfect
for real-time traffic. That's it for TCP and UDP. Two ways to
send data for two different purposes. This video is part of our full CCNA
course which can be found in the description. So please feel free to go
and check that out. if you like this video don't forget to give it a thumbs
up comment and subscribe other than that I hope this video helped
and thank you for watching