TCP (Transmission Control Protocol) is the connection-oriented transport protocol of the Internet protocol suite that provides applications with a reliable, ordered and error-checked byte stream between two endpoints over an unreliable IP network. Among transport protocols in networking, it is the workhorse behind web traffic, email, file transfer, remote shells and most database connections.
TCP was first specified in 1981 and is currently defined by RFC 9293, which consolidated four decades of updates. It runs directly over IP as protocol number 6 and identifies each conversation by the combination of source and destination addresses and port numbers.
How TCP delivers a reliable byte stream
TCP turns lossy, reorderable IP packets into a dependable stream through sequence numbers and acknowledgments. Every byte sent gets a sequence number; the receiver returns a cumulative acknowledgment naming the next byte it expects, and the sender retransmits anything not acknowledged in time.
A connection starts with the three-way handshake: the client sends SYN, the server answers SYN-ACK and the client confirms with ACK. Both sides exchange initial sequence numbers and options such as the maximum segment size, so application data normally flows only after one full round trip. A connection ends with FIN segments from each side, and the side that closes first waits in the TIME-WAIT state to absorb delayed duplicates.
Lost data is detected in two ways. A retransmission timeout (RTO) fires when no acknowledgment arrives within a time derived from measured round-trip times, while fast retransmit resends a segment after three duplicate acknowledgments, without waiting for the timer. Selective acknowledgment (SACK) lets the receiver report exactly which blocks arrived, so only the missing ones are resent.
The TCP header and its fields
The TCP header is 20 bytes without options and up to 60 bytes with them. Its fields carry everything needed for multiplexing, reliability and flow control, as the table summarizes.
| Field | Size | Function |
|---|---|---|
| Source and destination port | 16 bits each | Identify the sending and receiving application |
| Sequence number | 32 bits | Position of the first data byte in the stream |
| Acknowledgment number | 32 bits | Next byte the receiver expects |
| Data offset | 4 bits | Header length in 32-bit words |
| Flags | 8 bits | SYN, ACK, FIN, RST, PSH, URG, ECE and CWR control bits |
| Window | 16 bits | Free receive buffer space, scaled by an option |
| Checksum | 16 bits | Error check over header, data and IP pseudo-header |
| Options | 0 to 40 bytes | MSS, window scale, SACK, timestamps |
On standard Ethernet with a 1,500-byte MTU, the usual maximum segment size is 1,460 bytes for IPv4, after 20 bytes of IP header and 20 bytes of TCP header, and 1,440 bytes for IPv6, whose base header is 40 bytes.
Flow control and congestion control
TCP limits its sending rate with two separate windows. Flow control protects the receiver: the advertised receive window states how much unacknowledged data the receiver can buffer. Congestion control protects the network: the sender keeps its own congestion window and sends no more than the smaller of the two.
Because the window field has only 16 bits, it tops out at 65,535 bytes. The window scale option multiplies it by up to 2 to the power of 14, allowing about 1 GiB. This matters because a single connection can never exceed window divided by round-trip time. To fill a link, the window must reach the bandwidth-delay product, as the table shows.
| Link speed | Round-trip time | Required window |
|---|---|---|
| 100 Mbit/s | 20 ms | 250 KB |
| 1 Gbit/s | 20 ms | 2.5 MB |
| 1 Gbit/s | 100 ms | 12.5 MB |
| 10 Gbit/s | 100 ms | 125 MB |
Without window scaling, a 100 ms path is capped at about 5.2 Mbit/s per connection, whatever the link speed. Congestion control decides how quickly the congestion window grows and how sharply it shrinks after loss. Modern stacks start with an initial window of 10 segments, about 14.6 KB, and then use one of the algorithms below.
| Algorithm | Congestion signal | Behavior | Typical use |
|---|---|---|---|
| Reno and NewReno | Packet loss | Additive increase, halving on loss | Reference behavior, older systems |
| CUBIC | Packet loss | Cubic growth, fast recovery on long fat paths | Default in Linux and Windows |
| BBR | Measured bandwidth and RTT | Models the path instead of reacting to loss | Large content and cloud providers |
| DCTCP | ECN marks | Reacts to the share of marked packets | Data center fabrics with ECN |
TCP compared with UDP and QUIC
Choosing a transport protocol is a trade-off between guarantees and latency. TCP offers reliability and ordering built into the operating system, UDP offers minimal overhead with no guarantees, and QUIC rebuilds reliability on top of UDP with encryption included.
| Property | TCP | UDP | QUIC |
|---|---|---|---|
| Connection setup | Three-way handshake, 1 RTT | None | 1 RTT including TLS, 0-RTT on resumption |
| Reliability and ordering | Yes, one byte stream | No | Yes, per independent stream |
| Head-of-line blocking | Yes, across all data | Not applicable | Only within one stream |
| Encryption | Separate, usually TLS | Separate, usually DTLS | Built in, TLS 1.3 |
| Typical uses | Web, email, SSH, databases | DNS, VoIP, gaming, streaming media | HTTP/3 |
Performance pitfalls and misconceptions
A frequent misconception is that a faster link automatically speeds up every transfer. Latency and packet loss often matter more than bandwidth: for loss-based algorithms, throughput falls roughly with the square root of the loss rate. With a 1,460-byte segment, a 50 ms round trip and 0.01% loss, the classic Mathis estimate for Reno gives only about 28 Mbit/s per connection.
- Undersized socket buffers cap long-distance transfers far below the link speed.
- Head-of-line blocking stalls all later data while one lost segment is retransmitted.
- Blocked ICMP messages break path MTU discovery and make large segments disappear.
- Many short connections pay the handshake and slow-start cost again each time; connection reuse avoids it.
In everyday language
TCP works like a careful courier service with numbered pages. A long document is split into numbered pages, and the recipient confirms which pages have arrived. Any page that goes missing is sent again, and the recipient puts everything back in the right order.
The courier also watches the traffic and slows down when the roads are jammed. The key point is that TCP makes sure data arrives complete and in order, even though the network underneath can lose or shuffle pieces along the way.
Seen in the real world
A company copies nightly database backups from Frankfurt to a recovery site in New York over a dedicated 1 Gbit/s link with an 80 ms round-trip time. The bandwidth-delay product is 10 MB, but the backup servers limit TCP socket buffers to 4 MB, so each connection peaks at about 400 Mbit/s and a 2 TB backup takes roughly 11 hours.
The network engineer raises the maximum buffer size to 16 MB and confirms that window scaling is active in a packet capture. The same transfer now runs at about 940 Mbit/s, close to the practical maximum of the link, and the backup finishes in under 5 hours without any change to the hardware.