Why TCP’s Three‑Way Handshake and Four‑Way Teardown Matter for Reliable Networking
This article explains the OSI and TCP/IP layered models, details how data is encapsulated with headers at each layer, compares TCP and UDP, and walks through TCP’s three‑way handshake, four‑way termination, sequence numbers, flags, and common security considerations such as SYN flood attacks.
OSI Seven-Layer Model
OSI adopts a layered structure with seven layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application.
TCP/IP Model
The TCP/IP model, which is simpler and more practical, has four layers: Link, Network, Transport, and Application. The correspondence between the two models is shown below.
Each abstract layer builds on the services provided by the lower layer and offers services to the higher layer.
TCP/IP Protocol Suite
TCP/IP (Transmission Control Protocol/Internet Protocol) is the fundamental suite for the Internet, consisting of the IP protocol at the network layer and the TCP protocol at the transport layer. It is often used as a collective term for the protocols required for IP communication.
Data Encapsulation in TCP/IP Transmission
At each layer, a header is added to the data being sent. The header contains necessary information for that layer, such as destination address and protocol‑specific details. The header plus the payload from the upper layer together form the packet for the current layer.
A network packet therefore consists of two parts: the protocol header and the data passed down from the previous layer. The header’s structure is defined by the protocol specification and tells the receiver how to interpret the packet.
Processing steps:
Application layer performs encoding (similar to OSI’s Presentation layer) and manages connection establishment (similar to OSI’s Session layer).
TCP module adds a TCP header to the application data, establishing a reliable connection.
IP module adds an IP header to the TCP segment, forming an IP packet.
Network interface (Ethernet driver) adds an Ethernet header and transmits the frame over the physical layer.
Upon reception, the Ethernet driver strips the Ethernet header, determines the packet type, and forwards it to the appropriate module (e.g., IP, ARP).
IP module validates the destination IP, forwards the payload to the corresponding transport protocol (e.g., TCP, UDP).
TCP module verifies checksum, sequence order, and port number, then delivers data to the application.
Application receives and processes the data.
TCP and UDP
IP is the core protocol for routing packets. TCP and UDP are transport‑layer protocols that provide end‑to‑end communication between applications.
TCP offers reliable data transmission: it is connection‑oriented, establishes a link before sending data, and uses retransmission with acknowledgment to ensure reliability. It also employs a sliding‑window mechanism for flow control and includes congestion control algorithms (slow start, congestion avoidance, etc.).
UDP (User Datagram Protocol) sends data without establishing a connection or requiring acknowledgment, making it unreliable and prone to packet loss; applications must handle reliability themselves.
Note: Many common network applications are built on TCP and UDP, which in turn rely on IP. It is also possible to bypass the transport layer and use IP directly (e.g., Linux LVS) or communicate directly with the link layer (e.g., tcpdump).
Other protocol abbreviations:
ICMP – Internet Control Message Protocol
IGMP – Internet Group Management Protocol
ARP – Address Resolution Protocol
RARP – Reverse ARP
Detailed TCP Protocol Features
TCP is connection‑oriented; a link must be established before data transfer.
Once established, TCP provides bidirectional communication.
TCP transmits a byte stream, numbering each byte; the receiver acknowledges received bytes with ACK, ensuring ordered and complete delivery.
TCP implements flow control via a sliding window, dynamically adjusting the transmission rate based on the receiver’s capacity.
TCP includes congestion control (slow start, congestion avoidance, fast recovery, etc.) to prevent network overload.
Sequence and Acknowledgment Numbers
Sequence Number (seq): identifies each byte sent from the TCP source.
Acknowledgment Number (ACK): informs the sender which byte has been successfully received (seq + 1).
Flag bits:
TCP Three‑Way Handshake
To establish a reliable connection, TCP performs a three‑step handshake between a client (active initiator) and a server (passive responder).
First handshake: Client sends a SYN packet with an initial sequence number J and enters SYN_SENT state.
Second handshake: Server replies with SYN + ACK, acknowledges J + 1, chooses its own sequence number K, and enters SYN_RCVD state.
Third handshake: Client sends ACK acknowledging K + 1; both sides enter ESTABLISHED state and can exchange data.
Why Three Handshakes?
The three steps ensure both parties know each other’s initial sequence numbers, guaranteeing reliable data transfer while minimizing the number of exchanges.
SYN Flood Attack
Attackers exploit the second handshake by sending massive forged SYN packets with spoofed source IPs, causing the server to allocate resources for half‑open connections that never complete, leading to denial of service.
Mitigation methods include:
Firewalls that validate connection legitimacy before forwarding SYN packets.
Monitoring and releasing invalid connections.
Delaying TCB allocation until the handshake is completed.
Detailed TCP Four‑Way Termination
Connection termination involves four steps:
Client sends FIN, indicating no more data to send, and enters FIN_WAIT_1.
Server acknowledges with ACK and enters CLOSE_WAIT.
Server sends its own FIN after finishing pending data, entering LAST_ACK.
Client acknowledges with ACK, enters TIME_WAIT (waiting 2 MSL), then moves to CLOSED; server transitions directly to CLOSED after receiving ACK.
Waiting 2 MSL ensures the full‑duplex connection closes reliably and that delayed duplicate packets are discarded, preventing port reuse confusion.
Performance Considerations
Frequent handshakes can degrade performance; HTTP keep‑alive reuses existing connections to avoid repeated handshakes.
Common Issues
Large numbers of sockets in TIME_WAIT or CLOSE_WAIT can be mitigated by enabling tcp_tw_reuse and tcp_tw_recycle, or by fixing bugs that leave connections unclosed.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Architect's Guide
Dedicated to sharing programmer-architect skills—Java backend, system, microservice, and distributed architectures—to help you become a senior architect.
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.
