TCP status (selected from Windows Network Programming Technology)

As a wi n s o c k programmer, there is usually no need to understand the actual t c p status. However, knowing the status of t c p can better understand how Winsock API calls affect changes in the Grass-roots protocol. In addition, many programmers encounter a common problem when they close the socket. The t c p state around the socket is currently the most interesting issue.

For each socket, its initial state is C l o s e d. If the client initializes a connection, it will send an s y n packet to the server, and set the client socket status to s y n _ s e n t. After receiving the s y n package, the server sends out a "s y n-a c k" package. As a client, you need to use a c k package to respond to it. In this case, the client's socket will change to the e s ta B l I s h e d state. If the server never sends the "s y n-a c k" packet, the client times out and returns the C l o s e d status.
If a server socket is bound to the same local interface and port and listened on it, the socket state is L I s t e n. When the client tries to connect to it, the server will receive an s y n package and respond with a s y n-a c k package. The status of the server socket becomes s y n _ r c v d. Finally, the client sends out a c k packet so that the server socket status changes to e s ta B l I s h e d.
Once the application is in the e s ta B l I s h e d state, you can disable it in two ways. If the application closes, it is called "active socket close"; otherwise, socket close is passive. Figure 7-2 explains the two close methods. If it is disabled, the application will issue an f I n package. When the application calls C l o s e s o c k e t or s h u t d o W n (treats s d _ s e n d as the second parameter ), sends an f I n packet to the other party, and the socket status changes to f I n _ wa I T _ 1. Normally, the communication peer will respond to a c k packet, and the status of our socket will change to f I n _ wa I T _ 2. If the other party closes the connection, it will issue an f I n package, and our machine will respond to a C K package, set the status of your socket to t I m e _ wa I t.

T I m e _ wa I t status is also called 2 M S l wait status. Among them, m s l represents the "maximum lifetime of a segment" (maximum segment lifetime), indicating how long a packet can exist on the network before it is discarded. Each I p package contains a "survival time" (T L) field. If it is decreased to 0, the package will be discarded. When a packet passes through each vro on the network, the t l value is reduced by 1 and then transmitted. Once the application enters the t I m e _ wa I t state, it will continue for twice the M S L time. In this way, t c p can re-Send the last a c k, that is, f I n will be re-transmitted. The socket enters the C l o s e d State after the wait state for two times the Ms L time ends.
When active shutdown is taken, two paths will enter the t I m e _ wa I t status. In our previous discussions, only one Party sends an f I n and receives a A C K response. However, the other party can still send data freely until it is disabled. Therefore, two paths are required to play a role. In a path (that is, synchronous shutdown), a computer and its communication peer both require shutdown; the computer sends an FI n packet to the peer, and receives an f I n packet from it. Then, the computer sends an a c k packet, responds to the f I n packet of the other party, and sets its socket to the C l o s I n g state. After the computer receives the last a c k package from the other party, its socket status changes to t I m e _ wa I t.
When the socket is active, another path is actually a variant of synchronous shutdown: the socket is changed from f I n _ wa I t _ 1 to t I m e _ wa I t. This happens if the application sends an FI n packet, but almost simultaneously receives an fi n-a c k packet from the other party. In this case, the other party will confirm to receive the f I n package of the application and send its own f I n package. For this package, the application uses a c k package to respond.
T I m e _ wa I t state is mainly used when the T C P connection is in the 2 M S l wait state, a pair of sockets used to establish the connection cannot be rejected. The socket consists of the local I p port and the remote I p port. For some t c p implementation schemes, they are not allowed to reject any port numbers in socket pairs in the T I m e _ wa I t state. This problem does not exist in Microsoft's solutions. However, if you try to establish a connection through a socket that is already in the T I m e _ wa I t status, it will fail, and return w s a e a d r I n u s e error. To solve this problem (except for the socket pair waiting to use that local port to exit the t I m e _ wa I t status ), one way is to use socket option s o _ r e f u s e a d r. We will discuss this option in detail in Chapter 9th.

When the application is passively disabled, the application receives an f I n package from the other party and responds with an A C K package. In this case, the socket of the application changes to the c l o s e _ wa I t state. Because the other party has closed its socket, it cannot send data any more. But the application is different. It can send data until the socket of the other party is closed. To close the connection of the other party, the application needs to issue its own f I n, so that the socket state of the application changes to L A S T _ A C K. After an application receives a c k packet from the other party, its socket will be switched to the C l o s e d state.