端口与体系
608 对应 IANA 登记的 sift-uft（Sender-Initiated/Unsolicited File Transfer），登记人 Rick Troth，语义是“发送方主动推送文件”，与常见的“接收方来取”模式正好相反。它的动机很直接：让发送方像寄信一样把文件送出去，不必先建立共享目录。
现状
这种推送语义今天主要由邮件与协作平台的文件发送承接，纯协议层面的实现没有形成规模部署，因此该端口在现网很少出现，更多是规范层面的登记。
基本信息
| 服务名称 | sift-uft |
|---|---|
| IANA 登记说明 | Sender-Initiated/Unsolicited File Transfer |
| 传输协议 | TCP 与 UDP |
| 登记机构 | Rick Troth |
| 语义 | 发送方主动推送文件 |
| 当前状态 | 无广泛部署 |
典型使用场景
- 传输模型梳理：区分推送与拉取两种模式的适用条件
- 数据交换方案评估：为跨机构文件传递选择合适机制
- 扫描报告解读：扫描器标注 sift-uft，与实际进程比对
- 遗留通道回收：清理历史文件推送相关的策略条目
- 接收目录审计：主动推送方式通常需要预置可写目录，需核对权限
- 未知服务处置：无对应组件时按未知服务流程取证
定位占用进程
定位占用进程
# Linux：查看 608 的监听进程
ss -lntup 'sport = :608'
# 交叉验证可执行文件归属
sudo lsof -i :608
# 观察连接方向，判断主机是推送方还是接收方
ss -tnp | grep ':608'
# Windows：取 PID 后反查
netstat -ano | findstr :608
tasklist /FI "PID eq 1234"传输模型对照
| 模型 | 特点 | 适用条件 |
|---|---|---|
| 拉取 | 接收方发起连接 | 接收方能控制节奏与频率 |
| 推送 | 发送方发起连接 | 贴近业务直觉，需要预先约定接收端 |
| 判读依据 | 看谁主动建立连接 | 连接方向决定会话由谁主导 |
推送模型在跨机构场景里更容易被接受，因为发送方不需要开放自己的环境，只要求对方提供接收端。它的代价是接收方需要预置目录与权限规则，并做好容量与重复投递的处理。
无论推送还是拉取，缺少对账机制都会出现“以为传完了”的假象。建议在业务层记录每次传输的唯一标识与校验值，用业务记录而不是传输日志来判断数据是否完整。