At the end of the previous module we left an idea hanging: OSI is the theoretical map, but the territory — the real Internet that Grupo Meridiano's packets travel across every day — was built with a different stack, more pragmatic and with fewer layers. That stack is the TCP/IP model, and this lesson is your gateway into it: where it comes from, why it defeated the protocols the OSI community tried to impose, what design philosophy made it unbeatable, and how its four layers are organized. It matters because, unlike OSI, TCP/IP is not a model you "study": it is the software running right now on your laptop, on Meridiano's intranet server and on every router along the path between Valencia and Bilbao. Understanding it is understanding how the things you configure and diagnose actually work.

1. From ARPANET to the Internet: the history of TCP/IP
2. Why TCP/IP beat the OSI protocols
3. The design philosophy: pragmatism, robustness and the hourglass waist
4. The four layers of the TCP/IP model
5. The academic five-layer variant
6. The TCP/IP stack inside a real operating system
7. Marta's request, now in four layers

TCP/IP was not born in a standards committee, but in a research project with a very concrete problem to solve.

• 1969 — ARPANET: DARPA (the Defense Advanced Research Projects Agency, part of the US Department of Defense) funds an experimental network connecting four universities. Its initial protocol, NCP, worked — but only within that homogeneous network.
• The 1970s — the interconnection problem: other networks appear (radio, satellite, local networks) with mutually incompatible technologies. Vint Cerf and Bob Kahn pose the founding question: how do we connect different networks to each other? Hence the word Internet: inter-networking, the interconnection of networks.
• 1974: Cerf and Kahn publish the design of TCP. Shortly afterward the decision is made to split TCP into two protocols: IP (delivering packets between networks, with no guarantees) and TCP (end-to-end reliability). This separation, which you already know from modules 2 and 3, is one of the most influential design decisions in the history of computing.
• January 1, 1983 — the "flag day": ARPANET switches off NCP and switches on TCP/IP. This is the date usually cited as the technical birth of the Internet.
• The 80s and 90s: universities, and later companies and carriers, adopt TCP/IP en masse. The Unix BSD operating system ships it as standard along with its sockets API — if the system already comes with the stack for free, why implement another one?

A frequent confusion is worth clearing up here. OSI was not just the 7-layer model you studied in module 3: ISO also defined real OSI protocols for each layer (X.400 for email, X.500 for directory services, TP0-TP4 for transport...). During the 1980s many governments — including the US government — went as far as requiring OSI protocols in their procurement. And they still lost. Why?

The Internet community (the IETF, which publishes the RFCs) summed up its method in a famous motto, attributed to Dave Clark:

"We reject: kings, presidents and voting. We believe in: rough consensus and running code."

"Rough consensus and running code" means: an Internet standard is not approved by political vote, but when there is general agreement and at least two independent implementations that work and interoperate. TCP/IP won because by the time companies wanted to network, there was already working code — free and battle-tested — while the OSI protocols largely remained documents.

Hence the sentence that sums up this whole lesson: OSI won the vocabulary war; TCP/IP won the network war. We talk in OSI's 7 layers, but we build with TCP/IP's 4.

TCP/IP is not just a list of protocols: it is a way of thinking that explains why the Internet scales and survives. Three principles define it.

The network (the routers in the middle) does exactly one thing: move IP packets toward their destination, with no guarantees (best effort). It guarantees neither delivery, nor ordering, nor the absence of duplicates. This apparent weakness is the key to its scalability: a router doesn't need to remember anything about your connections — it just looks at the destination address and forwards (as you saw in 03-04). Less work per packet → simpler routers → a bigger, cheaper network.

If the network guarantees nothing, who does? The endpoints. The end-to-end principle says: complex functions (reliability, ordering, error control) must be implemented in the end machines — Marta's PC and the .10 server — not inside the network. It is exactly the division of labor you saw in 03-05: TCP at the endpoints reorders, retransmits and controls the flow; the routers in the middle never even notice.

