In module 1 we left the blueprint of Grupo Meridiano's network finished: two stars (Valencia and Bilbao) joined by the logical link of the VPN. But a blueprint doesn't talk. When a Valencia consultant's PC asks the server for a file, what "language" does it ask in? Who decides how that conversation starts, how the data gets sliced up, what happens if a piece goes missing along the way? The answer to all of those questions is communication protocols: the sets of rules that let machines from different vendors, operating systems and eras understand one another perfectly. This lesson explains what exactly a protocol is, what elements it is made of, how several protocols cooperate at once through encapsulation, and closes with a bird's-eye example: everything that happens, protocol by protocol, when a Meridiano consultant opens a web page. It is the module's map lesson: the next four explore in detail each family we will only introduce today.

1. What is a protocol and why is it needed?
2. The human conversation analogy
3. The three elements of a protocol: syntax, semantics and timing
4. Nobody works alone: protocol families and stacks
5. Encapsulation: headers piling on
6. Guided example: a Meridiano consultant opens a web page
7. Common mistakes, exercises and conclusion

A communication protocol is a set of rules, agreed in advance, that defines how data must be exchanged between two or more devices: what format the messages have, what each part means, in what order they are sent, and what to do when something fails.

The key phrase is agreed in advance. Meridiano's network is home to a Linux server, Windows laptops, Android and iOS phones, a network printer and routers from a vendor we've never even heard of. None of those devices was designed with the others in mind and yet they all communicate flawlessly. That is only possible because they all implement the same protocols, which are published as open standards (many of them in documents called RFCs, Request for Comments, maintained by the IETF).

Without protocols, every vendor would invent its own format and only machines of the same brand could talk to each other. With standard protocols, interoperability is total: that is why you can swap the Bilbao router for one of any other brand and the VPN with Valencia will keep working.

A protocol must answer, at a minimum, these questions:

• Format: what structure does each message have? Where does the sender go, where the recipient, where the data?
• Order: who speaks first? Do you have to "say hello" before sending data?
• Errors: how do you detect that a message arrived corrupted, or never arrived? Is it resent or ignored?
• Pace: how fast can you send without overwhelming the receiver?

The best way to get an intuition for what a protocol does is to look at something we use every day without noticing: the protocol of a phone call between people.

Notice that the conversation has implicit rules both of them respect: who initiates, how you confirm the other person is listening, how you ask for a repeat, how you say goodbye. If Jon picked up and stayed silent, or if both talked over each other nonstop, the communication would fail even though they both speak the same language. Network protocols formalize exactly this kind of rule, with one difference: machines don't improvise — every step is defined bit by bit.

This analogy will stay with us for the whole module: when we get to lesson 02-04 and see the "handshake" TCP uses to open a connection, you will instantly recognize steps 1-3 of Ana's call.

Every protocol, human or computer, can be broken down into three elements. It is a classic classification worth memorizing, because it lets you "dissect" any protocol you come across in your career:

A concrete example with all three elements at once: when Ana's PC sends data to the file server and waits for an acknowledgment:

• Syntax: the acknowledgment is a message with an exact format (fields of so many bits, in such-and-such order).
• Semantics: that message means "I've received your data up to byte N, carry on".
• Timing: if the acknowledgment doesn't arrive within a set time, Ana's PC gives the data up for lost and resends it automatically.

Ana sees none of this. And that is the second great virtue of protocols: they automate communication transparently for the user.

Here comes the most important idea of the lesson: there is no single "Internet protocol" that does everything. Getting two applications to communicate across a network means solving problems of very different natures, and the solution was to split the work among specialized protocols that cooperate:

This set of cooperating protocols, each one building on the services of the one below, is called a protocol stack. The stack used by practically the entire planet — and of course by Meridiano — is the TCP/IP stack, named after its two most famous protocols.

Why split the work this way, by function? For the same reasons we separate responsibilities into modules in software:

• Specialization: each protocol solves one problem and solves it well.
• Substitutability: you can swap the cable for Wi-Fi (the link protocol changes) without touching anything else; the web keeps working exactly the same.
• Independent evolution: HTTP has gone through several versions without anyone having to touch Ethernet, and vice versa.

This function-based organization is so well established that there are two reference models that formalize it into numbered "layers": the OSI model and the TCP/IP model. We devote the whole of modules 3 and 4 to them, so for now just hold on to the idea: the families we cover in this module are precisely the layers of those models. By the time you get there, you will already know all the main characters.

If each protocol in the stack does a different job, how do they cooperate in practice on the same message? Through a wonderfully elegant mechanism called encapsulation: each protocol wraps the data it receives from the protocol above by adding its own header (a block of control information with its own particular syntax), just as a letter goes into an envelope, and that envelope could travel inside a postal service mailbag.

Let's watch it happen as Ana's PC sends the data of a web request:

Notice three important things:

1. Each protocol only reads and writes its own header. Ethernet doesn't know (or care) that a web request is traveling inside; all it knows is that it has to deliver the frame to the machine with a certain MAC address. It's like the postal carrier: they deliver envelopes without reading the letters.
2. At the destination, the reverse process happens — decapsulation: each protocol strips off its header, checks what concerns it, and passes the contents up to the protocol above, until the "clean" HTTP request reaches the web server.
3. Each unit has its own name: data with a TCP header is called a segment; with an IP header, a packet; with an Ethernet header, a frame. We will use these names with growing rigor over the coming lessons, and they are required vocabulary in any technical interview.

The diagram sums up the idea: on the sender, data goes down the stack (each protocol adds its header), and on the receiver it goes up (each protocol removes it). Protocols at the same level "converse" with each other through their headers, even though physically everything travels together down the cable.

