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