Transmission Control Protocol (TCP) Explained

Transmission Control Protocol, TCP, is a transport-layer protocol in the OSI model. It’s what actually creates a reliable connection between two remote computers, guaranteeing that data sent from one side arrives at the other, intact and in order.

When the application layer has data to send, it hands that data down to the transport layer, either TCP or UDP, depending on what the application actually needs. TCP first establishes a connection through a three-way handshake. Once connected, it breaks the data into segments, attaches a header to each one, and passes them down to the Internet layer for delivery.

The TCP header is 20 bytes in its base form, without any options. With options included, it can grow up to 60 bytes total.

The TCP Header

Every TCP segment carries this header:

• Source Port (16 bits) and Destination Port (16 bits). Identify which application on each end this segment belongs to.
• Sequence Number (32 bits). Identifies the position of this segment’s first byte within the overall data stream.
• Acknowledgment Number (32 bits). Identifies the next byte the sender expects to receive back.
• Header Length (4 bits). Indicates how long the header itself is, since it can vary with options.
• Reserved (6 bits). Set aside, unused in the base specification.
• Code bits (6 bits), also called Flags. Includes the control flags: SYN, ACK, PSH, RST, FIN, and URG.
• Window (16 bits). Tells the other side how much data it’s currently willing to receive before needing an acknowledgment.
• Checksum (16 bits). Verifies the segment arrived without corruption.
• Urgent Pointer (16 bits). Used alongside the URG flag to mark urgent data within the segment.
• Options (0 to 320 bits, in 32-bit increments). Optional extensions, like Maximum Segment Size or Selective Acknowledgment support, padded to align on a 32-bit boundary.

The TCP Three-Way Handshake

TCP uses a three-way handshake to establish a connection between a client and a server before any actual data flows. It’s called a three-way handshake because it takes exactly three messages, using the SYN and ACK flags in the header’s code bits. This process is also what sets the initial sequence and acknowledgment numbers both sides will use for the rest of the connection.

Here’s exactly how it works, with real numbers:

1. Client → Server: Source Port 3005, Destination Port 80, Sequence Number 600, SYN flag set.
2. Server → Client: Source Port 80, Destination Port 3005, Sequence Number 700, Acknowledgment Number 601, SYN, ACK flags set. The server acknowledges the client’s sequence number plus 1 (600 + 1 = 601), since one byte is conventionally counted for the SYN itself.
3. Client → Server: Source Port 3005, Destination Port 80, Sequence Number 601, Acknowledgment Number 701, ACK only. The client acknowledges the server’s sequence number plus 1 (700 + 1 = 701).

Notice that only the first two messages carry the SYN flag. The third and final message carries only ACK. Once this exchange completes, actual data transfer can begin. Every subsequent segment in the connection builds on these initial sequence numbers, incrementing as data flows in each direction.

Data Segmentation

The Internet layer protocol beneath TCP limits how much data a single unit can carry, a limit called the Maximum Transmission Unit (MTU). Application data is often much larger than this limit, so TCP breaks it into smaller segments, each sized to fit within the MTU.

Sequence numbers identify every byte of data individually. The sequence number in a given segment’s header marks the position of that segment’s first byte within the overall stream, which is exactly what lets the receiving end reassemble everything in the correct order later.

Flow Control and Windowing

Flow control keeps a sender’s transmission rate proportional to what the receiver can actually handle, preventing a fast sender from overwhelming a slower receiver.

The Window field in the TCP header controls exactly how much data can be in flight, unacknowledged, at any given time. At the start of a session, the window is typically small. It grows as the connection proves itself reliable. The receiving host can also shrink the window if it needs to slow the sender down. Because this value changes dynamically over the life of the connection, it’s called the sliding window.

Once a sender has transmitted everything the current window allows, it has to stop and wait for an acknowledgment before sending more.

Here’s a worked example, with consistent, byte-accurate numbers:

1. Source sends: Window = 800, Sequence Number = 1000, 800 bytes of data (covering bytes 1000 through 1799).
2. Destination responds: ACK, Acknowledgment Number = 1800, Window = 900. The window has grown, since the connection is going well.
3. Source sends: Window = 900, Sequence Number = 1800, 900 bytes of data (covering 1800 through 2699).
4. No acknowledgment arrives for this segment.
5. Source retransmits: Window = 900, Sequence Number = 1800, the same 900 bytes.
6. Destination responds: ACK, Acknowledgment Number = 2700, Window = 1000. The window grows again.
7. Source sends: Window = 1000, Sequence Number = 2700, 1000 bytes of data.

That missing acknowledgment in step 4 is exactly how TCP detects loss, covered next.

Reliable Delivery with Error Recovery

When the destination successfully receives the segments covered by the current window, it sends an acknowledgment, with the ACK flag set and the acknowledgment number set to the next byte it expects.

If a segment never arrives, the destination simply never sends an acknowledgment for it. No separate “negative acknowledgment” message exists. The source detects this by timeout, waiting for an ACK that never comes, and retransmits the missing segment. That’s exactly what happens in step 5 of the windowing example above: the source doesn’t hear back after step 3, so it resends the same segment before the destination finally acknowledges it in step 6.

