Three Way Handshake

Overview

Definition

Three Way Handshake: TCP process to establish a reliable connection between client and server before data transfer.

Context in Transport Layer

Operates at transport layer (Layer 4), under TCP protocol. Ensures connection-oriented communication.

Historical Background

Introduced with TCP in early ARPANET. Designed to synchronize sequence numbers and acknowledge readiness.

General Mechanism

Exchange of SYN and ACK flags in three steps to establish connection parameters and synchronization.

Purpose and Importance

Connection Establishment

Ensures both ends agree on connection parameters before transmitting data.

Synchronization

Synchronizes initial sequence numbers to prevent data loss or duplication.

Reliability

Guarantees readiness of both parties, reducing connection errors.

Flow Control Preparation

Initializes parameters needed for flow and congestion control mechanisms.

Security Foundation

Helps prevent connection spoofing and certain DoS attacks by validating connection intent.

TCP Flags Involved

SYN (Synchronize)

Initiates a connection request and synchronizes sequence numbers.

ACK (Acknowledgment)

Confirms receipt of packets and synchronization of sequence numbers.

SYN-ACK Combination

Server response combining SYN and ACK flags to acknowledge client and request connection.

Flag Bit Positions

SYN = bit 1 (second least significant), ACK = bit 4 in TCP header flags field.

Detailed Steps

Step 1: SYN

Client sends TCP segment with SYN flag set, initial sequence number (ISN) chosen.

Step 2: SYN-ACK

Server replies with SYN-ACK, acknowledges client ISN + 1, sends its own ISN.

Step 3: ACK

Client sends ACK, acknowledges server ISN + 1, connection established.

Connection Established

Both sides enter ESTABLISHED state, ready for data transfer.

Diagrammatic Summary

Client Server | ----------- SYN(seq=x) ----------> | | <-------- SYN-ACK(seq=y, ack=x+1) - | | ----------- ACK(ack=y+1) ----------> | Connection Established

Sequence and Acknowledgment Numbers

Initial Sequence Number (ISN)

Randomly chosen 32-bit number to start byte stream sequencing.

Acknowledgment Number

Next expected sequence number, confirms receipt of previous segments.

Role in Handshake

Synchronizes ISNs to avoid overlap and data confusion.

Incrementing Sequence

SYN consumes one sequence number, hence ack = ISN + 1.

Example Values

TCP State Transitions

Client States

CLOSED → SYN-SENT → ESTABLISHED after handshake completion.

Server States

CLOSED → LISTEN → SYN-RECEIVED → ESTABLISHED after handshake completion.

State Diagram

Client: CLOSED --(SYN)--> SYN-SENT --(SYN-ACK)--> ESTABLISHEDServer: CLOSED --(listen)--> LISTEN --(SYN)--> SYN-RECEIVED --(ACK)--> ESTABLISHED

Implications

States ensure orderly connection setup and prevent half-open or invalid connections.

Timing and Timeouts

Retransmission Timeout (RTO)

Timeout awaiting handshake response triggers retransmission of SYN or SYN-ACK.

Exponential Backoff

Repeated timeouts cause RTO to double progressively to avoid network congestion.

Handshake Duration

Typically few milliseconds to seconds depending on network conditions.

Connection Failure

Handshake failure after multiple retries leads to connection abort.

Impact on Latency

Three step process adds initial delay before data transfer can begin.

Security Considerations

SYN Flood Attacks

Attackers send excessive SYN requests, exhausting server resources in SYN-RECEIVED state.

SYN Cookies

Technique to mitigate SYN flood by encoding state in TCP sequence number.

Connection Spoofing Prevention

Three way handshake validates client IP and port, reducing spoofing risk.

Man-in-the-Middle Risks

Handshake vulnerable to interception without encryption (e.g., TLS secures higher layers).

Firewall and IDS Role

Firewalls monitor handshake packets to detect anomalies and block attacks.

Common Issues and Failures

Half-Open Connections

Client or server fails to complete handshake, leaving connection in incomplete state.

Packet Loss

Lost SYN, SYN-ACK, or ACK packets cause retransmissions and delays.

Network Congestion

High latency and congestion increase handshake duration and failure probability.

Firewall Blocking

Improper firewall rules can block handshake packets, preventing connections.

Sequence Number Collisions

Rare, but reused ISNs can cause data confusion if handshake not properly synchronized.

Performance Impact

Connection Setup Delay

Three packet exchanges add latency before data transmission starts.

Resource Allocation

Server allocates buffers and memory upon SYN receipt, affecting scalability.

Throughput Implications

Handshake overhead negligible for long-lived connections; significant for short-lived.

Optimization Strategies

Use of TCP Fast Open, persistent connections to reduce handshake frequency.

Impact on Mobile Networks

Higher latency and packet loss exacerbate handshake delays and retransmissions.

Comparison with Other Protocols

UDP

Connectionless, no handshake, less overhead, but no reliability or ordering guarantees.

SCTP

Four-way handshake, supports multi-homing and multi-streaming, improved reliability.

QUIC

Built over UDP, uses 0-RTT handshake for faster connection establishment.

Impact on Application Design

Protocols with handshake favor reliability; others favor speed or simplicity.

Handshake Complexity

Practical Application in Networks

Web Browsing

HTTP over TCP uses handshake to establish reliable connections before data transfer.

Email Transmission

SMTP and IMAP rely on TCP handshake for session setup.

File Transfer Protocols

FTP and SFTP require connection establishment via handshake for secure, reliable transfer.

Network Diagnostics

TCP handshake used in tools like telnet and netcat for testing connectivity.

Load Balancers and Proxies

Track handshake to balance loads and manage sessions efficiently.

References

• W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols, Addison-Wesley, 1994, pp. 233-270.
• J. Postel, Transmission Control Protocol, RFC 793, 1981, pp. 1-85.
• Kevin Fall, W. Richard Stevens, TCP/IP Illustrated, Volume 2: The Implementation, Addison-Wesley, 1994, pp. 45-78.
• Mark Allman, Van Jacobson, Craig Leres, SYN Cookies, RFC 4987, 2007, pp. 1-7.
• Christian Huitema, TCP/IP Unleashed, Sams Publishing, 1998, pp. 150-180.