connection up/down splitting -- how to design?

[mmmray]

splithttp has some connection splitting built-in but not exposed, and there is a desire to have it for a few reasons:

• obfuscation of up/down traffic patterns or to defeat some other kind of detection
• cost optimization -- upload can pass through a more expensive, unthrottled CDN, download can pass through free CDN. The free CDN is throttled on upload but not on download

There are many ways to satisfy those usecases, and I am not sure what is the best to implement.

Option A: Generic TCP splitter

Essentially, the functionality inside splithttp is ignored, and another transport is built. On the client:

"outbounds": [
	{
	    "protocol": "vless",
	    ...,
	    "streamSettings": {
	        "network": "tcpsplitter",
	        "tcpsplitterSettings": {
	            "uploadDialerProxy": "my-upload",
	            "downloadDialerProxy": "my-download"
	        }
	    }
	},
    {
        "protocol": ???,  // I don't actually know, does "freedom" work here?
        "tag": "my-upload",
        ...,
       "streamSettings": {
           "network": "websocket", // or splithttp, or...
           ...
       }
    },
    {
        "protocol": ???,
        "tag": "my-download",
        ...,
       "streamSettings": {
           "network": "grpc",
           ...
       }
    }
]

The serverside config is TODO. The idea is that a different protocol can be used for upload vs download. For example, if the "upload CDN" supports websocket, but the "download CDN" supports nothing, one can use chunked transfer for download, but websocket for upload.

The downside here is that this is difficult to write, and I think the config for mobile will be really messy.

Option B: SplitHTTP can tag its traffic for routing

"outbounds": [
    {
        "protocol": "vless",
        ...
        "streamSettings": {
            "network": "splithttp",
            "splithttpSettings": {
                "downloadDialerProxy": "my-downloader",
                "uploadDialerProxy": "my-uploader"
            }
        }
    }
]

This is less flexible than Option A, many transport types cannot be combined. On the other hand, the overhead is lower, because there is no additional "session management" hashmap just for splitting connections.

Option C: Honor HTTP redirects in splithttp

This is the easiest to build.

Basically, nothing changes about the config. Instead, in splithttp the download GET /<sessionid> is changed so that it follows HTTP redirects across domains.

When a user establishes a connection with splithttp to example.com, the server can redirect the download using 301 Location: https://otherexample.com/.... And now the connection is split!

When this happens, the SNI and Host header is reset, and there is no way to do domain fronting. It has also very weird characteristics when establishing the connection.

On the other hand, this setup is easily compatible with sharelinks and most GUI clients, as most of the splitting can be controlled by the server.

---

@RPRX Any opinions about what should be pursued? Any suggestions about the config format? I don't really have a lot of opinion about this, this will be painful to build no matter what.

[galaxyport]

Using a generic splitter is a very good idea, especially for Iranians. Some of its advantages include:

• In Iran, domestic VPSs have very good upload speeds, but the cost of using them is very high. Sometimes the cost per gigabyte is comparable to mobile internet. By using this idea, it would be possible to upload via domestic VPSs and download directly, reducing the cost of using internet censorship solutions by ten times. This is because ordinary users mostly download and upload less, and there are almost no restrictions on downloading, while most disruptions occur with user uploads.

• Domestic VPSs are designed for uploading, and if a large amount of data is uploaded, it won't be suspicious, and they are less likely to be blocked.

• VPS servers used directly for downloading will not be censored or filtered because their identification method is through detecting upload handshakes.

• Cloudflare has been experiencing issues in Iran recently, and almost all Cloudflare disruptions are related to the upload section. If uploading and downloading can be separated, uploading can be done via domestic VPSs and downloading via Cloudflare or users' personal servers.

• This capability also removes the download limitations for Iranian users, as VPNs on domestic servers charge high fees for downloads based on gigabytes, while direct connections to foreign servers have very low download costs. Here, only the upload cost to domestic servers is paid.

[yuhan6665]

Share my two cents:

C ===== wall? ===== S --------- Dest

Assumption is single outbound config manages the connection from proxy server (S) to dest. Then what ever we do between C and S could be open to config, Mux, Split, DialerProxy. Seems to me these can be put at the same level of current "mux" object.
It is obviously a fresh and complex project. I'd say start small and work with steps. Optimistically we are ahead of this game :)

[mmmray]

if this is added to mux (but also with the other options), what are your thoughts on how this could look like in sharelinks? It seems that things like fragment and mux never made its way into sharelinks, but I think that's a bit unfortunate actually.

[yuhan6665]

yeah I haven't thought about the sharing link design for a while (traditionally managed by client builder such as @2dust ). I think we need to expand this design for the future.
Again, how user want to transport between C -> S is very important. We should be able to capture this info in the sharing link. Doesn't matter if it is Mux, Split, or DialerProxy.

[yuhan6665]

I just read about this..
daeuniverse/dae#236