Three Way Handshake

A connection must be established explicitly between a client and a host before a TCP link can be used. As already noted, a distinction is made between active and passive connection setup.

The kernel (i.e., the kernel of both machines involved in the connection) sees the following situation immediately prior to connection establishment — the state of the client process socket is CLOSED, that of the server socket is LISTEN.

A TCP connection is set up by means of a procedure that involves the exchange of three TCP packets and is therefore known as a three-way handshake. As the state diagram in Figure 12-25 shows, the following actions take place:

□ The client sends SYN to the server26 to signal a connection request. The socket state of the client changes from CLOSED to SYN_SENT.

□ The server receives the connection request on a listening socket and returns SYN and ACK.27 The state of the server socket changes from LISTEN to SYN_REC.

□ The client socket receives the SYN/ACK packet and switches to the ESTABLISHED state, indicating that a connection has been set up. An ACK packet is sent to the server.

□ The server receives the ACK packet and also switches to the ESTABLISHED state. This concludes connection setup on both sides, and data exchange can begin.

In principle, a connection could be established using only one or two packets. However, there is then a risk of faulty connections as a result of leftover packets of old connections between the same addresses (IP addresses and port numbers). The purpose of the three-way handshake is to prevent this.

A special characteristic of TCP links immediately becomes apparent when connections are established. Each packet sent is given a sequence number, and receipt of each packet must be acknowledged by the TCP instance at the receiving end. Let us take a look at the log of a connection request to a web server28:

1 TCP 1025 > http [SYN] Seq=2895263889 Ack=0

2 TCP http > 1025 [SYN, ACK] Seq=2882478813 Ack=2895263890

3 TCP 1025 > http [ACK] Seq=2895263890 Ack=2882478814

The client generates random sequence number 2895263889 for the first packet; it is stored in the SEQ field of the TCP header. The server responds to the arrival of this packet with a combined SYN/ACK packet with a new sequence number (in our example, 2882478813). What we are interested in here is the contents of the SEQ/ACK field (the numeric field, not the flag bit). The server fills this field by adding the number of bytes received +1 to the sequence number received (the underlying principle is discussed below).

26This is the name given to an empty packet with a set SYN flag.

27This step could be split into two parts by sending one packet with ACK and a second with SYN, but this is not done in practice.

28Network connection data can be captured with tools such as tcpdump and wireshark.

Together with the set ACK flag of the packet, this indicates to the client that the first packet has been received. No extra packet need be generated to acknowledge receipt of a data packet. Acknowledgment can be given in any packet in which the ACK flag is set and the ack field is filled.

Packets sent to establish the connection do not contain data; only the TCP header is relevant. The length stored in the len field of the header is therefore 0.

The mechanisms described are not specific to the Linux kernel but must be implemented by all operating systems wishing to communicate via TCP. The sections below deal more extensively with the kernel-specific implementation of the operations described.

+1 0

Post a comment