From Kernel to Browser

3. Tool 1: PQ Crypta Speed Test

The Speed Test is a browser-based diagnostic that directly compares QUIC/WebTransport performance against TCP on the user's actual connection. It measures five metrics — latency (RTT), jitter (σ), packet loss (%), download throughput (Mbps), and upload throughput (Mbps) — using genuine QUIC datagrams and WebTransport streams, not TCP round-trips, HTTP polling, or simulated UDP.

3.1 Latency and Packet Loss: True UDP Datagram Echo

RTT and jitter are measured via real QUIC/UDP datagram echo using QUIC DATAGRAM frames as defined in RFC 9221. Each ping embeds a high-resolution timestamp and sequence number. The server echoes immediately; the client computes round-trip time with sub-millisecond accuracy. This is not an HTTP-level ping — it is the true cost of a single UDP round trip through the user's ISP, middleboxes, and WAN path.

Packet loss probing fires 200 datagrams concurrently. Any datagram failing to echo within 2 seconds counts as lost. This concurrent burst approach reveals bursty loss caused by shallow buffers, ISP traffic policing, or wireless interference — patterns that sequential probing misses. TCP retransmissions mask loss at the transport layer; QUIC datagrams expose it directly.

3.2 Download: Trimmed Steady-State Measurement

QUIC Download: 12 concurrent WebTransport streams download data over a time-bounded window. The first 1.5 seconds are discarded to exclude congestion-control ramp-up. Only the steady-state window is averaged, eliminating slow-start artifacts. Deep Test mode extends the window to 10 seconds (standard: 5 seconds), allowing QUIC to fully saturate the link.

TCP Download: 6 parallel HTTP/1.1 streams, each on an independent TCP connection. HTTP/1.1 is explicitly negotiated — not HTTP/2. HTTP/2 would coalesce all streams onto a single TCP pipe via multiplexing, meaning one stalled HTTP/2 stream would drag all streams to zero simultaneously (head-of-line blocking). The server sends pseudo-random bytes to defeat ISP compression inflation.

3.3 Upload: Server-Measured Steady-State

QUIC Upload: 16 WebTransport streams each send data to the server. The server independently times each stream from first byte to FIN, discards the first 2 seconds, and reports steady-state Mbps. The 16 per-stream values are summed. Chrome serialises writes within a single QUIC stream, so parallel streams are required to fill the shared congestion window. Deep Test mode extends to 12 seconds (standard: 8 seconds).

TCP Upload: 6 parallel XHR streams each POST a 50 MB body over independent HTTP/1.1 connections. XHR is used instead of fetch() because Chrome throws a TypeError when a streaming ReadableStream body with duplex:'half' is sent over HTTP/1.1 — a browser implementation constraint, not a protocol limitation.

3.4 Live Path Traceroute and Network Fingerprint

A background traceroute streams hop-by-hop data to the UI in real time using ICMP probes sent from the server (browsers cannot send ICMP). Each visible hop is reverse-geolocated via the GeoLite2 database to show city and ISP. A composite stability score classifies the link as suitable for real-time gaming, video conferencing, or general browsing. Percentile comparison against recent real users provides context for what the numbers mean.

3.5 Critical Design Decisions

0-RTT is disabled. Every QUIC session is a full 1-RTT handshake. The RTT displayed is the true baseline cost — not an artificially low number produced by session resumption.

4. Tool 2: HTTP/3 QUIC & WebTransport Scanner

The HTTP/3 Scanner is a server-side native QUIC probe. It determines whether a target server actually supports HTTP/3, QUIC, and WebTransport — not inferred from HTTP response headers, but verified through actual QUIC transport-layer connections using the quinn and h3 Rust libraries.

4.1 How It Works

The Scanner sends real QUIC Initial packets to the target server and attempts a full QUIC handshake. If the handshake succeeds, it negotiates HTTP/3 via ALPN and opens HTTP/3 streams. If it fails, it records exactly why — timeout, TLS alert, version negotiation failure, connection refused. This is fundamentally different from checking whether an HTTP/2 response includes an Alt-Svc: h3=":443" header. The header is a promise. The Scanner verifies whether the promise is kept.

4.2 What It Extracts

