Frequently Asked Questions
Question: When should I use application-level keepalives like FTP or SSH2 keepalives instead of TCP keepalives? Or can I use them all
at the same time?
Answer: There is no issue with using the different
types of keepalives at the same time; remember that each type of keepalive
functions at a different protocol layer.
That said, if you have to choose, I would recommend using the application-level
keepalive feature when you can, as opposed to TCP keepalives. Why? First,
you probably have more control over when the application-level keepalive
feature is used than if you used TCP keepalives (e.g. you can use the
application-level keepalive check more frequently than the TCP keepalive
feature would detect a dead connection).
Second, TCP keepalives may not cause a NAT to keep the TCP connection
on each side open, but an application-level keepalive should do so, since
the application-level keepalive data must traverse both connections:
<------------ SSH2 REQUEST ----------->
-------------- FTP NOOP -------------->
client <---------------> NAT <---------------> server
<-- TCP probe --> <-- TCP probe -->
Question: Why should I use SocketOptions
to
configure proftpd
's TCP keepalive settings, as opposed to
changing some of the sysctls on my machine that apply to TCP KeepAlives?
Answer: Using the SocketOptions
directive
means that your TCP keepalive tunings will only affect the FTP/SFTP connections
to proftpd
, instead of applying to all TCP connections to
your machine. FTP/SFTP sessions, being long-lived, probably have different
keepalive timing needs than from other TCP connections, so it is best to tune
their settings separately, without impacting all connections to that machine.
Question: If TCP keepalives are so useful, why not
tune them to be quite short? Why does RFC 1122 recommend a default of
two hours before checking if the peer is still there?
Answer: There are a couple of reasons why you might
not want to tune your TCP keepalive settings to be shorter.
First, keep in mind that TCP was designed to keep the TCP level connection
"alive" even though various parts of the underlying hardware, such as
routers, firewalls, etc might crash and be rebooted in the middle of things.
This is why TCP retransmits lost packets, routes around unresponsive
hops, etc. If, then, your TCP keepalive settings are aggressively short,
your TCP connection may be shut down (due to not responding to TCP keepalive
probes in time) because of a crashed network component. The recommended
default of two hours allows for such network route changes without losing
the TCP connection.
Second, every TCP keepalive probe counts as more data transferred over your
network link. Some links may have exorbitantly high rates for transferred
bytes (think satellite links), so on such links, keeping the number of bytes
transferred down amounts to cost savings. Tuning TCP keepalive to use shorter
times on such links means more data transferred, thus higher costs.
On other links, where data transfer rates are cheap, the additional bytes
transferred due to shorter TCP keepalive settings may be negligible.
Last, many people argue that use of TCP keepalives may consume unnecessary
bandwidth. The question becomes "If no one is using the connection, who
cares if the connection is still good?" (To be fair, this argument makes more
sense when the connected peers are not separated by proxies, gateways,
and NATs.)
© Copyright 2017 The ProFTPD Project
All Rights Reserved