TCP Q&A

1. What is TCP?

   Transmission Control Protocol (TCP) provides a reliable byte-stream transfer service between two endpoints on an internet. TCP depends on IP to move packets around the network on its behalf. IP is inherently unreliable, so TCP protects against data loss, data corruption, packet reordering and data duplication by adding checksums and sequence numbers to transmitted data and, on the receiving side, sending back packets that acknowledge the receipt of data.

   Before sending data across the network, TCP establishes a connection with the destination via an exchange of management packets. The connection is destroyed, again via an exchange of management packets, when the application that was using TCP indicates that no more data will be transferred. In OSI terms, TCP is a Connection-Oriented Acknowledged Transport protocol.

   TCP has a multi-stage flow-control mechanism which continuously adjusts the sender's data rate in an attempt to achieve maximum data throughput while avoiding congestion and subsequent packet losses in the network. It also attempts to make the best use of network resources by packing as much data as possible into a single IP packet, although this behaviour can be overridden by applications that demand immediate data transfer and don't care about the inefficiencies of small network packets.

   The fundamentals of TCP are defined in RFC 793, and later RFC's refine the protocol. RFC 1122 catalogues these refinements as of October 1989 and summarises the requirements that a TCP implementation must meet.

   TCP is still being developed. For instance, RFC 1323 introduces a TCP option that can be useful when traffic is being carried over high-capacity links. It is important that such developments are backwards-compatible. That is, a TCP implementation that supports a new feature must continue to work with older TCP implementations that do not support that feature.

2. How does TCP try to avoid network meltdown?

   TCP includes several mechanisms that attempt to sustain good data transfer rates while avoiding placing excessive load on the network. TCP's "Slow Start", "Congestion Avoidance", "Fast Retransmit" and "Fast Recovery" algorithms are summarised in RFC 2001. TCP also mandates an algorithm that avoids "Silly Window Syndrome" (SWS), an undesirable condition that results in very small chunks of data being transferred between sender and receiver. SWS Avoidance is discussed in RFC 813. The "Nagle Algorithm", which prevents the sending side of TCP from flooding the network with a train of small frames, is described in RFC 896.

   Van Jacobson has done significant work on this aspect of TCP's behaviour. The FAQ used to contain a couple of pieces of historically interesting pieces of Van's email concerning an early implementation of congestion avoidance, but in the interests of saving space they've been removed and can instead be obtained by anonymous FTP from the end-to-end mailing list archive at <ftp://ftp.isi.edu/end2end/end2end-1990.mail>. PostScript slides of a presentation on this implementation of congestion avoidance can be obtained by anonymous FTP from <ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z>.

   That directory contains several other interesting TCP-related papers, including one (<ftp://ftp.ee.lbl.gov/papers/fastretrans.ps>) by Sally Floyd that discusses a algorithm that attempts to give TCP the ability to recover quickly from packet loss in a network.

3. How do applications coexist over TCP and UDP?

   Each application running over TCP or UDP distinguishes itself from other applications using the service by reserving and using a 16-bit port number. Destination and source port numbers are placed in the UDP and TCP headers by the originator of the packet before it is given to IP, and the destination port number allows the packet to be delivered to the intended recipient at the destination system.

   So, a system may have a Telnet server listening for packets on TCP port 23 while an FTP server listens for packets on TCP port 21 and a DNS server listens for packets on port 53. TCP examines the port number in each received frame and uses it to figure out which server gets the data. UDP has its own similar set of port numbers.

   Many servers, like the ones in this example, always listen on the same well-known port number. The actual port number is arbitrary, but is fixed by tradition and by an official allocation or "assignment" of the number by the Internet Assigned Numbers Authority (IANA).

4. Where do I find assigned port numbers?

   The IANA allocates and keeps track of all kinds of arbitrary numbers used by TCP/IP, including well-known port numbers. The entire collection is published periodically in an RFC called the Assigned Numbers RFC, each of which supersedes the previous one in the series. The current Assigned Numbers RFC is RFC 1700.

   The Assigned Numbers document can also be obtained directly by FTP from the IANA at <ftp://ftp.isi.edu/in-notes/iana/assignments>.

5. What are Sockets? A socket is an abstraction that represents an endpoint of communication. Most applications that consciously use TCP and UDP do so by creating a socket of the appropriate type and then performing a series of operations on that socket. The operations that can be performed on a socket include control operations (suchas associating a port number with the socket, initiating or accepting a connection on the socket, or destroying the socket) data transfer operations (such as writing data through the socket to some other application, or reading data from some other application through the socket) and status operations (such as finding the IP address associated with the socket). The complete set of operations that can be performed on a socket constitutes the Sockets API (Application Programming Interface). If you are interested in writing programs that use TCP/IP then you'll probably need to use and understand the sockets API. Your system manuals may have a description of the API (try `man socket' if you're using a Unix system) and many books devote chapters to it. A FAQ list for sockets programming is available on the Web from its Canadian home at from a UK mirror at or by anonymous FTP from . The TLI (Transport Layer Interface) API provides an alternative programming interface to TCP/IP on some systems, notably those based on AT&T's System V Unix. The Open Group, a Unix standards body, defines a variation of TLI called XTI (X/Open Transport Interface). Note that both sockets and TLI (and XTI) are general-purpose facilities and are defined to be completely independent of TCP/IP. TCP/IP is just one of the protocol families that can be accessed through these API.
   
6. How can I detect that the other end of a TCP connection has crashed? Can I use "keepalives" for this?
   Detecting crashed systems over TCP/IP is difficult. TCP doesn't require any transmission over a connection if the application isn't sending anything, and many of the media over which TCP/IP is used (e.g. Ethernet) don't provide a reliable way to determine whether a particular host is up. If a server doesn't hear from a client, it could be because it has nothing to say, some network between the server and client may be down, the server or client's network interface may be disconnected, or the client may have crashed. Network failures are often temporary (a thin Ethernet will appear down while someone is adding a link to the daisy chain, and it often takes a few minutes for new routes to stabilize when a router goes down) and TCP connections shouldn't be dropped as a result.
   
   Keepalives are a feature of the sockets API that requests that an empty packet be sent periodically over an idle connection; this should evoke an acknowledgement from the remote system if it is still up, a reset if it has rebooted, and a timeout if it is down. These are not normally sent until the connection has been idle for a few hours. The purpose isn't to detect a crash immediately, but to keep unnecessary resources from being allocated forever. If more rapid detection of remote failures is required, this should be implemented in the application protocol. There is no standard mechanism for this, but an example is requiring clients to send a "no-op" message every minute or two. An example protocol that uses this is X Display Manager Control Protocol (XDMCP), part of the X Window System, Version 11; the XDM server managing a session periodically sends a Sync command to the display server, which should evoke an application-level response, and resets the session if it doesn't get a response (this is actually an example of a poor implementation, as a timeout can occur if another client "grabs" the server for too long).
   
7. Can the TCP keepalive timeouts be configured?
   This varies by operating system. There is a program that works on many Unices (though not Linux or Solaris), called netconfig, that allows one to do this and documents many of the variables. It is available by anonymous FTP from . In addition, Richard Stevens' TCP/IP Illustrated, Volume 1 includes a good discussion of setting the most useful variables on many platforms.