The Linux Programming Interface

1270 Chapter 61

z LAST_ACK: The application performed a passive close, and the TCP, formerly

in the CLOSE_WAIT state, sent a FIN to the peer TCP and is waiting for it to

be acknowledged. When this ACK is received, the connection is closed, and

the associated kernel resources are freed.

To the above states, RFC 793 adds one further, fictional state, CLOSED, represent-

ing the state when there is no connection (i.e., no kernel resources are allocated to

describe a TCP connection).

In the above list we use the spellings for the TCP states as defined in the Linux

source code. These differ slightly from the spellings in RFC 793.

Figure 61-4 shows the state transition diagram for TCP. (This figure is based on diagrams

in RFC 793 and [Stevens et al., 2004].) This diagram shows how a TCP endpoint moves

from one state to another in response to various events. Each arrow indicates a pos-

sible transition and is labeled with the event that triggers the transition. This label is

either an action by the application (in boldface) or the string recv, indicating the

receipt of a segment from the peer TCP. As a TCP moves from one state to

another, it may transmit a segment to the peer, and this is indicated by the send label

on the transition. For example, the arrow for the transition from the ESTABLISHED

to the FIN_WAIT1 state shows that the triggering event is a close() by the local appli-

cation, and that, during the transition, the TCP sends a FIN segment to its peer.

In Figure 61-4, the usual transition path for a client TCP is shown with heavy

solid arrows, and the usual transition path for a server TCP is shown with heavy

dashed arrows. (Other arrows indicate paths less traveled.) Looking at the paren-

thetical numbering on the arrows in these paths, we can see that the segments sent

and received by the two TCPs are mirror images of one another. (After the ESTAB-

LISHED state, the paths traveled by the server TCP and the client TCP may be the

opposite of those indicated, if it is the server that performs the active close.)

Figure 61-4 doesn’t show all possible transitions for the TCP state machine; it

illustrates just those of principal interest. A more detailed TCP state transition

diagram can be found at http://www.cl.cam.ac.uk/~pes20/Netsem/poster.pdf.

61.6.4 TCP Connection Establishment

At the sockets API level, two stream sockets are connected via the following steps

(see Figure 56-1, on page 1156):

1. The server calls listen() to perform a passive open of a socket, and then calls
   accept(), which blocks until a connection is established.


2. The client calls connect() to perform an active open of a socket in order to estab-
   lish a connection to the server’s passive socket.

The steps performed by TCP to establish a connection are shown in Figure 61-5.

These steps are often referred to as the three-way handshake, since three segments

pass between the two TCPs. The steps are as follows:

1. The connect() causes the client TCP to send a SYN segment to the server TCP.
   This segment informs the server TCP of the client TCP’s initial sequence number