What is TCP?

The internet itself makes no promises. Data is cut into small packets, and each packet finds its own way across the network. Some get lost, some get damaged, and some arrive in a different order from the one they were sent in. TCP is the layer that fixes all of that, so the program at the other end gets one clean, complete stream of data.

What does TCP stand for?

TCP stands for Transmission Control Protocol. A protocol is an agreed set of rules for how two computers talk: what each message looks like, what order they come in and what to do when something goes wrong. TCP is one of the core protocols of the internet. The Internet Engineering Task Force (IETF) publishes its rules, and the current version is RFC 9293 from August 2022, which replaced the original RFC 793 from 1981.

What is TCP/IP?

TCP/IP is the name for the whole family of internet protocols, after its two most important members. IP, the Internet Protocol, gets each packet to the right computer using its IP address, but it is "best effort": packets can be lost, copied twice or arrive out of order, and IP won't tell anyone. TCP runs on top of IP and turns that unreliable delivery into a reliable one.

Think of IP as a postal service that delivers separate postcards. TCP is the habit of numbering every postcard, asking the other person to say which numbers arrived, and posting fresh copies of any that went missing. Routers along the way only read the IP part to forward each packet. The TCP work happens on the two devices at either end. Our IP Addressing and Protocols course covers the IP side, from addresses and subnet masks to ports, NAT and DNS.

The TCP/IP model: four layers

The TCP/IP model splits networking into four layers, as set out in RFC 1122. Each layer does one job and relies on the layer below it.

On the way out, each layer wraps the data from the layer above in its own header. This is called encapsulation. A web request gets a TCP header with port and sequence numbers, which makes a segment. That gets an IP header with the addresses, which makes a packet. The link layer adds its own header and trailer to make a frame. The receiving device unwraps them in reverse order.

Application:  [HTTP request]
Transport:    [TCP header][HTTP request]                     = segment
Internet:     [IP header][TCP header][HTTP request]          = packet
Link:         [Ethernet header][IP][TCP][HTTP][trailer]      = frame

You will also meet the seven-layer OSI model. It is a teaching and reference model rather than the one the internet was built on, and in it TCP sits at layer 4, the transport layer. In the UK, AQA GCSE Computer Science asks you to describe the four-layer TCP/IP model and to know that HTTP, HTTPS, SMTP and IMAP work at the application layer, TCP at the transport layer and IP at the internet layer.

How does TCP work?

A TCP connection has three stages: open the connection, send the data, then close it. Five ideas do the work: the handshake, sequence numbers, acknowledgements, flow control and congestion control.

The TCP three-way handshake

Before any data moves, the two devices agree to talk and swap starting sequence numbers. This takes three messages, so it is called the three-way handshake.

1. SYN: the client sends a segment with the SYN (synchronise) flag set and its starting sequence number. It means "I'd like to connect, and my numbers start here."
2. SYN-ACK: the server replies with both flags set. It gives its own starting number and acknowledges the client's number plus one.
3. ACK: the client acknowledges the server's number plus one. The connection is now open in both directions.

Client                                   Server
  |------ SYN      seq=5000 ------------------>|
  |<----- SYN-ACK  seq=9000  ack=5001 ---------|
  |------ ACK      seq=5001  ack=9001 -------->|
  |======= data can now flow both ways ========|

Why add one? A SYN uses up one sequence number, so the next byte the server expects from the client is 5001. The starting numbers are not 0. TCP picks them so they are hard to guess, which stops an attacker slipping forged segments into someone else's connection.

The handshake costs one round trip before the client can send its request. If a server is 100 milliseconds away there and back, that is 100 ms of waiting on every new connection, before any encryption is set up. Saving that time is one reason HTTP/3 moved to QUIC, which sets up the connection and the encryption together.

Sequence numbers and acknowledgements

TCP numbers every byte it sends, not every packet. Each segment carries the sequence number of its first byte. The receiver replies with an acknowledgement number: the number of the next byte it expects. That single number confirms every byte before it, which is called a cumulative acknowledgement.

