ssh 与 tcp 星怎么选

两条跨机通道并存，不是新旧替代。纠结通常来自把它们当同一条路的两个版本——其实各管一个切面：把消息送到某台机器用 ssh；要星内直达会话、跨机文件通道、堡垒拓扑用 tcp 星。ssh 半场由 ssh 专家执笔，tcp 半场待 tcp 专家补齐。

两条正交的通道

并存是设计内行为，有三处源码级证据：

回程自动选路的三分支：同一封回信按环境挑腿——本机有对端 ssh 别名走 ssh，无别名而有 tcp 星条目走 tcp（详见2.6 回信怎么认路）。一个机制同时认识两条通道，这本身就是正交并存
tcp 侧报错原文教 ssh 兜底：tcp 形态对端离线时报 PEER_OFFLINE，原文即“若两端另配了 ssh 也可走 ssh 形态“——星内故障的官方退路就是另一条通道
一对机器可同时配两条腿：ssh 别名与 tcp 星成员互不干扰，各走各的

按机器投递与星内寻址

ssh 按机器投递：--via ssh:<别名> --to <名>，名字在目标机上解析，机器内怎么找到会话完全是目标机自己的事。没有注册、没有成员名册——装好 crosschat、配好 ssh，会话命名即可投（收件形态不问出身，见2.5 查对端名单）。代价与优点同源：零部署增量，但寻址粒度停在“机器“，跨机大内容要靠 scp 旁路。

网络前提

ssh 的前提是端到端可达：双向可达（同 LAN/VPN）是默认形态；本机在 NAT 后时，回程由一条常驻反向隧道背回（随会话活的运维形态，见如何使用反向隧道）。全程没有第三台机器承载数据——这正是第2课题眼“没有中间服务器“。

选型判据表

你的情况	用	理由
两台互通，给对端机器上的会话发消息	ssh	零部署增量（复用既有 ssh），按机器直达
本机 NAT 后，只差一条回程	ssh + 反向隧道	一条常驻会话解决，仍无第三机
对端已在星里，要直达某个会话	tcp 星	会话级寻址是星的能力
要跨机文件通道（免 scp 手工）	tcp 星	内建分块传输，ssh 无此内建
多对端汇一台堡垒、消息量要常驻通道	tcp 星	broker 形态是长期正解
星内对端离线，两端另配有 ssh	退回 ssh	PEER_OFFLINE 报错原文即教此路

一句话判据：有没有“星“的需求（会话级寻址 / 内建文件通道 / 堡垒拓扑）——没有就 ssh，最省。

并存实证

上表最后一行不是应急技巧而是协议设计：两条通道各自的报错教学里都留着对方的路（ssh 侧跨机不达教自证与隧道，tcp 侧离线教 ssh 兜底）。选型失败的最坏结果是换一条腿重发，不是重做部署。