We reach the top of the TCP/IP stack: the application layer, the territory where the protocols that do something visible for people live — the web page Marta opens, the email Jon sends, the name resolution that happens without anyone seeing it. Its protagonists you already know from 02-05 (HTTP, TLS, DNS, email, SFTP, DHCP), so we won't dissect them one by one again. What this lesson adds is the architecture: why TCP/IP puts into a single layer what OSI spreads across three, where the practical boundary sits between "my application" and "the network" (hint: in the libraries and the operating system's API), and — the main course — the complete, ordered journey of a real request, GET /api/proyectos to Meridiano's intranet, from the line of code down to the socket from the previous lesson. We will close with an idea that usually goes unnoticed: DNS and DHCP are applications that serve the network itself, and with the complete port map of Meridiano's services. It matters because this is where 90% of IT professionals work every day: above the socket, but needing to understand what lies beneath.

1. One layer worth three: the merger of OSI 5-7
2. The familiar protocols, placed in the TCP/IP stack
3. The practical boundary: libraries and OS APIs
4. Anatomy of a real request: GET /api/proyectos, step by step
5. Infrastructure services: applications that serve the network
6. Meridiano's port landscape

In module 3 you devoted three lessons to OSI's upper layers — session (03-06), presentation (03-07) and application (03-08) — and in each one you reached the same conclusion: their functions exist, but in real software they don't live in separate layers. TCP/IP simply makes that reality official: above transport there is one single application layer, and each protocol solves within itself, however it sees fit, whatever session and presentation functions it needs.

The canonical example you've already worked through: HTTPS. In OSI terms, TLS does session things (establishing and resuming secure sessions) and presentation things (encrypting, negotiating formats), and HTTP does application things... but also session things (cookies, keep-alive) and presentation things (Content-Type, gzip compression). Trying to carve HTTPS into layers 5-6-7 is an exercise in taxidermy; TCP/IP declines to attempt it:

Why is this the right decision for building? Because session and presentation needs vary enormously between applications: DNS needs no session at all; SSH needs a persistent encrypted session with its own multiplexing; HTTP went from "one connection per request" (HTTP/1.0) to multiplexing dozens of requests per connection (HTTP/2) without any other layer having to change. Standardizing those functions into fixed layers would have been a straitjacket. The trade-off: when you diagnose, OSI's finer vocabulary remains useful — "this fails at presentation" (a badly encoded JSON) is more precise than "this fails at application". We will discuss that dual use in depth in 04-06.

Let's put the 02-05 catalog in its place, with its transport and its port — the two identity marks of an application protocol in TCP/IP:

Two architect's observations:

• The port is the protocol's "social" address. That HTTPS is "443" is a convention (IANA's well-known ports), not a law of physics: Meridiano's intranet could listen on 8443 and work just the same — but every client would have to know. Conventions exist so nobody has to be told.
• What about TLS? It has no row of its own because it isn't an application: it is an intermediate security layer that slots between the transport and whatever application protocol uses it (HTTPS = HTTP over TLS; IMAPS = IMAP over TLS). On the TCP/IP map it lives inside the application layer, hugging its floor. It is one of 04-06's star borderline cases.

Here is the lesson's most useful idea for a developer: where does "my program" end and "the network" begin? The answer takes the shape of a ladder of abstractions:

Readings of this drawing:

• The application layer runs in user space. Everything above the sockets line is program code and libraries; everything below is the kernel (04-01). HTTP is not "in the operating system": it is in the library your program loads.
• Each rung spares you the ones below. The intranet's programmer writes one line (http_get(...)) and the libraries do the rest. But when something fails, the error can be born on any rung — and the messages give it away: NXDOMAIN (the resolver failed), certificate verify failed (TLS failed), connection refused (the socket's connect failed, 04-04), 404 Not Found (everything below worked; the HTTP conversation failed).
• The sockets API is the universal meeting point. No matter the language or the library: in the end, they all wind up calling connect, send and recv. That is why lesson 04-04 is the module's hinge.

Let's put all the pieces together. The projects panel Marta has open in her browser executes:

What happens between that line and the JSON on screen, in order and with its layer:

