XHTTP: Add "stream-up" mode for client & server

[RPRX]

上午十点发频道，下午两点就写好了，中间还吃饭刷剧，所以又是两个小时系列，测试也是一遍过

顾名思义，XHTTP-H2-REALITY 等不经过 CDN 的场景并不需要分包上行，只需要 流式上行，彻底摆脱各种上行问题

XHTTP 的 stream-up 同样有默认的 header padding、XMUX，支持上下行分离 #3955 ，这些是与 HTTP 传输层的主要区别，极限性能基本没差，所以我决定 XHTTP 不再合并 HTTP 传输层，况且此前已决定 XHTTP 不应默认兼容 HTTP 传输层

配置项加了 "mode"，三选一：

• "auto" - 默认值 / 客户端：TLS H2 或 REALITY 时 stream-up，否则 packet-up / 服务端：同时兼容两种模式
• "packet-up" - 客户端：使用分包上行 / 服务端：仅接受分包上行
• "stream-up" - 客户端：使用流式上行 / 服务端：仅接受流式上行

具体实现就是 POST 到和 GET 相同的 URL，此外：

• 现在服务端向 POST 回复的报错 header 也有 padding 了
• 客户端 concurrency 计数减一移到了 onClose() 内，理论上有效，待观察
• Browser dialer 支持待完善（Chromium streaming request），Nginx 等反代软件待测试 推荐 grpc_pass h2c 其次 HTTP/1.1

XHTTP stream-up 模式旨在取代现有的 H2 / gRPC over REALITY，XHTTP 有 header padding、XMUX，表现会更好

[yoohooyoo]

从女人身上下来的R大，轻松进入心流状态。还得是贤者模式改变世界。

[ImMohammad20000]

It can run on 2 separate server?
One server use for upload and other use for download 🤔

[RPRX]

@ImMohammad20000 #3955

[RPRX]

忘了说，XHTTP stream-up 模式旨在取代现有的 H2 / gRPC over REALITY，XHTTP 有 header padding、XMUX，表现会更好

[zzlinwq]

大佬🐂（高产似母猪）

[hkbase]

小白问一下，大佬能给个配置参考吗？

[RPRX]

小白问一下，大佬能给个配置参考吗？

@Fangliding 改文档，顺便把 SplitHTTP 更名为 XHTTP

[RPRX]

你们在群里抓一下风扇去弄 XHTTP 的文档啊

[Fangliding]

因为我觉得套一层streamsettings有点那啥 多写个type多写个xhttpsettings 我觉得搞一个额外结构体再单独拿个xhttpsetting和secure设置就行了 但这样又改一道工程量又不小 我懒得做也不喜欢喊别人做事 而且也不知道其他人怎么想 再延伸到以后可能会允许服务端按这些设置监听 这样设计又是否科学 说白了就像当初和mmm讨论的那样有待商榷的地方太多 所以代码里留着可以分开的设置但是一直没急着端上来 要是以后真改了火急火燎写的文档又得重写 所以我想着再观察一下

[RPRX]

要是以后真改了火急火燎写的文档又得重写 所以我想着再观察一下

短期内不会改的，XHTTP 自身基本开发完了，就剩 browser stream-up，以及修修遗留 bug 了，接下来的开发重点是 Vision Seed

下行完全独立一套，又要有 xhttp 又要有 tls/reality 又要有 sockopt，套一层 streamSettings 是最简单、合理的，重新设计太要命

streamSettings 内加 address 和 port 也是未来的方向，它们本来就应当属于底层传输，以后 Xray 整体会往这个方向改

总之就是 XHTTP 基本告一段落，短期内不会大改了，分享标准也出了，文档是时候跟上了

[Fangliding]

以及我没有很看懂extra是干嘛的

[RPRX]

以及我没有很看懂extra是干嘛的

Host、path、mode 以外的参数的分享方案，分享链接标准中 XHTTP 就这四项 #716

[Fangliding]

这一会加糖一会又搞复杂的

[RPRX]

这一会加糖一会又搞复杂的

是有点复杂，但这就像套娃 streamSettings，参数就是这么多，都要分享，只有这么干是最简单的，不然分享链接再搞一套更复杂

[Fangliding]

还是没看懂这和分享整个原始json区别是什么 套娃stream是因为里外需要两套不一样的streamSettings 这个就只有里面部分覆盖外面 有和没有有什么区别吗