If segments arrive out of order, the receiver holds the early arrivals and puts everything back in order before passing it to the program. The program never sees the shuffle.

Resending lost data

The sender keeps a copy of everything that hasn't been acknowledged yet. TCP spots a loss in two ways:

• Timeout: no acknowledgement arrives within a time based on how long round trips have been taking, so the sender resends.
• Duplicate acknowledgements: when a segment goes missing, every later segment makes the receiver repeat the same acknowledgement number. Under RFC 5681, three duplicates in a row trigger a resend straight away, without waiting for the timer. This is called fast retransmit.

Every segment also carries a 16-bit checksum. If a segment is damaged on the way, the checksum won't match, the receiver throws it away, and it gets resent like a lost one.

Flow control: not overwhelming the receiver

Every segment includes a window: how many more bytes the receiver has room for. The sender must not have more unacknowledged data in flight than that. If the program at the receiving end is slow to read, the window shrinks, and if it fills up the sender pauses. The window field is 16 bits, so on its own it can't go above 65,535 bytes. A window scale option from RFC 7323 multiplies it, up to about 1 GB, which fast long-distance links need.

Congestion control: not overwhelming the network

The receiver might have room, but the routers in between might not. So the sender also keeps a congestion window and treats lost segments as a sign that the network is overloaded. Classic TCP, described in RFC 5681, does three things:

• Slow start: begin small and double the window every round trip, which finds the available speed quickly.
• Congestion avoidance: past a threshold, grow by just one segment per round trip.
• Back off on loss: when a loss shows up, cut the window, typically by half, then grow again.

Here x is the number of round trips and y is the congestion window in segments. To keep the numbers small, the window starts at 1 segment, as early TCP did. It doubles to 16 by round trip 4, then climbs by one each round trip to 24. A loss at round trip 12 halves it to 12, and the climb starts again. Over a long connection this makes the sawtooth shape TCP is known for. Many systems now use CUBIC (RFC 9438), which grows the window along a curve instead of a straight line, but the idea is the same: probe for speed, back off on loss, probe again.

Closing a TCP connection

Each side closes its own direction. One side sends a segment with the FIN (finish) flag, meaning "I have no more data to send", and the other acknowledges it. Then the other side does the same. That is usually four segments, or three when one segment carries both an ACK and a FIN. A segment with the RST (reset) flag ends a connection at once, for example when a device receives a segment for a connection it doesn't have.

TCP worked examples

These follow one connection, with the starting numbers from the handshake above: the client starts at 5000 and the server at 9000.

Example 1: sending data

After the handshake, the client sends 1,200 bytes in three segments of 400 bytes. What sequence numbers do the segments carry, and what does the server acknowledge after each one?

• The first data byte is 5001, so segment 1 has seq = 5001 and covers bytes 5001 to 5400. The server replies ack = 5401.
• Segment 2 has seq = 5401 and covers bytes 5401 to 5800. The server replies ack = 5801.
• Segment 3 has seq = 5801 and covers bytes 5801 to 6200. The server replies ack = 6201.

Each sequence number is the last one plus the bytes sent: 5001 + 400 = 5401, and so on.

Example 2: a lost segment

Same three segments, but segment 2 (seq = 5401) is lost. What happens?

1. Segment 1 arrives. The server replies ack = 5401.
2. Segment 2 is lost.
3. Segment 3 (seq = 5801) arrives. The server holds it, but byte 5401 is still the next one it needs, so it replies ack = 5401 again. That is a duplicate acknowledgement.
4. The client's timer runs out, or it collects three duplicates, so it resends segment 2.
5. Segment 2 arrives. The server now has every byte up to 6200, so it replies ack = 6201. One acknowledgement covers both segments.

Example 3: how many segments is a 1 MB file?

On Ethernet, a frame carries up to 1,500 bytes of IP packet. Take off 20 bytes for the IPv4 header and 20 for the TCP header, with no options, and each segment can carry 1,460 bytes of data. This is the maximum segment size, or MSS. How many segments does a 1,000,000 byte file need, and how many bytes of headers come with it?

