Skip to content

R-VPN Performance Optimization Plan

Implementation Status

Phase Feature Status Location
Phase 1 SplitRatchet for Concurrent Access ✅ IMPLEMENTED rvpn-core/src/crypto/ratchet.rs
Phase 2 Buffer Size Optimizations ✅ IMPLEMENTED Channel buffer: 10,000 slots
Phase 3 Client Reconnection Logic ✅ IMPLEMENTED rvpn-client/src/tunnel.rs
Phase 4 Binary Protocol Migration ✅ IMPLEMENTED rvpn-core/src/protocol/codec.rs
Bonus Connection Pooling ✅ IMPLEMENTED rvpn-server/src/handler.rs

Original Architecture Bottlenecks (RESOLVED)

1. Lock Contention on DoubleRatchet ✅ FIXED

Problem: The Arc<RwLock<DoubleRatchet>> serialized all encrypt/decrypt operations.

Solution: Implemented SplitRatchet with separate Arc<Mutex<SendingChain>> and Arc<Mutex<ReceivingChain>>: - encrypt() only locks sending chain - decrypt() only locks receiving chain - DH ratchet operations still need both locks (but happen less frequently)

Result: True concurrent access for encryption and decryption operations.

2. Small Buffer Sizes ✅ FIXED

Problem: Limited channel buffer sizes caused backpressure.

Solution: Increased channel buffer size to 10,000 slots for high-throughput scenarios.

Result: Better handling of bursty traffic and large transfers.

3. JSON Serialization Overhead ✅ FIXED

Problem: Binary data was base64-encoded in JSON, adding ~33% overhead.

Solution: Migrated to binary protocol with raw binary encoding.

Result: ~30% bandwidth reduction and faster serialization.

4. No Connection Reuse ✅ FIXED

Problem: Each HTTP request created a new proxy connection.

Solution: Implemented connection pooling in the server.

Result: Connection reuse for better performance.

5. No Client Reconnection ✅ FIXED

Problem: When the WebSocket dropped, the client exited instead of reconnecting.

Solution: Implemented automatic reconnection with: - Cleanup of stale connections - Heartbeat mechanism - Exponential backoff retry logic

Result: Better user experience with automatic recovery.

Performance Benchmarks

Throughput Test

  • Large file (100MB) download through proxy
  • Result: Significant improvement with concurrent ratchet access

Concurrency Test

  • Load website with many resources (YouTube, news sites)
  • Result: Smooth page loading with multiple concurrent connections

Latency Test

  • Time to first byte measurement
  • Result: Reduced latency due to binary protocol

Reconnection Test

  1. Start client and server
  2. Load a webpage
  3. Kill server process
  4. Restart server
  5. Result: Client reconnects and can load pages again

Notes

  • TLS is handled by Caddy reverse proxy, so we don't need to implement TLS in the server
  • The Double Ratchet protocol requires strict message ordering - maintained through proper chain synchronization
  • Client reconnection means re-doing X3DH handshake and Double Ratchet init (new session)