Imagine sending a letter to your friend, but there is no postal system, no delivery confirmation, no guarantee it will arrive or not. Multiple copies might show up, pages could arrive out of order or the letter might vanished entirely. You would have no idea if your friend received it, and they'd have no way to tell you they got it. But why i am saying you this ???
Because this is exactly what happens when data travels across the networks without rules. Packets get lost in the digital void. They arrived jumbled, duplicated or corrupted. There is no handshake 🤝, no reliability. Just chaos.
Now enter the world of TCP ( the protocol that brought order to this chaos )
In this comprehensive guide, we'll explore TCP (Transmission Control Protocol) from the ground up. We'll understand why it exists, how the famous three-way handshake works, how it ensures every byte reaches its destination, and how connections gracefully close. Whether you're a beginner taking your first steps into networking or an experienced developer seeking deeper understanding, this article will give you the complete picture.
Quick Refresher: where does TCP fit ?
Before diving into TCP it is most important to understand the OSI model.
OSI model is vast topic on it's own so,
OSI model (in one line): The OSI model is a conceptual framework that standardizes network communication into seven logical layers to clarify how data moves from one system to another.
My honest advice is to please visit this Cloudflare article on What is the OSI model ? before reading this article and after reading this article you can visit this article written by me on Understanding OSI model and how it align with TCP/IP
In this article i will give you the glimpse of OSI model and will tell you that how TCP align with these 7 layers of OSI model in 4 layers.
You've probably heard the term "TCP/IP" used together so often that they seem inseparable. But why?
TCP and IP are different protocols that work at different layers, but they're deeply integrated:
IP (Internet Protocol) works at the Network Layer. It handles addressing and routing - getting packets from one computer to another across networks using IP addresses.
TCP (Transmission Control Protocol) works at the Transport Layer. It handles reliable delivery -making sure data arrives complete, in order, and error-free.
It is something like a delivery service:
IP is the postal system that figures out routes and delivers packages to addresses
TCP is the tracking system that ensures packages arrive safely, in order, with signatures confirming delivery
They work together so closely that the internet is fundamentally built on this combination, hence "TCP/IP." TCP relies on IP to move packets, and IP benefits from TCP's reliability mechanisms for applications that need guaranteed delivery.
Now that we've positioned TCP in the networking landscape, let's understand what makes it so essential.
What is TCP and Why is it needed ?
TCP (Transmission Control Protocol) is a connection-oriented, reliable transport layer protocol that ensures data is delivered accurately, in order, and without errors between applications running on different devices.
It is developed by Vent Cerf who is an American Internet pioneer and is recognized as one of "the fathers of the Internet", and Rob kahn who is an American electrical engineer.
If you know the OSI model, it has 7 layers. You can see in the below diagram
TCP operates at:
- Layer 4 (Transport Layer) in the OSI model
Diagram below 👇
I think we grasp a lot, now it's time to break down the TCP:
Connection-oriented: Before sending data, TCP establishes a connection between sender and receiver (like calling someone before having a conversation)
Reliable: TCP guarantees that data will arrive or you'll be notified if it can't
Transport layer: It operates between applications and the network, managing end-to-end communication
Ordered delivery: Data arrives in the same sequence it was sent
Error-checked: Corrupted data is detected and retransmitted
What Problems TCP was designed to solve ?
When TCP was first specified in RFC 793 in 1981 (building on earlier work by Vint Cerf and Bob Kahn), it was designed to solve fundamental problems in network communication:
-
Unreliable delivery
Networks are naturally unreliable. Data packets can be lost because of traffic overload, hardware problems, or routing errors. Without TCP, applications would have to handle reliability on their own.
-
Out-of-Order Delivery
Packets traveling across the internet can take different routes and arrive in different orders. TCP ensures they're reassembled correctly.
-
Duplicate Packets
Network glitches can cause the same packet to be delivered multiple times. TCP detects and discards duplicates.
-
Data Corruption
Bits can flip during transmission due to electrical interference or faulty hardware. TCP detects corrupted data.
-
Flow Control
A fast sender can overwhelm a slow receiver. TCP manages the rate of data transmission to prevent this.
-
Congestion Control
Too much traffic can congest networks. TCP adjusts transmission rates to prevent network collapse.
The TCP Three-Way Handshake: Establishing Connection
The three-way handshake is TCP's most famous feature. It's the process that establishes a connection before any data is transmitted. Think of it as two people meeting and agreeing to have a conversation before they start talking.
Why a Handshake?
Before data flows, both sides need to:
Agree to communicate (establish connection)
Synchronize sequence numbers (know where to start counting data)
Exchange parameters (window sizes, maximum segment sizes)
Verify both can send and receive (bidirectional communication test)
I know it is bit confusing, let’s understand it with the conversational analogy
The Conversation Analogy
Imagine you're calling a friend:
You: "Hello, can you hear me?" (SYN)
Friend: "Yes, I hear you! Can you hear me?" (SYN-ACK)
You: "Yes, I can hear you too. Let's talk!" (ACK)
Only after this exchange do you start your actual conversation. The TCP handshake works the same way.
See image below of TCP - Three way Handshake
Above diagram explanation:
Step 1: SYN (Synchronize)
The client initiates the connection by sending a SYN segment to the server.
What happens:
Client picks a random initial sequence number (ISN), let's say 1000
Client sends a segment with the SYN flag set
Client enters the SYN-SENT state
Why a random sequence number? Security and uniqueness. If sequence numbers were predictable, attackers could inject fake packets. Random ISNs make this much harder.
Message: "Hello server, I want to connect. My starting sequence number is 1000."
Step 2: SYN-ACK (Synchronize-Acknowledge)
The server receives the SYN and responds with its own SYN and an acknowledgment of the client's SYN.
What happens:
Server picks its own random ISN, let's say 5000
Server sends a segment with both SYN and ACK flags set
Server acknowledges the client's sequence number by sending ACK = 1001 (client's ISN + 1)
Server enters the SYN-RECEIVED state
Message: "Hello client, I received your request (ACK 1001). I'm ready to connect too. My starting sequence number is 5000."
Step 3: ACK (Acknowledge)
The client acknowledges the server's SYN.
What happens:
Client sends a segment with the ACK flag set
Client acknowledges server's sequence number by sending ACK = 5001 (server's ISN + 1)
Both client and server enter the ESTABLISHED state
Connection is now open and ready for data transfer
Message: "Got it, server (ACK 5001). We're connected. Let's exchange data!"
Why Three Steps? Why Not Two or Four?
Why not two steps? With just two steps (SYN, SYN-ACK), the client wouldn't confirm receipt of the server's SYN-ACK. The server wouldn't know if the client is ready to receive data. Also, it wouldn't prevent old duplicate SYNs from creating phantom connections.
Why not four steps? Three is the minimum needed to:
Verify both sides can send
Verify both sides can receive
Synchronize both sequence numbers
Confirm mutual readiness
It's the optimal balance between reliability and efficiency.
Connection States During Handshake
Both client and server go through state transitions:
Client states:
CLOSED (initial state)
SYN-SENT (after sending SYN)
ESTABLISHED (after receiving SYN-ACK and sending ACK)
Server states:
LISTEN (waiting for connections)
SYN-RECEIVED (after receiving SYN and sending SYN-ACK)
ESTABLISHED (after receiving final ACK)
What Can Go Wrong?
SYN Flooding Attack: Attackers send many SYN packets but never complete the handshake, exhausting server resources. Servers use SYN cookies and other techniques to mitigate this.
Network Failures: If any step fails (packet loss), TCP will retry. If the handshake can't complete, the connection attempt times out.
The Curious part: How Data Transfer Works in TCP
Once the connection is established, the real work begins: transferring data reliably.
Sequence Numbers: Tracking Every Byte
Remember those initial sequence numbers from the handshake? They weren't just for show. Every byte of data sent over TCP is numbered sequentially.
Example:
Client's ISN: 1000
Client sends 100 bytes of data
Sequence number in the segment: 1001 (starting point)
Next segment will start at: 1101 (1001 + 100)
Think of sequence numbers as page numbers in a book. Even if pages arrive out of order, you can reassemble them correctly.
Acknowledgment Numbers: Confirming Receipt
When the receiver gets data, it sends back an acknowledgment (ACK) telling the sender what it expects next.
How it works:
Server receives bytes 1001-1100
Server sends ACK = 1101
This means: "I received everything up to byte 1100. Send me byte 1101 next."
The acknowledgment number is always the next expected byte, not the last received byte.
Bidirectional Communication
TCP is full-duplex, meaning both sides can send and receive simultaneously. Each direction maintains its own sequence numbers.
Example exchange:
Client → Server: SEQ=1001, 100 bytes of data
Server → Client: ACK=1101 (confirming client's data)
Server → Client: SEQ=5001, 200 bytes of data
Client → Server: ACK=5201 (confirming server's data)
Client → Server: SEQ=1101, 50 bytes of data
Server → Client: ACK=1151
Both conversations happen independently but simultaneously.
Window Size: Flow Control
The receiver tells the sender how much data it can accept using the window size field.
Example:
Server advertises window size: 4096 bytes
Client can send up to 4096 bytes before needing an ACK
If server's buffer fills, it advertises a smaller window (or zero)
Client slows down or pauses
This prevents a fast sender from overwhelming a slow receiver - a critical form of flow control.
How TCP Ensures Reliability, Order, and Correctness
TCP's reliability isn't magic. It's a carefully orchestrated system of mechanisms working together.
1. Sequence Numbers: Ensuring Order
Even if packets arrive scrambled, TCP reassembles them correctly using sequence numbers.
Scenario:
Sent order: Packet A (bytes 1-100), Packet B (bytes 101-200), Packet C (bytes 201-300)
Arrived order: Packet B, Packet C, Packet A
TCP reassembles: Packet A → Packet B → Packet C (correct order)
The receiving TCP buffer holds out-of-order data until gaps are filled.
2. Acknowledgments: Confirming Delivery
Every segment needs acknowledgment. If the sender doesn't receive an ACK within a timeout period, it knows something went wrong.
Cumulative Acknowledgments: TCP often uses cumulative ACKs. If you send packets 1, 2, 3, 4, and the receiver sends ACK for packet 4, it implicitly acknowledges packets 1, 2, and 3 as well.
Selective Acknowledgments (SACK): Modern TCP implementations support SACK, allowing receivers to acknowledge non-contiguous blocks of data. This makes recovery from multiple packet losses more efficient.
3. Retransmission: Recovering from Loss
When TCP detects loss, it retransmits the missing data.
Two ways TCP detects loss:
a) Timeout-Based Retransmission
Sender starts a timer when sending data
If ACK doesn't arrive before timeout, assume packet was lost
Retransmit the data
The timeout is adaptive:
TCP measures Round-Trip Time (RTT)
Timeout is set based on RTT (typically RTT + variance buffer)
If the network is slow, timeout is longer; if fast, timeout is shorter
b) Fast Retransmit (Duplicate ACKs)
If receiver gets packet 3, 5, 6 (missing 4), it sends ACK for packet 3 repeatedly
When sender receives three duplicate ACKs, it assumes packet 4 is lost
Sender immediately retransmits packet 4 without waiting for timeout
This is called fast retransmit and significantly improves performance.
4. Checksums: Detecting Corruption
Each TCP segment includes a checksum covering:
TCP header
Data
Parts of the IP header (pseudo-header)
How it works:
Sender calculates checksum and includes it in the segment
Receiver recalculates checksum
If checksums don't match, data was corrupted
Receiver discards the segment (doesn't ACK it)
Sender eventually retransmits due to missing ACK
5. Congestion Control: Preventing Network Collapse
TCP doesn't just consider the receiver's capacity (flow control) but also the network's capacity (congestion control).
Key mechanisms:
Slow Start
Connection starts with a small congestion window (cwnd)
For each ACK received, cwnd increases exponentially
Quickly ramps up to discover available bandwidth
Congestion Avoidance
After reaching a threshold, growth becomes linear
Increases more cautiously to avoid overwhelming the network
Fast Recovery
When packet loss is detected via duplicate ACKs (not timeout), TCP reduces cwnd but not drastically
Assumes congestion is moderate, not severe
Timeout Response
- If a timeout occurs (severe congestion), TCP drastically reduces cwnd and starts over with slow start
These algorithms (like TCP Reno, TCP Cubic, TCP BBR) ensure TCP adapts to network conditions dynamically.
The Big Picture: Reliability in Action
Imagine sending a file:
Data is broken into segments with sequence numbers
Segments are sent with checksums
Receiver checks each segment for corruption
Receiver sends ACKs for correctly received data
Sender tracks ACKs and retransmits missing data
Flow control prevents receiver overflow
Congestion control adapts to network conditions
Data is reassembled in correct order
Application receives perfect, complete data
All of this happens automatically, invisibly, millions of times per second across the internet.
How a TCP Connection is Closed
Just as TCP carefully establishes connections, it also carefully terminates them. This is done through a four-way handshake (also called connection termination).
Why Four Steps Instead of Three?
Remember, TCP is full-duplex — both sides have independent data streams. Closing requires each side to:
Finish sending its data
Acknowledge the other side's closure
Each direction closes independently, requiring four steps total.
The Four Steps in Detail
Let's say the client wants to close the connection:
Step 1: FIN from Client
Client has no more data to send
Client sends a segment with the FIN (finish) flag set
Client enters the FIN-WAIT-1 state
Message: "I'm done sending data. I'm closing my side of the connection."
Step 2: ACK from Server
Server receives FIN
Server sends ACK acknowledging the FIN
Server enters the CLOSE-WAIT state
Client enters the FIN-WAIT-2 state
Message: "I acknowledge you're done sending. But I might still have data to send you."
Important: At this point, the connection is half-closed. The client can't send more data, but the server can still send data to the client.
Step 3: FIN from Server
Server finishes sending any remaining data
Server sends its own FIN
Server enters the LAST-ACK state
Message: "Now I'm also done sending data. Let's fully close this connection."
Step 4: ACK from Client
Client receives server's FIN
Client sends final ACK
Client enters the TIME-WAIT state
Server receives ACK and enters CLOSED state
Message: "Acknowledged. Connection fully closed."
The TIME-WAIT State: Why the Wait?
After sending the final ACK, the client doesn't immediately close. It waits (typically 2 x MSL, where MSL is Maximum Segment Lifetime, often 2 minutes total).
Why?
Ensure final ACK arrives: If the ACK is lost, the server will retransmit its FIN. The client needs to be around to re-ACK it.
Prevent old duplicates: Ensures old segments from this connection don't interfere with a new connection using the same port numbers.
After TIME-WAIT expires, the connection is fully CLOSED.
Simultaneous Close
Both sides can initiate closure simultaneously:
Both send FIN
Both ACK each other's FIN
Still results in four segments total, just in a different pattern
Abrupt Termination: RST (Reset)
Sometimes connections end abruptly:
Application crashes
User closes browser mid-download
Firewall blocks connection
Invalid data received
In these cases, TCP sends a RST (reset) segment, which immediately terminates the connection without the graceful handshake.
TCP Connection Lifecycle - Complete Flow from Establish → Transfer → Close]
TCP in the Real World: Practical Insights
Port Numbers and Connections
TCP connections are identified by a combination of:
Source IP address
Source port number
Destination IP address
Destination port number
This combination is called a socket pair or connection tuple.
Example:
Client: 192.168.1.100:54321 ↔ Server: 93.184.216.34:443 (HTTPS)
Even to the same server, your browser can have dozens of simultaneous TCP connections (different source ports).
Here is the diagram of TCP Functional Specification. Don’t go deep inside the diagram if you want to learn more visit the TCP RFC 793 to read more.
Extra knowledge on TCP
Well-Known Ports
Some TCP ports are standardized:
Port 80: HTTP (web traffic)
Port 443: HTTPS (secure web traffic)
Port 22: SSH (secure shell)
Port 25: SMTP (email)
Port 3306: MySQL (database)
TCP Performance Tuning
Modern operating systems auto-tune TCP parameters, but understanding them helps:
TCP window scaling: Allows windows larger than 65KB for high-bandwidth connections
TCP timestamps: Improves RTT measurement and protects against wrapped sequence numbers
Keep-alive: Periodic probes to detect dead connections
Nagle's algorithm: Reduces small packet overhead by buffering
When TCP Isn't the Answer
Despite its reliability, TCP isn't always ideal:
Streaming media: Buffering and retransmissions cause stuttering. UDP with application-level error correction works better.
Real-time gaming: Latency from retransmissions is worse than occasional packet loss. UDP preferred.
DNS queries: Single request-response, UDP's lower overhead is better.
IoT devices: Limited bandwidth/power makes TCP's overhead costly.
Modern protocols like QUIC (used in HTTP/3) build TCP-like reliability on top of UDP, getting benefits of both.
Conclusion: The Foundation of Reliable Internet Communication
TCP is the invisible workhorse of the internet. Every time you load a web page, send an email, download a file, or stream a video (over TCP), this protocol ensures your data arrives intact, in order, and complete.
We've journeyed through:
Why TCP exists — solving unreliability, disorder, and loss
The three-way handshake — establishing connections with SYN, SYN-ACK, ACK
Data transfer — sequence numbers, acknowledgments, and windows
Reliability mechanisms — retransmission, checksums, flow control, congestion control
Connection termination — the four-way handshake with FIN and ACK
Understanding TCP gives you insight into how the internet actually works under the hood. When you see "Connection refused," "Connection timeout," or "Connection reset," you now know what's happening at the TCP level.
As you continue your networking journey, this foundational knowledge will serve you whether you're debugging network issues, optimizing application performance, or designing distributed systems.
Further Resources
To dive even deeper into TCP, here are authoritative resources:
RFCs (Request for Comments - Official Specifications)
RFC 675 - Specification of Internet Transmission Control Program (1974) - The original TCP specification by Vint Cerf, Bob Kahn, and others
RFC 793 - Transmission Control Protocol (1981) - The foundational TCP specification that defined the protocol as we know it
RFC 9293 - Transmission Control Protocol (2022) - The most recent update, consolidating decades of TCP evolution
Learning Resources
Cloudflare Learning Center - What is TCP/IP? - Excellent beginner-friendly explanations
MDN Web Docs - TCP - Web developer perspective on TCP
My Previous Article: Understanding the OSI Model and TCP/IP - Foundation for understanding where TCP fits
Advanced Topics
RFC 2581 - TCP Congestion Control
RFC 2018 - TCP Selective Acknowledgment (SACK)
RFC 7323 - TCP Extensions for High Performance
Visualization Tools
Wireshark - Network protocol analyzer to see TCP packets in action
tcpdump - Command-line packet analyzer
Network simulators - Tools like GNS3 or Packet Tracer to experiment with TCP
Thank you for reading! If you found this helpful, consider sharing it with others learning about networking. Questions or feedback? Drop a comment below!
Top comments (0)