选型只看三件事
要不要加密、能不能穿过现有防火墙、使用场景是服务器之间还是设备与电脑之间。把这三个问题问清楚，选型基本就没有悬念了，剩下的都是细节配置问题。
为什么优先选加密方案
对外能选基于 SSH 的方案，就别用传统明文协议：少一套明文协议和一对额外的数据端口，运维面直接减半，防火墙规则也简单得多。
基本信息
| 传统明文协议 | 控制与数据端口分离，配置复杂 |
|---|---|
| 在其上加密的方案 | 端口组合更复杂，两端配置必须匹配 |
| 基于 SSH 的方案 | 单端口、加密、适合脚本化与自动化 |
| 简单文件传输协议 | 无连接、无加密，仅适合设备刷机与网络启动 |
典型使用场景
- 新旧系统对接时的传输方式选择
- 网络设备刷机与网络启动场景
- 备份与发布流程的传输方式选择
- 安全评审中对明文协议的整改
一条命令识别协议
一条命令识别协议
nc -zv host 22 # 基于 SSH 的家族：文件传输与增量同步
nc -zv host 21 # 传统文件传输协议
nc -zvu host 69 # 简单文件传输协议，注意它是无连接的协议对比
| 协议 | 端口 | 加密 | 典型场景 |
|---|---|---|---|
| 传统明文协议 | 控制端口加数据端口 | 无 | 内网老系统、匿名下载站 |
| 叠加加密的方案 | 控制端口或专用端口加数据端口 | 有 | 合规要求加密的老场景 |
| 基于 SSH 的文件传输 | 单端口 | 有 | 服务器运维、脚本化传输 |
| 单次拷贝工具 | 单端口 | 有 | 临时拷贝单个文件 |
| 增量同步工具 | 单端口 | 有 | 增量同步与备份 |
| 简单文件传输协议 | 无连接端口 | 无 | 设备刷机、网络启动 |
对外能选加密方案就别用明文协议：少一套明文协议与额外的数据端口，运维面直接减半。
别把基于 SSH 的方案说成「安全的传统协议」：它是独立协议，客户端命令与服务端排障方式完全不同。
迁移时按用途分批切换，比一次性全量替换风险低：先切脚本化场景，再处理必须保留老协议的特殊设备。