[sercebr]

问题：握手期的连接对 idle_timeout_ms 完全不可见

服务端 accept 之后要等握手成功才把连接交给上层：

// src/net/uvcpp_tcp_server.cpp，listen() 的 accept 回调里
bool tls_handshake_pending = false;
if (ssl_ctx_ != nullptr) {
  const int tls_rc = client->enable_tls(ssl_ctx_);
  ...
  tls_handshake_pending = !client->is_tls_handshake_done();
  if (tls_handshake_pending) {
    client->set_tls_ready_callback([this](uvcpp_tcp_client* c, int st) {
      on_tls_handshake_done(c, st);
    });
  }
}
if (tls_handshake_pending) return;  // 握手完成时再交付

这个推迟本身是对的（握手没完成时 write() 必然失败，"已连接"这个语义也是错的）。
但框架层的连接登记表是在 uvcpp_web_app::on_accept() 里写的，而 on_accept
正是被推迟的那个回调。两者一叠加就出现了一个洞：

握手期这条连接不在任何登记表里，而 idle_sweep() 遍历的正是那张表。

于是 idle_timeout_ms 看不到它。

实测

环境：本地自签证书起 HTTPS，idle_timeout_ms=4000。

客户端行为	结果
连上之后什么都不发（明文连接）	✅ 4 秒左右被 idle_timeout 清掉
连上之后什么都不发（TLS 端口）	❌ 一直挂着 —— 连不上手，就进不了登记表
每 500 ms 发 1 字节喂 ClientHello	❌ 30 秒后仍然活着（超时值的 7.5 倍）

实验组跑的同时轮询服务端 /api/stats，connections_now 全程是 1（就是轮询
自己那条），证明卡住的连接压根没有被登记。

为什么这条值得单独处理

• 明文的 slowloris 有 idle_timeout_ms 兜着（判据是"从请求第一个字节起算"，
  滴字节刷新不了）—— 但那条规则的前提是"连接已经在登记表里"，握手期的连接
  不满足这个前提；
• 所以这是一条明文没有、上 TLS 才出现的占用路径；
• 单位带宽的占用效率极高：每 500 ms 一个字节，就能让一条连接连同它的 SSL*、
  OpenSSL 读写缓冲区一直挂着。

修复思路

在拥有握手生命周期的 uvcpp_tcp_client 里加一道一次性超时。

选这个位置而不是 uvcpp_tcp_server，是因为超时的生灭与握手的生灭完全重合，
放在客户端里，定时器的生命周期天然跟着连接对象走 —— 不会出现"服务端记着一个
已经释放的 client"这种悬垂。

三个关键点：

1. 起算点放在 tls_drive_handshake() 里（幂等）

