hpr-knowledge-base/hpr_transcripts/hpr0394.txt

Episode: 394
Title: HPR0394: Networking Basics Part 4 TCP and UDP
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0394/hpr0394.mp3
Transcribed: 2025-10-07 19:43:23

---

Hi everyone, this is Quattu.
This is episode 4 in my series of networking basics.
In this episode we're going to talk about TCP and UDP.
What is TCP and what is UDP?
Well, everyone's heard of TCP and you may have heard of the term UDP, but let's think
of how we've heard TCP before.
Well, there's that one phrase people seem to throw around a lot TCP-IP, right?
Well, most people don't necessarily realize that those are actually two separate protocols.
TCP is one and IP is another.
We'll talk about IP next episode, episode 5, but for this one we're going to concentrate
on that first part.
So TCP is a really common protocol of getting data around as is UDP and they both operate
entirely on the OSI model in the network layer.
It's that stage in the network process where data is being transmitted from one network
to another or even within the same network, but it's that process of where the data
is being transferred.
So let's talk about TCP first and then we'll talk about UDP and we'll talk about why one
would use one or the other or why one wouldn't use one or the other.
TCP stands for Transmission Control Protocol.
There are some characteristics of TCP.
It is full duplex.
It is connection-oriented and it's a reliable protocol.
What on earth does all that mean?
Well, full duplex, we call that because it sends and receives information simultaneously.
So it's a full duplex protocol.
Connection-oriented because it establishes what's called a virtual circuit.
Virtual circuits are kind of cool and we'll go over exactly how they occur but know that
that's something that TCP does.
It establishes a virtual circuit and so we can refer to it as a connection-oriented protocol.
We call it a reliable protocol because everything that is sent via TCP is confirmed.
It is always there are checks and double checks and cyclical redundancy checks to make sure
that the information that was actually sent was actually received in the way that it was
supposed to be received.
TCP of course, and I think we've kind of mentioned some of this before, TCP breaks the information
that you're going to send into little segments and it numbers the segments and it sends
all these little segments one by one to a remote location somewhere.
So it leaves your local machine and goes off to some remote machine, maybe a server or
maybe just another computer on the office in the office next door or whatever.
The remote machine takes all these little segments of data, it looks at how they're numbered
and it is able to thereby make sure that it's got all the information and is able to
then connect them all back together, put them back in the correct order.
How does this happen?
Well first, the TCP stack on your machine, on let's say, a Quattuz machine, contacts
the TCP stack over on Gortz machine, that's the destination machine.
Again, this could be a web server, it could be a mail server, it could be a friend's computer
that you're trying to get some information from.
They talk to each other and they establish a connection and that's the virtual circuit.
So there's a little handshake going on there and you've now got a connection.
So the Gortz machine knows that my machine is going to talk to it in a moment.
They establish, among themselves, what information is going to be sent and how much that information
is going to be, how much data that really is going to boil down to.
And then the remote machine, Gortz machine, will send my machine and that's not an acknowledgement.
Now to send the information, again, my machine is going to break it up into little segments
and they each little segment is going to attach a TCP header.
Now remember, I know we've talked about this before, remember that network, sending stuff
via these networks is a little bit like a space shuttle, lifting off from our great planet
here and going into the great far reaches of outer space.
Because what happens when you see a shuttle take off, right, it's got that big fuel tank
on it and it's got more fuel tanks on the fuel tank.
So it lifts off, it ejects the fuel tank, right, it sends it off, and it keeps going
and then it drops more fuel tanks and then finally it's in space or something, something
like that.
So that's what happens with all this network data, too.
The message gets through one layer and the next layer looks at the header and says, oh,
I know where you're from and what you are, okay, so I don't need your header anymore.
And then it keeps going and the next layer says, okay, now I'm down to these two headers,
well, this one, this header is from me, I don't need it anymore, so I'll process the
data and send it on and then it goes to the next, you know, and so on and so forth.
And first, the inverse would be true, I mean, first it gets headers from all these different
protocols, then it's sent and then it's, you know, the reverse happens, everything kind
of processes the header and sends the rest of the data wherever it's supposed to go.
So TCP adds its little header to this segment of information and what is in a header?
Well, in the TCP header, which is 24 bytes long, depending on some of the individual options,
there is a source port and that would be the port number of the application sending the
information.
There's the destination port, which would be the port number of the application being requested
by, you know, over on the remote machine, over on Gort's computer, whatever.
There would be an acknowledgement number, which is going to be the TCP octet that is
expected next.
There's a header link, which is 32 bits and that is the number of 32 bit words in the
header.
So kind of recursive in a way, but yeah, 32 bits, which is the number of 32 bit words
in the header, this helps define when the actual data begins, right?
Because if you know how long the header is and you know that everything after that is
the data that the person's actually sending.
So then once we take off that header, we can show you, we will know where the data is.
After that is a reserved bit, which is always set to zero.
I don't know what it's for.
I don't know on what occasion it would not be set to zero.
It might be something for developers to use or something like that.
Then there's code bits, which controls the setting up and the termination of a session.
There's the window size, which is the window size that you, the sender, is willing to
accept and that is always given in octets.
And then there's the checksum, which does the whole, the cyclic redundancy check for
the header and the data fields.
So this is what actually makes TCP reliable, right?
Because it's the thing that enables it to check the integrity of the data and stuff like
that.
Now after that, there is an urgent field.
I don't know exactly what makes something urgent or non-urgent.
But I do know that if the bits are not set, then it's only valid if the bits are set.
The value that it is set to would be, like, an offset from the current sequence number
in octets, where the first segment of non-urgent data begins.
Again, I have no idea exactly when this would be set as urgent or not, I'm just not doing
that sort of thing.
But if you are analyzing traffic and looking at headers and things like that, that's what
you'll see.
Options is next, it's 32 bits again, but if it's anything greater than zero but less
than 32 bits, you're going to just see a whole bunch of zeros to fill in the space.
This field contains different options.
Unfortunately, I don't know what those options are.
And I didn't want to read through all the different documentation trying to figure out
what they were.
But I'll touch on the importance or the non-importance of all this in a moment.
And then after that, finally, there is V data.
And that is V data that you are sending plus all the upper layer headers are there.
So you've got the TCP header and then you've got all the layers before that, all their
little headers and then your data.
But as far as TCP knows, that next portion is the data field and it's going to get passed
on to wherever it needs to get passed on to.
That is how TCP sends the data and it ensures that all the data has been sent.
That has been sent has been received.
And it is how it enables the remote machine to reassemble that data in the correct order
because of the acknowledgement number.
So you've got all that good stuff and that's how TCP works and you're going to be seeing
TCP when you are using protocols like HTTP, HTTPS, SSH, STP, Telnet and sometimes but not
always DNS.
Now like I was saying about the options field and the reserved bit and things like that,
I don't understand that kind of stuff.
You probably don't understand that kind of stuff and the importance of understanding it
is questionable because you and I, the regular user, we're not going to be messing around
with that kind of stuff.
Nor are we even making the call over whether we want to use, for instance, TCP or UDP under
normal circumstances.
So there are some applications which can use both and you can choose between the two.
But more often than not, the programmer who has made the application that you are using
has made the call.
So this is something that needs to use TCP and so we will use TCP and we will include
these kinds of options and set this bit to that and so and so and so.
So it's really a question of how deep you need to understand some of the technology versus
how you just need to know that the technology is actually occurring.
If you want to know more about TCP or UDP, there's a great website you may have already,
you may already know about this, you might not.
It's a website full of things called RFCs and RFCs stand for request for comments and
the official page of them is itf.org is the site that you're going to want to go for
for all the, I guess the actual RFCs.
The place that a lot of times I go to just because it seems to be almost easier to find
them in and I guess Google usually just returns them pretty quickly here is on fax.org F A Q S
.org slash RFCs that's RFCs and if you just type in RFC UDP that will bring up RFC 768
which is the RFC that details the UDP protocol or you could do RFC space TCP and that will
surely bring up RFC 793 which is the transmission control protocol one and it's a big document
I'm talking it's a good read it's a lot of pages or not I don't know many pages but it's
a bunch of screen full of a lot of information about TCP and you can start there and just
branch out as far as you want to go very informative documents the RFCs are and the RFCs
are put out and have been put out I mean like the UDP one dates from like 1980 or something
like that so but they're still relevant obviously because these are the protocols that
we're actually using but this is when these protocols were sort of implemented and this
is how they work these are their characteristics these are the specifications of some very
important protocols so check those out if you want to know a whole lot more than what
I will probably ever be able to tell you about now when you request something say a web
page or something your local computer assigns your signal a port number with a number from
anything from like 1020 or anything above 1024 up to something like 65,000 it's it's you
got a lot of got a lot of numbers there and and the computer will assign your little signal
a port number and that's what gets put into the source port of the TCP header so let's say that
it gives you the port number 2012 and then the destination port is going to be whatever port
happens to be assigned to the service that you're requesting so for instance maybe you're
trying to FTP into something and they have their default ports set for FTP so it's port 21
or maybe it's SSH and that would be port 22 right tell me 23 53 for DNS 80 for HTTP possibly 80
if they're clever you know 110 for pop 3 whatever why does it do this well because TCP doesn't use
hardware and it doesn't use logical addressing so they need to use a port number because you know
they need two distinct ports to identify the two entities sending messages back and forth so
that's the importance of the source and the destination port number so all of this happens with
an overhead right I mean TCP doing all this kind of work as you can even tell just from the header
file it does it it carries with it a certain amount of it's gonna it's gonna burden your network
to a certain degree so what happens is that when people want to use a they're writing an application
you know that that interacts over a network they decide well I don't really need all the
features of TCP I can use the much simpler and what would be called a thin protocol called UDP
and that's that stands for user datagram protocol again the rfc for that is 768 so you can
check that out if you want to UDP does not sequence its segments okay it sends a segment out
and forgets about them it just sends out the information it doesn't wait for confirmation it
doesn't want confirmation therefore we call it well it's not a reliable protocol which doesn't
mean that we wouldn't ever use UDP because it's just not reliable little break no it just means
that it doesn't it doesn't send and then wait for confirmation so TCP is called reliable protocol
UDP is not a reliable protocol but both are used just as much as the other one is just that
one does wait for confirmation one features the fact that it does not wait for confirmation and
that's a good thing in some cases UDP also does not create a virtual circuit meaning that it's not
gonna contact the destination computer before sending the information it's just gonna send the
information good to know the segment format for UDP is a lot simpler than the TCP format it's got
a source port it's got a destination port it's got the length and the check sum and then the data
skips over everything else that's all there is now some UDP signals aren't even sending data they're
just probing the network so sometimes there's not even a data you know the data the data the data field
would be empty so UDP does however run a cyclic redundancy check and that relies on the frame check
sequence so you're going to see frame frame check sequence data if you were going to look at UDP
signals but it's still it's not waiting for like confirmation or anything but it is it does have
that cyclical a cyclic redundancy check in it and the things that are that are using UDP that you
that you'll see are for instance pop three TFTP which is the lightweight version of FTP
S in MP and sometimes again so does DNS and a lot of times new services do as well for like
in news groups so if we broke it down into really simple simplified terms well I mean first of all
TCP is a little bit heavier it's gonna burden the network a little bit more than UDP and simple
terminology well TCP would be like talking to someone in class right if you're in a classroom
you guys are talking and you get feedback from them immediately right you whether it's body language
you're just like uh huh yeah oh really oh is that right you know that kind of thing like that kind
of in a feedback that you get from people just to identify that yes they're hearing what you're
saying they understand what you're saying if they don't get something if they don't if they
miss something that you said they'll they'll say what what's that what did you say something like
that you know so they'll you get that feedback it's a very interactive process I guess and you'll
you'll stop you'll modify what you're saying in order to accommodate the fact that they missed
something you'll you'll retransmit some information if needed now UDP is more like me talking to
you right now over a podcast I'm sending out the message I have no idea who I'm talking to I don't
know that you're listening you might not have even downloaded this file you might not be hearing
it at all or you may be listening to it you might not be understanding what I'm saying maybe I'm
talking too fast or maybe I'm being too vague or I'm being I'm not being clear on something you
can sit there and ask me to repeat something as much as you want you can try it now if you want
and I won't do it that's how UDP works in a way it's the signal being sent out and that's kind
of the end of of of that transaction it's it's being sent and and if you get it you get it and
if you don't you don't so that is TCP versus UDP and those are again both protocols that operate
on what would be called the network layer in the OSI network model and these both use the IP protocol
as always this is a podcast created by and for the community so if you want to do an episode
for hacker public radio all you have to do is either ping me or enigma or winter mute
and tell them that tell us that yeah you've got an idea for a show how about if you do an episode
on such and such and then you can do it and send it into us if you can't reach either me or enigma
or winter mute just do the episode and send it in and and email us and let us know that it's
that it's ready or email it to us or whatever you need to do post it somewhere and then email
us a link whatever if you want to do something on networking like for this series the networking
basics series by all means feel free I'm I've gotten like I think two different emails about
people who who might be doing an episode that will tie into this little series of networking
basics I would love to hear from other people who have more experience or different experience
or whatever with networking I think that other hosts within the networking basic series would be
fantastic I would love to hear it so please definitely just send it in or if you catch me
with some kind of misunderstanding or or an error or just not being complete enough send me an
audio comment and I will play it on the next episode or make a comment in text on the hacker
public radio site under the under the actual episode or do whatever you need to do to either
correct me or add to what I'm saying or clarify or give another example whatever so yeah contribution
and collaboration is always welcome so thanks for listening to hacker public radio
and I will see you next time
thank you for listening to hacker public radio
hpr sponsored by caro.net so head on over to c-a-r-o dot n-e-c for all of us