Step 1 — Name resolution (application: DNS). The library extracts the name intranet.grupomeridiano.example and calls the OS resolver (getaddrinfo). If the name is not cached, the resolver sends a DNS query — a UDP datagram to port 53 of the configured DNS server (in Valencia, the router .10.1 itself acts as the network's DNS and answers with the local record). Answer: 192.168.10.10. Fine detail: to make this query there was already networking underneath — a UDP socket, an IP packet, a frame. The first "application" that works in every web request is DNS.

Step 2 — Connection (transport: TCP). IP address in hand, the library opens a socket and does connect(192.168.10.10, 443): the three-way handshake from 02-04, exactly as you saw it from code in 04-04. Marta's kernel picks an ephemeral source port (e.g. 52814); on the server, nginx's accept() picks up the connection. State: ESTABLISHED on both sides. (Underneath, each segment traveled in IP packets decided by 04-03's routing table and in frames on 04-02's network — but we don't even look at that anymore: the lower layers just work, which is exactly their job.)

Step 3 — TLS handshake (application: security). Before the first byte of HTTP, the TLS library negotiates over the freshly opened connection: versions and ciphers, the server presents its certificate for intranet.grupomeridiano.example, the client validates it (is it signed by an authority I trust? does the name match?) and both agree on session keys (02-05, now in its exact place in the sequence). From here on, everything passing through the socket is encrypted: anyone capturing the traffic will see that Marta talks to the intranet, but not what she says.

Step 4 — Request and response (application: HTTP). At last, the library writes into the encrypted channel:

The server responds 200 OK with Content-Type: application/json and the body — the project list. The library checks the status code, decompresses if needed, and returns the data to Marta's code. In total: one line of code, four network conversations (DNS, TCP, TLS, HTTP), and the entire stack from the previous modules working underneath unseen.

This four-step script is, moreover, your diagnostic checklist for any "it won't load": does the name resolve? → does the port connect? → does the certificate validate? → what does HTTP answer? Each question isolates one rung of the ladder. In module 6 we will turn it into a method with tools.

There is a category of application protocols with a delicious philosophical quirk: technically they live in the application layer (they run in user space, use a transport, have a port), but their client is not a person — it is the network itself. Without them, the layers below never get going:

• DHCP (02-05): when Ana's laptop joins Valencia's Wi-Fi, it has no IP yet, no mask, no gateway, no DNS server. DORA hands them over... using UDP and broadcast — that is, using the stack to configure the stack. It is an application whose product is that everyone else's layers 2-3 work. At Meridiano, the DHCP server runs on router .10.1 and hands out the .10.100–.10.199 range (fixed machines, like the .10.10 server or the printer, have a static IP or a reservation).
• DNS (02-05): without it, the Internet "works" but is unusable — nobody browses by IP. Every DNS query is a complete mini-application (UDP socket, datagram, response) that runs before the "real" application can even start. At Meridiano, router .10.1 resolves the internal names (intranet.grupomeridiano.example → 192.168.10.10) and forwards the rest to the provider's DNS.
• NTP: synchronizes the clocks. It seems cosmetic until you remember step 3 of the request: TLS certificate validation compares dates — a server with its clock off by years starts rejecting all certificates and "the Internet goes down" in the most baffling way possible.

The architectural moral: in TCP/IP there is no separate "management" layer — the network administers itself with perfectly ordinary applications. It is 04-01's pragmatism taken to the extreme: if something can be solved with an application protocol over UDP, don't invent a new layer.

Let's close with the company's complete service map — the table Ana has (or should have) taped to the wall, which is at once an inventory, a diagnostic guide and the basis for the firewall rules:

Notice how the table condenses the entire module: each row is an application (this lesson) over a transport and port (04-04), reachable thanks to routing (04-03) over each site's interfaces (04-02). Four layers, one row per service.

• Believing "application layer" = "my application". The application layer is the protocols (HTTP, DNS...); your program is a user of those protocols through libraries. The browser is not HTTP: it speaks HTTP.
• Forgetting that DNS happens first. Half of humanity diagnoses "the web doesn't work" by rebooting the router when the failure was name resolution. First question, always: does the name resolve? (In module 6: nslookup/dig.)
• Placing TLS "in the transport" because it's called Transport Layer Security. The name misleads: TLS runs in user space, over TCP, inside TCP/IP's application layer. The full nuance, in 04-06.
• Assuming the port defines the protocol. 443 is usually HTTPS by convention, but nothing prevents serving something else there (or HTTPS on 8443). Ports are convention, not verification — serious firewalls inspect beyond the number.
• Ignoring infrastructure services in diagnoses. If DHCP fails, "nothing works" on the laptops but fixed-IP machines are fine; if DNS fails, "nothing works by name" but ping to the IP is fine; if NTP drifts, TLS fails in absurd ways. All three patterns are pure gold for isolating problems.
• Tip: internalize the 4-step script (DNS → TCP → TLS → HTTP) until it becomes reflex. It is the skeleton of any web service diagnosis and the structure we will build module 6's methodology on.

1. Jon, from Bilbao, opens https://intranet.grupomeridiano.example/api/proyectos and gets an error. Ana checks from Jon's PC: nslookup intranet.grupomeridiano.example answers 192.168.10.10; right after, a test connection to port 443 of that IP times out. (a) Which steps of the 4-phase script have worked and which has failed? (b) Which TCP/IP layer is the problem probably in? (c) Which concrete element of Meridiano's infrastructure is the prime suspect?

2. Classify these three incidents by which infrastructure service has failed, reasoning from the symptom pattern: (a) the laptops in Valencia's meeting room can't access anything, but the .10.10 server and the printer work normally for everyone else; (b) nobody can open the intranet by name, but https://192.168.10.10 (accepting the certificate warning) works; (c) for a week now, the file server rejects all HTTPS connections with "certificate not valid: not yet valid" errors, but only from some machines.

3. Ana wants to harden the Valencia router's firewall for traffic inbound from the VPN (Bilbao → Valencia): the branch only needs to use the intranet, the shared files, and Ana must be able to administer via SSH. Using Meridiano's port table, write the minimal list of "allow" rules (destination, transport, port) and explain why DNS and DHCP need no rule in that direction.

1. (a) Step 1 (DNS) works: the name resolves to the correct IP. Step 2 (TCP connection) fails with a timeout: neither TLS nor HTTP is ever reached. (b) A connection timeout (03-05, 04-04) suggests the SYNs aren't arriving or aren't coming back: a problem in the Internet layer (routing/reachability) or a firewall dropping — it is not a problem with the intranet application (that would give "connection refused" or an HTTP error). (c) The prime suspect is the Bilbao–Valencia VPN tunnel: it is Jon's mandatory path to 192.168.10.10. Quick check: ping 192.168.10.10 from Bilbao and review the tunnel's state on routers .20.1 and .10.1. (DNS answering does not exonerate the VPN if Bilbao's resolver has a cache or resolves locally.)

2. (a) DHCP: it affects only machines requesting dynamic configuration (laptops arriving in the room), while fixed-IP ones (server, printer) keep working. Probably an exhausted dynamic range or the router's DHCP service down. (b) DNS: the "not by name, yes by IP" pattern is its unmistakable signature — the whole network works; only the translator is missing. (c) NTP (clock): "not yet valid" means the client machine believes it is at a date earlier than the certificate's validity start — skewed clocks on those specific machines. That is why it affects "only some": each machine carries its own wrong clock.

3. Minimal inbound rules from the VPN: allow TCP:443 to 192.168.10.10 (intranet HTTPS), allow TCP:445 to 192.168.10.10 (SMB), allow TCP:22 to 192.168.10.10 and 192.168.10.1 (administration SSH; ideally further restricted to the IP of Ana's machine), and deny the rest. DNS needs no rule in that direction because Bilbao's machines ask their own DNS (router .20.1 or whatever they have configured), not Valencia's — the query doesn't cross the tunnel toward .10.1. Neither does DHCP: it works by broadcast within each local network (02-05) and broadcasts cross neither routers nor tunnels — Bilbao has its own DHCP on .20.1.

TCP/IP's application layer is the honest merger of OSI 5-7: each protocol solves session and presentation its own way, and the real boundary between "program" and "network" is not in a diagram but at the sockets API, with the libraries (HTTP, TLS, resolver) as intermediate rungs that save work — and as an orderly lineup of suspects when something fails. You can now walk the complete script of a real request (DNS → TCP → TLS → HTTP), recognize in DNS, DHCP and NTP the applications that serve the network itself, and read Meridiano's port map for what it is: the whole of module 4 compressed into one table. With all four layers now covered from bottom to top, one last task remains before closing the module: putting the two maps — OSI and TCP/IP — side by side, deciding when to use each, and defusing the classic boundary confusions (where does ARP go? and TLS?). That comparison is the module's next and final lesson.