• QUIC transport parameters: MTU, idle timeout, datagram support, congestion window, max streams, initial flow control limits
• Connection metrics: handshake completion time, TTFB, RTT as observed by the QUIC stack, packets sent and lost during the probe
• TLS extension analysis: ALPN protocols offered and selected, key share groups, ECH (Encrypted Client Hello) support detection
• Server implementation fingerprinting: identifies Cloudflare (quiche), Google GFE, Facebook (mvfst), Fastly (H2O), LiteSpeed (LSQUIC) via QUIC transport parameter signature analysis
• Alt-Svc analysis and 0-RTT replay attack risk assessment
• WebTransport capability testing with security validation on ports 443, 4433, or custom
• JA3/JA4 TLS fingerprinting with 3-tier confidence scoring and ML-enhanced recommendation engine

4.3 Five-Tier Grading System

The “C” grade is the most revealing result. A typical scenario: the CDN injects an Alt-Svc: h3=":443" header, but the origin server's firewall blocks UDP port 443. The browser attempts a QUIC connection, times out, falls back to TCP, and the user never knows. The Scanner reports the failure directly.

5. Tool 3: PQC Readiness Scanner

The PQC Readiness Scanner performs real-time TLS handshake analysis to detect whether a server supports NIST-standardized post-quantum cryptography algorithms. It is separate from the HTTP/3 Scanner — the HTTP/3 Scanner probes QUIC transport capabilities; the PQC Scanner probes cryptographic algorithm support at the TLS layer. A server can score “A++” on the HTTP/3 Scanner and “F” on the PQC Scanner, or vice versa. They measure different things.

5.1 How It Works

The Scanner performs an actual TLS 1.3 handshake with the target server and inspects the negotiated algorithms. It offers PQC key share groups in its ClientHello and observes whether the server selects them. If the server negotiates X25519MLKEM768, the Scanner detects ML-KEM support. If the server falls back to X25519, it records the absence of PQC. This is not a header check, certificate analysis, or DNS lookup — it is a real cryptographic exchange.

5.2 What It Detects

• ML-KEM-1024 (Kyber) and ML-DSA-87 (Dilithium) algorithm support — NIST FIPS 203/204 standardised algorithms
• Hybrid mode compatibility: X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024, X448MLKEM1024
• TLS version support: TLS 1.3 only versus TLS 1.2 fallback — critical for downgrade attack exposure assessment
• Quantum resistance assessment with detailed remediation recommendations tailored to the server’s current configuration

5.3 Three-Tier Grading System

5.4 Real-World Deployment Results (March 2026)

Fewer than 5% of scanned sites achieve the highest security posture. Government and intelligence agency sites — the organisations that should be leading PQC migration per NSA CNSA 2.0 mandates — overwhelmingly score “F.” Announcements are not deployments.

6. Tool 4: pqcrypta-proxy

The pqcrypta-proxy is an open-source, production-ready Rust reverse proxy. It is the infrastructure layer of the PQ Crypta ecosystem — the implementation that “walks the walk” after the diagnostic tools expose gaps. It is not a diagnostic tool; it is the fix.

6.1 Core Architecture

Built on the tokio asynchronous runtime, using the quinn crate for QUIC transport and h3 for HTTP/3 framing. Supports HTTP/1.1, HTTP/2, HTTP/3 (QUIC), and native WebTransport bidirectional streaming on a unified UDP listener. Domain-based routing maps incoming requests to backend services. Zero unsafe code in application logic.

6.2 Three TLS Modes

• Terminate — Decrypt at the proxy, forward plain HTTP to the backend. Standard reverse proxy behaviour.
• Re-encrypt — Decrypt at the proxy, re-encrypt with HTTPS to the backend. Supports mutual TLS (mTLS) for zero-trust architectures.
• Passthrough — SNI-based routing without decryption. The proxy reads the SNI from the TLS ClientHello and forwards the encrypted stream untouched. Zero visibility, zero overhead, zero certificate management at the proxy layer.

6.3 Post-Quantum TLS: X25519MLKEM768

The proxy implements hybrid PQC key exchange via OpenSSL 3.5+ with native ML-KEM support. The default algorithm is X25519MLKEM768 — the IETF hybrid combining classical X25519 with ML-KEM-768, providing NIST Level 3 security (192-bit equivalent). Algorithm negotiation is automatic: clients that support PQC negotiate PQC; clients without PQC support fall back to classical X25519 without service interruption. This is not bolted on — the proxy was designed PQC-first.

6.4 Security Features

