After restarting my server side application, my client side OS doesn't detect dead tcp connections. The zombie connections will stay in established state, and never be closed by OS. Is anyone hava any idea about this?
This is the server side connections on port 9888:
This is the client side connections to the server:
Some information of my OS:
You might want to use TCP keep alive mechanism to detect the dead peers. As rightly mentioned in the comments you need to call set following socket options using setsockopt function,
SO_KEEPALIVE - To enable/disable the TCP keep alive mechanism
TCP_KEEPIDLE - IDLE time (in seconds) after which TCP starts sending keepalive probes
TCP_KEEPCNT - Maximum number of keepalive probes TCP should send before dropping the connection
TCP_KEEPINTVL - The time (in seconds) between individual keepalive probes
So for example if you set ideal time = 60 seconds, cnt = 5 and interval = 2 seconds, the system will drop the connection after 70 seconds of inactivity.
More details are available at following website
http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html
Hope this helps.
Related
I'm having hard time understanding keepAlive option passed to nodeJS mongo driver.
this docs says keepAlive takes boolean value and keepAliveInitialDelay is used to wait before initiating keepAlive on the TCP socket
this docs says keepAlive takes an integer value and reads The number of milliseconds to wait before initiating keepAlive on the TCP socket.
I tried using both and failed to find any difference also I tried with both true and false values for keepAlive and tried 0,1 and 30000(default) for keepAliveInitialDelay.
what is the correct way to use keepAlive?
what does "initiating" keepAlive do? or what is the use of keepAlive option?
why did it not make any difference even after setting keepAlive to false or settings it to 0 or 1?
docs here state that keepAlive affects artefacts -> Server, ReplicaSet, Mongos. so to which option does it map to at server side docs?
I'm using mongo driver V3.3 and mongo atlas V4.2
Thanks in advance.
The TCP keep-alive mechanism is described here. It is used for:
Checking for dead peers
Preventing disconnection due to network inactivity
When keep-alive is enabled, the driver instructs the network stack to periodically send ping packets to the server on the established connection. If the server's network stack does not respond, the connection is flagged as failed.
Without keep-alive, the driver wouldn't find out about some of the network issues until after the application issued a query (and was waiting for it to be executed).
The driver sets the network stack options here using setKeepAlive.
To see whether keep-alives are being sent, you need to use a tool like tcpdump to inspect traffic on the connections established by the driver.
The server uses the system-wide keep-alive value if it is under 300 seconds, otherwise sets keep-alive interval to 300 seconds.
I have a requirement to enable TCP keepalive on any connections and now I am struggling with the results from our test case. I think this is because I do not really understand when the first keepalive probe is sent. I read the following in the documentation for tcp_keepalive_time on Linux:
the interval between the last data packet sent (simple ACKs are not considered data) and the first keepalive probe; after the
connection is marked to need keepalive, this counter is not used any
further
Some other sources state that this is the time a connection is idle, but they do not further define what this means. I also looked into Stevens to find a more formal definition of this, because I am wondering what "the last data packet sent" actually means when considering retransmissions.
In my test case, I have a connection where data is only sent from a server to a client at rather high rates. To test keepalive, we unplugged the cable on the client's NIC. I can now see that the network stack tries to send the data and enters the retransmission state, but no keep alive probe is sent. Is it correct that keep alive probes are not sent during retransmission?
I have a connection where data is only sent from a server to a client
at rather high rates.
Then you'll never see keepalives. Keepalives are sent when there is "silence on the wire". RFC1122 has some explanation re keepalives.
A "keep-alive" mechanism periodically probes the other end of a
connection when the connection is otherwise idle, even when there is
no data to be sent
Back to your question:
Some other sources state that this is the time a connection is idle,
but they do not further define what this means.
This is how long TCP will wait before poking the peer "hoy! still alive?".
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
In other words, you've been using a TCP connection and it has been great. However, for the past 2 hours there hasn't been anything to send. Is it reasonable to assume the connection is still alive? Is it reasonable to assume all the middleboxes in the middle still have state about your connection? Opinions vary and keepalives aren't part of RFC793.
The TCP specification does not include a keep-alive mechanism it
could: (1) cause perfectly good connections to break during transient
Internet failures; (2) consume unnecessary bandwidth ("if no one is
using the connection, who cares if it is still good?")
To test keepalive, we unplugged the cable on the client's NIC.
This isn't testing keepalive. This is testing your TCPs retransmit strategy, i.e. how many times and how often TCP will try to get your message across. On a Linux box this (likely) ends up testing net.ipv4.tcp_retries2:
How may times to retry before killing alive TCP connection. RFC 1122
says that the limit should be longer than 100 sec. It is too small
number. Default value 15 corresponds to 13-30min depending on RTO.
But RFC5482 - TCP User Timeout Option provides more ways to influence it.
The TCP user timeout controls how long transmitted data may remain
unacknowledged before a connection is forcefully closed.
Back to the question:
Is it correct that keep alive probes are not sent during retransmission
It makes sense: TCP is already trying to elicit a response from the other peer, an empty keepalive would be superfluous.
Linux-specific (2.4+) options to influence keepalive
TCP_KEEPCNT The maximum number of keepalive probes TCP should send before dropping the connection.
TCP_KEEPIDLE The time (in seconds) the connection needs to remain idle before TCP starts sending keepalive probes, if the socket option SO_KEEPALIVE has been set on this socket
TCP_KEEPINTVL The time (in seconds) between individual keepalive probes
Linux-specific (2.6.37+) option to influence TCP User Timeout
TCP_USER_TIMEOUT The maximum amount of time in
milliseconds that transmitted data may remain unacknowledged before
TCP will forcibly close connection.
So for example your application could use this option to determine how long the connection survives when there is no connectivity (similar to your NIC-unplugging example). E.g. if you have reason to believe the client will come back (perhaps they closed the laptop lid? spotty wireless access?) you can specify a timeout of 12 hours and when they do come back the connection will still function.
Machine - linux, 3.10.19 kernel
This is in a large distributed system, there are several servers and clients (on same as well as different nodes/machines) having TCP connections with each other.
Test case:
The client program node/machine is switched off (on purpose, test case) and the only way for server to know about his disconnection is via keepalive timer (idle time=40 sec, 4 probes, probe time=10 sec).
Good case:
This works fine in most of the cases, the server gets to know that the client has gone down in [40,70] sec.
Bad case:
But I am hitting another unique situation where while keepalive timer is running, the server tries sending some data to the client, and this in turn starts the TCP retransmission timer which overrides/kills the keepalive timer. It takes ~15 min for the retransmission timer to detect that the other end is not there anymore.
15 min is a lot of time for server to realize this. I am looking for ways how others handle such a situation. Do I need to tweak my retransmission timer values?
Thanks!
There is a completely separate configuration for retransmission timeouts.
From Linux's tcp.7 man page:
tcp_retries2 (integer; default: 15; since Linux 2.2)
The maximum number of times a TCP packet is retransmitted in
established state before giving up. The default value is 15, which
corresponds to a duration of approximately between 13 to 30 minutes,
depending on the retransmission timeout. The RFC 1122 specified
minimum limit of 100 seconds is typically deemed too short.
This is likely the value you'll want to adjust to change how long it takes to detect if your connection has vanished.
I have the same issue with a linux kernel release 4.3.0-1-amd64:
I used a server and a client, connected to the same switch.
TCP keep-alive mecanism works correctly for client and server in the following cases:
When no message is sent between the cable disconnection and the socket disconnection (by the tcp keep-alive mecanism).
When the cable is disconnected between the client/server and the switch (which sets the link state to down) even if the client/server application tries to send a message.
When the wire is unpluged on the other side of the switch, TCP Keep-Alive frames are transmitted until an applicative message is sent. Then, TCP Retransmission frames are sent and TCP keep-alive frames stop being sent, which prevents the socket to be closed.
I'm using Nginx and it sounds that TCP socket are not properly released by Nginx. Clients which connects to my Nginx are using a proxy and so far, the same 4-tuplets ip source, port source, ip dest, port dest could be re-used in a very short period (less than 1 minute). When it occurs, Nginx seems to be lost.
Here is what I can see in a tcpdump trace :
- FIN,ACK initiated by Nginx to close the session
- ACK from the client
- FIN,ACK from the client
- ACK for the server
If the client tries to reconnect very rapidly (less than 1 minute) with the same 4-tuplets, it fails. The client sends SYN TCP packet but Nginx replies with an ACK containing an unknown sequence (the sequence number if very high and does not make any sense with the previous TCP session).
If the same 4-tuplet is re-used after more than 1 minute, there is no problem.
Thank in advance to anyone who could have an idea to solve this problem
Aurélien
I am not familiar with Nginx, but in general, TCP sockets can remain in a TIME_WAIT state after being closed for up to several minutes in order to catch stray out-of-order packets. The 4-tuple cannot be reused until the TIME_WAIT state expires.
See:
What are the CLOSE_WAIT and TIME_WAIT states?
The TIME-WAIT state in TCP and Its Effect on Busy Servers
Say I have an websocket that may receive an event at any time, but is mostly idle, how much bandwidth will be consumed after the initial connection in order to keep it alive?
For what it's worth, the server is NodeJS using ws, and the client is using QtWebSockets.
Thanks!
Once established (meaning the three-way handshake completes), a raw TCP connection uses zero bandwidth unless:
You send or receive data
TCP keepalives are explicitly enabled
A server or client can enable TCP keepalives. A keepalive is a zero-length packet sent with the ACK flag set, and is only 54 bytes sent on the wire plus another 54 for the response. By default, TCP keepalives are sent every two hours. In other words, completely negligible.
WebSockets also have their own keepalive mechanism (to deal with proxies). The server or the client may send a PING frame, and the other end MUST respond with a PONG frame. While there is no browser-side JS API to send PINGs, a node server may send them and a compliant browser will automatically respond. (QtWebSockets does have an API to send PINGs.) This does not happen by default; you must do it manually. WebSocket PING and PONG frames are at least 7 bytes and at most 131 bytes each (plus 54 bytes of TCP/IP overhead). Thus a single PING/PONG costs between 122 and 370 bytes.
ws does not do any keepalives automatically, nor does QtWebSockets. So to answer your question, a default configuration does use zero bandwidth to maintain the TCP connection.
However...
Keepalives are important because intermediate devices (ie NAT routers) will drop inactive TCP connections. Depending on the networks between your server and your clients, this means that if you don't have any keepalives, your clients will lose their connections (possibly without knowing it, which is bad), and will have to re-eastablish the WebSocket session. This will likely be far more expensive in terms of bandwidth than enabling sane keepalives.
A PING/PONG every 5 minutes costs 1.5 - 4.4 kB per hour (per client).
Note: socket.io has its own keepalive mechanism (separate from WebSockets') that is enabled by default. The sio keepalive is managed by the sio library and happens over the WebSocket data channel (as opposed to WebSocket PING/PONG, which are control frames). The socket.io server sends an 8 byte (+overhead) keepalive message every 30 seconds, which amounts to about 15 kB per hour.