一个常见的心智模型误区:觉得 SSH 天生要"持续连接、时刻监听变化",所以很耗流量、很占资源,和普通网络转发不一样。真相是:SSH 确实有一条长连接,但空闲时几乎零流量;"监听"是服务端的事、也零流量;真正吃流量的是"传数据",跟连没连着无关。

触发场景

用 SSH 管理一台远程机器(比如 用 SSH + Termux 玩旧手机 里的安卓手机)时,担心"一直连着会不会烧流量",进而犹豫要不要常驻一条 SSH 连接、或改用别的转发方式。

症状 / 直觉

  • 觉得 SSH 连接 = 持续占用带宽。
  • 觉得 SSH 要"监听变化",所以必须时刻保持通信。
  • 觉得"端口转发(frp/nginx)不用一直连,SSH 却要一直连",所以 SSH 更费。

根因:三种概念被混为一谈

  1. 监听端口(服务端) = 零流量。sshd 监听 8022、frps 监听 7000、nginx 监听 80,都只是内核里注册一个"有人来连就叫我"的入口,不产生任何网络流量。
  2. 维持一条空闲连接 = 几乎零流量。TCP 连接空闲时双方只是各留一个 socket 挂在内存里,不发数据。SSH 唯一周期性的东西是可选的 keepalive(ServerAliveInterval),每几十秒一个几字节的心跳,用来防 NAT 掐连接。挂一整天空闲连接,流量可低到 1KB 级别。
  3. 实际传输数据 = 才真正耗流量。流量的唯一来源是你发了多少命令、传了多少文件、转发了多少字节。

正确的心智模型

  • SSH 是一条加密的 TCP 长连接,不是"无连接转发";但"长连接"≠"持续耗流量"。

  • frp/nginx 这类转发也是先建 TCP 连接再转发,同样"连着";区别不在"连不连",而在协议定位:

    • SSH = 管理面:登录、执行命令、临时传文件(SCP/SFTP)、临时把内网服务映射出来(-L)。费不费流量看传了多少数据,不看连没连着。
    • frp/nginx = 数据面:长期对外服务、高频/大流量请求,针对转发优化过。

一个真实的例外:SSH 做数据面转发确实不行

SSH 端口转发(-L)能做转发,但不适合高吞吐:

  • 每转发一个字节都要经 SSH 协议封装 + 加密解密,CPU 开销大。
  • 隧道里是 TCP-over-TCP,高丢包下"TCP 重传放大",性能崩。
  • 高频/大流量转发应换 frp/nginx,SSH 只当管理通道。

一句话结论

SSH 是"一条空闲时挂在内存里、只发几字节心跳的长连接";监听端口零流量;吃流量的是传数据本身。当管理通道随便连,当数据面转发才该换 frp/nginx。

相关

本文归档于个人知识库 · 领域：CS & AI · 模块：04 Project_CS_AI/Network