Ask what is TCP/IP and the answer arrives with a slash in the middle of it, as though the slash were incidental punctuation. It is the most consequential character in the name. And it was not there at the beginning: the first specification of the thing, RFC 675, published in December 1974 by Vinton Cerf, Yogen Dalal and Carl Sunshine, is titled “SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM”.
Program. Singular. One piece of software, doing the entire job of getting your bytes to another machine intact.
The shape you actually use — two protocols, one stacked on the other, with a defined seam between them — is not a fact of nature. Somebody argued for it in writing in 1977 and won. Almost everything that has kept the internet useful since comes out of that seam, including two protocols nobody had imagined when it was cut.
“Transmission Control Protocol” Appears Zero Times in RFC 675
Fetch the document as plain text and count: Transmission Control Program appears twice, in the title and in the first sentence of the introduction, and Transmission Control Protocol appears zero times in the whole specification. (Counted against the raw text on 8 September 2026.)
Two more counts from the same file make the point harder. The word datagram appears zero times. The word packet appears 344 times.
That is the 1974 architecture in miniature. Cerf, Dalal and Sunshine were certainly designing a network of networks — gateway and internetwork run throughout — but there was no delivery service underneath their program, so there was no unit of delivery to name. Packets were something the program moved, not something a lower protocol promised to carry.
What IP Promises the Layer Above It: Almost Nothing
Seven years later the delivery service exists as its own document, and it is blunt about its limits. RFC 791, Internet Protocol, September 1981:
The internet protocol does not provide a reliable communication facility. There are no acknowledgments either end-to-end or hop-by-hop. There is no error control for data, only a header checksum. There are no retransmissions. There is no flow control.
Five sentences, four of them refusals. That passage is what people mean by calling IP a best-effort service, and the phrase is worth taking literally: it sounds like an apology and is actually a contract. Under it your data may be lost, duplicated, reordered, or delayed by an arbitrary and variable amount, and none of that is a malfunction. A router that drops your packet because its outbound queue is full has not failed; it has done what the specification permits.
RFC 791 adds the detail that makes this stick:
The internet protocol treats each internet datagram as an independent entity unrelated to any other internet datagram.
No memory. Packet 2 knows nothing about packet 1, so nothing at the IP layer can notice that packet 1 never arrived, or that 3 and 4 arrived swapped. Nor is this about capacity: a link with spare bandwidth still loses packets, because loss is how a shared network signals a full queue.
The phrase everybody uses is not the specification’s phrase
One thing worth knowing before you cite anything here. “Best effort” and “best-effort” appear zero times in RFC 791, RFC 793, RFC 1122 and RFC 9293 — the four documents that define this split and its modern form. (Counted against the raw text of all four on 8 September 2026.)
The summary is ours. The specifications enumerate instead — a habit worth borrowing, because the enumerated version tells you what to build.
TCP Sells the Opposite Promise, Over Exactly That Wire
The current TCP standard, RFC 9293, states its contract in one sentence:
TCP provides a reliable, in-order, byte-stream service to applications.
The 1981 specification, RFC 793, states what it assumed it was standing on:
TCP assumes it can obtain a simple, potentially unreliable datagram service from the lower level protocols.
Put those two sentences side by side and you have the whole architecture. TCP does not repair IP and never asks it to be better. It assumes a network that misbehaves in specified ways, permanently, by design, and builds one mechanism per misbehaviour: sequence numbers because packets arrive out of order and duplicated, acknowledgements and retransmission timers because packets vanish, a receive window because a fast sender would overrun a slow receiver’s buffer, congestion control because a few million senders would overrun the network itself.
Each of those has its own article in this series. The point here is that they are not a feature list. They are all the same thing — the cost of the gap between those two sentences.
| Document | What it promises the layer above | What it refuses to do |
|---|---|---|
| RFC 791 — Internet Protocol (Sept 1981) | Address a datagram and make an attempt at delivering it | Acknowledge, retransmit, reorder, control flow, or relate one datagram to the next |
| RFC 768 — User Datagram Protocol (Aug 1980) | Ports and an optional checksum, directly over IP | Guarantee delivery, or protect against duplicates |
| RFC 9293 — Transmission Control Protocol (Aug 2022) | A reliable, in-order stream of bytes | Preserve your message boundaries, or hand over byte 101 while byte 100 is still missing |
The last cell is where people trip. TCP gives you a byte stream, not a sequence of messages: write two records, read once at the far end, and you may get one and a half of them. And because the ordering guarantee is unconditional, one missing byte holds up everything behind it that has already arrived. Both are consequences of the promise, not implementation defects.
The Argument for Splitting Them Is Dated 15 August 1977
The split was proposed in writing, in a memo by Jon Postel at ISI — IEN 2, 15 August 1977 — which opens its discussion section with no diplomacy at all:
We are screwing up in our design of internet protocols by violating the principle of layering. Specifically we are trying to use TCP to do two things: serve as a host level end to end protocol, and to serve as an internet packaging and routing protocol.
In that entire memo the word layering appears once, and layered once. It is not a treatise on layering. It is one accusation followed by a concrete proposal — a hop-by-hop internetwork protocol underneath, a host-level end-to-end protocol on top, a defined interface between them — which is precisely what shipped.
And it shipped fast.
| Document | Date | What it was |
|---|---|---|
| RFC 675 (Cerf, Dalal, Sunshine) | December 1974 | Specification of Internet Transmission Control Program — one thing |
| IEN 2 (Postel) | 15 August 1977 | The proposal to separate them |
| IEN 21 (Cerf) | January 1978 | TCP 3 Specification — still one thing |
| IEN 40 and IEN 41 (Postel) | June 1978 | Specification of Internetwork Transmission Control Protocol – Version 4 and Internetwork Protocol Specification – Version 4 — two documents, same month |
| RFC 791 and RFC 793 | September 1981 | The pair still running under everything you use |
(IEN titles and dates as printed in the RFC Editor’s Internet Experiment Note Index. The IEN texts survive only as scanned images, so they are cited by index entry rather than quoted.)
Read that index in order and a modern oddity resolves itself. The version numbers ran straight through the split — TCP Version 2, then TCP 3, then Version 4 issued as two separate specifications in the same month. RFC 791’s own field description says simply, “This document describes version 4.” The 4 in IPv4 is not the fourth Internet Protocol; it is the fourth version of a numbering that began when there was one program.
Postel’s stated reason was layering. The reason David Clark recorded in 1988, as one of the architects, was a pair of workloads that reliable delivery actively harmed — an argument with its own article in this series, and a better one than the tidy version.
The Payoff Landed in 1980, and Again in 2021
The seam matters more than the two things it separates. Once IP was a protocol in its own right, anything could sit directly on top of it — including software that wanted none of TCP’s guarantees. Two years after the split shipped, that is what appeared. RFC 768, User Datagram Protocol, J. Postel, ISI, 28 August 1980, runs to six pages and describes itself like this:
This protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed.
Then comes the sentence that shows the architecture working in public:
Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP) [2].
One specification pointing calmly at another for the case it declines to handle. That sentence is unwritable in 1974, because in 1974 there was no other case: one program, one promise, and if the promise was wrong for your workload you were out of luck.
Forty-one years later the same seam absorbed something nobody in 1978 could have described: RFC 9000, May 2021, is “QUIC: A UDP-Based Multiplexed and Secure Transport” — a transport that rebuilds TCP-style guarantees from scratch, in ordinary application code, on top of UDP, which is to say on top of the direct-to-IP path the split created. Why its designers did that rather than improve TCP belongs to another article here.
What belongs here is the arithmetic. A structural decision taken in June 1978 was still load-bearing in a protocol standardised in 2021, and the people who took it could not have known what for. If you ever want a reason to care about the shape of a system rather than its feature list, that is it. Nobody in 1978 was designing for a web browser.
Which Document You Cite Says Whether You Read It
One practical note, because getting it wrong is the commonest way to mark an article as written from memory: RFC 793 is obsolete. The current TCP standard is RFC 9293, W. Eddy, Ed., MTI Systems, August 2022, published as STD 7; its header lists what it replaced: “Obsoletes: 793, 879, 2873, 6093, 6429, 6528, 6691” and “Updates: 1011, 1122, 5961.”
Both are worth opening, for different jobs: RFC 793 states the reasoning most plainly and reads like a design document, while RFC 9293 is what a conformant TCP must do today. Cite whichever you mean, and say which.
RFC 793 was never an origin either. Its preface says so:
There have been nine earlier editions of the ARPA TCP specification on which this standard is based.
RFC 675 is one of those nine. The document most people treat as the beginning of TCP is its tenth edition, and the standard in force today is the one after that.
The Questions This Article Deliberately Leaves Open
You have never had to think about any of this, and that is the system working. Most software touches only the byte stream at the top, and the losses and reorderings underneath are absorbed by machinery you did not write and cannot see. An abstraction earns its keep by not leaking — until it does, at which point each of these becomes urgent:
- Why connection setup takes exactly three messages — and why the popular claim that it solves the Two Generals Problem is confidently wrong.
- TIME-WAIT, the connection state that shows up in production, gets blamed, and gets switched off by people who have not read what it defends against.
- Congestion control, in which every sender on the internet voluntarily slows down and nothing compels them to.
- The end-to-end argument — where a function belongs, and the qualification in the original paper that almost everyone citing it deletes.
- Seven layers versus four, both of which leak; one is called “an imperfect model” by the standard that defines it.
- QUIC and HTTP/3, where the protocol that won is being routed around inside the network it won.
- IPv6 adoption, where two excellent measurers disagree by five points on the same week.
Behind all of them is the larger question of how TCP/IP became the stack at all, when its rivals were not obviously worse — the reference article of this series, and the one to read for the argument rather than the mechanism.
❓ Frequently Asked Questions
Is TCP/IP one protocol or two? Two, and the slash is doing real work. IP addresses and delivers individual datagrams with no guarantees; TCP runs on top and manufactures a reliable, ordered byte stream out of that unreliable service. The name is also used loosely for the whole family — UDP, ICMP, ARP — which is why “the internet protocol suite” exists.
What does “best effort” actually mean? That your data may be lost, duplicated, delivered out of order or delayed unpredictably, and that none of it is a fault. RFC 791 puts it as a list of refusals: no acknowledgements, no retransmissions, no flow control, no error control on the data. Anything beyond that is manufactured above IP.
If TCP is more reliable, why does UDP exist at all? Because reliability costs time, and for some workloads a late packet is worse than a missing one — live audio and video being the classic cases, where a retransmitted fragment of speech arrives after the moment it belonged to. UDP (RFC 768, 1980) hands an application IP’s plain datagram service and lets it decide what to guarantee. That option exists only because TCP and IP were separated.
Is RFC 793 still the TCP specification? No. RFC 9293 (August 2022, STD 7) obsoleted it along with six other RFCs, consolidating decades of scattered corrections into one document. RFC 793 is still the better read for why TCP is shaped as it is; RFC 9293 is the authority for what an implementation must do.
Why is the common version of IP called version 4 when it was the first widely deployed? Because the numbering did not restart at the split. Versions 1 to 3 were versions of the single pre-split program — the RFC Editor’s IEN index lists TCP Version 2 in March 1977 and TCP 3 in January 1978 — and version 4 was the first issued as two separate specifications. RFC 791 inherited the number.
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.
Read the free material first, and mean it. This is one of the few subjects where the primary sources are genuinely better than the books about them: free, permanent, plain text, and often short enough to finish on a train. Every quotation in this article was taken from the raw text of the document rather than from a summary of it, and you can check any of them with find-in-page in about a minute. Start here; buy a book afterwards for the operational context the specifications deliberately leave out.
- RFC 675 — “Specification of Internet Transmission Control Program” (Cerf, Dalal and Sunshine, December 1974) — the document this article opens on. You do not need to read it closely; open it, read the title and the first paragraph, and search it for the word datagram. Ten seconds there does more for your intuition about why the stack is shaped as it is than a chapter of most textbooks.
- IEN 2 — “Comments on Internet Protocol and TCP” (Jon Postel, 15 August 1977) — the argument for the split, in about four pages, written by someone with no interest in being tactful about it. The best short demonstration in the whole record that architecture is something people argue for rather than something a system arrives with. The Internet Experiment Note Index is the companion piece: read the 1977–1978 entries in order and you can watch one specification become two.
- RFC 791 — “Internet Protocol” (September 1981) — worth reading for its first three pages alone, where it states what it will not do with a bluntness that modern specifications rarely manage. If “best effort” has ever felt like a vague term, this is the document that makes it concrete.
- RFC 768 — “User Datagram Protocol” (Postel, 28 August 1980) — six pages, and the best possible antidote to the idea that a protocol has to be large. It is also the clearest evidence that the split worked: a specification calmly directing you to a different one for the case it declines to handle.
- RFC 9293 — “Transmission Control Protocol (TCP)” (W. Eddy, Ed., August 2022, STD 7) — the current standard, and the one to cite for anything about what a conformant TCP does today. Long, but organised for reference rather than for reading straight through. Its predecessor RFC 793 (September 1981) remains the better explanation, because it argues rather than merely specifies — just do not cite it as current.
- RFC 9000 — “QUIC: A UDP-Based Multiplexed and Secure Transport” (Iyengar and Thomson, May 2021) — read the abstract and the introduction if nothing else. Seeing a 2021 standard building on the datagram service the 1978 split created is the whole argument of this article, made by the artifact instead of by me.
- The IETF Datatracker — free, and the fastest way to find out whether a document you are about to cite is still current. Worth making a reflex: it answers “has this been obsoleted?” in one page load.
TCP/IP Illustrated, Volume 1: The Protocols
Kevin R. Fall and W. Richard Stevens · 2nd edition, Addison-Wesley Professional, 2011 · Hardcover, 1,056 pp
The book to own if you want the two protocols as observed traffic rather than as specification prose, and the reason it has lasted three decades is its method: capture a real exchange, put the actual bytes on the page, and explain what each field is doing. That is exactly the gap between reading that IP may reorder your packets and watching it happen in a capture. Get the second edition — the 1994 original predates IPv6 and most of what you will actually see on a modern network. It assumes more comfort with the subject than this article does, so it is the right second book rather than the right first one.
Computer Networks: A Systems Approach
Larry L. Peterson and Bruce S. Davie · 6th edition, Morgan Kaufmann / Elsevier, 2021 · Paperback, 848 pp
The textbook that treats the layering of a network as a set of design decisions with alternatives, which is precisely the frame this article argues for. It is genuinely good on why a reliable byte stream is one choice among several, what a designer gives up by making it, and which problems get pushed upward as a result — the comparative view that turns TCP’s shape from an inevitability into a decision somebody made. Worth knowing before you buy that the authors maintain a freely licensed online edition, so you can judge the writing on its merits first.
Unix Network Programming, Volume 1: The Sockets Networking API
W. Richard Stevens, Bill Fenner and Andrew M. Rudoff · 3rd edition, Addison-Wesley Professional, 2003 · Hardcover, 1,024 pp
The bridge between the specification and the code you actually write. It is the book that explains what your program observes when the abstraction in this article holds and what it observes when it does not — why a read() returns fewer bytes than you asked for, what a TCP socket does differently from a UDP one, and why the byte-stream promise means your application still needs its own idea of where one message ends. Old, and its coverage of newer APIs shows that, but the socket semantics it documents have barely moved in twenty years.