We have climbed the whole stack: the data link crosses the local segment, IP joins the networks, TCP and UDP deliver to the right application with just the right guarantees. All that machinery exists to serve the top floor, the only one users ever see: the application protocols, the concrete "languages" programs use to do useful things. When Marta opens the intranet, when the Bilbao server receives an email, or when a freshly booted laptop gets its IP address without anyone configuring anything, an application protocol is at work. In this lesson we tour the essentials: HTTP/HTTPS (the web), DNS (the Internet's phone book), the email protocols (SMTP, IMAP, POP3), file transfer (FTP/SFTP) and DHCP (automatic address assignment). With it we complete module 2's catalog of families and stand ready for the next step: the formal map that puts them all in order.

1. The application family: the protocols programs see
2. HTTP: the protocol of the web
3. HTTPS and TLS: the web in a sealed envelope
4. DNS: the Internet's phone book
5. Email: SMTP, IMAP and POP3
6. File transfer: FTP and SFTP
7. DHCP: automatic IP addresses
8. The module's complete picture

An important nuance before we start: an application protocol is not the same as an application (we warned about this in 02-01, and here it becomes obvious). Chrome, Firefox and curl are different applications; HTTP is the protocol all three speak. Outlook and Thunderbird are programs; SMTP and IMAP are their languages. The protocol defines the messages; the program, the experience.

All the protocols in this lesson share three traits:

• They rest on the transport layer: each one chose TCP or UDP according to its needs (the previous lesson's table comes alive today), and each has its well-known port.
• Almost all follow the client-server model we defined in lesson 01-02: a server listens on its port; clients initiate the requests.
• Many are readable: their messages are text a human can read, which makes them ideal for learning (and for troubleshooting, as we will do in module 6).

HTTP (HyperText Transfer Protocol) is the request-response protocol the web runs on: the client (browser) asks, the server answers, and each exchange is independent. Its messages are plain text with crystal-clear syntax. When Marta opens the Meridiano intranet, her browser sends (over a TCP connection to the corresponding port) something like this:

• GET is the method: which operation is being requested.
• /informes/2026 is the requested resource within the server.
• The following lines are headers carrying metadata (which site is being asked, which formats the client accepts...). A blank line closes the request.

And the server responds:

The first line carries the status code, the semantics of the result. The essential methods and codes every professional must recognize:

A mnemonic rule worth gold in support work: 4xx codes say "the problem is in the client's request"; 5xx codes say "the problem is on the server". A 404 after an intranet revamp points to a stale link; a 500 says the intranet server needs attention.

HTTP travels in clear text: anyone able to see the traffic (say, on someone else's Wi-Fi) could read entire requests and responses, passwords included. HTTPS is exactly the same HTTP, but carried inside an encrypted tunnel called TLS (Transport Layer Security), established right after the TCP connection and before the first request. Conceptually, TLS provides three guarantees:

• Confidentiality: the content is encrypted; an observer sees only unintelligible bytes.
• Integrity: any tampering along the way is detected.
• Authentication: through a digital certificate, the server proves it is who it claims to be (that intranet.grupomeridiano.example really is Meridiano's server and not an impostor). This is what the browser checks when it shows the padlock — or the red warning when something doesn't add up.

We won't go into the cryptography (beyond this course); keep the mental model: HTTPS = HTTP inside a sealed, signed envelope, port 443 instead of 80. Today it is the standard: Meridiano's public website and its intranet both run over HTTPS, and a site on plain HTTP is a red flag.

We have been using it without naming it since lesson 02-01: people use names (www.grupomeridiano.example) and the network uses IPs (203.0.113.80). DNS (Domain Name System) is the distributed system that translates one into the other. Without it, the Internet would keep working... but you'd have to know the IPs by heart.

When Jon's laptop in Bilbao needs to resolve a name, it asks (over UDP, port 53: short query, short answer — the textbook case from the previous lesson) its configured DNS server, called the resolver. And here lies the system's elegance: if the resolver doesn't know the answer, it finds out by walking the name hierarchy from right to left:

Two details that make the system workable at planetary scale:

• Caching at every level: each answer carries a validity time (TTL — not to be confused with IP's TTL); the resolver — and the operating system itself — remember it, and subsequent queries are answered instantly, without repeating the walk.
• Delegation: nobody holds the complete list; each level only knows whom to ask about the next. Meridiano administers only the names of its own domain.

The data DNS stores is organized into records of different types. The four basic ones:

All of this can be queried by hand with nslookup, available on Windows and Linux:

Reading it: first it identifies which resolver it is asking (the one configured on the machine); "non-authoritative answer" means it came from the resolver's cache, not from the domain's DNS server — perfectly normal. You can request a specific record type:

When "the Internet is down" but a ping to an IP works, the usual culprit is DNS: names won't resolve even though the network is perfectly fine. nslookup is the tool that separates the two worlds in seconds; we will come back to it in module 6.

Email is the Internet's oldest federated system, and it uses different protocols for sending and for reading — the classic source of confusion we are about to clear up:

• SMTP (Simple Mail Transfer Protocol): the sending and routing protocol. Your mail program uses it to hand the message to your server, and servers use it among themselves to get it to the recipient's server. It is readable text: MAIL FROM, RCPT TO, DATA...
• IMAP (Internet Message Access Protocol): the modern reading protocol. The mailbox lives on the server; the client browses and synchronizes it. You read an email on your phone and it shows as read on your laptop.
• POP3 (Post Office Protocol v3): the classic reading protocol: it downloads messages to the device (typically deleting them from the server). Simple, but awkward with several devices; today it is a minority player next to IMAP.

The journey of an email from Marta ([email protected]) to an external client ([email protected]):

Look at step 2: the DNS MX record is the hinge of the whole system — it is how the world's mail servers find each other without any central directory. Application protocols don't live in isolation: they lean on one another.

FTP (File Transfer Protocol) is the veteran of file transfer: sessions with username and password, commands to list, upload and download. It is worth knowing because it still turns up on old systems and because its great flaw teaches a lesson: it transmits everything in the clear, credentials included (and it uses separate connections for control and data, which complicates its path through firewalls).

Its modern replacement is SFTP (SSH File Transfer Protocol): same job, but built on SSH's encrypted channel (port 22), with robust authentication and all traffic protected. When Meridiano needs to exchange files with external clients, it publishes an SFTP endpoint; plain FTP was banned by internal policy.

A note to avoid confusion: day-to-day files inside the Valencia office don't travel over FTP/SFTP, but over the server's shared-folder protocol (SMB, the port 445 that peeked out in netstat last lesson). FTP/SFTP shine in exchanges between organizations or with remote servers.

We close with the most invisible and most appreciated protocol. In the previous module we mentally configured IPs, masks and gateways; does anyone type them into every Meridiano laptop and phone? No: DHCP (Dynamic Host Configuration Protocol) does it, the protocol that assigns network configuration automatically when a machine connects.

The exchange is known as DORA, after the initials of its four messages (over UDP, ports 67/68, because the client doesn't have an IP yet and needs broadcast — the third UDP use case we saw):

Details that matter:

• The assignment is a lease with an expiration: the machine must renew it periodically, and the addresses of machines that leave become free for others.
• The final ACK delivers the complete configuration bundle: IP, mask, gateway and DNS server — exactly the settings whose purpose we learned in lesson 02-03 and in this one. DHCP is the protocol that hands out what we already know how to interpret.
• Machines that offer services get a fixed IP outside the DHCP range (at Meridiano: server .10, router .1, printers .40): a server whose IP changed every day would be impossible to find.

We will return to DHCP in module 5, when we study addressing in depth; here it stands introduced as what it is: the application protocol that gets all the others started.

With the application family, the catalog is complete. Here is module 2 in a single table — keep it, because it is the skeleton of everything to come:

And the encapsulation from lesson 02-01 assembles them: the HTTP message travels in a TCP segment, inside an IP packet, inside an Ethernet frame. Each family with its header, its address and its job.

• Confusing the protocol with the program (once more, because it is the eternal mistake): "Outlook isn't working" may be a problem with SMTP (sending), IMAP (reading), DNS (finding the server) or the program itself. Naming the right protocol is half the diagnosis.
• Forgetting that the modern web is HTTPS. Testing a service with http:// when it only listens on 443, or being puzzled by a certificate warning without reading what it says, are first-week stumbles. The padlock is not decoration: it is TLS's authentication.
• Blaming "the Internet" when DNS fails. If websites won't load but ping 203.0.113.80 answers, connectivity is fine and what's broken is name resolution. nslookup confirms it in ten seconds.
• Ignoring the DNS cache when making changes. After changing a record, half the world will keep seeing the old value until the caches expire. Patience (or lowering the record's TTL before the change) is part of the trade.
• Tip: learn this lesson's port table (80, 443, 53, 25, 993, 22, 67/68) as basic vocabulary. In netstat, in firewalls and in job postings, services are named by their port.

Exercise 1. Jon, in Bilbao, types https://intranet.grupomeridiano.example on a freshly booted laptop that has just joined the network. Put in chronological order all the application and transport protocols involved until he sees the page, stating the role of each one: DHCP, DNS, TCP, TLS, HTTP.

Exercise 2. State which DNS record type (A, AAAA, CNAME or MX) solves each Meridiano need: a) making www.grupomeridiano.example point to the public IP 203.0.113.80; b) making email addressed to @grupomeridiano.example arrive at mail.grupomeridiano.example; c) making intranet.grupomeridiano.example an alias of the server's real name, servidor01.grupomeridiano.example; d) making www also reachable over IPv6.

Exercise 3. In Valencia, a user reports: "I can't get into any website, external or the intranet". From their machine you check: ping 192.168.10.1 answers; ping 203.0.113.80 answers; nslookup www.grupomeridiano.example fails with a timeout. Which protocol/service would you flag as broken, and why do you rule out the LAN, the router and the Internet uplink?

Solution 1:

1. DHCP (UDP): the laptop, with no IP yet, runs its DORA and receives an IP, mask, gateway and DNS server.
2. DNS (UDP): the browser needs the IP of intranet.grupomeridiano.example; the resolver obtains it (or serves it from cache) and answers, for instance, 192.168.10.10 via the corresponding CNAME→A records.
3. TCP: three-way handshake with 192.168.10.10:443 to open the connection.
4. TLS: over that connection the encrypted tunnel is negotiated and the server authenticates with its certificate.
5. HTTP: inside the tunnel, GET / and a 200 OK response with the page, which the browser displays.

Solution 2: a) A (name → IPv4). b) MX (domain → mail server). c) CNAME (alias of another name). d) AAAA (name → IPv6).