[RPRX]

还是没看懂这和分享整个原始json区别是什么

主要是打个样，方便使用 Xray-core 的客户端不需要解析 json，直接把值填进 extra 就行

因为想把最关键的三项 host、path、mode 摘出来，如果 core 不做，客户端还要自己去解析、覆盖、再序列化，可能有兼容性问题

[RPRX]

就是 GUI 不需要管 extra 的内容是什么，直接原样填进去就行，手写 json 的话用不到

另外 Xray 也能识别出这部分来自分享，然后把里面 sockopt 给去掉

[1265578519]

我不更新就不会取消，作者真有创意，居然想到要删除现有h2功能来鼓励更新。
还好这是第三方版本，可以随便瞎搞，如果作为官方版本作者肯定被人骂一顿

[RPRX]

我不更新就不会取消，作者真有创意，居然想到要删除现有h2功能来鼓励更新。

阴阳怪气的，这不是隔壁 v2fly 的贵物吗咋跑这里来了？不好意思忘了隔壁 v5 早就删了它，懒得废话，blocked @1265578519

还好这是第三方版本，可以随便瞎搞，如果作为官方版本作者肯定被人骂一顿

这什么傻逼啊，如果你所谓的“官方”指的是 v2fly，自己去看 v5 的文档，就没有过 h2 传输层，怎么没见有人骂，你去骂骂？

[RPRX]

重新决定一下，明天写个 stream-one 模式，即把 HTTP 传输层并入 XHTTP，正式补上最后一块拼图，相当于 HTTP 传输层也有了 header padding、XMUX 等功能而不用维护两份代码和名称滥用，但不应默认兼容原 HTTP 传输层所以应默认检查 x_padding

[RPRX]

https://t.me/projectXtls/514

HTTP 传输层一直以来连 header padding 都没有，固定包长早就能被精准识别了，如果现在给它加就陷入了要维护两份代码的问题

[RPRX]

https://t.me/projectXtls/515

协议的安全性更新不应兼容过去，原因是会被猪队友害了，Vision 最初兼容无 flow 就有不少人被封端口，改成不兼容了才清净

[RPRX]

https://t.me/projectXtls/516

就是因为没多少人还在用 HTTP 传输层才没那么 break，服务端要加检查 x_padding 也是防止猪队友客户端，当然如果你服务端设个 -1 也就不会检查 x_padding 也就完全兼容原 HTTP 了，虽然我不建议大家这样做也没必要这样做

此外 HTTP 传输层名称的问题还在于我们还有个代理协议也叫 HTTP，容易搞混，而且 fly v5 都扔了，别有 sb 提 VLESS，那不是一回事

[RPRX]

https://t.me/projectXtls/517

代码没扔主要是因为还要兼容 v4，v5 没它文档态度已经很明确了，可能是因为他们的 h2 还有些 bug 没修，现在发现能过 cf 可能又会捡回来，Xray 这边是去年我搞 REALITY 时把 h2 的 bug 修了才有人捡起来用，anyway 我自己修好的东西我删掉都不心疼

下一条频道消息已删，既然都改成兔头图了

[RPRX]

https://t.me/projectXtls/519

其实我想保它的原因是它是ray的所有transport里除了直进直出的tcp外最好实现的一个 绝大多数语言只需要标准库就能写出来

这下被隔壁那群写软件的带坑里了，对于穿墙协议来说，容易实现可以有但是是次要的，而且太容易实现、都去实现的话，有些实现不当的反而会成为猪队友，就像原版 Clash 的单独发协议头，就像他们喜欢 SS、Trojan 是因为简单，巧了，GFW 也是这么想的

[RPRX]

https://t.me/projectXtls/520

幽默padding=复杂

这个也挺抽象的，话说回来要求 header padding 又不复杂，且不实现 XMUX 也能兼容 XHTTP stream-one，更没理由保 HTTP 传输层了

[RPRX]

https://t.me/projectXtls/521

为啥会这样，那server端遇到原版clash这种的可以断开吗

可以写但已经没必要了，原版 Clash 的那些协议早就不适合过墙了

[aawwsslll]

我现在在用vless + reality, 我比较关心的是这个新的xhttp对比 reality来说有没有速度上的优势，如果没有那还是接着用reality吧，毕竟用着也挺好用的。