RFC 793 · · Obsoleted by RFC 9293
TCP, the protocol that turns postcards into a phone call.
The official title is "Transmission Control Protocol." What it actually decides: how two machines turn the loose, unreliable packets of IP into a connection that behaves like a phone call, the one nearly every web page, email and login quietly rides on.
Written by Noel Lang · IT trainer
TL;DR
RFC 793 is the original specification of TCP, the protocol that turns IP’s unreliable packets into a reliable, ordered connection. It numbers every byte, acknowledges what arrives and resends what does not, and it defines the three-way handshake (SYN, SYN-ACK, ACK) that opens a connection. Written in 1981, it was replaced by RFC 9293 in 2022, which is the text to cite today. The protocol on the wire never changed: your browser still speaks 793-era TCP.
The problem it solves
RFC 791 gives you postcards. Each IP packet is dropped into the network on its own, with an address on the front and no promises: some arrive out of order, some arrive twice, some are lost in the post and never mentioned again. That is wonderful for the network, which stays simple and fast, and terrible for almost every program, which wants to write a stream of bytes on one end and read the exact same bytes, in the exact same order, on the other.
TCP is the layer that makes that happen, using nothing but those unreliable postcards. It numbers every byte it sends, waits for the other side to confirm what arrived, and resends anything that went missing. Out of a stack of unordered postcards it reconstructs a clean, continuous conversation. IP delivers packets. TCP delivers a promise.
The phone call analogy
Sending raw IP packets is like mailing postcards. You write one, drop it in a box, and hope. You get no confirmation, no ordering, and if one is lost you will never know which.
A TCP connection is a phone call. First it rings: one side dials, the other picks up, and they confirm they can hear each other before anyone says anything important. That opening ritual is the three-way handshake. Once the call is up, words arrive in the order you speak them, and if the line crackles you say “sorry, again?” and the sentence is repeated until it lands. When you are done, you say goodbye rather than just dropping the receiver, so nothing half-spoken is lost. Every one of those behaviors is something RFC 793 added on top of IP’s postcards.
The analogy from RFC 1918 continues here. There, an address was the building and a port was the buzzer label on the door. TCP is what actually uses those buzzers: a connection is identified by four things, your address and port plus their address and port. That is how one laptop keeps twenty browser tabs, an email client and an ssh session on the same address without mixing up whose bytes are whose. The address gets the packet to the building; the port gets it to the right conversation inside.
What TCP guarantees, and what it doesn't
This is the single most misunderstood thing about TCP. It makes exactly two promises and pointedly refuses two others:
-
Order guaranteed
Yes. Every byte is numbered. If packet 5 arrives before packet 4, TCP holds it back and hands your program the bytes in the order you sent them. You never see the reordering that happens on the wire.
-
Completeness guaranteed
Yes. The receiver acknowledges what arrived. Anything unacknowledged gets sent again until it lands. What you read out one end is exactly the byte stream that went in the other, no gaps, no duplicates.
-
Latency not guaranteed
No. TCP promises the bytes arrive, never when. On a bad connection it will happily wait and resend for seconds. That's why a video call over TCP stutters: you'd rather drop a late frame than wait for it.
-
Security not guaranteed
No. The bytes travel in the clear. Confidentiality is the job of TLS one layer up. TCP makes sure your message arrives whole, not that nobody else can read it.
Order and completeness: yes. Timing and secrecy: not TCP's job. The last two belong to your application and to TLS.
The three-way handshake
Before a single byte of your request moves, the two machines exchange three packets to agree they are both there and to pick starting sequence numbers. This is what “opening a connection” actually means, and why it costs one round trip.
What the RFC actually says
The 1981 original is about 85 pages, and section 3 is the whole heart of it. The map, in case you want to visit the source:
| Section | In plain words |
|---|---|
| 1 · Introduction | Why a reliable layer is needed at all: IP loses, duplicates and reorders packets, and applications want a clean stream instead. |
| 2 · Philosophy | The design goals: reliability, flow control, multiplexing via ports, and connections. The mental model for everything below. |
| 3.1 · Header format | The famous diagram: source and destination ports, sequence and acknowledgement numbers, the flag bits (SYN, ACK, FIN, RST) and the window. |
| 3.4 · Establishing a connection | The three-way handshake, spelled out packet by packet. This is the part everyone quotes. |
| 3.5 · Closing a connection | The polite goodbye: FIN and ACK from each side, so no in-flight data is lost when the call hangs up. |
| 3.7 · Data communication | Sequence numbers, acknowledgements, retransmission and the sliding window: the machinery that makes the guarantees real. |
Things people get wrong
-
"TCP is slow."
It has overhead, which is not the same as slow. The handshake costs one round trip before data flows, and retransmission costs time only when packets actually drop. On a healthy connection TCP saturates the link. It feels slow exactly when the network is bad, because it is doing the work of hiding that badness from you, which is the entire point.
-
"RFC 9293 is a new version of TCP."
It is not a new protocol, it is a new document. RFC 9293 (2022) merges the original RFC 793 with the pile of errata and update RFCs that grew around it over 41 years into one clean text. Not a single bit changed on the wire. A modern machine and a 1981 machine would still complete the same handshake. 9293 is a better map of the same territory.
-
"TCP guarantees my data is secure."
It guarantees delivery and order, never secrecy. Bytes sent over plain TCP are readable by anyone on the path. The padlock in your browser comes from TLS, a separate layer above TCP. Reliable and encrypted are two different promises, made by two different protocols.
-
"UDP is always faster and better."
UDP is faster to start and lighter, but it hands you raw, lossy, unordered packets. If your application needs the bytes complete and in order, you either use TCP or you rebuild TCP's guarantees yourself on top of UDP. That is precisely what QUIC does. Faster is only better when you did not need the promises in the first place.
Where you'll meet TCP
TCP is the quiet default under most of what you do online. A field guide to spotting it:
| You see | You're probably looking at |
|---|---|
| https:// in your browser | HTTP/1.1 and HTTP/2 both run over a TCP connection (then wrapped in TLS). Every page you load opens one. |
| An ssh login | SSH is a TCP application, port 22. The reliable ordered stream is what lets you type a command and trust every character arrives. |
| A database connection | PostgreSQL (5432), MySQL (3306), Redis (6379): all long-lived TCP connections. Losing a byte mid-query is not an option. |
| SYN flood in a security log | An attack that sends the first handshake packet and never finishes, exhausting the half-open connection table. A direct abuse of the 793 handshake. |
| HTTP/3 in devtools | The deliberate exception: HTTP/3 uses QUIC over UDP, not TCP. When you see it, someone chose to leave TCP behind (RFC 9000). |
| Connection timed out | TCP tried its handshake or its retransmissions and gave up. The guarantee is delivery-or-tell-you, never silent loss. |
Questions people actually ask
Is RFC 793 still the current TCP standard? +
No. RFC 793 was obsoleted by RFC 9293 in August 2022. RFC 9293 describes the same protocol but folds in four decades of corrections and updates. For the authoritative text today, cite 9293; for the historical origin, cite 793. The TCP on the wire is unchanged, so your browser still speaks 793-era TCP right now.
What is the TCP three-way handshake? +
The three packets that open a connection: the client sends SYN, the server replies SYN-ACK, the client answers ACK. After that both sides have agreed on starting sequence numbers and the connection is established. RFC 793 defined it, and it is exactly why a TCP connection is slower to start than a single UDP packet.
What is the difference between TCP and UDP? +
TCP (RFC 793 / 9293) guarantees that your bytes arrive complete and in order, at the cost of a handshake and retransmissions. UDP (RFC 768) just fires each packet and forgets it, no setup and no promises. TCP for correctness, UDP for speed and real-time traffic where a late packet is worthless anyway.
Does TCP guarantee security or encryption? +
No. TCP guarantees delivery and order, nothing about confidentiality. The bytes travel in the clear unless a layer above adds encryption. That layer is TLS, which is why the padlock lives at https and not at TCP. Reliable is not the same as secret.
Why is RFC 9293 not a new version of TCP? +
Because it changes no bits on the wire. RFC 9293 is a redraft that merges RFC 793 with the errata and update RFCs that had accumulated around it (1122, 3168, 6093, 6528 and more) into one clean document. It is a cleaner map of the same territory, not a new protocol. Both are STD 7.
Why is TCP called connection-oriented? +
Because both machines set up shared state (the sequence numbers, the window, the connection itself) before any data moves, and tear it down when finished. IP underneath has no such notion: each packet is independent. TCP builds the illusion of a continuous connection on top of those independent packets.
Referenced by
Other explainers on this site that point back to this RFC:
How RFC 793 connects
What came before
-
RFC 791 IP moves packets and makes no promises: some arrive late, twice or never. TCP sits directly on top and adds every guarantee using nothing but those same best-effort packets.
Its counterparts
-
RFC 9293 · replaced by
The 2022 consolidation
RFC 9293 rolls the 1981 spec plus decades of errata and updates into one current document. Same protocol, current text. This is the RFC to cite now.
-
RFC 768 · the opposite trade
UDP, TCP without the promises
The counterpart. UDP drops the handshake, the ordering and the retransmission to gain speed and simplicity. TCP and UDP are the two ways to use IP, chosen per application.
-
RFC 9000 · the modern redo
QUIC, the same idea rebuilt on UDP
HTTP/3 wanted TCP's reliability without its slow start and head-of-line blocking, so QUIC reimplements ordered, reliable, encrypted streams on top of UDP instead. A deliberate escape from TCP, forty years later.
Part of a guided cluster: The networking basics, explained