M9000+FTP

您观察到的中断和 TCP-EST 老化时间有直接关系，问题出在 FTP 协议的特殊性上。简单来说，TCP-EST 老化时间直接导致了您遇到的 FTP 传输中断。

 为什么是 TCP-EST 的问题？

核心原因在于 FTP 协议的数据传输和控制通道分离，以及防火墙对这两种通道的不同处理逻辑。

1. FTP 的“双通道”模式

   • 控制通道：始终连接到服务器的 TCP 21 号端口，用于发送指令，在文件传输期间大部分时间处于“空闲”状态。

   • 数据通道：用于实际的文件内容传输，连接和端口（在被动模式下为随机高端口）是动态协商的。

2. 防火墙处理流程的差异

   • 防火墙会为控制通道建立一个会话，老化时间遵循 FTP 应用层协议的老化时间，默认为 3600 秒。

   • 文件传输开始时，防火墙会创建对应的数据通道会话。但防火墙将其视为一个普通的 TCP 连接，其老化时间遵循 TCP-EST (TCP Established) 状态的老化时间，默认也是 3600 秒。

3. 中断是如何发生的
   当传输一个耗时超过1小时的大文件时：

   • 第1小时：数据通道会话建立，防火墙将其老化计时器设为 3600 秒，并随着时间流逝不断倒计时。

   • 当传输进行到第59分钟时，会话已接近老化。

   • 在第60分钟的临界点，会话因超时被防火墙强制删除，导致传输中断。这完美解释了您观察到的“每1小时就断一次”的现象。

直接结论

• FTP / SFTP 长连接、空闲也不断开的那种
• 防火墙会话表项默认超时就是你设的 TCP-EST: 3600 秒 = 1 小时
• 会话超时 → 防火墙直接删除会话
• 结果：连接被强制切断，表现就是每小时准时断开一次

为什么 FTP/SFTP 特别容易中招？

1. FTP 有控制连接 + 数据连接两条 TCP
2. 传大文件时，控制连接可能长时间不发任何报文
3. 防火墙认为这条连接 “空闲”
4. 到 3600s 直接删会话 → 控制断 → 数据也跟着断

怎么验证是不是它导致的？

• 这条 FTP/SFTP 会话的剩余老化时间，快到 0 时就会断开

解决方法（H3C M9000 适用）

方法 1：直接延长 TCP 老化时间（最简单）

方法 2：只对 FTP/SFTP 加长老化（更规范）

方法 3：开启 FTP ALG（必须开）

最终一句话