• JA3/JA4 TLS fingerprinting: Extracts ClientHello signatures during handshake, enabling client identification even behind NAT and corporate proxies.
• Advanced multi-dimensional rate limiting: Composite keys combining IP address, JA3/JA4 fingerprint, URL path, JWT subject extraction, and X-Forwarded-For trust chains. IPv6 /64 subnet grouping prevents per-host evasion.
• Adaptive baseline anomaly detection: ML-inspired model that learns normal traffic patterns and flags statistical deviations with configurable standard deviation threshold.
• Circuit breaker: Backend health monitoring with automatic recovery. Configurable failure and success thresholds prevent cascading failures.
• WAF: Injection pattern detection covering SQLi, XSS, path traversal, SSRF, command injection (CMDi), and XXE.
• GeoIP blocking via MaxMind GeoLite2 for country-level access control.
• Security headers: HSTS, X-Frame-Options, CSP, COEP, COOP, CORP — configurable per domain.

6.5 Load Balancing

Six algorithms: least_connections (default), round_robin, weighted_round_robin, random, ip_hash, and least_response_time (exponential moving average tracking). Session affinity via cookie, IP hash, or custom header. Health-aware routing bypasses unhealthy backends. Slow start prevents overwhelming a recovering backend. Connection draining enables graceful maintenance.

6.6 HTTP/3 Advanced Features

• Early Hints (103): Preload CSS, JavaScript, and fonts via Link headers before the main response is ready.
• Priority Hints: RFC 9218 Extensible Priorities for HTTP/3 resource scheduling.
• Request coalescing: Deduplicates identical in-flight GET/HEAD requests.
• Alt-Svc advertisement: Automatic HTTP/3 upgrade headers on all ports.
• PROXY Protocol v2 for client IP preservation behind other load balancers.

6.7 Operations

Hot reload of configuration and TLS certificates without restart — no connection drops. ACME automation for Let’s Encrypt provisioning and renewal via HTTP-01 or DNS-01 challenges. OCSP stapling with caching. Prometheus metrics covering TLS handshake durations, connection counts, request rates, backend latencies, error rates, and PQC algorithm negotiation statistics. Admin API for health checks, configuration reload, and graceful shutdown. Runs on Linux, macOS, and Windows.

7. Post-Quantum Cryptography in Transport: Research Context

The integration of post-quantum cryptography into transport protocols is happening now. This section situates the academic research against what PQ Crypta’s tools measure and enforce. All cited papers have been verified against their published venues.

7.1 QUIC’s Cryptographic Architecture Advantage

QUIC’s mandatory TLS 1.3 makes PQC integration architecturally cleaner than TCP’s bolt-on TLS. In QUIC, TLS 1.3 is not optional — every connection uses it, fused with the transport handshake. When you replace X25519 with X25519MLKEM768, you change one configuration parameter; the handshake structure, packet format, and loss recovery all remain unchanged. In TCP, the TLS library, the TCP stack’s interaction with it, and the application configuration all require coordination.

7.2 Cryptographic Overhead: Verified Research Findings

8. Performance Formulas

The following formulas are the theoretical foundations behind what the Speed Test measures empirically. They are standard transport-layer performance models with notation aligned to PQ Crypta’s measurement methodology.

8.1 Bandwidth-Delay Product

The BDP determines optimal buffer and congestion window size. The Speed Test’s steady-state trimming (discarding the first 1.5–2 seconds) exists to let the congestion window grow to BDP before measurement begins.

8.2 TCP Throughput — Mathis Formula

TCP throughput degrades with the square root of loss rate. At 1% loss, throughput drops to roughly 12% of theoretical maximum. The Speed Test’s 200-datagram loss probing quantifies the “p” in this formula for the user’s actual connection.

8.3 QUIC Effective Goodput

Total_bytes includes: QUIC header (1–20 B) + AEAD tag (16 B) + UDP header (8 B) + IP header (20–40 B). On small packets (voice, gaming), the AEAD overhead is proportionally large. On large packets (bulk transfer), it is negligible — which is why the Speed Test’s bulk measurements operate in the large-packet regime.

8.4 PQC Handshake Overhead

For X25519MLKEM768 hybrid: T_keygen ≈ 0.02 ms, T_encaps ≈ 0.03 ms (combined classical + PQ). Total PQC overhead: ∼1–4 ms — negligible on most links. For SLH-DSA-256s: T_sign ≈ 50 ms, plus multi-packet fragmentation for the 29,792-byte signature. FALCON-512’s 666-byte signature fits in a single packet and avoids fragmentation entirely.

8.5 BBR Congestion Control

