Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) are the two main transport protocols that support higher-level application protocols like the Simple Mail Transfer Protocol (SMTP) and the Hypertext Transfer Protocol (HTTP). In turn, TCP and UDP sit on top of the Internet Protocol (IP). The main feature of TCP is that it guarantees reliable delivery of packets, to the extent that dropped packets are retransmitted as required. However, reliable delivery in transport terms is different from reliable delivery assured by asynchronous messaging as might be implemented by a message queue. It is up to the application to provide for the storing and forwarding of packets if the network connection is broken. However, it’s important to note that while TCP aims for guaranteed delivery, UDP makes no such promises—indeed, the “User Datagram” Protocol may well be described as the “Unreliable Delivery” Protocol! The trade-off here is between guaranteed delivery and efficiency—UDP is more lightweight than TCP and can significantly reduce bandwidth requirements. In some applications where bandwidth is limited and connectivity is transient, such as noisy wireless signals, UDP is much more appropriate for use at the transport level. However, as broadband, highly reliable Ethernet is rolled out, fewer applications will use UDP compared to TCP. TCP is best suited to situations where a reliable network is always available, and where real-time interactions are necessary. For example, the telnet daemon uses TCP transport because interactive commands are issued in real time. In contrast, the biff daemon, which lets the user know that new mail has arrived, doesn’t really require real-time access because no interactive commands are issued. In this case, UDP is more appropriate than TCP.

In technical terms, TCP is a connection-oriented protocol, while UDP is a connectionless protocol. This means that where services use TCP to transmit data, a persistent connection must be maintained between the client and the server. There are some important differences in the way that data is packed using TCP and UDP—in TCP, sequence numbers are issued to ensure that packet delivery is consistent. UDP has much less restrictive requirements, which reduces the amount of bandwidth required to carry UDP traffic compared to equivalent services that utilize TCP.

All TCP and UDP services operate through a specific port. Sometimes, a service is offered over both TCP and UDP ports, such as the LDAP daemon, which operates on port 389 TCP and port 389 UDP. However, many services operate only on TCP or UDP. One service may operate on a specific TCP port, while a separate service may operate on the same numbered port for UDP. There are conventions for operating services on specific ports, although these may be modified on a local system. For example, the default port number for operating the Apache web server is port 80 TCP; however, any other TCP port may be used as long as it is not being used by another service. When a remote client connects to a locally operated service, a port listener receives the connection for the appropriate service as defined by the port number. This prevents data destined for one service from being diverted to another (inappropriate) service. A server socket is formed by the service port and the local IP address for the server. A client socket is formed in the same way, by the client’s IP address and the appropriate port. In this way, client/server interactions can be described by the two sockets. The kernel has a port table that it maintains to match up client and server ports and IP addresses, which can be viewed by using the netstat command:

# netstat

   Local Address    Remote Address    Swind Send-Q Rwind Recv-Q  State
---------------- -------------------- ----- ------ ----- ------ -------
ivana.telnet     austin.1040           8550      1 24820      0 ESTABLISHED
ivana.32807      ivana.32782          32768      0 32768      0 TIME_WAIT

Active UNIX domain sockets
Address  Type          Vnode     Conn  Local Addr      Remote Addr
30000b0dba8 stream-ord 300006cb810 00000000 /tmp/.X11-unix/X0
30000b0dd48 stream-ord 00000000 00000000

In this example, a socket comprised of the host ivana and the telnet port is servicing a telnet session for the client austin with the remote port 1040. All of the standard services are mapped in the services database (/etc/services). These ports are defined as part of the work of the Internet Engineering Task Force (IETF), and the Request For Comment (RFC) process for defining Internet standards ( Generally, standard services are defined for ports 1–1024, which correspond to privileged ports on UNIX because only the superuser may execute services that operate in this range.


Any user may execute services that operate on ports 1025 and above.

Exercise 37-1 Using netstat  Execute the netstat command on your local system. Can you identify any services that have active sockets that should be closed for security?

An example entry in /etc/services is shown here:

telnet          23/tcp

This entry defines the telnet service to run on port 23 TCP. A number of possible tokens can be contained within each service definition:

  • Name of service

  • Service port number

  • Service transport type

  • Aliases for service

Another convention in UNIX systems is to operate Internet services through a single superdaemon known as inetd. One advantage of running through inetd is that daemons can be configured using a single file (/etc/inetd.conf). However, with complex services like a web servers, it’s often preferable to configure them through their own configuration file.

Part I: Solaris 9 Operating Environment, Exam I