The fastest remote access: how LynxTrac delivers low latency
Remote access usually feels like a compromise. Here is how LynxTrac keeps round-trips tight so terminal sessions feel local instead of sluggish.
Remote access usually feels like a compromise — just slow enough to remind you it’s not local. Getting it to feel fast requires attention at every layer. Here’s how LynxTrac does it.
Where the latency actually hides
For a terminal session, the user-visible latency comes from:
- Keystroke → local event → browser event loop. ~2ms, nothing to do.
- Browser → relay over TLS. Network-bound. Can be 5-200ms.
- Relay → agent over an already-established tunnel. 5-50ms, depending on path.
- Agent → pty write. <1ms.
- Shell response → reverse path back. Same as 2-4.
So: two full round-trips per keystroke, approximately 2 × (RTT_browser_to_relay + RTT_relay_to_agent).
What LynxTrac does about each
RTT browser → relay. We run relays in 14 regions and route browser connections to the nearest one, validated by TLS SNI. Median browser → relay RTT: 18ms.
RTT relay → agent. The agent keeps a persistent multiplexed tunnel to the relay, so there’s no reconnection cost. We keep the tunnel alive with HTTP/2 pings — a new session opens a new logical stream, not a new TCP connection.
Pty handling. We buffer output on the agent and flush at 60Hz instead of character-at-a-time, which cuts syscalls by an order of magnitude without adding perceivable latency.
TLS setup. Sessions use resumed TLS tickets where supported; first-byte-to-shell is typically 80ms from a cold browser.
Remote desktop is different
For remote desktop, latency is dominated by frame pipeline — encode, send, decode, paint. We use H.264 for most sessions and switch to WebCodecs-based hardware decode where the browser supports it. On a good path, you see 16-30ms click-to-paint.
The numbers
- Terminal keystroke echo (p50): 42ms
- Terminal keystroke echo (p99, good network): 85ms
- Remote desktop click-to-paint (p50): 21ms
- Session open (cold browser → prompt): 110ms
For comparison, a direct SSH session on a LAN is ~5ms. Over a broadband connection to a remote host, 40-80ms. LynxTrac adds one extra hop’s worth of latency, at the cost of giving you zero inbound ports, full audit, and SSO-backed auth.
What still feels slow
Line editors over trans-continental paths. There’s no way to hide 200ms of RTT on a vim session across the Pacific — that’s physics. For those cases, we recommend tmux on the agent so your typing is local to the remote shell.
Try it yourself
LynxTrac is free forever for 2 servers — no credit card, no sales call. Start in under 2 minutes →
Related posts
Why remote access should never be a standalone tool
Remote access without context is just a shell in the dark. Here is why access, monitoring, and audit must ship as one surface instead of separate purchases.
How VPN-free remote access works
VPNs carry cost, latency, and a broad trust boundary. Here is how outbound-only agents give you remote access without ever opening an inbound port or routing a tunnel.
Secure remote access for modern IT teams: what really matters today
Most remote access checklists are stuck in 2015. Here are the controls that actually matter for IT teams operating across cloud, hybrid, and remote-first realities.