BBR probes bandwidth and RTT independently, unlike CUBIC which relies on loss signals to infer congestion. A lost packet on QUIC stream 5 does not trigger a congestion response that throttles streams 1–4. BBR’s model works naturally with QUIC’s multiplexed stream architecture.

9. What the Measurements Actually Show

9.1 Handshake Latency: QUIC Wins

TCP + TLS 1.3 requires a minimum of 2 RTT for connection establishment: one RTT for the TCP three-way handshake, one for the TLS handshake. QUIC 1-RTT combines transport and cryptographic handshakes into a single round trip. The Speed Test consistently shows QUIC RTT lower than TCP RTT — typically 5–15 ms on residential broadband.

With PQC (X25519MLKEM768), the handshake adds 1–4 ms of computational overhead. On a 25 ms RTT link this represents a 4–16% increase — measurable in a lab, unnoticeable to a user. On a 100 ms RTT intercontinental link, PQC overhead is 1–4% — noise.

9.2 Throughput: TCP Wins on Clean Links

TCP with kernel offloading approaches line rate on clean, low-loss links. Six parallel HTTP/1.1 streams with TSO/GSO doing the heavy lifting can saturate most residential connections. QUIC throughput is bounded by userspace crypto overhead.

9.3 The HTTP/3 Deployment Gap

Many CDN-fronted sites report HTTP/3 support via Alt-Svc headers in their HTTP/2 responses. Native QUIC probing with quinn/h3 reveals the reality: the CDN edge terminates QUIC, converts to TCP, and proxies to a TCP-only origin. The server “supports” HTTP/3 in the same way a person who hires a translator “speaks” Mandarin.

9.4 PQC Deployment Reality

The PQC Scanner’s data shows fewer than 5% of scanned sites achieve A+ (PQC with TLS 1.3 only). Major platforms — Google, Cloudflare, Baidu — show “A” grades: PQC is supported, but TLS 1.2 remains enabled as a fallback. This creates a downgrade attack surface: an active man-in-the-middle can strip the TLS 1.3 ClientHello extensions and force a TLS 1.2 connection, bypassing PQC entirely.

Government and institutional sites overwhelmingly score “F” — no PQC whatsoever. This includes fbi.gov and cia.gov, despite NSA CNSA 2.0 mandating PQC migration timelines. The gap between announced PQC readiness and actual deployment is as wide as the HTTP/3 gap. Policy has outrun deployment by years.

10. How the Tools Work Together

Although each tool is independent — separate codebases, separate URLs, separate purposes — they form a complementary diagnostic chain covering the full stack from transport performance to cryptographic readiness to infrastructure deployment:

• Speed Test answers: “What is the real-world performance difference between QUIC and TCP on my specific connection, right now?”
• HTTP/3 Scanner answers: “Does this target server actually implement QUIC at the transport layer, or is it claiming support it doesn’t have?”
• PQC Scanner answers: “Is this server’s cryptography quantum-resistant, and is the TLS 1.2 downgrade path closed?”
• pqcrypta-proxy answers: “Here is open-source infrastructure that implements all of the above natively, with production-grade operations.”

The tools are independently useful. A developer benchmarking their home network uses only the Speed Test. A security auditor assessing PQC readiness uses only the PQC Scanner. An infrastructure team evaluating HTTP/3 deployment uses only the HTTP/3 Scanner. A DevOps engineer deploying a reverse proxy uses only pqcrypta-proxy. Complementary value emerges when used together; no tool requires another to function.

11. Architectural Recommendations

Based on measurements from all four tools and the verified research literature, the following recommendations are ordered by impact:

1. Tune UDP buffer sizes immediately. Set net.core.rmem_max and net.core.wmem_max to at least 2.5 MB (10× the Linux default) for any QUIC deployment. This is the single highest-impact, lowest-effort QUIC performance optimisation. Failing to do this guarantees packet drops under load.
2. Deploy PQC now. X25519MLKEM768 hybrid key exchange adds 1–4 ms per handshake — negligible in practice. Waiting creates harvest-now-decrypt-later exposure. The pqcrypta-proxy provides a drop-in solution with automatic algorithm negotiation and classical fallback.
3. Measure at the transport layer, not the HTTP layer. Alt-Svc headers lie. Use native QUIC probing to verify actual protocol support. If you cannot complete a QUIC handshake with the server, the server does not support QUIC, regardless of what its HTTP headers claim.
4. Choose QUIC implementations carefully. The 50× throughput variance between implementations (90–4,900 Mbit/s on 10G links) [1] is the largest single QUIC performance variable. Quinn (Rust) and MsQuic (C) consistently benchmark at the top.
5. Expect TCP to win on raw throughput — and plan accordingly. Use QUIC where its architectural advantages matter: multiple concurrent streams, lossy links, mobile clients, and latency-sensitive applications.
6. Disable 0-RTT in security-sensitive deployments. The replay attack surface is real. 0-RTT data can be replayed by an attacker who captures the initial flight. For financial services, healthcare, and government applications, the latency savings do not justify the replay risk.
7. Enforce TLS 1.3-only on PQC deployments. The PQC Scanner shows that A vs A+ is the difference between having PQC and having PQC that cannot be downgrade-attacked. If you deploy PQC but leave TLS 1.2 enabled, an active attacker can force a downgrade and bypass your post-quantum protection entirely.

