Damus
Laan Tungir profile picture
Laan Tungir
@Laan Tungir

Tor / Clearnet / FIPS Speed Comparison

Article header image

Compare how long it takes to fetch the laantungir.net homepage over five network paths

#nostr#tor#fips

Tor / Clearnet / FIPS Speed Comparison — Results

Goal

Compare how long it takes to fetch the laantungir.net homepage over five network paths to the same origin server, to feel the cost of DNS, the Tor circuit, and the Tor exit node — and to see how the FIPS mesh transport stacks up.

Results

Medians, seconds, sorted fastest → slowest. % = median total relative to the fastest path (fips = 100%). 5 distinct Tor circuits × 10 runs each for the Tor paths; 10 runs for the others. No warm-up — the cold first fetch is included. Run: 2026-08-06.

pathaddressdns (s)tcp (s)tls (s)ttfb (s)total (s)%
fips-udpnpub1crpl…t59ud.fips0.0000.1220.0000.2430.610100%
direct-iphttps://15.235.3.231/0.0000.1210.2450.4870.729120%
clearnethttps://laantungir.net/0.0530.1740.3000.5410.784129%
tor-onionkn2jam4k…uvnad.onion0.0000.0000.0000.7011.444237%
tor-exitlaantungir.net (via Tor exit)0.0000.0000.6271.1351.450238%
fips-tornpub1crpl…t59ud.fips (FIPS over Tor)0.0000.5000.0001.1013.949647%

All paths returned the full 135,977-byte payload.

fips-tor is the same FIPS npub host, but with the FIPS node's transport layer switched to Tor. The FIPS daemon (not curl) owns the Tor circuit, so distinct circuits were sampled by reconnecting the daemon's link (fipsctl disconnect/connect) between rounds — 5 circuits × 3 runs. The FIPS mesh stack (IPv6 → FSP Noise → FMP → Tor circuit) rides on top of the Tor circuit, which is why it is slower than bare tor-onion despite both traversing a single Tor circuit. Runner: scripts/fips-tor-circuits-test.sh · raw data: logs/fips-tor-circuits-20260806T163622Z.txt.

Runner: scripts/tor-speed-test.sh · Methodology: plans/tor-speed-comparison.md · Raw data: logs/tor-speed-test-20260806T155725Z.txt

Explanation

FIPS is fastest, and it is fully encrypted. Its tls = 0.000 does not mean plaintext — it means curl isn't the one doing the encryption. FIPS encrypts below the application, inside the daemon, using the Noise protocol framework (hop-by-hop Noise IK on each link, end-to-end Noise XK between the two endpoint npubs), settling on ChaCha20-Poly1305 symmetric keys after the handshake. Crucially, that session is persistent and reused: the handshake happens once, then every request rides the cached keys. So FIPS's 0.610 s is almost pure RTT + server processing, with zero per-request crypto setup.

FIPS over Tor is the slowest path — encryption isn't free to route. When the FIPS node's transport is switched to Tor (fips-tor, 3.949 s), the same persistent-session advantage no longer dominates, because the whole FIPS mesh stack — IPv6 packet → FSP Noise-encrypted datagram → FMP link frame → Tor circuit — rides on top of a Tor circuit instead of a direct link. The result is ~2.7× slower than bare tor-onion even though both traverse a single Tor circuit: FIPS adds its encapsulation and routing overhead to Tor's latency, and the daemon's Tor link was itself measuring a high ~550–700 ms SRTT during the test. The 5-circuit spread was tight (3.45–4.28 s), so this is a consistent cost, not one bad circuit. The lesson: FIPS's win comes from a fast direct link plus session reuse; put it on Tor and it inherits — and compounds — Tor's latency.

HTTPS pays a TLS handshake on every request. direct-ip and clearnet show tls ≈ 0.245–0.300 s because each curl opens a fresh TCP connection and does a full TLS handshake (cert exchange + validation + key agreement) before the HTTP request. The only difference between them is DNS (0.053 s for clearnet, 0.000 for direct-ip) — small relative to TLS.

Tor adds a full circuit on top. tor-exit is the slowest model: it builds a 3-hop Tor circuit, then does a second TLS handshake to the clearnet origin through the exit node (tls = 0.627 s). tor-onion skips the exit node and the clearnet TLS layer entirely (tls = 0.000) — the onion's end-to-end crypto shows up under ttfb instead.

The cold-start cost is real, and it's why we stopped discarding the warm-up. Every tor-onion circuit's first run was its slowest (4.0–4.8 s vs ~1.5–2.3 s steady-state) because the first request pays the Tor stream-build + rendezvous cost. Including those cold starts pulled tor-onion's median up to roughly tie tor-exit (1.444 vs 1.450 s); in a warm-only run tor-onion was clearly ahead. The honest takeaway: per request, tor-onion avoids the exit-node TLS tax, but it pays a heavier one-time circuit-build cost — so which is "faster" depends on whether you amortize over many requests (onion wins) or measure a single cold fetch (roughly a wash).

Bottom line: for repeated fetches to the same peer, a persistent encrypted session over a direct link (FIPS) beats per-connection TLS (HTTPS), which beats routing through a Tor exit node — and going straight to a .onion avoids the exit-node tax at the price of a heavier first-connection build. Layering FIPS on Tor (fips-tor) is the slowest option of all: you pay FIPS's mesh encapsulation on top of Tor's circuit latency.