The Internet Without Rules: A Thought Experiment
Imagine two people trying to have a conversation over a call but it's a bit noisy phone line. Words can get dropped, repeated, or misunderstood — and there’s even no guarantee that the other side even heard you. That chaotic experience resembles what happens on a raw network without rules and guarantees.
Computers also face the same challenges when transferring data over networks. Without a structured communicating mechanisms, information can be lost, arrive out of order, can be duplicated or be corrupted while getting transmitted. This is where TCP (Transmission Control Protocol) comes in: a set of rules and processes that turns an unreliable network into a reliable, ordered, and correct data delivery channel.
In this blog, we go beyond definitions. We have already discussed a vast portion of the TCP protocol in my previous blog. We’ll unpack how TCP actually works — from establishing a connection to transfer data and gracefully closing it.
What TCP Solves — The Big Picture
At its core, TCP is designed to solve four fundamental problems networks introduce:
- Unreliable delivery: Packets may be dropped or never arrive.
- Out-of-order packets: They may arrive in a different sequence than they were sent.
- Corrupted data: Bits can flip/manipulated during transmission due to noise.
- data duplicacy: Data packets can be duplicated through out the transmission.
TCP addresses these with:
- Connection establishment (3-way handshake)
- Sequence numbering and acknowledgements
- Retransmission of lost data
- Flow control and error checking
This transforms an unreliable network into reliable for HTTP, email, file transfer, and interactive remote sessions.
The 3-Way Handshake: Starting a Conversation
Before meaningful data can transmit between two endpoints, TCP performs a 3-way handshake — an exchange that ensures both sides are ready for the communication.
Here’s an easy real-world analogy:
- Person A says: “Hello, Can you hear me? Are you ready to talk?”
- Person B replies: “Yes you are audible, I’m ready.”
- Person A confirms: “Great — let’s begin.”
This three-step back-and-forth is precisely what TCP does to establish a reliable connection.
The 3-way handshake can be both sides actually, if the client issues a request then that would be Active Open, on the other hand, if the server tells that its TCP i.e, it's ready to accepts the connection, than that would be Passive Open.
Step 1 — SYN
The client sends a packet with the SYN (synchronize) flag set. This segment is for synchronization of Sequence numbers. It consumes one sequence number.
This packet includes an initial sequence number — the first byte of data the client plans to send and every time that would be incremented by 1.
Client → Server: SYN (Seq = x)
Step 2 — SYN-ACK
The server responds with a segment that has 2 flag bits set:
- SYN set — to synchronize its own sequence number
- ACK set — acknowledging the client’s SYN
It sends its own initial sequence number and consumes one sequence number.
Server → Client: SYN-ACK (Seq = y, Ack = x+1)
Step 3 — ACK
The client sends a final acknowledgement segment back. It's just the acknowledgement of the second segment sent from the server-side and it consumes one acknowledge number field; doesn't consume any sequence number.
Client → Server: ACK (Ack = y+1)
Once this exchange completes, both sides have synchronized sequence numbers and the connection transitions into the ESTABLISHED state. Once the handshake completes, TCP shifts from coordination to actual data delivery.
How Data Transfer Works
Once the connection is established, data is transferred in segments, each carrying:
- A sequence number — to track ordering of bytes
- An acknowledgement number — confirming receipt up to a certain byte
- A window size — letting the other side know how much data it can send without overflow. It's byte-oriented.
Here’s how TCP manages this:
- Sender sends a segment with a sequence number.
- Receiver sends back an ACK indicating the next expected byte.
- Sender slides its window forward and sends more data.
This process continues until all data is sent and acknowledged.
Ensuring Reliability and Correctness
TCP achieves reliability through several interlocking mechanisms:
Sequence Numbers: Every byte in a TCP stream gets a monotonically increasing sequence number. This enables receivers to reorder out-of-order packets and detect missing data.
Acknowledgements: Receivers send ACKs to confirm receipt. If an expected ACK does not arrive within a timeout, the sender assumes packet loss and retransmits.
Sliding Windows: Used to make transitions more efficient as well as to control the flow of data, so that the destination doesn't get overwhelmed by the data.
Retransmission: When data is lost (inferred by missing ACKs), TCP automatically resends the missing segments.
Catching Duplication: If a data gets tranmitted again i.e, if duplication happens then it also helps to catch it during the transmission from the receiver side.
Flow Control: By negotiating a “window size”, TCP ensures senders don’t overwhelm receivers.
Together, these mechanisms make TCP a reliable, ordered, and error-checked transport protocol.
Connection Termination: Ending the Conversation
Any of the two parties who are exchanging data, can close the connection, although in most of the cases, the termination is initiated from the client side. Most implementations allow 3-way handshaking for connection-termination.
After the transmission gets completed, the client side sends the first FIN segment to the receiver side. FIN flag set may include the last chunk of data sent by the client or it can be the control segment. It consumes one sequence number if it doesn't carry data.
The server after receiving the FIN segment informs its process about the situation and sends the second segment, a FIN + ACK segment to confirm the receipt of the FIN flagset which is sent from the client-side and at the same time to announce the closing of the connection at server. This segment can also contain last chunk of data from the server, and if it doesn't carry that, it's gonna consume one sequence number.
The client sends the last segment, an ACK segment to confirm the receipt of FIN segment that is sent from the server. It basically consumes the acknowledge number, which is 1 plus the sequence number received in FIN segment of the server. It doesn't carry data nor any sequence number.
Conclusion
TCP doesn’t just send bits. It ensures a disciplined exchange that turns the unpredictable real world of networks into a dependable communication channel. Through:
- The 3-way handshake
- Sequencing and ACKs
- Retransmission and flow control
TCP guarantees that data arrives reliably, in order, and free of corruption.
Armed with this understanding, you’ll not only write better networking code — you’ll be able to architect systems that depend on predictable, resilient communications.
Top comments (0)