TCP State Transitions
As noted earlier, each of the two machines communicating via a TCP connection maintains information about the state of the connection from the perspective of that machine. The rules that describe how and when these states are updated (independently by the two machines) is best explained as a Finite State Machine (FSM) , shown in Figure 1. Depending on which machine is initiating a new connection (client) vs. listening for new connections (server), sending or receiving data over a connection (either the client or the server), or initiating the closure of a connection (either the client or the server), the two machines may follow different transitions (represented as arrows) in the FSM to update the state of the connection. The states of the client while initiating the connection (known as active open) are shown in blue, whereas the server states while waiting for a new connection to be opened (known as passive open) are shown in orange. Similarly, the active close states (for the side that initiates connection closure) are shown in red and the passive close states (for the other side) are shown in magenta. The CLOSED state (duplicated at the bottom to avoid cluttering the diagram) is shown in black, indicating no TCP connection state. While data is being transmitted, both machines will maintain the TCP connection in the ESTABLISHED state shown in green.
Figure 1: TCP State transition
Each machine maintains the TCP connection in its present state. When an event occurs at a machine, it transitions to an appropriate state as indicated by arrows. (In some cases, the next state may be the same state and this is indicated by a loop in the FSM). Each arrow is accompanied by two lines of text. The top line indicates the event that must occur for this transition to be triggered, and the bottom line indicates the action that this machine will take in response to the triggering event (in addition to following the arrow to the next state). This action could involve sending a message to the machine at the other end of the TCP connection, and such messages allow the two machines to maintain a coherent view of the TCP connection. For example, when a client application initiates a connection with the server by creating a network socket and invoking connect() (socket call to connect to server), this triggers an “appl: active open” event on the client machine. In response to this event, the state of this connection on the client machine moves from CLOSED to SYN_SENT, and the client machine additionally takes the action “send: SYN” (see the Figure 1) that sends a message to the server
A machine can run many processes concurrently, and each process can have many TCP connections. The state of every TCP connection in a machine can be viewed using the network utility command netstat  , as shown in Figure 2. (Note that netstat never shows TCP connections in the CLOSED state, since no system resources are associated with such TCP connections.) Each TCP connection is identified by a tuple <source IP, source port, destination IP, destination port>. When netstat is run, TCP connections will typically be in one of the three stable states LISTEN, ESTABLISHED, or TIME_WAIT (Figure 2). Under normal TCP communications, the other seven states shown by netstat are transient i.e. the machine rapidly updates TCP connection states to one of the stable states. Hence, if we observe a TCP connection remaining in one of these transient states (for more than a second), it indicates the occurrence of some abnormality, which should be carefully investigated and resolved (e.g. a network or application issue, or an improperly configured firewall that is blocking incoming or outgoing TCP messages that it should not).
Figure 2: An example of states of all TCP connections
We will now explore some of these abnormal conditions that enable TCP connections to exist in one of the transient states for long durations during Phase 1 and Phase 3. This exploration is supplemented with experiential learning exercises that will enable the reader to observe these states. A typical setup (consisting of two systems) for conducting such experiments is shown in Figure 3.
Figure 3: Basic setup of conducting TCP learning exercises.