3.2.16. The Internet Transport Protocol TCP

The Internet has two main protocols in the transport layer, a connection-oriented protocol TCP and a connectionless protocol UDP.

TCP (Transmission Control Protocol) was specifically designed to provide a reliable end-to-end byte stream over an unreliable network.

TCP was formally defined in RFC 793. As time went on, various errors were detected, and the requirements were changed. These clarifications are detailed in RFC 1122. Extensions are given in RFC 1323.

Each machine supporting TCP has a TCP transport entity, either a user process or part of the kernel that manages TCP streams and interfaces to the IP layer. A TCP entity accepts user data stream from local processes, break them up into pieces not exceeding 64K bytes (in practice, usually about 1500 bytes), and sends each piece as a separate IP datagram. When IP datagrams containing TCP data arrive at a machine, they are given to the TCP entity, which reconstructs the original byte streams.

The IP layer gives no guarantee that datagrams will be delivered properly, so it is up to TCP to time out and retransmit them as need to be. Datagrams that do arrive may well do so in the wrong order, it is also up to TCP to reassemble them into messages in the proper sequence. In short, TCP must furnish the reliability that most users want and that IP does not provide.

3.2.17. The TCP Service Model

TCP service is obtained by having both the sender and receiver create end points, called sockets. Each socket has a socket number (address) consisting of the IP address of the host and a 16-bit number local to that host, called a port. To obtain TCP service, a connection must be explicitly established between a socket on the sending machine and a socket on the receiving machine. The socket calls are listed in Fig. 6-6.

Fig. 6-6. The socket primitives for TCP.

A socket may be used for multiple connections at the same time. In other words, more connections may terminate at the same socket. Connections are identified by the socket identifiers at both ends, that is, (socket1, socket2).

Port numbers below 256 are called well-known ports and are reserved for standard services. For example, any process wishing to establish a connection to a host to transfer a file using FTP can connect to the destination host's port 21 to contact its FTP daemon. To establish a remote login session using TELNET, port 23 is used. The list of well-known ports is given in RFC 1700.

All TCP connections are full-duplex and point-to-point. TCP does not support broadcasting and multicasting.

A TCP connection is a byte stream, not a message stream. Message boundaries are not preserved end-to-end. For example, if the sending process does four 512-bytes writes to a TCP stream, this data may be delivered to the receiving process as four 512-bytes chunks, two 1024-bytes chunks, or some other way. There is no way for the receiver to detect the units in which the data were written.

When an application passes data to TCP, TCP may send it immediately or buffer it (in order to collect a larger amount to send at once), at its discretion. If an application wants the data to be sent immediately (e.g. TELNET), it can use the PUSH flag, which tells TCP not to delay the transmission.

TCP also recognizes urgent data. When an interactive user hits CTRL-C key to break off a remote computation, the sending application puts the appropriate data to the TCP along with the URGENT flag. This causes TCP to transmit the data immediately. When the urgent data are received at the destination, the receiving application is interrupted and read the data stream to find the urgent data. The end of the urgent data is marked, so the application knows when it is over. The start of the urgent data is not marked. It is up to the application to figure that out.

3.2.18. The TCP Protocol

Every byte on a TCP connection has its own 32-bit sequence number. The sequence numbers are used both for acknowledgments and for the window mechanism, which use separate 32-bit header fields.

The sending and receiving TCP entities exchange data in the form of segments. A segment consists of a fixed 20-byte header (plus an optional part) followed by zero or more data bytes. The TCP software decides how big segments should be. It can accumulate data from several writes into one segment or split data from one write over multiple segments. Each segment including the TCP header must fit in the 65535 byte IP payload.

The basic protocol used by TCP entities is the sliding window protocol. When a sender transmits a segment, it also starts a timer. When the segment arrives at the destination, the receiving TCP entity sends back a segment bearing an acknowledgment number equal to the next sequence number it expects to receive. "Sliding window" means that the sender is allowed to send without acknowledgment all bytes from the stream laying in a predefined window that is sliding ahead as the acknowledgment are coming. If the sender's timer goes off before the acknowledgment is received, the sender transmits the segment again. This sounds simple but there are many problems that can occur and the TCP has to solve them.

3.2.19. The TCP Segment Header

Fig. 6-24. The TCP header.

Fig. 6-24 shows the layout of a TCP segment. Its header contains the following fields:

• The Source port and Destination port - identify the local end points of the connection. Each host may decide for itself how to allocate its own ports starting at 256.
• The Sequence number and Acknowledgment number - perform their usual functions. The former indicates the byte sequence number of the first octet in this TCP data block and is incremented according to the number of octets transmitted in each TCP segment, the latter specifies the next byte expected, not the last byte correctly received.
• The TCP header length - the number of 32-bit words contained in the TCP header.
• 6-bits unused.
• Six 1-bit flags. URG is set to 1 if the Urgent pointer is in use. The Urgent pointer is used to indicate a byte offset from the current sequence number at which urgent data are to be found. The ACK bit is set to 1 to indicate that the Acknowledgment number is valid. If ACK is 0, the segment does not contain an acknowledgment. The PSH bit indicates PUSHed data. The receiver is hereby requested to deliver the data to the application upon arrival and not to buffer it. The RST bit is used to reset a connection that has become confused due to a host crash or some other reason. It is also used to reject an invalid segment or refuse an attempt to open a connection. The SYN bit is used to establish connections. It is used to denote CONNECTION REQUEST when ACK = 0 and CONNECTION ACCEPTED when ACK = 1. The FIN bit is used to release a connection. It specifies that the sender has no more data to transmit.
• The Window field tells how many bytes may be sent starting at the byte acknowledged. If equals 0, it says that the bytes up to and including Acknowledgment number - 1 have been received, but that the receiver would like no more data for the moment. Permission to send can be granted later by sending a segment with the same Acknowledgment number and nonzero Window field.
• Checksum checksums the header, the data, and the conceptual pseudoheader shown in Fig. 6-25.
• The Option field was designed to provide a way to add extra facilities not covered by the regular header. The most important option is the one that allows each host to specify the maximum TCP payload it is willing to accept. During connection setup, each side can announce its maximum and see its partner's. The smaller of the two numbers wins. If a host does not use this option, it defaults to a 536-byte payload. All Internet hosts are required to accept TCP segments of 536 + 20 = 556 bytes.

Fig. 6-25. The pseudoheader included in the TCP checksum.