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.
