tline：从 TCP 到远端终端

先证明最短路径

最小场景里，WSL 是操作端，138 和 51 都可以各自启动一个 tline server。操作端直接连接目标，不要求 138 再替 51 转发终端会话。

PTY 不要求设备被动等待连接

当前 PoC 由目标机器监听 TCP；这只是网络发起方向，不是 PTY 模型的限制。PTY master / slave 和 bash 仍然位于设备本地，master 左侧既可以接入站连接，也可以由设备 agent 主动建立出站连接。

这种 reverse-connect 形态不要求先有虚拟网络。操作端和设备都可以通过普通可出站网络连接中心，由应用层根据设备身份和 session 直接转发终端帧；只有需要为任意应用提供透明 IP 可达性时，虚拟网卡、地址分配、路由和二层转发才重新变得必要。

一条按键怎样到达 bash

“远程终端”不是把一个 shell 对象穿过网络。真正穿过网络的是字节和少量控制消息；终端语义由两端的 tty、PTY 和进程组共同恢复。

先确认 PTY 在哪里

再展开本地终端

网络通只解决“字节能不能过去”。交互式体验还要求控制字符、窗口尺寸、退出顺序和异常断开都能沿着同一条路径得到处理。

PTY 为什么是核心

普通 pipe 可以连接 stdin/stdout，却不会自动给程序一个“我正在终端里运行”的环境。PTY 是一对虚拟终端设备：应用一侧操作 master，shell 一侧把 slave 当成真正终端。

pipe、PTY 和串口不是一回事

TCP 是字节流，帧是应用自己定义的

一次 send() 不对应对端一次 recv()。TCP 只承诺在连接存活且没有错误时，按顺序交付字节。因此 tline 需要自己的长度和类型字段。

如果未来需要同时承受高速输出和控制消息，才需要非阻塞 I/O、独立发送队列、高水位线和明确的丢弃策略。v0 可以先记录这个边界，不必为了想象中的吞吐提前造完整流控层。

谁创建谁，谁等待谁

进程生命周期不能只靠信号处理器“顺手收一下”。先画出所有权，退出逻辑才有确定位置。

父进程退出并不自动保证所有后代都按预期结束。socket 断开以后，连接处理进程还需要关闭 PTY、向正确的进程或进程组发信号，并等待 shell，避免孤儿进程、僵尸进程或 PID 复用后的误杀。

session、进程组与 setsid

Unix 终端控制不是“一个进程对应一个终端”，而是围绕 session、process group 和 controlling terminal 组织的。

先把三张图分开

APUE 把这些知识分散在进程关系、信号、daemon、Terminal I/O 和 PTY 几章里。它们看起来像同一张图，实际回答的是三个不同问题；先分开，后面才不会把父子关系、文件描述符和作业控制混成一件事。

tline client
    ↕ TCP frames
connection handler
    ↕ PTY master
kernel PTY
    ↕ PTY slave
bash / foreground job

tline serve
└── connection handler
    └── bash
        ├── sleep
        └── yes | head

session
├── controlling terminal: /dev/pts/N
│   └── foreground PGID: 当前前台 job
├── process group: bash
├── foreground process group: yes | head
└── background process group: some-job &

当前只把这三张图作为阅读锚点，不表示已经掌握 APUE 中的全部信号和作业控制细节。以后若启动内核中的进程、调度与终端实现研究，再沿着这组接口进入内核侧。

setsid() 具体做什么

1. 创建一个新的 session，调用者成为 session leader；
2. 同时创建一个新的 process group，调用者成为 process group leader；
3. 让调用者脱离原来的 controlling terminal。

setsid() 不是“转后台”的同义词。它重建的是终端和作业控制的归属关系。调用者如果已经是 process group leader，调用会失败，因此常见模式是先 fork()，让子进程再调用 setsid()。

daemon:
fork → child setsid → optional second fork → no controlling terminal

interactive PTY child:
fork → child setsid → PTY slave becomes controlling tty → exec bash

所以同一个 setsid() 会同时出现在 daemon 和终端程序里。它们不是目的相同，而是都要重新安排“这个进程属于哪个会话、受哪个终端控制”。

SIGCHLD 与 SIGCLD

