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.
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
Selected Java Interview Questions
A professional Java tech channel sharing common knowledge to help developers fill gaps. Follow us!
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.