Fundamentals 19 min read

Why Does TCP Need a Three‑Way Handshake? A Deep Dive into Network Layers and Protocols

This article explains the fundamentals of computer network architecture, the purpose of layered protocols, compares the OSI and TCP/IP models, details each TCP/IP layer, and clarifies the three‑way handshake and four‑way termination processes with common interview questions.

ITPUB
ITPUB
ITPUB
Why Does TCP Need a Three‑Way Handshake? A Deep Dive into Network Layers and Protocols

Layered Network Architecture

Computer networking is built on a layered abstraction. Each layer offers a specific set of services and hides its internal details from the layers above and below, making complex protocols easier to design, implement, and maintain.

What Is a Network Protocol?

A network protocol is a formally defined set of rules that govern data format, transmission timing, acknowledgment, and error handling so that communicating hosts can exchange information reliably.

Why Use Layering?

Simplifies design by breaking a large problem into independent, manageable sub‑problems.

Provides flexibility: changes in one layer do not affect others as long as the defined interfaces remain unchanged.

Facilitates implementation, testing, and maintenance.

Enables standardisation; each layer can be specified and implemented independently.

Drawback: functionality may overlap across layers, introducing some overhead.

OSI vs. TCP/IP vs. Five‑Layer Model

TCP/IP (4 layers) : Application, Transport, Internet, Network Interface.

Five‑layer model (educational hybrid) : Application, Transport, Network, Data Link, Physical.

OSI (7 layers) : Application, Presentation, Session, Transport, Network, Data Link, Physical.

The five‑layer model is primarily a teaching tool; real Internet implementations use the four‑layer TCP/IP architecture.

TCP/IP Protocol Suite

Application Layer

Provides network services to end‑user applications. Common protocols include:

Domain Name System ( DNS) – name resolution.

HyperText Transfer Protocol ( HTTP) and its secure variant HTTPS – web traffic.

File Transfer Protocol ( FTP) – file exchange.

Simple Mail Transfer Protocol ( SMTP) – email sending.

Post Office Protocol v3 ( POP3) – email retrieval.

Telnet – remote terminal access (insecure).

Secure Shell ( SSH) – encrypted remote access.

Dynamic Host Configuration Protocol ( DHCP) – IP address assignment (runs over UDP).

Network Time Protocol ( NTP) – clock synchronization (UDP).

Bootstrap Protocol ( BOOTP) – diskless booting (UDP).

Application layer protocols diagram
Application layer protocols diagram

Transport Layer

Offers end‑to‑end data transport services between host processes.

TCP (Transmission Control Protocol) – connection‑oriented, reliable, byte‑stream service. Guarantees ordered delivery, retransmission of lost segments, flow control, and congestion control.

UDP (User Datagram Protocol) – connection‑less, best‑effort service. No reliability guarantees; suitable for latency‑sensitive applications such as DNS, VoIP, and streaming.

Typical application‑layer protocols and the transport they use:

TCP‑based: HTTP, HTTPS, FTP, POP3, SMTP, Telnet, SSH.

UDP‑based: BOOTP, NTP, DHCP.

Both TCP and UDP: DNS (uses UDP for queries, TCP for zone transfers).

Network Layer

Responsible for routing packets across heterogeneous networks. In the TCP/IP suite the layer implements the Internet Protocol ( IP), so packets are called IP datagrams. The layer selects the best path, performs fragmentation/reassembly, and adds source/destination IP addresses.

Data Link Layer

Encapsulates IP datagrams into frames for transmission over a physical link. Frames contain MAC addresses, error‑checking codes (e.g., CRC), and synchronization bits. The layer also handles link‑level flow control and retransmission on some technologies (e.g., Ethernet).

Physical Layer

Transmits raw bits over the physical medium (copper, fiber, wireless). It defines voltage levels, timing, connector types, and modulation schemes, abstracting the hardware details from upper layers.

TCP Connection Mechanics

Three‑Way Handshake

Establishes a reliable connection by exchanging sequence numbers and confirming bidirectional communication.

Client → Server: SYN with initial sequence number ISN_c.

Server → Client: SYN‑ACK with its own initial sequence number ISN_s and acknowledgment ACK = ISN_c + 1.

Client → Server: ACK with acknowledgment ACK = ISN_s + 1. After this step both sides consider the connection established.

Three‑way handshake diagram
Three‑way handshake diagram

Four‑Way Termination

Closes a TCP connection gracefully, ensuring that all pending data are delivered.

Client → Server: FIN (no more data from client). Sequence number = last_sent + 1.

Server → Client: ACK acknowledging the FIN ( ACK = FIN_seq + 1).

Server → Client: FIN after it has sent any remaining data.

Client → Server: ACK acknowledging the server’s FIN. The client then waits for 2 MSL (twice the maximum segment lifetime) before fully closing its side; the server can close immediately after receiving this ACK.

Four‑way termination diagram
Four‑way termination diagram

TCP Header Overview

The TCP segment header (32‑bit fields unless otherwise noted) contains the following essential fields:

Sequence Number (seq) – 32‑bit number identifying the first byte of data in this segment.

Acknowledgment Number (ack) – valid only when the ACK flag is set; indicates the next expected byte ( ack = received_seq + 1).

Flags – six control bits: SYN: initiate a new connection. ACK: acknowledgment field is valid. FIN: request graceful connection termination. RST: abort the connection. PSH: push data to the receiving application immediately. URG: urgent pointer field is valid.

TCP header diagram
TCP header diagram

Common Interview Questions (Technical Focus)

Why three‑way handshake? It protects against lost packets during connection setup. With only two messages, a lost second message would leave the client unaware that the server is ready, preventing data exchange. The third message confirms bidirectional readiness.

Why four steps to close? Both endpoints must finish sending data. The client’s FIN only signals its own completion; the server must acknowledge, finish its own transmission, then send its own FIN, resulting in an extra round‑trip.

Why wait 2 MSL after the final ACK? To ensure that any delayed duplicate FIN or ACK packets are discarded, preventing a stray packet from being interpreted as a new connection request.

What happens if a client crashes after a connection is established? TCP uses a keep‑alive timer (commonly 2 hours). If no traffic is seen, the server sends keep‑alive probes every 75 seconds; after ten unanswered probes the server assumes the client has failed and closes the connection.

TCP connection lifecycle diagram
TCP connection lifecycle diagram
Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

TCP/IPNetworkingOSI modelHandshakeProtocol Layers
ITPUB
Written by

ITPUB

Official ITPUB account sharing technical insights, community news, and exciting events.

0 followers
Reader feedback

How this landed with the community

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.