Transmission Control Protocol (TCP)
Transmission Control Protocol/Internet Protocol, the suite of communications protocols used to connect hosts on the Internet. TCP/IP uses several protocols, the two main ones being TCP and IP. TCP/IP is built into the UNIX operating system and is used by the Internet, making it the standard for transmitting data over networks. Even network operating systems that have their own protocols, such as Netware, also support TCP/IP. The IP protocol deals only with packets, and TCP enables two hosts to establish a connection and exchange streams of data. TCP guarantees delivery of data and also guarantees that packets will be delivered in the same order in which they were sent.
TCP makes up for IP's deficiencies by providing reliable, stream-oriented connections that hide most of IP's shortcomings. The protocol suite gets its name because most TCP/IP protocols are based on TCP, which is in turn based on IP. TCP and IP are the twin pillars of TCP/IP.
TCP adds a great deal of functionality to the IP service it is layered over:
The basic method of operation involves:
- Streams. TCP data is organized as a stream of bytes, much like a file. The datagram nature of the network is concealed.
- Reliable delivery. Sequence numbers are used to coordinate which data has been transmitted and received. TCP will arrange for retransmission if it determines that data has been lost.
- Network adaptation. TCP will dynamically learn the delay characteristics of a network and adjust its operation to maximize throughput without overloading the network.
- Flow control. TCP manages data buffers, and coordinates traffic so its buffers will never overflow. Fast senders will be stopped periodically to keep up with slower receivers.
- wrapping higher level application data in segments
- wrapping the segments into IP datagrams
- associating port numbers with particular applications
- associating a sequence number with every byte in the data stream
- exchanging special segments to start up and close down a data flow between two hosts
- using acknowledgments and timeouts to ensure the integrity of the data flow
TCP segments are constructed from 32 bit words and include a 20 byte (5 word) header. The information contained within is as follows:
- Source port number. The source (and destination) port numbers are used for sending the data stream to applications. It is entirely possible for there to be multiple simultaneous TCP data streams between two hosts. A TCP data stream is uniquely identified by a group of four numbers. These are the two hosts addresses and the two port numbers.
- Destination port number. This is the "target" port number on the remote system.
- Sequence Number. This 32 bit number identifies the first byte of the data in the segment.
- Acknowledgment Number. This 32 bit number is the byte number of the next byte that the sender expects to receive from the remote host. The remote host can infer that all bytes up to this number minus one have been safely received and the remote host's local copies can be discarded.
- Header Length. This 4-bit field specifies the header length in 32 bit words. Clearly the maximum value is 15 words (60 bytes) allowing for 10 (40 bytes) options.
- Flag Bits. This group of 6 bits identify various special states in the protocol. Several of the bits may be set simultaneously.
- Cheksum. This covers both the header and the data. It is calculated by prepending a pseudo-header to the TCP segment, this consists of 3 32 bit words which contain the source and destination IP addresses, a byte set to 0, a byte set to 6 (the protocol number for TCP in an IP datagram header) and the segment length (in words). The checksum field of the TCP segment is set to zero and an algorithm applied to the prepended segment treated as a sequence of 16 bit (unsigned) words.
- Flow Control. Flow control is associated with the current byte sequence numbers at each end of the data flow. Whenever a segment is sent it includes the sequence number of the last byte sent. A segment will also include the sequence number of the next byte that the sending host expects to receive, this is called the acknowledgment number (ACK). A host receiving a segment can assume that the remote host has safely received all bytes up to and including byte ACK-1, local copies may now be discarded.
TCP uses a 32-bit sequence number that counts bytes in the data stream. Each TCP packet contains the starting sequence number of the data in that packet, and the sequence number (called the acknowledgment number) of the last byte received from the remote peer. Each TCP peer must track both its own sequence numbering and the numbering being used by the remote peer.
TCP uses a number of control flags to manage the connection. Some of these flags pertain to a single packet, but two flags (SYN and FIN), require reliable delivery as they mark the beginning and end of the data stream. In order to insure reliable delivery of these two flags, they are assigned spots in the sequence number space. Each flag occupies a single byte.
Opening a TCP Connection
A TCP connection is opened by a three-way handshake to establish a common view of the sequence numbers. A connection will be initiated by an active client, the other end of the connection is described as the passive client, although in terms of the client/server software model this is likely to be a server. The passive client should be in a state known as LISTEN which simply means that it is expecting an incoming connection request.
The three way exchange involves the active client sending a SYN segment with the sequence number set to an arbitrary value (J). The passive client responds with a SYN segment with the acknowledgment number set to J+1 and the sequence number set to a further arbitrary value (K). The active client responds to the SYN segment by sending an ACK segment with the acknowledgment number set to K+1.
The "arbitrary" initial sequence number is required to increment approximately every 4 µs, this avoids delayed segments from a previous connection getting mixed up with a new connection. The initial sequence number will wrap in about 4‡ hours. Once a connection is established the sequence numbers can wrap much more quickly depending on traffic and line speed.
Closing a TCP Connection
The orderly close down of a TCP connection requires a four way exchange.
At the active end the application initiates the closure sequence, possibly by a close() system call on a socket. At the passive end receipt of the FIN segment causes the software to pass an "end-of-file" indication to the server software.
It should be noted that the exchange is really two independent exchanges and it is possible to close the connection in one direction but not the other. This is known as a half close.
RFC 793 defines MSL (Maximum Segment Lifetime) as 120 seconds but some implementations use 30 or 60 seconds. It is, basically, the maximum time for which it is reasonable to wait for a segment, i.e. if a segment doesn't reach its destination in MSL, it probably won't get there at all at it can be assumed that it has been lost.
Round-Trip Time Estimation
When a host transmits a TCP packet to its peer, it must wait a period of time for an acknowledgment. If the reply does not come within the expected period, the packet is assumed to have been lost and the data is retransmitted. The obvious question - How long do we wait? - lacks a simple answer. Over an Ethernet, no more than a few microseconds should be needed for a reply. If the traffic must flow over the wide-area Internet, a second or two might be reasonable during peak utilization times. If we're talking to an instrument package on a satellite hurtling toward Mars, minutes might be required before a reply. There is no one answer to the question - How long?
All modern TCP implementations seek to answer this question by monitoring the normal exchange of data packets and developing an estimate of how long is "too long". This process is called Round-Trip Time (RTT) estimation. RTT estimates are one of the most important performance parameters in a TCP exchange, especially when you consider that on an indefinitely large transfer, all TCP implementations eventually drop packets and retransmit them, no matter how good the quality of the link. If the RTT estimate is too low, packets are retransmitted unnecessarily; if too high, the connection can sit idle while the host waits to timeout.
Last Updated: 17 September 1999, 01:56