12. Conclusion

Four tools, four layers, one mission: expose the gap between what protocol specifications promise and what production deployments deliver.

The Speed Test proves QUIC’s latency advantage while honestly showing TCP’s throughput advantage on clean links. Both results are architecturally expected — QUIC saves round trips at handshake time but pays a per-packet userspace tax on bulk transfer. Neither result is a failure; they are the predictable consequences of where each protocol lives in the operating system.

The HTTP/3 Scanner reveals that most “HTTP/3 support” is CDN veneer over TCP-only origins. The “C” grade — servers claiming HTTP/3 but failing at the QUIC transport layer — is the most common surprising result. Real HTTP/3 deployment requires QUIC capability at the origin, not just at the CDN edge.

The PQC Readiness Scanner shows fewer than 5% of scanned sites are properly quantum-ready with TLS 1.3-only enforcement. Government agencies — the organisations most vocal about PQC migration — overwhelmingly score “F.” Policy has outrun deployment by years.

The pqcrypta-proxy provides the open-source infrastructure to close all three gaps simultaneously: native HTTP/3 and WebTransport, hybrid PQC TLS with X25519MLKEM768, and the operational features required for production deployment.

References

1. B. Jaeger, J. Zirngibl, M. Kempf, K. Ploch, and G. Carle, “QUIC on the Highway: Evaluating Performance on High-rate Links,” Proc. IFIP Networking Conference, Barcelona, June 2023. [Verified: IFIP Networking 2023 proceedings, dblp, arXiv:2309.16395]
2. M. Kempf, N. Gauder, B. Jaeger, J. Zirngibl, and G. Carle, “A Quantum of QUIC: Dissecting Cryptography with Post-Quantum Insights,” Proc. IFIP Networking Conference, 2024. [Verified: IFIP Networking 2024 proceedings, ResearchGate]
3. M. Raavi, S. Wuthier, P. Chandramouli, Y. Balytskyi, X. Zhou, and S. Y. Chang, “QUIC Protocol with Post-Quantum Authentication,” Proc. Information Security Conference (ISC), 2022. [Verified: ISC 2022, cited in Kempf et al. 2024]
4. J. Zheng, H. Xiao, and S. Xu, “Faster Post-Quantum TLS 1.3 Based on ML-KEM,” Proc. ESORICS, 2024. [Verified: ESORICS 2024 proceedings]
5. D. Gómez-Cambronero, D. Munteanu, and A. I. González-Tablas, “Layered Performance Analysis of TLS 1.3 Handshakes: Classical, Hybrid, and Pure Post-Quantum Key Exchange,” arXiv preprint, 2025. [Verified: arXiv preprint; venue unconfirmed as of March 2026]
6. IETF, “QUIC: A UDP-Based Multiplexed and Secure Transport,” RFC 9000, May 2021.
7. IETF, “Using TLS to Secure QUIC,” RFC 9001, May 2021.
8. IETF, “HTTP/3,” RFC 9114, June 2022.
9. IETF, “An Unreliable Datagram Extension to QUIC,” RFC 9221, March 2022.
10. W3C, “WebTransport Working Draft,” February 2026.
11. NIST, “FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM),” 2024.
12. NIST, “FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA),” 2024.
13. NIST, “FIPS 205: Stateless Hash-Based Digital Signature Standard (SLH-DSA),” 2024.

All external references verified March 2026. The Späth et al. ‘Kernel Bypass Surgery’ (IEEE/IFIP NOMS 2026) paper cited in a prior draft has been removed — it could not be located in any authoritative index including IEEE Xplore, arXiv, TUM mediaTUM, or author CVs.