TCP 3-Way Handshake & TLS 1.3 Protocol Visualizer
Simulate packet round-trips from SYN/ACK to encrypted TLS 1.3 records. Interactive packet inspection of the TCP 3-way handshake and TLS 1.3 cryptographic key exchange, illustrating how modern zero-RTT connection resumption reduces network latency.
TCP 3-Way & TLS 1.3 Handshake Simulator
Step-by-step state machine showing sequence synchronization and Diffie-Hellman cryptographic exchange.
MSS=1460, SACK_PERM, WS=1281. TCP SYN (Synchronize)
Client picks Initial Sequence Number (ISN=1000) and sends SYN packet over raw network.
How It Works Under the Hood
Before a client can send an encrypted HTTPS request, it must establish a reliable transport layer connection (TCP) and negotiate cryptographic session keys (TLS). In legacy TLS 1.2, establishing an HTTPS connection required 3 network round-trips (RTTs): 1 RTT for the TCP SYN/SYN-ACK handshake, followed by 2 RTTs for TLS cipher negotiation and certificate validation. TLS 1.3 overhauled this process, combining the Diffie-Hellman key share directly inside the ClientHello packet. This reduced the cryptographic handshake to a single round-trip (1-RTT), and enabled 0-RTT resumption for returning clients.
Core Architectural Principles
- TCP 3-Way Handshake: SYN -> SYN-ACK -> ACK establishes sequence numbers and window sizing.
- TLS 1.3 1-RTT: ClientHello includes supported ciphers and ephemeral key shares simultaneously.
- 0-RTT Early Data: Returning clients can transmit encrypted application data in the very first flight using pre-shared keys (with replay mitigation).
Highlight connection initiation latency in system design rounds. Explain why Edge CDNs are critical: by terminating TCP and TLS handshakes at nearby Point of Presence (PoP) edge nodes, mobile users complete handshakes in ~10ms instead of ~150ms back to the origin datacenter.
0-RTT connection speed vs replay attack vulnerability on non-idempotent HTTP POST requests.