Ideas for future development of SplitHTTP

[mmmray]

This serves as a dumping ground for random ideas on how SplitHTTP should evolve. We may never implement them.

Some current issues:

1. The most obvious issue is the slow upload.
2. Streaming download requirement is sometimes a compatibility hazard.

anything else?

Some proposals for 1:

• Go back to [Potential new transport] Streamed xSSE Meek (HTTP/1.1) #3334, essentially, and add streaming upload. This can still pass nginx but no longer CDN. @RPRX suggests to release this under a separate transport name (XHTTP), SplitHTTP: Server supports HTTP/3 #3554 (comment)
• Some users have reported that maxUploadSize and maxConcurrentUploads defaults are not correct and need to be lowered to achieve better stability, even on CloudFlare where it actually shouldn't be an issue. I think it could be possible to solve this by implementing some kind of congestion control on top of the existing chunked upload. Although it sounds like a lot of work and I know very little about congestion algorithms.

Some proposals for 2:

• SplitHTTP can fall back to chunked download, essentially emulating meek. SplitHTTP: Server supports HTTP/3 #3554 (comment)

[Fangliding]

CDN usually has may IP ranges, and the client can randomly use one as the request target. The data will eventually be forwarded to the server, so the server does not need any changes, but can significantly increase the cost of tracking connections for DPI(like hysteria port hopping but it's IP hopping)

[RPRX]

现在 SplitHTTP 的基础架构可以支撑同时用十个 IP，一个下行九个上行，这样就是实际拆分而不只是逻辑拆分了

[mmmray]

oh right. I think this kind of thing should be in dialerProxy or some other layer somehow (because why not make it work for wss as well), but it's more work that way. #3482

[RPRX]

是 XHTTP 而不是 HTTPX，后者听起来像 HTTP 的一个版本或 HTTPS 这样的东西

我觉得 XHTTP 的定位可以是高效，支持 Browser Dialer 和 Nginx 等，而 SplitHTTP 则是在此基础上支持 CDN，并且探究各种 Split 模式

[Fangliding]

Perhaps we can change it to allow changing upload/download transport mode
The current approach is to use streaming requests to transmit downstream and multiple posts to transmit upstream
We can allow clients to switch to using streaming for both upstream and downstream, so that they can achieve better performance when not using CDN or use get/post to transmit upstream and downstream like Meek