Introduction
Recall that TCP’s service model is a byte stream.
TCP detects and repairs essentially all the data transfer problems that may be introduced by packet loss, duplication, or errors at the IP layer (or below).
UDP is a connectionless protocol that involves no con- nection establishment or termination.
Some options are allowed to be sent only when the connection is established, and others can be sent later.
Recall from Chapter 12 that the TCP header has a limited space for holding options (40 bytes)
TCP Connection Establishment and Termination
A TCP connection is defined to be a 4-tuple consisting of two IP addresses and two port numbers.
More precisely, it is a pair of endpoints or sockets where each end- point is identified by an (IP address, port number) pair.
A connection typically goes through three phases: setup, data transfer (called established), and teardown (closing).
the following events usually take place:
1. The active opener (normally called the client) sends a SYN segment (i.e., a TCP/IP packet with the SYN bit field turned on in the TCP header)
specify- ing the port number of the peer to which it wants to connect
and the client’s initial sequence number or ISN(c) (see Section 13.2.3).
It typically sends one or more options at this point (see Section 13.3). This is segment 1.
2 The server responds with its own SYN segment containing its initial sequence number (ISN(s)).
This is segment 2. The server also acknowledges the client’s SYN by ACKing ISN(c) plus 1.
A SYN consumes one sequence number and is retransmitted if lost.
3 The client must acknowledge this SYN from the server by ACKing ISN(s) plus 1. This is segment 3.
This is often called the three-way handshake.
Its main purposes are to let each end of the connec- tion know that a connection is starting and
the special details that are carried as options, and to exchange the ISNs.
In Section 13.2.2 we describe a supported but unusual simultaneous open when
both sides can do an active open at the same time and become both clients and servers.
Either end can initiate a close operation, and simultaneous closes are also supported but are rare.
Usually a close operation starts with an application indicating its desire to terminate its connection (e.g., using the close() system call).
The closing TCP initiates the close operation by sending a FIN segment (i.e., a TCP segment with the FIN bit field set).
1 The active closer sends a FIN segment specifying the current sequence num- ber the receiver expects to see (K in Figure 13-1).
The FIN also includes an ACK for the last data sent in the other direction (labeled L in Figure 13-1).
2 The passive closer responds by ACKing value K + 1 to indicate its success- ful receipt of the active closer’s FIN.
At this point, the application(server) is noti- fied that the other end of its connection has performed a close.
Typically this results in the application initiating its own close operation.
The passive closer then effectively becomes another active closer and sends its own FIN.
The sequence number is equal to L(server not waste sn yet).
3 To complete the close, the final segment contains an ACK for the last FIN.
Note that if a FIN is lost, it is retransmitted until an ACK for it is received.
This reason is that TCP’s data communica- tions model is bidirectional, meaning it is possible to have only one of the two directions operating.
The half-close operation in TCP closes only a single direction of the data flow.
Two half-close operations together close the entire connection.
There are more abrupt ways to tear down a TCP connection using special reset segments, which we cover later.
When a small amount of data needs to be exchanged, it is now apparent why some applications prefer to use UDP because of its ability to send and receive data with- out establishing connections.
TCP Half-Close
The Berkeley sockets API supports half-close, if the application calls the shutdown() function instead of calling the more typical close() func- tion.
Most applications, however, terminate both directions of the connection by calling close.
Figure 13-2 shows an example of a half-close being used. We show the client on the left side initiating the half-close, but either end can do this.
When the end that received the half-close is done sending data, it closes its end of the connection, causing a FIN to be sent,
and this delivers an end-of-file indication to the application that initiated the half-close.
Simultaneous Open and Close
It is possible, although highly improbable unless specifically arranged, for two applications to perform an active open to each other at the same time.
The only real difference is that the segment sequence is inter- leaved instead of sequential.
Initial Sequence Number (ISN)
This brings up the question of whether it might be possible to have TCP segments being routed through the net- work that could show up later and disrupt a connection.
This concern is addressed by careful selection of the ISN.
Before each end sends its SYN to establish the connection, it chooses an ISN for that connection.
The ISN should change over time, so that each connection has a different one.
[RFC0793] specifies that the ISN should be viewed as a 32-bit counter that increments by 1 every 4μs.
The purpose of doing this is to arrange for the sequence numbers for segments on one connection to not overlap with sequence numbers on a another (new) identical connection.
In particular, new sequence numbers must not be allowed to overlap between different instantiations (or incarnations) of the same connection.
The idea of different instantiations of the same connection becomes clear when we recall that a TCP connection is identified by a pair of endpoints, creat- ing a 4-tuple of two address/port pairs.
If a connection had one of its segments delayed for a long period of time and closed, but then opened again with the same 4-tuple,
it is conceivable that the delayed segment could reenter the new connec- tion’s data stream as valid data.
This would be most troublesome. By taking steps to avoid overlap in sequence numbers between connection instantiations, we can try to minimize this risk.
It does suggest, however, that an application with a very great need for data integrity should employ its own CRCs or checksums at the application layer to ensure that its own data has been transferred without error.
This is generally good practice in any case, and it is commonly done for large files.
As we shall see, knowing the connection 4-tuple as well as the currently active window of sequence numbers is all that is required to form a TCP segment that is considered valid to a communicating TCP endpoint.
This represents a form of vul- nerability for TCP: anyone can forge a TCP segment and, if the sequence numbers, IP addresses, and port numbers are chosen appropriately, can interrupt a TCP connection [RFC5961].
One way of repelling this is to make the initial sequence number (or ephemeral port number [RFC6056]) relatively hard to guess. Another is encryption (see Chapter 18).
Example
second segment:
...
This segment also includes a window advertisement indicating that the server is willing to accept up to 64,240 bytes.
...
finish third segment:
...
This segment also (redundantly) ACKs the client’s FIN once again.
...
Note that the PSH bit field is on. This has no real effect on the closing of the connection but usually indicates that the server has no additional data to send.
...
One thing we can see in Figure 13-5 is that the SYN segments contain one or more options.
These take up additional space in the TCP header. For example, the length of the first TCP header is 44 bytes, 24 bytes greater than the minimum size.
...
Timeout of Connection Establishment
There are several circumstances in which a connection cannot be established. One obvious case is when the server host is down.
If, however, we place an ARP entry for a nonexistent host in the ARP table first, the ARP request is not sent,
and the system immediately attempts to contact the nonexistent host with TCP/IP.
The interesting point in this output is how frequently the client’s TCP sends a SYN to try to establish the connection.
The second segment is sent 3s after the first, the third is sent 6s after the second, the fourth is sent 12s after the third, and so on.
This behavior is called exponential backoff .
The number of times to retry an initial SYN can be configured on some sys- tems and usually has a fairly small value such as 5.
In Linux, the system configura- tion variable net.ipv4.tcp_syn_retries gives the maximum number of times to attempt to resend a SYN segment during an active open.
A corresponding value called net.ipv4.tcp_synack_retries gives the maximum number of times to attempt to resend a SYN + ACK segment when responding to a peer’s active open request.
It can also be used on an individual connection basis by setting the Linux-specific TCP_SYNCNT socket option.
Its default value is five retries, as we see here.
The exponential backoff timing between these retransmissions is part of TCP’s congestion management response.
We shall examine it in detail when we discuss Karn’s algorithm (see Chapter 16).