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

[RPRX]

https://github.com/XTLS/Xray-core/pull/3994#issuecomment-2497920598 让我们补上 XHTTP 近期最后一大块拼图：

现有的 HTTP 传输层使用“一条子连接”承载一条被代理请求，即没有任何上下行逻辑分离。但它一直以来存在一个没有 header padding 的大问题，即请求头和响应头在 TLS 上会表现出固定的长度特征。 加 header padding 不难，但穿墙协议的安全更新不应默认兼容旧版，否则会被旧版客户端所拖累。此外 HTTP 传输层与代理协议的名称相撞，亦没有 XHTTP 的 XMUX 等功能。

所以，最佳解决方案是将 HTTP transport with header padding 作为 stream-one 模式并入 XHTTP 传输层，这样一来也有了 XMUX 等功能而无需维护两份代码。 XHTTP 服务端会检查客户端发来的 x_padding 是否符合所配置的范围（有默认值），以确保不默认兼容原 HTTP 传输层。虽然你也可以将 xPaddingBytes 设为 -1 以兼容原 HTTP 传输层，但不建议，也没有必要这样做。

就像 stream-up 模式，stream-one 模式也默认有 gRPC header 伪装，据称也可以过 CF H2。此外，客户端发 gRPC header 伪装时，这个 PR 补上了服务端回应 gRPC header 伪装。 然而 CDN 可能对 gRPC 有流量限制，所以更建议用 stream-up 仅上行。

所以 stream-one 模式和 stream-up 模式的主要区别是前者无需服务端 "session" 机制，流量特征上也略有不同。

本来看到服务端提前发送了响应头而没有等数据一起，本想改成粘着，后来想到了一项不知道是否已公开的研究，就没改。

"mode" 四选一，客户端、服务端默认值都是 "auto"：

• "auto" - 客户端：TLS H2 时 stream-up，REALITY 时 stream-one（有 downloadSettings 时 stream-up），否则 packet-up / 服务端：同时接受三种模式
• "packet-up" - 客户端：分包上行 + 流式下行（单独的子连接）/ 服务端：仅接受 packet-up
• "stream-up" - 客户端：流式上行 + 流式下行（另一条子连接）/ 服务端：仅接受 stream-up 和 stream-one
• "stream-one" - 客户端：流式上行 + 流式下行（同一条子连接），不能有 downloadSettings / 服务端：仅接受 stream-one

新模式的加入也使得 XHTTP 更加完备，预计月底 release，正好接棒一个月：借我一个月，还你们一个完全体 XHTTP

REALITY 的 NFT 也即将发行，别错过收藏 Project X NFT 送 REALITY NFT 的最后机会：Announcement of NFTs by Project X

（初始售价 0.033 ETH 的 Project X NFT 现已涨至 0.18 ETH，且还会送 REALITY NFT，只能说越早上车越香，现在才刚开始）

[RPRX]

代码中已将缺少 header padding 的 HTTP 传输层列为 deprecated 并提醒迁移至 XHTTP 传输层，前者预计于 v25 版本被移除

代码中已建议 gRPC 传输层迁移至 XHTTP 传输层，但出于兼容性、流量特征多样化等原因，前者不会于近期被移除

[AmirReza2012]

A quick off-topic question here. Will XHTTP use h2 for alpn when using REALITY? If I want it to use h3 does it have to be TLS?

Since REALITY support for splitHTTP was added after the documentation was written, I thought I would ask

[RPRX]

@AmirReza2012 REALITY 不能修改 ALPN，基本会协商出 H2，但内层协议随意。REALITY 暂不支持 QUIC，想用 H3 需要用 TLS。