TCP handshake vs TLS handshake: what happens before opening an HTTPS website
Published on 2026-10-26 by frfrand
SYN sequence and TLS, and slow connection diagnostics
You open a website with HTTPS and it seems like the connection is instant. Behind it there are different steps: DNS, connection establishment, and encryption negotiation. Understanding them helps when the browser takes a long time before receiving the first byte.
The idea is to solve a data or deployment problem that appears in real applications. We will see the concept without detours, an implementation example, and what to check before taking it to production.
What TCP handshake and TLS handshake do
In classic TCP, SYN, SYN-ACK, and ACK are exchanged to establish a reliable flow. Then, in HTTPS over TCP, TLS negotiates cryptographic parameters and verifies the server's identity via certificates. HTTP/3 uses QUIC over UDP, so it does not follow exactly the same sequence.
It is not enough to repeat a recipe if you do not understand who reads the data, from which process, and with what permissions. In an application with reservations, invoices, or users, a race condition or a poorly designed access policy can be more serious than a slow API.
A concrete example
# Comprobar DNS
dig api.ejemplo.com A +short
# Ver tiempos de una petición
curl -s -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n' https://api.ejemplo.com/health
# Inspeccionar la cadena TLS
openssl s_client -connect api.ejemplo.com:443 -servername api.ejemplo.com </dev/nullThe names, tables, and keys in this example are illustrative. Try it first in a test database or environment and adapt permissions, indexes, and versions. When there are write operations, do not run sample queries on customer data without reviewing what they modify.
Step by step
- Measure how long it takes to resolve the domain.
- Measure the establishment of the TCP connection with a real request.
- Review TLS negotiation and validation without disabling certificate checks.
- Compare time to first byte and full response duration.
- Repeat the test from more than one network before attributing latency to the server.
In the end, don't settle for "the SQL didn't throw an error." Check the actual effect from the API and with concurrency or permission tests as appropriate. In databases, there are errors that only appear when two users do something at the same time.
Example work project
An API hosted in Europe has users in the Americas. The SQL query takes 15 ms, but creating each new connection adds network latency. Connection reuse and server region can matter more than optimizing another index.
That scenario helps distinguish performance from consistency. Speeding up a query is useless if it allows creating two reservations for a single seat, nor does a huge database fix the backend allowing querying another client's data.
The typical error
Don't confuse time_connect with total page time. Also, don't claim that every website uses TCP: HTTP/3 usually runs over QUIC/UDP and changes the observable phases.
It's also worth having a recovery plan. Before touching schema, users, or policies, save a verifiable copy or reversible migration and check that the application can keep running during the change.
How would you solve it with ArduMaker?
In ArduMaker you can choose the domain architecture, HTTPS, and processes of a VPS. Measuring the latency of each phase helps decide whether it is worth bringing infrastructure closer to users or reviewing the backend.
ArduMaker allows you to deploy services from Git and work with databases and processes within the VPS. The panel does not replace your application logic: transactions, permissions, and validations must be correctly designed in the code and the database.
Three checks before publishing
Integrity: if a request is repeated or fails halfway, do the data end up in a valid state?
Security: can an authenticated user access only their information, and does the API use a base identity with minimal permissions?
Recovery: do you know how to restore the data and revert the compatible code version if an update goes wrong?
If you can answer those three questions with tests, your backend is much better prepared than when you only checked if the endpoint returned 200.
Resources to learn more
To wrap up: choose the simplest solution that allows you to keep data correct, secure, and recoverable. Performance comes after measuring.