Repository navigation
[RFC] Semi-xmux: Connection Multiplexing Layer for Quota Optimization and Fingerprint Randomization #794
Description
Hi there,
I would like to propose an architectural enhancement for MHRV called Semi-xmux.
The primary goal is to significantly reduce Google Apps Script (GAS) quota burn, accelerate Download/Upload speeds, reduce waiting time for EETB (Estimated End-to-End Time to Byte), and drastically randomize the traffic fingerprint against active DPI systems.
While the recently added coalesce feature is a great step forward, it still leaves room for optimization. Currently, if a website initiates 5 batches inside 1 connection, MHRV processes them as such. I propose adding a dedicated, internal multiplexing layer handled directly by MHRV.
Proposed Architecture & Milestones
I suggest breaking this fundamental feature into two progressive milestones:
Phase 1: Fundamental Multiplexing (Mux Layer)
Instead of executing a TLS handshake and generating overhead for every single micro-request, MHRV should pack 4 to 8 active connections into a single main HTTP stream.
Mechanism: MHRV acts as an aggregator, carrying multiple connections from multiple distinct target websites together in one payload.
Reassembly: The node side (whether GAS via UrlFetchApp.fetchAll optimizations or the tunnel-node service) natively disassembles the muxed stream, fetches the external resources, and returns a multiplexed/multipart response back to the client.
Impact: This immediately reduces the sheer number of isolated requests hitting the GAS endpoint, optimizing the 20,000 daily quota and reducing latency caused by repetitive connection warm-ups.
Phase 2: "Semi-xmux" Distribution Layer
Once the core mux feature is stable, we can build the actual Semi-xmux logic on top of it.
Mechanism: The client takes these heavily multiplexed streams and distributes them across several different GAS deployments (a multi-edge routing approach).
Impact: Sending stream-muxed connections across diverse deployment URLs acts as an ultimate layer of performance. It effectively load-balances the processing wait time across multiple Google edges.
DPI Resistance: By distributing packed streams across varying endpoints, the TLS fingerprint and packet timing (temporal jitter) become highly randomized, making it exponentially harder for active throttling systems to detect and disrupt the flow via RST-injection.
Expected Benefits:
Quota Efficiency: Massive reduction in quota burn per user, allowing heavier daily usage on the free tier.
Performance: Faster page loading times and lower EETB due to reduced handshake overhead.
Censorship Resilience: Highly randomized traffic fingerprints and better resistance against active DPI probing.
I would love to hear your thoughts on this approach and discuss how we can realistically implement the chunking and reassembly logic on the Rust client and the GAS/tunnel-node sides.
Activity
4clsd commentedon May 6, 2026
I ain't reading allat but from the title, yes I love mux and randomized fingerprints are good, it is being detected slowly on the dpi, so it's Now or Never
mrezaee1994 commentedon May 6, 2026
a pull request would be highly appreciated :D
w0l4i commentedon May 6, 2026
I don't have programing skills + ci/cd pipeline environment, I'm good at network engineering
2bemoji commentedon May 6, 2026
This is a compelling architectural proposal. By moving beyond simple request coalescence and implementing a true multiplexing layer, you are effectively shifting the bottleneck away from the "handshake tax" inherent in the current Google Apps Script (GAS) architecture.
1. The "Handshake Tax" and Latency
Every time a new connection is established, the TLS handshake incurs a significant round-trip time (RTT) penalty.
In high-latency environments or when routing through multiple intermediaries, a standard TLS handshake (even with session resumption) consumes precious time before the first byte of payload is even sent.
By packing 4–8 connections into a single long-lived HTTP stream, you are essentially amortizing the cost of the initial TCP and TLS handshakes over multiple downstream requests. This is conceptually similar to how HTTP/2 multiplexing works, but applied at the application-tunneling level to bypass the limitations of GAS's standard request handling.
Quota Optimization (GAS UrlFetchApp)
Google Apps Script’s
UrlFetchAppis subject to strict execution time limits and daily request quotas.Many users hit the "Execution time limit" (6 minutes) not because of the data transfer volume, but because of the overhead of sequential request processing. Reducing the number of unique
UrlFetchApp.fetchcalls by grouping them into a single multipart payload is the most effective way to maximize the utility of the 20,000 requests/day quota.Processing one large payload containing multiple requests is computationally cheaper for the Google infrastructure than initiating and tearing down several discrete HTTP sessions, which also triggers redundant internal billing/metering events.
DPI Resistance via Temporal and Endpoint Jitter
Active Deep Packet Inspection (DPI) systems often look for specific patterns: consistent packet timing, fixed request intervals, and predictable TLS fingerprints.
Phase 1 Impact: Multiplexing naturally hides the individual signatures of different target websites inside a single, obfuscated stream.
Phase 2 Impact (The "Semi" in Semi-xmux):** Distributing these streams across different GAS deployments creates Endpoint Jitter. If a DPI system attempts to correlate traffic based on the destination IP (the GAS node), the load balancing across multiple deployments forces the DPI system to constantly update its state-tracking for that specific client, significantly increasing the overhead for the censor.
Scientific Context: This approach mimics "Traffic Morphing" and "Flow Obfuscation" techniques, which are known to be highly effective against statistical traffic analysis.
Considerations for Implementation
To make this work in a Rust-based client, you may want to explore the following technical components:
Chunking/Framing Protocol:** You will need a custom, lightweight binary framing protocol to define where one sub-request ends and the next begins within the multiplexed stream to prevent the reassembly logic from failing if one sub-request is partial.
Backpressure Handling:** Because you are aggregating multiple connections, the multiplexing layer must implement robust backpressure mechanisms. If one sub-request is throttled by a target website, it should not stall the entire multiplexed stream (Head-of-Line Blocking). Implementing an asynchronous, stream-aware buffer in Rust will be critical here.
Payload Encryption:** Even though it’s a tunnel, the multiplexed payload itself should be encrypted before being sent to the GAS endpoint, ensuring that the "disassembly" logic only executes if the node has the appropriate keys.
This architecture has the potential to turn a standard proxy setup into a high-performance, hardened transport layer. It transforms the GAS environment from a simple gateway into a sophisticated, distributed edge-compute node.
@w0l4i
@therealaleph
therealaleph commentedon May 6, 2026
RFC for Semi-xmux. Reviewed the proposal — multiplex multiple user requests into a single relay request to amortize quota. Two layers of complexity:
_doTunnelBatch) and a similar shape for batch relay (q:[...]) which the client doesn't emit yet.The quota optimization is real (1 batch fetch instead of N), but tradeoffs are: head-of-line risk (a slow upstream gates the batch), more complex retry semantics (which sub-request needs retry? all?), bigger blast radius if Apps Script-side mishandles one entry.
Putting on roadmap as v1.10.0 (xmux is the canonical name for this work). Closing this thread; will reference when implementation lands.
[reply via Anthropic Claude | reviewed by @therealaleph]