what's the difference, when would they be used, and how do we analyze them? Now there's a lot that
we could go over in these two protocols but just to keep it simple oftentimes the thing that you're
going to need to remember for that certification or that interview that you're trying to ace is
that TCP or the transmission control protocol that's a connection oriented protocol and the user
datagram protocol, UDP, is connectionless. Well what does that really mean and why do I care? Well
let's get into it in the packets so we can really see at the packet level what the difference is.
So first of all you can see here I have a couple of packets here this is just DNS here's my DNS
conversation, and then after that I start up with the TCP stream. So let's go and take a look at the
DNS first of all. Now if i come down here I can see I got my layer 2 stuff that's ethernet then
I got my layer 3 stuff so layer 2 ethernet, layer 3 IP, and then layer 4. I'm sitting in the user
datagram protocol. So just clicking this protocol header over here on the right you can see the
associated bytes that are highlighted and really UDP is a very simple protocol and that's why an
application would use it: when they don't need that layer 4 protocol to do a lot of thinking. UDP
is very efficient it's two ports - if we expand this out - source port, destination port, length,
checksum, that's it. So quick delivery we're not worried about whether the traffic got there or not
we're not worried about congestion control or how fast we're transmitting. We just let this packet
go hope it gets to the other side and if we get a response great. So here we can see a very common
application or service you could say that uses UDP and that's DNS. So very simple we send our
DNS request over UDP and we wait for our reply to come back and there we go. Very simple there's no
connection here there's no protocol set up, very simple. But that doesn't mean that UDP
is just a bad protocol that nothing should ever use, obviously we're running DNS over it,
and as a matter of fact right now you're likely watching this very video over UDP.
And that's because UDP is also being used by other applications that are upstairs that have a lot of
re-transmission smarts and other types of data recovery features built in. For example QUIC.
So QUIC sits on top of UDP - simple eight byte header - in order to be able to get into that
kernel on the other side and just make a simple use of that stack. Okay so UDP connectionless.
Very simple, only eight bytes in the header, just a source, destination, length, and checksum
and that's it. Now let's flip to TCP. A whole lot more is going on under the hood with TCP and it's
a whole lot more than just that one certification answer. It's a "connection-oriented protocol".
While that's true, let's take a look at how much is going on with TCP. So here we can see
a simple tcp connection, let's go back to our packets. So here we have a TCP SYN, SYN/ACK,
ACK, three-way handshake. Now why do we need these three packets? Well TCP unlike UDP is stateful and
what that means it maintains a state on each end. Each end is aware of this connection, it dedicates
resource to it, and there's a lot of things that happen on each endpoint, more than just a simple
send and receive. So for example when we establish a connection, take a look at that SYN. We're not
just opening a port but we're also dedicating other resources to this connection. So for example
we're beginning to count our sequence numbers, we have a tcp window which is dedicated resource to
be able to receive tcp data, and also we can see the other options that a lot of times we'll talk
about in this channel some of the options that are exchanged in that handshake. Now on the opposite
side as well, we have port numbers, sequence and acknowledgement numbers so data is being sent data
is being acknowledged, and then we can see also window size and other options as well. But TCP
is way more than just a handshake. Every single byte that I transmit is tracked, if you will,
by something that I call a sequence number. If I send you 100 bytes, you're going to acknowledge
it and let me know that you got each one of those 100 bytes. If something was missed you can let me
know by that acknowledgement number. I can analyze it and then I can re-transmit any missing data.
Another huge thing that makes TCP different than UDP is also congestion control. What this
means is I don't want to send data so fast that I actually cause my own congestion on the network
and basically muscle everyone else out of the way and cause my own packet loss, which would
make me need to re-transmit. Remember that TCP it doesn't know what network it's going over.
It could be that we're going across an ocean with a very very large amount of latency,
or it could be that you're sitting right next door to me on the same switch with very
low network latency. In addition to latency, also the amount of bandwidth that's available.
So TCP is not aware of any of those things when it begins to transmit. So in many cases what
TCP will do is it will be conservative when it begins to transmit. It'll go through something
called slow start, as data successfully makes it to the other side and acknowledgments come back,
it'll gradually increase the amount of data that it's putting out on the wire
as successful acknowledgements come back. So that's a whole other facet of TCP that we need
to think about that makes it different than UDP - congestion control - and that's where
TCP will limit how much data it puts out on the wire and gradually increase the amount as
it successfully is able to send data to the other side. Now there's a whole lot of algorithms that
control that but let's just leave it at that for now. Now at the end of the TCP connection,
we have to tear the connection down. So what makes that happen? Well two ways so we can either FIN
the connection to tear it down or we can send a reset in order to tear down the TCP connection.
But either way, eventually we don't want that TCP connection to live on forever,
so TCP being stateful, both sides are going to dedicate resource to that connection
for as long as it's alive. That's the reason why we don't want TCP connections to run on forever,
because both sides are going to maintain that state. Okay so whoa we just talked about a lot
of things but let's just keep this very simple. What's the difference between TCP and UDP? Again,
connection-oriented, connectionless. UDP best effort. It will transmit and hope for the best.
It does not resend data, and it does not do any kind of congestion control. TCP is
connection oriented. It first has to establish that three-way handshake. It maintains state.
It tracks every single byte that's sent in order to re-transmit any missing data and it
also implements congestion control so it doesn't overwhelm the network by being too aggressive
by sending. So I hope this video was useful to you and understanding the difference between these two
very core protocols at the transport layer TCP and UDP. Thanks for stopping by I'll see you again!