Transmission control protocol, or TCP,
is a connection-oriented protocol.
This means that if two devices would
like to communicate via TCP they have
to send formal messages to each other
to set up the connection before any data can be transferred.
TCP is also a reliable protocol.
When you send data to another device via TCP,
the other device will acknowledge
that it received that data.
That way both sides can be assured
that they've received exactly the right information.
Because TCP is keeping track of what is sent and in what order,
anything that is received out of order on the other side
is something that can be pieced back together
in its correct form.
This is something that commonly happens
on our modern networks is we'll send information out
in one particular order and because of the way
the traffic flows, when it's received on the other side,
those frames may come in out of order.
TCP can handle that piece.
If anything is missing, it will ask for re-transmissions
and put everything back together in its original form.
User Datagram Protocol, or UDP, is a very different protocol
than TCP.
UDP is connectionless.
There's no formal startup process
to set up a communication to another device,
there's no formal tear down process for the flow.
UDP simply sends information to another device
without any type of warning whatsoever.
UDP is also what we call an unreliable protocol.
This doesn't mean that UDP is any better or worse
than any other protocols and it doesn't
mean that UDP doesn't work well because UDP works exceptionally
well.
What this means is that there are
no acknowledgements to the data that's
sent to the other device.
So the originating station really
has no idea if the information has gotten to the other side
or not.
And generally the applications that are using UDP
don't care if all of that information
got to the other side.
It's making a best effort to send that information out,
and it doesn't worry that it's not receiving
any acknowledgments back.
Because there are no acknowledgements or tracking
in UDP, there's no way to reorder or re-transmit
information through the network.
And usually the applications that
are using UDP as a protocol aren't concerned
with re-transmissions.
There's no need to retransmit a Voice over IP
communication in real time, so therefore UDP
makes a fine protocol for that particular purpose.
As with TCP, you can think of UDP
as that person who's loading the moving truck on one side
and unloading the moving truck on the other.
But in the case of UDP, the person
who is unloading the truck on the other side
doesn't really care if anything came in in the right order
or even if anything's missing, and will not
be sending any message back to the originating station
letting them know what was received on the other side.
When you start working with TCP/IP,
you start using port numbers especially
as you're referring to different applications.
In a single IP packet, you'll have a server IP address,
a server port number, a client IP address, and a client port
number.
And this is how the end stations are
able to send information to each other
and have them find their way to the correct service.
There's two types of ports we often reference in TCP and UDP.
Non-ephemeral ports are ports that are permanent.
They're ports that are set up for a particular application,
and those port numbers on a service will not change.
They are always that particular port.
When we refer to web servers as providing services
over port 80, that's a non-ephemeral port.
That port is always going to be port 80 on that web server
and that IP address so that everybody knows
what port number to use on that device
to access those web servers.
Ephemeral ports are temporary port numbers.
They're port numbers used so that you
can start a conversation and once that conversation is over,
that port number is no longer in use.
For example, if your device was communicating to a web server,
you're using an ephemeral port on your device
or temporary port number so that you
can create a connection to a non-ephemeral port
number on that web server.
When a device is given a port number,
whether it's TCP or UDP, the number
is going to range between 0 and 65,535.
As we mentioned earlier, most services
use non-ephemeral port numbers although there
are some services that are completely dynamic
and you'll connect to those services
at a different port number every time.
Don't worry about the details of exactly what number is being
used and when, you just need to understand
that to be able to communicate to this service,
we need to know the port number initially, and then
start the conversation.
Port numbers are there to facilitate communication.
They're not a security method.
You can certainly change the port number of your web server
from port 80 to port 3,000, but then you'd
have to tell everybody to communicate to this web server,
communicate over port 3,000.
The bad guys, though, know how to find the open port
numbers on your devices.
There are many port scanners available that do exactly that.
So even moving the port number from something
that's well known to something that's not so well known
doesn't provide you any more security.
It's only changing the way you're
communicating to that device.
If you're going to provide a service on the network,
then you need to make sure that all of the clients
know what port number you're going to use for that service.
That's why we use well known port numbers
for these services.
If you're going to communicate to a web server,
you're always going to use TCP port 80 and TCP port 443
because those are the well known port numbers for that web
service.
Although TCP and UDP can use port number ranges between 0
and 65,535, they are providing completely different services
and using completely different protocols.
You could have on one single machine
one service running TCP port 80 and a completely
different service providing information over UDP port 80.
Let's look at how these port numbers work together.
On our network, we have one computer--
my computer, 192.168.0.5-- and a web
server running 192.168.0.10 as its IP address.
There are services running on this web server that are
using well known port numbers.
UDP port 53 is used for DNS, TCP port 80
is used for non-encrypted web services,
and TCP port 443 is used for encrypted web services.
To communicate to these services,
our client device chooses an ephemeral port number--
TCP port 1331-- and communicates, for instance,
to TCP port 80.
It sends information back and forth,
and when this particular conversation is complete,
it closes out this particular traffic flow.
If this device now needs to perform more communication
to any of these services, it will
choose another ephemeral port number
and communicate to any of these non-ephemeral
or well known port numbers on this server.
Some of the most popular protocols on our networks
are web browsing protocols.
These are protocols used by web servers
but other applications may use exactly the same type
of protocol and the same port numbers as well.
Information sent to a web server can either
be in the clear or non-encrypted or it can be encrypted
information.
And we tend to use two different port
numbers to send these two different kinds of data
streams.
HTTP's protocol uses TCP port 80.
That is the clear and non-encrypted web server
communication that HTTP stands for hypertext transfer
protocol.
If you need to send secure or encrypted information
to the web server, you'll be using
HTTPS, that's the hypertext transfer protocol
secure protocol, and it uses TCP port 443
to have that encrypted channel to the web server.
Microsoft Windows has its own way of networking
that's specific to the Windows operating system.
And here are just a few of the protocols
used by the Windows OS.
These Microsoft protocols primarily
use NetBIOS and it's using them over TCP/IP.
So it's putting these NetBIOS messages
within the TCP/IP packets themselves.
And you'll notice that it's using both UDP
and TCP depending on what protocol is in use.
UDP port 137 is the NetBIOS name service.
So if you need to find a device on the network by name,
you're going to communicate via UDP 137.
UDP port 138 is the NetBIOS datagram service.
This is data transfer between two devices,
but because we're doing this via UDP,
we call this a connectionless service.
TCP port 139 is also a way to communicate and send
data between two devices on a Windows Network,
but this is a connection-oriented service
because we're using the TCP protocol instead of the UDP
protocol.
We use many different protocols to transfer
email between devices.
If you're running an email client on your device,
maybe you're running Outlook or Thunderbird,
then you're probably going to use
one of these kinds of protocols like POP3 IMAP4.
If you're using email that's in a browser,
like Google Mail or Yahoo Mail, then you're
using HTTP or HTTPS to communicate
to those web servers and not any of these specific email
protocols.
If there is an email server sending information
to an email server-- which means you're not involved
in that conversation-- you'll generally
see that traffic sent as SMTP.
If you're using a client and using POP3 or IMAP4,
you're using TCP port 110 for POP3-- that's the Post Office
Protocol version 3-- and if you're
using IMAP4 as your client protocol,
it's a TCP port 143 for the Internet Message Access
Protocol version 4.
If you have two email servers communicating to each other,
they're using Simple Mail Transfer Protocol or SMTP,
and that communicates over TCP port 25.
We're all using Voice over IP to communicate with our telephones
these days, but if you look at the actual communication
between all of the devices, you will find many different ports
and protocols in use.
One of the main protocols used with Voice over IP
is the session initiation protocol, or SIP.
It uses TCP ports 5060 and 5061 to set up
the signaling between two Voice over IP devices.
There are two media gateway control protocols.
One for the gateway and one for the call agent.
From the call agent to the gateway
is MGCP using UDP port 2427 and if it's
from the gateway to the call agent, it uses UDP port 2727.
There's also a real-time communication that takes place.
When you're talking with somebody on your Voice over IP
phone, there's a protocol that sends your digitized voice
information to the other side.
That protocol is the Real-time Transport Protocol, or RTP.
It uses a UDP protocol 5004 and 5005 to send that communication
across the network.
And lastly is another signaling protocol
you may use on your Voice over IP network.
You're either going to use SIP or you're going to use H.323.
This H.323 standard signaling protocol
uses TCP port 1720 to be able to communicate
that signaling information across the network.