XHTTP: Add "stream-one" mode for client & server #4071
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
新文章已发布:XHTTP: Beyond REALITY
#3994 (comment) 让我们补上 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":
新模式的加入也使得 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,只能说越早上车越香,现在才刚开始)