Overview of Ports and Sockets

Overview of Ports and Sockets

On a TCP/IP network, data travels from a port on the sending computer to a port on the receiving computer. A port is a numerical value that identifies the application associated with the data. The source port number identifies the application that sent the data, and the destination port number identifies the application that receives the data. Each port is assigned a unique 16-bit number in the range of 0 through 65535. Additionally, there are two types of ports—TCP and UDP—which are based on their respective protocols. Both TCP and UDP maintain a separate list of used (reserved and allocated) port numbers. This allows them both to make sure no
port is duplicated within each list. A benefit of this mechanism is that multiple application data streams can be multiplexed through each protocol simultaneously. For example, it is no problem for TCP to handle HTTP traffic and FTP traffic simultaneously, nor is it a problem for UDP to allow TFTP and SNMP simultaneous access to the network.

Note:

Of course, simultaneous access is a figurative expression because, as with all serial data flows, only one data source can be serviced at a time. The appearance of simultaneous operation is achieved through time-division multiplexing, which interleaves the separate flows into one.

The very existence of ports and their numbers is more or less transparent to the users of the network because many server-side ports are standardized. Thus, a client application protocol
will know which remote port it should connect to for a specific service. For example, all servers that offer Telnet services usually do so on TCP port 23, and web servers normally run on TCP
port 80. This means that when you connect to the Internet to browse to a web server, you automatically connect to port 80, and when you use Telnet, you automatically connect to port 23.
The TCP/IP protocol suite uses a modifiable lookup table to determine the correct port for the data type. Table 3.1 lists some of the well-known port numbers for common protocols.

TABLE 3 . 1 Well-Known Port Numbers for Common Protocols

ــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــ
       Port                                           Protocol
ــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

       UDP port 15                               NETSTAT

       TCP port 20                                FTP data
       TCP port 21                                FTP control
       TCP port 22                                SSH
       TCP port 23                                Telnet
       TCP port 25                                SMTP
       TCP port 53                                DNS zone transfers
       UDP port 53                                DNS queries
       UDP port 69                                TFTP
       TCP port 70                                Gopher
       TCP port 79                                Finger
       TCP port 80                                HTTP
       TCP port 110                              POP3
       UDP port 111                              RPC
       TCP port 119                              NNTP
       TCP port 123                              NTP
       UDP port 137                              NetBIOS name service
       TCP port 143                               IMAP4
       UDP port 161                              SNMP
       TCP port 443                               HTTPS
       UDP port 520                               RIP

       UDP port 2049                             NFS
ــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــ

Client application protocols require identification by port numbers as well, but they could not possibly each have their own well-known port numbers, which is where registered port numbers come in. Registered port numbers begin at 1024 and extend to 49151. These port numbers are used by TCP and UDP alike to be temporarily assigned to client application protocols as they begin their journey to the remote device and its server application protocol. Ports from 49152 to 65535 are considered dynamic ports and/or private ports.

The combination of an IP address (more on IP addresses in a moment) and a port number is known as a socket. A socket identifies a single network process in terms of the entire Internet or other endto- end IP-based internetwork. Two sockets—one on the sending system and one on the receiving host—are needed to define a connection for connection-oriented protocols, such as TCP. You may hear or see the terms socket and port used as if they are interchangeable terms, but they are not.

Note:

In the Novell NetWare world, a socket is part of an IPX internetwork address
and acts as a destination for the IPX data packet. Most socket numbers are allocated
dynamically, but a few are associated with specific functions.

Sockets were first developed as a part of the BSD UNIX system kernel, in which they allow processes that are not running at the same time or on the same system to exchange information.
You can read data from or write data to a socket just as you can with a file. Socket pairs are bidirectional so that either process can send data to the other.

The Two Ports and Modes of FTP

You may have noticed in Table 3.1 that FTP has two TCP ports associated with it, one for control and the other for data. Additionally, FTP runs in two modes: active and passive. In every FTP active-mode session, both of these ports are used on the server but in very different capacities. Because the use of the FTP protocol implies that resources will be available across a potentially
insecure public infrastructure, it is important that the administrator of those resources have the last word as to their availability. This is where the two ports come into play. Port 21, the FTP control port, is targeted by the client when an FTP session is being requested of the server. In this request directed at the server’s TCP port 21, the client issues a PORT command, whereby it communicates to the server the random TCP port it would like the server to send data back to. This randomly assigned port will generally be one greater than the port it was using to source the traffic to port 21. The server then opens a TCP connection sourced from its own port 20, the
FTP data port, back to this advertised port on the client. Once this TCP connection is established, data transfer can commence across it. This prevents the client from simply reaching over to the server and grabbing whatever it wants without first being authenticated. The port 20 connection can be postponed, pending proper authentication from the client.
That’s how the active-mode FTP connection works. What if a firewall local to the user is secure enough not to allow what appears to be an externally initiated TCP connection? Well, then the
second half of the FTP process fails because that’s exactly what the server’s port-20-initiated connection is and data transfer never actually occurs. Why not let the client initiate the data connection
to port 20 at will? Well, if the server merely lets any and every client gain immediate access to its resources without authentication, FTP wouldn’t last very long as a successful protocol. One
solution is for everything to start the same way it does for the active-mode FTP connection, but instead of the server initiating the second session from port 20, it actually opens a random port,
as the client did, and asks the client to use that port to effect its data transfers. All of this can be done in the initial port 21 control phase, allowing any authentication the administrator has configured
to occur before this random port number is shared with the client. How does the server know the client wishes to start this type of connection and not have the server open a connection of its own from port 20? Instead of issuing the PORT command, as it did in the active-mode connection, the client issues the PASV command, indicating to the server that the client itself needs to open the data connection. This is known as passive-mode FTP. Not all client software supports passive-mode FTP, but most modern versions do. A key difference between the modes is that active mode uses both ports 20 and 21 but passive mode only uses port 21, substituting a registered port, greater than 1024, for port 20.