• 1,000,000 ÷ 1,460 = 684.9, so 684 full segments and 1 more for the rest: 685 segments.
• The last segment carries 1,000,000 − 684 × 1,460 = 1,360 bytes.
• Headers: 685 × 40 bytes = 27,400 bytes, which is about 2.7% on top of the file.

Round up, never down: a part-full segment is still a segment.

TCP vs UDP: how does TCP differ from UDP?

TCP and UDP are the two main transport protocols, and they make opposite trades. TCP guarantees that data arrives complete and in order, at the cost of a handshake, acknowledgements and resends. UDP, the User Datagram Protocol, just sends each message and hopes. It is lighter and starts instantly, but lost data stays lost unless the program deals with it.

When to use TCP and when to use UDP

Ask one question: is late data still useful? If every byte matters, as in an email, a web page or a file, use TCP. A file with one missing chunk is broken, so waiting for a resend is worth it. If late data is useless, use UDP. In a video call, a piece of audio that turns up 300 milliseconds late is worse than a tiny glitch, so the program skips it and carries on.

UDP doesn't always mean unreliable, though. HTTP/3 runs on QUIC (RFC 9114), which is built on UDP but adds its own acknowledgements, resends and encryption on top. DNS uses UDP for most lookups because a question and answer fit in one message each, and switches to TCP when an answer is too big.

Try sorting some real applications into TCP or UDP. Answer here, then press Mark to check in the course.

TCP ports

An IP address gets data to the right device. A port number gets it to the right program on that device. TCP ports are 16-bit numbers, from 0 to 65,535. Servers listen on well-known ports, and your device picks a spare high-numbered port for its side of each connection.

IANA splits ports into three ranges: system ports from 0 to 1023, user ports from 1024 to 49151, and dynamic or private ports from 49152 to 65535. A TCP connection is identified by four values: source IP address, source port, destination IP address and destination port. That is why ten browser tabs can each hold their own connection to the same server on port 443: each one uses a different port on your side.

The TCP header

Every TCP segment starts with a header of at least 20 bytes. These are its fields, from RFC 9293.

The fixed fields add up to 160 bits, which is 20 bytes. The data offset is 4 bits, so its biggest value is 15 words of 4 bytes, which is why the header tops out at 60 bytes. Compare UDP's header from RFC 768: just source port, destination port, length and checksum, 8 bytes in all.

A 32-bit sequence number runs out after 4,294,967,296 bytes, about 4.29 GB, then wraps back to zero. A 10 gigabit link sends that much in about 3.4 seconds, so RFC 7323 adds timestamps to tell old segments from new ones after a wrap.

A short history of TCP

Vint Cerf and Bob Kahn described the first version of TCP in a 1974 paper on connecting different packet networks together. It started as one protocol and was later split in two: IP for addressing and routing, and TCP for reliability. TCP was standardised as RFC 793 in 1981, and on 1 January 1983 the ARPANET, the network the internet grew from, switched over to TCP/IP. The rules have been extended many times since, and RFC 9293 gathered them into one up-to-date document in 2022.

Common mistakes about TCP

• Treating TCP and IP as the same thing. IP delivers packets to a device and makes no promises. TCP makes delivery reliable between two programs.
• Thinking sequence numbers count packets. They count bytes. A 400-byte segment moves the next sequence number on by 400.
• Thinking TCP makes data secure. TCP checks for accidental damage, but it doesn't encrypt anything. HTTPS adds TLS on top of TCP for that.
• Saying UDP is just worse. For live audio, video and games, UDP's lack of waiting is exactly what you want.
• Thinking "reliable" means it always gets through. If the network is down, TCP keeps trying and then gives up and tells the program. Reliable means you never silently get missing or jumbled data.
• Saying a port is a physical socket. In TCP a port is a number that picks out a program or connection on a device.

Read next

Computer Science · NetworksHow does the internet work? Packets, routers and protocolsHow the internet works, step by step: packets, routers, IP addresses, DNS, TCP and HTTP, the TCP/IP model and the cables that carry it all.