This design was also born with robustness as an explicit goal: if a router along the path goes down, IP simply routes around it and TCP retransmits what was lost. Nobody has to "repair the session" in the middle of the network, because the middle of the network keeps no sessions.

Draw the protocol stack as an hourglass:

At the top, dozens of application protocols. At the bottom, dozens of physical technologies. And in the middle, a single protocol everything passes through: IP. That is the hourglass waist, and its consequences are enormous:

• Any application runs over any network technology, without knowing anything about it. Meridiano's intranet doesn't know whether Jon connects over fiber, Wi-Fi or 4G — and it doesn't need to.
• Innovation above and below is independent: you can invent a new application protocol (as HTTP was invented in 1991) or a new access technology (like 5G) without touching the rest of the stack. All you have to do is speak IP.
• The price: changing the waist itself is extraordinarily hard. That is why the transition from IPv4 to IPv6 (only mentioned here; we will cover it in module 5) has been underway for decades.

The TCP/IP model organizes everything you already know into four layers. It introduces no new protocols: it regroups the ones you mastered in module 2.

Note the two "mergers" compared with OSI (we will justify them in depth in 04-06):

• Network access = physical + data link: TCP/IP doesn't care what the medium looks like; it only needs the frame to reach the next hop. We will cover it in 04-02.
• Application = session + presentation + application: the functions of layers 5 and 6 (which in 03-06 and 03-07 you saw "dissolved" into TLS and the data formats) live inside the applications themselves. We will cover it in 04-05.

Each lesson in this module walks through one layer (04-02 to 04-05), and the last one (04-06) puts the two models face to face.

In many textbooks (Tanenbaum, Kurose & Ross...) you will see a five-layer stack: application, transport, network, data link and physical. It is not a third model: it is TCP/IP with its network access layer split in two, borrowing OSI's separation because it is didactically useful (the problems of a broken cable and those of a MAC table are very different, as you saw in 03-02 and 03-03).

Practical tip: when someone says "layer 2" or "layer 3", they are always numbering in OSI, even if they are working with TCP/IP. Nobody calls the Internet layer "layer 2". The numbers belong to OSI; TCP/IP layer names are used without numbers.

Here is the most important practical difference from OSI: TCP/IP is not a diagram, it is code installed on your machine. Let's see who implements what on Marta's PC (Windows) and on the intranet server (Linux).

• The application (the browser, the intranet server) implements the application layer: it builds the HTTP request, negotiates TLS, decides which host to resolve via DNS.
• The kernel (the core of the OS) implements transport and Internet: when the browser "sends data", it actually hands it to the kernel through the sockets API (02-04), and it is the kernel that manufactures TCP segments and IP packets, consults the routing table and handles retransmissions. That is why there is no program called tcp.exe: TCP is part of the operating system.
• The driver and the network card implement network access: frames, MAC addresses, signals.

And the commands you have already used are the configuration and query windows into that kernel stack:

Note the conceptual detail: ipconfig and ip send nothing over the network; they read and write the configuration of the TCP/IP stack living inside the kernel. When we use diagnostic tools in module 6, almost all of them will likewise be conversations with that stack.

In 03-01 you followed Marta's request to the intranet down OSI's 7 layers. Let's repeat it in the real-world model, with the PDUs you already know:

Four steps instead of seven, and not a single new function: DNS, TLS and HTTP live together in the application layer (what OSI split across 7, 6 and 5); the rest is identical. On the .10 server, the stack climbs in reverse order and delivers the request to the web server process listening on port 443. Same territory; more compact map.

