Visualize the SSL/TLS handshake process as a timeline
Handshake Timeline
About TLS Handshake Timeline
Visualizes TLS handshake timing breakdown showing DNS lookup, TCP connection, TLS negotiation, and data transfer phases. Identifies performance bottlenecks in the connection process.
How to Use
1Enter the domain name and optional port number.
2Click "Get Timeline" to capture the handshake timing breakdown.
3Review each phase of the handshake with timing details and descriptions.
Use Cases
•Performance optimization by identifying slow handshake phases
•Latency debugging for TLS connection establishment issues
•SLA monitoring to ensure handshake times meet performance targets
Frequently Asked Questions
The four phases of a new connection: resolving the name, establishing the TCP connection, completing the TLS negotiation, and the first exchange of application data. Each is timed separately because they have different causes and different fixes. DNS belongs to your resolver and the network path, TCP to the distance and any device in between, TLS to the server's configuration and key sizes, and the first data to the server's actual work. Adding them up gives the time to first byte that a visitor experiences.
High latency multiplies every round trip, so a client far from the server pays for it most, which is why the difference between regions is often dramatic. Deep certificate chains add round trips of their own, since each signature must be verified in sequence. A server fetching revocation status during the handshake instead of stapling it adds a full network round trip to a third party, which is one of the most common avoidable causes. Beyond that it is ordinary server-side processing under load.
Enable TLS 1.3, which completes in one round trip instead of two and in some configurations in none at all for a resumed session. Staple OCSP so the server supplies the revocation answer rather than making the client fetch it. Enable session resumption, including session tickets, so returning visitors skip the full handshake entirely. Reducing chain depth helps a little on TLS 1.2. Measure again afterwards, since the relative cost of each depends on latency more than on anything you change.
Because in most configurations neither side will commit to anything before hearing from the other. The client offers, the server chooses, then keys are exchanged and confirmed — and each step needs the previous one answered. TLS 1.3 reduced this by moving most of the key exchange into the first flight, which is why enabling it is the most effective single handshake improvement available.
The ClientHello, because everything after it depends on what the client offered. If the offered cipher suites, key exchange groups or signature algorithms do not intersect what the server accepts, there is no valid continuation and the handshake fails before the certificate is even sent. Diagnosing it means comparing the two lists rather than reading the error, which is what the client-hello page helps with.
On TLS 1.3 it removes almost everything, since a resumed handshake is essentially one round trip against two for a full one. That is a larger saving than any cipher optimisation and it carries no replay exposure. It is also why resumption should be prioritised over 0-RTT for most deployments: same round-trip saving, no security caveat.
No, and the breakdown is worth reading before optimising anything. Network distance sets a floor that no setting can beat, and on a distant server most of the time is round-trip latency rather than computation. Compare with the performance monitor, which separates DNS, TCP and TLS, to see where the time actually goes before deciding any of it is yours to fix.
The sequence and its cost. A test tells you whether a connection succeeds; the timeline tells you how many round trips it took and what each was for, which is what makes an improvement identifiable. That matters when you have several possible changes available — resumption, a protocol upgrade, a cipher change — and need to know which one actually reduced the round trips.
What The Timeline Shows
A TLS handshake is a sequence of round trips, and each message has a purpose. This page narrates the sequence with real timings from one live connection.
1ClientHello opens it, offering protocol versions, cipher suites, key exchange groups and extensions. Its size and content determine what can be negotiated at all — an empty intersection here is why handshakes fail.
2ServerHello and the rest follow: the server's selection, then the key exchange and certificate, then the change cipher spec and finished messages that confirm both ends computed the same keys. Every one of these is a round trip unless the protocol removed it.
3Session resumption is the shortcut, collapsing the middle of that sequence on a repeat connection. This is why resumption is the single largest handshake saving available and why it carries no replay risk, unlike 0-RTT.
The timing here is from one connection at one moment, so treat the figures as one sample. Protocol version is the main determinant of round-trip count: 1.3 in one, 1.2 in two for a full handshake, one for a resumption.
Tips & Best Practices
•Analyze handshake timelines to identify performance bottlenecks
•Compare timelines across different cipher suites and protocols
•Use timeline analysis to optimize TLS handshake configuration
•Monitor timeline changes after server configuration updates
Technical Details
Phases: ClientHello, ServerHello, Certificate, Key Exchange, Finished Timing: Microsecond-level timing for each handshake phase Analysis: Bottleneck identification and optimization recommendations Visualization: Timeline diagram showing handshake progression
