XMUX: Change to non-infinity-reuse default values

[RPRX]

这样可以改进默认配置下 SplitHTTP 的使用体验，看了下代码，加到配置解析这里最合适，不过 API 可能会绕过这些默认值

看了下代码，splithttpNewRandRangeConfig 的 nil 改为 0 不会有问题

[Fangliding]

xmux改成指针类型然后 if Xmux==nil不就行了）

[RPRX]

xmux改成指针类型然后 if Xmux==nil不就行了）

据说有些面板会填 0

[RPRX]

@Fangliding 等正式 release 后，文档改为“忽略或全填 0 时会取这些默认值”

[Fangliding]

@Fangliding 等正式 release 后，文档改为“忽略或全填 0 时会取这些默认值”

都已经要求面板得用ssh tunnel进行http连接了这份上了 还迁就这些行为是否有些

[RPRX]

都已经要求面板得用ssh tunnel进行http连接了这份上了 还迁就这些行为是否有些

可能有些客户端也会这么干，总之想要 infinity-reuse 的话 maxConnections 填 1 就行了，不用留着“全 0 即 infinity”的语义

[RPRX]

感觉现在平均 96 个子连接就开一条新连接，频率有点高，要不要改成 192 或 384

[fodhelper]

doesn't it create a pattern/fingerprint for splithttp?

[Fangliding]

The actual behavior is random within a considerable range, and we still recommend users to fill in according to their own needs, but this default value should not cause additional fingerprints

[RPRX]

doesn't it create a pattern/fingerprint for splithttp?

这是个好问题，我还没有解释，我特地选了两个在 TLS 外不太能看出来的选项即 maxConcurrency 加 cMaxReuseTimes（而不是 maxConnections 加 cMaxLifetimeMs），并且这两个选项的默认值都是 range 取随机，最大程度上消除了潜在特征。

[fodhelper]

Lower traffic = less connections count to the same server Higher traffic = more connections count to the same server Connection count will change by the traffic rate Am i wrong? how TLS gonna hide this pattern

[Fangliding]

It is very normal for high traffic to have more connections.....

[RPRX]

Lower traffic = less connections count to the same server Higher traffic = more connections count to the same server Connection count will change by the traffic rate Am i wrong? how TLS gonna hide this pattern

我选择 maxConcurrency 而不是 maxConnections，就是为了防止连接数成为 fixed pattern，当然如果你喜欢后者也可以手动设置