Warm HTTPS vs a warm VPN: compare the same request path

You have probably read that HTTPS opens a new TCP connection and a fresh TLS handshake for every API request, so a tunnel that stays up for an hour looks cheaper. The first half of that is usually false. A supported client reuses an established connection for many exchanges, and a benchmark that builds a new client per call is measuring lifecycle rather than protection. The rest of this page is what to measure instead.

What reuse actually requires

Persistence is part of the HTTP model rather than a trick: one connection carries multiple request-response exchanges. The connection ends when either side closes it, when the server retires an idle or overloaded connection, or when a header or protocol rule says the connection cannot be reused. HTTPS layers that conversation inside TLS without demanding a new handshake for every exchange. So a second request does not repeat the first request's handshake unless something ended the connection in between.

Reuse also has one condition that applications break easily. A client that plans to reuse a connection must read the complete response body, and a response abandoned halfway through is the usual way pooling disappears without anyone noticing.

Check the library's supported client and connection-pool lifecycle instead of assuming pooling is on or off. Record the negotiated HTTP version too, because HTTP/2 and HTTP/3 handle connection reuse differently from HTTP/1.1. Treat the negotiated version as part of the measurement, not a footnote.

Why the comparison measures lifecycle

Creating a fresh client for every operation and comparing it with a tunnel that has been connected for an hour compares connection setup with steady state. That is a legitimate benchmark, and it is not HTTPS versus VPN. Two runs with the same client configuration describe the behaviour better than one, especially when the first run warms a resolver or connection cache.

Hold the API operation, the server, the account and the data constant, or the comparison carries more than one variable. Decide in advance where you place the timer, because setup, TLS negotiation, application execution and response delivery contribute differently to the total. A single first-request timer characterises setup and says nothing about the steady traffic you actually run. Write the timer boundaries down next to the numbers.

Separate cold setup from warm requests

Measure the first request separately from the ones that follow it. Then add what the service really sees: idle periods, bursts, concurrency, response size and reconnects.

Keep certificate validation and HTTPS enabled on both paths, because removing them measures a different security design rather than a faster one. If the tunnel changes the route or the gateway location, report that difference separately instead of attributing every timing change to encryption, since path, loss and queueing can dominate a small request. Run each path twice over the same route before drawing a conclusion. Record the negotiated protocol and the timer boundaries with both runs.

Plan for the connection that closes

Persistent does not mean permanent. A server, a proxy or a network change can close a connection during an idle period, and the client has to recover through its library's supported behaviour. That recovery has a state machine: the request may have completed on the server, or it may have failed before the server read it, and a closed socket does not tell the caller which happened. A non-idempotent operation in that position cannot simply be replayed, because a replay turns an unknown outcome into a duplicate write. This is where a warm tunnel and a warm connection behave alike, since both can fail at the moment work is in flight.

Use the service's documented retry or idempotency mechanism instead of a loop that reopens the socket. Test the recovery explicitly by closing an idle connection and watching what the client does next. Reopening a socket does not make repeating a state-changing call safe.

Choose the boundary first, then tune

Choose the network boundary from the access and trust requirements before optimising anything. A VPN protects the segment between its peers, while the application endpoints and any cleartext segment outside the tunnel still matter. Then tune the connection lifecycle inside that boundary. The cheaper-tunnel conclusion only follows from the belief that every request repeats the handshake, and that belief is the thing being tested here.

The persistence section of RFC 9112 is the reference for what reuse actually promises, including the conditions that end a connection. Read it once before trusting a benchmark that ignores them.