Skip to content

Count connections by TCP state

homepage-banner

Commands

netstat

show TIME_WAIT/CLOSE_WAIT/ESTABLISHED/LISTEN state of TCP conntection.

netstat -tan |grep ^tcp |awk '{++a[$6]} END{for (i in a) print i, a[i]}'

ss

ss -s

Total: 156
TCP:   6 (estab 0, closed 0, orphaned 0, timewait 0)

Transport Total     IP        IPv6
RAW       0         0         0
UDP       7         3         4
TCP       6         3         3
INET      13        6         7
FRAG      0         0         0

TCP State

  • CLOSED: Initial state, indicating no connections.
  • LISTEN: A socket on the server side is listening for connection requests from a remote TCP port.
  • SYN_SENT: After sending a connection request, waiting for confirmation. When the client socket performs a connect connection, it will first send a SYN packet, then enter the SYN_SENT state, and then wait for the server side to send the second packet of the three-way handshake.
  • SYN_RECEIVED: After receiving a connection request, sending back confirmation information and a peer connection request, then waiting for confirmation information. It is usually an intermediate state in the process of establishing a TCP connection, indicating that the server-side socket has received a SYN packet from the client and responded to it.
  • ESTABLISHED: Indicates that the connection has been established and data transmission can occur.
  • FIN_WAIT_1: The party actively closing the connection waits for the other party to return an ACK packet. If the socket actively closes the connection in the ESTABLISHED state and sends a FIN packet to the other party (indicating that there is no more data to be sent), it enters the FIN_WAIT_1 state, waits for the other party to return an ACK packet, and can still read data but cannot send data. Normally, regardless of the state of the other party, an ACK packet should be returned immediately, so the FIN_WAIT_1 state is generally rarely seen.
  • FIN_WAIT_2: After the party actively closing the connection receives the ACK packet returned by the other party, it waits for the other party to send a FIN packet. After the socket in the FIN_WAIT_1 state receives the ACK packet returned by the other party, it enters the FIN_WAIT_2 state. Since the socket in the FIN_WAIT_2 state needs to wait for the FIN packet sent by the other party, it is often seen. If a packet with both FIN and ACK is received from the other party while in the FIN_WAIT_1 state, it directly enters the TIME_WAIT state without going through the FIN_WAIT_2 state.
  • TIME_WAIT: After the party actively closing the connection receives the FIN packet sent by the other party and returns an ACK packet (indicating that the other party also has no more data to send, and can no longer read or send data), it then waits for a long enough time (2MSL) to ensure that the other party receives the ACK packet (considering the possibility of losing ACK packets and the impact of lost duplicate data packets), and finally returns to the CLOSED state, releasing network resources.
  • CLOSE_WAIT: Indicates that the party passively closing the connection is waiting for the connection to be closed. After receiving the FIN packet sent by the other party (indicating that the other party has no more data to send), the corresponding ACK packet is returned, and then it enters the CLOSE_WAIT state. In this state, if the local party still has unsent data, it can continue to send it to the other party, but cannot read data until the data is sent.
  • LAST_ACK: After the party passively closing the connection completes sending data in the CLOSE_WAIT state, it can send a FIN packet to the other party (indicating that the local party has no more data to send), and then wait for the other party to return an ACK packet. After receiving the ACK packet, it returns to the CLOSED state and releases network resources.
  • CLOSING: A relatively rare exceptional state. Normally, after sending a FIN packet, an ACK packet should be received (or received at the same time) from the other party before receiving the FIN packet from the other party. The CLOSING state indicates that after sending the FIN packet, the ACK packet from the other party was not received, but the FIN packet from the other party was received. There are two situations that may cause this state: First, if both parties almost simultaneously close the connection, it is possible for both parties to send FIN packets at the same time; Second, if the ACK packet is lost and the FIN packet from the other party is sent quickly, the FIN may arrive before the ACK.

TCP State Transition

tcp-stat-1.png

tcp-stat-2.png

TCP Connection Termination

  1. Client sends a FIN packet to the Server, indicating that the Client is actively closing the connection. Then, it enters the FIN_WAIT_1 state, waiting for the Server to return an ACK packet. After this, the Client cannot send data to the Server anymore, but can still read data.
  2. Upon receiving the FIN packet, the Server sends an ACK packet to the Client, and then enters the CLOSE_WAIT state. After this, the Server cannot read data anymore, but can continue sending data to the Client. The Client enters the FIN_WAIT_2 state after receiving the ACK packet from the Server, waiting for the Server to send a FIN packet.
  3. After completing the data transmission, the Server sends a FIN packet to the Client, and then enters the LAST_ACK state, waiting for the Client to return an ACK packet. After this, the Server cannot read data or send data anymore.
  4. Upon receiving the FIN packet, the Client sends an ACK packet to the Server, and then enters the TIME_WAIT state. It waits for a sufficiently long time (2MSL) to ensure that the Server receives the ACK packet, and finally returns to the CLOSED state, releasing the network resources. The Server returns to the CLOSED state upon receiving the ACK packet from the Client, releasing the network resources.
  • Client Side

CLOSED -> SYN_SENT -> ESTABLISHED -> FIN_WAIT_1 -> FIN_WAIT_2 -> TIME_WAIT -> CLOSED

  • Server Side

CLOSED -> LISTEN -> SYN_RECEIVED -> ESTABLISHED -> CLOSE_WAIT -> LAST_ACK -> CLOSED

TIME_WAIT

After a detailed understanding of the state and closing method of TCP connection, we will find that the TIME_WAIT state is a troublesome existence! After the active-closing side sends the last ACK packet, it will enter the TIME_WAIT state regardless of whether the other party has received it or not. It waits for 2MSL (Maximum Segment Lifetime), which is the maximum time a packet can survive on the Internet. If it exceeds this time, the packet will disappear in the network. The operating system usually sets 2MSL to 4 minutes, with a minimum of 30 seconds, so the TIME_WAIT state is generally maintained for 30 seconds to 4 minutes. This is essential for the TCP/IP protocol and is designed by TCP/IP designers, so it cannot be solved. The existence of the TIME_WAIT state is mainly due to two reasons:

  1. To reliably terminate TCP full-duplex connections. When closing a TCP connection, the last ACK packet is sent by the active-closing side. If this ACK packet is lost, the passive-closing side will resend the FIN packet. Therefore, the active side must maintain state information to allow it to resend this ACK packet. If this state information is not maintained, the active side will return to the CLOSED state and respond to the FIN packet retransmitted by the passive side with a RST packet, which the passive-closing side will interpret as an error (in Java, it throws a SocketException of “connection reset”). Therefore, to achieve a normal termination of TCP full-duplex connections, it is necessary to be able to handle the situation where any packet is lost in the four-way handshake protocol, and the active-closing side must maintain state information and enter the TIME_WAIT state.
  2. To ensure that lost duplicate packets disappear in the network and prevent packets from the previous connection from reappearing and affecting the new connection. TCP packets may get lost due to router anomalies. During the time when the packets are lost, the sender may resend the packet due to timeout. When the lost packets are finally delivered after the router recovers, they are called Lost Duplicate packets. After closing a TCP connection, if a new TCP connection is established immediately using the same IP address and port, it is possible for the lost duplicate packets from the previous connection to reappear, affecting the newly established connection. To avoid this situation, the TCP protocol does not allow a new connection to be initiated using the IP and port of a connection in the TIME_WAIT state. Only after a time of 2MSL, which ensures that all lost duplicate packets from the previous connection have disappeared from the network, can a new connection be safely established.

Reference

  • http://www.cnblogs.com/fczjuever/archive/2013/04/05/3000680.html
Leave a message