隧道架构
一条隧道，从建立到转发
从SSH握手、账号认证、端口监听，到协议处理、限速与并发控制，隧道的每一层都是自研。原生 ssh -R 只解决了「连通」，我们把业务层全部补上。
nssh 客户端
发起连接 · 自动重连
SSH -R 反向隧道
SSH 服务端
认证 · 协议处理 · 限速 · 转发
端口监听 · 数据转发
内网服务
公网可访问
服务端
核心数据流
一条隧道从建立到转发，要经过六个环节，每个环节都可独立管控
从连接到转发
SSH连接
SSH Server
认证
Redis Auth
协议处理
Protocol Handler
隧道创建
Tunnel Manager
端口监听
Port Binding
数据转发
Data Transfer
自研内核
隧道内核技术
Go语言实现，从协议层开始自研
自研SSH协议栈
基于Go标准库进行深度定制，完整掌控SSH握手、密钥交换、认证、通道建立全流程。
SSH-2.0 协议
密码+密钥认证
反向隧道
自定义通道
自研协程池
自研协程管理机制，按任务类型划分独立工作池，资源精细管控。
独立工作池
阻塞提交
自动调度
资源隔离
自研QoS限速器
基于令牌桶算法，支持全局和隧道级带宽控制，零CPU空转。
令牌桶算法
全局+隧道级
精确阻塞等待
动态调整
并发控制与资源限制
多层并发控制，从单隧道到全局，每个层级都有明确的资源上限。
隧道级隔离
连接数限制
内存监控
Prometheus 指标
能力清单
原生 ssh -R 做不到的事
连通只是起点，隧道之上还有一整层业务能力
认证鉴权
每次连接都要通过账号认证，隧道不会被陌生人随意占用。
端口分配管理
端口由平台统一分配与回收，避免多条隧道抢同一个端口。
限速控制
按套餐带宽对隧道限速，不干扰同一台服务器上的其它隧道。
并发限制
连接数与内存都有上限，单条隧道不会把节点资源打满。
断线重连
网络抖动后客户端自动重连，隧道尽可能自行恢复。
状态监控
隧道连接状态与流量指标实时上报，异常可查可定位。
技术选型
为什么这样做隧道
每一项技术选型都有明确的工程理由
为什么不直接用 ssh -R？
原生ssh -R无法做到：认证鉴权、端口分配管理、限速控制、并发限制、断线重连、多进程集群、状态监控。内网云在原生SSH之上构建了完整的业务层。
为什么限速用 阻塞等待 而不是轮询？
传统10ms轮询在低流量时浪费CPU，且精度固定。阻塞消费(ConsumeBlocking)根据TokenBucket缺额精确计算等待时间，零CPU空转，精度到bit/s。