子进程退出、停止或继续时，内核可以向父进程发送 SIGCHLD。退出状态会一直保留，直到父进程调用 wait() 或 waitpid()；只收到信号并不等于已经完成回收。

为什么 handler 里通常要循环 waitpid

传统 Unix signal 不是可靠的事件队列。多个子进程几乎同时退出时，信号可能合并成一次通知，因此一次 handler 需要把所有已经结束的直接子进程收干净。

while ((pid = waitpid(-1, &status, WNOHANG)) > 0) {
    /* record or discard this direct child's exit status */
}

fork 和 exec 的信号继承规则

tline 里容易出现的继承问题

fork() 后，子进程会继承父进程的 signal disposition。若 server 主进程安装了一个“回收所有子进程”的 SIGCHLD handler，连接处理子进程也会继承它；它随后创建自己的 bash 时，继承来的 handler 可能先把 bash 回收，打乱连接层显式的 waitpid(shell_pid, ...)。

清晰的做法是：连接子进程在创建 PTY shell 前，把 SIGCHLD 恢复成默认处置；随后由连接层按已知 PID 显式等待。bash child 还要在 exec 前把 server 为 socket 写入而忽略的 SIGPIPE 恢复成默认处置，避免服务端策略污染用户程序。这里修复的不是两个信号技巧，而是进程角色和所有权。

Ctrl-C 不是直接发给 bash

本地终端进入 raw mode 后，按下 Ctrl-C 通常只是产生字节 0x03。tline 把这个字节送到远端 PTY master，真正解释它的是远端 PTY slave 的 line discipline。

这也解释了为什么 `sleep 100` 被中断后连接还能继续：终端把信号发给当前前台 job，而不是杀掉整个 session 或网络连接。

窗口变化也是控制面消息

主路径跑通以后，问题集中在退出

远程 shell 最容易展示的是“连上了”；更能决定它是否可靠的，是快速退出、半关闭、积压输出、信号竞态和 daemon 启动失败。

从初版到当前 PoC

初版报告记录了约 765 行 C、严格编译参数下零 warning、约 50 KiB 可执行文件，并跑通登录、命令执行、Ctrl-C、窗口变化、正常退出、强制断开和连续连接。后续独立复核还跑过连续两次连接、20,000 行输出以及 8 KiB 快速输出。

复核随后暴露了 signal handler 继承、PTY HUP 排空、终端恢复和 daemon bind/listen readiness 四类问题。当前单文件版本已分别加入显式子进程回收、HUP 后数据排空、flag-only signal handler、统一终端恢复和 daemon 前置 bind/listen；bash child 还会在 exec 前恢复 SIGPIPE 默认处置。构建保持零 warning，针对快速输出、外部信号、端口占用、daemon 连接和重复连接的测试均已跑通。

这证明的是一个边界清楚、可以真实使用的远程 PTY PoC，不是安全远程运维产品。并发上限、应用层流控、完整进程树回收、认证、加密、授权和审计仍明确留在边界之外。

保留的最小回归集

1. 严格编译参数下零 warning；
2. 本地和跨机器连接，普通命令输出正确；
3. Ctrl-C 只中断远端前台 job，连接仍在；
4. 窗口 resize 后远端 stty size 一致；
5. 短时间输出超过单个 buffer，尾部标记仍存在；
6. 客户端异常断开后 shell 被回收，server 可再次连接；
7. 端口被占用时 daemon 启动必须返回失败；
8. 客户端被外部信号终止后，本地 termios 恢复。

安全不是后补功能，但这次先冻结

能启动远端 bash 的服务，本质上已经暴露了远程代码执行能力。没有认证和加密时，它只能运行在明确隔离、参与者可信、生命周期很短的实验环境中。

“先加一个明文 token”通常只会制造一种已经安全的错觉。若安全设计尚未开始，诚实地限制实验环境，比增加一个无法轮换、吊销和审计的临时口令更清楚。

以后接 UART，会变成另一条路径

tline 这个名字最终可以靠近串口，但当前 PoC 的远端对象是 PTY 和 bash。真实 UART 不是把设备路径换一下就自动得到同一种语义。

两条路径可以复用 framing、网络传输和一部分终端 UI，却不应假装拥有相同的会话模型。板子是否提供 shell、是否支持 resize、Ctrl-C 是普通字节还是特殊命令，都由目标协议决定。

一页摘要