Solution 3: The broken piece is the DNS service (or the path to the configured resolver). Reasoning by elimination: ping 192.168.10.1 answers → the LAN, the switch and the machine work; ping 203.0.113.80 answers → the router, the gateway and the Internet uplink work (all the way to an external IP!); but nslookup gets no answer → names aren't resolving, and without resolution the browser can't even start (which is why "every website" fails, intranet included, since all are reached by name). The natural next step: check which DNS server the machine has configured (did DHCP hand it out correctly?) and whether that server is up.

With the application protocols, the module is complete: HTTP/HTTPS requests and delivers the web with its methods and codes (and TLS wraps it in a sealed, authenticated envelope), DNS translates names into addresses by walking its hierarchy with caching at every level and A, AAAA, CNAME and MX records, email travels via SMTP and is read via IMAP (or the veteran POP3), finding its destination thanks to the MX record, SFTP moves files encrypted where FTP moved them in the clear, and DHCP opens the show by handing out, with its DORA, the configuration that makes everything else possible. Now look at the module's complete picture: application, transport, network and data link — four families, each with its mission, its data unit and its addresses, assembled by encapsulation. That picture is no ordinary summary: it is, almost literally, a layered model, and we are not the first to draw it. The industry formalized it decades ago into a seven-layer reference framework that gives every function a name and a number, organizes the vocabulary of the entire profession, and structures everything from certification syllabuses to support conversations ("it's a layer 3 problem"). That map is the OSI model, and we devote module 3 to walking it layer by layer, starting with the next lesson: Introduction to the OSI Model.