增加上下行分流

[sduoduo233]

客户端主动建立两个http1.1连接，一个用来上传，另一个用来下载。每一个连接有一个id，通过path区分上传和下载，服务器再把两个连接整合到一起。
就像这样：

这样可以避免tls in tls的问题，并且客户端如果有多可ip的话，上传请求和下载请求可以从不同ip发出。这个想法很早就有人提出了，我最近实现了一下（https://github.com/sduoduo233/commonweb），发现下载流量是可以过Cloudflare的。

[cross-hello]

Good work Mar 14, 2023 21:21:19 sduoduo233 ***@***.***>:

…

客户端主动建立两个http1.1连接，一个用来上传，另一个用来下载。每一个连接有一个id，通过path区分上传和下载，服务器再把两个连接整合到一起。 就像这样： [https://user-images.githubusercontent.com/85996970/225010431-310c5602-8ee6-4a09-bc55-cd37f56fdeb7.jpg][i][https://user-images.githubusercontent.com/85996970/225010431-310c5602-8ee6-4a09-bc55-cd37f56fdeb7.jpg] 这样可以避免tls in tls的问题，并且客户端如果有多可ip的话，上传请求和下载请求可以从不同ip发出。这个想法很早就有人提出了[v2ray/discussion#815]，我最近实现了一下（https://github.com/sduoduo233/commonweb），发现下载流量是可以过Cloudflare的。 — Reply to this email directly, view it on GitHub[#1794], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYGDFYSCQMCXWRD7DDLW4BWE7ANCNFSM6AAAAAAV2N5TBU]. You are receiving this because you are subscribed to this thread.[Tracking image][https://github.com/notifications/beacon/AKGBAYBRTJWFBC7SKRKERRTW4BWE7A5CNFSM6AAAAAAV2N5TBWWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHGBRBTTQ.gif]

[RPRX]

客户端主动建立两个http1.1连接，一个用来上传，另一个用来下载。每一个连接有一个id，通过path区分上传和下载，服务器再把两个连接整合到一起。

实现起来不难，但考虑到 ALPN，还是走 h2 吧

这样可以避免tls in tls的问题，并且客户端如果有多可ip的话，上传请求和下载请求可以从不同ip发出。

可以在一定程度上干扰 GFW 的判断，不走 CDN 时可以再结合 XTLS 解决加密套娃问题

发现下载流量是可以过Cloudflare的。

下行一直都可以，上行不可以是因为 Cloudflare 尚未支持，并且看起来不太想支持 streaming request 回源，其实这可是个好东西

去年 Chrome 105 加了它，我就写了 另一个东西，也就是扩展了 WSS Browser Dialer 到 h2，一个请求上行，一个请求下行，不过它们是同一条 h2。我还加了些料，以后再放出来。

[CCCAUCHY]

这不就是负载均衡

[simplerick-simplefun]

不错的想法。从流量计费的角度看，应该由负责下行的"server2"与"目标"连接。因为一般上行流量远小于下行。

可以考虑应用于grpc + cdn的实现：对于上行流量，客户端发起一个request，服务器能否ignore或者返回空response？或者返回一个数据量很低的随机response？这样的做法是否会产生类似"tls in tls"的可识别指纹？

之前我看gfw report就有说，他们通过修改请求骗过gfw，一个办法就是把请求拆开。从现在这个思路延申，甚至可以把上行和下行分别拆成N个连接，来打乱特征。当然打乱特征的办法是工具，目的还是要伪装成正常流量。

如果能做成，又是一段时间内墙无解的方案了。

[OnlyCharacters]

我也构想过类似的，使用一台服务器的v4 v6分别上下行，思路就是上下行使用不如的地址。

#1332 (comment)

[RPRX]

我还加了些料，以后再放出来。

防止出什么幺蛾子，先说一下吧

现有 TLS 代理的一个小特征是，总是只和主域名连接，而不像浏览器一样加载相关资源，即使是对主域名的流量特征也不像浏览器

而根据我用 WSS 的 经历，GFW 已经会结合你最近的行为去判断你的这个请求是否合理，所以加料之一就是 同时自动加载网页

但现在白名单的趋势越来越明显，以后只用原版浏览器可能不行了