Abandoning QUIC for TCP? The Counterintuitive Architecture of xSend LAN Transfers

In the grand river of network engineering, QUIC (the bedrock of HTTP/3) is undeniably the shining star of the decade. It entirely reinvented the transport layer on top of UDP, boasting 0-RTT handshakes, the elimination of head-of-line blocking, and the ability to maintain a connection even as you switch from Wi-Fi to cellular data.

Unsurprisingly, xSend embraces QUIC completely for its Wide Area Network (WAN) peer-to-peer transfers. It provides an incredibly resilient, packet-loss-resistant tunnel for transfers bridging continents and complex networks.

However, if you peek into our src/lan.rs source code, you’ll discover something bizarre: In the absolute best, fastest environment—your Local Area Network (LAN)—we abandoned the state-of-the-art QUIC and reverted to primitive TCP.

It’s a wildly counterintuitive technical crossover. But it’s also the most pragmatic architectural trade-off we’ve ever made.

1. The Absurd Bottleneck: When the CPU Chokes the Network Card

On gigabit (1 Gbps) or ten-gigabit (10 Gbps) local networks, physical bandwidth is rarely the bottleneck. The real battleground shifts to the host machine’s CPU syscall and context-switching overhead.

QUIC is a protocol suite that simulates congestion control, sliding windows, and packet retransmission entirely within User-Space. On the high-latency open internet, this isn’t slow at all. But when your LAN transfer speeds surge to 100 MB/s or even 300 MB/s, you quickly realize the bottleneck isn’t the ethernet cable. It’s the fact that the single CPU core handling the network stack is pinned at 100%.

What about TCP? TCP is fundamental infrastructure hardcoded into the Kernel-Space of the operating system. Modern Network Interface Cards (NICs) even feature TCP Offload Engines (TOE), meaning the network card calculates sliding windows and checksums in hardware without ever waking up the CPU.

In a perfect LAN environment with zero packet loss and sub-millisecond latency, TCP is the absolute king of throughput.

2. Dragon-Slaying Weapons: QUIC’s Anti-Loss Features Become a Drag

Let’s review the three legendary features of QUIC:

• 0-RTT Handshakes: Shaving off a 200ms handshake between New York and Tokyo is massive. But when your router is sitting next to you with a 0.5ms ping, saving 1 millisecond is imperceptible.
• No Head-of-line Blocking: The internet is vast, and packets get lost constantly. But if you connect two machines to a reliable gigabit switch via ethernet, the packet loss rate is practically 0.000%.
• Connection Migration: LAN file transfers generally happen while sitting at a desk. No one switches from internal Wi-Fi to a 5G cellular network while transferring a 50GB 4K video locally.

On a LAN, QUIC’s meticulously designed algorithms and heavy packet-header overhead devolve into pure performance drag.

3. TCP’s Minimalist Kevlar: ChaCha20-Poly1305

If we aren’t using QUIC’s mandatory TLS 1.3, how do we guarantee security on the internal network?

xSend’s answer is an exercise in “Violent Minimalism”:

1. Both parties establish a clean, long-lived TCP connection.
2. They rapidly exchange symmetric keys via an X25519 handshake.
3. Next, we slice the data into large, fixed chunks (e.g., 2MB). We abandon all multiplexing and run the ChaCha20-Poly1305 encryption cipher directly over the raw kernel TCP stream.
4. Each chunk is encrypted, slapped with a length header, and violently shoved into the TCP Stream (write_all).

The entire underlying send/receive core is extremely sparse. We stripped away all the “heavy armor,” minimizing how much our user-space code interferes with the underlying kernel. The sole purpose is to squeeze every last drop of throughput out of the network card.

4. Bypassing the “LAN Butler” QoS Blockades

There is a very specific pain point in many university networks, massive corporate intranets, and even on some enthusiast-grade home routers: Administrators heavily police traffic using strict Quality of Service (QoS) rules.

When these firewalls see an unknown, high-frequency stream of UDP traffic (especially a single connection maxing out hundreds of megabits), their first reaction is often: “This is clearly a rogue P2P downloader or an internal DDoS attack!” The router immediately throttles, drops packets, or completely severs the connection.

TCP, on the other hand, is treated much more “gently.” xSend’s TCP long-connections are welcomed by 99% of routers on the market, identified simply as stable, conventional business traffic.

---

Conclusion: Architecture is Pragmatism

Great architecture isn’t about cramming the newest, coolest wheel into every available crevice.

The Wide Area Network (WAN) is a hostile wilderness filled with potholes and offline nodes. We deploy QUIC, trading slightly higher CPU overhead for off-road resilience, guaranteeing the tunnel remains solid no matter how terrible the conditions.

The Local Area Network (LAN) is your private, ten-lane autobahn. What you need to do is throw out the heavy shock absorbers and the thick all-terrain tires, bolt on a TCP acceleration engine, floor the gas pedal, and feel the G-force.

It is precisely through this seemingly “fragmented” but ultimately perfect binary architecture that xSend achieves speeds noticeably faster than the competition, regardless of the network you find yourself on.