Fundamentals 28 min read

Comprehensive Guide to TCP: Differences with UDP, Handshakes, Termination, SYN Flood, Fast Open, Timestamps, RTO, Flow & Congestion Control, Nagle, Delayed ACK and Keep‑Alive

This article provides an in‑depth overview of TCP, explaining its core differences from UDP, the three‑way handshake and four‑way termination processes, half‑open queues and SYN‑Flood attacks, Fast Open, timestamp usage, retransmission timeout calculation, flow and congestion control mechanisms, as well as Nagle’s algorithm, delayed acknowledgments and TCP keep‑alive.

Selected Java Interview Questions
Selected Java Interview Questions
Selected Java Interview Questions
Comprehensive Guide to TCP: Differences with UDP, Handshakes, Termination, SYN Flood, Fast Open, Timestamps, RTO, Flow & Congestion Control, Nagle, Delayed ACK and Keep‑Alive

The article presents a comprehensive overview of the TCP transport‑layer protocol, covering its fundamental concepts, mechanisms, and security considerations.

001. Difference between TCP and UDP

TCP is a connection‑oriented, reliable, byte‑stream protocol, whereas UDP is connection‑less. Compared with UDP, TCP provides three core properties:

Connection‑oriented : a three‑way handshake establishes a client‑server connection before data exchange.

Reliability : TCP tracks sent and received data, ensures ordered delivery, and can retransmit lost packets (stateful and controllable).

Byte‑stream : TCP treats data as a continuous stream of bytes, unlike UDP’s datagram model.

002. TCP three‑way handshake

Analogy with a romantic relationship

The handshake is illustrated with a love‑story analogy: the first SYN is "I love you", the SYN‑ACK is "I received your love and love you back", and the final ACK confirms mutual love, establishing a reliable connection.

Actual handshake

Both sides start in CLOSED . The server moves to LISTEN , the client sends SYN and enters SYN‑SENT . The server replies with SYN + ACK and enters SYN‑RECEIVED . The client then sends ACK , moving both ends to ESTABLISHED . The article notes that SYN consumes a sequence number, while ACK does not.

Why not two or four handshakes?

Two handshakes cannot guarantee the client’s receive capability, leading to resource waste if delayed packets arrive after the connection is closed. Four handshakes add unnecessary latency without benefit.

Can data be carried during the handshake?

Only the third handshake may carry data; the first two must remain empty to avoid amplification attacks.

Simultaneous open

If both sides send SYN simultaneously, each enters SYN‑SENT , then upon receiving the peer’s SYN they move to SYN‑RECEIVED , exchange ACK+SYN , and finally reach ESTABLISHED . The state diagram is shown with an image.

003. TCP four‑way termination

The termination process starts from ESTABLISHED . The client sends FIN (entering FIN‑WAIT‑1 and half‑close), the server acknowledges ( CLOSED‑WAIT ), the client moves to FIN‑WAIT‑2 , the server sends its own FIN ( LAST‑ACK ), and the client finally reaches TIME‑WAIT before closing. The article explains the need to wait for 2 MSL to avoid stray packets.

004. Half‑open queue and SYN‑Flood attack

Before the handshake, the server creates a SYN (half‑open) queue and an ACCEPT (full‑open) queue. A SYN‑Flood attack floods the server with forged SYN packets, filling the half‑open queue and exhausting resources. Mitigations include enlarging the SYN queue, reducing SYN‑ACK retries, and using SYN cookies.

005. TCP header fields

The header includes source/destination ports, sequence number, ISN, acknowledgment number, flags (SYN, ACK, FIN, RST, PSH), window size (with scaling), checksum, and optional fields such as Timestamp, MSS, SACK, and Window Scale. Images illustrate the layout.

006. TCP Fast Open (TFO)

TFO reduces latency by embedding a SYN cookie in the initial SYN ‑ACK exchange. The client caches the cookie and can send data (e.g., an HTTP request) together with the subsequent SYN , allowing the server to respond before the three‑way handshake completes.

007. TCP timestamp option

The 10‑byte option contains a timestamp and timestamp echo . It enables accurate RTT measurement (by recording send and echo times) and prevents sequence‑number wrap‑around ambiguity.

008. Retransmission timeout (RTO) calculation

Two methods are described:

Classic method : smooth RTT with SRTT = α·SRTT + (1‑α)·RTT (α≈0.8‑0.9) and compute RTO = β·SRTT bounded by lower and upper limits.

Standard (Jacobson/Karels) method : update SRTT with α=1/8, compute RTT variance RTTVAR with β=0.25, then RTO = μ·SRTT + δ·RTTVAR (μ=1, δ=4).

009. TCP flow control

Flow control uses the receiver’s advertised window to limit the sender’s transmission. The article explains the sliding‑window mechanism for both sending and receiving sides, showing diagrams of window regions and how ACKs shrink the window when the receiver’s buffer fills.

010. TCP congestion control

Congestion control maintains cwnd and ssthresh . It consists of:

Slow start : cwnd doubles each RTT until reaching ssthresh .

Congestion avoidance : cwnd grows by 1/cwnd per ACK (approximately one MSS per RTT).

Fast retransmit & fast recovery : three duplicate ACKs trigger immediate retransmission and halve ssthresh , set cwnd to ssthresh , then increase linearly.

011. Nagle algorithm and delayed ACK

Nagle coalesces small segments: after the first small packet, subsequent data is sent only when a full MSS is accumulated or all previous packets are ACKed. Delayed ACK postpones ACK transmission (≤500 ms) to combine acknowledgments, improving efficiency but may increase latency when both mechanisms are active.

012. TCP keep‑alive

Keep‑alive probes detect dead connections by periodically sending empty packets (default 7200 s interval, 9 probes, 75 s between probes on Linux). Many applications disable it because the interval is too long to be useful for most scenarios.

Source: juejin.im/post/5e527c58e51d4526c654bf41

TCPsecuritynetworkingProtocolcongestion controlhandshake
Selected Java Interview Questions
Written by

Selected Java Interview Questions

A professional Java tech channel sharing common knowledge to help developers fill gaps. Follow us!

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.