So, a socket could be in a TIME_WAIT state for as long as 4 minutes. The time is specified in RFC793 as twice the Maximum Segment Lifetime (MSL). NOTE: It is normal to have a socket in the TIME_WAIT state for a long period of time. This could be the result of one instance (among all threads or processes) of the socket not being closed. This could indicate that the client properly closed the connection (FIN has been sent), but the server still has its socket open. LAST_ACK Server is in this state when it sends its own FIN.ĬLOSED Server received ACK from client and connection is closed.Īs an example, consider the following scenario:Ī socket application has been terminated, but Netstat reports the socket in a CLOSE_WAIT state. Server just received first FIN from a client.įIN_WAIT_2 Client just received acknowledgment of its first FIN from the server. TIMED_WAIT Client enters this state after active close.ĬLOSE_WAIT Indicates passive close. LISTEN Server is ready to accept connection. SYN_RECEIVED Server just received SYN from the client.ĮSTABLISHED Client received server's SYN and session is established. Socket applications can call shutdown with the second argument set to 1 to enter this state. Upon receiving this ACK, the server closes the connection.Ī half-closed connection can be used to terminate sending data while sill receiving data. The client sends an ACK (which is server's FIN sequence + 1). The server sends an ACK (which is the clients FIN sequence + 1) Upon receiving this FIN, the server enters a passive close state. The client no longer sends data, but is still able to receive data from the server. The Client sends an ACK (which consists of the server's ISN + 1).Ĭonnection Tear-down (modified three way handshake). The server sends back its own SYN and ACK (which consists of the client's ISN + 1). The client sends a SYN message which contains the server's port and the client's Initial Sequence Number (ISN) to the server (active open). Note that this notation does not reflect Client/Server relationships as an architectural principal. In this context the "client" is the peer requesting a connection and the "server" is the peer accepting a connection. Following is a brief explanation of this handshake.
0 kommentar(er)
