Поддерживает ли LFTP keepalive для FTP / SFTP?

Для FTP нет механизма keep-alive, поэтому нет, как объяснено здесь: https://unix.stackexchange.com/questions/101399/how-to-keep-ftp-connection-alive

Однако вы можете попробовать использовать параметры сети для установки таймаутов вручную:

net: idle (интервал времени)

отключиться от сервера после этого простоя. > По умолчанию 3 минуты.

А также

net: timeout (временной интервал)

устанавливает тайм-аут сетевого протокола.

Что касается sftp, это зависит от настроек вашего SSH-клиента, например, вы можете настроить время ожидания и сохранить параметры openssh в / etc / ssh_config в обычном режиме (расположение файла зависит от дистрибутива). Это лучше всего объяснить в этом ответе https://unix.stackexchange.com/a/261905/10525, но вкратце вам нужно:

Host * ServerAliveInterval XX ServerAliveCountMax YY 

Очень хорошее объяснение проблемы приходит из проекта ProFTPD :

Рассмотрим, что происходит с FTP-передачей, которая занимает много времени (либо из-за передачи очень большого файла (-ов), либо из-за медленного соединения): у вас есть одно TCP-соединение для управляющего соединения и отдельное TCP-соединение для соединения для передачи данных, Все байты передаются через соединение для передачи данных, так что соединение для передачи данных, безусловно, не находится в режиме ожидания, но во время передачи данных управляющее соединение не используется! И давайте предположим, что ваши FTP-соединения проходят через какое-то устройство NAT между клиентом и сервером.

Этот NAT может быть не очень умным; он может не знать, что два разных TCP-соединения вашего FTP-сеанса связаны друг с другом; он видит только одно простое TCP-соединение и одно занятое TCP-соединение. Если это управляющее FTP-соединение слишком долго не используется, NAT может закрыть его (чтобы сохранить ценное пространство в своих таблицах состояний, доступное для TCP-соединений, которые фактически должны передавать байты). (Известно, что некоторые NAT закрывают TCP-соединения, которые простаивают только 5 минут.) FTP-сервер видит, что управляющее FTP-соединение закрыто, и прерывает передачу данных. Какой беспорядок!

Если либо FTP-сервер, либо FTP-клиент использовал контрольные сообщения TCP на управляющем соединении, то, возможно, этот NAT видел бы контрольные сигналы TCP-активности, а не закрывал простое контрольное соединение.

Projrct ProFTPD это полноценный FTP - сервер, который поддерживает TCP сообщения keepalive от самого сервера.

Со стороны клиента есть клиенты, которые можно настроить для поддержки TCP-соединения с сервером, например Filezilla.

Из Unix Stack Exchange :

Здесь нет абсолютного ответа, так как сам по себе протокол FTP не содержит такого механизма.

Однако существуют команды протокола FTP, не имеющие реального значения в данной ситуации, такие как «NOOP», «LIST» или «CWD», которые можно использовать для поддержания соединения FTP.

Так что это зависит от самого клиента, чтобы реализовать такой механизм, используя эти «бессмысленные» команды, чтобы сбросить таймеры тайм-аута на стороне сервера. Конечно, вам также может понадобиться настроить эти механизмы на стороне клиента, чтобы соответствовать значению максимального времени простоя на стороне сервера.

В качестве примера, известный Filezilla реализует такой механизм (см. Пункт меню «Правка» -> «Настройки», затем вкладка «Соединение» -> «FTP»):

Вы можете попробовать установить переменную ftp: nop-interval :

ftp: интервал nop (секунды)

задержка между командами NOOP при загрузке хвоста файла. Это полезно для FTP-серверов, которые отправляют сообщение «Передача завершена» перед сбросом данных. В таких случаях команды NOOP могут предотвратить тайм-аут соединения.

set ftp:nop-interval 10;