UDP provides the basics for transferring data between processes on different computers. But using UDP alone, the source doesn’t know whether or not a destination received the data sent. TCP uses a system of sequence and acknowledgment numbers that enable the destination to acknowledge receiving specific data bytes. Using sequence numbers, a destination can place received messages in the order they were sent, even if they were received out of order. Sequence numbers also enable a destination to detect duplicate received data. For more efficient transfers of large amounts of data, TCP specifies a way for the source to match the amount of data sent with the ability of the destination to accept new data. The document that defines TCP is RFC0793: Transmission Control Protocol. It’s also an approved standard with the designation STD0007.

Several additional RFCs contain proposed standards that enhance and improve the original standard. TCP is a called a connection-oriented protocol because processes can’t exchange data until they have exchanged communications to establish a connection with each other. TCP is called a reliable protocol because the handshaking, checksum, and sequence and acknowledge numbers enable the source to verify that data has arrived at its destination without error. A TCP segment consists of a header optionally followed by a data payload. (A header might transmit without a data payload to send status or control information.) The term segment suggests that a single TCP segment is only a portion of a complete TCP data transfer, and in fact, every successful data transfer uses at least two segments. The source sends one or more segments containing data, and the destination sends one or more segments to acknowledge receiving the data. A single acknowledgment can acknowledge multiple segments. In contrast, each UDP datagram is an independent unit that requires no additional communication. Like UDP, TCP uses port numbers to identify processes at the source and destination.

Before two processes can send and receive data using TCP, their computers must establish a connection by performing a 3-way handshake. On completing the handshake, each computer has acknowledged that the port specified in the handshake is available to receive communications from the specified port on the other computer. Either computer may then use the connection to send TCP segments to the other computer. On receiving a data over an established connection, the destination responds by returning information about whether the data arrived without error, whether it’s OK to send more data, and if so, the quantity of new data the destination is able to receive. To close a connection, each computer sends a request to close the connection and waits for an acknowledgment of the request.

The TCP Header

The header of a TCP segment has ten required fields and one optional field. The header is at least 20 bytes. Data following the header is optional. Table 5-5 shows the fields. Source Port Number. The source port number identifies the port, or process, on the computer that is sending the message. A TCP segment must include a source port number so the destination knows where to send the acknowledgment. This field is two bytes. Destination Port Number. The destination port number identifies the port, or process, that should receive the message at the destination. This field is two bytes. Sequence Number. The sequence number, also called the segment sequence number, identifies the segment. The sequence number enables the destination to acknowledge receiving the data in a specific segment. When a source sends a message that requires multiple segments, the sequence numbers enable the destination to place the segments in order even if they arrive out of order. In the first segments sent when establishing a connection, each computer provides an initial sequence number. The TCP standard recommends select ing this number by using the value of a counter that increments every four microseconds. Using a counter helps to prevent duplicate numbers if a connection closes, then reopens. For segments that include data, the sequence number is also the number of the first data byte in the segment, with the following data bytes numbered in sequence. If the source sends another segment using the same connection, that segment’s sequence number equals the previous segment’s sequence number plus the number of data bytes in the previous segment. For example, assume that a source sends three segments, each with 100 data bytes, and the first segment’s sequence number is 1000. The second segment’s sequence number is 1100 (1000 + 100) and the third segment’s sequence number is 1200 (1100 + 100). If a sequence number reaches the maximum value of 232-1, it wraps back to zero. This field is four bytes.

Acknowledgment Number. The destination computer returns an acknowledgment number to let the source know that a specific segment or segments were received. The field is valid when the ACK control bit described below is set to 1. The acknowledgment number equals the sequence number of the last received byte in sequence plus 1. This value is also the sequence number the destination expects in the next received segment. In returning an acknowledgment number, the computer is saying that it has received all of the data up to one less than the acknowledgment number. For example, if we again assume that a source sends three segments, each with 100 data bytes, and the first segment’s sequence number is 1000, on receiving the first segment, the destination could return a header with an acknowledgment number of 1100. On receiving the second segment (with a sequence number of 1100), the destination could return an acknowledgment number of 1200. On receiving the third segment, the returned acknowledgment number would be 1300. The destination doesn’t have to return a acknowledgment for every received segment. In the above example, the destination could wait until it received all three segments. It would then return a single segment with an acknowledgment number of 1300, indicating that all of the data bytes through 1299 have been received. But if the destination waits too long before acknowledging, the source will think the data didn’t reach its destination and will resend. In the above example, if the destination receives only the first and last segments, with segment numbers 1000 and 1200, it can return an acknowledgment number of 1100, but should wait to receive the middle segment, with the segment number 1100, before returning an acknowledgment number of 1300. This field is four bytes. Header Length. Because a TCP header’s length can vary depending on the contents of the TCP Options field, the header includes a field that specifies the header’s length. The value is in units of 32 bits, so all headers must be multiples of 32 bits, padded with zeros at the end if necessary. A header with no TCP Options field has a Header Length of 5, to indicate a header size of 160 bits, or 20 bytes.

