Phase 2 implements a baseline TCP tunnel over TLS. The architecture consists of
an accelerator-ingress agent and an accelerator-egress agent. They establish
a server-authenticated TLS session and relay TCP stream data using a simple
8-byte framing protocol.
This phase does not implement QUIC multiplexing or advanced congestion control (planned for Phase 3). As a result, the performance in the WAN laboratory is expected to be identical to or slightly worse than the Phase 1 direct TCP baseline, due to the added TLS encryption and framing overhead.
- Ingress Agent: Listens on
127.0.0.1:1080. Accepts TCP connections, connects to the WAN peer over TLS, and relays traffic. - Egress Agent: Listens on
0.0.0.0:4433(TLS). Authenticates the ingress agent, connects to the final target, and relays traffic. - Protocol:
[Version: 2 bytes] [Type: 2 bytes] [Length: 4 bytes] [Payload].
The validation was performed using accelerator-bench running through the ingress and egress agents over local loopback. The setup successfully demonstrated:
- Bidirectional transparent proxying.
- TLS encryption with egress certificate validation by ingress.
- Clean connection teardown and
HALF_CLOSEpropagation.
(Note: Full WAN impairment tests are deferred to Phase 3 where QUIC will show measurable improvements over TCP).
| Profile | Method | Duration (s) | Goodput (Mbps) | Verified |
|---|---|---|---|---|
| unlabelled | direct_tcp (Phase 1) | ~0.04 | ~200.0 | true |
| unlabelled | tunnel_tls (Phase 2) | ~0.06 | ~139.3 | true |
The tunnel introduces minor latency and CPU overhead due to TLS encryption, user-space framing, and context switching between the agents. This validates the correct functionality of the relay loop.
Proceed to Phase 3: QUIC Transport to replace the underlying TLS/TCP transport with a multiplexed QUIC session using MsQuic. This will let the lab measure whether independent QUIC streams improve mixed-flow behavior on lossy WAN profiles.