In one of our server, many connections are in CLOSE_WAIT. I understand that it means the other side of the connection is closed and now it is upto the server to send the FIN and change the state to LAST_ACK and close the connection.
My questions are:
What if the client send a RST when the server is in CLOSE_WAIT state?
After the client has send the FIN and if the server still wants to send more data, what would be the state of the server in this case?
What if the client send a RST when the server is in CLOSE_WAIT state?
The server would still have the socket open so the state won't change. CLOSE_WAIT means that the local TCP is waiting for the local application to close the socket.
After the client has send the FIN and if the server still wants to send more data, what would be the state of the server in this case?
The FIN means the client has stopped sending. It doesn't imply that the client can't receive. If the server tries to send, either:
It will succeed, which means the client only did shutdown for output, or
It will provoke an RST from the client, which means the client closed the socket. The RST probably won't happen on the first send but on a subsequent one, due to TCP buffering.
Related
Consider a scenario where exists one server and multiple clients. And each client creates TCP connections to interact with the server. There are three usages of TCP alive:
Server-side keepalive: The server sends TCP keepalive to make sure that the client is alive. If the client is dead, the server closes the TCP connection to the client.
Client-side keepalive: Clients sends TCP keepalive to prevent the server from closing the TCP connection to the client.
Both-side keepalive: Both server and clients send TCP keepalive as described in 1 and 2.
Which of the above usages of TCP keepalive are typical?
Actually, both server and client peers may use TCP keepalive. It is useful to ensure that the operating system will eventually release any resource associated with dead connections. Note that if a connection between two hosts get lost because of some issue with a router between them, then both hosts have to independently detect that the connection is dead, and cleanup for themselves.
Now, each host will maintain a timer on each connection indicating when it last received a packet associated with that connection. A host will send a keepalive packet when that timer goes over a certain threshold, which is defined locally (that is, hosts do not exchange information about their own keepalive configuration). So either host with the lowest keepalive time will take the initiative of sending a keepalive packet to the other host. If the packet indeed goes through, the other host (that is, the one with the higher keepalive time) will respond to that packet and reset its own timer; therefore, the host with an higher keepalive time will certainly never reach the need to send keepalive packet itself, unless the connection has indeed been lost.
Arguably, it could be said that servers are generally more aggressive on keepalive than client machines (that is, they will more often be configured with lower keepalive time), because hanging connections often have undesirable effects on server software (for example, the software may accept a limited number of concurrent connection, or the server may fork a new process instance associated with each connection).
Server-side keepalive: The server sends TCP keepalive to make sure that the client is alive. If the client is dead, the server closes the TCP connection to the client.
If the client is dead, the server gets a 'connection reset' error, after which it should close the connection.
Client-side keepalive: Clients sends TCP keepalive to prevent the server from closing the TCP connection to the client.
No. Client sends keepalive so that if the server is dead, the client will get a 'connection reset' error, after which it should close the connection.
Both-side keepalive
Both sides are capable of getting a 'connection reset' due to keepalive failure, as above.
Whuch of the above usages is typical?
Any of them, or none. If a peer is sending regularly it doesn't really need keepalive as well. It is therefore often of more use to a server than a client.
Consider such a scenario, there are client-a and server-b. server-b has TCP keepalive disabled. And server-b does not have any application logic to check whether a TCP connection is open. client-a establishes a TCP connection to server-b. There is no data transfer between client-a and server-b afterward. In such a case, will the server ever close the idle connection? Or the server will have the TCP connection stay open forever.
After reading Longest Open TCP Connection?, I guess that such a TCP connection will stay open forever. Is my guess correct?
There is no limit in the TCP connection itself. Client and server could in theory stay connected for years without exchanging any data and without any packet flow. Problems are usually caused by middleboxes like NAT router or firewalls which keep a state and expire the state after some inactivity. Any new packets sent within the connection cannot be delivered then because no associated state exists anymore in the middlebox.
when a TCP client wants to establish a tcp connection with a tcp server
it needs to send SYN and then ACK
while tcp server only sends SYN/ACK
so they are different
but , after the 3_way handshaking,
is this connection symmetric, namely, are TCP client and server in equal status
for example, after the 3-way handshake, usually the client send packet first,
can TCP server send packet first?
No, the procedure is not different at all, but instead of sending a SYN then an ACK in two different packets, the servers concatenate them by sending them via a single packet!
In the other hand, remember always that the client/server nomenclature is relative. The server is the party that remains in listening mode, while the client is the party that initiates the connection ...
After the establishment of the connection, both parties are equivalent (same status as you said: ESTABLISHED). For that reason, both can send the FIN statement to close the connection ...
After the connection is established, both ends are indeed "symmetric". Who sends first is decided by the underlying protocol and differes amongst them.
For example, HTTP starts with the GET <path> HTTP/1.0 command, while other protocols let the server give a greeting line first, and only then the client sends its request.
So in general, both ends are free to send their stuff first.
TCP Stream in a tcp dump off a remote network segment showed proper handshake and conversation up to the 8s mark followed by a 20s delay where no packets were sent from either client or server. Server send sent FIN,ACK followed shortly by client's ACK and then RST packets. Why wouldn't the client send a FIN? And is FIN,ACK the proper response for a session timeout from the server's side?
The RST means that the client had already closed the connection.
The FIN means that the server closed the connection. It's one reasonable response to a timeout.
Connect function returns after sending the last ACK(3rd segment of 3-way handshake of initiating TCP connection). What happens if this 3rd segment is lost because listen is still waiting for ACK at server but there is no one at client to send that ACK again ?
If the client sends its ACK with a data packet, and it gets lost, the client will notice that the data hasn't been ACKd by the server and resend the packet.
If the client sends its ACK in a separate packet, and it gets lost, the server will notice that the SYN/ACK hasn't been ACKd by the client and resend the packet. Client will respond by resending the ACK.
Whether the application's connect call is still blocking at that time doesn't matter, since the ACKing is done by the OS's TCP/IP implementation.