Let's close the lesson with the promised bird's-eye view. Marta, a consultant in the Valencia office, types www.grupomeridiano.example into her browser and presses Enter. In under a second, and without her seeing any of it, every protocol family in this module gets involved. We won't go into the detail of any of them (that's what lessons 02-02 through 02-05 are for); the goal is to see who plays which role:

1. Application — resolving the name (DNS). The browser has no idea what www.grupomeridiano.example is; machines are located by IP addresses. An application protocol called DNS translates the name into an IP address, say 203.0.113.80. (Lesson 02-05.)
2. Transport — opening the conversation (TCP). Marta's PC and the web server run a quick "handshake" to agree that they are going to talk, and TCP will make sure nothing gets lost or arrives out of order. (Lesson 02-04.)
3. Application — requesting the page (HTTP). The browser phrases the request in the language of the web, HTTP: "give me the home page". The server will reply with the content. (Lesson 02-05.)
4. Network — routing the packets (IP). The request, sliced into packets, carries the destination IP address. Marta's PC sees that 203.0.113.80 is not on its local network, so it hands the packets to the Valencia router, which routes them toward the Internet hop by hop. (Lesson 02-03.)
5. Link — crossing each local leg (Ethernet). To physically get from Marta's PC to the router, the frame travels through the Valencia switch using MAC addresses. On every leg of the journey the same move is repeated with whichever link protocol applies (Ethernet, Wi-Fi, the carrier's fiber...). (Lesson 02-02.)
6. The trip back. The server's response retraces the path in reverse; TCP reassembles the pieces in order, HTTP delivers the content, and the browser paints it on the screen.

Notice the pattern: no protocol does another protocol's job. DNS only translates names; TCP only guarantees delivery; IP only routes; Ethernet only crosses the local leg. If tomorrow Marta connects over Wi-Fi instead of cable, only step 5 changes. If the site moves to HTTPS, only step 3 gets reinforced. That modularity is what we will study piece by piece throughout the rest of the module.

• Thinking that "the Internet runs on one protocol". A classic beginner's blunder: it runs on a stack of dozens of coordinated protocols. When someone says "the network runs on TCP/IP", they are naming the whole stack after its two most famous members.
• Confusing a protocol with a program. HTTP is not the browser, and SMTP is not Outlook. The protocol is the set of rules; the program is an implementation that follows them. That is why Chrome and Firefox, two different programs, open the very same websites.
• Believing encapsulation adds "copies" of the data. It doesn't: the data travels once; what gets added are small headers (tens of bytes) in front of it. The cost is minimal compared to what you gain.
• Skipping the "what for" and jumping straight to memorizing acronyms. In this module every protocol is always introduced with the problem it solves. If you know the problem, the acronym remembers itself; the other way around, it doesn't.
• Tip: whenever you come across a new protocol at work (and you constantly will), always ask it the three questions from this lesson: what syntax does it use? what do its messages mean? what timing rules does it follow? It is an analysis method that works with any protocol, from the oldest to the most modern.

Exercise 1. Classify each rule of this "conversation" between Marta's PC and the file server as syntax, semantics or timing:

1. "Every message starts with 6 bytes containing the recipient's address."
2. "If I don't receive an acknowledgment within 3 seconds, I resend the data."
3. "The message with code 550 means you don't have permission."
4. "Between one message and the next, you must wait for the receiver to confirm it is ready."

Exercise 2. Meridiano's administration department asks why, when the laptops switched from cable to Wi-Fi, "everything kept working exactly the same: the web, email, the files on the server". Explain it in two or three sentences using the concepts of protocol stack and substitutability.

Exercise 3. Arrange, from the inside out, how an HTTP request from Marta's PC ends up encapsulated just before leaving down the cable, and name the resulting data unit at each step: Ethernet header, IP header, TCP header, HTTP request.

Solution 1:

1. Syntax (it defines the format and position of a field).
2. Timing (it defines a maximum wait and what to do when it runs out).
3. Semantics (it defines the meaning of a message).
4. Timing (it defines the pace and turns of the exchange).

Solution 2: The applications (web, email, files) use application and transport protocols that do not depend on the physical medium. Moving from cable to Wi-Fi only replaced the link protocol (Ethernet with 802.11), and since each family in the stack works independently, building on the one below, the upper layers never even noticed the change. It is exactly the substitutability that motivates organizing protocols by function.

Solution 3: From the inside out: the HTTP request (application data) is wrapped with the TCP header (forming a segment), that is wrapped with the IP header (forming a packet), and that with the Ethernet header plus its trailer (forming a frame), which is what becomes bits and leaves down the cable. At the destination they are removed in reverse order: Ethernet → IP → TCP → HTTP.

We now know what a protocol is: a set of rules — syntax, semantics and timing — agreed in advance so that heterogeneous machines can communicate without ambiguity, just as two people unknowingly follow the "protocol" of a phone call. And we know something even more important: no protocol works alone. Communication is divided among specialized families — link, network, transport and application — that cooperate through encapsulation, adding and removing headers like envelopes within envelopes, forming the TCP/IP stack that the entire Internet uses and, of course, Grupo Meridiano too. In the example of Marta opening a web page we saw the full cast of roles from a bird's-eye view; now it is time to land on each family. We start at the bottom, with the one that solves the most immediate problem of all: how two machines that share the same cable, the same switch or the same Wi-Fi talk to each other. That is the territory of Ethernet, MAC addresses and ARP, and we explore it in the next lesson: Data Link Protocols.