RPRX
> RatelimitedConn 的 Read() 有个问题，如果数据量大要等很久，或者直接卡死 > > 应该改成 Write() 里有多少 token 就 write 多少数据 这个我想了一下不会卡死，但有多少 token 就 write 多少数据也不太行，调用方循环 write 会造成调用次数太多 只是说如果限速 1kb/s，但 target 发来一个 16kb 的 record，要等 16 秒。。。
~~uint64，不是 int64~~
我不确定 golang 里 uint64 转 int64 大于一半时会发生什么，你试一下，不过搞这么大还限什么速，所以 max 那里有点没必要 After 就直接传过去，不用减掉 burst 把 write 改回 read 吧，然后把 NewBucketWithRate 的逻辑合进去，也就是说直接传三个参数
~~那我想这个版本就把 H2 传输层删了，命名为 HTTP 实在是~~
@mmmray 你研究下 chrome 支持的 streaming request，支持 browser dialer，把 SplitHTTP 重命名为 XHTTP，加个参数 mode，现在的两种分别为 splitupload 和 normalupload，结合 REALITY 时默认后者否则默认前者，我写一下可以在 path 中配置这些参数
Streaming request 模式就叫 normal，不用加 upload 后缀
> `?upload=normal` / `?upload=chunked` ~~或许这样也行~~
https://github.com/XTLS/Xray-core/issues/3823#issuecomment-2362658554
@mmmray ~~应该有空先把这个 PR 完成吧，剩下的我来~~
我一直认为 @mmmray 是将 SplitHTTP 重命名为 XHTTP 的最佳人选，so，the plan is： 1. 将 HTTP 传输层的 H2、H3 并入 SplitHTTP，同样默认有 header padding 和 XMUX，同时 SplitHTTP 也支持了 REALITY 2. 支持旧版配置的转译，提醒迁移，v25 删掉转译代码 3. 若写 XHTTP，安全选 REALITY...