• Believing TCP/IP is just two protocols. "TCP/IP" is the name of the whole family (also called the Internet protocol suite): it includes UDP, ICMP, DNS, HTTP... It is named after its two founding members.
• Thinking OSI and TCP/IP compete and you must pick one. They coexist with different roles: OSI is the vocabulary for thinking and communicating; TCP/IP is what is implemented. A good professional uses both (we systematize this in 04-06).
• Saying "TCP/IP layer 3". Layer numbers are OSI jargon. In TCP/IP, say "Internet layer". If you mix numbering schemes, the person you're talking to won't know whether your "layer 4" is transport (OSI) or application (TCP/IP counting from the bottom).
• Looking for the "TCP program" on the system. TCP and IP are implemented by the operating system kernel. Applications only see sockets. If a Meridiano developer asks "which HTTP library does the system ship for speaking TCP?", the answer is: no library implements TCP; they all use the kernel's.
• Dismissing IP's "best effort" as a flaw. It is a deliberate decision that makes Internet-scale possible. Reliability isn't missing: it is where it belongs, at the endpoints.
• Tip: memorize the hourglass drawing. It is the image that best explains why the Internet works over any technology and why IPv4→IPv6 is so slow.

Place each item in its TCP/IP layer (network access, Internet, transport or application): (a) the three-way handshake, (b) the DNS lookup of intranet.grupomeridiano.example, (c) the TTL that gets decremented at the Valencia router, (d) the 802.1Q-tagged frame on VLAN 10, (e) the ICMP "destination unreachable" message, (f) the TLS negotiation between Marta's browser and the intranet.

The VPN between Valencia and Bilbao runs over the Internet, and one afternoon an intermediate router at the carrier reboots. Jon was downloading a 200 MB file from the .10 server, and the download completed without errors, just a little slower. Explain which TCP/IP design principle (or principles) just saved the download, and what each layer involved did.

A Meridiano developer writes a script that calls GET /api/proyectos. For each of these actions, state whether it is performed by their code/library (user space), the kernel, or the driver/network card: (1) building the line GET /api/proyectos HTTP/1.1, (2) retransmitting a lost segment, (3) computing the frame's FCS, (4) choosing the outgoing interface by consulting the routing table, (5) encrypting the data with TLS.

Exercise 1: (a) transport — that's TCP (02-04). (b) application — DNS is an application protocol (02-05). (c) Internet — the TTL is a field in the IP header (02-03). (d) network access — 802.1Q is Ethernet/VLAN (03-03). (e) Internet — ICMP accompanies IP at its layer (02-03). (f) application — TCP/IP has no session/presentation layers; TLS lives with the application (03-06/03-07 explain why).

Exercise 2: Principles: IP's best effort + robustness, and the end-to-end principle. The Internet layer kept no state about the download in the failed router: as soon as the carrier's routing protocols converged, packets flowed along another path (hop-by-hop routing, 03-04). The packets lost during the outage were not recovered by the network: they were detected and retransmitted by TCP at the endpoints (the .10 server resent whatever was unacknowledged). Jon's application never noticed: it just saw a slightly slower byte stream. The network did the bare minimum; the endpoints guaranteed reliability.

Exercise 3: (1) code/library — application layer in user space. (2) kernel — TCP lives in the kernel. (3) driver/card — the FCS is normally computed by the NIC's hardware (03-03). (4) kernel — the routing table belongs to the kernel (Internet layer). (5) code/library — TLS is implemented by a user-space library (e.g. the TLS library the script's language uses), not by the kernel.

You now know the territory as a whole: TCP/IP was born in ARPANET to interconnect different networks, defeated the OSI protocols thanks to running code and open specifications, and rests on three ideas — a minimal best-effort network, intelligence at the endpoints, and IP as the universal waist everything passes through. Its four layers (network access, Internet, transport and application) bring no new protocols: they reorganize everything you learned in module 2, and they live as real code in the kernel, the libraries and the drivers of every machine at Meridiano. Over the next four lessons we will descend into each layer with a practical eye — not "what it does" (you already know that), but "how you see and touch it on a real system". We start at the bottom, with the layer TCP/IP deliberately left open so it could run over any cable, wave or fiber: the network access layer.