How TCP Works
TCP turns a best-effort network into a reliable byte stream
IP packets can be dropped, duplicated, delayed, or delivered out of order. TCP sits on top of IP and adds the rules needed for two systems to exchange data reliably without forcing the application to rebuild those guarantees every time.
When developers say a service speaks over TCP, they usually mean the application gets a stream-like connection where bytes arrive in order, missing pieces are retransmitted, and both sides coordinate how quickly data can be sent.
Last updated: May 11, 2026
The basic idea
TCP treats application data as a stream of bytes, not separate messages. The sender breaks the stream into segments, tags them with sequence numbers, and sends them across the network. The receiver acknowledges what it has received, and the sender resends anything that appears to be missing.
This gives applications reliable in-order delivery, but it also means the protocol needs connection setup, bookkeeping, timers, and backpressure.
Step by step
- The client and server establish a connection with a three-way handshake so both sides agree on initial sequence numbers.
- The sender transmits segments containing byte ranges from the stream.
- The receiver sends acknowledgements to indicate which bytes arrived successfully.
- If an acknowledgement does not arrive in time, the sender retransmits the missing data.
- Flow control and congestion control limit how much data is in flight so the receiver and the network are not overwhelmed.
Important mechanisms
Three-way handshake
The handshake synchronizes state before data starts flowing. It prevents one side from assuming a connection exists when the other side is not ready.
Sequence numbers
Each byte in the stream is numbered logically. This lets the receiver reorder segments and detect gaps.
Acknowledgements
The receiver reports the next byte it expects. That tells the sender what has been delivered successfully.
Flow control
The receiver advertises how much buffer space it has. This keeps a fast sender from overrunning a slower receiver.
Congestion control
The sender adjusts its rate based on network conditions so it does not keep increasing traffic into a congested path.
What TCP does not do
TCP does not know about application message boundaries. If your protocol needs framed messages, you still need length prefixes, delimiters, or another application-level convention.
TCP also does not encrypt traffic. If you need confidentiality and authentication, you typically add TLS on top.
Why latency can still be painful
Reliable delivery has a cost. Packet loss triggers retransmission, and in-order delivery means later bytes may wait behind earlier missing ones. This is one reason a connection can feel sluggish even when it is technically functioning correctly. TCP optimizes for correctness first, then tries to be efficient under real network conditions.
Common confusion
- TCP is reliable, but it is not guaranteed to be fast under loss or congestion.
- One application write does not necessarily equal one network packet or one receiver read.
- Connection-oriented does not mean a physical dedicated line exists between two hosts.
What developers usually notice first
At the application level, TCP issues often surface as timeouts, resets, partial reads, stalled connections, or intermittent slowness. The protocol is doing significant recovery work behind the scenes, so the visible symptom is often delayed data rather than a clean immediate failure.