Welcome back to the channel packet
people it's great to have you back. So today we're going to talk about another
topic in the "How TCP Works" series. I realized something that I hadn't covered looking over this
playlist is the difference between TCP and UDP. I know that's something that a lot of people
need to know for various certifications or if they're just getting into packet
analysis and they want to know the difference. But really, what's the difference between these
two protocols? When would an application use them? and How can I analyze them in
Wireshark? So stick around. Now if you'd like to follow along with me in
this video, go ahead and click the link in the description down below and you can download that
trace file, open it up in Wireshark and follow right along. Now TCP and UDP. You're going to hear
a lot about these two protocols in networking but 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! you
