记一次commons-net FTP上传下载卡死

在利用apache的commons-net包，做FTP上传下载时，碰到了一个问题：在默认配置下，传输大文件会卡死。
commons-net的maven依赖：

            <dependency>
                <groupId>commons-net</groupId>
                <artifactId>commons-net</artifactId>
                <version>3.6</version>
            </dependency>

在翻阅了官方文档后，发现了一段描述，原文如下：

Control channel keep-alive feature:

Please note: this does not apply to the methods where the user is responsible for writing or reading the data stream, i.e. retrieveFileStream(String) , storeFileStream(String) and the other xxxFileStream methods

During file transfers, the data connection is busy, but the control connection is idle. FTP servers know that the control connection is in use, so won't close it through lack of activity, but it's a lot harder for network routers to know that the control and data connections are associated with each other. Some routers may treat the control connection as idle, and disconnect it if the transfer over the data connection takes longer than the allowable idle time for the router.
One solution to this is to send a safe command (i.e. NOOP) over the control connection to reset the router's idle timer. This is enabled as follows:

ftpClient.setControlKeepAliveTimeout(300); // set timeout to 5 minutes

This will cause the file upload/download methods to send a NOOP approximately every 5 minutes. The following public methods support this:

• retrieveFile(String, OutputStream)
• appendFile(String, InputStream)
• storeFile(String, InputStream)
• storeUniqueFile(InputStream)
• storeUniqueFileStream(String)

This feature does not apply to the methods where the user is responsible for writing or reading the data stream, i.e. retrieveFileStream(String) , storeFileStream(String) and the other xxxFileStream methods. In such cases, the user is responsible for keeping the control connection alive if necessary.

The implementation currently uses a CopyStreamListener which is passed to the Util.copyStream(InputStream, OutputStream, int, long, CopyStreamListener, boolean) method, so the timing is partially dependent on how long each block transfer takes.

如上描述，commons-net有一个重要特性，Control channel keep-alive特性。在大文件传输时，由于网络网速比较低，传输较慢，在传输期间，data connection是在活动的，但是 control connection是空闲的。对于FTP服务器来说，它知道网络是有活动的。但是对于一些路由器来说，它们将data connection和control connection视为相互关联的，发现control connection空闲就将网络关闭。
解决方法是发一个no-op command，类似心跳请求来维持网络，防止路由器将网络切断。但是对于xxFileStream的方法是不适用的，在一开始编码时正好使用该方法，导致卡死的情况，可以改用retrieveFile和storeFile方法替换。另外根据业务情况可以添加一些超时配置：

# 默认超时时间（ms）
defaultTimeout: 3000
# 连接超时时间 (ms)
connectTimeout: 3000
# 数据传输超时时间（ms）
dataTimeout: 3000
# 每隔xx秒，像FTP服务器发送一次心跳
controlKeepAliveTimeout: 60

总结：一开始使用commons-net包，很容易碰到的一个坑，此处记一下，希望能帮助到大家，谢谢。