Ordered Delivery

TCP transmits data in the order the application layer handed it over, using sequence numbers to track that order explicitly. Network conditions can still cause segments to arrive out of order at the destination, since different segments can take different paths. TCP re-sorts everything by sequence number before handing the reassembled, correctly-ordered stream up to the application layer. This ordered delivery is one of TCP’s core guarantees, and it’s exactly what the sequence number exists to make possible.

Connection Termination

Once all data has transferred successfully, TCP closes the connection using a four-way exchange, involving the FIN and ACK flags from both sides:

1. The side finished sending data sends a segment with the FIN flag set.
2. The other side acknowledges with ACK.
3. Once that side is also finished sending, it sends its own FIN.
4. The original side acknowledges with a final ACK, and the connection formally closes.

This four-step process, rather than a simple two-step close, exists because TCP connections are full-duplex. Each side needs to independently signal it’s done sending, since one side might still have data left to transmit even after the other side has finished.

Key Features of TCP

• Connection-oriented. A stable connection is established before any actual data exchange happens.
• Full-duplex. Both sides can send and receive simultaneously, over the same connection.
• Congestion control. Algorithms like TCP Reno and CUBIC actively prevent the network from being overloaded by too much simultaneous traffic.
• Multiplexing. Port numbers let a single device run many independent TCP connections at once.
• Flow control and error recovery. Built directly into the protocol, not left to the application layer to handle separately.

TCP vs. UDP

TCP prioritizes reliability. UDP prioritizes speed. The right choice depends entirely on what the application actually needs:

• TCP fits applications where correctness matters more than raw speed: email (SMTP), web traffic (HTTP/HTTPS), and file transfers (FTP).
• UDP fits applications where speed and low latency matter more than guaranteed delivery: video calls, live streaming, and online gaming.

Some newer protocols, like QUIC (which underlies HTTP/3), build reliability features on top of UDP rather than using TCP directly, aiming to get UDP’s low latency without fully giving up TCP’s reliability guarantees. That’s a genuine, real architectural trend worth knowing about, distinct from vague claims about unspecified “hybrid protocols.”

Common TCP Challenges and How to Address Them

Security. TCP itself doesn’t encrypt anything. TLS/SSL, layered on top of TCP, is what actually secures the connection, which is exactly the difference between HTTP and HTTPS.

Latency. Modern congestion control algorithms like TCP BBR (Bottleneck Bandwidth and Round-trip propagation time) actively model the network path to reduce unnecessary delay, rather than relying purely on packet-loss signals the way older algorithms did.

Packet loss. Selective Acknowledgments (SACK) let a receiver tell the sender exactly which segments arrived and which didn’t, so only the genuinely missing segments need retransmission, instead of resending everything after the first gap.

Conclusion

TCP’s reliability comes from a handful of mechanisms working together: the three-way handshake to establish a connection, sequence and acknowledgment numbers to track and confirm delivery, the sliding window for flow control, and a proper four-way close to end the connection cleanly. Understanding the real numbers behind each of these, not just the concepts in the abstract, is what makes TCP troubleshooting and packet analysis make sense later on. A packet capture showing a wrong acknowledgment number, for instance, is exactly the kind of detail that becomes obvious once you’ve worked through the arithmetic by hand.

FAQs

How does TCP differ from UDP?

TCP guarantees reliable, ordered delivery through acknowledgments and retransmission, while UDP sends data without any delivery guarantee at all, trading reliability for lower overhead and lower latency. TCP fits applications like web browsing and email, where correctness matters most; UDP fits real-time applications like video calls and gaming, where speed matters more than occasional loss.

How does TCP handle packet loss?

TCP detects loss when an expected acknowledgment doesn’t arrive within its timeout window, then retransmits the missing segment. Selective Acknowledgments (SACK) improve on this by letting the receiver specify exactly which segments it actually received, so the sender only needs to retransmit genuinely missing data rather than everything after the first gap.

What are TCP ports, and why do they matter?

TCP ports are 16-bit values, ranging from 0 to 65535, that identify which specific application or service a segment belongs to on a given device, port 80 for HTTP being a familiar example. Ports are what let a single device maintain many independent TCP connections simultaneously, since each connection is uniquely identified by the combination of source IP, source port, destination IP, and destination port.

Why does the TCP handshake need three steps instead of two?

Two steps would only confirm one direction of the connection. The third step exists specifically so both sides can independently confirm they’re ready to communicate: the client’s SYN proposes a connection, the server’s SYN-ACK confirms it received that proposal and proposes its own sequence number back, and the client’s final ACK confirms it received the server’s response. All three messages are necessary because TCP connections are bidirectional from the very start, and each side needs its own sequence number acknowledged before real data can safely begin flowing in both directions.

Why does closing a TCP connection take four steps instead of two?

Because TCP connections are full-duplex, each side sends data independently of the other, and each side needs to signal separately when it’s actually done sending. A single FIN/ACK exchange would only close one direction. The four-step close lets one side finish and close its sending direction while the other side potentially keeps sending a bit longer, before it too sends its own FIN to close the connection completely.

Test your knowledge with our self-assessment test for exam preparation: Quiz Test Transmission Control Protocol (TCP)