networkutils.org

Home / Network Tools / TCP Handshake

TCP Handshake

Network Tools

Connection setup timing split by SYN, ACK and first byte.

Run this tool: the interactive TCP Handshake loads here (requires JavaScript). Input: Host and port — e.g. example.org:443.

Description

The TCP Handshake tool measures the time breakdown of a full TCP connection setup — SYN, SYN-ACK and ACK — plus the time to first byte, so you can isolate where connection latency is introduced.

Features

✓ Split timing for SYN, SYN-ACK and final ACK
✓ Time-to-first-byte measurement after handshake
✓ IPv4 and IPv6 connection support
✓ Connection failure diagnostics

How to Use

Enter a host and port (for example example.org:443) and run the tool. The probe opens a TCP connection and records the timing of each handshake phase.

Input: Host and port — e.g. example.org:443.

Understanding the Results

The output shows the duration of the SYN send, the SYN-ACK wait (server processing), the final ACK, and the time to first byte of data. A long SYN-ACK wait points to server-side accept latency; a fast handshake but slow first byte points to application-layer processing delay.

Common Use Cases & Examples

→ Separate network latency from application latency for a slow API.

→ Measure TTFB of an origin server behind a CDN.

→ Diagnose connection-accept bottlenecks on a busy service.

→ Compare IPv4 vs IPv6 connection setup time.

Frequently Asked Questions

What is time to first byte (TTFB)?

TTFB is the time from the moment the TCP connection is established until the first byte of the response body arrives. It captures server-side and application processing time separately from network round-trips, making it a key origin-performance metric.

My handshake is fast but TTFB is slow — what does that mean?

The network path and TCP setup are healthy, but the application behind the port is slow to produce a response. Look at backend processing, database queries, or cold caches rather than the network.

Why would the SYN-ACK wait be long?

A long SYN-ACK wait usually means the server’s accept queue (backlog) is full or the listening process is overloaded and slow to accept new connections. It can also indicate deep packet inspection or a proxy adding delay.

About this tool

Maintained by
networkutils.org editorial team
Last updated
September 2026
Testing methodology
Probes run from the NetworkUtils.org server using Node.js standard networking libraries. Ping attempts an ICMP echo via the system ping utility and falls back to a TCP connect probe on port 80 when ICMP is unavailable in the probe environment; traceroute uses the system traceroute utility; the Port Check and TCP Handshake tools open real TCP connections to the specified port; the MTU Probe sends progressively larger packets with the Don’t-Fragment flag set.
Technical references
RFC 9293 — Transmission Control Protocol (TCP)