使用Apache Commons Net 3.6 FTPClient下载FTPS文件时出现截断问题

我碰到过好几例类似的FTPS文件截断问题，结合你用的commons-net 3.6和ProFTPD服务器环境，咱们来拆解可能的原因和对应的解决办法：

1. 数据连接超时或被防火墙中断 #

FTPS默认用被动模式，控制连接和数据连接是分开的。如果文件传输过程中数据连接长时间空闲，服务器或者中间的防火墙可能会主动切断连接，导致文件还没传完就停了，看起来像是截断。

• 应对措施：
  • 给数据连接设置超时时间：调用 ftpClient.setDataTimeout(300000)（比如设5分钟，根据你的文件大小调整），这样一旦数据传输停滞超过这个时间，客户端会直接抛出异常，不会默默截断文件。
  • 开启TCP保活和控制连接心跳：

    // 每60秒向控制连接发送一次心跳，防止被断开
    ftpClient.setControlKeepAliveTimeout(60);
    Socket controlSocket = ftpClient.getControlSocket();
    controlSocket.setKeepAlive(true);
    

2. Commons Net 3.6的已知传输完整性bug #

commons-net 3.6版本在处理FTPS数据传输时，存在一些边缘场景下的流读取不完整问题，尤其是当服务器响应和数据传输有微小延迟时更容易触发。

• 应对措施：
  • 优先升级到最新版的commons-net（比如3.10.0），后续版本修复了不少FTPS相关的传输bug，能从根源上减少这类问题。
  • 如果暂时没法升级，就手动做完整性校验：传输前用ftpClient.getFileSize("/OUT/somefile.xml")获取服务器上的文件大小，传输完成后对比someBAOS.size()，如果不一致就重新发起下载。

3. ProFTPD服务器的配置限制 #

有些ProFTPD的配置会限制单文件的传输大小或传输时长，大文件很容易触发限制导致截断。

• 排查方向：
  • 检查服务器上的ProFTPD配置文件，看看MaxRetrieveFileSize、TimeoutIdle这类参数有没有设置过小。
  • 查看服务器的传输日志（比如/var/log/proftpd/transfer.log），找有没有“Transfer aborted”或者类似的中断记录，能帮你定位是不是服务器端主动切断的传输。

4. 传输模式错误切换成ASCII模式 #

如果不小心把传输模式设成了ASCII，对于包含特殊字符的XML文件，可能会被错误处理（比如换行符转换），看起来像是文件被截断了。

• 应对措施：
  • 一定要在调用retrieveFile之前，明确设置二进制传输模式：

    ftpClient.setFileType(FTP.BINARY_FILE_TYPE);
    

5. ByteArrayOutputStream的缓冲区刷新问题 #

虽然这种情况不多见，但有时候ByteArrayOutputStream可能存在数据未完全写入的情况，导致看起来文件被截断。

• 应对措施：
  • 在retrieveFile执行完成后，调用someBAOS.flush()，再检查字节流的大小。另外可以先把文件写到本地磁盘（用FileOutputStream），再读取验证，排除ByteArrayOutputStream的潜在问题。

内容的提问来源于stack exchange，提问作者maaartinus