SplitHTTP: New padding mechanism #3643
Conversation
1. "ooook" handling on client is removed entirely, since there is no released version of xray-server that actually writes variable-length "ok" This partially reverts commit 4b7947c (XTLS#3614) 2. X-Padding header is added to every request and response (in fact, all of them have length characteristics if the transported protocol has length characteristics already. it can be reduced once VLESS adds its own padding, but I thought it's best to stay independent of VLESS and also handle other inner layers) 3. The client reads two bytes, and if those are != "ok", forwards them to VLESS/Trojan. I think this is the simplest way to deal with this. If headers are used for communication, then browser dialer has to be adjusted as well (may be done in later PR)
|
Whether adding padding to all traffic exceeds the responsibility of the transport layer is debatable, as that could arguably be handled by the protocol itself. Padding at the transport might only be necessary during the handshake phase. |
|
Here is how I'm thinking about it. Without any padding in the transport:
If download and upload are very busy, there is no problem. I don't want to make assumptions there. Anyway, I don't have a strong opinion on which layer should handle it. VLESS can do it but I can't imagine how it does that effectively without knowing the transport. Maybe it's also good to consider vmess/Trojan for now (vmess is still useful, it's encrypted). I also think the issue extends beyond the handshake for upload. |
|
Random thought: If your latency requirements are low, you can also perform a lot of timing-and-sizing-related traffic shaping in a layer wrapping the transport (like fragment) you can delay bytes and flush them in bursts, but not add padding -- it will not be as good as built into the transport, but maybe it is more generic |
|
I think it is better to add a new parameter called |
|
@ahmad0489 please take a look at the preceding discussion here: #3614 (comment) -- this decision to phase out
needs much stronger justification. If you cannot provide this justification publicly please send me an email (see profile). We're not going to add multiple forms of padding without any. Everybody has opinions. |
Yes, you're right, I didn't know you were going to phase out |
better than this PR or better than no padding at all? the latter I believe immediately, but this PR should be completely equivalent (for as long as you use TLS, but unless specifically targeted, probably without as well) |
Ok padding is better than this PR and better than no padding. |
|
我觉得个别 CDN 早晚会通过简单地禁止 X-Padding header 来禁止 SplitHTTP，
你指的是对 CDN 进行特殊的设置使它不转发任何 header 吗？还是反代软件？总之我觉得应当提醒用户避免这样的设置而不是接受这种情况，所以客户端检测有没有 X-Padding 就行了，没有的话就还是原逻辑， 此外想把 |
|
|
以及支持设置 -1 以不发送这个 header， |
I was thinking it's possible but didn't know how likely it is Some ideas:
|
|
@mmmray 可以先用 X-Padding，等有人报告 CDN 禁止了这个 header 再改，此外这个 PR 内 Browser Dialer 也要支持 X-Padding |
|
Encode via |
The "CDN" does not permit the forwarding of headers, there are no settings. If the protocol is switched based on the presence of the header, I think it will cause more incompatibility:
Maybe I don't understand the issue. Anyway, I really don't think the current logic in this PR was difficult to build, personally I find it easier to reason about compatibility this way, although I agree it is not elegant to wrap the reader. The support for The setting has been renamed to Actually, because the padding can be disabled with
I thought about it a lot now, and I feel that if X-Padding is blocked, the header name should just become configurable, or the user can just disable the padding. Maybe some custom anti-domestic-CDN padding can be added with custom reverse proxies, I am not sure. |
The typical length of an ETag is 32 characters or less. A 1000 characters ETag is an infrequent occurrence and the consequence of blocking it would be insignificant. Nevertheless, it is not uncommon for cookie lengths of 1000 or even 2000 characters to be encountered (for example, on dash.cloudflare.com or youtube.com, based on personal usage). Alternatively, In addition to the above, I support suggestion of using custom padding headers to address different scenarios. edit: But it seems that Sec-WebSocket-Protocol is usually no longer than 500, so it's probably okay to put padding anywhere, although there may be some weird CDN providers. |
|
Browser Dialer 支持？ |
我的意思是，CDN 应该会转发 header，除非进行了特殊设置，比如：
我的意思是应当避免这样的特殊设置，不过不用纠结这个了，我觉得 |
I'm all for using cookies for extensible configurations. Might have suggested |
|
Now that I looked at browser dialer, I'm questioning this entire PR as well. Any custom header in browser dialer will trigger a CORS preflight request, which is bad for performance and is its own characteristic. The only header that can be used for padding there is current idea:
|
|
@mmmray 我觉得客户端用 querystring |
|
对了，昨晚在群里看到了 Nginx 默认 1MB 导致测速上行没速度的问题，@Fangliding 进行更多测试？ |
|
我自己几乎不用nginx的 只是怀疑 毕竟卡1MB鬼知道会不会有MiB和MB之类的小问题或者刚好因为什么原因多一点点导致抛出错误 我叫他改2MB也没回我 |
|
I think this can be merged, header padding on every response, querystring padding on every request. Tested browser dialer. If RPRX doesn't do it I will tomorrow, just want to give everybody time to comment. |
|
反正现在客户端一定兼容任何版本的服务端，或许服务端加个逻辑，querystring 为空才发 |
|
I propose:
No matter what we do, we have to wait until most clients are updated and do not get stuck if the server does not respond with |
确实有 missing something，现在服务端的逻辑是一定发 |
"ooook" handling on client is removed entirely, since there is no released version of xray-server that actually writes variable-length "ok"
This partially reverts commit 4b7947c (SplitHTTP server: add ok padding #3614) -- servers that are on that commit from main are incompatible with clients on this PR
X-Padding header is added to every request and response (in fact, all of them have length characteristics if the transported protocol has length characteristics already. it can be reduced once VLESS adds its own padding, but I thought it's best to stay independent of VLESS and also handle other inner layers)
The client reads two bytes, and if those are != "ok", forwards them to VLESS/Trojan. This should be acceptable because VLESS/Trojan headers are larger than two bytes.
I think this is the simplest way to deal with this. If headers are used for communication, then browser dialer has to be adjusted as well (may be done in later PR)