Secure Socket Tunneling Protocol (SSTP) remains a practical choice for organizations that require VPN connectivity that can traverse restrictive firewalls by encapsulating IP traffic over TLS on TCP port 443. However, because SSTP runs TLS over TCP, it has unique performance characteristics and trade-offs compared with UDP-based VPNs. This article provides a technically detailed approach to benchmarking SSTP speed and highlights the best tools and methodologies you can use to obtain repeatable, actionable results.

Why SSTP performance is different: protocol-level considerations

Before measuring performance, you must understand the architectural factors that influence SSTP throughput and latency:

  • TCP-over-TCP interaction: SSTP encapsulates a TCP stream inside another TCP connection (TLS/TCP). This can cause severe performance degradation under loss because both the inner and outer TCP layers perform congestion control and retransmission, leading to suboptimal throughput and head-of-line blocking.
  • TLS overhead and CPU load: SSTP uses TLS for transport security. The choice of cipher suite (AES-CBC vs AES-GCM), key exchange (RSA vs ECDHE), and whether hardware acceleration (AES-NI, Intel QAT) is available will significantly affect throughput, especially on high-bandwidth links.
  • MTU and fragmentation: Encapsulation increases packet size; if MTU is not adjusted, fragmentation will occur, degrading performance. Proper MSS clamping and MTU tuning are essential.
  • Latency sensitivity: Because SSTP runs over TCP, added latency can reduce the effective window size and lower throughput unless TCP window scaling and selective acknowledgements are properly supported and tuned.
  • Client and server implementation differences: The Windows SSTP client (built into Windows RAS), SoftEther, and various third-party implementations may differ in concurrency, threading, and TLS stack choices, so results can vary per implementation.

Benchmarking goals and metrics

Define what you want to measure before running tests. Typical goals include:

  • Maximum sustained throughput (upload and download).
  • Round-trip latency and jitter with and without VPN.
  • CPU utilization on client and server during transfer.
  • Packet loss and retransmission rates.
  • Impact of concurrent connections and real-world patterns (web, streaming, bulk transfer).
  • Effect of MTU/MSS changes and TLS cipher selection.

Important metrics to capture:

  • Throughput (Mbps) — both directions, measured over sustained intervals (30–120s).
  • RTT, jitter (ms) — use ICMP and tool-specific latency measures.
  • Packet loss (%) — small loss rates (0.1–1%) can disproportionately affect TCP-over-TCP.
  • CPU load (%) and context switching — to gauge encryption overhead.
  • Retransmits and duplicate ACKs — indicators of congestion and poor performance.
  • MTU fragmentation counts — if available from interface statistics or packet capture.

Testbed and methodology: how to get repeatable results

A controlled, repeatable environment is essential. Follow these guidelines:

  • Use identical hardware and software images for server and client when comparing configurations.
  • Isolate the test network from other traffic. If not possible, run multiple iterations at different times and report median and 95th-percentile results.
  • Test native (no-VPN) baseline first to establish the maximum achievable throughput and latency for your environment.
  • Run each test multiple times (minimum 3–5) and discard outliers. Use averages and percentiles.
  • Test in both directions (client-to-server, server-to-client). For asymmetric links, both directions matter.
  • Document software versions, cipher suites, TLS versions, CPU models, and OS tuning (e.g., TCP buffer sizes, net.ipv4.tcp_* settings on Linux).
  • Measure CPU and system metrics (top, htop, sar, perf) on both ends during tests.

Top tools for SSTP speed benchmarking

Combining several tools gives a comprehensive view. No single tool covers every need, so use complementary utilities for throughput, latency, packet-level analysis, and application-level simulation.

iPerf3 — Controlled TCP/UDP throughput tests

iPerf3 is the de-facto tool for measuring raw TCP and UDP throughput. It supports parallel streams, duration control, and reports bandwidth, jitter, and loss (for UDP).

  • Run server on the host behind the SSTP server or on the public-facing endpoint, depending on your test design.
  • For SSTP, run the iPerf3 client through the VPN tunnel. Use multiple parallel streams (e.g., -P 4 or 8) to saturate the path and expose CPU/TCP stack limits.
  • Use long test durations (60–120s) to capture steady-state behavior and avoid startup transients.
  • Record CPU usage concurrently — high CPU with low throughput indicates encryption bottleneck.

Ookla Speedtest CLI — realistic ISP-level tests