This field is four bits. Reserved Field. This field is six bits, all zeroes. Control Bits. The control-bits field is six bits. The bits provide information about the status of the connection, tell the destination something about when to process the data, and enable the source to inform the destination of a change in status of the connection. The following sections describe the meaning of each bit, in order as they appear in the header, when the bit is equal to 1. URG. The segment is urgent. Urgent segments use the Urgent Pointer field described below. ACK. The header contains a valid acknowledgment number. When establishing a TCP connection, each computer sets this bit in the first segment that acknowledges receiving a header containing a sequence number, and in all segments that follow in the connection. PSH. The receiver should push, or send, the segment’s data to the receiving application as soon as possible. If a computer normally waits for a buffer to fill before passing received data to an application, the PSH bit can advise the computer to pass data to the application right away, even if the buffer isn’t full. RST. Reset the connection. RST provides a way to recover if a connection becomes unsynchronized or invalid. A computer sends a segment with the RST bit set after receiving a segment that doesn’t appear to be intended for the current connection, or if the connection has been closed. Receiving a segment with the RST bit set informs a computer that it should end the current connection and start over in establishing a connection. For example, if one computer in a connection crashes and restarts, the previous connection is no longer valid, but the other computer may not know this and may continue sending data. On receiving a segment for a closed connection, the destination returns a segment with RST set to let the source know that the computers need to re-establish the connection. SYN. Synchronization is in progress. Synchronization is the process of performing the 3-way handshake to establish a TCP connection. The SYN bit is set to 1 until the handshake is complete, indicating the connection is established. In all of the segments that follow, the SYN bit is zero. FIN. The source has no more data to send. The source may set this bit in the header of the segment containing the final data sent in a connection, or in a header that follows this segment. Window. Window is the number of new bytes the receiving computer can accept.

The value may change with each segment a computer sends, depending on how much buffer space is available. A source may use the received value in determining how much data to send in the next segment. The maximum window size is 65535 bytes. If a destination’s window is zero, a source that wants to send data may send a single byte periodically to cause the destination to return an updated window value. This field is two bytes. Checksum. TCP requires a checksum. The source and destination calculate the checksum on the contents of the TCP segment plus a pseudo header containing information from the IP header and the TCP segment length. Table 5-6 shows the values in the pseudo header. As with UDP, the pseudo header doesn’t transmit on the network and including the pseudo header in the checksum protects the destination from mistakenly accepting datagrams that have been misrouted. The checksum value is calculated in the same way as the IP header’s checksum, as described in Chapter 4. The field is two bytes. Urgent Pointer. When the URG bit is set, the urgent pointer marks the end of the urgent data. The value is the sequence number of the last byte of urgent data, expressed as an offset from the segment’s sequence number. For example, if the segment’s sequence number is 1000 and the first 8 bytes are urgent data, the urgent pointer would be 8. A typical use for the urgent pointer is to enable a user to interrupt a process. The wording of the original TCP standard left some confusion about whether the URG pointer points to the last byte of urgent data or the first byte following the urgent data. RFC 1122 clarifies by saying that URG should point to the last byte of urgent data. This field is two bytes.

TCP Options. The items in the TCP options field are optional, so this field is zero or more bytes. The Maximum Segment Size option enables the receiving process to specify the maximum segment size the process can handle. A process uses this option only when establishing a connection, in a segment where the SYN bit is set. The option is four bytes, consisting of the byte 02h, followed by 04h, followed by two bytes that specify the maximum segment size. The No Operation option provides a way to align options on a word boundary. The option is the single byte 01h. The End of Option List option indicates that there are no more options in the field. This option is the byte 00h. The complete TCP header must be a multiple of 32 bits. To achieve this, the end of the TCP Options field may be padded with zeros. The Data Portion. Following the header is the optional data portion of the segment. The IP standard requires hosts to accept datagrams of up to 576 bytes. An IP header with no options is 20 bytes, and a TCP header with no options is also 20 bytes. So a TCP segment with up to 536 data bytes and no IP options or TCP options should be able to reach its destination without fragmenting.