mux cool: Add maxReuseTimes

[Fangliding]

字面意思 现 mux cool 逻辑: MaxConcurrency 为一个连接里的最大活动子连接数 还有一个神秘的 MaxConnections 参数 硬编码为128 实际上就是最大复用次数 我不知道为什么叫这个 这个PR将其重命名了 我修改了一下 允许手动指定 maxReuseTimes 并把默认值变成了65535(mux.cool两位流ID允许的最大上限)

这些限制仅存在于客户端 服务端没有限制 旧的可以正常工作

[RPRX]

还有一个神秘的 MaxConnections 参数 硬编码为128 实际上就是最大复用次数 我不知道为什么叫这个 这个PR将其重命名了

之前我也发现了这个，我觉得现在要加参数的话不如加上与 XMUX 等价的所有参数，~~所以明年再合~~

[yuhan6665]

现在要加参数的话不如加上与 XMUX 等价的所有参数

这个我支持R佬 长远来看 XMUX 应该对 mux-cool 以及所有有 mux 效果的 transport 起作用

[Fangliding]

我也不反对 不过这都是后话了 其他部分还有包括让它支持range什么的都需要一定的修改 而且就连xmux自己刚刚都还有一些参数修改 这里只是把这个已经有的逻辑暴露出来

[yuhan6665]

~~所以我一开始就说配置放外面~~ https://github.com/XTLS/Xray-core/pull/3613#issuecomment-2256118984

[Fangliding]

之前甚至还想过要不要轮转重用前面的子连接ID 65535可能有点短 看起来应该不用 除了被劣质tdesktop一秒钟刷几个post一般到个几千万把到头了

[ghost]

还有一个神秘的 MaxConnections 参数 硬编码为128 实际上就是最大复用次数 我不知道为什么叫这个 这个PR将其重命名了

之前我也发现了这个，我觉得现在要加参数的话不如加上与 XMUX 等价的所有参数，~所以明年再合~

I think you should try to integrate this pr and then it will be completed in the rest of the version, But still, your opinion is preferable

[RPRX]

@alphax-hue3682 I'm not intend to introduce unstable changes between v24.12.31 and v25.1.1. The diffs should be tiny.

[Fangliding]

这个可以考虑了吧 不过我在想不要把限制 65535 顶满了 改成硬限制 65000 或者 60000 剩下一点点作为保留 类似xudp使用的子连接 ID 0 作为特殊用途

[Fangliding]

比如一些连接控制信息 用65001发送 六万多个子连接ID不够用 用65002发送后面再加一个可边长子连接ID再接真正的请求

[RPRX]

想发个新版，关于这个 PR 我本来想的是要不先把 128 这个数值改大点，然后想到现在 XMUX 也是限制复用几百次，先不改吧

[Fangliding]

嗯 主要是这样可以一条连接赖着不死开几个小时(我专门加了一个日志记录) 使用体验区别不会很大

[RPRX]

大多数运营商应该会倾向于 Q 掉时间过长的 TCP 连接，对 QUIC 则更加严苛

[Fangliding]

大多数运营商应该会倾向于 Q 掉时间过长的 TCP 连接，对 QUIC 则更加严苛

我想了一下 可以这么扩展mux cool的策略 不过和xmux的想法不太兼容

concurrency expectedConcurrency maxReuseTimes

如果一个mux的活跃连接达到concurrency 标记为已满 达到maxReuseTimes标记为已关闭/等待关闭

把mux worker放在一个数组里 先从后往前遍历所有worker 忽略已满和已关闭 如果发现这个连接的活跃连接小于expectedConcurrency 直接将即将发送的请求分配给它 如果没有 在没被忽略的连接里选择活跃子连接数最少的 这样如果因为短时间并发产生很多mux连接 核心可以把它们均匀分配给所有worker 而后请求数下来 达到了expectedConcurrency以下 核心会倾向把请求分配给更新鲜的mux连接 旧的连接会被战略性忽略 促使核心放弃过老的连接