int uvcpp_tcp_client::tls_drive_handshake() {
  if (tls_ssl_ == nullptr || tls_handshake_done_) return 0;
  tls_arm_handshake_timer();   // 幂等：已经起过就不重起
  ...

服务端与客户端两条路都汇聚到本函数推进握手，所以一处起算、两处生效。

2. 到期走与"握手失败"完全相同的那条路

tls_fail(UV_ETIMEDOUT, false);

tls_fail 已经负责"通知上层但绝不把连接交付出去"，之后由既有的收尾链
（读侧通知 → 关闭回调 → 服务端摘表并释放）走完。不需要为超时另开一条拆连接的路径。

3. 句柄生命周期

这是本改动里最容易出错的地方，单独说明：

• 定时器惰性创建（第一次推进握手时），正常路径上只活几十微秒；
• 超时回调里只 stop()、不 delete —— 那个句柄的回调正压在栈上，析构它就
  是在析构正在执行的闭包（与本文件析构注释里记的"三层悬垂"是同一类）；
• 析构分两种情况：正常分支安全释放；"在自身回调里被析构"那一支用 tls_hs_in_cb_
  判断 —— 若正跑在超时回调里则只停不放（宁可漏一个对象，也不踩正在执行的闭包）；
• tls_fail() 里同样只 stop 不 delete，因为它可能就是被那个超时回调调进来的。

句柄的最终归宿判断见下面的调用矩阵：

路径	定时器状态	谁释放
握手成功	tls_drive_handshake() 里 stop + delete	当场
握手因协议/证书错误失败	tls_fail() stop；析构（正常分支）delete	析构
握手超时	回调 stop；析构视 tls_hs_in_cb_ 决定 delete 或保留	析构
连接在握手期被外部关闭	析构 stop + delete	析构

配置

新增三层透传，默认 10000 ms，0 = 不设：

uvcpp_tcp_client::set_tls_handshake_timeout_ms(int ms);
uvcpp_tcp_server::set_tls_handshake_timeout_ms(int ms);   // accept 时下发给新连接
uvcpp_web_app::set_tls_handshake_timeout_ms(int ms);      // 框架层入口

服务端那一层必须在 enable_tls() 之前下发：enable_tls() 里就会推进一次
握手，而超时是从"第一次推进"起算的。

10 秒这个默认值是按"正常握手即便在慢链路下也远小于 1 秒"选的，留了十倍以上余量；
对握手特别慢的客户端想放宽，显式调大即可。

回归用例

tests/functional/web_ssl_app_func.cpp 新增场景 4，两段：

1. 设了 300 ms 握手超时 → 发一段永远凑不完整的 ClientHello，断言连接会在
   3 秒内被服务端关闭；
2. 对照：把这道闸门关掉（0） → 同样的连接在 2 秒窗口内必须不被关闭。

第 2 条是对照，不能省：没有它的话，"被关掉了"也可能来自别的路径（比如 idle
超时），这条用例就证明不了是握手超时干的。idle_timeout_ms 在两段里都故意留成
30 秒，把 idle 那条路排除掉。

用例用不开 TLS 的 uvcpp_tcp_client 去连 TLS 端口：要的恰恰是"线上字节凑不成
一次完整握手"这个状态，用明文 socket 发 TLS 记录头的前几个字节，对服务端来说与一个
真正的 TLS 客户端发到一半卡住完全一样。

一处取舍，想听你的意见

改用共享定时器（服务端一个 timer + 一张待握手表）能省掉"每条 TLS 连接一个
timer 对象"的开销。没有那样做是因为共享方案需要处理"表里的 client 已经被释放"
这件事 —— 而当前方案里定时器归 client 所有，这个悬垂问题在结构上不存在。

按目前的实现，正常握手下每条连接会短暂创建并销毁一个 uvcpp_timer；只有超时那条
路上它才活到连接被拆掉。如果觉得这点开销不可接受，我可以改成共享定时器版本。

测试说明

• 环境同前一个 PR：Windows 10 + MSVC，客户端为 OpenSSL 3.5.6 / Python 3.15。
• ⚠️ 本补丁同样未经编译验证：本机没有 OpenSSL 开发头，仓库的 FetchContent
  依赖也拉不下来。改动跨 6 个文件（net 层两个、webapp 层两个、测试一个，外加头
  文件），已逐行复核，但请以 CI 的编译结果为准；尤其是上面那张句柄归宿表，
  是最值得复审的部分。
• 问题部分的实测数据来自对预编译包（1.1.0）的运行观察；代码引用为 master
  当前内容，uvcpp_tcp_server.cpp 的推迟逻辑与 idle_sweep() 的判据在 master
  上均未改变。
• 两个 PR 已互相验证：git apply 可单独应用，也可按任意顺序一起应用，无冲突。

[Antruly]

已合入（squash 成 66d0147），谢谢 —— 问题本身核实为真，落点（超时的生灭挂在
uvcpp_tcp_client 上、到期复用 tls_fail）我这边也认为是这一版里最合适的选择。

本地复核（补上你标的那处"未经编译验证"）

• build-h2（Release，OpenSSL + nghttp2）全量重编：0 error C / 0 error LNK；
  ctest 87/87（新用例是 #75，实跑不是 SKIP：[web_ssl_server_hs_timeout] ALL PASS）；
• tests/tools/run_pageheap_gate.py --tree build-h2：rc=0，87 个用例裸跑与完整页堆下
  都绿、过期 DLL 0 个 —— 本 PR 动的是"回调里可能析构句柄"，这条不能省；
• OPENSSL=OFF 的 build-webapp 树同样全量重编 0 错误（并行 4 那趟在两个用例上撞了
  C1060 编译器堆空间不足，降到并行 2 就过了）、ctest 76/76、门禁 rc=0；新用例按
  web_ssl_.* 排除规则正确地不出现在那棵树里（那棵树里 test_web_ssl* 可执行文件 0 个）。

配置层、默认值 10000 ms、0 = 不设，三处透传都按你写的行为复核过。

复核中查到一个真实缺陷，已另行修掉

超时那条路上会赔掉整个 uv_loop_t。 前一次析构在"本对象正在自己的超时回调里
被拆掉"这一支上只 stop() 不关句柄 —— 依据是"删包装对象等于析构正在执行的闭包"，
这半句是对的，但只停不关的句柄既不是活跃也没在关，却照样挂在
loop->handle_queue 上。而 uv_loop_close() 正是遍历那个队列挑非 internal
句柄（_local_deps/libuv/src/uv-common.c:883），与活跃与否无关 —— 于是它永远
返回 UV_EBUSY，~uvcpp_loop 只能按既有策略把整块 uv_loop_t 泄漏掉。

实测不是推的（web_ssl_orphanprobe，同一套服务端 + 同一个卡住的 ClientHello，
唯一变量是"销毁发生在哪个回调里"）：

销毁发生在	uv_loop_close()	队列上剩下的孤儿
超时回调（闸门响）	-4082 (EBUSY)	timer active=0 closing=0
读回调（对端断开走同一条 tls_fail）	0	无

触发它不需要用户做任何特别的事：uvcpp_tcp_server 自己的管理槽
（install_client_manager() 装的 set_close_manager）就是在 tls_fail() 第 5 步里
delete 客户端的。

你新增的场景 4 挡不住这个 —— 它钉的是"连接确实被关掉了"，而那条断言在两种
销毁路径下都是绿的。所以补了一条站到循环这一侧的用例
（tests/functional/web_ssl_server_hs_timeout_func.cpp）：uv_walk 数非 internal
句柄 + uv_loop_alive()，也就是 uv_loop_close() 那两条判据的非破坏性形式
（用例里的 server/client 是栈对象，真去 uv_loop_close() 会先销毁循环再析构对象）。

修法保留你的判断、只补上缺的那半句：包装对象留在原地，底层句柄单独 uv_close
（与该文件里 tcp_ 那句同一个形状 —— uv_close 是异步的，完成回调回来时包装对象
仍然有效）。提交：d12188c。去掉那句 uv_close，新用例必红：

1 handle(s) left on the loop's handle queue after the handshake timeout fired
  — uv_loop_close() would return UV_EBUSY forever and the whole uv_loop_t leaks
  (type=13 active=0 closing=0)

关于共享定时器那个取舍

保持现在这样（每条连接一个 timer），别改共享。 理由就是你写的那条，而且这次
的缺陷恰好是它的反面教材：悬垂不是"结构上不可能"，只是"被所有权挡住了"。共享方案
要在每条拆除路径上从表里摘 client，而拆除路径在这个库里不止一条（正常收尾、协议
错误、外部关闭、以及现在这条超时），漏一条就是表里留个野指针 —— 而 idle_sweep()
遍历登记表那个形状的坑，正是这个 PR 要修的东西。次数上也不值得：定时器是惰性创建
的，正常握手只活几十微秒。

一处如实留白（没有改，先记在这里）

tls_hs_in_cb_ 是单向闩锁（uvcpp_tcp_client.cpp:1881 置上，全文件没有复位点）。
在"超时回调里没人释放客户端、之后才从别处析构"这条窄路上，析构会走 close 分支而把
那个 uvcpp_timer 包装对象留在原地 —— 句柄本身关得干净、循环也关得掉，泄漏的
只是一个约百字节的对象。

没有顺手改，是因为精确判据（"这个闭包是不是还压在栈上"）库里没有，而唯一能改进
它的位置（在 tls_fail() 之前清标记）正好会把原来那个"析构正在执行的闭包"放回来。
要真做对得动所有权，那是另一件事。