While not as reproducible as iPerf3, Ookla Speedtest CLI tests against public servers and simulates the kind of throughput users experience with real-world CDNs and websites.

  • Good for comparing perceived performance before and after SSTP enablement.
  • Provides latency and jitter metrics and is easy to script for multiple runs.

NDT (Network Diagnostic Tool) / ndt7

NDT provides deep diagnostics about throughput, bufferbloat-like behavior, and TCP stack interactions. The NDT server ecosystem includes servers at multiple institutions and can be used to analyze TCP behavior specifically on the path.

  • Useful for diagnosing TCP stack-level problems that significantly affect TCP-over-TCP VPNs.

Flent / Netperf / nuttcp — advanced networking tests

These tools provide advanced tests (concurrent flows, latency-throughput correlation, streaming tests). Flent is especially useful for aggregating multiple tests and generating plots.

  • Use Flent to run multi-flow scenarios and measure how throughput behaves under latency and packet-loss conditions.

Wireshark / tcpdump — packet-level inspection

To diagnose fragmentation, TCP retransmits, and TLS behavior, capture packets on both sides of the SSTP tunnel. Look for:

  • Repeated retransmissions and duplicate ACKs.
  • TLS handshake details (cipher suites, TLS version) visible if you control private keys or use server-side decrypted capture.
  • IP fragmentation and DF bit behavior.

mtr and hping3 — path diagnostics and synthetic loss

mtr combines traceroute and ping for hop-by-hop latency/loss. hping3 lets you craft TCP/UDP probes and simulate packet loss or smaller MSS to test how the SSTP session reacts under stress.

Practical tests to run

Design a test matrix that covers realistic and edge-case scenarios:

  • Baseline (no VPN) throughput and latency using iPerf3 and Speedtest CLI.
  • SSTP enabled, single-stream iPerf3 test (TCP) — measure impact of TCP-over-TCP.
  • SSTP enabled, multi-stream iPerf3 test — reveals how parallelism mitigates head-of-line blocking.
  • Vary TLS cipher suites (AES-GCM vs AES-CBC, ECDHE vs RSA) to measure CPU vs throughput trade-offs.
  • MTU/MSS tuning experiments — change MTU on client or server and observe fragmentation and throughput differences.
  • Introduce controlled packet loss/latency (tc on Linux, network emulator) to observe TCP-over-TCP behavior; compare to UDP-based VPN baseline.
  • Real-traffic tests: download/upload large files, stream video, and run multiple small-request workloads to capture application-level performance.

Interpreting results and optimization tips

When analyzing your results, keep these points in mind:

  • If throughput is well below baseline and CPU is high, prioritize TLS offload (AES-NI, hardware accelerators), use AES-GCM if supported, and consider upgrading CPU or using multi-core capable VPN server software.
  • If small loss rates cause disproportionate throughput collapse, test whether using more parallel streams improves effective throughput. Consider moving to a UDP-based VPN (WireGuard, OpenVPN UDP) if possible.
  • If fragmentation shows up in packet capture, reduce MTU or enable MSS clamping on the VPN server to avoid IP fragmentation.
  • For high-latency WANs, ensure TCP window scaling and SACK are enabled and consider TCP tuning (larger buffer sizes) on both ends.
  • When comparing implementations, keep TLS versions and ciphers consistent; differences in TLS stacks (SChannel vs OpenSSL) can create measurable differences.

Sample test script outline

A reproducible test script should:

  • Create baseline iPerf3 server on the target host (server-side): iperf3 -s
  • On client (through SSTP): sync clocks, run iPerf3 with -P for multiple streams and -t for duration, capture CPU stats and interface counters.
  • Save logs and pcap files for post-analysis; parse iPerf3 JSON output for automated reports.
  • Repeat for each TLS cipher setting and MTU configuration, and summarize median/95th-percentile results.

When SSTP is the right choice — and when to consider alternatives

SSTP is excellent where firewall traversal is critical and UDP cannot be relied upon. However, for high-performance wide-area links or when minimizing latency and loss sensitivity is critical, UDP-based VPNs (WireGuard, OpenVPN in UDP mode) often outperform SSTP because they avoid TCP-over-TCP issues and can use transport-level improvements. That said, with careful tuning (MSS clamping, TLS GCM, CPU offload) SSTP can still provide satisfactory performance for many enterprise use cases.

Clear benchmarking and documentation of test conditions are essential before concluding that SSTP is the bottleneck. Use the tools and methods above to build a comprehensive performance profile, then optimize TLS settings, MTU, and hardware accordingly.

For further resources and configuration examples targeted at enterprise deployments, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.