Home > Experiential Learning > Experiential Learning of Networking Technologies: Understanding TCP States – Part 2

Experiential Learning of Networking Technologies: Understanding TCP States – Part 2


Ram P. Rustagi

Department of CSE, KSIT Bangalore

Viraj Kumar

Divecha Centre for Climate Change, IISc Bangalore


This article focuses on the states of a TCP connection once one of the endpoints decides to terminate the connection. This so-called teardown phase involves the exchange of numerous messages (for reasons we will explore), and the TCP connection itself transitions through several states. Web developers often have only an overly simplistic understanding of these states, which may suffice when the network behaves reliably. However, a deeper understanding of TCP states is essential to design web applications that robustly manage TCP connections even in the presence of network faults during the teardown phase, and debug poorly design applications that exhibit poor resource utilization and poor performance in such situations. As always, we will explore these issues through a series of experiential learning exercises.

1 Introduction

In the last article [8], we discussed the three phases of TCP [1] communication: (1) connection setup, (2) data transfer, and (3) teardown. For each TCP connection, the two machines communicating via this connection independently maintain information about the present state of this connection from their own perspective (one of the 11 possible states listed in Table 2). The last column of this table lists the states of a TCP connection after one of the machines decides to close the connection by initiating connection termination. In case of any abnormal network behaviour, an understanding of these states of the TCP connection is critical to accurately diagnose problems and resolve them.

For experiential understanding of these TCP states and the Transport layer [2], we need a basic setup consisting of two machines $H_{1}$ and $H_{2}$ connected via a network as shown in Figure 1. We will make use of i) a network utility called netcat (nc) [5][6] that can be used to create both a TCP client and a TCP server (for the latter, run with the option 1), ii) a utility to implement firewalls functionality called iptables [7], and iii) some custom applications (simple Python programs) to depict the typical application behaviour.

As extensively discussed in [8], the two machines exchange messages during connection setup (Phase 1) and data is transferred during Phase 2 when both machines “agree” that the TCP connection state is ESTABLISHED.

Table 1: TCP Connection state in various phase of communication
Initial (no connection) Phase 1 Connection Setup Phase 2 Data Transfer Phase 3 Connection Tear Down
Figure 1: Basic setup of conducting TCP learning exercises

2 TCP Teardown (Phase 3)

At some point during Phase 2, one of the applications will decide that it does not need to transmit data any more and will initiate connection closure (i.e., the TCP connection will enter the teardown phase, Phase 3). This application (which can be either the client or the server application) will follow the Active Close path in Figure 2 (shown on the left in purple colour), and the other application will follow the Passive Close path (shown on the right in orange colour). Each sent message is identified by a number in parentheses (n), and when this is received it is identified as (n). It should be noted that even though connection initiation (connection setup in Phase 1) is always by a client, connection termination can be initiated by either the client or the server (or by both at the same time – a very rare case that is generally not seen in real-life applications).

Figure 2: TCP connection teardown phase

To understand why so many states are necessary in Phase 3, note that data transfer may continue for a long time after connection closure is initiated. As a concrete example, consider a typical case of web communication where a web client is downloading a large file (e.g., an image or a document). After the client sends the URL details (which may correspond to only a few hundred bytes, including HTTP headers), it need not send any further data and it may decide to initiate TCP connection closure (to better manage client-side Operating System resources). Despite this, the application should continue to receive data until the server has sent the full file. The connection can only be closed after the server has sent the last byte (which could be for several minutes or even hours after the client’s initial request for closure) and has received the corresponding TCP-level acknowledgement (in accordance with TCP reliable delivery). Keeping in mind that some messages can be lost due to network faults, TCP states must maintain enough information to properly manage the connection. For ease of understanding, let us first consider the simpler (and more common) scenario when the network functions correctly.

3 TCP Connection Closure – Normal case

Phase 3 starts when either the client or the server application invokes the connection close API. For clarity, we will assume that the application on $H_{1}$ initiates the connection close and $H_{2}$ responds to this connection close request. Thus, $H_{1}$ transmits a TCP FIN(ish) message (1) to $H_{2}$ and must wait for a response (typically an acknowledgement). Thus, the TCP connection on $H_{1}$ enters the state FIN_WAIT1 which indicates that it has initiated connection closure by transmitting the FIN message and is waiting for a response. When $H_{2}$ receives this FIN message (1), it responds with an ACK message (2) and the TCP connection on $H_{2}$ enters the CLOSE_WAIT state. This state indicates that the other side has initiated connection closure and the same has been acknowledged by, but the connection should not be closed yet because the application running on $H_{2}$ may wish to transmit more data. When $H_{1}$ receives this ACK message (2), the TCP connection on $H_{1}$ enters the state FIN_WAIT2.

Pages ( 1 of 5 ): 1 23 ... 5Next »

Leave a Comment:

Your email address will not be published. Required fields are marked *